VM /ETC

Archive for March, 2009

Part of the magic hosting multiple virtual machines (VMs) on VMware ESX server is accomplished by leaning on the host’s CPUs to simultaneously handle networking loads. The more network I/O generated the more the CPUs have to work. When this happens the performance of the ESX host and the VMs can suffer because the result is limited access to available physical processing. Some common network I/O examples are software iSCSI adapter or NFS access to data stores, live migration of VMs between ESX servers via VMotion, and even administrator access with the VI Client.

Fortunately, ESX/ESXi 3.5 TCP Segmentation Offload, or TSO, can remove some of the networking burden from the host’s CPUs and improve overall performance. When the ESX server’s physical NICs support it, enabling TSO is as simple as choosing the right virtual network adapter, the Enhanced VMxnet adapter, for the VM. Surprisingly, making the Enhanced VMxnet adapter available to the VM is not a straightforward process because the Enhanced VMxnet adapter might not be an option in the virtual NIC properties or the Add New Hardware wizard.

First, you may be wondering how TSO reduces CPU overhead. Read the rest of this entry »

Today marked the official release of the Hyper9 search based, agentless VMware admin tool. Regular readers will recall VM /ETC helped recruit beta testers for this product through multiple different sign up periods over the last 6 months. In fact, the Hyper9 team in Austin, TX has been busy with several press releases recently. I’ll sum them up with some quotes here in this post. Go to the Hyper9 | Company » News & Events web page to read all announcements in full. Read the rest of this entry »

I collaborated with Joerg, Stephen, and Martin while writing Planning for Virtual Infrastructure: Avoid the Pitfalls at GestaltIT.com. The post offers many virtual infrastructure planning considerations in the areas of migration, performance, storage, administration, backup / restore, and disaster recovery.

Please go check it out!

I’m excited to announce that I am one of nine bloggers contributing content to a new independent online magazine. GestaltIT.com, a concept created by Microsoft MVP Stephen Foskett, is self described on it’s home page as “a “web magazine” focusing on the best in IT infrastructure content, syndicated from expert bloggers”. Look for both new, unique content from me there along with syndication of some of my posts from VM /ETC.

In case you were wondering, gestalt is generally defined (in my own words) as a group of concepts so unified that it is greater than the sum of it’s parts.

Here’s some more information from the GestaltIT FAQ page: Read the rest of this entry »

If you thought that because all ESX virtual machines (VM) share a virtual portgroup on a virtual switch (vSwitch) inside an ESX host you could easily sniff all VM traffic with a protocol analyzer like ethereal or wireshark, when you tried it you found out you were wrong. If I am not mistaken, ESX vSwitches are considered layer 2 devices and come with all the expected security and isolation. However, you can make some relatively simple vSwitch design and setting changes to turn a VM into a virtual sniffer and monitor all other VMs on that same host. Another option is a free virtual appliance that can allow you to use your physical monitoring tools to watch your VMs. This post explores both of these free VM sniffer alternatives.

I’m going out on a limb here reporting what I’ve learned about VM sniffers, but I figure that passing on what I know so far would be helpful to VM /ETC readers. At the very least, use the info in this post to get you pointed in the right direction. Fill me in on what I’ve missed, please! Read the rest of this entry »

One of the advantages of running virtual machines (VMs) on shared storage is that if you need to rebuild your ESX host(s) you won’t lose your VMFS volumes or the VMs. But, what if you can’t VMotion evacuate the VMs to another host with extra capacity first? This scenario means the VMs will no longer be registered on an ESX host once you are finished. Importing VMs with the datastore browser is simple enough, but what if you have hundreds of VMs to import? Manually importing that many VMs will take hours.

Luckily, the built-in ESX console command vmware-cmd with the -s option allows you to mass import VMs via some simple scripting. Ed Haletky pointed this out to me via Twitter, and then Duncan Epping tweeted me a post of  his that contained the following batch script he used for mass VM imports in slightly different scenario :

for i in `find /vmfs/volumes/ -name "*.vmx" `
do
echo "Registering VM $i"
vmware-cmd -s register $i
done

To use the above code save it as a text file with a .sh extension. For example “importvms.sh”. Place the file on anywhere on your ESX host and then as root run

#./importvms.sh

updated 3.12.09 – My Softchoice colleague, Michael Cocat out of our Chicago office, modified the original script above to work when spaces exist in the VM (and .vmx) name. Michael also likes to run the script as a single line entry on the ESX Console. Here’s the updated command in single line format:

find /vmfs/volumes -name “*.vmx” | while read LINE; do echo “registering VM $LINE”; vmware-cmd -s register $LINE

updated 3.12.09 – I also want to point out that this script will not place the VMs back in Resource Pools or Folders. The VMs are imported into the root of the object tree because the resource pool and folder information is not stored in the .vmx file. Once you have the VMs back registered with the ESX server you can simply drag and drop them into resource pools and folders again. Thanks to Jason Boche for bringing this up, and pointing out it is not really a fully automated recovery process. It is still a much better alternative to manually importing each VM with the datastore browser which will prompt you for Resource Pool and VM folder placement.

To find out more about the vmware-cmd options and switches check out

http://www.vmware.com/support/esx21/doc/vmware-cmd.html

and

http://www.esxguide.com/esx/content/view/2/25/

Image via Wikipedia

Here’s some common scenarios where external USB devices might be needed in VMs:

Temporary USB Connections

• One time data transfers
• Print to a printer
• Scanning

Permanent USB Connections

• Application security keys
• Printing
• Scanning
• Card readers

These are just a few I could quickly think of.

In the rest of this post I discuss using RDP USB pass through for the temporary scenario, and then provide some links for permanent USB connection possibilities to a VM. Read the rest of this entry »