Cloud-Based VDI!!! No.

I was having a conversation this week with a colleague about his plans to create a hybrid-cloud environment by moving many of his datacenter workloads onto Windows Azure. After all, it makes plenty of sense – eliminating new capital expenses and reducing ongoing operational expenses just makes sense.

“And once we have tested it, we plan to roll out a thousand pooled VDI clients running on Windows Azure. It is great!”

No, I’m afraid it is not. Unfortunately, while there is no technological reason why you couldn’t do this, there is a legal reason.  There is no license for the Windows Client (not even Enterprise Edition) that you can deploy in someone else’s datacenter.  In order to legally deploy VDI you must own the physical hardware on which it is installed.

By the way, let me be clear, that is not only an Azure thing, and it is not only a Remote Desktop Services issue. The same licensing limitation is true on Citrix’s Xen Desktop and VMware’ Horizons.  It is true of Azure, Amazon Web Services, Rackspace, and Joe’s Datacenter Rental.  If you do not own the hardware you can install Windows Server… but not Windows 8.1 (or 8, or 7, or XP for that matter).

I had this conversation with the VP of Sales for a major Microsoft partner in Ontario recently, and I was so flabbergasted that I went back and looked it up. Sure enough he was right.  So when I spoke with my colleague the other day I was able to save him a lot of time, effort, money, and frustration.  Unfortunately I forgot to turn on the meter, so he got the advice for free.  Oh well, I’m sure he’ll remember around the holidays J

Consultants, I want you to remember this lesson: Your customers may not always like the news you have to tell them… but you do have to tell them.  Of course, this is one of those places where good communication skills will help you out – don’t just say ‘Wow, you are scroo-ooed!’ Tell them what they need to say and offer alternative solutions for them to accomplish what they are trying to do.

Advertisements

Building the IT Camp with PowerShell Revisited

I always said I am not hard to please… I only need perfection.  So when I wrote my PowerShell script to build my environment the other day I was pleased with myself… until I realized a huge flaw in it.  Generation 1.

Actually to be fair, there is nothing wrong with Generation 1 virtual machines in Hyper-V; they have served us all well for several years.  However how could I claim to live on the bleeding edge (Yes, I have made that claim many times) and yet stay safe with Generation 1?

In the coming weeks Windows Server 2012 R2 will become generally available.  One of the huge changes that we will see in it is Generation 2 virtual machine hardware.  Some of the changes in hardware levels include UEFI, Secure Boot, Boot from SCSI, and the elimination of legacy hardware (including IDE controllers and Legacy NICs).

Of course, since Generation 1 hardware is still fully supported, we need to identify when we create the VM which Generation it will be, and this cannot later be changed.

I had forgotten about this, and when I created the script (of which I was quite proud) I did not think of this.  It was only a few hours later, as I was simultaneously installing nine operating systems, that I noticed in the details pane of my Hyper-V Manager that all of my VMs were actually Gen1.

Crap.

Remember when I said a couple of paragraphs ago that the generation level cannot be changed?  I wasn’t kidding.  So rather than living with my mistake I went back to the drawing board.  I found the proper cmdlet switches, and modified my script accordingly.

As there is a lot of repetition in it, I am deleing six of the nine VMs from the list.  You are not missing out on anything, I assure you.

# Script to recreate the infrastructure for the course From Virtualization to the Private Cloud (R2).
# This script should be run on Windows Server 2012 R2.
# This script is intended to be run within the Boot2VHDX environment created by Mitch Garvis
# All VMs will be created as Generation 2 VMs (except the vCenter VM for which it is not supported).
# All VMs will be configured for Windows Server 2012 R2
# System Center 2012 R2 will be installed.

# Variables

$ADM = "Admin"                # VM running Windows 8.1 (for Administration)
$ADMMIN = 512MB                # Minimum RAM for Admin
$ADMMAX = 2GB                # Maximum RAM for Admin
$ADMVHD = 80GB                # Size of Hard Drive for Admin

$SQL = "SQL"                # VM (SQL Server)
$SQLMIN = 2048MB            # Minimum RAM assigned to SQL
$SQLMAX = 8192MB            # Maximum RAM assigned to SQL
$SQLCPU = 2                # Number of CPUs assigned to SQL
$SQLVHD = 200GB                # Size of Hard Drive for SQL

$VCS = "vCenter"             # VM (vSphere vCenter Cerver) (Windows Server 2008 R2)
$VCSMIN = 2048MB             # Minimum RAM assigned to vCenter
$VCSMAX = 4096MB             # Maximum RAM assigned to vCenter
$VCSCPU = 2                 # Number of CPUs assigned to vCenter
$VCSVHD = 200GB                # Size of Hard Drive for vCenter

$VMLOC = "C:\HyperV"            # Location of the VM and VHDX files

$NetworkSwitch1 = "CorpNet"        # Name of the Internal Network

$W81 = "E:\ISOs\Windows 8.1 E64.iso"            # Windows 8.1 Enterprise
$WSR2 = "E:\ISOs\Windows Server 2012 R2.iso"        # Windows Server 2012 R2
$W2K8 = "E:\ISOs\Windows Server 2008 R2 SP1.iso"     # Windows Server 2008 R2 SP1

# Create VM Folder and Network Switch
MD $VMLOC -ErrorAction SilentlyContinue
$TestSwitch1 = Get-VMSwitch -Name $NetworkSwitch1 -ErrorAction SilentlyContinue; if ($TestSwitch1.Count -EQ 0){New-VMSwitch -Name $NetworkSwitch1 -SwitchType Internal}

# Create & Configure Virtual Machines
New-VM -Name $ADM -Generation 2 -Path $VMLOC -MemoryStartupBytes $ADMMIN -NewVHDPath $VMLOC\$ADM.vhdx -NewVHDSizeBytes $ADMVHD -SwitchName $NetworkSwitch1
Set-VM -Name $ADM -DynamicMemory -MemoryMinimumBytes $ADMMIN -MemoryMaximumBytes $ADMMAX
Add-VMDvdDrive $ADM | Set-VMDvdDrive -VMName $ADM -Path $W81

