VMware: Extracting info from VMX files

In order to get some information on the exact names of VMs and the VMDK files they have mapped, I created a dump of all .VMX files on the SAN and used the following sed script to extract some relevant data:

s/#!.*/Configuration:/p
s/displayName/  &/p
s/scsi.:.\.fileName/  &/p
s/sched.swap.derivedName/  &/p

The script can be run using the following command:

$  sed -n -f "sed_script" "config-list"

The result is:

Configuration:
  displayName = "Service Desk 5.2"
  scsi0:0.fileName = "Service Desk 5.2.vmdk"
  sched.swap.derivedName = "/vmfs/volumes/46363464-80...

If you want, it can even be formatted in other ways:

s/displayName = \"\(.*\)\"/\n\1\n/p
s/scsi.:.\.fileName = \"\(.*\)\"/  \1/p
s/sched.swap.derivedName = \"\(.*\)\"/  \1/p

Resulting in:

Service Desk 5.2
  Service Desk 5.2.vmdk
  /vmfs/volumes/46363464-80...

Capacity Monitoring for Desktops?

With the rise of VDI (Virtual Desktop Infrastructure, see here for a comprehensive overview) and the momentum it has, one starts to ask similar questions as with conventional server consolidation: what type of virtualization platform is required, how many users/desktops can I host, will there still be room for scaling, etc.

The way to approach this in server virtualization projects is by means of capacity monitoring and planning using virtualization scenarios. We refer to earlier posts for more information about this topic.

The question we are asking: can we use the same concepts and ideas for desktop virtualization? My answer is 'NO', because:

1. A user acts completely different than a process or service: less predictable, depending on our mood, depending on the time of the day, etc.
2. Some end-user applications ask 1OO% of the CPU even while they are not doing anything. The classic example used to be the game 'Pinball'. Even a screensaver can take a large amount of CPU power.
3. In a VDI context, this becomes even more important. For instance: why would you scale your virtual desktop CPU and memory to include desktop search if really nothing personal can be found on the hosted desktop?
4. When starting and running 10 applications at the same time, we will probably only use 5 of them later, but still... they require CPU power (and memory) while seeming idle.
5. If a user has meetings half the time, does that mean his session is closed? Does it still require processing power? How can this be analyzed?
6. Etc.

In other words, a desktop environment is inherently different from a server environment. This is why in my opinion it is harder to maintain a Citrix farm than a VMware farm: applications and users tend to be less predictable and 'stable' than servers.

Does that mean that we can not do any sizing or planning in a VDI context? On the contrary, we should only keep in mind that applying exactly the same reasoning as with server consolidation planning is not a good idea.

A few more tips:

• Make sure you have an overview of running processes and their CPU/memory utilization. This helps in deciding what is really important.
• Be careful with averages and peaks: a PC that is running all the time will have a low average, but may be used heavily during the day and a PC may be 100% used during the day because of some applications.
• Take into account inactive time during the day.
• Do not try to analyze the 'average' user, instead create classes (say 5 or so) that each have typical characteristics. Use these classes to create the virtualization scenarios.

Octopus Platform: VDI 2.0

I came in contact with the people of e-BO yesterday. Their Octopus platform is truly amazing. In fact, this company already deployed VDI infrastructures years ago, when the term VDI did not even exist! Moreover, the whole concept is not even tied to VDI (hosted desktops), but can include other types of application/desktop provisioning as well.

Under the hood, an abstraction layer is created between the user front-end (thin or fat client) and the desktop/application provisioning backend. This layer makes it possible to do advanced things like: load-balancing, settings connection policies, secure channels, failover, etc.

Definitely worth a look!

Chargeback

On the VMworld website, you can find a featured presentation concerning chargeback. The presentation is by the CEO of VKernel, a company that I have mentioned on this blog before.

Chargeback, as pointed out in the presentation, is about 'measuring' and accounting for two types of costs: Consumables and non-consumables. The latter has to do with floor space, licenses, support and administration, etc. Consumables refers to utilization of CPU, memory, power, etc. Obviously, performance monitoring is critical in this aspect. Check out the presentation (registration required)!

Performance Monitoring: Correlations

Although I have been arguing that performance monitoring and capacity planning require a decent server montoring environment, it also requires more. This extra part comes from the fact that often services depend on each other. A web service connects to a database (hosted on a different server) and fetches data from the file server (local, or SAN/NAS). Often, one part in the chain is a bottleneck for the whole of the process. This is a shame and can be avoided by careful analysis of the correlations between performance data.

Again, this is an argument in favor of what I called a 'load profile' earlier. By modeling a server by means of a load profile, we get a representation of that server in terms of measurable quantities. Statistics and mathematics in general can then help us analyze the correlations between those load profiles.