I often use the feature of Hyper-V that allows you to “type clipboard text” into a virtual machine.  Unfortunately, in the Windows 8 / Windows Server 2012 beta release there is a known issue where doing this can result in missing or garbled characters being typed into the virtual machine.

Luckily – Ned Pyle has posted the details of how to work around this here.

My preferred option is to increase the keyboard buffer (the second option that he outlines).

Cheers,
Ben

In Windows 8 / Windows Server 2012 we have introduced a new state for a virtual machine to be in.  This is called “Off-Critical”.

What is happening here is that there is a virtual machine registered with Hyper-V – but we cannot find the XML configuration file for that virtual machine.  In the past, this would have just caused the virtual machine to disappear from Hyper-V Manager.  In Windows 8 / Windows Server 2012 we now show the virtual machine in Hyper-V Manager – but mark it as “Off-Critical”.

The most common reason to have a virtual machine that is “Off-Critical” is because you had the virtual machine stored on a file server or removable disk (e.g. USB) that is not currently available. 

When a virtual machine is in this state you have two options:

• Delete the virtual machine.  This will simply tell Hyper-V to stop looking for this virtual machine.
• Restore the missing storage (e.g. reconnect the USB disk)

Note that in the beta build, after you have restored the missing storage you will need to stop and start the virtual machine management service for us to detect that the configuration file is back.  Once you have done this – everything should be good again:

Cheers,
Ben

A couple of days ago I talked about how it was much easier to shrink a virtual hard disk in Windows 8.  But after writing that blog post – I spent some time playing around with PowerShell and found that there was an even better option.

Instead of logging into a running virtual machine, doing some work, shutting it down and completing the operation.  You can do everything from PowerShell in Hyper-V if the virtual machine is shutdown first.

The process that I figured out is as follows:

• get-vm <vmname> | select ID | get-vhd | select path
• This command will get you the virtual hard disk path and file name for each virtual hard disk in the virtual machine. Obviously you can skip this if you already know it.
• mount-vhd <vhdname> –passthru | get-disk | get-partition | get-volume
• This will mount the virtual hard disk in the management operating system, and let you know the drive letter that was assigned to it.
• resize-partition –driveletter <driveletter> –size <newsize>
• This will resize the partition inside the virtual hard disk
• dismount-vhd <vhdname>
• Dismount the virtual hard disk after shrinking the partition
• resize-vhd <vhdname> –ToMinimumSize
• Now shrink the virtual hard disk to match the new size

Here is a screenshot of me resizing a virtual hard disk from 50GB to 30GB on a virtual machine:

This whole process took under a minute and was completed without needing to start the virtual machine.

Cheers,
Ben

Late last year I posted about the process that I followed to reduce the disk size of my virtual machines, prior to converting them to using a fixed size virtual hard disk.  The process I used was quite complicated.

If only I had waited for the beta availability of Windows Server 2012 – things could have been a lot simpler.  You see, one of the new features in Windows Server 2012 is the ability to shrink a virtual hard disk.  You need to free up space inside the virtual hard disk first – but then you can shrink the drive using a simple wizard.  This means that the process of shrinking an existing virtual machine now looks like this:

1. Login to the virtual machine using an administrative account
2. Open Server Manager and select the Disk Management node under the Storage node.
3. Right click on the partition that you want to shrink and select Shrink
4. Select how much you want to shrink the partition by
1. In my case I want to shrink a 250GB partition to 70GB:
   
5. Once this is complete, shutdown the virtual machine.
6. Open the virtual machine settings under Hyper-V and select the virtual hard disk that you want to shrink.
7. Click on the Edit button.
8. This will open the Edit Virtual Hard Disk Wizard where you can now select to Shrink the virtual hard disk:
    
9. Now hit Finish

Hyper-V will automatically shrink the virtual hard disk to remove any free space from the end of the disk – so there is no need to enter how much you want to shrink the disk by.  Once this process is complete your can boot the virtual machine and start using the smaller virtual hard disks.

Cheers,
Ben

Along with the new user experience in Windows 8, we have introduced a number of new Windows-Key shortcut combinations.  For example – Windows Key + C will bring up the charms bar, while Windows Key + Z brings up the application bar.  You can read about all of the various options on the Getting around in Windows 8 post on the Windows team blog.

But how does this work for Windows 8 inside a Hyper-V virtual machine?

With Hyper-V on Windows 8 – we have updated things so that, by default, all Windows key combinations go through to the virtual machine (except for Windows Key + L for locking the desktop).  This means that you can just use the keyboard shortcuts out-of-the-box.

If, however, you are running Windows 8 on Hyper-V on Windows Server 2008 R2 – Windows key combinations will not go into the virtual machine by default.  But this can be easily remedied. All you need to do is to open the Hyper-V settings and go to the Keyboard setting:

There you can select Use on the virtual machine.  Then you will be able to use the new key combinations in virtual machines too.

Cheers,
Ben

Recently a number of the Hyper-V drivers for Linux made it into the main kernel branch.  This means that native support for Hyper-V is starting to turn up in a number of Linux distributions.  Ubuntu 12.04 LTS is an example of a new Linux release with Hyper-V support “out of the box”.  To try this out for myself – I grabbed the 32-bit desktop install media from Ubuntu.com and fired up a virtual machine:

