Citrix Announces Agreement to Acquire XenSource 86
An anonymous reader writes "'Citrix has signed a definitive agreement to acquire XenSource a leader in enterprise-grade virtual infrastructure solutions. The acquisition moves Citrix into adjacent and fast growing datacenter and desktop virtualization markets.'
For nearly $500 million, including about $100 million of unvested options, Citrix would be purchasing VMWare's closest competitor in the server virtualization market, with XenEnterprise v4 offering technology similar to VMWare's flagship product — and arguably overtake them as a combined solution, as VMWare offers little in the realm of application and desktop virtualization. Though subject to the customary closing conditions, both boards of directors have approved the transaction, and the deal is expected to close in Q4 of 2007."
Xen not "closest competitor". (Score:5, Informative)
Xen is, of course, not VMWare's "closest competitor". Microsoft has over 25% of the market with their Virtual Server product. After that, Virtuozzo has the next largest deployment.
C//
Re:kvm (Score:3, Informative)
You've been reading propaganda again (Score:4, Informative)
Virtuozzo isn't a server VM, it's an app VM.
VMWare and Xen are a bit different. VMWare has lots of depth and maturity. Xen has nearly similar compatibility but has fewer API sets to work with it. Xen's app hosting capabililities are more astute and highly competitive with Microsoft's SoftGrid and Citrix's remote apps. That's why Citrix bought them.
Virtuozzo has roots in site hosting, and it's maturity with Apache also extends to OpenVZ.
Re:If they're smart, they'll be more open with Xen (Score:3, Informative)
Sure, getting a Xen-capable Linux going is simple. In recent Linux distributions it's just a matter of selecting a couple packages for installation.
Installing client VMs (DomU in the really intuitive Xen nomenclature) can be easy, and can be a MAJOR pain in the ass.
Installing the trivial 'ttylinux' was painless. Specify the ISO, start the VM, and it's done before it starts.
Installing CentOS was not so simple. Install failed completely and silently. Dig around for support info.. there are hundreds of sources, each very superficial and fragmented. Finally find a random user report on a forum recommending to set the OS type to Solaris for the install. Finally works.
Installing Windows was also not a simple process. The first stage of the install was easy. Point it to the ISO, and let it fly. But, after the system reboot, re-mounting the ISO and getting the VM to find it proves to be very difficult. Finding obscure command-line options gets it moving in the right direction (although, the documented parameters fail to actually mount the ISO), after much more searching and experimentation, I was able to get it to recognize the physical disk in a CD drive and complete the install.
Installing a pre-built Xen "virtual appliance" also proves to be near impossible. This is partly because the suppliers of those appliances have little or no Xen documentation (one can only assume this reflects their userbase.. VMWare documentation is more plentiful). And, it is partly because of the configuration issues in Xen. Is this a paravirtualized image or a full hardware virtualized image? What type of disk image does it use? Again, back to hunting down configuration information all over the Internet. Many suggestions, few actually work to do anything useful. I still haven't gotten these working.
Then, with the OS's that do successfully install, using them can be troublesome. In both Windows and Linux GUI environments, there is some quirk with the mouse pointer that causes the shown VNC pointer to be offset from the GUI pointer by varying amounts (yes, I did disable mouse acceleration. Problem decreases a bit, but is still quite bad). There are many other quirks, which often don't respond well to the documented fixes: making a VM actually reboot - rather than just stopping when rebooted, requiring command line intervention to restart the VM; automatically starting VMs on reboot of the hypervisor host (Dom0). Getting a hung VM to correctly respond with status incormation or actually quit when told to. And many more issues...
Managing and monitoring multiple VMs on a host is also quite weak on Xen, and the strength of VMWare ESX server. It's all done through an intuitive GUI, tons of status and monitoring information is available, and there are bunches of APIs to extend beyond what ESX does itself.
> When I compare that to the hell that was setting up (and remotely administering) VMWare, I realise I'd never want to go back. And that's without even getting into VMWare's habit of eventually swallowing up all RAM and swap on the host until everything grinds to a clanking halt.
The only way I could see Xen, in its current state, being superior is if you absolutely had to use only text based console management. You can, and often must, manage xen from the terminal. If you want to use a GUI, to ease management and hide the details of all those command-line tools, Xen just doesn't measure up.
I have seen some third party projects that aim to make better Xen management tools. Red Hat has a Python based GUI that is better than nothing. And, as I mentioned, XenSource's proprietary tools are not bad. The good news is, that Xen could easily be very competitive.. the hard work is done, the virtual machine works. Wrap a GUI around it, and it becomes available to 10x as many users.