[SATLUG] Filesystem/RAID advice
Ernest De Leon
edeleonjr at gmail.com
Tue Oct 12 23:05:01 CDT 2010
Working in the enterprise virtualization space for a long time now, let me
throw a few observations in. Let me first say that I lost the origin of this
thread (maybe it forked?) but I am responding to the pieces I can see. If I
address something that is out of context to the OP, please excuse.
No matter how you slice it, a virtual machine (even sitting on a bare-metal
hypervisor) has a layer of abstraction to go through. Although the
hypervisors on the market have gotten much better over time and offer
near-native hardware performance, they do not offer native hardware
performance. They can't.
With that said, most of the 'perceived' increase in VM performance or speed
comes from the virtual and physical disk sub-systems. At the virtual level,
your vmdk (or virtual disk format of choice) is loaded (as much as possible)
into RAM (depending on the amount of RAM on the system). Think of it as a
RAMdisk. Performance will be much faster than if reading/writing to hard
disk. The disparity is huge on a 'home user' system where slow SATA disks
are being used. In the enterprise space, fast SAS or SAN LUNs exported over
4G Fibre Channel (iSCSI if you are frugal) are used, so even when something
has to be read from/written to disk, it is done at much faster rate than a
SATA drive. Couple that with the fact that today's enterprise systems come
with 12 cores and usually include about 128-256 GB of RAM and you can see
why it would seem that VMs perform better (are faster) than physical
On home systems, the situation is similar though not the same. There is
still a sense of better performance due to the heavy use of RAM in virtual
environments. Using graphics intensive applications as a barometer of
virtual machine performance is about the poorest example you can pick.
That's like taking a Ferrari and saying that it has horrible off-road
capabilities. If you want a Jeep, then buy a Jeep.
Now with all that said, there are still some caveats with virtual
environments to take into account. First of all, assigning more RAM does not
always solve issues. Even on 64 bit machines, there is overhead associated
with managing ever MB of memory assigned to a virtual machine, so over
subscribing RAM can actually hurt performance at a certain level. Second,
assigning more vCPUs (processors) to a VM is a BAD idea unless you have
applications that take advantage of multiple processors and/or are
multi-threaded. There is a context-switching penalty for every vCPU beyond
the first. Linux file systems are not inherently more reliable than NTFS. I
am a huge Linux fan, but I have seen more errors/bugs in EXT3 and EXT4 than
I have seen in NTFS. I'm sure others will have different experience. This is
from my observation in the field over the last 10+ years. I have accessed
just about every FS from every OS out there (that's even possible) and *nix
file systems are very robust, each has their purpose. Keep in mind that in a
virtualized environment, VMFS blows NFS, EXTx, and every other FS out of the
water in terms of performance and stability. Why is this? Well it was
designed specifically for holding virtual machines and their meta-data. How
many OSes can actually read VMFS? I'm sure all of the *nixes could if you
could install the drivers, but ESX is the only platform to read it natively.
So the long and short of the issue is that virtualization does not slow down
the VM perceptibly (in fact it appears the opposite), but it may slow down
the host system if the resources are over-committed to the guest. You have
to carefully balance the resources of the host with the resources of the
guests. This is even true of enterprise deployments where you have over 100
VMs on a single host with many processors (and cores) and hundreds of GB of
RAM. The enterprise hypervisors allow you to fudge the numbers a little with
memory ballooning and memory sharing, but you must still be mindful of the
In defense of Windows, the same performance can be had with Server 2008 R2
x64 assuming you have applications (or workloads) that can leverage all of
the hardware underneath. The historical problem with Windows is that you
couldn't run multiple workloads concurrently without issues. Although you
can do it now with the latest server versions, it is still not recommended
to do so. This is why virtualization really took hold. You can isolate the
instances so that each is only running one workload and a failure at the OS
or application level will not affect other virtual machines running on the
host. Even in the *nix world where multiple workloads can be run in a single
instance or multiple instances (e.g. Solaris Zones) it is still better to
isolate workloads to where a failure at the OS will not affect more than one
On Tue, Oct 12, 2010 at 9:05 PM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> Othniel Graichen wrote:
>> So in response to "Virtualization DOES slow down the system" I would ask
>> you these questions:
>> 1) How much RAM did you allocate for running XP in your test environment?
>> 2) How many processors did you allocate to XP?
>> 3) Is your guest operating system even able to use all such resources?
>> 4) Why are you using a game which uses ActiveX to validate your point
>> system speed?
>> That is a measure of responsiveness not throughput or speed.
>> 5) Why don't you acknowledge that Linux file systems are more reliable
>> 6) Since Windows doesn't have good drivers for the robust file systems
>> native to Linux,
>> why not acknowledge that accessing such file systems via a VM guest
>> operating system
>> and a standardized networking protocol is a reliable and high performance
>> way to interface
>> between a Windows application and a Linux disk's file system.
>> 6) Do you have enough experience with accessing a disk and the files on it
>> from multiple
>> Operating Systems to know why that is such a bad idea?
> I'd add that which VM in use makes a difference as well as the VM
> I'll also note that Nate seems to have his heart set on a native HW
> instance of Windows. I know that friends don't let friends use Windows, but
> we also have to know when to let go.
> -- Bruce
> SATLUG mailing list
> SATLUG at satlug.org
> http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
> Powered by Rackspace (www.rackspace.com)
Message void if penguin is violated...
Don't mess with the penguin.
More information about the SATLUG