The best way I determined to do this was to break out PowerShell/WMI and hit my host remotely:

Get-WmiObject -ComputerName my_hyper-v_hostname-Query “SELECT * from Win32_ComputerSystem”).TotalPhysicalMemory / (1024*1024*1024)

I like PowerShell, and both vSphere and Hyper-V get big points in my book for being able to be managed with it – remotely, even.  Don’t get me wrong, XenServer has the full power of *nix batch scripting using its xe commands, but PowerShell makes things pretty simple for your average Windows administrator.

Once my VMs were built, there were few surprises, but accomplishing some tasks required thinking a different way on different platforms.  Coming from a VMware background, the methods for attaching an ISO image to a VM in either XenServer or Hyper-V seem somewhat awkward.  With XenServer, ISO images are stored on an NFS or CIFS share and mapped as a datastore object to the hosts within a management domain.  There is no concept of directory hierarchy, and only the ISOs in the root of the share are made available for use.  Hyper-V seems a bit less intuitive since the media access and attachment is accomplished via the local drive on the Hyper-V host .  Sticking the ISOs on a cluster volume seemed to make sense, or creating a persistent drive mapping, but those didn’t quite work out as I expected.  A little digging on TechNet led me to a nugget that I must share.  When an ISO image is presented to a VM, Hyper-V uses the host machine’s credentials to access the network share.  Something called constrained delegation must be configured, and this requires an Active Directory change to the hosts’ machine objects:

To configure constrained delegation for a Hyper-V host:

1. In Administrative Tools, open Active Directory Users and Computers, and then navigate to the machine account for the computer running Hyper-V.
2. Right-click the computer account for the Hyper-V host, and then click Properties.
3. On the Delegation tab, click Select this computer for delegation to specified services only, and then click Use any authentication protocol.

To allow the Hyper-V computer account to present delegated credentials for the library servers:

1. Click Add.
2. In the Add Services dialog box, click Users or Computers, select each server that stores ISO image files, and then click OK.
3. In the Available services list, select the CIFS protocol (also known as the Server Message Block (SMB) protocol) for each of the ISO image servers, and then click Add.

Once this is done, ensure that each Hyper-V host machine has at least Read only permissions (Share and Security) to the CIFS share.  When presenting the media to the VM, enter the UNC path to the ISO image and watch as the magic happens.

After all of this, I was able to get my applications installed into the VMs without further issue.  That part is consistent across platforms since it relies on the guest OS and the resources it can see.  There is a lot more to consider when comparing these platforms for use in your organization, and only you can perform the ultimate comparison.  I will leave you with a few considerations going forward:

1. Make certain you understand how networking works with the platform you select.  For example, Hyper-V has no real concept of a virtual switch as XenServer and vSphere do – its VLAN tags are applied at the VM’s NIC level and any load balancing must occur at the NIC driver level.  Ensure that your NIC vendor’s load balancing driver is supported for Hyper-V, not just Windows Server 2008 – and make sure it will install into Server Core if you choose to use that platform.
2. Ensure that you understand not only how to create VMs, but how to delete them.  VMware vSphere has two options: Remove from Inventory and Delete from Disk.  The first one simply unregisters the VM from the system while the second one actually deletes the files.  Keep that in mind so you don’t inadvertently consume extra disk space. 
3. Consider what problem you are trying to solve and your budget for doing so.  Choice of hypervisor platform should not be taken lightly and it should take into account your organization’s long-term IT strategy.  This type of commitment is roughly equivalent to choosing a vendor for core infrastructure like storage or switching – there may be a significant cost to changing platforms, so the commitment will most likely last several years.  Would your organization consider ripping out all of VendorX’s switching or storage gear for VendorY’s every few months?

The bottom line is that you should carefully weigh each platform’s capabilities (a proof of concept is your friend) against the needs of your organization.  From a cost perspective, make sure you consider up-front costs as well as the cost of ongoing support and maintenance – don’t let anyone tell you that you don’t need 24x7x365 support for production platforms.

Read: vSphere, XenServer and Hyper-V Notes from the field part I – Installation

Pages: 1 2