blog.scottlowe.org

Welcome to another installation of Virtualization Short Takes!

• For you Quicksilver lovers out there that also run VMware Fusion, here’s a handy trick to allow you to launch Windows apps to run under Fusion via Quicksilver.
• Duncan of Yellow Bricks points out this VMware Communities Forums thread discussing how to determine which host has a lock on a LUN. This thread also makes brief mention of the new VMFS version, version 3.31, that was released with ESX 3.5, which does a better job of handling SCSI reservations than previous versions. Good find, Duncan!
• Speaking of the new VMFS version, a summary of the information shared in the VMware Communities Forums threads can be found here.
• While we are on a bit of a storage kick, VMware has launched a new VMware Storage blog, and one of the early posts deals with VMFS. The post primarily attacks the notion of VMFS as a “proprietary” file system (which it is) by describing the advantages that VMFS provides. I’m hoping that the new storage blog will get more technical than marketing in the future, but the information is useful nevertheless.
• This link falls more into the “ironic” category than anything else. Do you suppose he got into trouble with Citrix for blogging about how to use a competitor’s product to test ICA performance?
• John Howard gives us an in-depth look at Hyper-V’s handling of virtual NICs in this article. This is particularly important for users who are interested in cloning VMs hosted on Hyper-V; I would assume that SCVMM 2008 will handle this correctly.
• This news emerged several weeks ago via VMblog.com. It’s good to see Leostream getting some recognition; their broker is actually quite good in many respects.
• Sven over at Virtualfuture.info recently blogged about XenServer’s HA functionality and how Marathon’s EverRun products play into that functionality. I actually had a conference call with the folks from Marathon several months ago about EverRun, but never got around to blogging about it. I do like the fact that you can control HA functionality on a per-VM basis, whereas VMware HA is applied to all VMs. (Well, I suppose you could disable HA for the VMs that you don’t want restarted, but it’s not quite the same.) I do agree with both Sven and PeterB’s comments regarding “Continuous Availability”; the sooner that VMware gets this functionality out the door, the more of a leg up they’ll have on the competition.
• As has been reported elsewhere as well, Reflex Security has released the Reflex Virtual Security Center (VSC). The full press release is here. Based on what I’ve read thus far, it appears that the idea behind the VSC is to combine the information from multiple instances of their Virtual Security Appliance (VSA) so that users get the “full view” of what’s occurring across the virtual infrastructure. In this regard, it is remarkably similar to Altor Networks’ Virtual Network Security Analyzer (VNSA), which is also designed to provide visibility across the entire virtual infrastructure.

As always, feel free to share other interesting links and news in the comments below. Thank you!

Here’s the latest installation of Virtualization Short Takes, my occasionally-weekly view on various virtualization news, reviews, and other happenings. Hopefully I can share something interesting with you!

• Via VMblog.com, I saw that Transitive Corporation is supporting the use of QuickTransit within Hyper-V virtual machines. This is interesting because it extends the ability of Hyper-V to help customers consolidate applications. QuickTransit, in case you aren’t aware, allows applications written for Solaris/SPARC environments to run in Linux/x86 environments. It was also the technology behind Apple’s Rosetta, which allowed Mac users to run PowerPC apps on Intel Macs. Does anyone know if QuickTransit is supported within VMware VMs, or is this specific to Hyper-V?
• This one was quite interesting to me. Question #2 is particularly applicable: why is a reboot required, anyway? (Yes, yes, I know—there is a workaround that does not require a reboot. It’s the principle of the matter.)
• Via various sources on the Internet, I learned about the release of ESX Manager. This looks like quite an interesting tool, although I have not yet had the opportunity to install or try it yet. Anyone out there tried this and have some feedback for us?
• Every now and then, something comes up about Citrix XenServer and Xen and it makes me wonder about the relationship between Citrix and the open source Xen community. The latest thing is what appears to be an offhand comment by Simon Crosby of Citrix where he says, “Because we own the hypervisor, we can do much more integration and development around it” (read it in context here). What does that mean? What does “ownership” of the Xen hypervisor mean? And if the Xen hypervisor is licensed under an open source license (GNU GPL v2, according to this page), how can Citrix make proprietary extensions to the hypervisor without being forced to release those extensions back to the community? I guess I just don’t understand the relationship there and how it works. This is where the murky waters of a commercial entity “owning” an open source project come into play, in my mind.
• I ran across this very useful tip for creating a vSwitch with a specific number of ports. It looks like Dwight Hubbard, the maintainer of the site, also has some other interesting posts. Might be worth adding his feed to your RSS reader.
• Nick Triantos discusses NetApp’s Site Recovery Adapter (SRA) and its role with VMware Site Recovery Manager (SRM). Anyone have any links to similar discussions of the SRAs for other storage vendors?
• John Howard provides a great breakdown of how Hyper-V generates dynamic MAC addresses and how Hyper-V attempts to protect against MAC collisions in some circumstances.
• The VI3 Security Hardening Guide has been updated, which is good because some people felt it just didn’t go far enough.
• VMware re-iterated their stance on being storage protocol agnostic, and in the article included a very useful table that summarizes the various products and technologies and which are supported with which storage protocols. While the rest of the post is helpful, that summary of supported features is probably the most helpful.
• Interesting in trying out Hyper-V, but don’t have shared storage? Take a look at this blog post. I think you’ll find it helpful.

