Hyper-V NIC Teaming

In a previous post I wrote about my experiences with Hyper-V on Server 2008 R2, and that teaming didn't work.

Well the good news is it works. The bad news is it feels like a house of cards.

Working with HP DL380 G5 and the very latest Proliant Support Pack (PSP 7.6) I managed to setup Hyper-V (on 2008 R2 Core) for Live Migration on teamed NICs. The storage is fibre attached and I would imagine that iSCSI teams are still not possible, but if anyone manages to do this let me know.

Anyway, onto the details.

For an exisiting Hyper-V server:

• Do one host at a time Live Migrating everything off it before starting
• Delete your Virtual Networks through Hyper-V Manager
• Install the PSP, downloading and updating NIC firmware as required
• Reboot
• Download the HP Network Configuration Utility (NCU) for 2008 R2 and install
• Reboot
• Create the team using the util C:\Program Files\HP\NCU\hpteam.cpl
• Reboot
• Set the IP info for your net interface (sconfig)
• Restart Hyper-V and Cluster services
• Recreate your Virtual Networks in Hyper-V manager.

Note: The last step is that hardest and takes ages to process so BE PATIENT.

also if it does fail then you have to break your team, reboot, recreate your team and try again.

I'd recommend turning off Windows Updates and avoid doing them for the moment. There is talk of windows updates breaking the teaming. Your own testing will be required on this one.

EDIT; I found a hiccup with teaming and MAC address. Have a read just so you are aware; http://anicegameof.blogspot.com/2010/04/hyper-v-mac-conflicts.html

Application Virtualization (AppV)

So I've had some fun installing AppV 4.5 recently and thus far it's all been a little too easy.

Tip:
Install IIS first - including all the IIS6 management and the Windows Authentication components.
Certificate - Hey another ceritificate. Setup the site for SSL.
Active Directory - Create a AppV management and an APPV user group (and also a service account) before you install. Add your admin account to the management group.

Gotcha:
No 64-bit support till the next version (4.6) is released.
That means no Windows 2008 R2 installs and no 64-bit client.
This will bite you if you deploy 64-bit Windows 7 (Which I would always do given the choice)
Update: Got a copy of the 4.6 Public Beta client and will be giving that a bash.

...and now time to sequence some apps. More about that to follow.

Command Line

Changing the theme of this Blog for a moment I'm going to use this post as my own person dumping ground for stuff relating to Server 2008 Core and other Command Line thing... mostly so I have an easy reference place online. Steal / use whatever you like :)

Moving the Page File

diskpart.exe

DISKPART> select disk 0
DISKPART> select partition 1
DISKPART> shrink desired=2280
DISKPART> create partition primary
DISKPART> select partition 2
DISKPART> format fs=ntfs label="Swap"
DISKPART> assign letter=E
DISKPART> exit

wmic.exe computersystem where name=”%computername%” set AutomaticManagedPagefile=False
wmic.exe pagefileset create name="E:\pagefile.sys"
wmic.exe pagefileset where name="E:\\pagefile.sys" set InitialSize=2048,MaximumSize=2048
wmic.exe pagefileset where name="C:\\pagefile.sys" delete

Turning off Hibernation (on by default on 2008)

powercfg.exe /hibernate off

Windows Deployment Services 2008

At the same time as making great headway into a centralized computing model and all the technologies around that (Hyper-V, RDS, App-V), Microsoft haven't stopped developing the old and familiar.

Remote Installation Services (RIS) has been upgraded and rename Windows Deployment Services (WDS). Coupled with MS Deployment Toolkit 2010 and the Automated Install Kit this becomes very appealing for management of your desktop and non virtualized server environment, especially in like of the imminent Windows 7 release.

The biggest downfall of ye ol faithful RIS was that any images were either tied to a hardware / driver set or relied on Sysprep to effectively reinstall the drivers.

WDS takes advantage of the WIM format, which is a file based image format. This makes replacing files within the image and during it's deployment an easy task. The upshot is that this solves all the annoying issues with RIS.

