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<atsang at advance.net> 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 >> CentOS-virt at centos.org >> http://lists.centos.org/mailman/listinfo/centos-virt >