I'm not here to dispute anything. I would ask some questions that IBM did not make clear to me in the technote. They did not spell out what type of I/0 was inside the physical ESX host they tested. I would also be instrested in these specfics: NIC count/speed HBA count/speed. Also what kinda of load was on CPU 0 (the CPU that the VMware kernal uses), was a min CPU/Memory reservation set for the console OS? I'm of the mind set to give more resources to the console OS. I run a reservation of 1024MB and 800MHz for the console just to be safe. Also something to look at is %ready for the console and various VMware processes.

Anyway its something you can look at in your enviroment if you have not already.

Good point. They seemed to do a pretty thorough job of testing then at the end of the day made some assumptions and moved on. Would have been nice to bring this to VMWare support (both as an ordinary support customer and as "big blue") or at least state that you tried to or whatever the case may be. Maybe I'll have time one of these days to try and reproduce some of the simple failure cases they conducted and then give VMWare a call myself, since we seemed to see the same thing IBM noticed when running heavy Domino I/O.

Benny,

Just for fun, do you mind sharing with us what you give to the console OS for Proc/Mem plus any reservation numbers. Count/Type NIC/HBAs would also be helpful.

The session is only viewable by attendees. Anyone care to share notes they took at VMWorld?

I hadn't read that one yet. Pretty standard VMWare doc, really (no practical advise there that isn't in any best practice guide for ESX). Impractical stuff like this is kind of annoying:

However, good news: I'm having conversations with the guy from IBM that wrote the original technote I posted and he also was the one who made that presentation at VMWorld. I'll share the results of our work once we are finished.

Question for a moderator: Can I post details about a particular presentation from VMWorld if I get the content directly from the presenter and not from the password-protected VMWorld site?

I don't see why not, the presentations are not public yet but the information in them isn't confidential. Just like if you went to VMworld and came back and told your co-workers about everything you had seen and heard there. The presentations should all be available to the public shortly I expect. There is a thread on this in the vmworld forum...

http://www.vmworld.com/vmworld/message/1307#1307

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-
Thanks, Eric
Visit my website: http://vmware-land.com
-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Glad that you pointed that out - we experience the same thing:

I see high CPU on heavily used notes servers (mail servers with 100-200 users) BUT we can't see poor response time on the client end at all - furthermore we can't see a noticeable difference in response time regardless of whether we are cpu-throttled on a VM or on a physical server using very little cpu. That is a very good thing because it means we can keep our existing virtualized notes servers around while we figure something else out.

It should be noted that we still need to figure something else out (as an alternative to virtualizing Domino servers) if for no other reason than those VMs are using more than their fair share. Virtualization has lots of benefits, but if one VM hogs the cpu resources that 4-6 better-chosen VMs would use, then it makes more fiscal sense to put the one VM on a low-end physical box (where in our case won't need the CPU resources the VM counterpart did) and then virtualize the 4-6 other VMs in its place. I understand that Domino server then can't participate in VMotion and all that other cool stuff (cheap SAN connectivity for instance), but in the end it comes down to money, right? If a choice has to be made, I'll virtualize the 4-6 and deploy the resource hog on hardware.

Benny