Articles by slowe

Readers who have installed and configured VMware ESX in a storage area network (SAN) environment know that all the VMware ESX servers in an environment need to see the same LUNs with the same LUN IDs. This is necessary in order to avoid problems with VMFS resignaturing.

Similarly, readers who are familiar with configuring and managing NetApp storage arrays will know that NetApp igroups (initiator groups) are the mechanism whereby a host—or a group of hosts—are granted access to see a particular LUN on a specific LUN ID.

Because the igroup configuration is core to how LUNs are presented to hosts, and because VMware ESX has specific configuration requirements with regards to LUN presentation, it’s necessary to take a closer look at strategies for how NetApp igroups should be configured and managed in a VMware ESX environment. There are basically two approaches:

1. Create a single igroup for all the VMware ESX hosts in the environment, then map LUNs to LUN IDs using that single igroup.
2. Create a single igroup for each VMware ESX host in the environment, and then map LUNs to LUN IDs for each igroup.

Obviously, each approach has its advantages and disadvantages:

Using a Single Initiator Group:

• Adding a new LUN to the entire group requires only one change: mapping a LUN to a LUN ID for that one initiator group.
• Similarly, only a single change is required to remove a LUN from the entire group of VMware ESX servers, by removing the one group-LUN ID map.
• Storage administrators and VMware ESX administrators are assured that all the VMware ESX hosts will see the same LUNs with the same LUN IDs because all the hosts are placed into one group-LUN ID map. There is very little possibility for error.
• On the downside, there’s no way to prevent a particular host from seeing a particular LUN. All hosts in the initiator group will see the LUN.
• The storage administrator kind of “loses track” of which hosts see the LUNs. Because all the initiators are thrown into the same group, it’s more difficult to track down which hosts see a particular LUN. This is less true for iSCSI—where the hostname is often embedded in the IQN—but more prevalent for Fibre Channel, as the initiator group only contains World Wide Port Names (WWPNs). Mapping WWPNs to actual servers requires some additional steps.

Using Multiple Initiator Groups:

• It’s easier for storage administrators to match hosts to initiators, because each host has its own initiator group on the NetApp storage array.
• The storage administrators and VMware ESX administrators have greater flexibility in determining which hosts see which LUNs, so it’s possible to have a LUN visible to some VMware ESX servers and not others.
• There’s greater room for error in accidentally mapping a LUN to a different LUN ID for one or more of the hosts, which can lead to an inability to access the VMFS datastore on that LUN.
• Multiple changes are required to add or remove a LUN from the entire set of VMware ESX servers; each LUN will have to be individually modified.

One could also mix-and-match these approaches to a certain extent; for example, an organization could employ a “hybrid” model that has the full set of base LUNs exposed to all servers via one large initiator group, but other LUNs exposed on a more granular basis via smaller initiator groups. Since an initiator can be included in more than one initiator group (as long as the initiator group uses the same OS type), this gives some additional flexibility.

I guess the purpose of this post is less to explain the different ways of using initiator groups and more to try to generate some discussion around the various ways they can be used. Hopefully, the initial explanation will be helpful to some readers, but what I’d really like to see is some more advanced and experienced readers sharing their strategies for using initiator groups in larger VMware ESX environments and what “best practices” they may be employing.

Back in July, I was recognized as #2 in the “Top 10 blogs that VMware administrators must read.” I was honored by my inclusion in that list along with some very well-recognized names.

A couple of weeks ago, I was recognized again in a list of “Top 10 Storage Blogs (non-vendor)” over at Storage Monkeys. And included at #2 as well—what a surprise! I am very honored to be on this list and most certainly did not expect anything like this.

Now, if I could just figure out how to get to #1…

Some while ago, it was noted that Cisco was signed up as a participant in Microsoft’s Server Virtualization Validation Program (SVVP). Many wondered why—what did Cisco have up its sleeve?

This article today from InfoWorld seems to make the story much clearer:

