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!

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.

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!

Here in Virtualization Short Take #11, I offer to you a collection of virtualization-related news and tidbits and my thoughts on them.

• I seem to be on a bit of kick reading Ryan Arneson’s stuff these days. This time is actually an older post of Ryan’s on using the COMSTAR stuff from Sun with ESX. It’s an interesting read. I’m quite fascinated by the myriad things that Sun is doing with storage, and I hope that some of these actually get backed with good execution. I’ve guess I’ve heard the saying “Sun is where storage goes to die” from too many Sun veterans.
• I was notified of this post by Chris Barclay of Virtual Iron regarding a comparison of Virtual Iron Virtualization Manager and Citrix XenCenter. This is an interesting comparison considering that both products are built on the same underlying hypervisor (Xen). In this case, Chris makes the argument that management is the piece that sets one virtualization solution apart from other solutions, and that in this particular case Virtual Iron’s management capabilities far exceeds those provided by XenCenter. I don’t have any direct experience with either of these products, so I can’t attest as to the accuracy of his claims. While I don’t necessarily agree that the hypervisor is being commoditized, I do agree that management is increasingly becoming the factor that distinguishes solutions. In this regard Microsoft has an early lead, in my opinion, with cross-platform VM management inside Virtual Machine Manager 2008. Will other vendors follow suit?
• Last week the new VMware Networking blog posted a notice about a new whitepaper jointly authored by VMware and Cisco. Duncan over at Yellow Bricks also picked this up, but from a different source; the whitepaper, however, appears to be the same from both sources. I haven’t had the opportunity to fully review it yet, but I do plan to do so and will highlight any notable recommendations here.
• Chad Sakac, the “VMware Guru” for EMC, published an entry on stretched ESX clusters. This article was picked up by a number of other bloggers (here or here, for example), so I won’t rehash it all here again. The timing on the article was helpful; he wrote that and not more than two days later I had a customer asking about doing this very thing. Personally, I agree with Chad that it’s generally a bad idea, and so it was handy to be able to point the customer to this article as further support. One other thing I did get out of Chad’s post—how many of you picked up that up to 10 different isolation addresses can be configured? Is that in the documentation somewhere and I just missed it?
• Continuing on with Chad, it appears that an old VMware HA article of mine is useful in helping to understand how the VMware HA admittance algorithm works. Chad’s article provides excellent details on the key concepts to understand.
• Most readers have probably seen the article describing how to access the ESXi command line. This article also shows you how to enable SSH access to that CLI. I found this information so handy that I added it to my del.icio.us bookmarks. As ESXi gains broader adoption, this kind of stuff will be very useful.
• With the release of Hyper-V, comparisons of Hyper-V vs. ESX will become much, much more common. Here’s another one for review as well. I’ll echo the comments in this article regarding the comparisons: it’s not about the brand, or the technology, it’s about the solution.
• I’ll have to partially disagree with the sentiment behind this article regarding the use of virtualization as a DR tool. The article intends to present 5 things that should be considered when using virtualization for DR, but does not, IMHO, accurately present some of the challenges around virtualization for DR. How are the VMs being replicated over to the DR site? Replication technologies need to be properly coordinated with the virtualization software so that the data being replicated is consistent and useable. If this is synchronous replication it’s not as much of an issue, but it’s definitely an issue with asynchronous replication. What about registering VMs on the DR site? How does one handle VirtualCenter in this kind of scenario? Is testing failover really that easy? My experience indicates that while virtualization can certainly assist in creating a good DR plan, it’s only one part of an overall DR solution, and it can create its own unique challenges. Again, the timing of this is interesting; I just came across the article after finishing up a presentation about the use of virtualization in disaster recovery solutions.
• Anyone working in the VDI environment has almost certainly had more than their fair share of discussions about remote display protocols. This article on x86virtualization.com provides a decent overview of VNC, RDP, ICA, and Net2Display. Seems like I recall seeing something somewhere about VMware assisting in the development of Net2Display; anyone know anything more about that?

I guess that about does it for this round. Thanks for reading, and feel free to share your thoughts in the comments.

Here are some virtualization links I found interesting over the last few days:

• Duncan points out a VMTN thread regarding VMware HA behaviors in “heterogeneous” clusters, i.e., clusters that include 1/2 vCPU VMs as well as 4 vCPU VMs. The recommendation is to move these 4 vCPU VMs into their own cluster to help address this issue. This is similar to the discussions I had here about VMware HA failover capacity calculations, and it goes to further reinforce the fact that planning is needed to fully take advantage of VMware HA’s functionality. It’s not quite “fire and forget” just yet, folks.
• Via a number of different sites, I learned that VMware has released version 2.1 of VDM. More information is available in the Release Notes. Of key interest to me is the defined process for bulk importing individual desktops, which will make it easier for organizations that already have a number of desktop images to bring those VMs into VDM.
• On the VMware performance blog, they’re discussing achieving 100K IOPS with a single ESX server. While some of the readers are taking VMware to task for what they call an “unrealistic” test, I do have to agree with commenter Chad who points out that this exercise wasn’t intended to create a “best practices” configuration. The point was simply to see just how high the IOPS could go—nothing more, nothing less, just a test to see how high they could take the number. Yes, I think we’d all agree that using a cluster without 1:1 VM-to-VMFS mappings would be a realistic test, and personally I’d love to see the results of a test like that as well. Even so, it’s still handy to see that the I/O subsystem of ESX is more than capable of handling even the most demanding workloads.
• It becomes more obvious every day that I really need to take some time to learn PowerShell. With Microsoft embedding PowerShell in all their products and VMware embracing it via the VI Toolkit, it’s becoming ubiquitous. Now VMware is even showing off a series of videos about the VI Toolkit and its functionality. Ugh..I need more hours in a day to keep up with all this stuff.
• Paul Shannon of VM-Aware points out this VMware page describing support for Microsoft products, both from Microsoft as well as from various OEMs. Useful information to have, especially when you need to reassure a concerned customer about their support options. Personally, I think it’s just poor business (or poor ethics, take your pick) for Microsoft to be giving customers a hard time about virtualization support while developing their own virtualization product. Come on, we all know that the day Hyper-V goes RTM, Microsoft will start offering full product support for virtualized instances—well, virtualized instances running on Hyper-V, anyway. Am I wrong?
• Via Ruben at Brian Madden’s site (and thanks to an e-mail from Patrick Rouse himself), I learned about this VDI broker comparison created by Patrick Rouse of Quest/Provision Networks. Right now, it only compares VDM, XenDesktop, and Provision Networks Virtual Access Suite (VAS), but they are open to including additional brokers if enough requests come in.
• Brian Madden delves into an extended discussion of the key problem with VDI solutions: the display protocol. He posits that Citrix is in better shape than VMware because of the ICA protocol, but both suffer from the same problem in that “neither ICA nor RDP can remote all applications.” It’s a good read.
• This may be a bit dated now, but here’s some information on an unattended installation of Windows Server 2008 with Hyper-V.
• InformationWeek recently published an article describing Hyper-V’s “advanced virtualization features.” The two things that are really touted by the article are I/O optimization via driver enlightenments, and support for failover clustering at the host level. Driver enlightenments, unless I am mistaken, are equivalent to Xen’s paravirtualized drivers, VMware’s VMware Tools, and Virtual Iron’s VI Tools; they all accomplish the same thing. I’m not sure how having the same feature as all the other competitors makes it “advanced”. It sounds like a standard feature if you ask me. Host clustering support is nice, but not that different from VMware HA; I believe Citrix is due to introduce a similar feature for XenServer soon as well. (It’s my understanding that Marathon Technologies plans to build their “Continuous Availability”-like product to extend this new XenServer HA functionality.) Not that I’m knocking Hyper-V or these features that are slated to be included in Hyper-V; you just can’t call them “advanced” if pretty much every other virtualization solution on the market also has the same features.

Well, that’s it for now. If you have links that you’d like to share with me or other readers, feel free to add them in the comments below or put them in my del.icio.us inbox. Thanks for reading!

In his three recent articles about Quick Migration and live migration, Jeff Woolsey spends a lot of effort differentiating Quick Migration, VMotion, and VMware HA. Personally, I thought the distinction between these features and the purposes they were intended to serve were pretty clear already, but apparently Microsoft’s earlier claims that Quick Migration and live migration were comparable confused everyone.

The three articles from Jeff can be found here:

Hyper-V Quick Migration and VMware Live Migration, Part 1
Hyper-V Quick Migration and VMware Live Migration, Part 2
Hyper-V Quick Migration and VMware Live Migration, Part 3

In the first article, Jeff discusses the importance of high availability (HA) in virtualization scenarios. He’s absolutely right on target with his statements: HA is critical in virtualization implementations. I couldn’t agree more. VMware recognizes this fact and includes VMware HA, and Microsoft recognizes this fact and provides integration between Hyper-V and Windows Server 2008 Failover Clustering. So far, so good.

In part two, Jeff goes on to state that VMotion doesn’t work for unplanned downtime. Again, he’s absolutely correct: VMotion doesn’t work for unplanned downtime. Then again, apart from the comments that Jeff claims to have received from VMware supporters stating VMotion was “far superior for unplanned host downtime and that it was a much better HA solution”, I don’t think anyone has ever claimed that VMotion was an HA solution. I know I certainly haven’t. I can’t recall VMware ever making that statement. After all, if VMotion were an HA solution, why would VMware have VMware HA? What point would there be in two different HA solutions?