Short version; Anyone undertaking a large Windows 7 deployment should take a serious look at WDS first. This coupled with "Easy Migration", which is part of Windows 7, makes this a lot less scary an undertaking.

What you need to do;

Server setup

• Install Server 2008 R2 and the Windows Deployment Services role.
• Download and install MDT2010 and the AIK.
• Open up the WDS management console
• Add a deployment point where you want to store all your data
• Add a source OS (basically copy the DVD) via a wizard
• Add some apps you want to be available, also via a wizard - Office is a good example
• Create a Task Sequence for the above
• Add the new WDS server to your DHCP server (option 67)
• Right Click "Distribution Share" and click update
• Let it rebuild everything and it will create an ISO as part of this.
  Burn this ISO (x86 or x64) to a CD for later.

Image Creation

• Use the above (via PXE boot) to create a nice clean Windows 7 install.
• Once you have a base install, go ahead and install everything you want on their. Acrobat, Office, etc
• Install the AIK on this as well
• Once you are happy reboot the machine to the ISO which you burnt earlier.
• From the CD browse to the AIK install and run IMAGEX to create a WIM of your gold image machine. (imagex.exe /compress max /capture d: d:\image.wim "gold image")
• Once this is done reboot back to Windows 7 and copy the new gold image to your WDS server.
• On the WDS server import a new OS and make the source a WIM image, yes, the one you just created. Be sure to provide the location of your Windows 7 source file during this.

Drivers and disparate hardware

• Heaven only knows what hardware you are using. Thanking the stars above I've only had to do this on newish HP hardware, but for those not that lucky, you have the ability to provide WDS with any drivers you like.
• It's easy enough, just takes some testing to see what hardware works with Windows 7 and what requires additional drivers.

Deployment time

• Now the easy part; Install and run the Windows 7 Easy Transfer utility to copy all the local user profile data (depending on your situation you might have roaming profiles or not care about local settings).
• Dont save the profile locally. It wont be there after the rebuild. Setup a server location to save all this to. (And it can be a huge amount of data)
• Next PXE boot and install Windows 7 via RDS <- wow, wasn't that easy
• After the reboot check your drivers are good and the expected applications appear.
• Use the already installed Easy Transfer to restore the profile you backed up earlier.
• Reboot, and you're done. Congrats.

The "step by step with pictures" wheel, that I wont be reinventing, is located here:

http://blog.augustoalvarez.com.ar/2009/01/31/microsoft-deployment-toolkit-2010-beta-1-using-mdt-to-prepare-install-and-capture-customized-windows-7-images-part-i/

Teaming NICs within Hyper-V R2

Well a new Proliant Support Pack (8.30) is available so it's time to put it to the test.

I'm currently getting setup to install this within a production Hyper-V R2 (running Live Migration) environment. I'm hoping it's going to be as simple as installing the PSP on the Server 2008 R2 Core Hosts - this is the recommended install order for the PSP - however only time will tell.

I'm also curious how the team interacts with the Cluster Services and if any there are performance gains to be had by running the vendor NIC drivers.

Watch this space for the results ( 10 days away at date of this post)

Hyper-V Live Migration

Well Microsoft Hyper-V has been around for a little while now and has been playing the catchup game. However the release of Server 2008 R2 sees the introduction of features previously only available from other vendors.

One such feature is Live Migration, the ability to move a Virtual Machine from one Host to another without turning the guest off. Coupled with a case study deployment of Direct Access I got the opportunity to complete an implementation of Live Migration with great success.

Things I have learnt;

• There's a lot of useless information around for Hyper-V - I'll try not to add to it :)
• Hyper-V and Hyper-V R2 are quite different, dont expect them to behave the same.
• DO NOT team network cards - As of today (04/09/09) teaming is not supported, and when it is, it will be up to the vendor to provide and support any teaming of NICs.
  Update: This has changed. Check this post for details.