New-VM -Name $SQL -Generation 2 -Path $VMLOC -MemoryStartupBytes $SQLMIN -NewVHDPath $VMLOC\$SQL.vhdx -NewVHDSizeBytes $SQLVHD -SwitchName $NetworkSwitch1
Set-VM -Name $SQL -DynamicMemory -MemoryMinimumBytes $SQLMIN -MemoryMaximumBytes $SQLMAX -ProcessorCount $SQLCPU
Add-VMDvdDrive $SQL | Set-VMDvdDrive -VMName $SQL -Path $WSR2

New-VM -Name $VCS -Path $VMLOC -MemoryStartupBytes $VCSMIN -NewVHDPath $VMLOC\$VCS.vhdx -NewVHDSizeBytes $VCSVHD -SwitchName $NetworkSwitch1
Set-VM -Name $VCS -DynamicMemory -MemoryMinimumBytes $VCSMIN -MemoryMaximumBytes $VCSMAX -ProcessorCount $VCSCPU
Set-VMDvdDrive -VMName $VCS -Path $W2K8

#Start Virtual Machines
Start-VM $ADM
Start-VM $SQL
Start-VM $VCS

In the script you can see a few differences between my original script (in the article) and this one.  Firstly on all machines that are running Windows 8.1 or Windows Server 2012 R2 I have set the switch –Generation 2.  That is simple enough.

