VM /ETC

Posts Tagged ‘esx’

Surprisingly, Iomega can provide VMware certified low cost shared storage. I’ve heard mixed reports about actual performance, but none the less the filers provide cost effective options for VMware labs or small virtual environments.

The image to the right shows recent pricing on Amazon.com.

Fellow GestaltIT.com author and Microsoft Storage MVP Stephen Foskett has a great post with positive things to say on the Iomega models.

Iomega Grows Up and Moves Out of the House – Stephen Foskett

“…it was a surprise to find that the ix4-200r is certified compatible with ESX using both iSCSI and NFS right out of the gate. This is the only inexpensive storage system to wear a VMware badge, and this alone will likely make it a fixture in small offices and VMware labs. The desktop StorCenter ix4-100 and StorCenter ix2 are already widely used in these environments even without iSCSI, after all. The ix4-200r provides a complete SAN-in-a-box, supporting multiple NAS and iSCSI shares with dynamic allocation of the internal RAID-5 protected storage.”

Here is a screen shot from the on line VMware HCL showing the certified Iomega models.

So, who wants free VMware High Availability? That’s the title of a post created by Leo Raikhman on his Leo’s Ramblings blog. In this post, Leo has published the steps and scripting necessary to simulate VMware’s VI3 High Availability (HA) feature. Leo’s script works without VirtualCenter (VC), so VMware customer’s who have not implemented VC can manually create “HA -like” awareness between 2 ESX hosts. If one of the ESX servers goes offline then the virtual machines (VMs) are auto restarted on the other host. Of course, the VMs must be created on shared storage for this to work.

Before considering this script as a replacement understand the major differences between VirtualCenter HA and Leo’s HA:

• Leo’s script only works between 2 ESX hosts while VC HA can be configured with up to 32 ESX hosts as of VI 3.5 (actually using 32 host HA clusters is another topic, but it can be done)
• Leo’s script needs the ESX Service Console as written. It would need to be ported for the RCLI to work with ESXi. VC HA works with both ESX and ESXi
• VC provides a visual status for the health of your HA cluster via the VI Client
• VC HA provides HA fail over capacity for more than 1 ESX host at a time

I’ve held this post in my drafts because I wanted to try this configuration myself, but alas, I have never gotten around to it.  For those that can benefit from VC -less HA and give this script a test, let me (and Leo) know your results.

Leo’s post says: Read the rest of this entry »

Let’s say you need to quickly figure out if a remote server is a VMware virtual machine (VM). I won’t go into reasons why you might not already know, or why you would need to know, but let’s just say you do. If you have Remote Desktop access you can check the hardware devices, but what if you can’t and you need to tell remotely? I can’t think of an easier indicator than the server’s MAC address.

When ESX Server automatically generates a MAC address, the first three bytes are the VMware Organizationally Unique Identifier, or OUI. ESX Server uses one of two VMware OUIs for network adapters:

• If you initiate the virtual machine directly in ESX Server, ESX Server uses 00:0C:29:XX:XX:XX
  
• If you initiate the virtual machine in VirtualCenter, ESX Server uses 00:50:56:XX:XX:XX

If I am not mistaken the VirtualCenter generated MAC OUI is also the same for VMware Workstation, Fusion, and Server, but don’t hold me to that.

Armed with knowledge of the standard OUIs, it’s now easy to tell a VMware VM by the MAC address.

To get the remote MAC address using a Windows XP or Vista desktop, for example, enter the following at a command prompt: Read the rest of this entry »

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 »

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 »