blog.scottlowe.org

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.

The VMware peformance team blog (found here) published an entry last week on ESX scheduler support for multiprocessor VMs. The blog entry itself was quite informative; in particular, the information about ESX 3.x’s “relaxed co-scheduling” mechanism was very useful.

Long-time users of ESX will recall that mixing uniprocessor (UP) and multiprocessor (MP) workloads on an ESX server was very strongly discouraged, especially in systems with a lower number of cores. This was due to the “strict co-scheduling” mechanism used in ESX 2.x. The “relaxed co-scheduling” mechanism introduced in ESX 3.x that allows for far greater flexiblity in scheduling UP and MP VMs. To quote the blog entry:

Relaxed co-scheduling significantly reduces the possibility of co-scheduling fragmentation, improving overall processor utilization.

I was not aware that the vCPU scheduling mechanisms had changed between 2.x and 3.x, so this is good news.

However, the real treasure in this blog entry—for me, anyway—was the link to the in-depth performance documents being posted in the Performance Community Forum. Here are some very detailed documents that provide outstanding information on topics like:

• the VMkernel scheduler
• how ESX co-schedules SMP VMs (more detailed than the blog entry)
• using (or not using) hyper-threading with ESX

Overall, this is a ton of good content which will be very helpful to anyone seeking to solidify their knowledge of the ESX platform.

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.

I ran into a recent issue with a customer who was having problems getting VLANs to work as expected with ESX. The basic scenario was that ESX would refuse to work properly with a VLAN that was marked as the native (or untagged) VLAN. This was causing no end of grief for this customer.

I’ve discussed VLANs extensively—first with this blog post, then again here, and again in this SearchVMware.com tip—so I was confident that I could help the customer resolve this issue. Granted, the customer was using Nortel switches, with which I am completely unfamiliar, but a switch is a switch, right?

Not quite. While the configuration seemed correct in all ways, it turns out there is a checkbox somewhere labeled “untag-default-vlan”. If this box is not checked, then the default VLAN gets tagged. Since ESX wasn’t configured with a VLAN tag, then it doesn’t see the network traffic. Once that box gets checked, then the default (or native) VLAN doesn’t get tagged and will be properly recognized by an ESX port group without a VLAN tag configured.

So, if you’re using Nortel switches and having problems with VLANs, double-check this setting.

A lot of virtualization-related articles were published while I was in Orlando at Microsoft Tech-Ed 2008. Here are a few that caught my attention over that time period as well as in the last few days.

• Rich Brambley over at VM /ETC is on a roll with a couple of good articles, one on VMFS storage sizing for performance and one on downgrading the VM HAL after P2V. The title for that second article was “How to P2V Multi-processor servers to Uni-processor VMs”, and I was hoping that it was a new trick with VMware Converter or some other P2V tool that would actually take care of the HAL for me. Alas, not this time. Rich’s article is useful information nevertheless, don’t get me wrong. I am curious, though, as to the source of Rich’s storage sizing recommendations. Rich, can you share where you derived those recommendations?
• Ryan Arneson shares some of his experiences in using an X4500 with ZFS as an NFS datastore for ESX. Ryan’s post reminds readers of the some of the requirements for using NFS with ESX, so readers new to that sort of configuration may find it helpful.
• Gabe brings us, courtesy of this VMware Communities thread, some information on getting DRS VMotion information from the VC database. That’s handy. In an earlier article, Gabe also weighed in on storage sizing as well. This seems to be getting quite a bit of attention recently (gee, I can’t imagine why). Readers, I’d love to hear your thoughts on storage sizing approaches, algorithms, etc. Please share them in the comments!
• I found this article discussing NFS vs. CIFS for VMware. At first I was a bit baffled, but then I realized the author must have been talking about VMware’s hosted products like VMware Server not ESX. Anyone else tried this?
• Rick Blythe aka VMwareWolf posted an article about VM customization failing after VC 2.5 upgrade. Fortunately, the fix is easy; just download and install the correct version of the Sysprep tools and put them in the right location on the VC server. The details are all provided at his site, so check that out.
• The VMware Fusion Team announced support for running Mac OS X Leopard Server in Fusion 2.0 back during the WWDC, but it seems that Parallels may have beaten them to the punch with an actually shipping product.
• Schley Andrew Kutz has released a version of the VI Toolkit for .NET that supports mocking. More information on mocking the VI Toolkit is available here. I haven’t seen any sample taunts yet. (You’ll get that in a few minutes.)