I’m always on the lookout for other interesting or useful virtualization news, tips, and tricks, so feel free to share with me and other readers in the comments.

I stumbled across this post by Duncan over at Yellow Bricks about his inclusion in a recent Top 10 list by Eric Siebert over at VMware-land. The new Top 10 list is “Top 10 blogs that VMware administrators must read.” This list is a regular “Who’s Who” list of well-known bloggers like Mike Laverick, Eric Sloof, Christofer Hoff, and others. Lo and behold, I find out that I’m on the list as well! And at #2, no less!

Thanks to all my readers and to everyone who has helped me along the way. It’s been a tremendous pleasure writing this blog and I’m looking forward to many more posts in the future!

In early December of 2006, I wrote a very popular article on VMware ESX, NIC teaming, and VLAN trunking. In that article, I laid out the configuration for using both NIC teaming and VLAN trunking. In particular, the NIC teaming configuration in that article described the use of Cisco Gigabit EtherChannel for link aggregation, in which both the physical switch and the vSwitch are configured to distribute traffic across all the links between them.

Since that time, the question has come up many times: which method is better, with EtherChannel or without? Many engineers prefer not to use EtherChannel (or its standardized equivalent, static LACP/802.3ad) because of the added complexity involved. It’s easier to just team the NICs at the vSwitch level and leave the physical switches alone. That is true, but what about performance? And what impact does this have on NIC utilization?

There are two ways of handling NIC teaming in VMware ESX:

1. Without any physical switch configuration
2. With physical switch configuration (EtherChannel, static LACP/802.3ad, or its equivalent)

In the NIC teaming/VLAN trunking article I referenced above, I noted that there is a corresponding vSwitch configuration that matches each of these types of NIC teaming:

1. For NIC teaming without physical switch configuration, the vSwitch must be set to either “Route based on originating virtual port ID” or “Use explicit failover order”
2. For NIC teaming with physical switch configuration—EtherChannel, static LACP/802.3ad, or its equivalent—the vSwitch must be set to either “Route based on ip hash” or “Route based on source MAC hash”. The majority of the testing I’ve done is with “Route based on ip hash,” so that’s where I’ll focus most of this discussion. Either way, the physical switch’s link aggregation mechanism should match whatever configuration is set on the vSwitch.

In order to better understand how these settings and different configurations affect NIC utilization, I set out to do some tests in the lab. Most of my tests were centered around IP-based storage from the host (i.e., using NFS or iSCSI for VMDKs), and only tested two basic configurations: using “Route based on originating virtual port ID” and no link aggregation and using “Route based on ip hash” with link aggregation. Although the tests were slanted toward IP-based storage traffic, the underlying principles should be the same for other types of traffic as well. Here’s what I found.

NIC Teaming Without Link Aggregation

First, it’s important to understand the basic behavior in this configuration. Because the vSwitch is set to “Route based on originating virtual port ID”, network traffic will be placed onto a specific uplink and won’t use any other uplinks until that uplink fails. (This is described in more detail in this PDF from VMware.) Every VM and every VMkernel port gets its own virtual port ID. These virtual port IDs are visible using esxtop (launch esxtop, then press “n” to switch to network statistics). That’s simple enough, but what does this mean in practical terms?

