As you may know, I've become a certified Macophile over the last year or so. My MacBook Pro is my main work machine, and I love it -- with a few very annoying exceptions (which I'll probably blog about before too much longer.)
You may have noticed that Parallels (formerly SWsoft) is similarly smitten with Apple. It is, by far, doing the most virtualization-related development for the platform. First there was Parallels, a virtual environment for Macs that allowed the running of Windows OSes. Parallels was a breakthrough product in the industry; suddenly, Mac lovers could use Windows-only products without buying a PC.
That innovation has continuted with the just-released, first-ever hypervisor for Apple's servers, known as Xserve. In the press release announcing Parallels Server for Mac, Serguei Beloussov, Parallels CEO, had this to say:
"Parallels Server for Mac opens the door for virtualization on Apple servers and represents an important step in delivering on our 'Optimized Computing' vision by adding hypervisor-based server virtualization. Parallels Server for Mac will be a catalyst in driving Mac server adoption in the enterprise, as it is the first product ever to enable IT professionals and developers to capitalize on the power of OS X Server while keeping the flexibility to run Windows and Linux workloads."
There's lots of marketing hype in that statement, of course, but there are some interesting nuggets. One is that Apple and Parallels both have a vested interest in seeing Mac server deployment take off. Mac server is a marginal product in the market; in fact, it's quite difficult to find anyone who uses them (not impossible, before the flames start coming my way -- it just takes some serious research).
Will the ability to run Windows, Linux and so on drive adoption? We'll see; frankly, I'm skeptical. Xserve has been around a long time, and it's much more niche-y even than Macs, which for years have been relegated to art departments (although that's certainly been changing lately.) But if Xserve works as well as most Macs, they may start catching on. I'd like to hear from admins out there -- would you try an Xserve? Have you? Let me know.
In the meantime, work continues on Parallel's bare-metal hypervisor for Windows, Linux and other servers. Still in beta, this will be the real product to watch, as it's in more direct competition with ESX/ESXi, Hyper-V, XenServer and all the Xen variants from Virtual Iron, Red Hat, Novell, Oracle, Sun, and all the rest. When it comes out, Parallels and Sun will be the only vendors with products that do both OS and hardware virtualization (OS virtualization essentially clones copies of the OS, allowing multiple copies of, for example, Windows Server 2003 to run on a single physical box with almost no discernable performance degradation). Will that edge help out those vendors? We'll see.
Posted by Keith Ward on 06/24/2008 at 12:48 PM5 comments
I recently
blogged about the issue of "NIC teaming", also known as "NIC bonding", and the fact that it's allegedly missing from Hyper-V. Virtualization blogger Scott Lowe originally reported this, and we have confirmed that it is not a feature of Microsoft's new hypervisor. Here's the response, from Microsoft's Robb Mapp:
"NIC Teaming is a capability provided by our hardware partners such Intel and Broadcom. Microsoft supports our partners who provide this capability. This is true whether the customer is running Windows, Exchange, SQL Hyper-V, etc.
We'll have a detailed KB article about this coming out soon."
So Hyper-V doesn't do it, but you can buy products that do it -- although not all of them do. I went back to my go-to virtualization analyst, Chris Wolf, for his take on how this could affect the market for Hyper-V. Here's what he said:
"This is a pretty big issue, and one that I've been raising with Microsoft for months. NIC teaming is a requirement in virtualization deployments, in my opinion, as there should be no single points of failure that could potentially disrupt access to several VMs.
Now if you think about it, the need for teaming is nothing new to Microsoft. I've been deploying Microsoft clusters with teamed NICs for years. The NIC vendors would support their own teamed configuration and that was good enough for me. So basically, it's the same issue with Hyper-V. Microsoft may not officially support the teamed configuration, but the vendor that provides the NIC driver will. Microsoft even has a KB article about this.
Compare this to storage and there are a lot of similarities. Microsoft officially supports multipath storage drivers, and when it comes to troubleshooting low-level storage issues, the storage HBA vendor will get involved. It should be the same process with network interface vendors.
Comparing VMware to Microsoft, I can team any two NICs using VMware ESX, so I don't need to go out and buy specific NICs that include a teaming driver. The Microsoft implementation would require a pair of NICs and a teamed driver, so the NIC teaming would be managed independently of the hypervisor.
At the end of the day, I can achieve the same level of network availability in both hypervisors (ESX and Hyper-V). However, Microsoft can do more in this area. Since I can still achieve teaming in Hyper-V, I don't see the issue as a deal breaker. I'm sure Microsoft will do more with teaming down the road, but Hyper-V is a first generation product, so it's fair to expect Microsoft to take some time to develop such features. In the meantime, the features are there, but just implemented differently."
My take: NIC teaming should be included in the base hypervisor, period. If Hyper-V truly wants to compete with ESX -- and more competition for VMware is something everyone should want -- this needs to be added as a feature.
Posted by Keith Ward on 06/18/2008 at 12:48 PM9 comments
A blog reader recently brought this
Microsoft policy to our attention. It has to do with support for its products running in non-Microsoft virtualization software, e.g. Virtual Server 2005 and the upcoming Hyper-V. The key sentence is this:
"Microsoft does not test or support Microsoft software running together with non-Microsoft hardware virtualization software."
Sounds a little scary, doesn't it? So, if you have an Exchange server running on ESX, VMware's hypervisor, Microsoft won't help you when it stops working? To use the cliche, "What's up with that?!"
The comment from the reader is as follows: "M$ refusing to
support anything running on VMware!" He, uh, isn't happy (you can always tell when someone is mad at Microsoft, because they use the dollar sign in place of the "s").
Well, the policy sounded a little harsh to me as well, although there's also a lot of language about the ways Microsoft will help, even if you're running on XenServer, Virtual Iron, other flavors of Xen, VMware, etc. It normally involves being able to reproduce the problem independently. Again, here's the techno-babble from the support doc:
"Where the issue is confirmed to be unrelated to the non-Microsoft hardware virtualization software, Microsoft will support its software in a manner that is consistent with support provided when that software is not running together with non-Microsoft hardware virtualization software."
After wading through that lilting prose, it seems to say that Microsoft will actually support its stuff -- to a degree. But I was a little confused, I must admit, since those statements seem somewhat contradictory. Thus I turned to my on-call guru, Chris Wolf, to get his analysis of what it all means. His response, reproduced in full, is enlightening:
"This isn't a big deal. Microsoft provides best effort support for VMware
environments, which is similar to what other vendors do. Most vendors do not
test their software on multiple hypervisors; it's too expensive to build and
deliver such a test case, so testing on one hypervisor is usually the norm.
For a software vendor to officially support anything, they have to either
have a formal testing/validation program for the hypervisor/platform or have
a formal support handoff agreement with the hypervisor/platform vendor.
Microsoft doesn't officially support their software on homegrown white box
servers (since there's no formal testing/validation or support agreement in place), but people have been deploying such configurations for years.
Last week Microsoft announced their Virtualization Validation program, and
VMware was conspicuously absent from the list. I talked to VMware about this
and VMware is actively working on joining the program. So I think it's safe
to expect and official VMware support agreement somewhere down the road."
In other words, Microsoft's support pretty much falls in line with the rest of the virtualization industry. And full support is on the horizon, which is good news for all you VMware admins out there.
Posted by Keith Ward on 06/17/2008 at 12:48 PM5 comments
There's no doubt that the word "virtualization" is a mouthful, so nicknames are invariably going to happen. In fact, the URL for this Website is horribly long; but in the age of URL hoarding, the choices for pithy URLs are shrinking. In the magazine, we call virtual machines "VMs", and internally, the magazine is usually designated "VRM" to save on hand cramps.
Microsoft has gone the same route, shortening, for example, "Virtual Machine Manager 2008" to "VMM 2008" in most instances. And, of course, there's Hyper-V, probably Microsoft's most cool product name ever. "Hyper-V" is just fun to say. Now, Microsoft has shortened another hideously long product name, and given it strong echoes of Hyper-V. Microsoft Application Virtualization will informally be known as "App-V", a name that's sure to stick; I know that's how I'll always refer to it on second reference henceforth.
This entry on the App-V blog (formerly the SoftGrid blog) has more details. So the last vestiges of the Softricity acquisition in 2006 are swept away in the new naming scheme. SoftGrid is out; Microsoft Application Virtualization is reserved for black-tie events; and all the hep cats will be calling it App-V from now on.
Now the three major players have cool application virtualization names: ThinApp (VMware), XenApp (Citrix) and App-V. Let's see if the products live up to their names.
Posted by Keith Ward on 06/17/2008 at 12:48 PM0 comments
So your soon to be ex-junior administrator, who was watching
"Trapped in the Drive-Thru" rather than paying attention to his job, accidentally reformatted an important RAID drive, containing lots of mission-critical data. And guess what -- the backups, which you check about every other year, are corrupt.
No problem, say you -- just send it out to your data recovery vendor. But your heart sinks when you check the disks in that RAID and find that they were VMFS disks; the VMware file system. Your vendor doesn't do recovery of VMFS volumes. You make some calls; no one else seems to, either.
Gulp. You start looking for your visa, hoping it's up to date in case you need to leave the country in a hurry.
Don't worry. Just call Kroll Ontrack, and breathe a sigh of relief as you realize you won't soon have to learn how to speak Portuguese. Kroll is, according to executives, the only company out there that does data recovery of VMware data. Kroll writes internal tools (not for commercial sale -- yet) developed for dealing with the specific issues surrounding virtualization.
Kroll has done data recovery for many years, but only recently saw its requests for retreival of VMware data take off. In fact, business has increased "ten-fold" year over year, according to Jeff Pederson, manager of data operations. A key turning point was the release of ESX Server 3.0, followed by 3.5. As they gained in popularity, says Robert Bloomquist, principal data recovery engineer, so did the need for virtualization-specific data recovery.
Over the last several years, as its tools have improved, Kroll has significantly shortened the time needed to recover data. "In as short as a few hours we can do remote work; more common is a day or two. In extreme cases, it can end up being a week," says Bloomquist. "One good thing about putting money in tools is that the software's much better. We average a couple of days on big jobs."
Pederson says that about data on about 10 percent of the drives Kroll works on can't be recovered. But he and Bloomquist don't blame VMFS for the errors -- it's almost always user error that results in the need for their services, they say.
Kroll does data recovery for other virualization platforms like Microsoft and Xen, but they are more standard operations, since they don't use a proprietary file system. Pederson says that his company would consider making the VMware-specific tools available commercially, if there was a demand for it. "That's something we'd be open to. It would depend on what kind of opportunities there are in the channel for us."
In the meantime, make sure to have proper high-availability and backup procedures in place; although it's good for Kroll, it could be bad for your career prospects. And it wouldn't hurt to buy a Portuguese-English dictionary.
Posted by Keith Ward on 06/13/2008 at 12:48 PM2 comments
Blogger
Scott Lowe is doing some fantastic work at Tech-Ed this week, covering the virtualization-related sessions. Very enlightening, informative stuff.
He's also uncovered what he sees as a big potential problem with Hyper-V: the lack of NIC bonding. NIC bonding, also known as "NIC teaming," "port teaming" and other names, means to link two NICs so they appear as one device, increasing their speed and redundancy.
Lowe learned in the session that Hyper-V doesn't support NIC bonding at all. His take on the impact this could have?
"In my opinion, that is a huge problem. How does one go about providing network link redundancy to guests hosted on Hyper-V? Surely using Failover Clustering and Quick Migration isn't the answer here, is it?"
Lowe contacted one of the presenters and asked for more information on the issue, but as of this writing, he hasn't blogged about getting a response.
What's your take on this? Is it as big a deal as Lowe seems to think? Also, if you work for Microsoft and have any insight into this issue -- if NIC bonding really is unavailable, and if so, why -- please contact me.
Posted by Keith Ward on 06/12/2008 at 12:48 PM5 comments
Microsoft has issued an update for the ungainly-named System Center Virtual Machine Manager 2008. The last beta of VMM 2008 was
released April 29, and this minor upgrade essentially adds one thing: support for Hyper-V RC1, which was previously
missing. That meant you had to work with RC0 if you wanted to use both products together.
A couple of things to note, according to this blog:
- All hosts must be running Hyper-V RC1
- You won't be able to add Hyper-V hosts running RC0 once you've updated VMM 2008, so be sure it's what you want
- A restart may be required after the install
Go here to get the VMM 2008 update.
Posted by Keith Ward on 06/11/2008 at 12:48 PM0 comments
Security company Tripwire has released a limited, but very useful,
utility for checking the security of VMware's ESX hypervisor. Best of all, it's free.
The tool, ConfigCheck, looks for vulnerabilities in ESX, the kind that generally occur through misconfiguration of a server. The svelte, 11 MB download makes it easy to set up and try. After running the program, it compares data with VMware's published security guidelines and alerts admins if there's a problem.
ConfigCheck was developed in concert with VMware, and runs on Windows. In a press release, Raghu Raghuram, vice president, products and solutions for VMware, described the challenges virtualization administrators face with security:
"Two of the most important security issues customers should focus on are misconfiguration and patching. With VMware Update Manager which we introduced earlier this year, we have simplified the management of our customers' Virtual Infrastructure by automating the deployment of patches and updates. Tripwire ConfigCheck now adds to that capability by providing customers with a tool to proactively compare their VMware configurations with proven, hardening guidelines developed using best practices from the most business-critical VMware Infrastructure deployments."
A test results in one of three outcomes: "Passed", "Failed" or "Unavailable". Passed means that it meets the VMware guidelines for hardening the server. Failed, of course, means the opposite. Unavailable means that the test couldn't be completed for some reason.
Being free means there are also limitations to what it can do. For instance, only ESX 3.5 can be tested; you're out of luck if you have an earlier version, although Tripwire indicates on its Web site that it will be adding more versions in the future. Also, nothing beyond ESX can be tested -- no VMs, guest OSes, applications or other parts of the infrastructure. You'll need to get Tripwire Enterprise for that.
Tripwire says that it will be supporting ESXi, the embedded hypervisor, in a future release. If you've used ConfigCheck, or are going to, please let me know your experiences.
Posted by Keith Ward on 06/11/2008 at 12:48 PM2 comments
VMware has updated a number of important products in the last week; no major changes, but worth knowing about.
Most exciting from my point of view is the first VMware-guided release of the product formerly known as Thinstall, before the company was bought by VMware in January. ThinApp 4 plugs a hole in the VMware's product line, providing application virtualization. A virtualized application is encapsulated and isolated, making it unlikely to cause conflicts with other apps on a server or desktop.
There was a bit of cynicism over the name ThinApp when it was first announced, with some pundits wondering whether it was trying to capitalize on the recently-announced name for Citrix' app virtualization offering, XenApp, but it didn't amount to much in the blogosphere. ThinApp 4 will be available within a month, according to a VMware press release. It's not cheap, at $5,000 a pop, but that does include VMware Workstation, which is generally regarded as the best PC virtualization product out there, and 50 licenses.
At the end of May came the first refresh of VMark, VMware's benchmarking software. VMark exists to analyze the performance of apps running in virtual environments. VMark 1.1, which is free, includes a number of updates for 64-bit operating systems, including Windows Server 2003 64-bit, and Novell SLES (SUSE Linux Enterprise Server) 10 SP1.
VMark first came out about a year ago. One reason this update caught my eye is that we're preparing an article on performance benchmarking in virtual environments for our July/August issue. The article makes the point that although VMark is a good starting point to use, it's only the beginning of what you should be doing in the planning stages of your virtual infrastructure. The story also examines and explains the pitfalls of performance benchmarking, and how difficult it is to do.
The last announcement surrounds Virtual Desktop Manager 2.1, an update of the connection broker for its virtual desktop infrastructure (VDI). Desktop Manager does just what it says: it manages the connections between the backend VDI servers and remote users, helping them get connected and stay connected, as well as managed.
The main upgrade is to scalability; VMware says in a press release that admins can run "up to 5,000 concurrent connections per cluster of Virtual Desktop Manager servers and provides enterprises the ability to scale to tens of thousands of desktop connections through the use of multiple clusters." In addition, hundreds of desktops can be assigned a single storage pool, making use of storage virtualization technology and, ultimately, more efficient use of storage.
Virtual Desktop Manager 2.1 is available through VMware's sales channel now.
Posted by Keith Ward on 06/10/2008 at 12:48 PM5 comments
Hi gang,
Our second print issue is on the streets; those of you with subscriptions should have your copies by now. For others, I wanted to give you a rundown on some of my favorite stuff (we put all the print copy online).
If you're considering ESXi, VMware's embedded hypervisor, you'll definitely want to check out this myth-busting article by Andrew Kutz. He pops the hype bubble surrounding ESXi. He likes ESXi -- a lot, in fact -- but it's not exactly on a par with flight as a history-changing technology.
Our fantastic cover story package tackles the hardware side of the virtualization industry. I've mentioned before how virtualization is of equal importance to both hardware and software companies, making it unique in that sense. Editor-in-Chief Doug Barney took on the gargantuan task of writing about the major hardware vendors and their different approaches to virtualization. We have limited space in print, so we've put greatly expanded versions of his stories online. Check out his coverage of IBM, Sun, HP and Dell. It's simply the most exhaustive coverage of hardware OEMs and their virtual strategies you'll find in one place anywhere.
Those of you fairly new to virtualization will want to look over Peter Varhol's piece comparing three commercial server virtualization products -- VMware ESX, Citrix XenServer and Virtual Iron. Peter, as always, has interesting insights into the strengths and weaknesses of each, giving you a head-start in your search for the right product for your environment.
One story you absolutely don't want to miss is Greg Shield's column on disaster recovery strategies with virtualization. DR, in my opinion, is the single most important reason to implement virtualization. Greg, our 'Virtual Architect', shows you different levels of DR at different price points, letting you choose the solution that best fits your budget.
Also featured is a case study about how The George Washington University went to a full-scale VMware setup, and how the school is saving money by taking advantage of the technology. I love case studies, because they show you how this stuff works in the real world.
There's lots and lots more, as well. I'm awfully proud of this issue, and the folks who helped put it together (Doug, Tom and Wendy, this means you!) Please let me know what you think of our coverage -- and don't be afraid to tell me what we can do better.
Posted by Keith Ward on 06/09/2008 at 12:48 PM0 comments
A number of core VMware products have earned the highest security rating possible from the
Common Criteria security evaluation. According to a VMware
press release, VMI 3, ESX and VirtualCenter have earned Common Criteria Evaluation Assurance Level 4 (EAL4+).
EAL is a substantive certification, and EAL4+ is its highest rating. That's good news for VMware, since virtualization security is a growing concern for businesses as the technology moves into the mainstream.
Many moons ago, when I was working for sister publication Redmond magazine, we ran an article on Common Criteria certfication from our then-security guru, Roberta Bragg. She had some interesting things to say about CC, that are relevant to this discussion. These comments are referring to an older Windows product that earned the rating, but are equally applicable to VMware:
"Be careful, though: CC validation doesn't mean that Win2K is a secure operating system. Rather, it means that it's a securable operating system. Just as an MCSE certification doesn't guarantee that the holder is competent to administer Windows enterprise networks, the CC certification doesn't guarantee that any implementation of Win2K is secure. Like previous government product-specific security standards -- E3/F and C2 -- CC certification certifies that the product, when configured as it is in the evaluation, meets some security profile. It says, in effect, that Win2K can be secure if properly patched and configured to specific criteria."
In other words, don't assume that just because you're using ESX, VMI or VirtualCenter, that you're secure, since it has the rating. Due diligence is absolutely necessary. "Secure" and "securable" are related, but very different, concepts.
Posted by Keith Ward on 06/04/2008 at 12:48 PM0 comments
Simon Crosby, CTO of Citrix and former head of XenSource, responded via e-mail to several recent
blog entries of mine regarding the new trademark policy surrounding Xen. He thinks I'm off base and wants to give the Citrix take on the issue. As always, his comments are worth reading. Here they are, reproduced verbatim:
"1. The new TM policy is approved by the Xen Advisory board, not just Citrix. That's Intel, Red Hat, Novell, Sun, IBM and Citrix.
2. It was available for community comment for a substantial period, and all of that feedback was used in the final version.
3. We are in the unfortunate position that for our commercial product is named XenServer. So any other XenABC risks confusion. We therefore requested the community to respect that, and I've seen no negative response. Importantly all of the other Xen based products are named differently today, so there is no incumbent competitive issue.
So it's not "Hands off" but "hands on, go for it" with clarification as requested by the community. The AB has done a good job here"
Crosby makes good points, but I differ with him on the following:
First, the Xen Advisory Board (AB) does a fine job by all appearances, but it's made up of commercial companies. Naturally, those organizations would support a company's trademark policy, since it doesn't affect them in any way. My point was more about open source developers and how they'll be affected.
"All of that feedback was used in the final version" only means all feedback was considered; it doesn't mean that it was all accepted. I'd be interested in knowing how much feedback there was, and how much of it was against the policy released a few days ago.
Finally, Simon writes "We are in the unfortunate position..." I wonder if that's just poor phrasing on Simon's part. After all, the name was chosen by Citrix; is that an admission that it was a mistake to go with the name?
If the open source and virtualization communities had full input into the policy and seem to be happy with it, it's hard to argue with Citrix's position. Again, I put it to the readers: Tell me what you think about the policy.
Posted by Keith Ward on 06/04/2008 at 12:48 PM0 comments