In addition, as a follow-up to my Tech-Ed coverage of the Microsoft Assessment and Planning (MAP) toolkit, I found these two articles in my list of “things to blog about”:

Microsoft Assessment and Planning How-To Series: Part 1 (Server Virtualization Candidacy Reporting)
[VIDEO] Microsoft Assessment and Planning How-To Series: Part 1 (Server Virtualization Candidacy Reporting)

Note also that the beta program for MAP 3.1 is already running; this version will add support for Hyper-V. More information here. (I couldn’t remember if I stated anything about this my Tech-Ed session liveblogs.)

That about does it this time around. Thanks for reading!

Last week Network World published an article about Sanbolic’s announcement to provide VMware virtual machines access to shared application data using their shared file system, Melio FS. This announcement was made last week at Tech-Ed 2008 in Orlando, FL. Sanbolic also announced support for running Melio FS in VMware Infrastructure 3 (VI3) environments as well. Unfortunately, the information in these announcements seems to have gotten jumbled while being reported and now these two very different uses of Sanbolic’s products are being intermingled when they really shouldn’t be. Allow me to explain.

Readers who followed my Tech-Ed coverage will recall that I had the opportunity to speak one-on-one with Jeff Woolsey, Senior Program Manager for Virtualization at Microsoft. One of the questions I asked him during that session was about Hyper-V’s requirement of one VM per LUN when Quick Migration was involved. Quoting from my summary of that discussion:

Rather than spending time creating a clustered file system, Microsoft chose instead to allow storage partners to create those solutions. He referred me to Sanbolic, whose MelioFS clustered file system and LaScala volume manager will allow Hyper-V deployments to store multiple VMs on a single LUN visible to all hosts, just like VMFS.

Prompted by Jeff’s response, I went to the Sanbolic booth at Tech-Ed and spoke with Bill Stevenson, Sanbolic’s executive chairman and the same person quoted in the Network World article. Bill and I spoke at length and he shared a lot of information with me about Melio FS, LaScala, Hyper-V, and VMware ESX.

Here’s what the Network World article says about Sanbolic and Hyper-V:

Sanbolic for now isn’t providing shared access to application data on Hyper-V, because Microsoft’s upcoming hypervisor lacks the ability to store virtual machine images in shared SAN volumes, Stevenson says.

The first part of that statement is true. Sanbolic hasn’t announced support for allowing Hyper-V VMs to use Melio FS to access shared application data. However, Sanbolic has announced support for running Melio FS (and the La Scala volume manager) on Windows Server 2008 Hyper-V hosts. This allows the VHDs for multiple VMs to be co-located with each other on the same LUN but still be able to take advantage of Quick Migration. It eliminates the “one VM per LUN” limitation, essentially.

With regards to the second part of that statement, I believe that the reason Sanbolic hasn’t made any announcements regarding Melio FS inside Hyper-V VMs is that we don’t yet know how Hyper-V is going to handle physical disk access. We know that there is support within Hyper-V for NPIV (refer to this Tech-Ed session liveblog), but I saw only a single mention of physical disk access—what I believe to be the equivalent of VMware’s Raw Disk Mapping. Will Hyper-V support the equivalent of RDMs? I don’t know, and Sanbolic probably doesn’t know, either. Until they do know, they can’t run Melio FS inside a Hyper-V VM.