• Each VM will only use a single network uplink, regardless of how many different connections that particular VM may be handling. All traffic to and from that VM will be place on that single uplink, regardless of how many uplinks are configured on the vSwitch.
• Each VMkernel NIC will only use a single network uplink. This is true both for VMotion as well as IP-based storage traffic, and is true regardless of how many uplinks are configured on the vSwitch.
• Even when the traffic patterns are such that using multiple uplinks would be helpful—for example, when a VM is copying data to or from two different network locations at the same time, or when a VMkernel NIC is accessing two different iSCSI targets—only a single uplink will be utilized.

This last bullet is particularly important. Consider the implications in a VMware Infrastructure 3 (VI3) environment using the software iSCSI initiator with multiple iSCSI targets. Even though multiple iSCSI targets may be configured, all the iSCSI targets will share one uplink from that vSwitch using this configuration. Obviously, that is not ideal.

Note that this doesn’t really impact VMotion traffic, since VMotion is a point-to-point type of connection. VMotion would only be impacted if placed on a vSwitch with other types of traffic and their virtual port IDs were assigned to the same uplink.

NIC Teaming With Link Aggregation

In this configuration, EtherChannel/static LACP/802.3ad is configured on the physical switch and the ESX vSwitch is configured for “Route based on ip hash.” With this configuration, the behavior changes quite dramatically.

• Traffic to or from a VM could be placed onto any uplink on the vSwitch, depending upon the source and destination IP addresses. Each pair of source and destination IP addresses could be placed on different uplinks, but any given pair of IP addresses can use only a single uplink. In other words, multiple connections to or from the VM will benefit, but each individual connection can only utilize a single link.
• Each VMkernel NIC will utilize multiple uplinks only if multiple destination IP addresses are involved. Conceivably, you could also use multiple VMkernel NICs with multiple source IP addresses, but I haven’t tested that configuration.
• Traffic that is primarily point-to-point won’t see any major benefit from this configuration. A single VM being accessed by another single client won’t see a traffic boost other than that possibly gained by the placement of other traffic onto other uplinks.

This configuration can help improve uplink utilization on a vSwitch because traffic is dynamically placed onto the uplinks based on the source and destination IP addresses. This helps improve overall NIC utilization when there are multiple VMs or when a VMkernel NIC is accessing multiple IP-based storage targets. Note again, though, that individual connections will only ever be able to utilize a single uplink.

Practical Application

I come back again to the question I asked earlier: what does this mean in practical terms?

• If you want to scale IP-based storage traffic, you’ll have to use link aggregation and multiple targets. Using link aggregation with a single target (destination IP address) won’t use more than a single uplink; similarly, no link aggregation with multiple targets will still result in only a single uplink being used. Only with link aggregation and multiple targets will multiple uplinks get used.
• Link aggregation will help with better overall uplink utilization for vSwitches hosting VMs. Because there are multiple source/destination address pairs in play, the vSwitch will spread them around the uplinks dynamically.
• To achieve the best possible uplink utilization as well as provide redundancy, you’ll need physical switches that support cross-stack link aggregation. I believe the Cisco Catalyst 3750 switches do, as do the Catalyst 3120 switches for the HP c-Class blade chassis. I don’t know about other vendors, since I deal primarily with Cisco.

Clearly, this has some implications for efficient and scalable VI3 designs. I’d love to hear everyone’s feedback on this matter. In my humble opinion, extended conversations about this topic can only serve to better educate the community as a whole.

I just wanted to provide a quick update on some articles I have in the works to be (hopefully) published soon.

• I’m working on an article discussing when to use various NIC teaming configurations with VMware ESX. There are some significant repercussions here for a variety of network configurations, but especially so for configurations involving IP-based storage (iSCSI or NFS).
• I’m finally wrapping up an article on the Xsigo I/O Director. I’ve been working a Xsigo VP780 in the lab for quite some time, and this article will provide a brief overview along with some tips and tricks.
• I received word from HP that I should be getting a ProCurve switch in my lab soon, so that means I can provide a ProCurve-oriented version of this NIC teaming and VLAN trunking article.
• I have some notes on using NetApp Open Systems SnapVault (OSSV) in conjunction with VMware ESX that I plan to post here as well.

New versions of the Linux and Solaris AD integration articles are on the way as well, starting with an update of the Solaris instructions to accommodate Solaris 10 Update 5 and Windows Server 2008.

If there’s anything else you’re interested in seeing, let me know in the comments. Thanks for reading!

UPDATE: The NIC utilization article is available here.

