Yellow Bricks

by Duncan Epping

ESX

Train Signal

· ·

Almost a year ago I wrote an article on a CBT by Train Signal. I really enjoyed watching the CBT and that says a lot coming from someone that never used to be a CBT fan. In the end the ease of learning when and wherever you want is what convinced me. Another reason to use a CBT instead of a classroom training is costs, which is most definitely a valid reason in these times of financial crisis.

If you’re not familiar with CBT’s check out this example:

I managed to get a discount for my readers, buy one of the virtualization related(VMware ESX, Server, Workstation etc) CBT’s and get a 25% reduction! All you need to do is head over to Train Signal and enter the following coupon code “YELLOWBRICKS”. And by buying a CBT you also support Yellow-Bricks.com!

High Availability “Deepdive” page

· ·

I’ve just created a new Page. This page will also deal about VMware HA. I threw all my “deepdive” posts into one page which makes it easier to find for you guys and search engines. But most important, easier to maintain. When I’ve got more technical in-depth information I will add it to the page.

Check it out and let me know what you think.

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” )

Permissions and roles

· ·

I was just troubleshooting a problem with permissions and roles at a customer site within vCenter. For some weird reason we could not create a VM. I hardly ever use this functionality and if I do it’s mostly on a “Hosts & Clusters” level.

This customer wanted to set permissions on a “HA-DRS” Cluster level. Each cluster will be administered by a different group of admins. These admins should not be allowed to do any administrative tasks on one of the other clusters in vCenter. Half of the setup worked, as in the admins could do certain tasks on the ESX hosts, but there was no way they could create VM’s.

I’ve browsed through my documentation but couldn’t find anything useful but luckily VI:OPS contained an excellent document on this topic: VI3 Roles and Permissions.

I did a copy and paste of the information that clarified the problem we were facing:

VMs appear in the inventory in two places: under the “Virtual Machines and Templates” view and the “Hosts and Clusters” view. This is also reflected in their privilege inheritance: VMs inherit privileges from both the containing host/cluster object as well as the containing VM/Template folder. Under Hosts and Clusters, possible containing objects include: folders, clusters, hosts, and resource pools. The two views and hierarchies become unified at the top level datacenter (or any folder that contains the datacenter)

Certain tasks require privileges on both sides of the hierarchy. For example, to create a VM, you need to have the “VM > Inventory > Create” privilege on a VM folder (in the VM view) as well as “Resource > Assign VM to Resource Pool” somewhere on an object in the Host view (folder, cluster, host, or resource pool). If you have a role which contains both these privileges, and you assign it at the datacenter level, it will propogate down both sides of the hierarchy. If, however, you want to limit its scope, then you’d need to apply it separately to individual subsections on each side of the hierarchy.

In other words, creating VM’s requires permissions on both levels “Datacenter” and “Cluster”.

vimsh, what can I do with it?

· ·

Vimsh(and vmware-vim-cm) is probably one of the worst documented commands out there. At the same time it’s one of the most powerful commands(I know it’s a shell…) out there. You name it and “vimsh” does it. Most of you ran into the “enabling vmotion” from the Service Console problem when first starting out with scripted install. Vimsh solves this:

/usr/bin/vmware-vim-cmd “hostsvc/vmotion/vnic_set vmk0″

As you can see “vimsh” is very powerful, but most of the other command-line stuff can be handled with the “esxcfg-*” commands. Well almost, for instance we talked about enabling autostart in my previous post. According to the KB article you must edit the file “/etc/vmware/hostd/vmAutoStart.xml”. Editing this file can be dangerous, I guess this goes for most ESX configuration files. During the Dutch VMUG I had a short chat with Wil van Antwerpen, Wil told me he was busy documenting the “vimsh” “command” in a wiki. After I published the enabling autostart blog Wil emailed me that this could and should be done with “vimsh”. I fully agree with Wil:

vmware-vim-cmd /hostsvc/autostartmanager/enable_autostart true

This enables the autostart functionality without manually editing the files. But I guess you would like to check if it’s enabled or disabled:

vmware-vim-cmd /hostsvc/autostartmanager/get_defaults

The big question remains, how do I know what I can and can’t do with “vimsh”. Well that’s the main reason for this post, as I said Wil has been very busy documenting “vimsh”. Wil created VI-Toolkit.com. VI-Toolkit.com contains a section on vimsh. Besides the the info that the vimsh command provices Wil added sample code. The sample code can be very usefull, but the search function is even more useful. Searching the vimsh documentation provides you with a fast way to check if a specific configuration action can be scripted with “vimsh”. For instance a search on “vimsh role” returns the following:

* Vimsvc/auth/role add
==== vimsh vimsvc/auth/role_add ==== Usage: role_add roleName [priv0] [priv1] [priv2] [priv3] [priv4]
171 B (24 words) – 14:32, 26 December 2008
* Vimsvc/auth/role permissions
==== vimsh vimsvc/auth/role_permissions ==== Usage: role_permissions roleName
1 KB (118 words) – 22:26, 28 December 2008
* Vimsvc/auth/role remove
==== vimsh vimsvc/auth/role_remove ==== Usage: role_remove roleName [failIfUsed]
123 B (16 words) – 14:34, 26 December 2008
* Vimsvc/auth/roles
==== vimsh vimsvc/auth/roles ==== Usage: roles
7 KB (550 words) – 21:50, 28 December 2008

I guess I can sum up this blog post in just one line:”Bookmark VI-Toolkit.com and add it to your RSS reader!”. Be sure to not miss out on anything regarding “vimsh” or any of the VI Toolkits that Wil be be describing and aggregating source code for. The “vimsh” section alone is already 345 pages large and it will continue to grow even more. Keep up the great work Wil and it was nice meeting you in person!