• You'll need more NICs - Hyper-V loves network cards. 2 teamed for production (when it actually works), 1 for heart beat, 1 for live migration traffic and 1+ for iSCSI, if you use it.
• You'll have to rethink your SAN - Cluster Shared Storage require a witness disk for the quorim data, and you can't store anything else on it. So plan to setup a new vDisk from your SAN at around 250 -> 500MB.
• You'll want more resources - One of the really appealing aspects to Live Migration is the ability to setup an N+1 High{ish} Availability Cluster, but that means the nearly 90% utalization you are currently running your poor, innocent hosts at, isn't going to do. Plan / Budget for it.

Server 2008 core

It is a huge pain. I do like working on core though, it feels (excuse the pun) hard-core, but it does make managing the hosts hard. Unless you are going to implement Virtual Machine Manager (which I do recommend btw) you aren't going to be able to do all the thing you want to within core. Troubleshooting is also made substantially harder.

The big appeal is of course the smaller footprint Core has - though dont expect some magic performance boost by just going to core.

That being said, I'd implement Hyper-V on 2008 Core whenever I can - it just seems appropriate.

As for your guests - You'll need to re setup their networking, moving to R2 will install new networking hardware with nice fresh DHCP settings [maybe an oversight from Microsoft but no biggie]. Just remember to record them before hard.

Micosoft Cluster Shared Storage

I've kept this seperate as it is required by Hyper-V Live Migration but IS NOT part of Hyper-V.

This means you should consider it seperately and carefully.

You'll need a static IP and hostname for your Cluster when you create it, you'll need to configure the Witness disk mentioned earlier and you'll need to seperate the heart beat, production and Live Migration network all setup in Cluster Manager.

TIP: Moving an already NTFS formatted disk to Cluster Shared Storage does not destroy the data. Be sure you have backups though.

Installation Order

Do things one at a time and test them carefully and you wont go wrong. - Measure twice, cut once and all that.

1. SAN - Create the Witness Disk, Virtual Machine storage, LUNs etc
2. Server 2008 R2 - Install the base OS, if at all possible stick with the Windows Drivers (I'd only use vendor drivers after careful testing) *See below for Core
3. Networking - Assign your IPs, Name your NICs, test connectivity between all hosts and SAN [iSCSI]
4. Storage - Connect to the SAN, check all the drives appear and make sure they have the same drive letters on all hosts.
5. Clustering - Install MPIO and Clustering. Create your cluster, give it its IP and hostname, check your hosts and networking appears corrently. Configure your witness disk.
6. Hyper-V - Install Hyper-V, configure all networking, dont create Guests!
7. Live Migration - Enable Cluster Shared Storage and add your disks (No, not the witness disk)
8. Add/create your Virtual Machine using Cluster Manager.
9. Check their configuration using Hyper-V manager.
10. Start your Guests using Hyper-V manager.
11. Migrate your Guests using Cluster Manager.

Well thats all for now, have fun with Virtualization. It's powerful technology but there's a lot of room to break things, so please be careful.

Footnote about Server 2008 Core:

There's a lot of good info online about the basic setup of core as well as a few mini GUI tools to download. Check out http://www.petri.co.il/configuring-windows-server-2008-networking-settings.htm

One thing I'd recommend is get remote management working and do as much as you can from your Windows 7 management machine.

Update: As for this past weekend (12/10/09) I've managed to get NIC teaming working with Hyper-V. Have a read.

Microsoft Direct Access

Microsoft Direct Access has just been released and there is always a lot of hype with new solutions. However this one has truly impressed me and I hope to see some serious market uptake.

I recently had the opportunity to assist with New Zealand’s first production implementation of this, in conjunction with Microsoft Prof Services and I'll try to detail the experience below.

The first thing you need to know is that Direct Access is awesome, but comes with some friends. Like the hot blonde you're excited to let into your party, until you see the not-that-hot friends she's bringing too.

In this case I'm referring to IPv6 and Public Key infrastructure (PKI). Both technologies have very nice personalities, but they are a lot of work and aren't good looking enough to sell to your boss. If you create a plan to get these technologies in place properly, in addition to the Direct Access planning, you'll do fine.

Public Key Infrastructure

If you dont already have one, put it in place. It's useful in many other places too.

The catches;

• Whatever server to decide to make your Certificate Authority will be with you for a long, long time. Virtualize if possible and choose a smart name.
• Lots of certificates will be handed out - things like DCs are going to jump on the PKI bandwagon straight away. That’s OK, it doesn't hurt. It will only hurt if you start trying to be clever and stop them.
• Server 2008 R2 - if you can, make it your CA. Newest templates and distribution points out of the box are nice.

For Direct Access use you will have to publish a CRL to the outside world. If you happen to have an ISA box, a web publishing rule is an easy option. But as long as you can get to the CRL how you do it is up to you. And no, you can’t reuse one of the DA boxes external IP addresses.

IPv6

It's coming and you can't ignore it anymore :) That being said there an army of technologies to make getting IPv6 going easier (and ironically, more complicated)

