Posts Tagged ‘surface graphs’
Why Virtual Desktop Memory Matters
I have seen several Virtual Desktop projects with “bad storage performance”. Sometimes because the storage impact simply was not considered, but in some cases because the project manager decided that his Windows 7 laptop worked ok with 1GB of memory, so the Virtual desktops should have no issue using 1GB as well. Right? Or wrong? I decided to put this to the test.
Test setup
To verify the way a windows 7 linked clone (VMware View 5) would perform on disk, I resurrected some old script I had laying around on vscsiStats. Read the rest of this entry »
vscsiStats in 3D part 2: VMs fighting over IOPS
vscsiStats is definitely a cool tool. Now that the 2D barrier was broken in vscsiStats into the third dimension: Surface charts! it is time to move on to the next level: Multiple VMs fighting for IOPS!
Update: Build your own 3D graphs! Check out vscsiStats 3D surface graph part 3: Build your own!
I figured the vscsiStats would be most interesting in a use case where two VMs are battling for IOPS from the same RAID set. A single VM would have to force I/O on a RAID set. Wouldn’t it be cool to start a second VM on the same RAID set later on and to see what happens in the 3D world? In this blogpost I’m going to do just that!
TO THE LAB!
The setup is simple: Take a LUN on a RAID5 array of (4+1) SATA72K spindles, take two (Windows 2003 server) VMs which have a datadisk on this LUN. Now install iometer on both VMs. These two instances of iometer will be used to make both VMs fight for IOPS.
The iometer load is varied between measurements, but globally it emulates a server load (random 4K reads, random 4K writes, some sequential 64K reads).
First only a single VM runs the iometer load. At 1/3rd of the sample-run, the second VM is started to produce the same IO pattern. At 2/3rd, the first VM stops its IO pattern load. This results in the following graph: