Overcoming the VM I/O Blender?

Last week I was invited to come out and visit with a new company in

the virtualization space called Virsto Software. Virsto is based out

of Sunnyvale, CA and they have developed a new software solution

that will solve a lot of the inefficiencies known to virtualization.

When considering virtualization in the data center a couple of goals

that come to mind are reducing physical footprint, gaining higher CPU

utilization and reduced provisioning time. Hyper-V has provided

affordable options to address these requirements, but limiting factors

still exist. One of the biggest problems that we are faced with as we

start loading up VM's on the host is the I/O blender effect. When you

have a single OS to disk relationship the I/O is smooth, but as you

add additional VM's the hypervizor has to manage all these different

I/O loads and this causes the streams to not flow smoothly anymore and degrades I/O performance. Then there is VM Snapshots that so severely degrade I/O that most data centers have a policy against using them in production.

Virsto's new solution has answers to all these problems and more.

Their solution is also vendor-agnostic, so its works with any storage

solution. Virsto has integrated their software into the native Hyper-V

Manager snap-in, so the footprint is very small on the Host. This

integration allows an administrator to manage their VM deployment,

Snapshots, golden VHD's and Clones all from a single pane of glass.

They have even built their solution to be cluster aware giving data

centers options to improve performance and managements of all their Hyper-V environments.

To address the I/O blender effect they have incorporated a new file

structure that presents Hyper-V disk files as native VHD's to the VM,

but are stored on disk in a format they call vDisk. This newly

developed file structure allows I/O to remain smooth as VM density is

increased and regains a lot of the lost I/O performance from VM's hosted on native file systems. In my own testing I was able to show I/O performance gains between 20-30% over native Microsoft VHD's when benchmarking 1 -25 VM's. But, the biggest improvement was post snapshot with I/O performance with Virsto being as great as a 50% improvement in cases up to 25 VM's. This results in greater VM density and greater storage savings.

Virsto has also addressed concerns with storage sprawl and cloning. In most production environments we work with a number of golden fixed VHD's, many of which may not be used and take up valuable space. Provisioning is time consuming since its based on a file copy process. Virsto implements fixed VHD's same as Hyper-V, but the Virsto provisioning solution commits only the required disk space without having to fully expand the VHD, saving valuable disk space. This same concept applies to provisioning clones from Virsto's built-in cloning feature. When compared to Hyper-V native provisioning of a 70GB fixed VHD this process could take between 5-15 minutes, but in every cloning test case I performed I was able to create the clone and have the VHD ready for boot in just seconds, a tremendous time savings.

Given the potential for drastic storage savings and provisioning improvements, I believe Virsto is a solution that Hyper-V administrators will be adding to their host deployment checklist.

If you would like to learn more about Virsto Software, then check out the link below.

http://www.virsto.com/

NVSPBind: NIC Management from the Command Line

Hello all.....here it is 2010 already and I am just getting back in the saddle after being away on a long break. I lost my father suddenly at the end of last year, so I had to step away from the blogging for a bit. But, I am back and boy do I have a lot of great things to share with you folks over the next couple of weeks. So, lets get started with a new utility that was just released, that I am sure we all will be really excited about.

Keith Mange from the Microsoft Hyper-V team has developed a new utility called NVSPBind, that address a major management headache when working with Hyper-V Server 2008, Hyper-V Server 2008 R2 and server core installations of Windows Server 2008 and Windows Server 2008 R2. When working with these installations, there wasn't a utility or process provided that allowed for the administration of the bindings or protocols for installed network adapters. Unlike the full installation of Windows that leverages the network connections applet.

NVSPBind now gives administrators the ability to enable or disable specific NIC bindings, Hyper-V network switch protocol and query and change NIC connection order. Best of all, this can all be done from the command line.

For instructions on usage and to download the utility, visit the link below.

http://code.msdn.microsoft.com/nvspbind

Deleting a Hyper-V Virtual Switch using WMI and Powershell

For those of you who don’t know, I work for a company called Crutchfield who is an online and mail order consumer electronics retailer providing products for the home and car. It is that time of year again when we are very busy finishing up all systems and application work that is necessary to support our sales operations during the holiday season. This year, one of our final tasks is to complete the upgrades to our nine Hyper-V hosts to Windows Server 2008 R2 and Hyper-V Server 2008 R2.

Last week, we performed upgrades on our Hyper-V Server 2008 hosts to R2 that serve our Test\Dev environments. The upgrades were very straight forward and uneventful, which is what anyone hopes for when performing any upgrade. However, after the upgrade was complete, it appeared that either a virtual switch had either lost its configuration or failed. It turned out that it was one of those problematic Broadcom NIC’s that we all love so much that failed. So, I unbound the virtual switch that was configured to use the NIC from all VM’s and attempted to delete the switch. I was complimented with a nice error message, informing me that it couldn’t be deleted. So, I did what any good admin would do when the GUI fails us and turned to my trusty command line.

So, when administering Hyper-V using powershell, I use the Hyper-V library that is available from codeplex. Unfortunately, the powershell library doesn’t provide a cmdlet for deleting a virtual switch, so I leveraged a WMI class called “MSVM_VirtualSwitchManagementService”. Then, I used the “Choose-VMSwitch” powershell cmdlet to select the virtual switch for deletion and then deleted the switch. I searched online and found plenty of info on creating a virtual switch using powershell, but nothing regarding how to delete it, so I will walk you through deleting a virtual switch I created called “Demo Virtual Switch”.

In the steps that follow I will show you how to create the WMI object reference, select the virtual switch and finally deleted the selected switch. For this demo I am running the scripts local to the host with the virtual switch that I want to delete. With that said, let’s get started!

1. You need to start Powershell and set the execution policy to unrestricted to allow the scripts that follow to execute.

Set-ExecutionPolicy Unrestricted

2. Load the Hyper-V powershell library if it hasn’t already been done.

3. Now, like I said before, there isn’t a Powershell cmdlet for deleting a virtual switch. So, we will need to create an object reference to the WMI Class “MSVM_VirtualSwitchManagementService” so the switch can be deleted. Use the following syntax.

$HVSwitchObj = Get-WMIObject –class “MSVM_VirtualSwitchManagementService” –namespace “root\virtualization” –computer “.”

4. Now, we need to select the virtual switch that we want to delete. There is a powershell cmdlet called Choose-VMSwitch that will allow us to make this selection. The following syntax will provide a list of all the virtual switches that exist on the host and provide the ability to select the switch that is to be deleted. Enter your switch selection by typing the associated ID number from the list and hit enter.

$HVSwitch = Choose-VMSwitch

5. Finally, we delete the switch. The final syntax uses the WMI class to delete the virtual switch selected by the powershell cmdlet.

$HVSwitchObj.DeleteSwitch($HVSwitch)

If you now pull up "Hyper-V Manager" and select “Virtual Network Manager”, you will see that the virtual switch has been removed and problem resolved. At this point I was able to replace my failed NIC, create a new virtual switch and bind the new switch to my virtual machines.

I hope this helps!

Guide to Upgrading to Virtual Machine Manager 2008 R2

It has been several months now since the release of System Center Virtual Machine Manager 2008 R2, but it has been my experience that folks haven't been rushing to upgrade their production environments. However, with the recent release of Windows Server 2008 R2 and the requirement to manage all the new Hyper-V features, I have been very busy helping folks with their upgrade task to VMM 2008 R2. Microsoft did a great job on creating a very clean upgrade with little post installation steps required.

In the steps that follow, I will be focusing on the in-place upgrade from VMM 2008 RTM to VMM 2008 R2 RTM. We will be looking at this in three parts, Pre-Upgrade, Upgrade and Post-Upgrade Tasks.

Pre-Upgrade:
1. Make sure that any jobs that are currently running, have completed before attempting the upgrade. All jobs that ran prior to the upgrade will appear in the job history, but can not be restarted.

2. Make a back up of the VMM database to insure you can restore VMM 2008 in the event of a failure during the upgrade. VMM includes the built-in ability to perform this backup. Go to the "Administration" View and then select "General" or "Managed Computers" and on the right side of the screen you will see an option for "Backup Virtual Machine Manager". Select this option and you will be prompted to provide a path to store the backup.














Upgrade:
3. On the server hosting VMM, run setup.exe with "ELEVATED PRIVILEGES" from the VMM 2008 R2 installer location. The setup will start with a splash screen presenting options to install different components including (VMM Server, VMM Admin Console, Self-Service Portal, Local Agent and Configure Operations Manager.
















If you select any of the options that are currently installed, then the installer will automatically detect those bits and then proceed by asking if you would like to upgrade those components. If you select yes, then the install will start the upgrade process. Should you choose one of the options not currently installed, exp. PRO or Self-Service Portal, then the upgrade will proceed with upgrading the currently installed components and once completed, it will install the additional feature(s).

After the upgrade is complete and the server has been rebooted you will have to perform a few manual steps to insure that your host and library servers are properly communicating with the new VMM 2008 R2 instance. Part of the upgrade to VMM 2008 R2 was an update to the VMM database and this requires an update to the agents to insure the hosts and libraries can be properly managed from VMM.

4. Start the VMM Admin Console and open the "Hosts" view. Under "All Hosts" you will see that all hosts and libraries are now reporting a status of "Needs Attention". If your agents haven't been updated and you don't see this message, then you can do a couple of things. First, you can wait for the normal host refresh window to occur that will update the status. Second, you can Right-Click on the host and select "Refresh" forcing the host agent to report to the VMM server.












5. Now that the agents are reporting a status "Needs Attention" you need to update the agent. In order to update the agent you can do this two ways. First, you can Right-Click your hosts while in "Hosts" view and select "Update Agent". Second, you can go to "Administration" view and select "Managed Computers", then Right-Click your hosts and select "Update Agent". You can select multiple hosts at a time for agent updates, but I generally limit this to 10-15 hosts at a time. After a few moments the job will complete and the agent will be updated with a status of "OK" letting you know the agent version is consistent with the database.













6. Finally, you will need to repeat these steps on any additional VMM 2008 servers you may have and you will need to update any VMM Admin Consoles with the R2 version.

So, thats it, upgrade complete!

If you need additional information regarding Virtual Machine Manager 2008 or Virtual Machine Manager 2008 R2, then please refer to the VMM TechNet site that provides lots of great information on VMM Planning, Deployment, Operations and Security.

http://technet.microsoft.com/en-us/library/cc917964.aspx