32bit+VMI or 64bit Linux?

[tbsky]

hi:

with vsphere 4.0, now i have many choice to implement linux vms. my cpu is AMD 4 core and has some nice hardware virtualization support.

most of the vms i use are nomal LAMP linux with 768M memory. i don't know which one is better?

1. 32 bit os with VMI support

or

2. 64bit os without VMI

some of the vm need more ram(but no more than 3GB). how about 32bit+VMI or 64bit in this kind of situation?

thanks a lot for help!!

[AntonVZhbankov]

32bit VMs also have less overhead, so 32bit is the choice here.

---

VMware vExpert '2009

http://blog.vadmin.ru

[AndreTheGiant]

If you have an OS that need less than 3 GB of RAM, you can use the 32 bit version.

Andre

[tbsky]

hi:

thanks a lot for the information. so if my vm didn't need momory > 3GB, i should stay with 32bit, even in vsphere.

and i am a little confused about VMI. vsphere now supports the advanced hardware virtualizaion like intel/EPT, AMD/RVI.

i suppose i can still enable VMI to get more performance in these new hardware platform.

will VMI be useless or even lower the performace on these new hardware platform?

thanks again for your information!!

[AndreTheGiant]

will VMI be useless or even lower the performace on these new hardware platform?

Maybe.

Some people have different results with or without VMI.

Also also different results with or without VMware Tools on Linux.

IMHO I prefer install always VMware Tools, and use VMI on 32 bit Linux machine.

Andre

[agesen]

Time permitting, I would recommend that you try both options

and compare the performance for your particular workload. In

general, we have found 64 bit guests to be somewhat easier to

virtualize efficiently. One of the reasons probably is that

the greater 64 bit address space allows workloads to run with

less use of mmap/munmap (which involve the MMU, which tends

to be slower in a virtual environment than natively). Put

differently, a 64 bit address space will more likely be able

to hold the entire working set of the application than a 32

bit address space.

There's also the question of future-proofing workloads. Maybe

you don't need to give the VM a lot of memory today, but needs

could grow in the future, in which case it is simpler to just

add some more memory than having to rebuild a new 64 bit VM

to replace a 32 bit VM that you have outgrown.

Thanks,

Ole

[tbsky]

hi:

so it seems 64 bit vm is the trend. i thought there are some benefits to use VMI, like performance and time keeping.

but since VMWARE didn't support 64bit VMI, maybe the situation is different in the 64 bit world?

will VMI be abandoned in the future?

[agesen · Accepted solution]

There can be little doubt that the future will be increasingly

dominated by 64 bit operating systems, whether Linux or Windows,

laptop or server. It is just a matter of time.

VMware has no 64 bit VMI support; we have not observed any

compelling performance for bringing this feature into 64 bit

Linux now that modern CPUs support RVI and EPT. In addition

to improving performance, these hardware features have allowed

us to bring the hypervisor overhead memory consumption down,

so VMI will not save you memory at the hypervisor level.

Regarding time keeping, VMI did bring early improvements to

time keeping by implementing "tickless" time keeping. However,

newer linux kernels have now moved to tickless time keeping

as well, so you get these benefits with or without VMI. For

example, SLES 11 is tickless and it should be just as good at

keeping time as a VMI kernel on vSphere 4.

Thanks,

Ole

[tbsky]

hi:

thanks a lot. the infomation is much clear for me now.

since 64bit is the long turn trend, and 64bit VMI won't be supported in the future, i should go 64bit linux now. espeically i already have AMD/RVI cpus.

and i am glad to hear tickless linux can do good job for time keeping in vsphere. it is really a good news for me.

thanks again for all the information!!

[thinks2much2]

If I may throw another question into the mix. How does a PAE enabled kernel affect performance? If I understand it correctly, this allows a 32bit Linux server to access more than 4 GB of RAM. Indeed, I see that SLES 11 installs that kernel by default (2.6.27.19-5-pae), which i assume is also VMI enabled.

http://en.wikipedia.org/wiki/Physical_Address_Extension

Kevin

[agesen]

PAE allows a 32 bit system to address physical memory beyond 4 GB.

While early versions of PAE MMU virtualization were less optimized

than non-PAE, it has been years and years since we got PAE to

parity with non-PAE (back in ESX 2.0 or was it ESX 1.5).

Keep in mind, though, that PAE doesn't expand the virtual address

space. If you have a server that runs a 32 bit OS, like SLES 11,

any single process can use at most 4 GB of memory. In fact, it is

worse still, since the kernel takes up some address space too

(unless you use a 4g/4g kernel, but these have issues of their

own). So, a user mode process can at lost address 3-4 GB, even

if PAE allows the system as a whole to have 64 GB (or more) of

physical memory. All that extra memory can only be put into play

by running multiple processes or using overlays.

In other words: 32 bit systems have become address space limited.

PAE doesn't expand the virtual address space. 64 bit does.

What all this means is that the time, really, has come and gone

for 32 bit operating systems when you want to run workloads that

need to scale to large memories.

I can confirm that the vmi kernel is PAE enabled.

Ole