Roy Schestowitz wrote:
> Xen GUI In Fedora Core 6
>
> ,----[ Quote ]
> | The new version (6) of Fedora Core, which became available for
> | download in November, shows that major Linux vendors see the
> | importance of virtualisation and virtual private servers in
> | years to come.
> |
> | Xen in Fedora Core 6 comes with a GUI named Virtual Machine
> | Manager.
> `----
>
>
http://www.webpronews.com/expertarticles/expertarticles/wpn-62-20061129XenGUIinFedoraCore6.html
Did you notice how he carefully avoided his own implied question of what the
difference between the two are.
That being that Xen uses complete resource issolation, meaning you have your
own running kernel. Whilst openVZ uses a shared kernel.
Both have implecations for the people offering the host.
A single shared kernel is easier to manage (for the host), plus the users of
it get more resources, because the resource split between virtual hosts
need not be so stringently assigned. The down side is that the host has to
pre-compile in any modules that might be required by it's users. So the
list of what is available on your host server tends to be fixed and very
unlikely to include the rarer used modules at all, or, extras that are
needed require a special request since the extended kernel would have to be
compiled and tested on the none-live mirror server before being set free as
the live kernel.
While Xen's total issolation mean that the host can let it's users select
their own kernel, compile in their own modules or cut it down to bare
minimum. (remember that we are only talking about the kernel, you can still
select from a range of distros). But that means it can be much more
difficult for the host to manage your server for you, you are often on your
own when you take up Xen plan after the initial setup, other than they will
take your system back to a previous backup.
So both have their good and less good points, but the distinction doesn't
take away the fact that each has it's own root access and everything from
kernel up is within the virtualisation, including some conf's that the
kernel and kernel modules make use of in openVZ.
I also think there is value for these on company servers. Server hardware is
cheap enough that departmental servers and clusters/mirrors can be built
for very little cost. But we all still tend to have one or two very
powerfull servers, then a few less powerfull, maybe just standard desktop
hardware, for the mirrors. Which might be a mixture of distros, which in
itself is also a good thing, reduce the risk of a bad update affecting all
servers.
By using xen you can have the departmental servers side by side on the most
powerfull of your servers, each with the kernel that is a mirror of it's
own mirror/cluster set built on lesser machines.
Or, if all of your machines are the same, a blade rig for example, then
openVZ would likely be a better set up.
Remember though that you can get a great deal of seperation with no
virtualisation, simply by using the standard user system of your Linux.
This means that you can have a single place to maintain the underlying
Linux and applications, whilst giving departmental seperation. It is just a
matter of having multiple admin levels each with their own 'bin' for local
applications and 'etc' for their own prefered configs.
root-adminsales
-adminaccounts
- ....
Though the way virtualisation is building momentum, it seems now to be the
better option even if your seperation only needs to be fairly minimal.
|
|
