Date: Wed, 17 Oct 2007 15:16:43 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: martinko <gamato@users.sourceforge.net> Cc: freebsd-arch@freebsd.org Subject: Re: kernel level virtualisation requirements. Message-ID: <200710172216.l9HMGhbd067251@apollo.backplane.com> References: <470E5BFB.4050903@elischer.org> <470FD0DC.5080503@gritton.org> <20071013004539.R1002@10.0.0.1> <47107996.5090607@elischer.org> <ff5vdh$jol$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I think the reason you see such a huge degree of virtualized and
para-virtualized environments these days is simply because service
providers can no longer provide all the web services individual sites
need as a single common set of managed applications. All they can do,
pretty much, is allow their users to install and run the application
set they need to run for their site. In fact, there are several layers
of middle-management web site providers available today who simply lease
virtual machines and build a custom environment for their clients.
Virtualization neatly solves what would otherwise be a nightmare
for providers.
Despite the loss of performance you get in a virtualized environment,
it is far, far easier to manage memory and I/O resources in a
virtualized environment then it is in a jail, and far far easier to
migrate such environments between physical machines without having to
worry about introducing incompatibilities or having to force your
customers to upgrade and deal with the inevitable snafus that crop up
when that happens. You don't even have to worry about upgrades to
physical hardware... the virtual environment doesn't have to change by
a single byte. I remember upgrading machines at BEST Internet.
It was a nightmare to deal with all the customer snafus that occured
every time we upgraded something. I wish we had virtualization back
then.
Security is also a whole lot easier to manage with a virtualized
environment. You basically just run the virtual kernel (strangely enough,
in a jail usually), and give the user root inside it. The user can
install whatever he wants... whatever services, applications, etc.
And if the user crashes a virtual kernel or creates a security issue,
just that one user is effected, not the other 19 on the physical box.
Dealing with break-ins which effect dozens, hundreds, or thousands of
users is a nightmare for any provider. Dealing with a break-in which
effect one user and is basically the user's own fault is not.
Global resources are a lot easier to manage in a virtualized environment.
For example, it is impossible for a user running in a virtual kernel
to use any more real system memory then was assigned that virtual
kernel, and all I/O resources basically devolve down into just one or
two points inside the virtual kernel (network I/O and 'raw disk' I/O),
which are similarly ultra easy to control. If that user blows up his
own system, or causes it to start page-thrashing, it is his problem
to solve and will not effect the other 19 users on the box. Thrash
a machine in a jailed environment and the whole machine goes to pot.
'limit' and other resource controls just don't work well in a jailed
environment if the intent is to avoid thrashing other environments
running on that same machine.
What a jailed environment offers is performance. There is no question
about that. If I were designing a turnkey server with a very specific
application set I would probably use jails. But if I wanted to hand an
actual login to a user in an environment where the user needs to run
many potential services or backend run-times, I would choose a virtual
kernel hands-down above a jail solution. Jails are useful for many
things, but most of those are not things which require scaling.
Hardware is cheap, manpower is not. Being able to avoid hiring a single
employee is worth 20 machines at least, and hardware costs scale far
better over time then employee costs. That is what is driving the
market for virtualization. Performance doesn't enter into the equation
most of the time. For anyone doing a serious deployment this is a
huge deal. A jailed environment just doesn't offer the same level of
control or management, no matter how much you try to separate resources
out inside the kernel.
Similarly, storage is almost free these days. Storage is not an issue,
so the replication of environments and application installs is not an
issue. Not any more.
The only real limitation for a virtualized environment is physical memory,
and that has already been taken care of with the money you save by not
having to hire that extra employee.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710172216.l9HMGhbd067251>