Further in that same article, Jeff compares VMware HA with Windows Server 2008 Failover Clustering, aka Quick Migration, and states that they are comparable technologies. Once again, I agree; VMware HA and Quick Migration are comparable technologies. Both will restart virtual machines on another host automatically in the event of a host failure. OK, Jeff and I still agree thus far.

Part three of Jeff’s series wraps things up by attempting to downplay the importance of VMotion. In his words, “Even customers with Live Migration still wait until off hours to service the hardware.” Unfortunately, this is where Jeff and I have to disagree. I don’t know how many customers they spoke to, but I know I have customers that have live migration functionality who use it during business hours. Besides, live migration isn’t just about hardware servicing or patching the root partition/parent partition/Service Console, it’s also about enabling dynamic load balancing a la VMware DRS, or enabling power savings in off-hours via DPM. After all, just because you can shut down and/or power off guests to migrate them doesn’t mean you will necessarily want to in every instance. It may be acceptable for some workloads, but not for all workloads.

I just can’t help but feeling that if Microsoft hadn’t made the comparisons between VMotion and Quick Migration themselves earlier in Hyper-V’s development, this sort of “unequal comparison” that Jeff is trying so hard to clear up wouldn’t have happened.

In The Four Horsemen of the Virtualization Security Apocalypse, Chris Hoff shines a great big spotlight on the dark side of virtualization security (or virtsec, as its increasingly being known). To quote from Hoff’s article:

Short of the notions I’ve discussed previously regarding instantiating the vSwitches into hardware and loading physical servers with accelerators and offloaders for security functions, there aren’t a lot of people talking about this impending set of challenges or the solutions in the short or long term.

This should be cause for alarm.

These issues are nasty. Combined with the organizational issues of who actually owns and manages “security” in the virtualized context, this stuff makes me want to curl up in a fetal position.

I agree with what Hoff has to say and I’m glad he’s taking the time to boil down the issues so that non-security-minded IT pros can really understand the problems. However, Hoff, I have to take you to task for one thing in your article: the kitten thing was just too much. Poor little kitten…

I particularly agree with Hoff’s #1 point (”Virtualized Security Screws the Capacity Planning Pooch”). The idea behind VMsafe and all these virtsec appliances is a great idea and all, but what about the overhead? At what point does having all this “extra” security so greatly bog down our virtualization engine that it’s no longer worth it to virtualize? And how do we actually, realistically begin to address this issue? Do we move the security functions into the hypervisor itself? And while this might address the performance concerns—although I don’t think so—isn’t this just instantiating Hoff’s vUTM?

One of the interesting things that I hope to be able to do soon is try to measure the overhead of some of the virtsec appliances that are currently available on the market. Not to publish any results or hit any vendors over the head with the information, but just to have a better idea for myself and my customers about how this stuff actually behaves in the real world. If anyone has already done that sort of thing and is willing to share their information with me, I’d be mighty appreciative.

I am curious about something—how many organizations are using a single physical host with VMs across different security zones? See, this is something that I would never recommend, and to me it seems like physically segregating your security zones into different virtualization environments solves a fair number of the concerns about the “dynamic data centers” created by VMotion, VMware DRS, and VMware HA. Or am I overlooking a critical aspect?

Here’s some thoughts on a variety of links that passed by me over the last couple of weeks. (Yes, I’ve been a bit lax in getting another Short Take published. Sorry.)

• Colleague Colin McNamara has written a good article about some of the challenges in integrating VMware into a Cisco network. He highlights something I’ve been saying for a while: a VMware implementation is more than just server virtualization; it affects servers, storage, networking, and security, and a good implementation requires addressing all of these areas as well as addressing things like staff organization and change management.
• Christofer Hoff started a good conversation about the performance implications of virtual security initiatives. It’s something many people are probably overlooking. After all, have you stopped to consider the additional processing power that running security products either inside the VMs, or at the hypervisor level, or both, will take from your CPU pool? I have a feeling that those high server consolidation ratios may not be so applicable when you factor in the security overhead.
• Per Duncan and Thomas, ESX Server 3.5 Update 1 will provide support for Microsoft Cluster Server (MSCS). Duncan also broke the news about the incorrect links for the update ESX ISOs.
• Massimo has initiated a discussion, picked up by the VMTN Blog, about the current state of high availability. I’m not a clustering expert, although I’ve setup my share of Microsoft clusters for SQL Server and Exchange Server. In my simplistic view, MSCS and VMware HA don’t really solve the same problem; MSCS is stateful (or mostly so), and VMware HA is stateless. Would you rather have a reasonably stateful failover for your Exchange Server, or would you rather have it rebooted? Stateful failover is not something that can be easily achieved in the virtual world right now, unless you bring MSCS into the virtual world; that, in turn, creates its own set of challenges. Continuous Availability, as demonstrated at VMworld 2007, will bring stateful failover to the virtual infrastructure.
• In the comments for the VMTN post about clustering vs. HA, reader “Matt” questions the use of NFS for VMware. In his linked article, he asks for a good white paper on why NFS instead of Fibre Channel. Well, I can’t provide a good white paper, but I can provide a couple useful articles, like this one or this one, to get started.
• David Marshall at VMblog has published parts one, two, and three of a three-part series on best practices for securing virtual networks. I haven’t had the opportunity to finish reading all three articles yet, but it looks like it’s avoided becoming an advertisement for Reflex Security.

