VMware Paravirtualized SCSI (PVSCSI) introduced in vSphere was a special purposed driver for high-performance storage adapters that offered greater throughput and lower CPU utilization for virtual machines. According to tests PVSCSI offers 12% improvement in throughput and 18% less CPU cost compared to LSI SCSI.

In the early releases it had lots of limitations:

• FT not supported
• PVSCSI on boot disk not supported
• Hot Add not supported
• Only suited for heavy disk IO demanding workloads due to how PVSCSI handles interrupt coalescing
• Very limited OS support
• Not for Direct Attached Storage

All of these limitations are gone now (vSphere 4.1) except the two last bullets.

Lots of benefits:

• Simplicity, only having one template to maintain
• Don´t have to worry about changing virtual hw/driver if VM is starting to require higher disk IO at a later state
• Allows you to run more VMs -> higher VM density
• Increased disk IO performance

I wouldn´t change to PVSCSI on existing VMs if there is not a demand for high disk IO. But I would like to see more adoption of PVSCSI going forward as most people are basing their decisions on old and inaccurate information.

Please leave some comments on your experiences on PVSCSI (good and bad).

For more info:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017652

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010398

http://www.vmware.com/pdf/vsp_4_pvscsi_perf.pdf

/Mattias

The Experts Conference (TEC) is a Quest and Microsoft sponsored conference that focus on the experienced admin with deep technical sessions presented by the experts in the industry. This is an excellent opportunity to learn more, network and have fun!

There are several tracks that you can attend:

• Virtualization & Cloud
• Exchange
• Directory & Identity

To learn more about the Virtualization & Cloud track take a look at: http://www.theexpertsconference.com/europe/2011/virtualization-cloud-training/overview/

I am responsible for the virtualization track and we still have some open speaker and blogger opportunities.

If you are interested, please reach out to me: This e-mail address is being protected from spambots. You need JavaScript enabled to view it. or Twiiter: @msundling

Auf Wiedersehen!

Update: Announcement, there will be a PowerShell Deep Dive track available as well.

http://blogs.msdn.com/b/powershell/archive/2011/07/12/powershell-deep-dive-the-experts-conference-europe-2011.aspx

It´s time for you to vote for sessions you would like to be presented at VMworld 2011.

Deadline is May 18th so don´t waste any time, go vote today (http://www.vmworld.com/)

Approximately 2 years ago, there was a community conversation that was kicked off from Arnim Van Lieshout's blog post on memory management.  Over 31,000 blog hits later, this topic still remains one of the most talked about subjects in VMware virtualization.  At the end of the day, it is still NOT a good scenario to have in your ESX environment, and we consistently run across the situation when talking with partners and customers simply due to lack of education on how setting a memory limit can ultimately impact performance of an entire host.

The first question that keeps coming up is "Don't memory management methods only kick in when there is contention?"  My answer to this is two-fold.  First, I've only seen the VMkernel waiting for contention when looking at shares to determine priority, not to execute a method of memory savings/management.  Secondly, we need to define "contention".  In this particular case it is when a Guest OS needs more resources than the VMkernel can assign to it at a point in time.  This can be from a lack of available resources, or by forcing a restriction (like a limit) as to how much the VMkernel can give to a guest.  That's the one thing about a limit in VMware...  The limit is a hard value.  There is no "If someone else isn't using it we will let you go above it", it's static and absolute.