Virtualization.info, Gridtoday, the eGenera website, and a lot of other sources reported that eGenera has received a patent for an all-in-one N+1 tiered disaster recovery solution that combines grid technology and virtualization to provide a hardware-neutral Disaster Recovery product that takes your entire data center and encapsulates it. This is an awesome product because it can greatly improve DR and perhaps make DR more accessible to smaller businesses, but it’s not patent-worthy. It smacks of a way to stifle competition and generate revenue via patent suits over product sales. Or it may just be that patent itself is just pointless. I’m not sure which case is more true, honestly. It all depends on if it’s challenged, and how.
DISCLAIMER: I’m not a lawyer. In fact, I don’t ever even want to be a lawyer. I’m happy as an IT Director and SysAdmin, and don’t want to ever be a source of legal advice. The below is informed opinion, not legal advice. Tell it to the Judge. Under the recently-relaxed “Obviousness” rule that governs patents, a patent is useless if the idea behind it is only an obvious improvement over an existing idea. eGenera’s patent seems to fall squarely under that rule, from the language in their patent application. Just for kicks, I read it, and will quote it. Under the quotes I’ll comment on what this means, in my not-so-humble and not-so-attorney opinion.
It starts out with a SCREAMING cry of obviousness in section 1…
“A method of providing processing resources to respond to a fail-over condition in which a primary site includes a configuration of processing resources, comprising: generating a specification that describes a configuration of processing resources of the primary site; providing the specification to a fail-over site having a configurable processing platform capable of deploying processing area networks in response to software commands; using the specification to generate software commands to the configurable platform to deploy processing resources corresponding to the specification; wherein the processing resources at the primary site include a plurality of independent processing area networks and wherein the specification describes only a subset of the plurality of independent processing area networks. “
That, my friends, is commonly known in the IT field as a failover cluster. The link even defines the N+1 method that eGenera is using in its product. The short of it – You have multiple boxes on a network that are mirrors of one another. One fails, another takes over its role. There’s usually hardware or software in-between that keeps things synchronized and detects the failure. This part of the patent is worded to be host-, network- and processor-inclusive, which would be obvious because most clusters are situated on networks, don’t necessarily need to run the same processors, and are hosts. The “big” improvement is in the use of the term “site” – where the product is meant to restore an entire data center’s configuration. In the press release, this means that if you have four data centers and one disaster site, if any one data center fails, the disaster site takes on the complete configuration of the failed site (i.e., all nodes, network configurations, etc.). This is a huge step forward in disaster recovery, but it’s not patent-worthy because there are a zillion ways to do this.
Here’s one – If you put 100% of your data center(s) onto VMware’s VI3 with shared storage, and had a huge WAN pipe between each site to cover the overhead, you would have this “network in a box” N+1 approach because ESX provides virtual network switching and virtual guest machines, without having to worry about the value of N except in scalability terms. The same is true of most Xen-based products, like Virtual Iron. I’ve been doing this for years on a much smaller scale. If my main data center drops off the face of the earth, I’ve got all of my critical systems in VMware, with snapshots and backups of the machines and the storage they’re on, as well as configuration of the virtual switches. If the worst happens and my data center goes down, my staff and I drive over to a remote office, restore, and have exactly what eGenera is talking about – a complete restoration of all configurations at a remote data center. The method – backing up virtualized systems. The process – recovery to virtualized systems. It’s not as slick as an automated system, but we’re getting to the point that eGenera talks about in its patent (thanks to an Open Source project called Openfiler and some extra bandwidth on our WAN to handle sending snapshots between sites rather than driving tapes around).
Soon, the site backups will be automatically done over WAN links, meaning that when something fails, I switch over to the DR network and everything comes back online from the virtual machine snapshots / backups. It won’t be long after that until we automate that switchover, and have exactly what eGenera is describing. It’s been a long process because that deep a level of DR isn’t a critical requirement to the business, but it was obvious where we wanted to go, and obvious how we needed to get there – through the use of virtualized host and network environments.This brings me to the next few sections:
“2. The method of claim 1, wherein the act of using the specification to generate commands to deploy processing resources is in response to the receipt of a fail-over condition.
3. The method of claim 1, wherein the act of generating includes specifying data specific to device configuration at the primary site.
4. The method of claim 1, wherein the act of generating includes specifying management information relevant to the primary site. “
Summary – we’re patenting how we’re going to do what we claim, how we’re going to encode the configuration, and how we’re going to send notifications when it kicks off. All irrelevant if the concept of the patent is obvious. Also these are all in themselves obvious – any virtualized system has to have information on configuration of the underlying virtualized hardware. Any cluster sends notification on a failure of a node. Any mirrored port has awareness of the cache in its partner port. Outside of the patent office, and in the IT office, this stuff goes without saying.
Next up, section 5… this is identical to section 1, except the last few words: “wherein the specification describes all of the independent processing area networks.”. There’s no significant difference as to obviousness here – it’s just the parts of the patent which are different from each other that are referenced. This is a matter of scale – rather than a “subset of the plurality” (English: part of the whole) this is a “master file” of the entire environment being monitored. It adds grid technology into the mix, another obvious case for virtualization.
Section 6 changes the plurality part to “a minimum configuration of processing resources at the primary site”, which is just saying that the system will use the most efficient (i.e., minimal) configuration possible to get the job done. Duh. Do I have the same number of VMware hosts at my remote sites? No, I don’t. I don’t even always have the same builds or even the same versions! Do I have all of the same configurations? No. Can I really bring up 100% of my data center at a remote site? Sure. And eat a performance bullet on the servers.
So what would I do? I would bring up critical systems only – Active Directory, DNS, Email, mission-critical apps. My Jabber server would stay down. My dev environment would stay down. I would run the minimal configuration I need to get the business working. Can it get any more obvious than “if I don’t have the all the resources I need, I’ll get by with what I have, the best that I can”?
The seventh section tacks this part onto the end: “…wherein the primary site includes a configurable processing platform having a pool of processors and wherein the act of generating includes specifying information descriptive of how the processors are pooled at the primary site. “A pool of processors. Also known as a computing grid. And it goes on to describe having a documented system for how that grid works, and tying that to the application. This is truly obvious. If you have a system, you document it. If you have an automation system, it’s documented, and it uses documentation on how the system it automates functions. This sort of thing has been around forever.
On a non-grid level, Detroit has been outsourcing human labor to robots using this exact methodology for decades. On grids, this is how they work… regardless of distance. Each node is aware of each other node, and so the grid has an internal documentation of the pool of resources that are available.
Section 8: “The method of claim 7 wherein the act of generating includes specifying data to describe logical partitioning of processors and interconnectivity into logical processing networks. ” This is the virtualization component. In virtualized systems and virtualized DR products like VMware’s VMotion, this is a core component of how the systems work to provide fault tolerance. The service console knows what virtual machines are out there, and what host systems are out there. It has descriptive information about the resources, how they’re pooled, and how they’ll be moved in the event of failure. eGennera’s idea is obviously a small improvement to the process, applying it towards a virtualized grid concept, but it’s not a huge leap forward (again). Virtualized grids have already been in the works for some time. See here and here.
Section 9 states:
“A system of providing processing resources to respond to a fail-over condition in which a primary site includes a configuration of processing resources, comprising; a computer-readable specification that describes a configuration of processing resources of the primary site; a configurable processing platform capable of deploying processing area networks in response to software commands; logic to generate software commands to the configurable platform to deploy processing resources corresponding to the specification; wherein the processing resources at the primary site include a plurality of independent processing area networks and wherein the specification describes only a subset of the plurality of independent processing area networks. “
In other words, the systems to the methods described above.
Section 10 is similar, switching plurality for totality like sections 1 and 5 did. So they’re going to build a computer system to do what DR specialists and Virtualization specialists have been doing for some time now, only under a commercial brand. Seems obvious to me.
The next sections reference art that I won’t reprint or link to here, as they’re not very original. In fact, the art is as obvious as the concept for this patent. I won’t need the art to describe the obviousness of some of what is printed in the text. Here’s my favorite example so far:
“To date, a considerable body of expertise has been developed in addressing disaster recovery with specific emphasis on replicating the data. Processor-side issues have not received adequate attention. To date, processor-side aspects of disaster recovery have largely been handled by requiring processing resources on the secondary site to be identical to those of the first site and to wait in standby mode.”
Processors have not received adequate attention because in virtualized environments, they are largely irrelevant as long as you’re not mixing widely different types (such as AMD and Intel). You do not need to maintain identical processors, or quantities of processors, or anything like this. I can restore the virtual machines running on my Intel dual core Xeon servers on my Intel single core Xeon machines with a great deal of flexibility amongst processor family types. Does it matter if one is 2.8GHz and another is 1.6GHz? Not really. The processors at my remote sites aren’t sitting in standby mode, either. They’re running apps on the local servers. They are live, running, and chugging along. They’re ready to load up more virtual machines and take over the load at any time.
So, considering the giant logical fallacy presented here, I’m left wondering if there’s even a need for this patent. I could get REALLY brave and open up a huge pipe to the remote sites and run shared storage and VI3 over my WAN… assuming I had unlimited funds for a 1+gig WAN pipe, and then I could get away with having no other process beyond VMware’s built-in recovery with VMotion, CB, and HA.
And yes, I recognize that not everything can be virtualized, but in all honesty, what eGenera proposes is no less disruptive and impactful to a data center than that of virtualization. The rest of the document gets into specifics and details that are very patent-sounding, detailed diagrams, how the parts of the product will work, a definition of PAN (processor area network, as opposed to personal area network), how control nodes manage the environment, etc.
Here’s the summary: We’re going to build a set of interconnected boxes that will virtualized your environment down to the tiniest level. Then when something fails, we’ll load up resources at a remote site and make it all come back online.
Can it get any more obvious than this? It seems like eGenera is using patents to block competition. It strikes me that the folks as eGenera collectively went “Oh, I have an idea to improve this and this and this. It seems kind of logical, but we should patent it so nobody else with the same idea can compete with us without licensing from us”. It’s a great product, but it uses existing technology and existing ideas about how to use technology to provide a product that is already out there, just not in a commercial pacakage. I personally don’t think the patent will stand up to challenge, given the recent changes to patent law.
I am writing this little op-ed piece in lieu of a full-blown obituary. Why? the market speaketh, and it declared hardware-based appliances dead. Like dinosaur-dead, dead. Sure, some of the specialists may survive, just like the Crocodile and the Shark have managed to keep evolving and avoid the big-rock-hit-earth-make-dino-dead era.
From the Metaphoric Journal-Register:
Appliance, Mr. Hardware B. passed away on June 19th, 2007. Mr. Appliance was renowned for the uncanny abilities to bith create controversy and save money. During his career he was the muscle behind most modern network equipment, many network security services, the complete setup of numerous small and home office businesses, and a host of other specialized IT functions. His ability to reduce cost and complexity is duly noted and many have expressed great appreciation for his efforts. While many did not agree with his one-device-one-task approach, his fame and popularity continued to rise even in conflict. He is survived by one child, a Ms. Virtual Appliance. Said Ms. Appliance in her eulogy “My father was of great service, and it is with great pride that I take up his mission. I promise to provide the public with the same services, the same muscle, and the same fiscal attention. Furthermore, I plan to take his vaunted career one step further and sever my ties to proprietary equipment. I know Dad would have been proud of this decision, which will give greater economic and administrative freedom to you, my beloved supporters.”
Why am I, at the risk of sounding like the world’s biggest (well, you can insert your own word here), being so haughty as to declare the hardware appliance dead? Because hardware is mattering less and less in the commodity server market, and it’s bleeding over into the commodity appliance market. Hardware appliances were great – they did one task (or one category of tasks) very well, had minimal overhead, and were often cheaper than a full-blown server-and-software solution. Who uses their own server-based routers? Not many people. And yet Cisco has gone quite far in undocking much of IOS from the hardware, a move that (among other things) is good for virtualization. If you’re looking for a security appliance, you could buy a Symantec hardware appliance, or you can download any number of similar appliances from VMTN. Inboxer makes an email archival hardware appliance. They also make a virtual appliance. Need a NAS or iSCSI SAN? These even come in virtual appliance flavors like the Openfiler appliance – and they’re great for taking those old hanging-chad JBOD storage arrays off their legacy hosts, linking them up on a single host, and converting to centralized storage. Zeus‘ network traffic monitoring hardware appliances are now available in virtual appliances. This list of links goes on and on and on, and it shows an interesting trend; that hardware appliances are giving way to virtual appliances across most of the market.
And like the big-rock-hits-earth scenario, it’s happening fast. It’s not flashy like a meteor strike, but its just as quick – a few short years and hardware appliances will take a backseat behind the virtual appliance mammals. It’s cheaper for vendors to work on the software and not have to integrate it onto hardware that can change from revision to revision, and it’s as easy for customers to deploy and manage virtual appliances as it was to do the same with their dinosaur cousins. There’s even an extra layer of manageability with virtual appliances, since you can manage the hardware. A huge boon – business continuity. There’s more built-in DR/BC in virtual appliances that you just don’t get in hardware. Wanna be ready for DR? Ok, get all of those hardware appliances duplicated. Or take snapshots of your virtual appliances. Which is easier? Which is less expensive? Which is more rapidly verifiable?
What about the performance hit? In all but the most demanding cases, such as a core switch or the load balancer for the storage arrays of a Fortune 500’s ERP systems, the 10% degradation of performance caused by virtualization is of minimal importance. These then, are the crocs and sharks of the new era – highly specialized, long-term survivors that will continue to proliferate when the rest of market enters the long sleep of a the virtual asteroid impact.
Mitchell Ashley’s blog on the same subject takes a similar look here, and even uses some of the same analogies I use (I was quite grumpy when I found that mine wasn’t a very original thought, but such is what it is).
A few more links for the weary web-traveler:
Alessandro Perilli, SearchServerVirtualization.com contributor and owner of virtualization.info, has a fantastic virtualization-related jobs section on his site. At the time of this post positions are mostly for VMware gurus, but a few are for sales. Locations range from coast to coast in the US.
Check out the virtualization.info job board now — but not while your boss is watching… 😉
Another great site if you’re looking for virtualization-related jobs is indeed.
If you’re still not convinced you should switch jobs, vi411.com has a post from January 22, 2007 that says VMware salaries are 115% higher than average data center salaries.
In Monday’s newsletter column, I included a question to our Linux users: Do you prefer Xen, VMware or Virtual Server, and why?
It’s only Monday afternoon, but I’ve gotten some interesting responses. Chris, the CIO for Oxford Archaeology: Explorying the Human Journey, wrote:
In response to your question, we prefer VirtualBox, which offers a degree of flexibility that only VMware VI3 gets close to. Without the entry costs! We currently are working with VMware server, and a lack of a Linux client for VMware VI3, along with its MS SQL dependency, prevented a planned migration to VI3. VirtualBox is the young upstart on the block; the list of features that it is currently lacking in comparison with ESX grows shorter at an alarming rate, it is cross platform, independent of hardware extensions (but can benefit from them), high performance, and remarkably quick to get to grips with.
David of Code No Evil, LLC wrote:
I prefer VMware because it’s a non-free commercial product with support. Microsoft, for example, doesn’t even list in their support site VPC 2K7 as a product. As for Xen, I’m rarely a proponent of the OSS community. As for VMware, my current support case just became a known bug # 154399. Nice to know that VMware was willing to admit a fault in their platform and intends on fixing it.
I asked him for clarification on the bug. Here’s what he said:
I am running Vista x64 on a Mac Pro. My intent was run XP off the hard drive from my old machine (a Dell Precision 340) in a USB enclosure using VirtualPC 2K7. VPC crashed every time I attempted to access the virtual drive (mapped to the physical drive). Support is non-existent for VPC 2K7 because Microsoft doesn’t even list it as a product at the support website. I even reached out to the “Virtual PC Guy”0, but he was no help either. At this point, I figured that I should try VMware Workstation. At least if it didn’t work, I could open a support incident and I’d get some help. Well, long story short, there is a permissions issue that despite going back and forth with VMware tech support (in India none-the-less) was irresolvable even in VMware Workstation. The support overall was not bad. A few times I had to send an extra email to get them to wake up, but all-in-all it was satisfactory. The rep even called me because the issue became too difficult to talk about on the phone. Now, the real test is to see how long it will be before a fix is released. I would gather that it will be soon because this bug precludes anyone from using a VMware virtual drive instance mapped to a physical drive on Vista. I would, as a developer, classify this as critical defect.
Richard of OnX Enterprise Solutions Inc. wrote in suggesting Virtuozzo.
Chris, a system architect, wrote in with his preference for Xen:
I prefer Xen as it’s free on Red Hat 5 or SuSE 10 for Linux environments. EMC ESX rocks though if customers can afford with its small Linux Red Hat kernel and the various tools for both Linux and Windows environments. MS Virtual Server is better for test labs and with Microsoft platforms. I had a very bad experience with MS Virtual Server and NetWare systems although that’s another OS.
Possibly with improvements in MS Virtual Server there might be a point where if it’s free and if MS really does support Red Hat and especially SuSE underneath it that if it’s free with MS licenses that it could move up within the server marketplace.
More to come. In the meantime, what are your thoughts, readers?
In case you missed it, SearchServerVirtualization.com reported last week that VMware is developing an embedded “ESX Lite” hypervisor. And while VMware may have opted not to comment about it, the virtualization community has plenty to say on the topic. For one, Bob Plankers, over at The Lone Sysadmin thinks that ESX Lite could save him money on server hardware:
So you have an ESX server that doesn’t need local disk. That saves you $300 for a RAID controller and about $300 per 15K RPM 146 GB disk. For my RAID 1 + hot spare configurations that’s $1200. No moving parts equals theoretical better reliability, though flash drives have a limit to the number of read/write operations they can do over their lifetime. Also very little power consumption, and very little heat. Without all the extra heat from the disks you can reduce the number of fans in the chassis, which further reduces the price and power draw.
I for one, totally agree with this assessment. Spinning disk drives inside a server are a major bummer. Since the vast majority of ESX instances are already SAN-attached, why not go all the way and ditch the internal boot drives?
The flipside, said Fred Peterson, a system administrator writing on the VMTN message board, is that an ESX Lite appliance could not be reused like general purpose hardware:
Once it becomes “out dated” it has to be tossed, you wouldn’t be able to re-use as a test windows box or linux box or something. While not a bad thing, its life span to justify the upfront cost would have to be pretty good.
Over at MindSecure, a blog about “information security, virtualization, application delivery and storage,” ESX Lite is paired with Citrix Ardence, an OS streaming application, to positive effect.
Embedding ESX Lite in the hardware and using Ardence to stream the operating system would allow for complete hardware abstraction at the server and desktop level as well as the ability to remove spinning disk from servers and desktops, use solid state storage strictly on these devices, reduce storage utilization by using Ardence shared images, reduce cooling costs in the data center by using less disk, and many other advantages which these two solutions provide when paired together.
Scott Lowe on his blog says that ESX Lite has interesting competitive implications:
It’s smart because it derails Microsoft’s attempts to marginalize the hypervisor by bundling it with the operating system (via Windows Server Virtualization, aka “Viridian”). It’s smart because it expands the hypervisor market in new directions that no one else has yet tapped, helping VMware retain mindshare about its technical leadership and innovation. It’s smart because it’s the hardware vendors that have the most to lose via virtualization, and by partnering with them you remove potential future opponents.
But it’s a strategy that his his risks, he points out, namely, if the embedded hypervisor doesn’t perform as well as regular ESX, or if VMware loses visibility by going too deep under the hood.
Meanwhile, rumor has it the the original story has some inaccuracies in it, but like the old advertising saying (“I know half my advertising dollars are wasted – I just don’t know which half!” ), without official word, I can’t speculate as to what’s right and what isn’t. An obvious possibility is that Dell is not participating with ESX Lite, or that the effort is not limited to just Dell. My gut tells me the latter is closer to the truth. Any thoughts are appreciated.
In the past six months, every single IT exec or manager who discusses Linux desktops in a corporate setting with Nat Friedman asks about thin-client enviroments. That’s why Friedman — co-creator of the open source Ximian desktop and open source strategies CTO for Novell — predicts that desktop virtualization is going to take off faster than anyone has anticipated, and Linux desktops adoption is going to increase rapidly as a result.
“The pendulum is swinging back, and there’s an interest and need to centralize data for security reasons. IT managers and corporate execs don’t want people to walk out with laptops holding, say, millions of Social Security numbers.
Centralizing desktop management via virtualization and thin clients holds the much-desired promise of easier management, Friedman told me in a recent conversation.
There’s a desire to have lower-cost manageability by having all your applications running centrally and making thin clients into dumb terminals. Virtualization plays a role there, because on the server you could host thousands of desktops and virtualize those sessions so they’re all isolated from one another and run on an operating system that’s transparent to users. Or, you can use multiple desktop apps running on multiple operating systems. You can have computers running OpenOffice, Firefox, Microsoft apps and so on all this playing onto a single thin client. Virtualization makes it possible to dynamically allocate the resources for that. The desktop itself running virtualization locally developers do that. If you run Linux primarily and you want to run Windows for one app, virtualization is one way to get at that.”
In a virtual desktop setting, Friedman concludes, IT managers will be able to choose best-of-breed, easiest-to-manage and lowest-cost applications and operating systems. He thinks Linux and the desktop applications that run on that platform will gain from this interoperability.
I agree with Friedman’s views on how quickly desktop virtualization will be adopted. My team has been surprised by the number of IT managers who’ve expressed keen interest in moving forward with projects. I do think Linux will gain some users from this trend, but I think the key stumbling block will be getting IT shops to evaluate Linux-based desktop apps in the first place. Historically, they’ve taken the easy route, Windows and Microsoft apps.
What do you think? Let me know via your comments or an email to me at firstname.lastname@example.org.
For more of Friedman’s views on the desktop marketplace, check out this post on SearchEnterpriseLinux.com.
Does a grid by any other name smell as sweet? In years of covering grid computing technologies, I’ve seen the definition of “grid” changed to fit vendors’ products or the computing flavor of the month.
In general, I see the most basic function of grids is creating virtual communities of servers, applications and users. (Let me know if you see it otherwise.)
So, when I heard about virtualized service grids, I wondered if the “virtualized” moniker just get added because virtualization is hot right now? Or, is this a real next-generation grid model. Well, there’s a lot of activity in this space, as I’ve seen when reading Virtualization and Grid Computing blog, which has been a great resource for me. I see, too, that endors seem to be hopping on board. For instance, on the Inside HPC blog, I read that grid vendor United Devices is pursuing creation of virtualization products.
Recently, I asked Ash Massoudi, CEO and co-founder of NextAxiom, a virtualized service grid technology firm, some basic questions about virtualized service grids. Here’s an excerpt from our exchange:
What’s the difference betweeen traditional grids and virtualized service grids?
Massoudi: “The first difference is in programming models used by each. In traditional grid computing, it becomes a programmer’s responsibility, through the use of a dedicated library, to build an application that is designed to run on the grid. So, the programming model requires programming to the grid. In a virtualized service grid, software business and integration components are assembled using a Service-Oriented-Programming (SOP) technique that requires zero-knowledge of the computer resources. The application developer doesn’t need to explicitly identify the load and how it is allocated or to create work units accordingly. Each business or integration component is a service (implicit work unit) that can be composed of other services. The same Service Virtual Machine (SVM) that runs the final application will transparently externalize and distribute the service load across all available computer resources.
“Another difference is that service grid virtualization has a built-in concept of application multi-tenancy and thus favors scaling-up, through multiple-cores, over scaling out as is common with traditional grid computing.”
Why should IT managers take a look at service grid virtualization? What benefits can it bring to their companies?
Massoudi: IT managers should consider service grid virtualization since it reduces TCO across human capital as well as machine resources. Also, the business and integration services that are programmed and virtualized on the service grid provide a way to directly tie their efforts to the tremendous business value that they are creating.
What type of company would use service grid virtualization?
Massoudi: “You need significant IT expertise to run and operate a Virtualized Service Grid (VSG). Large enterprises who already operate data centers and need composite and flexible applications across their existing legacy systems should think of owning and operating their own service grid.”
What type of IT infrastructure is a good fit for service grid virtualization, and for what apps is it appropriate?
Massoudi: Multi-core processor architectures like the dual-core Intel Itanium 2 processor provide the most cost-effective and efficient foundation for Virtualized Service Grids. The more tenants you can run on a single machine the higher the efficiency of the service grid. Service grids are most suited for creating any composite business application or business process that needs to integrate across departmental application silos or enterprises.
My research continues, as does the job of separating the wheat (real technologies) from the chaff (vendor hype). If you’re involved with virtualized service grids — either as a user or developer — or other next-generation grid models, please comment here or write to me at email@example.com.
While browsing another blog, the famous virtualization.info, I came across a very interesting story of Parallels making an alpha code release of it’s new server-based product. As I mentioned in a slightly-off-topic post, my ears are perked because of the interest the Coherence has generated, with it’s seamless (almost Citrix-y) windows into the guest OS.
I’m really hoping to see what Parallels does with Coherence on the server level. While there are a plethora of ways to administer a heterogeneous server environment (ssh, rdp, vnc, mmc, e-i-e-i-o), Coherence in the mix of remote administration is an interesting proposal. How much further can it be taken – can it, instead of being host-based, become central-management-server based? Picture how Virtual Center allows remote administration of VMware virtual guest, from the virtual machine settings to the guests’ interfaces, plus all of the other settings involved. Add in a ONE-SCREEN management interface, with everything packed off to a Coherence Manager, and imagine how much simpler things can become. Application management tools that don’t work well over remote sessions, direct access to ini/conf/whatever files on a server without extra steps to get there, an organized toolset for administration that makes the mmc look tired… very interesting stuff.
Taking it to the next point, virtual desktops… Parallels supports DirectX and OpenGL (so does VMware’s Fusion, but I liked the beta of that much less than Parallels Desktop after putting them both through the ringer). That support makes VDI a lot close togetting over the hump of multimedia issues that bar it’s large scale adoption. Just as Citrix and other thin clients never reclaimed the desktop over PCs, I don’t doubt that virtual desktops will remain a niche market. I do think, however, that remote-coherence has the same opportunity as Citrix’s ICA (and competitors products as well) to be an excellent value-add for remote application deployment, right up to and including a full desktop. As it stands now, we have a number of users here who have very old applications that don’t work well under Windows XP, yet they just can’t go away (some are government-mandated apps), so we use VMware Player to dish them up in a virtual OS. I’d like to use a Coherence-like product instead, to eliminate a lot of the headache associated with end-user education and change management. To take it one logical step further, I’d like to use a Coherence-like server-based product, to keep those virtual machines off the local desktops and under my department’s management and deployment. If it means buying an Apple XServe or two to support it, so be it. We’re a mixed Windows, Linux, and BSD shop as it is, so that wouldn’t be a big deal in overhead and support. I imagine that’s the case in many environments.
I’m hoping for a sneak peak, being the Parallels geek that I am.
Improved configuration and lower costs are on John E Quigley II’s wish list for VMware ESX. In the meantime, Quigley is moving ESX to the back burner.
Today, Quigley — a senior network engineer — told me that his firm, Total Quality Logistics, LLC, will be migrating over to Microsoft Virtual Server 2005 R2, over the next 45 days. TQL — up to now a VMware shop — will only use ESX in the lab. ESX is too expensive to upgrade and requires more training and resources than TQL can deliver, Quigley said.
“ESX is an good product, but we are seeing issues with the configuration. And replication inside of VMware has always had issues. I have found problems with RPC communications, which affects Exchange and Active Directory. I found the issues during a prototyping exercise with Microsoft and some black belts a few years ago.”
At that time, Microsoft actually recommended using VMware to prototype the network configuration for an Exchange 2000/2003 rollout. Microsoft provided “a bunch of work-arounds for the known issues with the RPC issues.” He’s since replicated this environment with Virtual Server and “never saw any issues that they were apparent with VMware.”
“We are running several SQL servers sessions on ESX, and performance is not what we expected. I have created a new Virtual Server session for a new SQL 2005 server requirement, and it is outperforming the ESX session hands down. With ESX, we can’t easily import or export sessions, and a key lib file has died, and we are getting errors (on) all Internet searches…The only fix is to re-format and install ESX from scratch. It is locking the sessions up, and currently we can only admin from the Web console, as the management application crashes the ESX server.”
Quigley finds using Virtual Server simple and straightforward and gets plenty of documentation on configuration and tuning from Microsoft.
“Microsoft is willing to support many of the services that we are running under VS, not VM. Microsoft is willing to assist with consulting and services to better implement the product. The ROI on Microsoft is much better.”
Quigley says he’s pleased with Microsoft products overall, particularly the performance and troubleshooting capabilities of Microsoft AD/Exchange/SQL performance and troubleshooting
“I have been running the product since the Alpha, and really like the results that I am seeing. With the beta of what they are offering on the Longhorn, I see a lot of promise.”
After discussing this subject with John, I checked out Scott Lowe’s
How to Provision VMs Using NetApp FlexClones. Scott has some great info on working with ESX in Windows environments on his blog; but I didn’t find anything relating directly to John’s problems.
An article on SearchDataCenter.com, however, discusses the fact that “backing up VMware’s ESX Server is a fairly clunky process” and some of the third-party companies — like NSI Software Inc., Asigra Inc. and Vizioncore Inc. — that are releasing products that assist in replication on ESX.
Is anyone out there sharing John Quigley’s experiences with ESX configuration and cost problems or having no problems with those issues at all? Let me know by commenting here or writing to me at firstname.lastname@example.org.
PC blade manufacturer ClearCube has become the first non-server vendor to OEM VMware’s ESX hypervisor, which it will sell to customers implementing virtual desktop infrastructure (VDI).
As indicated in an article this April, ClearCube will sell ESX on a per user basis, rather than per host. This makes it cost-effective to run fewer virtual desktop sessions per blade, explained Tom Josefy, ClearCube director of product management. With this arrangement, IT managers can “guarantee a great end user experience but don’t need to have 30+ users per server to amortize the cost of ESX,” he said.
Josefy said ClearCube expects customers to be able to run up to about 12 VDI sessions on one of its R2200 PC blades, for a list of about $250 per seat including support. “At higher numbers it’s at least a 50% reduction in cost per seat,” he said.
Josefy also weighed in on Microsoft licensing for virtual desktops. Thus far, two licensing models have emerged. With Windows XP, the EULA requires each user to have a “unique set of bits” in the form of a full packaged product, he said. Microsoft’s Vista Enterprise Centralized Desktop (VECD) model, on the other hand, charges “per access device, per year” and is only available to Microsoft Software Assurance customers, typically large enterprises.
Small companies, Josefy said, “will like the Windows XP full packaged product,” even though “they do have to worry about when XP goes end of life.” Large companies, on the other hand, “are looking at the [VECD] program because it’s simple [for them,]” he said.
Of course, VECD requires that they move to Vista, which in ClearCube’s testing, has been shown to consume more resources. How much more? Josefy couldn’t say yet. “I don’t know it it’s a 10% penalty, a 20% penalty, or what.”