With the new product, called Windows Server on WAAS, branch offices can host services locally including Active Directory, Microsoft Print Services, Microsoft Domain Name System Server and Microsoft Dynamic Host Configuration Protocol Server. That can improve performance for branch workers and reduce costs related to wide area network connectivity and branch systems management. An IT administrator can remotely manage the Windows Server functions using Microsoft System Center.
 
Cisco used embedded virtualization technology in its appliance to enable Windows Server 2008 to run on it.

Now, the real question is this: what “embedded virtualization technology” did Cisco use?

UPDATE: Based on the comments below, it looks like KVM is the technology Cisco chose to virtualize Windows Server on WAAS. Very interesting!

Microsoft announced the release of Hyper-V Server 2008 today via a blog post on the Server and Tools Business News Bytes blog (man, is that a mouthful!). Available “later today” as a free download, Hyper-V Server is Microsoft’s “bare metal” hypervisor-based virtualization product. Although the blog post said later today, I tried downloading it right away anyway, but the download link apparently doesn’t yet work.

<aside>I don’t know that it can really be called a “bare metal” virtualization solution since it still does require Windows Server 2008, albeit a heavily stripped-down version, in the parent partition in order to provide I/O drivers.</aside>

Hyper-V Server 2008 can be downloaded here.

Technical resources for Hyper-V Server 2008 can be found here.

I just got word this morning from a co-worker that HP has announced it will buy LeftHand Networks for about $360 million. The official HP news release can be found here on the HP web site.

It will be interesting to see how HP integrates the LeftHand offerings into their existing storage product lines—the All-in-One (AiO), Modular Smart Array (MSA), and Enterprise Virtual Array (EVA) product lines. Based on HP’s news release, it looks like they envision the LeftHand products fitting in between the AiO/MSA at the low end and the EVA at the high end.

With the purchase of EqualLogic by Dell and today’s acquisition of LeftHand by HP, it looks like all the small iSCSI-focused startups are getting acquired by system vendors. Does this signal a trend?

For those that follow me on Twitter, you may have noticed that I purchased and installed OmniFocus for iPhone over the weekend. If you are a GTD lover and a Mac user, you are no doubt familiar with the “regular” OmniFocus application from The Omni Group. I’ve been using OmniFocus for quite some time now (I wrote about that back in February), and I was really excited about the possibility of taking it mobile with me on my iPhone.

A number of things stand out after using this combination for a few days:

• I’m too cheap to pay for a MobileMe subscription, so I just setup a WebDAV site on my hosting package. It’s not the greatest in the world (I’d prefer to run WebDAV over SSL on the standard HTTPS port, for example), but it works. However, less technically inclined folks would have had a problem without a MobileMe subscription. I hear that Omni is planning on adding Bonjour syncing support, but I can’t imagine that will be anything other than Wi-Fi only.
• It takes quite a while to sync my iPhone after a day of working in OmniFocus on my MacBook Pro. This is even with a good 3G data connection. I don’t know that there’s anything that can be done about this, nor is this even anyone’s “fault”; it’s just an observation I’ve seen thus far.
• In an effort to stretch the battery out as long as possible, I generally keep Location Services turned off. This limits some of the location-aware functionality that OmniFocus for iPhone features. Since the release of the 2.1 firmware, my battery life has improved; perhaps I can turn on Location Services and not suffer too much of a battery hit. If anyone has any feedback on how much of a hit it is to keep Location Services turned on, I’d certainly appreciate it.
• I’m finding that my current set of contexts don’t necessarily translate well to the iPhone version. Currently my contexts are more for grouping similar tasks than by location or resource; I’m thinking I may need to move to more location-based contexts. I’m not yet sure how that will work or how I’ll integrate that with my workflow. Again, suggestions are more than welcome.

Overall, I’m pretty pleased with OmniFocus for iPhone. (In fact, I’m pretty pleased with my iPhone in general.) There’s always room for improvement, but given my experience with The Omni Group with applications like OmniGraffle and OmniOutliner I’m quite confident that the application will improve over time.

This edition of Virtualization Short Takes is mainly a collection of items from the VMworld 2008 conference in Las Vegas. Some of these are session transcripts from various bloggers; some are just VMworld-related blog posts.