After the initial splash screen, I was pleasantly surprised by the first indication of the improved Hyper-V support.  Before even install Ubuntu, on the first page of setup, I already had integrated mouse support.

I chose to Install Ubuntu and was then presented with a page that confirmed that I had enough space, and I had a valid internet connection. This was also interesting to note, as I had not added a legacy network adapter to the virtual machine.  This meant that Ubuntu had already recognized and loaded drivers for the Hyper-V high-performance network adapter.

After this – the installation was fairly pedestrian…

The only quirk I encountered was that at the end of the initial installation phase – the virtual machine failed to reboot automatically.  It sat at this page for about a minute until I manually reset it:

But after that it booted perfectly:

And I confirmed that applications and network connectivity was working correctly:

My favorite part of this was seeing this message:

“No proprietary drivers are in use on this system”.  Correct! The Hyper-V drivers are now part of Linux, under GPL.

Cheers,
Ben

You probably do not know who Eric Bahna is, but let me tell you why you want to.  Eric is a Senior Program Manager on my team who has been driving the development of Hyper-V’s PowerShell support for Windows 8 / Windows Server 2012.  If you want to know the “behind the scenes” story – Eric is the man to talk to.  In fact, half the time when I do a blog post about Hyper-V PowerShell cmdlets, at one stage in the writing of the blog post I had to walk into Eric’s office and ask “how the heck do I make this work?”

With all that in mind – here is an interview with Eric where he talks about what is happening with Hyper-V PowerShell Support in Windows 8 / Windows Server 2012:

Cheers,
Ben

A little while ago I wrote about how storage migration actually works.  One thing I would like to call out is that the storage migration process is “copy and delete” and not “move”.  Which is to say that just before storage migration is completed you will have two copies of your virtual hard disks on your computer, and the final stage of the storage migration will be to delete the original versions of the virtual hard disks.

Why I am I highlighting this?

Well, storage migration is designed to allow you to move your virtual machines from one storage location to a completely different location (i.e. a new disk, SAN or SMB share). But every now and then I find myself using storage migration just to reorganize my virtual machines and their folder structure.  This can result in problems if I want to move a large virtual machine from one folder to another folder on the same disk.  If I want to do this I need to make sure that I have enough space for two copies of the virtual hard disk.

Cheers,
Ben

Hyper-V provides one setting that you can configure for storage migration.  The maximum number of storage migrations you can have happening at the same time:

By default this is set to “2”.  If you try to perform more than this – you will receive an error message that tells you that you are at your limit.  If you want to change this setting (I usually set it to 10) the only thing you need to consider is if your physical storage is up to having that much I/O occurring at one point in time.  My systems tend to have SSD disks or to be configured in RAID 10 and are able to handle a larger number of simultaneous storage migrations comfortably.

Cheers,
Ben

A common question I get asked about storage migration is “how does it perform?”

This question can actually be broken into two components:

• How long does it take to move the virtual machine storage?
• How does performing a storage migration effect the rest of the system?

Let’s tackle these sections separately. 

First up – how long does it take to move the virtual machine?

As I have discussed, at the core of storage migration is the combination of a single file copy of the virtual hard disk that is being moved, combined with duplicating incoming virtual hard disk writes.  This approach means that the actual length of the storage migration depends on the amount of activity that is happening inside the virtual machine.  The more data the virtual machine is writing to its storage, the longer the storage migration will take.  For a virtual machine that is mostly idle (with little disk activity) the amount time that it takes to complete a storage migration is going to be similar to the amount of time it takes to perform an unbuffered copy of the same files.

I highlighted the word “unbuffered” because most of the time people perform buffered file copies.  If you just copy a file in Windows explorer – you are doing a buffered file copy.  These copies tend to be faster, but they utilize more system resources to do so, and are not recommended when copying very large files.  You can do an unbuffered file copy manually in Windows by using the command XCOPY /J.  This should give you a good idea of the amount of time that will be involved in using storage migration.

Now for the second part – how does performing a storage migration effect the rest of the system?

Assuming that you are migrating your storage to a new physical disk (or a separate SAN or SMB share) the impact is surprisingly small.

If you imagine a running virtual machine, with reads and writes happening to its virtual hard disks, storage migration will add the following activity:

• Data is being read from the source virtual hard disks and written to the destination virtual hard disks.  The extra read activity on the source virtual hard disks will effect the overall performance of the virtual machine, but the write activity will be happening on a different device.
• New writes are being sent to both the source and destination virtual hard disks.  This has very little impact at all, as the duplicated writes are happening to a different disk.

With all of that said – the performance impact of a storage migration is pretty bad if you migrate to another location on the same disk.  If you think through this scenario (storage migration with a source and destination location on the same physical device) you will essentially be doubling the write operations on the disk, and performing a large unbuffered file copy at the same time.

All this to say – if you are interested in assessing the performance of storage migration – do not test it with a storage migration where the source and destination locations are on the same physical disk.  Instead, use it like it is intended to be used and storage migrate between separate physical devices.

Cheers,
Ben