I recently wrapped up some testing in my lab around VMware HA; specifically, around VMware HA isolation response. My tests involved various network configurations and attempted to clearly document the behavior of VMware HA isolation response under different circumstances. I thought I’d share some of my findings here in the hopes that others would find this information useful as well. (Keep in mind that some of the stuff listed below is just common sense, but I’m including it here anyway just for completeness.)

• Ensure that the vSwitch hosting the Service Console has at least two uplinks. Keep in mind that instead of leaving that second uplink primarily unused, you can place other traffic on the same vSwitch and use the “Override vSwitch failover order” option to direct traffic preferentially onto certain uplinks. (I’ll most likely post a separate blog entry about that so that I can explain that in more detail.)
• Ensure that DNS is working correctly on all ESX hosts in the HA-enabled cluster. You should verify host name resolution for both short names as well as fully-qualified domain names (FQDNs). Although I’ve seen numerous recommendations to hard-code entries into /etc/hosts, this approach is difficult to manage and does not scale well. Just fix DNS instead.
• Ensure that the Service Console’s default gateway responds to ping. If it does not, you’ll need to use the das.usedefaultgateway and das.isolationaddress parameters to change where VMware HA should check to see if it is isolated. Chad Sakac recently discussed these items as well, so check that entry for additional information.
• In a Cisco networking environment, ensure that Portfast is enabled on all physical switch ports. This will help reduce the possibility of an isolation response occurring due to transient network issues. Otherwise, the delay to put the port into a forwarding state is longer than the isolation response timeout, and a brief loss of connectivity could easily result in triggering VMware HA isolation response.
• If you are going to use a second Service Console port, be sure to specify a different IP subnet for the matching vswif interface. Otherwise, the Service Console’s routing table gets involved and tries to route everything through vswif0. That kind of defeats the purpose behind the secondary Service Console. My tests showed that isolation response was triggered every single time connectivity to vswif0 was lost when the secondary Service Console shared the same IP subnet as the primary Service Console interface.
• It should go without saying, but be sure that the secondary Service Console port is placed on a different vSwitch than the primary Service Console port. (Common sense, I know, but it’s worth pointing out anyway.)
• My tests have not shown that it’s not necessary to use a secondary isolation address when using multiple Service Console ports. The same post by Chad I linked to earlier seems to imply (unless I’m reading it incorrectly) that you should have multiple isolation addresses. I’m certainly open to any additional clarification any readers may be able to provide.

If you have any additional information or recommendations to share, please include them in the comments.

Sanbolic, whose Melio FS product I discussed a short while ago, announced today the availability of their Kayo file system. The official press release is here in PDF format. Quoting from the press release:

Sanbolic today announced that Windows Server 2008 Hyper-V virtual machines can now be stored on a single shared storage area network (SAN) storage volume using Sanbolic Kayo File System. The virtual machines can then be moved independently between physical host servers using Quick Migration because all host servers have shared access to the virtual machines files. Kayo FS will be price at $299 per host server and sold in a 5 license bundle.

Kayo FS is described as “VMFS for Hyper-V,” providing file level shared access to a shared SAN volume. This is distinguished from Sanbolic’s advanced file system, Melio FS, which provides byte-range locking and can provide concurrent access to application data on a SAN. The use of either Kayo FS or Melio FS resolves a key problem with Hyper-V deployments that want to take advantage of Quick Migration functionality, and that is that each VM would require its own LUN.

The introduction of Kayo FS also removes the key objection to the use of Melio FS for Hyper-V deployments: price. Kayo FS will be priced much lower than Melio FS; this means organizations adopting Hyper-V will be much more likely to swallow the cost of Kayo FS vs. Melio FS.

What is up with this? In case you’ve been hiding under a rock—or, like me, have been on the road all day with no Internet access—VMware issued a press release today announcing the removal of Diane Greene as President and CEO of VMware, to be replaced by a former Microsoft executive, Paul Maritz. Where in the world did this come from?

I think that everyone knew that VMware’s meteoric revenues simply would not and could not continue as they had. Too many competitors, including Microsoft, were nipping at their heels. I’ve been saying for months that VMware needed to be diligent and continue to innovate, to keep the focus off the virtualization engine itself and keep the focus on the tangible business benefits of using virtualization. This means that VMware needs to continue to deliver game-changing technologies like live migration (VMotion), DRS, VMware HA, and Storage VMotion. As soon as customers see that other vendors are delivering “good enough” virtualization engines, VMware will begin to lose its luster. Is that what happened here, and Greene became the “fall guy”?