Adding the virtual DVD was a little trickier; with Generation 1 hardware there was a ready IDE port for you to connect the .ISO file to.  In Gen 2 it is all about SCSI, so you have to use the Add-VMDvdDrive cmdlet, and then connect the .ISO file (Set-VMDvdDrive –VMName <Name> –Path <ISO Path>Not only for simplicity but also to demonstrate that you can I have put these two cmdlets on a single line, connected with a pipe (the | key).

I want to thank a couple of colleagues for helping me out with the Generation 2 hardware and DVD issues… especially Sergey Meshcheryakov , who was quick to answer.  The exact cmdlet switches were not easy to track down!

…and remember, if I can learn it, so can you!  Even the great Sean Kearney once did not know anything about PowerShell… and now look at him!

Building an IT Camp with PowerShell

I have been telling people for a couple of years that if they want to ensure a good future in the IT field there are two things to learn: System Center and PowerShell.  I unfortunately am quite good with one, but have been referring to myself as a scripting luddite for quite some time.  It is just something that I have not had the chance to learn.  After all, as a trainer and (Virtual) Evangelist I have not really had a lot of opportunity to get my hands on the type of environment where it would come in handy.

Recently I was in a conversation with a colleague who was complaining that he was too busy all of the time, and was really not enjoying his job because he hardly had time to breathe.  I asked him what sort of tasks he did on a regular basis, and when he told me my answer was simple: ‘If you have to do a task only once, do it manually.  If you might have to do it twice or more… automate it.’  In other words, learn PowerShell.

As I walked away from that meeting I realized that I was a hypocrite.  I built the labs for my course, From Virtualization to the Private Cloud, by hand, and every time I had to rebuild the environment I was doing it manually.  Considering the scope of what was involved I was not only being a hypocrite, I was being stupid.

Time is money, and time wasted is money lost.  I was scheduled to teach a four hour seminar on Hyper-V at the end of last week, and I decided that I was going to include some PowerShell management into that session.  I sat down and learned the basics, and that resulted not only in a better for the attendees last Friday, but also in an article titled Managing Hyper-V Virtual Machines with Windows PowerShell.  I started with some basics, how to start and stop VMs, how to check the VM memory, things like that.  I then expanded into creating a virtual machine, and adjusting the settings for it.  I was thrilled to be able to do all of this from the command line.

Okay, that was great, but now I needed to create a script that would really help me.  I knew there wouldn’t be anything on-line that would be exactly what I needed, but I was sure I would find the basics out there.  I found a great article by Neil Tucker on how he builds a couple of virtual machines for his course 50331 (Windows 7, Enterprise Desktop Support Technician).  Neil’s article gave me the basic framework for what I would come up with, including how to set variables for different VMs such as name, memory, and hard drive size.  It even went so far as to attach the proper ISO file to each VM and installs the OS using answer files.  As I already have my hard drives built I didn’t need that… but I was going to take things a little farther than Neil did.

I needed to build a script that would build nine virtual machines, each of which has its own special requirements.  I also needed to ensure that they would be connected to a virtual switch (which I would have to build as well if it wasn’t already there).

Although strictly speaking I do not need my script to create the VHDX files for me, I do want to make sure that each VM will connect to my pre-created virtual hard drive files, so I wrote the script to go through the motion of creating them in the correct place; I can then simply copy over them.

Up to now I have delivered the course on standard laptops (HP EliteBook 8570w with 32GB RAM).  However this likely would not be the case going forward, so it was important that I write the script so that I could easily provision new hardware with the course.

Goals:

  1. Create a virtual switch for the course (check to see that it does not already exist)
  2. Create a repository for all course virtual machines and virtual hard disk files to reside
  3. Create nine virtual machines, each with their own settings for dynamic memory, CPUs.
  4. Connect all virtual machines to the virtual network switch
  5. (For extra credit) attach the appropriate OS DVD to each virtual machine
  6. Start all of the virtual machines.

While I thought about allowing the person running the script to choose their VM names, I decided that this would make it confusing for attendees running the courseware labs, where I have set the VM names appropriately.

Here is what I came up with:

# Script to recreate the infrastructure for the course From Virtualization to the Private Cloud (R2).
# This script should be run on Windows Server 2012 R2.
# This script is intended to be run within the Boot2VHDX environment created by Mitch Garvis
# All VMs will be configured for Windows Server 2012 R2 unless otherwise stated

# Variables

$ADM = “Admin”                # VM running Windows 8.1 (for Administration)
$ADMMIN = 512MB                # Minimum RAM for Admin
$ADMMAX = 2GB                # Maximum RAM for Admin
$ADMVHD = 80GB                # Size of Hard Drive for Admin

$DC1 = “DC1”                # VM (Domain Controller) (Windows Server Core)
$DC1MIN = 512MB                # Maximum RAM assigned to DC1
$DC1MAX = 2048MB            # Maximum RAM assigned to DC1
$DC1VHD = 30GB                # Size of Hard Drive for DC1

$SQL = “SQL”                # VM (SQL Server)
$SQLMIN = 2048MB            # Minimum RAM assigned to SQL
$SQLMAX = 8192MB            # Maximum RAM assigned to SQL
$SQLCPU = 2                # Number of CPUs assigned to SQL
$SQLVHD = 200GB                # Size of Hard Drive for SQL

$STOR = “Storage”            # VM (Storage Spaces, iSCSI Target)
$STORMIN = 512MB             # Minimum RAM assigned to Storage
$STORMAX = 2048MB             # Maximum RAM assigned to Storage
$STORVHD = 30GB                # Size of first Hard Drive for Storage
$STORVHD2 = 100GB            # Size of second Hard Drive for Storage
$STORVHD3 = 100GB            # Size of third Hard Drive for Storage

$VMM = “VMM”                # VM (System Center Virtual Machine Manager)
$VMMMIN = 2048MB             # Minimum RAM assigned to VMM
$VMMMAX = 8192MB             # Maximum RAM assigned to VMM
$VMMCPU = 2                 # Number of CPUs assigned to VMM
$VMMVHD = 100GB                # Size of Hard Drive for VMM

$OM = “OpsMgr”                # VM (System Center Operations Manager)
$OMMIN = 2048MB             # Minimum RAM assigned to OpsMgr
$OMMAX = 8192MB             # Maximum RAM assigned to OpsMgr
$OMCPU = 2                 # Number of CPUs assigned to OpsMgr
$OMVHD = 100GB                # Size of Hard Drive for OpsMgr

$ORC = “Orchestrator”             # VM (System Center Orchestrator)
$ORCMIN = 2048MB            # Minimum RAM assigned to Orchestrator
$ORCMAX = 8192MB             # Maximum RAM assigned to Orchestrator
$ORCCPU = 2                 # Number of CPUs assigned to Orchestrator
$ORCVHD = 100GB                # Size of Hard Drive for Orchestrator

$SM = “SrvMgr”                 # VM (System Center Service Manager)
$SMMIN = 2048MB             # Minimum RAM assigned to Service Manager
$SMMAX = 8192MB             # Maximum RAM assigned to Service Manager
$SMCPU = 2                 # Number of CPUs assigned to Service Manager
$SMVHD = 100GB                # Size of Hard Drive for Service Manager

$VCS = “vCenter”             # VM (vSphere vCenter Cerver) (Windows Server 2008 R2)
$VCSMIN = 2048MB             # Minimum RAM assigned to vCenter
$VCSMAX = 4096MB             # Maximum RAM assigned to vCenter
$VCSCPU = 2                 # Number of CPUs assigned to vCenter
$VCSVHD = 200GB                # Size of Hard Drive for vCenter

$VMLOC = “C:\HyperV”            # Location of the VM and VHDX files

$NetworkSwitch1 = “CorpNet”        # Name of the Internal Network

$W81 = “E:\ISOs\Windows 8.1 E64.iso”            # Windows 8.1 Enterprise
$WSR2 = “E:\ISOs\Windows Server 2012 R2.iso”        # Windows Server 2012 R2
$W2K8 = “E:\ISOs\Windows Server 2008 R2 SP1.iso”    # Windows Server 2008 R2 SP1

# Create VM Folder and Network Switch
MD $VMLOC -ErrorAction SilentlyContinue
$TestSwitch1 = Get-VMSwitch -Name $NetworkSwitch1 -ErrorAction SilentlyContinue; if ($TestSwitch1.Count -EQ 0){New-VMSwitch -Name $NetworkSwitch1 -SwitchType Internal}

# Create Virtual Machines
New-VM -Name $ADM -Path $VMLOC -MemoryStartupBytes $ADMMIN -NewVHDPath $VMLOC\$ADM.vhdx -NewVHDSizeBytes $ADMVHD -SwitchName $NetworkSwitch1
Set-VM -Name $ADM -DynamicMemory -MemoryMinimumBytes $ADMMIN -MemoryMaximumBytes $ADMMAX

New-VM -Name $DC1 -Path $VMLOC -MemoryStartupBytes $DC1MIN -NewVHDPath $VMLOC\$DC1.vhdx -NewVHDSizeBytes $DC1VHD -SwitchName $NetworkSwitch1
Set-VM -Name $DC1 -DynamicMemory -MemoryMinimumBytes $DC1MIN -MemoryMaximumBytes $DC1MAX

New-VM -Name $SQL -Path $VMLOC -MemoryStartupBytes $SQLMIN -NewVHDPath $VMLOC\$SQL.vhdx -NewVHDSizeBytes $SQLVHD -SwitchName $NetworkSwitch1
Set-VM -Name $SQL -DynamicMemory -MemoryMinimumBytes $SQLMIN -MemoryMaximumBytes $SQLMAX -ProcessorCount $SQLCPU

New-VM -Name $STOR -Path $VMLOC -MemoryStartupBytes $STORMIN -NewVHDPath $VMLOC\$STOR.vhdx -NewVHDSizeBytes $STORVHD -SwitchName $NetworkSwitch1
Set-VM -Name $STOR -DynamicMemory -MemoryMinimumBytes $STORMIN -MemoryMaximumBytes $STORMAX

New-VM -Name $VMM -Path $VMLOC -MemoryStartupBytes $VMMMIN -NewVHDPath $VMLOC\$VMM.vhdx -NewVHDSizeBytes $VMMVHD -SwitchName $NetworkSwitch1
Set-VM -Name $VMM -DynamicMemory -MemoryMinimumBytes $VMMMIN -MemoryMaximumBytes $VMMMAX -ProcessorCount $VMMCPU

New-VM -Name $ORC -Path $VMLOC -MemoryStartupBytes $ORCMIN -NewVHDPath $VMLOC\$ORC.vhdx -NewVHDSizeBytes $ORCVHD -SwitchName $NetworkSwitch1
Set-VM -Name $ORC -DynamicMemory -MemoryMinimumBytes $ORCMIN -MemoryMaximumBytes $ORCMAX -ProcessorCount $ORCCPU

New-VM -Name $OM -Path $VMLOC -MemoryStartupBytes $OMMIN -NewVHDPath $VMLOC\$OM.vhdx -NewVHDSizeBytes $OMVHD -SwitchName $NetworkSwitch1
Set-VM -Name $OM -DynamicMemory -MemoryMinimumBytes $OMMIN -MemoryMaximumBytes $OMMAX -ProcessorCount $OMCPU

New-VM -Name $SM -Path $VMLOC -MemoryStartupBytes $SMMIN -NewVHDPath $VMLOC\$SM.vhdx -NewVHDSizeBytes $SMVHD -SwitchName $NetworkSwitch1
Set-VM -Name $SM -DynamicMemory -MemoryMinimumBytes $SMMIN -MemoryMaximumBytes $SMMAX -ProcessorCount $SMCPU

New-VM -Name $VCS -Path $VMLOC -MemoryStartupBytes $VCSMIN -NewVHDPath $VMLOC\$VCS.vhdx -NewVHDSizeBytes $VCSVHD -SwitchName $NetworkSwitch1
Set-VM -Name $VCS -DynamicMemory -MemoryMinimumBytes $VCSMIN -MemoryMaximumBytes $VCSMAX -ProcessorCount $VCSCPU

# Configure Virtual Machines
Set-VMDvdDrive -VMName $ADM -Path $W81
Set-VMDvdDrive -VMName $DC1 -Path $WSR2
Set-VMDvdDrive -VMName $SQL -Path $WSR2
Set-VMDvdDrive -VMName $STOR -Path $WSR2
Set-VMDvdDrive -VMName $VMM -Path $WSR2
Set-VMDvdDrive -VMName $OM -Path $WSR2
Set-VMDvdDrive -VMName $ORC -Path $WSR2
Set-VMDvdDrive -VMName $SM -Path $WSR2
Set-VMDvdDrive -VMName $VCS -Path $W2K8

Start-VM $ADM
Start-VM $DC1
Start-VM $SQL
Start-VM $STOR
Start-VM $VMM
Start-VM $OM
Start-VM $ORC
Start-VM $SM
Start-VM $VCS

Please remember that until a little under a week ago I had not written a single script longer than a couple of lines.  While I am sure there are efficiencies that can be improved upon, I don’t think it’s too bad for a first go at it.

So now that I am scripting, what do you think you could come up with?  The way I see it, if I could do it… anyone can!

If He Can Do It YOU Can Too!

I have been saying for the past couple of years that Microsoft’s Hyper-V is much simpler than vSphere, but I never imagined that I would see this:  Caleb, a 5th grader, shows us how to create a virtual machine, install an OS, and even create a virtual switch.  Not only was I impressed with how well he does it, but his communication skills far exceed those of many adult IT Pros that I have met!  (Not you of course… I mean the other guys…)

http://blogs.technet.com/b/yungchou/archive/2013/03/18/are-you-smarter-than-a-5th-grader-in-creating-hyper-v-virtual-machine-and-installing-windows-server-2012.aspx?wa=wsignin1.0

So the question is if he can do it, why can’t you?  Of course you can, it is that simple!

It’s Official: My SIXTH MVP Award Category

Two weeks ago 1,400 Microsoft MVPs gathered in Redmond, Washington (the MotherShip, as some call it!) to ‘geek out’ for three days (or as many as six for some, depending on pre-day and post-day events).  We spent at least two and as many as four days in closed-door sessions with the product teams for which we were awarded… in my case it was with the Windows Client product team, which includes Windows 8, Microsoft Desktop Optimization Pack (MDOP), Microsoft Deployment Toolkit (MDT) and other deployment technologies, and of course the folks behind the Microsoft Surface.

While we all enjoyed ourselves immensely, I realized early on that although I do spend a lot of time discussing and presenting Windows 8, it is simply not the area where I spend most of my energies and focus.  As such, after meeting with both Stephen Rose (a Senior Product Marketing Manager for Windows) and Ben Armstrong, and then making the formal request through proper channels, I am proud to say that I have officially switched MVP competencies to Virtual Machine.

For those of you keeping score, here is the official list:MVP_Horizontal_FullColor

  1. Windows Server – Customer Experience
  2. Small Business Server
  3. Essential Business Server
  4. Windows Desktop Experience
  5. Windows Expert – IT Pro
  6. Virtual Machine

I want you all to know that this is not because I cannot make up my mind… simply over the years interests and areas of focus change.  A couple of years ago I was spending a lot of time talking about desktop deployment, which put me square into the Windows DE (and then Windows Expert – IT Pro) camp.  My primary focus of late has been virtualization, and it looks like that is where I am going to stay for at least a couple of years.  I am sure you all know that this is not simply a whim – I am as passionate about virtualization as is possible.

For any of you who might be interested in seeing my MVP Profile Page, it can be viewed at: http://mvp.microsoft.com/profiles/Mitch.

I want to thank all of my friends in the Windows space – Stephen Rose, David Trupkin, Michael Niehaus, and everyone else (too many to mention!) for everything they have done for me over the past few years.  I promise that I am not abandoning you – simply adjusting to the realities.  I will continue to participate in the STEP (Springboard Technical Experts Panel) as long as I am allowed, and will speak at every user group that invites me!

I am looking forward to my new program – new lists, mail servers, and so on… time to reintroduce myself to another group of poor, unsuspecting souls who have no idea what they have coming to them fine MVPs with whom I have so much in common!

Shared Nothing Live Migration: Goodbye Shared Storage?

This article was originally written for the Canadian IT Pro Connection.

Many smaller companies and individuals with home labs see shared storage – usually a SAN (Storage Area Network) device as the impediment to Live Migration.  In April of 2011 Microsoft released the iSCSI Software Target 3.3 as a free (and supported) download.  At the time Pierre and I wrote a series of articles in this space as guest bloggers (The Microsoft iSCSI Software Target is now free, All for SAN and SAN for All!, Creating a SAN using Microsoft iSCSI Software Target 3.3, Creating HA VMs for Hyper-V with Failover Clustering using FREE Microsoft iSCSI Target 3.3).  It seems that those articles were so well liked that Pierre and I are now the resident technical bloggers for this space! Smile

Ok, but seriously… Software SANs make life easier for smaller companies with smaller environments.  The fact that you can now build a failover environment without investing in an expensive SAN is a great advancement for IT Professionals, and especially for those who want to do Live Migration.  Windows Server 2012 now includes the iSCSI Software Target out of the box, and IT Pros are taking full advantage.

Now let’s go one step further.  You have started to play with Hyper-V… or maybe you have a small environment built on a single host.  You get to the point where you are going to add a second host, but you are still not ready to create shared storage.  Are you stuck with two segregated hosts? Not anymore!

Shared Nothing Live Migration allows you to have VMs stored on local (direct attached) storage, and still be able to migrate them between hosts.  With absolutely no infrastructure other than two Hyper-V hosts (and the appropriate networking) you can now live migrate virtual machines between hosts.

Requirements

Any live migration, whether it be Hyper-V or any other platform, have a number of requirements in order to work.

  • Both hosts must have chipsets in the same family – that is, you cannot live migrate an Intel to an AMD or vice-versa.  If the processors are similar enough (i7 to i5 is fine, i7 to Core2 Duo is not) then no action is necessary.  In the event that you do have dissimilar processors (newer and older but still within the same family, then you have to configure your virtual machine’s CPU compatibility, as outlined in the article Getting Started with Hyper-V in Server 2012 and Windows 8.
  • If your virtual machine is connected to a virtual switch then you need to have an identically named virtual switch on the destination host.  If not your migration will be paused while you specify which switch to use on the destination server.
  • The two virtualization hosts must be connected by a reliable network.

Settings (Host)

In order to perform Live Migration you have to configure it in the Hyper-V Settings.

1) In Hyper-V Manager click Hyper-V Settings… in the Actions Pane.

image

2) In the Hyper-V Settings for the host, click on the Live Migrations tab on the left.  In the details pane ensure that the Enable incoming and outgoing live migrations box is checked, and that you have selected an option under Incoming live migrations.  In this screenshot you will see that I have left the default 2 Simultaneous live migrations, and that I selected the option to Use any available network for live migration.  Depending on your network configuration and bandwidth availability you can adjust these as you like.

