Yellow Bricks

by Duncan Epping

Management & Automation

“Quick” Migration for VM’s running on ESXi 3.5u2+

· ·

Mike D was the first one that actually wrote a powershell quick migration script that exactly does the same as Microsofts Quick Migration. (Suspend on host 1, Resume on host 2.) Yesterday William Lam emailed me about a script that he created that actually does the same as Mike D’s script. But, William’s script was specifically designed for ESXi and he used Perl to do the job. Before we get into the “is this supported with the current API/RCLI discussion“, William contacted VMware and certain procedures used will be restricted again in the next update for ESXi.

William described his script as follows:

ESXi is a formidable hypervisor solution in both licensed and free operation mode. When fully licensed in a Virtual Center cluster, ESXi’s features (VMotion, HA, DRS, VCB, etc…) are indistinguishable from ESX. One feature of importance, VMotion, is used to perform live migrations of VMs that reside on shared storage from one host to another. In free operation mode however, ESXi hosts are independent of each other, in which case, useful features like VMotion become unusable.

The motivation for this script (ghettoQuickMigrate.sh) then is to provide administrators running the free version of ESXi on several hosts with the capability to perform Hyper-V-like “quick” migrations of virtual machines residing on shared storage between the hosts. VMware’s VIMA virtual appliance was chosen as the central launch point for the quick migration process. ghettoQuickMigration.sh is executed from within VIMA and is compatible with ESXi 3.5u2+.

William wrote an extensive Communities blog post on how this script works, what the requirements are and how to set this up. Another reason for you to start using VIMA!

Failover using SRM might be slow…

· ·

I was just reading an excellent weekly technical digest by VMware’s Michael White and noticed the mention of a KB article on SRM. This KB article has the following describtion:

With VMware Site Recovery Manager 1.0 Update 1, recovery of a VM might take a long time.  The recovery time during a test or real recovery will be longer when more VM’s are involved.  The Change Network Settings task might time out during the test or real failover.  This is due to the serial fashion in which Site Recovery Manager waits until a guest heartbeat is seen prior to customizing the VM.

This problem can be encountered when running the following ESX versions:

  • ESX 3.5 Update 2 and Update 3
  • ESX 3.0.2 and 3.0.3

In other words, the behaviour of ESX has changed and it might be useful and beneficial for SRM to change this behaviour again. We are talking about a 5 minute delay, that’s 5 minutes for each VM. You can imagine that running a recovery plan can and will take a long time when this setting isn’t changed. Here’s the solution which has also been outlined in the KB article.

Set hostd heartbeat delay to 40.
Disconnect the host from VC (Right click on host in VI Client and select “Disconnect” )
Login as root to the ESX Server with SSH.
Using a text editor such as nano or vi , edit the file /etc/vmware/hostd/config.xml
Set the “heartbeatDelayInSecs” tag under “vmsvc” to 40 seconds as shown here:

<vmsvc>
<heartbeatDelayInSecs>40</heartbeatDelayInSecs>
<enabled>true</enabled>
</vmsvc>

Restart the management agents for this change to take effect. See Restarting the Management agents on an ESX Server (1003490).
Reconnect the host in VC ( Right click on host in VI Client and select “Connect” )

FastSCP vs WinSCP

· ·

The last couple of days I’ve read a whole bunch of tweets and blogs on Veeam’s FastSCP. Everyone highly praises FastSCP because it is really really fast compared to WinSCP. I’ve been testing it myself in the past and indeed it is. With the release of 3.0 Beta that probably hasn’t changed a bit.

Keep in mind though that FastSCP is faster than WinSCP because FastSCP doesn’t encrypt the data that is being copied. WinSCP does encrypt the data and I consider WinSCP to be more secure than FastSCP. FastSCP does use an SSH control channel though. An SSH control channel can best be described as a secure channel which is used to pass user/password/port information. In addition to the ports used for SSH other ports need to be opened up for FastSCP to work, which increases the attack surface of the ESX host. Some of you might have security policies in place, this might be the time to start reading it.

Don’t get me wrong, it’s not that I’m telling you not to use FastSCP cause it’s a wonderful tool, but it might not be what you are looking for. If you do require an encrypted file transfer WinSCP would be the way to go. WinSCP even gives you the option to pick between the different encryption types. In other words, think before you use…

Compare your hosts…

· ·

One of the most promising features in my opinion for the upcoming version of ESX definitely is “Host Profiles”. With host profiles you can ensure that each and every single ESX Host has been installed in the same way. But this feature isn’t available yet, and you would probably like to know if at least all hosts in a Cluster share the same LUN’s and/or Portgroups.

Well, it’s no surprise probably that Hugo Peeters created a script that does exactly that:

This Powershell script generates an overview of any items that are not available to every ESX server in a VMware cluster. These items might prevent your vm’s being vmotioned by DRS or restarted by HA. Pretty serious business, I’d say!

The items involved are:
1. datastores
2. LUNs (important when using Raw Device Mappings)
3. port groups

Hugo exports the output to a nice html file so no more importing to Excel needed or whatever.

Hop over to Hugo and pick up the script. The link is at the bottom of the article!

Check your VM’s alignment…

· ·

I’ve been test driving a script called “mbrscan” for a while now. Today I noticed that this script had already been released a couple of weeks ago. The cool thing about the script is that you can check the alignment of the VM’s filesystem from the outside. The script runs directly on the service console of ESX. NetApp’s Nick Triantos describes it as follows:

There’s a new utility that has been added, called mbrscan. The purpose of mbrscan is to identify whether or not a VM has properly aligned partitions. The script will run successfully under two conditions: a) The VM is powered off b) the VM has VMsnaps. The script will error out if none of the above two conditions are satisfied simply because the VMDK(s) are locked.

This can be very useful to identify possible performance issues within just a matter of seconds. Combine this command with “vmware-cmd” to create and remove snapshots and you’ll have the results for you entire environment within minutes.

Now that you just received your results the real question would be:”How am I going to modify this without destroying the data?”

At this point in time that’s not possible. But I know NetApp is working on a tool called “mbralign”. This tool will make it possible to align the filesystem from outside the VM.

The mbrscan tool is part of the “Unified Host Utilities Kit” which reached version 5. The toolkit isn’t available for everyone, you will need a now.netapp.com/ to be able to download it.

UPDATE: MBRSCAN is a binary not an editable script, and the script version has been floating around for a while now…