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 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.

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!

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.