image

NOTE: These steps must be performed on both hosts, although the configuration options do not have to be the same.

Migrating a VM

Performing a Live Migration is easy.

1) In the Hyper-V Manager right-click on the virtual machine that you want to migrate and click Move…

NOTE: In this screenshot I am managing both hosts from the same MMC console.  This is NOT a requirement.

image

2) On the Before You Begin screen click Next>.

3) On the Choose Move Type screen select Move the virtual machine and click Next>.

4) On the Specify Destination Computer screen enter the name of the destination host and click Next>.  You also have the option to browse other hosts in Active Directory.

image

5) On the Choose Move Options screen select what you want to do with the virtual machine’s items (see screen capture).  I usually select the option Move the virtual machine’s data to a single location.  This option allows you to specify one location for all of the VM’s items, including configuration files, memory state, and virtual storage.  Click Next>.

image

6) On the Choose a new location for virtual machine screen enter (or browse to) the location on the destination host where you would like to move the VM.  This screen will also tell you how big your files are (note the Source Location in the screen capture says 9.5 GB).  Click Next> then on the Summary screen click Finish.

image

Now that your virtual machine migration is in progress you can watch the progress bar in two places: In the Performing the Move progress bar, and in the Hyper-V Manager under Status.

image

The one place where you would not be able to watch the progress is from within the virtual machine.  There is nothing to see.  If you are in the VM while the migration is happening there is no indication of it, and you (and all of your processes and networking) will be able to continue as normal.  The operating system within the VM itself has no concept that it is virtualized, and therefore has no concept that it is being moved.  Should the live migration fail (as has been known to happen) the VM would experience… nothing.  It would continue to work on the source host as if nothing had happened.  In fact the only time it ceases to work on the source host is when it is fully operational on the destination host.