Well, that wraps it up this time. Thanks for reading!

Over the last few weeks, I’ve been collecting various virtualization-related links in NetNewsWire’s Flagged Items collection, with the intention of blogging about them, bookmarking them, or both.  With time a bit short recently—let’s just say that life is really, really busy right now—I decided to just condense a bunch of them here with a brief commentary, where applicable, for each.  Hopefully some of this information will prove useful to some readers here.

• ESX Host Currently Has No Management Network Redundancy Error:  This is new to ESX Server 3.5; VMware HA reports a warning when it detects that there is no redundancy for the Service Console.  Clearly, this is an attempt to prevent situations where isolation response kicks in, and as the author points out can be mitigated by adding another NIC to the vSwitch where the Service Console port group is located.  I have also found that creating a second Service Console port group on another vSwitch will also remove the warning.  Duncan of Yellow Bricks also goes into more detail on Service Console redundancy on his blog as well.
• ESX “Configuring for HA” errors - What to do?:  VMware HA continues to be a sore spot, as Rick Vanover discusses here.  One useful tidbit of information from this article is the suggestion to go directly to the VPX_EVENT table of the VirtualCenter database to look for troubleshooting information.  Rick’s right—VirtualCenter’s error messages with regards to VMware HA are often totally useless.
• How to Use the Remote Command-line Interface to Invoke Storage Vmotion in Windows Server or Desktop:  Jack’s off to a great start to his blog at VMware World with a lot of very relevant and very useful information.  This article on using the RCLI to do Storage VMotion can come in handy at times, until you get the hang of it.  On a related note, Duncan hits us up with some information on useful add-ons for Storage VMotion.
• Virtual Machine High Availability:  Still listed as an “experimental” feature in VI3 version 3.5, if I recall correctly, Virtual Machine HA uses heartbeats from the VMware Tools inside a guest to try to determine if a guest has failed.  Anyone out there doing more than just experimenting with this?
• Delete all snapshots:  For those end users that don’t work with snapshots, this article is a must read.
• VMotion Is Disabled After ESX Server Upgrade:  This can be handy if you were wondering why VMotion suddenly stopped working after the upgrade to ESX Server 3.5.
• Migration will cause the virtual machine’s configuration to be modified:  It’s still not clear exactly why VirtualCenter is making some changes to virtual machines during a live migration.  Duncan’s explanation about virtualized MMU and paravirtualization support in ESX Server 3.5 makes sense, but what about the commenter’s issue with a migration from ESX Server 3.0.1 to ESX Server 3.0.2?  That doesn’t seem to make any sense, especially on identical hardware.

Anyone with additional information on any of these topics is invited to speak up in the comments.

VMwarewolf posted an update today intended clarify the behavior of VMware HA admission control:

I was previously under the impression that Configured Memory (in a VM) was the number used in this consideration. Some further investigation has revealed this is incorrect. It is the Reserved Memory, plus overhead, that is used in this calculation.

If I’m reading this correctly, then reserved memory is the number that really matters when calculating failover capacity.  That leads me to believe, assuming I am understanding this correctly, that a 2GB VM which only has 256MB of RAM reserved would be calculated as 340MB for the purposes of calculating failover capacity (256MB + 84MB overhead for a 32-bit virtual machine, slightly higher for a 64-bit virtual machine).

I suppose in a way that makes sense, since only reserved memory is ever really “guaranteed” to a VM.

However, this again underscores the need for VMware to get on the ball and prepare some useful, comprehensive documentation about VMware HA, how it works, how it’s configured, how one goes about troubleshooting it, and how it behaves when it’s not configured correctly.  Right now, the community is attempting to figure this out itself, and doesn’t seem to be having a great deal of success.