The one we are particularly interested in is ISATAP. Short version is it creates a IPv6 addresses based on [Address type][network prefix][IPv4 address].

In our case it would look something like 2002:0000:0000:0000:0000:5efe:192.168.1.1 or 2002::5efe:192.168.1.1

What you need to know is;

• Any server taking part in the Direct Access communications will need one of these ISATAP addresses.
• This is supported on Server 2003 and up.
• The address is generated by doing a DNS request to ISATAP.{domain}
• ISATAP.{domain} is blocked by default on your DNS server and will need to be allowed.
• You can bypass this lookup, by configuring the address this resolves to, directly on the ISATAP interface, on the server you are configuring. (NETSH INTERFACE ISATAP SET ROUTER {ipv4 address of DA box})
• You can disable and re-enable this interface to force it to do this DNS query again.

If you are doing IPv6 just for Direct Access the best results have been from leaving ISATAP blocked on your DNS servers and manually configuring the router address on the servers you want to take part in Direct Access. This leaves your other servers unaffected. Up to you though.

Direct Access

The irony of this name shouldn't escape anyone, this access is about as tunnelled as it gets. Packets get packaged in other packets, NATs traversed and the like.

Before you install you should read this. Lots of good info and instructions.

I'm not going to cover the install in details just the highlight and some tips I discovered. RTFM for the how to... and just 'cause you haven't downloaded it yet, click me.

• 2 sequential Public IPv4 addresses both assigned to the same interface.
• Un-firewall access to those IPs (OK if you have to, then check the guide for ports - but open it up for testing)
• If you're doing it as a Hyper-V Virtual Machine use Legacy Network Adapters.
• Use an IP Address, not a hostname for the Location Awareness URL (LAU)*
• Get yourself an external IP for a Windows 7 client that you can stick in your DMZ - great for testing.
• Enable your local admin account on your Windows 7 machines! - When things go wrong you will want to log in locally... and by 'things' I mean net being able to get ANY network comms.

The install of the Direct Access role itself and the configuration wizard are stupidly easy. The skill is in the planning, so be sure you do lots of it.

*Almost forgot. You'll want an IIS website hosted somewhere internal with a Certificate on it matching its IP address (and the PKI is useful again). You should be able to access this site securely and without any warning from the internal network, and not at all externally. The content of the site doesn’t matter, just that it exists. - This is how Windows 7 figures out if it's on the network or not. Location Awareness - pray it never gets it wrong.

Well, have fun and do me a personal favour. Do lots and lots of testing before giving this to your users. If we want this to be a hit in the industry the user experience has to be a good one. So let’s get it right and get people talking about it.

{Written while over Direct Access on Windows 7}

... Chess

For those that missed it the title of this Blog is a reference to the movie WarGames (1983).

This will be a blog about my exploits in the IT industry.

I am a Senior Systems Engineer working for Lexel Systems Ltd based in Auckland New Zealand.

Hopefully I can provide some insight and assistance to other working in the IT industry through this Blog. I work with all Microsoft, VMware, Citrix and Cisco technologies and get he opportunity to work with a lot of Beta and early adoptor releases.

Thanks for reading.