This site in the UK indicated that VMware had issued a fiscal 2008 shortfall, but I’ve been unable to locate that information, aside from this WSJ article that briefly mentions VMware lowering their revenue forecast. The same article also links to this Fortune article that indicates that Greene’s contract ended this month (I didn’t see that information in the linked article). Perhaps, as that article suggests it’s simply a failure to renew a contract. Whatever the reason, it’s a new era at VMware starting today.

We may never know the real reasons or motivations behind the move. The real question, in my mind, is what’s next? The relationship between EMC and VMware has always been an “arms length” relationship. Does the appointment of Paul Maritz, a former Microsoft executive and previously the director of EMC’s cloud computing business unit, signal a change in that relationship? Despite the rumors of EMC spinning out VMware, or the rumors of Intel buying VMware, there are others that think this signals the start of a new relationship:

But he agreed that a spin-off of the remaining VMware shares now looks less likely, since EMC has “essentially inserted one of its own as CEO.”

In addition, rumors from the field of EMC sales reps more closely aligning themselves with their VMware counterparts, and in some cases even inviting themselves onto VMware sales calls in an effort to pitch storage wares seem to indicate a new level of interaction (and perhaps integration?) between VMware and EMC. This move, led by Joe Tucci, also seems to indicate that the “arms length” relationship between VMware and EMC is now over. Is VMware’s autonomy now over? To borrow a line typically reserved for Microsoft, resistance is futile.

UPDATE: As expected, coverage of this is everywhere. Of the various articles covering this, I enjoyed this one the most. And I really have to agree—why in the world would you rattle the entire company by firing its CEO, possibly placing yourself in the position of losing its Chief Scientist (Mendel Rosenblum, who is Diane’s husband), right at the worst possible time? Microsoft is finally ready to compete with VMware. Why now? From where I’m sitting as an ordinary guy who knows absolutely nothing about running multibillion dollar companies, I have to say I think this was a boneheaded move.

Here’s Virtualization Short Take #12, a collection of links I’ve gathered over the last week or so and my thoughts on them. Enjoy!

• For those that missed it in the Release Notes, VMware added support for Storage VMotion and 10Gb Ethernet with iSCSI SANs, as outlined in this VI Team blog entry. I went back and reviewed the Release Notes and didn’t see this listed anywhere, so this is news to me. Of course, I already knew that Storage VMotion worked just fine with iSCSI, but this added formal support for iSCSI.
• Virtualfuture.info published some good recommendations for running Citrix in a VI3 environment. If you run Citrix Presentation Server…er, XenApp…in a VI3 environment, these tuning tips may prove quite handy.
• VMware’s Virtual Reality blog posted an entry on some of the architectural advantages of VMware Infrastructure in comparison to the two leading competitors, Xen (any Xen-based solution) and Hyper-V. Many of the things listed as advantages by VMware are severe points of contention with the other vendors, such as the direct vs. indirect I/O model. Ultimately, time will tell which model was the best; I honestly don’t know enough about the deep dark internals to really state which is better. One thing I am glad to see pointed out is the true comparison of hypervisor sizes; Microsoft can say all they want that Hyper-V is only 600K in size and therefore is the “thinnest” hypervisor, but the truth of the matter is that Hyper-V can’t run without Windows Server 2008 in the parent partition. As a result, it doesn’t really matter how “thin” Hyper-V is, does it?
• Via Mike Laverick, I learned that Microsoft may have brought up the whole 64-bit hypervisor vs. 32-bit hypervisor argument yet again. Mike used a snippet from this Microsoft Virtualization Team Blog entry; in reading it myself, I don’t get quite the same 64-bit vs. 32-bit that Mike picked up. That’s good, because I didn’t want to have to go there again. Personally, the tone I picked up from the whole article was one of educating people far too accustomed to Virtual Server/VirtualPC and trying to educate them on how Hyper-V is different.
• Virtualization analyst Chris Wolf recently posted an entry in which he questioned if Apple would capitalize on the opportunity that virtualization is creating. It’s an interesting scenario, one that is similar to a scenario that I discussed a couple of years ago in a piece titled “Application Agnosticism.” In that article, I suggested that seamless host-guest interactions with virtualization software (now implemented by VMware as Unity and by Parallels as Coherence) would usher in a new wave of computing. I suggested that Mac OS X was ahead of the curve because of its ability to run native OS X applications, UNIX applications, X11 applications, Windows applications via WINE (or the commercial variant CrossOver Office), and applications from any other operating system via virtualization. Sounds like I may have been a bit ahead of my time!
• Chad continues discussing VMware HA with another post on some additional configuration options for HA. Also check out the comments with links to even more information on HA’s advanced configuration options.
• This VMware KB article has some good information on getting LUN identification information. The breakdown of the command-line output from esxcfg-mpath is particularly helpful (and for that reason I’ve added it to my del.icio.us bookmarks).
• Rich of VM /ETC shares with us a “Doh!” moment he had when he saw this simple method for identifying VMs with snapshots. Sometimes it’s the simplest solutions that evade us the longest. Here’s what I want to know: Aaron, what exactly does “/HEADDESK” mean, anyway?
• This article at SearchNetworking.com brings to light some of the challenges networking professionals face with server virtualization. I do agree with one point made in the article regarding the mapping of applications—what the end users really care about—to the networking infrastructure. VMware’s support for CDP in recent versions of VMware Infrastructure is a step in the right direction, but there is still more work to do for sure. I’m not so sure about the rest of the points in the article, but I may be an exception to the norm; I was a CCNA for a while (on track for CCNP) and have done my fair share of Cisco configurations, so I’m no stranger to the networking world. The use of VLANs to ease configuration in a server virtualization environment seems just second nature to me. Also, I did note that the author indicated that “server administrators sometimes inappropriately configure the switches to create a loop” (referring to vSwitches in ESX). How exactly does that happen? I’ve never seen a way to link two vSwitches together without using a VM.