• Blogger Rich Brambley has some great coverage of various VMworld sessions: BC3819, BC2370, PO2575, and VD3261, among others. Excellent work, Rich.
• The whole vStorage thing has prompted quite a flurry of attention. I’ll probably tackle this myself soon, but for now I’ll just comment on what others are saying. Stephen Foskett comments that “VDC-OS has legs!”, meaning that this vision has some substance behind it; I agree. He also has a nice collection of related vStorage links. There’s also Chad’s discussion of vStorage, which is quite helpful coming as it does from the perspective of a storage vendor seeking to take advantage of these new capabilities. Mark Twomey also had a little bit to say about vStorage as well.
• Michael Keen’s VMworld 2008 analysis provides a good review of VMware’s announcements and strategy in relation to the competition and the partner and the partner ecosystem.
• UK magazine Computing was disappointed by Paul Maritz’s vision and the VDC-OS announcement, expecting “more granular details on how the initiative would actually take off.” Personally, I felt that Steve Herrod’s keynote on Day 2 did a fairly reasonable job of showing the mechanics behind Paul’s vision.
• Redmond Developer News provided another view of VMware’s VDC-OS announcement, although to be honest the article looked pretty much like every other discussion of VDC-OS, with the same interviews of the same people.
• Kevin Fogarty’s take on the VDC-OS pitch, published on CIO.com originally, then republished by Computerworld and touched upon briefly by Tarry Singh, is that it’s “too much of a leap of faith for me and, I suspect, most of the VMware faithful as well.” I get that VMware’s new strategy is radically different from anything VMware has done before; up until now, their releases have been product-focused. Now Maritz is driving the company with a long-term vision that will be fulfilled through a series of product releases. It’s a shift in thinking, and one that will require an adjustment. Personally, I don’t like the new VDC-OS branding and I told VMware straight up that it would be confusing to customers. Nevertheless, the vision behind the brand is, in my opinion, solid and so I must disagree with Kevin’s analysis.
• Massimo thinks Paul plagiarized the VDC-OS concept. If he were serious (which he’s not), he actually has a pretty good case.
• Eric Sloof has a bit of additional Cisco Nexus 1000V coverage.

I think that about wraps up my collection of VMworld 2008-related links. If I’ve missed anything significant—and I’m sure I have—please feel free to add it in the comments.

My wife, a couple of the kids, and I just got back home after watching Fireproof at the local movie theater. You’ll recall that I first mentioned Fireproof back in August, and today was the opening day. I thoroughly enjoyed the movie. If you haven’t seen it, make plans to go see it right away! The movie is great, but the Message in the movie is even greater.

Having previously discussed Marathon Technologies’ everRun VM product in conjunction with XenServer HA as part of XenServer 5, I think that I have some useful information to bring to the recent discussion that has come to light about everRun VM vs. VMware HA vs. VMware FT.

Apparently, this discussion started with a blog entry by Marathon titled VMware FT - The Top Four Reasons it’s Kinda Sorta Fault Tolerance. Mike DiPetrillo of VMware responded from his personal blog, first tackling Marathon’s blog post and then again tackling comparisons posted on Marathon’s web site. Various others also weighed in, such as Duncan at Yellow Bricks and TechTarget’s Server Virtualization Blog.

I’ve spoken with the folks from Marathon a couple of different times about everRun and its functionality, so let me attempt to compare these three products—everRun VM, VMware HA, and VMware FT—with an eye toward understanding the differences between them.

• Marathon everRun VM provides two levels of protection: Level 1 and Level 2. Level 1 is basic failover, and is included in XenServer 5 as XenServer HA. In this regard, it is essentially the same as VMware HA in that it will restart VMs in the event of host failure. Both products calculate available capacity for failover but do not reserve those resources in advance; hence, neither of them can provide guaranteed failover. VMware HA seems to have an upper hand here because admission control can actually prevent users from powering on VMs if there are not enough resources to provide failover for that VM. From all information I have been able to obtain, everRun VM Level 1/XenServer HA lacks that ability, and it’s possible therefore that users could power on more VMs than the resource pool could sustain in the event of hardware failure. Both products should be considered “best effort” as a result. Users wanting to make comparisons between Marathon everRun VM and VMware HA should constrain their comparison to everRun Level 1. Otherwise, the comparison is not a like-to-like comparison.
• Marathon everRun VM goes on to add Level 2 protection for component-level failure. It’s true that this level of protection exceeds anything that can be provided via VMware HA today. With component-level protection, I/O to or from a failed storage device or a failed network device is transparently redirected to another host, where an identical VM environment has been established. Please note that the two VM environments are not both executing at the same time, but that resources on the secondary host are reserved and cannot be used by any other VMs. These resources include not only RAM, but also storage and networking. If there is a host failure, the VM is restarted on the secondary host. Because resources were pre-allocated, everRun VM is able to provide guaranteed restart on the secondary host. The functionality provided by everRun VM when configured for Level 2 protection exceeds any functionality that VMware HA has today.
• On the flip side, however, it’s also fair to note that VMware has not needed to provide component-level fault tolerance because they’ve supported storage multipathing and NIC teaming for quite some time. It’s my understanding that those features have only recently made it into the XenServer product line.
• VMware Fault Tolerance (FT) and everRun VM Level 3 are comparable. Both establish an identical VM on another host and keep that VM “mirrored” with the original VM. If there is a host failure, the “mirrored” VM will automatically take over right where the primary was when it failed. It appears that everRun VM might have an edge here because it again supports component-level failover, but given that neither product is available yet it’s still a bit too early to be making calls on which product is “better”.
• As for the “complexity” of one product versus the other, both have their own complexities. Marathon everRun VM requires a dedicated network link, called the “Availability Link”, in order to provide the component-level protection. I would assume the Availability Link will be needed for everRun VM Level 3 as well. That corresponds directly to VMware FT’s logging NIC. VMware HA does not require any special NICs or unique configurations; it’s unclear if the same is true for everRun VM Level 1/XenServer HA protection. I’ll have to call Marathon out on their knocks against setting up NIC teaming and storage multipathing; those tasks may be complicated in XenServer environments but are drop-dead simple in VMware ESX environments. The same goes for enabling VMware HA and VMware DRS.

As you can see, each product has its own set of strengths and weaknesses.

As a final note, as SearchServerVirtualization.com stated, comparisons between these two product sets are a bit irrelevent anyway: VMware’s functionality works only with VMware ESX environments, and Marathon’s functionality works only with XenServer. It’s not like users have to choose between them in the same virtualization environment.

I welcome everyone’s input and thoughts on this matter. Please contribute in the comments to this article.

While trying to clear out the backlog of articles that have accumulated in my Reading/Review context in OmniFocus, I’ve come across a number of Hyper-V articles on various topics:

• Robert Larson has a good article at VirtualizationAdmin.com that covers how to work with VLANs with Hyper-V. That includes information on configuring the parent partition to use VLANs as well as configuring child partitions to use VLANs. The title of the article is completely wrong for the content, but it’s still a useful article nevertheless.
• Via Ben Armstrong, I saw that there is a VMC to Hyper-V import tool. More information on the tool is available here. In addition, Ben also recently mentioned a Hyper-V VSS hotfix that fixes a problem with VSS failing to backup any VMs if even a single VM has a corrupt or invalid configuration file.
• And while we’re on the subject of migrating to Hyper-V from Virtual Server or Virtual PC, this blog post provides a checklist of things to do when migrating virtual machines from those older platforms to Hyper-V.
• Hyper-V’s Linux Integration Components—the paravirtualized drivers (or synthetic devices, or virtualization-optimized components, or whatever else you want to call them) that provide better performance under Hyper-V—have been officially released.
• By the way, this page provides a comparison of Hyper-V Server 2008 and more “traditional” implementations of Hyper-V with a full Windows Server 2008 parent partition.
• Looking for a comparison of performance with dynamic VHDs and fixed VHDs? Inquiring minds want to know! Get the scoop here.

That’s it for now. If any readers have other useful or helpful Hyper-V links, please share them in the comments.