x86 vs. x86_64

Fri Mar 26 20:15:54 MST 2010

Depending on the virtual system and how you're using it, you may need to run 64-bit to use all of the RAM.
VMWare works reasonably well with PAE, but it occasionally has trouble in some hardware configurations with BIOS or chipset limitations.
VirtualBox had difficulty with PAE for a long time, it's supposed to be working much better now but I haven't tried it.

In all cases, PAE is a significant performance hit vs. straight 64-bit once you exceed the 4G limit, so if you're planning to run over 4G of RAM, I strongly recommend just loading up a 64-bit system.
There are very few incompatible systems left, and most of those could be run just as easily in a VM.

For OpenVZ, you can have different distributions quite easily.  You can even host a 32-bit container on a 64-bit server (I do that a lot), although you can't go the other direction.
It's actually quite simple to run a single 64-bit host, then have 32-bit CentOS 5, 32-bit Ubuntu 8.04, 64-bit Gentoo, 64-bit CentOS 5, 32-bit Ubuntu 9.10, and 64-bit Ubuntu 9.10 all running in containers just fine.
I typically reduce containers to a really tiny amount of RAM (I often run 64M or less, since I strip out all services except the one application I intend to run), it's pretty easy to get total system overhead in a container to 12M or less, since the main kernel doesn't consume container RAM.
Given the small RAM usage of containers in general, it's pretty normal to run OpenVZ as 64-bit host with 32-bit containers.

OpenVZ is very lightweight compared to other VM systems, so it's a good choice if you're wanting to experiment with a bunch of server guests with no GUI.

If you want to experiment with GUI systems, a VirtualBox install on the same host would provide that option.

Either way, if you're wanting to experiment with servers, go with a 64-bit install, since it's pretty rare to install servers on 32-bit anymore, there's nothing to gain and 64-bit has better performance in large-memory scenarios.

Alex Dean wrote:
> This has always confused me a bit, so it seems like a good time to ask.
> 
> I have a machine running 32-bit Ubuntu.  It has 4GB of RAM.  I'd like to
> use it as a host OS for several (maybe 6?) VM guests.  I thought it
> would make sense to add more RAM before doing this, but I wasn't sure if
> I'd be able to utilize the extra memory w/o changing to a 64-bit host
> OS.  From reading this thread, it sound like I wouldn't need to change
> over to a 64-bit host, since none of my guests would have processes
> accessing more than 4GB of RAM.  Is that correct?
> 
> The guests will be server OSs, not running any GUI applications, so I
> expect their resource utilization to be pretty slim.  I just need
> somewhere to test multiple-box HA cluster configurations, and I don't
> have the extra hardware lying around to do it with.
> 
> I'll probably use VMWare, but that's not settled.  If OpenVZ or
> VirtualBox might have advantages for this kind of thing, I'm interested
> in hearing about them. The host is Ubuntu, but the guests will be RHEL5,
> so I think that means I can't use OpenVZ since they'll have different
> kernel versions.  Someone correct me if I've got that wrong.
> 
> thanks,
> alex
> 
> ps - Apologies if this is thread-hijacking.
> 
> On Mar 26, 2010, at 12:17 AM, Kurt Granroth wrote:
> 
>> Just to be pedantic; Matt is correct in his use of 'AND' with the
>> memory.  It is 'have more than 4GB RAM *AND* something that can use
>> more than 4GB in one process'.
>>
>> Basically, this is due to PAE.  The PAE extension (which all modern
>> CPUs support) allow the OS to access up to 64GB of memory, even on a
>> 32-bit x86 system.  There's no need for a 64-bit processor for that.
>>
>> HOWEVER, PAE doesn't permit a single process from mapping or
>> allocating more than 4GB.  That's where you'll need 64-bit processors.
>>
>> And if you don't know for sure that you need that capability... then
>> you definitely don't.  It's very very rare (unless, of course, you are
>> in the fields that do need that and then you'd know that).
>>
>> On 3/25/10 5:38 PM, Stephen wrote:
>>> this is pretty accurate. if you are at the 4g limit or more then 64
>>> bit. or if you are doing some really high end memory intensive
>>> applications then you will have a need, otherwise 32 bit is the better
>>> idea for compatibility and ease of use (some weirdness with flash in
>>> 64 bit, solvable but you have some hoops to jump, there are a few
>>> others like this)
>>>
>>> On Thu, Mar 25, 2010 at 3:32 PM, Matt
>>> Graham<danceswithcrows at usa.net>  wrote:
>>>> From: Nathan England<nathan at paysonlinux.org>
>>>>> Before I spend any time downloading and trying it myself, has any
>>>>> one taken
>>>>> the time to compare performance differences in every day usage between
>>>>> ubuntu x86 and the 64 bit version?
>>>>
>>>> There is essentially ZERO performance difference between 64- and
>>>> 32-bit Linux
>>>> for normal user apps AFAICT on a Gentoo box.  Couple that with the
>>>> fact that
>>>> at least one app (epsxe, PSX emulator) doesn't work at all on 64-bit
>>>> Linux,
>>>> and it's a no-brainer:  Use 32-bit.
>>>>
>>>> The only reason that I can see to use 64-bit Linux is if you have
>>>> more than 4G
>>>> RAM in your box AND you've got something that can benefit from
>>>> malloc()ing
>>>> more than 4G of RAM in one process.  So if you're running a big DB
>>>> or a huge
>>>> numerical simulation or something like that, go 64-bit.  Otherwise, go
>>>> 32-bit.
>>>>
>>>> (Constructive criticism and flying attack porcupines welcomed, since
>>>> the above
>>>> post may be full of bovine feces....)
>>>>
>>>> -- 
>>>> Matt G / Dances With Crows
>>>> The Crow202 Blog:  http://crow202.org/wordpress/
>>>> There is no Darkness in Eternity/But only Light too dim for us to see
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20100326/d319e109/attachment.pgp>