As always, readers’ thoughts are welcome in the comments!

Yesterday, Brian Madden wrote an interesting editorial about how he thinks that Citrix will drop the Xen hypervisor in favor of Hyper-V, and will essentially “port” XenServer to run on Hyper-V. Keith Ward at Virtualization Review picked up on this in his post titled “The End of Xen?”. Today, Brian posted a follow-up article clarifying that he wasn’t talking about XenServer, but the open source Xen hypervisor.

Architecturally speaking, the commercial XenServer product and the open source Xen hypervisor are inextricably linked to each other. I don’t see how it would even be possible for Citrix to “port” XenServer, which is a Linux dom0/parent partition plus an “enhanced” build of the Xen hypervisor, to run on Windows Server 2008, or even to use Microsoft’s hypervisor. Keith addresses this point in his article:

I’m not sure what Brian’s sources are on that, but I’ve talked to people in the know for both Microsoft and Citrix, and they state that although the two hypervisors interoperate very well, that they are not duplicates, or near duplicates, of each other. They were developed entirely separately, but there is a common perception, in fact, that Hyper-V is based upon Xen. Not true.

It’s probably pertinent to clarify some architectural issues at this point. (Experts and gurus, feel free to correct me if I am wrong.) Both XenServer (and non-commercial Xen implementations) as well as Hyper-V must have the parent partition present in order to function; they cannot function alone. This is because critical functions like networking and storage are routed through the dom0/parent partition. Without dom0 (a Linux instance for XenServer and non-commercial Xen implementations) or the parent partitions (Windows Server 2008 for Hyper-V), the hypervisor has no I/O functionality. This means that Xen is very closely tied to Linux, and Hyper-V is very closely tied to Windows. Making either run with the other would be a monumental task, if it’s even possible. I could be wrong; while these two products share some architectural similarities, they still seem worlds apart to me.

So, in my mind, the idea of Citrix dropping the use of the open source Xen hypervisor—or any commercial variants of the hypervisor—in favor of Hyper-V are so far-fetched so as to be nonexistent.

Now, that’s not to say that Citrix won’t try to provide some enhanced functionality for Hyper-V, such as live migration (what they call XenMotion and what VMware calls VMotion). This is a key feature that is missing from the initial release of Hyper-V. Is this even possible, though? If it is possible, is it worthwhile? Microsoft has already publicly stated on multiple occasions that live migration will come to Hyper-V in a future release. Why spend a great deal of time, money, and development cycles adding functionality that Microsoft is planning on building anyway?

It’s also very possible, even likely, that Citrix will expand their XenDesktop offering to encompass virtual machines hosted on Hyper-V, thus combining their application/desktop delivery expertise with Microsoft’s hypervisor and virtualization management capabilities. Now that’s quite a possibility, in my opinion. This would be just another example of how Citrix has survived over the years by plugging the gaps in Microsoft’s product line, this time offering significant and beneficial desktop virtualization functionality to Hyper-V environments.