To read all comments associated with this story, please click here.
True, I'm hoping it will be merged soon - I'm looking forward to being able to run Windows on Xen to allow syncronisation with my MiniDisc player
I think at the end of the day, it depends on what you actually going to use virtualisation for - is it for legacy compatibility? server consolidation? if it is for legacy compatibility one would argue it is temporarily used for transition, but I question why, for example, would have multiple server operating systems for the back end. It sounds more to me like an IBM services wet dream of complexity when standardisation on all one server platform would yield lower costs in the long run.
Zones is OS virtualization, like OpenVZ, Linux-VServer, BSD Jails, Microsoft SoftGrid, etc. Instead of virtualizing the hardware so that multiple operating systems think they have a dedicated system, Zones virtualizes the OS (Solaris) so that multiple application containers think they have a dedicated OS.
Compared to hardware virtualization, OS virtualization is a solution to a different problem. It focuses on isolating and managing unrelated workloads that can share a common OS. It's lightweight and relatively simple to deploy.
However, it cannot be used where different OS flavors or releases are needed for each workload. Although it can be made very secure, most security researchers would agree that OS virtualization offers a greater opportunity to find attack vectors that escape a guest.
The issue that Ulrich raises is that the trend in hardware virtualization is for the hypervisor to be essentially a complete operating system, drivers and all. Xen initially tried to get around this by making one of its guests a privileged Dom0 that manages the hardware. However, the Linux-based Dom0 became less and less like vanilla Linux over time, posing serious maintenance and quality challenges.
Predictably, the commercial overlords of the Xen project dislike their out-of-tree Linux development model. They want to control their own destiny, and that means moving away from the Dom0 and greatly expanding the role of the hypervisor. This is the VMware approach, and XenSource is compelled to follow suit. Goodbye Xen. You'll never match up to VMware by flying solo.
Of course, KVM follows this model as well, with the hypervisor having direct control of the hardware. The difference is that it uses a vanilla Linux kernel to do so, taking advantage of 16 years of development, thousands of developers, and millions of users. The implications for compatibility, quality, and maintainability are enormous.
Without the KVM kernel module, Linux manages the hardware on behalf of userspace processes. With the module loaded, Linux manages the hardware on behalf of userspace virtual machines. It's a relatively minor change, so KVM will play just as nicely on your VT/SVM-enabled system as regular Linux.
I agree with Ulrich that Xen is a dead end and that VMware is making loony statements in the press. KVM isn't ready for prime time quite yet, but it will become the leading FOSS hardware virtualization competitor up against VMware and Microsoft. In a space characterized by demand for flexibility and concern over licensing, I expect KVM to hold its own quite nicely.
Let's not forget Qumranet, the stealthy startup driving KVM development. Besides Avi Kivity, they also employ Moshe Bar, the developer behind the late OpenMosix project. They're located right down the road from Intel's Israel campus, so it stands to question whether Qumranet is a prime acquisition candidate for a corporation that loves Linux and virtualization.
FreeBSD jails allow you to run different versions of FreeBSD inside each jail. So long as the host OS is newer than the jailed OS, everything will work fine.
You can run FreeBSD 7.x, 6.x, 5.x, 4.x inside a jail on a FreeBSD 7.x host.







Member since:
2006-05-09
This is a question: What about Solaris Zones?
Is Solaris Zones a KVM-like implementation?