[CentOS-virt] tick divider bugs

[Allen Tsang]

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
>