Maximum memory for VM guest in ESX 3.0.1

[dborgill]

I have searched for this I keep coming up with mixed answers and a lot of old ESX 2.5.x articles.

We have Windows 2003 Enterprise hosts in ESX 3.0.1 - The host is an IBM x3950 with 16 gig of RAM. We have a request for a large SQL server that need 8 gig of RAM.

What is the OS and VM limitation for a 2k3 Enterprise guest?

[Rumple]

I have not heard of any plans for increasing the memory limit further at the moment, but i think you are in a rather unique situation.

Most times with virtualization the issue is consolidation, not hardware independance that drives the P2V decision. With consolidation there is typically no need to use massive amounts of a single resource such as memory because then all ESX does is add cost overhead.

I've priced out 4 servers with 32GB RAM on each and a single server with 128GB RAM and the ESX costs and in the end the 4 servers were cheaper then the ESX environment, but as indicated its the hardware independence that is your challenge.

[RParker]

STD supports up to 4Gb

ENT supports up to 32Gb

ENT 64-bit supports up to 64Gb

[RParker]

Actually Windows 2003 Standard ONLY supports 4Gb.

[RParker]

Only with Enterprise.. 64-bit Supports 64Gb

[RParker]

It wouldn't matter anyway, the OS is limited by memory anyway, so increase the maximum does no good, as the OS would not be able to utilize it.

[RParker]

ON this we could ALL agree. If the host only has 32Gb, and he wants a VM to be 32Gb, wouldn't that negate WHY you use VM's in the FIRST place?

As spock would say .... fascinating . . . .

[RParker]

[RParker]

<<Then further assume that the latest spec hardware from your chosen hardware vendor is not supported on that OS. Also assume that you'd like to be able to guarantee further hardware could be used with the system and ideally move the OS between physical hardware on the fly when you upgrade hardware. >>

Not supported.. maybe, but have you actually TESTED it to confirm this?

But yes virtualzing would give you portability, true enough.

It's just out of the ordinary that anyone would ask for this amount of RAM for a VM.... And I have dealt with lots of software over the years, this seems an awfully steep need for RAM, even for Math computations considering Math needs CPU, not RAM.

[Optic_Nerve]

Hi DeeJay,

I think a lot of the replies to you have been a little narrow in scope.

I agree with you, consolidation is not the sole driver for virtualisation. It just happens to be the primary driver most of the time.

I used to think of VMware as consolidation software only, but VMware representatives who helped us with our implementation convinced me otherwise. Virtualising machines on a 1:1 ratio with hosts is a perfectly valid thing to do. Naturally they were trying to sell us more licenses but it's still true.

There are so many benefits with virtualisation other than just consolidation. Portability and easy backup (good for DR), high availability (with HA), snapshots (very handy when it comes to patching) etc.

Naturally the first thing we virtualised (and consolidated) was our development environment, then next was the "minor production" stuff (also lots of consolidation here). After that we started virtualising some of our major production systems. These often require 16 GB of RAM and we have a single VM on each host. Sometimes we even have a single VM on two hosts (with HA) for the business critical applications that don't offer any native clustering capabilities.

The cost of VM licenses in our case can be justified for all these features even when we aren't consolidating. The increased operational efficiencies and savings more than make up for the cost of the licenses. We virtualise when the hardware is up for renewal anyway, so hopefully the overhead required for virtualisation is more than made up for by the increased power of the new server (typically going from dual NetBurst-architecture Xeon ~3.0 Ghz CPUs to dual dual-core Core-architecture Xeon 3.0 Ghz CPUs).

I think over time more and more companies will start to do this (especially as VMware continues to mature) and it will become much more common to require VMs with 16 GB+ RAM.

Obviously the logical "starting point" for any VMware implementation is consolidation, but it doesn't have to stop there!

Cheers,

Optic

[daat]

agree on that

if you plan to virtualize a important system, and you have no problem with the hardware costs (which everybody here seems to worry about) then why not virtualize it?

and with vm you have the limit of 16GB at the moment, which should be changed ASAP...

i already filed a feature request to vmware, and according to a support request i also opened last week (which was quickly answered) 3.0.2 should support that... thought i have no date

[DeeJay]

That's good to know - I'll keep an eye out for the increase in the next version.

To answer one of the other questions raised:

1) It's unlikely to need that amount of memory. Well, that may be true. However the physical server starts paging massively with 16GB of memory half way through the job. So, I suspect it does

2) Most people use VMWare for consolidation, and a single VM on a host is pointless. As others have mentioned, that's not the case, and certainly not in our environment. I usually aim for more than a single VM (because if a VM needs 4 CPU's and it's on a 4 CPU ESX box then you have to wonder what happens to the service console's requirements)

D

[CWedge]

Here is an article about the Product Direction.

http://searchservervirtualization.techtarget.com/originalContent/0,289142,sid94_gci1248948,00.html?t...

It speaks about the memory

"But, as we move to support 64 GB and beyond, those objections are going to come down. "

[DeeJay]

An interesting article, and mirrors some of the comments made on other threads about the next product release (DMOTION, more guest capabilities such as 8 vprocs and hopefully more memory).

I'm not sure about the comment about moving from 8GB to 16GB though (wasn't it 3.6GB in 2.5?)