image

Notice now that the virtual machine SWMI-DC2, which we moved from SWMI-HOST5 to SWMI-HOST6 is now running as normal on the destination host.  You will see that the Uptime is reset – that is because the uptime is tied to the VM on the host, and not the uptime of the guest OS.

VIDEO!

Now that you understand how it works, why not watch the video of my performing a Shared Nothing Live Migration.  For the sake of good TV I cut out the three minutes of waiting while the migration performed, but everything else is in real time.  Check it out here:

Shared Nothing Live Migration–real time, minus a few minutes cut out of the Watching it happen phase.

Conclusion

Whether you have a small infrastructure and want to be able to live migrate between a couple of hosts, or you have a large infrastructure but still have VMs stored on direct-attached storage, Shared Nothing Live Migration is one of the new features in Windows Server 2012 that will make your virtualization tasks easier.  Remember that it is not a license to get rid of your SAN devices, but is a great (and easy) way to migrate DAS-attached VMs between hosts without any downtime.

A Quick Tip for Hyper-V Users: Product Keys

I keep telling people that the best way to activate your servers and desktops is to have a Key Management Server (KMS) in your environment.  However not everyone has volume license keys, and when an IT Pro (or Dev) builds a lot of lab environments using their TechNet, MSDN, or MAPS licenses that is not an option.

If you hate typing and retyping product keys, here’s a trick that will make your life a little easier:

1) Navigate to the Subscriber Downloads page on your TechNet Plus, MSDN, or other site and find the operating system that you are looking for, then click Product Keys next to the desired product.

image

2) Once you have the key available (you may have to click Get a Key first) click on the clipboard icon next to that key. (you may have to allow Internet Explorer to access your clipboard).

3) Now bring up the Hyper-V Virtual Machine Connection for your virtual machine and begin installing the OS.  When you get to the screen where you would have to type in the product key, select the Clipboard option in the menu and click Type clipboard text.

image

You should see the product key being typed into the appropriate location.

image

I use this technique whenever I have lab environments to build, but it would work just as well for copying any text  from your desktop (or server) into your Hyper-V virtual machine.  It is simple and effective… just like Hyper-V!

Getting Started With Hyper-V in Server 2012 and Windows 8

You all know by now that I am a huge Hyper-V fan… I have been using it since 2008, but with the latest release I am unabashedly loving Microsoft’s Layer 1 hypervisor.  The fact that it has been included in Windows 8  – as in, no different from the virtualization platform I use in my servers – is just the icing on the cake.

It is true that almost any IT Pro would be able to install and use Hyper-V on either the server or client platform without much guidance.  However when you do start out – either with Hyper-V in general, or on a new system – there are a few things that you should know before you go.  Here are some of my tips, in no particular order of importance.

1) Change the default file locations!

The default file locations for virtual hard disks and virtual machines are a bit obscure.  I like to change them right out of the gate.  Depending on which drive I want to store them on (in Windows 8 it is usually the C drive, while on proper servers it will usually not be) I will store them both right off the root… x:\VHDs and x:\VMs.  That way I do not have to navigate to the defaults whenever I want to copy a file.  I find x:\VHDs much easier than c:\Users\Public\Documents\Hyper-V\Virtual Hard Disks and c:\ProgramData\Microsoft\Windows\Hyper-V.

If I am going to use Failover Clustering with Cluster Shared Volumes the defaults will be different, but for standalone servers these defaults suit me fine.

STEPS:

  1. In Hyper-V Manager click on Hyper-V Settings… in the Actions Pane.
  2. Under the Server context, click on Virtual Hard Disks and change the default location.  You will have to create the directory before going ahead.
  3. Still under the Server context, click on Virtual Machines and change the default location.  Again, you will have to create the directory first.

It’s as easy as that.  Of course, VMs that are already there will not be moved, but going forward all VMs will be placed in the proper directory.

2) Create your Virtual Switch!

When you start creating virtual machines there will be nowhere for them to go and nobody for them to talk to… that is, unless you create a virtual switch (previously called virtual network) to connect them to.  Depending on your server and your environment this might be simple or complex, and may require more planning.  However the long and the short of it is you have to make three decisions when creating a virtual switch:

  • Is the network going to be External (can communicate beyond the physical host), Internal (can only communicate with other VMs on the same host, plus with the host), or Private (can only communicate with other VMs on the same host)?
  • If External, what physical NIC (uplink) will it be bound to?
  • Can the Management OS (on the host) use the same NIC?

STEPS:

  1. In the Action Pane of Hyper-V Manager click Virtual Switch Manager…
  2. In the navigation pane click New virtual switch
  3. In the right screen select External, Internal, or Private and click Create Virtual Switch
  4. In the Virtual Switch Properties window delete New Virtual Switch and name the switch something that you will understand (i.e.: CorpNet).
  5. Click OK to close the Virtual Switch Manager.

Again, this is all there is to it.  Plain and easy, no fuss, no muss.

3) Configure Dynamic Memory

When you create a virtual machine there are a few defaults that Hyper-V thinks is a good idea… which I don’t.  The main one that comes to mind is the Dynamic Memory option (per VM).  When you configure Dynamic Memory the defaults are going to be:

Startup RAM: 512 MB

Minimum RAM: 512 MB

Maximum RAM: 1048576 MB

Ok, for a lot of our virtual machines 512MB may be a fine minimum… but unless you are driving a BAWL (Big @$$ Work Load) server on the VM you will nearly never need a terabyte of RAM.  Granted it is nice that we have that ability, it is not going to be the norm.  On the other hand, not setting a realistic maximum would mean that if your VM were to place a huge memory demand – say, because of an unchecked memory leak or a compromised server, or even something as simple as an Exchange Server grabbing as much physical (ahem… virtual) RAM as it can – then this would necessarily be at the expense of contention resources, which would no longer be available to other virtual machines on the same host.

My recommended best practice is to pick minimums and maximums that are reasonable to you for each server (and those will be different from VM to VM, depending on the load expectations).  You will be able to tweak these up or down as needed, but the point is you will have reasonable limits.  For many of my servers I set limits such as these:

Startup RAM: 512 MB

Minimum RAM: 512 MB

Maximum RAM: 4096 MB

These settings allow the VM to consume up to 4 GB of RAM when needed and available, but no more than that.  If I discover the VM workload needs more then I will tweak it up incrementally.  I am not letting resources go to waste, and I am making sure that my VMs work within their means – i.e.: as efficiently as they can.

STEPS:

  1. imageWithin Hyper-V Manager click on the VM in question and then in the Action Pane (VM Name) click Settings…
  2. In the Navigation Pane click Memory
  3. In the Memory window change the Minimum and Maximum RAM as needed.
  4. Click OK.

4) …and Hard Disks!

By default the virtual hard disks that are created for us in the New Virtual Machine Wizard will be 127 GB.  But do they really need to be that big?  Actually, in a lot of cases they do.  In many cases they should be bigger.  Sometimes they should be smaller.  If you are creating your disks this way then you should right-size them in the wizard.

With that being said, the one question that the wizard does not ask you is ‘what type of disk would you like to create?’  In Server 2012 there are actually three questions that you should be asked that are only asked when creating your disks using the New Virtual Hard Disk Wizard:

a) Would you like to create a VHD file (with backward-compatibility, and limited to 2 TB in size) or a VHDX file (which adds resilience to consistency issues that might occur from power failures, and are limited to 64 TB in size but offer no backward compatibility)

