Posts Tagged ‘Scripting’

Force vCenter Server update to reflect .vmx changes

May 2nd, 2009

Virtual infrastructure administrators may edit a VM’s .vmx configuration file by hand with vi or nano (my favorite) for a variety of reasons. Efficiency through bulk changes via scripting, troubleshooting a problem, adding unsupported/undocumented .vmx parameters, or a higher comfort level with command line interfaces to name just a few.

Modifying .vmx files by hand is all well and good. Administrators have been doing since since for as far back as I can remember with VMware products. There is an annoying caveat with VMware vCenter Server however. Changes made by hand in the .vmx file may take a while to show up in the Virtual Infrastructure Client. For example, if I’m looking at a VM’s configuration summary in the VIC, and then modify the .vmx file to change the memory configuration from 256MB to 512MB, save and exit, nothing seems to happen in the VIC. I’m looking at the VIC and configured memory of 256MB is staring back at me. It may end up staying this way for quite some time. Removing the VM from inventory and re-adding it to inventory will resolve the issue but that’s drastic, annoying, and it presents the opportunity for more problems. For instance, what if during the import of the VM it lands in the wrong resource pool or VM folder? Suddenly you’re exposed to potential resource contention issues impacting SLAs and incorrect permissions or patch management baselines on the VM.

There’s an easier way that involves a lot less risk using two vimsh commands at the service console. Here are the steps:

  1. Log on to the service console on the host that the VM is registered on.
  2. In the service console, make the configuration change in the .vmx file and save it.
  3. In the service console, run the command vimsh -ne “vmsvc/getallvms” |grep <vmname> to obtain the VmID of the VM. The VmID will be the first number displayed on the left. Excluding the |grep <vmname> portion of the command will display all VMs registered on the ESX host.
    vimsh -ne “vmsvc/getallvms” |grep knoppix
    80 knoppix [msa1000_lun3] knoppix/knoppix.vmx otherLinuxGuest vmx-04 Veeam Backup: Time [4/30/2009 5:46:41 AM], Backup host [SKYWALKER], Backup file [V:\VeeamBackups\Galleon Cluster Backup.vbk]
  4. In the service console, run the command vimsh -ne “vmsvc/reload <VmID>” using the VmID obtained in the previous step.
    vimsh -ne “vmsvc/reload 80”
  5. After a few seconds, the configuration change will be received by the vCenter Server and will be reflected in the VIC.

vimsh is a very powerful command line tool. To check out more of its goodness, take a look at xtravirt’s vimsh documentation.

VI Toolkit Quick Reference Guide

March 14th, 2009

Virtu-Al (Alan Renouf) has posted a great two-page cheat sheet for the VMware VI Toolkit version 1.5.

This gem of a document is similar to VI3 card created by Forbes Guthrie over at Excellent job gentlemen!

While you’re at Virtu-Al’s site, check out all the sample code and scripts.  Chances are you could implement one or more of these puppies in your environment to configure ESX or ESXi.  Scripting is definitely one of the ways to become more efficient and agile and it’s a great way to ensure consistency across your environment.  PowerShell and VI Toolkit is where’s it at.  I think they are going to be here for a long time.

He sed / she sed

November 14th, 2008

Sed (Stream EDitor) is a powerful Unix and Linux utility which has the ability to parse text files and make changes.  It’s practically a gold mine for scripting.  Fortunately, this utility has been part of the modified Red Hat Enterprise Linux service console (COS) in VMware ESX current and previous versions.  Used in my deployment scripts, it serves me well for the purposes of rapidly standing up new or rebuilding existing ESX hosts.

Admittedly, I don’t have a real strong Linux background.  My foundation has been primarily Microsoft Windows, and before Windows, Microsoft DOS and Commodore 64/VIC-20 BASIC programming which actually did provide me a nice basis for command line going forward.  When I began building ESX hosts, I soon discovered scripting was where it’s at for efficiency and more imporantly consistency.  I learned the use of sed by borrowing snippets of example code available on the internet and VMware Community forums.  By the way, the sed rabbit hole goes very deep.  I’ve only learned the find/replace function of it to get me by for ESX scripting which is just the tip of the iceberg.

I learned something about sed recently that probably would have helped me during my learning process of sed a while back.  The majority of sed examples found on the internet (and probably in the man pages) use a forward slash / as the delimiter.  This is because the / is natively used in ed, more, and vi.  What I discovered is that any character can actually be used as a delimiter.  This would have been helpful for me to know earlier because some of the scripting I do involves Linux paths which of course make use of the forward slash.  Adding an additional forward slash for sed scripting made for an awful lot of forward slashes in one line and at times made my eyes hurt.  Similar to building a complex Microsoft Excel formula whith a lot of parentheses and trying to keep track of the number of open parens versus the number of close parens. 

Let me show a few examples and maybe you can see what I’m talking about.

Here’s one line of an actual script I use to add the full path display in the COS (there are three / delimiters in this example, see if you can find them):

sed -e “s/\\h \\\W/\\h \\\w/g” /etc/bashrc.old > /etc/bashrc

Forward and backwards slashes that butt up against each other are commonly reffered to as “the picket fence effect”.  In the example above, for my sanity I could have chosen a different delimiter, such as an underscore, so that the script looked like this instead:

sed -e “s_\\h \\\W_\\h \\\w_g” /etc/bashrc.old > /etc/bashrc

Here’s another example which prevents the VMFS2 module from loading at startup on ESX3 hosts:

sed -e “s/echo \”vmfs2 vmfs2\”/\#echo \”vmfs2 vmfs2\”/g” /etc/init.d/vmware.old > /etc/init.d/vmware

More picket fence, not quite as bad though.  Maybe this time I use use the asterisk as a delimiter so that it looks like this instead:

sed -e “s*echo \”vmfs2 vmfs2\”*\#echo \”vmfs2 vmfs2\”*g” /etc/init.d/vmware.old > /etc/init.d/vmware

So it boils down to choosing the right sed delimiter for the line of code you’re working with.  Kind of like choosing the right bottle of wine for your meal, and choosing the right cigar for afterwards.

I’ve always said that much of the fun of this career I have chosen is the opportunity to learn something new every day and put it to practical use.  Today has been no exception.  Some days are more fun to learn than others.  It depends on the conditions and circumstances…