VMware Cloud Community
AWo
Immortal
Immortal

ESX 3.5 Paravirtualization Advanced Option / Experience

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?

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
0 Kudos
6 Replies
AntonVZhbankov
Immortal
Immortal

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.

EMCCAe, HPE ASE, MCITP: SA+VA, VCP 3/4/5, VMware vExpert XO (14 stars)
VMUG Russia Leader
http://t.me/beerpanda
dconvery
Champion
Champion

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

Dave Convery, VCDX-DCV #20 ** http://www.tech-tap.com ** http://twitter.com/dconvery ** "Careful. We don't want to learn from this." -Bill Watterson, "Calvin and Hobbes"
AWo
Immortal
Immortal

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.

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
0 Kudos
chucks0
Enthusiast
Enthusiast

We are implementing VMI with our Linux VMs for improved clock stability.

0 Kudos
AWo
Immortal
Immortal

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.

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
0 Kudos
chucks0
Enthusiast
Enthusiast

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

0 Kudos