b) Would you like the disk to be Fixed size (pre-provisioned storage), Dynamically expanding (storage on demand), or Differencing disk (associated with a parent-child relationship with another disk)?

c) Would you like to create the new VHD(X) file based on the contents of an attached physical drive?

The solution is to pre-create your VHD(X) files to spec, and then point to them from the New Virtual Machine Wizard.  While dynamically expanding disks are fine for labs and offer greater portability, I never recommend them in a production environment.  Also if you think you might need to port your VMs back to Server 2008 (or Windows 7) then VHD will be required.

STEPS:

    1. From the Hyper-V Manager console in the Actions Pane click New > Hard Disk…
    2. Go through the wizard and select the options you choose.
    3. From the New Virtual Machine Wizard click the radio button Use an existing virtual hard disk and point to the right file.
    4. Click Finish.

image

Alternately, you could select the radio Attach a virtual hard disk later and create your VMs, then create your VHD(X) files, and then attach them.  It seems like more work to me though…

5) …and CPUs!

There are a few new settings in the Processor tab of Hyper-V VMs than there used to be.  Not only can you set the number of virtual processors (to the lesser of either a maximum of 64, or the number of physical cores in your computer), but you can also set the VM reserve, the percent of total system resources, the VM limit, and the relative weight.  These are all set in the main screen of the Processor Settings page.

imageWhat a lot of people do not realize is that there are two subsections to the Processor tab: Compatibility and NUMA.  In order to access these you need to expand the + next to Processor in the navigation pane.

NUMA stands for Non-Uniform Memory Architecture, and essentially means that a single VM can use memory that is assigned to different physical CPUs.

Compatibility in this context refers to CPU families, and is a very handy option indeed.  In virtualization there is no way to live-migrate a VM from a host running on AMD CPUs to a host running on Intel CPUs.  This is not a limitation of Hyper-V, rather of the architecture of CPUs, and is identical in VMware.  However CPU family is not the only limiting factor to allow live migrations; CPU properties are a factor too, and because of advancements in the technology it would generally not be possible to live migrate a VM from a host with an older CPU to a host with a newer CPU.

A few years ago VMware saw this as an issue, and along with Intel developed a technology called EVC, or Enhanced vMotion Compatibility.  What EVC does is it masks the newer chipset features (generally multimedia signatures and things like that) from the VM, so that all of a sudden you can migrate between older and newer hosts (say, an Intel i7 to an Intel Core Duo).  In VMware this is assigned at the Cluster level.

Of course the technology is simple enough, but the intellectual property is not.  EVC has the word vMotion (a trademark) in the title.  Microsoft cannot use the term vMotion.  As such their compatibility mechanism (which works the same way) is called Migrate to a physical computer with a different processor version (MTPCWDPV).  The name is not nearly as sexy as EVC, but they compensated by assigning it to the VM instead of the cluster.  It is a simple checkbox that you check (or uncheck) under the Compatibility Configuration screen.

If you are going to be using Live Migration between hosts with potentially incompatible CPU then follow these steps:

STEPS:

      1. imageWithin Hyper-V Manager click on the VM in question and then in the Action Pane (VM Name) click Settings…
      2. In the Navigation Pane click Processor, then click the + next to Processor to expand the tree.
      3. Click on Compatibility
      4. Click the checkbox Migrate to a physical computer with a different processor version.
      5. Click OK.

Following these simple best practices will not make you an expert in Hyper-V by any means, but it is a good start… what they will allow you to do is get started comfortably and play with the technology without hitting some of the more common stumbling blocks that beginners seem to run into.  As your needs grow you will be comfortable enough with the technology to try new things, explore new possibilities.  Before long you will be as virtualization expert, ready to tackle concepts such as Shared Nothing Live Migration, Failover Clustering, Cluster Shared Volumes, and much much more.

In the meantime dip your toes into the virtualization waters… it’s warm and inviting, the hazards are not too dangerous, and the rewards are incredible.  In no time you will be ready to get certified… but even if that is not your goal you have already taken the first steps to becoming a virtual wiz!

Linux Integration Services for Hyper-V 3.4

Linux PenguinThis post was originally written for the Canadian IT Pro Connection blog, and can be seen there at http://blogs.technet.com/b/canitpro/archive/2012/09/11/linux-integration-services-for-hyper-v-3-4.aspx.

Microsoft has been taking tremendous steps to prove that Hyper-V is not simply the best hypervisor for Windows users and administrators, it is also a viable option if you have Linux servers as well.  Last week Microsoft released the Linux Integration Services v3.4 for Hyper-V.  Integration Services are the tools that you need to get the full functionality of your hardware within a guest OS, including the drivers that enable synthetic device support in (supported) Linux virtual machines under Hyper-V.

Here is the overview of what is included:

When installed in a supported Linux virtual machine running on Hyper-V, the Linux Integration Components provide. Driver support: Linux Integration Services supports the network controller and the IDE and SCSI storage controllers that were developed specifically for Hyper-V. Fastpath Boot Support for Hyper-V: Boot devices now take advantage of the block Virtualization Service Client (VSC) to provide enhanced performance. Time Sync: The clock inside the virtual machine will remain synchronized with the clock on the virtualization server with the help of the pluggable time source device. Integrated Shutdown: Virtual machines running Linux can be shut down from either Hyper-V Manager or System Center Virtual Machine Manager by using the “Shut down” command. Symmetric Multi-Processing (SMP) Support: Supported Linux distributions can use multiple virtual processors per virtual machine. The actual number of virtual processors that can be allocated to a virtual machine is only limited by the underlying hypervisor. Heartbeat: This feature allows the virtualization server to detect whether the virtual machine is running and responsive. KVP (Key Value Pair) Exchange: Information about the running Linux virtual machine can be obtained by using the Key Value Pair exchange functionality on the Windows Server 2008 virtualization server. Integrated Mouse Support: Linux Integration Services provides full mouse support for Linux guest virtual machines.

