The more I dig, the more it feels like Xen's definition of
paravirtualization trumps everything else. You know what, I never liked
the term paravirtualization anyway. What would you guys call an OS that
has vm-tools installed and various tweaks to the kernel and config files
to make it work as close to a physical machine as possible?
Allen Tsang wrote:
Hey folks,
By Paravirtualization, I mean the installation of "tools" or "guest
additions" type packages, which present virtual interfaces to the
guest OS. So in VMware, a component of this would mean setting
"ethernet0.virtualDev = vmxnet", and having the tools modules
pre-installed. A fully virtualized OS for VMware would support all
that crap.
From Wikipedia:
"""
In computing, paravirtualization is a virtualization technique that
presents a software interface to virtual machines that is similar but
not identical to that of the underlying hardware.
Paravirtualization may allow the virtual machine monitor (VMM) to be
simpler or virtual machines that run on it to achieve performance
closer to non-virtualized hardware. However, operating systems must be
explicitly ported to run on top of a paravirtualized VMM. Owners of
proprietary operating systems may decline to allow paravirtualization
for strategic purposes.
"""
I'm neurotic about paravirtualization because, well, we roll our
organization's production systems on VMs, so I want minimal
performance hit if possible across the board. I'm sure some of you
are thinking right now how foolish I am for doing this. In reality,
cost savings in labor through all of the flexibilities of a fully
virtualized environment is more important to us than raw performance
and low latency.
One problem with setting your VM template to utilize virtualDevices in
a production environment currently is the inability to PXE boot the
machine to provision your host, because no commerical distro or
operating system I know of, Linux, BSD, Solaris or otherwise,
currently offers an out-of-the-box module support for virtualization
in their install initrd, for various licensing and technical reasons
(the open-vm-tools effort would likely solve this in the near
future). OHAI Trolls who can't read: YES YOU *CAN* PXEBOOT w/VMXNET
(NOT VMXNET-ENHANCED), BUT YOUR INSTALL FAILS BECAUSE IT CAN'T FIND A
"DRIVER" FOR 'VMXNET'.
I know of tru's efforts and others on this front and I really
appreciate the knowledge they have brought to the table, but I feel
that it's about time that some dedicated entity step in and 'solve'
this problem (we've written kickstart+firstboot-type scripts that
eliminate the 'work' of managing hundreds of VMs and their
installation of tools, but through the whole process we have wished
for Our Favorite Community Enterprise OS to support this stuff OOB so
we didn't need to do the work. Lazy Sysadmins are lazy). One man
cannot keep such a beast up to date; it needs to be a dedicated effort
or project. The complexity of 'doing VMs right' is getting to the
point where it requires a virtualization expert to be staffed
(consider the ever-present Time Sync Issue, which requires
customization on the Host configuration AND the Guest OS). This is
unacceptable; we either need virtualization software that is a little
more clever or we have to step in on the application layer and have
the OS live closer to the host hardware. Also, there's a great deal
of untapped potential in having at least a greater set of conservative
message passing between the Guest OS and Host / VM Infrastructure,
shared storage amongst different hosts over the attached SAN, etc
etc... skies the limit.
This might be a direction that Big Mommy RedHat should/would
eventually take. I'm not a big fan of CentOS mini-forks of kernels
myself (e.g. centosplus, -vm, etc), since it kinda defeats the 'point'
if you know what I mean.
/me crosses fingers that Sun + InnoTek makes a really kickass
VirtualBox for the Enterprise that develops a much better solution, or
better yet, a *truly* embedded virtualization solution (Hey, anyone
from Sun Engineering on this mailing list? Imagine memory and storage
pooling on the hardware layer over something like infiniband, guys).
Then again, cloud computing, future is bright, sunglasses + igloos,
teotwawki, lol.
- allen tsang
Daniel de Kok wrote:
On Mon, May 5, 2008 at 5:13 AM, Allen Tsang<[EMAIL PROTECTED]> wrote:
Speaking of which, I was talking to some friends about building a
fully
paravirtualized rhel/centos that works with xen, vmware, virtualbox,
etc.
Do you guys feel like that's a product you would consider using?
I suppose you mean "fully virtualized", since VMWare and VirtualBox do
not paravirtualize? If so, True provides VMWare images of CentOS 4 and
5. They should be easy to modify for VirtualBox and qemu as well:
http://dev.centos.org/~tru/vmware/
Take care,
Daniel
_______________________________________________
CentOS-virt mailing list
[email protected]
http://lists.centos.org/mailman/listinfo/centos-virt
_______________________________________________
CentOS-virt mailing list
[email protected]
http://lists.centos.org/mailman/listinfo/centos-virt
