Has anybody made some (good, bad or neutral) experiences with the VMI Paravirtualization Option, which is available for guest's under ESX 3.5?
Does it provide a performance boost? Regarding some VMware documents the performance gain when using paravirtualization is not so noticeable (or do they state this just because XEN uses this approach?).
Does this statement ("This feature is available only for versions of the Linux guest operating system that support VMI paravirtualization.") from the VI online help mean that this option can only be used by VMI-aware Linux systems and excludes Windows hosts or does this statement not exclude Windows?
Am I right thinking that this switch applies to CPU virtualization as at least the VMware Tools NIC driver is already paravirtualized?
VMI is supported in any 32bit linux with kernel 2.6.22 and newer. It is also supported in SLES10sp2.
RHEL5 will not support VMI at all and still no decision to support VMI in RHEL6.
The underlying guest OS needs to be paravirtualization "aware". Only a few versions of Linux do this. I believe that Windows 2008 is paravirtualization aware as well because of Hyper-V. I would say to test it first. You may not see a performance boost and there may be some security issues with this. I always say this: Just because you CAN do something doesn't mean you SHOULD do it...
Dave
I always say this: Just because you CAN do something doesn't mean you SHOULD do it...
I agree.
My questions are more of a hypothetical nature or let's say "to be prepared". If somebody comes around the corner saying "I know how to improve performance blabla" or "Why didn't you use this or that option, etcetcetc...." I would like to provide reasonable answers.
But it might also be possible that these are valuable options.
So, I just want to know what I can or cannot do/expect.
We are implementing VMI with our Linux VMs for improved clock stability.
Sucessfully?
What does change regarding the clock synchronization when using VMI?
As the clock source used by Linux depends on the Kernel version, it should not change the clock behavior as long as the PIT is used. Even with VMI only the host owning the CPU will see the timer ticks and that is the source of the problems. With the newer Kernels (2.6.18/21 and later) TSC or ACPI will be used to fix this.
It is my understanding that when running a VMI kernel under linux, it also uses a clocksource other than PIT. Looking at dmesg, I see the following on VMI enabled servers which would indicate this may be true:
Linux version 2.6.16.60-0.23-vmi (geeko@buildhost) (gcc version 4.1.2 20070115 (SUSE Linux)) #1 SMP Thu May 15 06:38:31 UTC 2008
Detected VMI ROM version 3.0
VMI Timer active.
VMI Timer cycles/sec = 2992499000 ; cycles/jiffy = 11969996 ;cycles/alarm = 29924990
Using vmi for high-res timesource