The requirements are simple: If you have Hyper-V (including Windows Server 2008 RTM and Windows 8) on the host, and a supported build of Linux in the guest OS, the LIS will work.

Supported builds:

I am not an expert in Linux, but I do know that previous LIS sets supported several builds, including:

This most recent build only includes support for several builds of Red Hat Enterprise Linux (5.7, 5.8, 6.0, 6.3).  This is not because Microsoft does not care about Linux, nor because it feels that other builds are less important.  Simply stated, all versions of Linux based on Linux Kernel 2.6.32 and later include the drivers for Linux in Hyper-V out of the box.  There are articles on-line which explain how to enable these modules (see article from Port 25).

Microsoft wants you to use Windows Server; they are also realistic to know that not everyone does, and there are a huge number of heterogeneous environments out there.  Just because you use Linux in addition to Windows Server does not mean that you should discount Hyper-V (and all of its great benefits) as your hypervisor of choice.

By the way, the best resource that I have found for Open Source support with Microsoft technologies is the Port 25 Blog right here on TechNet… Check them out here.

Virtual Hard Disks: Best Practices for dynamic / thin provisioned disks and other stories…

 sort of an armillary sphere (or at least a disk)

Virtual environments offer us many new options with regard to storage.  Whether you are using Hyper-V or VMware, a few of the options (and recommendations) are the same, even when the terms are different.

One of the options I am often asked about is dynamically expanding hard drives.  MY first reaction is that I am against them… and I have very good reasons for that, except that there are caveats to make them acceptable for a production environment.

Hyper-V has dynamically expanding disks, vSphere has thin provisioned disks.  They both do the same thing – rather than creating a file equivalent in size to the disk you are creating (say, 20GB on disk for a 20GB VHD) it will create a tiny little file that grows as data is written to it, up to the limitations set forth in the configuration.

Dynamically expanding disks make our VMs much more easily transported… it is quicker and easier to move a 6GB file than it is a 20GB file.  However in our server environments transportability is seldom a factor.  Performance and stability are.

The performance issue is not really a factor anymore… although the dynamic expansion of a file must on some level take resources, both Microsoft and VMware have made their virtual disks so efficient at the difference is negligible.  As for stability, I rarely see virtual disks corrupting because of expansion… unless they expand onto corrupt sectors on the physical drive, and even then the drives and operating systems are so good these days that seldom happens.

There are two main reasons I provision my virtual disks as thick/static disks:

  1. Storage is cheap… at least, it is cheaper than downtime.  If you need 5TB of storage for your virtual environment, you should buy it.  That way you know what you have, and don’t have to worry about a situation where your virtual disk file grows and fills the volume on which it is stored, which would prevent it (and any other dynamically expanding disks on the same volume) from growing, resulting in the virtual machines that are dependent on them to crash.
  2. Files fragment as they grow.  Fragmentation is bad.  Need I say more?

Now both of these issues do have mitigations that would, when necessary, allow you to implement dynamic/thin disks without risking these problems.  In fact, one of these mitigations will actually solve both issues:

  1. Under-provision your storage.  While this sounds a lot like the ‘Hey Doc, it hurts when I do this…’ So don’t do that! discussion, it is true.  if you have two virtual disks that can expand to 35GB residing on a 72GB volume, there is no threat of them filling the space.  This does not address the fragmentation issue though.
  2. Put each virtual disk file onto its own volume.  This mitigates both issues.  Unfortunately it also means that you are limiting the number of virtual disks you have to the number of hard drives (or LUNs) that you have.  Fortunately there is a mitigation for that too: partition! Bad for Quebec, but good for maximizing the number of virtual disks you can store segregated on a single drive.

When speed is a factor…

The partition plan does not address one more issue – the performance issue.  Mitch’s Rule #11 is very clear: more spindles = more speed = more better.  I have said this in class and on stage a thousand times, and I firmly believe that.  Every virtual disk that you spin up on a hard drive must share that rpms (and therefore the speed) with all of the other virtual disks on that drive.  Partitioning the drive does not change the fact that the multiple partitions still exist on the same spindles.

There are two answers to this: more spindles, or fewer virtual disks.  In larger organizations storage costs are easily justified and therefore accepted.  Smaller organizations very often have to make do with what they have, or often buy the cheapest solution (external USB drives, etc…).  This is never a good idea, but if you are going to use external drives make sure you invest in the fastest bus available – in other words, USB 2.0 is not a good option, and USB 3.0 or eSATA are better bets. 

What other options do I have?

Of course, we have not discussed two great solutions, but they are going to be a little costlier:

  • Storage Area Networks (SANs).  SANs are great because they allow us to take several disks in a unit and partition the total rather than the individual drives, and then we can share them across multiple hosts.  Absolutely every organization considering virtualization, no matter how small, should invest in a SAN device. 

I say invest because they are not cheap… a decent entry-level SAN should cost around Five Thousand Dollars ($5,000.00).

  • Raw Device Map (RDM) / Pass-through disks (PTD). This is a great functionality that ensures that a virtual machine gets the best performance available from the drive by giving it exclusive access to it.  It eliminates the worry of performance degradation due to resource sharing.

The downside to this is that you cannot partition the drive, and while you can create an RDM/PTD to a SAN LUN (Logical Unit Number) that does not change the fact that are limiting the number of drives you can have.  This functionality can also limit the portability of your virtual machines – neither Microsoft nor VMware prevents you from live migrating a VM with a RDM/PTD, but there is an added layer of complication.

Conclusion

While planning for resources is important in a physical environment, it is infinitely moreso in a virtual environment where resources have to be shared and virtual machines have to co-exist on the same hardware resources.  The ability to plan your storage strategy begins with a good understanding of the technologies, as well as an understanding of best practices and recommendations from others who have been there before.  I still wouldn’t use dynamically expanding disks in my servers, but with more and more people asking me about it I wanted to make my reasons clear, as well as outline the steps I would take if I were in a position where I had no choice.

Now it’s up to you!