And that’s the crux of the VMware-related announcement: it’s not about running Melio FS on the ESX hosts, but instead about running Melio FS inside Windows-based VMs on ESX. Sanbolic requires direct disk access and VMware provides that ability via RDMs, so Sanbolic can allow organizations running VMware to utilize VMFS as the shared file system for the hosts and Melio FS as the shared file system for the guests. By the way, I’m waiting to hear back from Sanbolic as to whether physical mode RDMs or virtual mode RDMs are supported. I’ll post an update here when I find out.

The confusing part about the Network World article is that it doesn’t, in my opinion, clearly delineate these two very different use cases. The idea of running Melio FS on the host vs. running Melio FS in the guest are two very different use cases with very different results, and the article seems to intermingle the two more than it should. This statement especially confused me:

Gartner’s Paquet says VMware could choose to provide the shared access to application data within the virtualization engine, making the Sanbolic technology unnecessary. VMware officials did not respond last week whether they will take such a step.

What, VMware writing a share file system for Windows so that Windows VMs could access SAN LUNs concurrently? What sense does that make? Believe me, there are some real geniuses over at VMware, and I would imagine that there is some magic that can be played at the virtualization layer that would make guest-level shared file systems unnecessary. But would that “magic” be efficient? Would it be worthwhile to develop when companies like Sanbolic already have this offering? Not in my mind. The purpose of VMFS is not to provide shared file system functionality for VMs; it’s to provide that functionality for hosts.

To summarize:

• In a VI3 environment, you use Melio FS (and La Scala, if you desire) inside a VM with an RDM to allow multiple VMs to access a SAN LUN concurrently. This is something that NTFS can’t/doesn’t do, so Melio FS provides that functionality.
• In a Hyper-V environment, you run Melio FS (and La Scala, if you desire) on the Hyper-V hosts. This allows multiple hosts to access a SAN LUN concurrently, eliminating the “one VM per LUN” limitation imposed by Quick Migration.

Anyway, this can be a fairly complicated topic to understand and I wanted to try to help explain it as I understand it. I hope this has been helpful. If I’m wrong, feel free to correct me in the comments. Thanks!

UPDATE: Sanbolic updated me to inform me that they have thus far only tested physical mode RDMs with Melio FS. They are currently in the process of virtual mode RDMs.

I came across an interesting paper discussing how various virtualization environments protect well-behaved VMs from misbehaving VMs. The paper is available here.

In the tests described in the paper, researchers used virtual machines on Xen 3.0 (the open source hypervisor not the commercial XenServer product, as far as I can tell), VMware Workstation 5.5, and “Open Solaris 10” (quotes mine). As pointed out in the paper, these three environments represent paravirtualization, full virtualization, and OS virtualization (or containers). I’m not sure if the researchers actually meant OpenSolaris; I suspect not since that’s a very recent release. Instead, I believe they probably just meant Solaris 10. On Xen and VMware Workstation, both running under Linux, they used Linux-based VMs; on Solaris, they used additional instances of Solaris. Each VM or instance ran Apache 2 and was tested using physical clients to connect to the HTTP server in each VM.

The results are interesting; VMware showed the best protection of well-behaved VMs from a misbehaving VM, followed by Xen with Solaris Containers providing the least protection. The level of protection was tested using a memory consumption stress test, a CPU stress test, a disk I/O stress test, and a network I/O stress test. I’d encourage you to have a look at the full paper for all the details.

These results are very interesting, but I wonder how much the results would change if we were to use VMware’s ESX server product line instead of one of the hosted products like VMware Workstation? As a product representative of “full virtualization” solutions, I’d be curious to know if the results seen with VMware Workstation were also seen with ESX.

In any case, the results are a validation of what we, as consultants, have been talking about: full virtualization provides the best isolation of well-behaved workloads from ill-behaved workloads, preventing a workload in one VM from affecting other workloads due to mishandling of CPU, RAM, disk, or network resources. As the researchers conclude in the paper, “…it is clear that VMware completely protects the well-behaved VMs under all stress tests. Its performance is sometimes substantially lower for the misbehaving VM, but in a commercial hosting environment this would be exactly the right tradeoff to make.”

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!