UUIDs are wonderful! Really. They’re just not all that easy to get to, at least not when you need more than a few of them at a time. That is where this script comes in:

# get-uuid.ps1
#
# Takes either a VMHost or VM object from the pipeline, returns the corresponding UUID.
Begin {
    $VMHost_UUID = @{
        Name = "VMHost_UUID"
        Expression = { $_.Summary.Hardware.Uuid }
    }
    $VM_UUID = @{
        Name = "VM_UUID"
        Expression = { $_.Config.Uuid }
    }
}

Process {
    $InputTypeName = $_.GetType().Name
    if ( $InputTypeName -eq "VMHostImpl" ) {
        $_ | Get-View | Select-Object $VMHost_UUID
    } elseif ( $InputTypeName -eq "VirtualMachineImpl" ) {
        $_ | get-view | Select-Object $VM_UUID
    } else {
        Write-Host "`nPlease pass this script either a VMHost or VM object on the pipeline.`n"
    }
}

Excusing the line wrap and odd orange color, you can see in the “Begin” block, that we define the two properties, based on their location in the API. In the process block we do some error checking, and then grab the relevant UUIDs.

The output looks similar to:

[VI Toolkit] C:\> get-vm | select -first 1 | .\scripts\get-uuid.ps1

VM_UUID
——-
50205819-19c6-965d-8d70-dbad7c43e598

[VI Toolkit] C:\> get-vmhost | select -first 1 | .\scripts\get-uuid.ps1

VMHost_UUID
———–
44454c4c-4a00-104d-8042-cac04f544831

The script can be downloaded here. Please note, that it was discovered while researching this post that the VMHost UUIDs stored by vCenter 2.5 U3 may or may not actually be unique. I have an active SR around this, and will make a follow up post once we get it sorted.

Well, I’m not sure how “Extreme” it is, but over the weekend VMware’s Developer community site got a face lift.

Unlike Joan Rivers, this one actually kinda looks good afterwards:

Since my first few posts on this got a bit of attention, I thought I’d add some more to this. In today’s post we’ll cover adding or deleting a route, and setting a default route. I’ve got requests for others that will keep the next few weeks worth of VIX posts busy.

We’ll cover this against both a Windows and a Linux guest, because well… VIX is flexible like that. Remember, if you have any trouble, check that your VMware Tools are running, your command syntax is correct, and that you have the right user & password settings.

On Windows:

Traditionally this would be done by logging into the guest OS, and running one of the following commands:

Adding:
Temporary Route: route add 192.168.100.0 mask 255.255.255.0 192.168.15.1 1
Permanent Route: route add -p 192.168.100.0 mask 255.255.255.0 192.168.15.1 1

Deleting:
route delete 192.168.100.0

Doing this in VIX is as simple as:

Before:

Adding:
vmrun -T esx -h https://esx/sdk -u cody.bunch -p password -gu guest.user -gp guest.password runProgramInGuest "[datastore] vm/vmx.vmx" c:\windows\system32\route.exe add -p 192.168.100.0 mask 255.255.255.0 192.168.15.1

Deleting:
vmrun -T esx -h https://esx/sdk -u cody.bunch -p password -gu guest.user -gp guest.password runProgramInGuest "[datastore] vm/vmx.vmx" c:\windows\system32\route.exe delete 192.168.100.0

Setting the default was accomplished back in our setting the IP address post.

C:\Program Files\VMware\VMware VIX>vmrun -T esx -h https://esx.example.com/sdk -u nerv\cody.bunch -p apassword -gu Administrator -gp anotherpassword  runProgramInGuest “[sanstorage1] test/test.vmx” c:\windows\system32\netsh int ip set address “Local Area Connection” static 192.168.15.25 255.255.255.0 192.1

On Linux

On Linux, where my knowledge is quite limited, I’ve come to understand (thanks Google) that it’s as simple as the “route add –net” commands to add and delete routes. I did find however, that for making this route persistent, can vary across distro of choice, and thus I’ve not included it here.

Adding:
route add –net 192.168.100.0/24 gw 192.168.15.1

Deleting:
route del –net 192.168.100.0/24 gw 192.168.15.1

In VIX:

Before:

Adding:
vmrun -T esx -h http://dc01.nerv.local/sdk -u user -p password -gu root -gp rootpassword runProgramInGuest "[Local
Storage] shell.nerv.local/shell.nerv.local.vmx" /sbin/route add -net 192.168.10
0.0/24 gw 192.168.15.1

Deleting:
vmrun -T esx -h http://dc01.nerv.local/sdk -u user -p password -gu root -gp rootpassword runProgramInGuest "[Local
Storage] shell.nerv.local/shell.nerv.local.vmx" /sbin/route add -net 192.168.10
0.0/24 gw 192.168.15.1

See!

get-datacenter MyVC | get-vm | Get-NetworkAdapter | Where-Object { $_.Name -like "*1"} | Set-NetworkAdapter -NetworkName NotThatNetwork -Confirm:$false

So, say you provision all of your VM’s on one host, with one set of networks, that is completely removed from the remainder of your infrastructure. You then Cold-Migrate the new VM’s to their new homes. You now need to chance the network names to match. What you say? You have a dozen, a hundred of them to change? The above PowerShell one-liner will take care of all of that for you.

Questions? Comments? Leave em in the comments.

Found out from VM/Etc and a few other sources today, that the recent opening of the ESXi 3.5 Update 3 API’s was an accident, and they’re going to be locked down again soon. That sucks.

What happens in 3 days? You know, don’t you? Well, I’m sure you do. That said, here are 3 ways to configure a vSwitch. (Yes there are more ways than this, but alas… one has to stick with the theme.).

Using the Virtual Infrastructure Client:

Using The VI Toolkit (PowerShell)

Before:

PowerShell:

PS C:\> get-vmhost 192.168.15.253 | New-VirtualSwitch -Name Example2 -Numports 128

Name       Num Ports  Num Ports  Mtu   Key
                      Available
—-       ———  ———- —   —
Example2   128        127        1500  key-vim.host.VirtualSwitch-…

After:

Using the Remote CLI:

Before:

Rcli:

C:\Program Files\VMware\VMware VI Remote CLI\bin>perl esxcfg-vswitch.pl –vihost 192.168.15.253 –server dc01.nerv.local –add Example3

Enter username: cody.bunch

After:

Tell me about some other ways you do this in the comments.

One of the greatest things about working with/on VMware is the attention they pay to the community that has built up around their products. The community itself becomes a great resource for feedback to the company and for support to new users. Their PowerShell community is no exception to this. Here is a post on their PowerShell blog highlighting their commitment to the community, as well as pointing out several good tips/tricks.

Templates can be quite big and pose a challenge to storage management, so it’s nice to be able to move them around. Moving templates across datastores is something the VI Toolkit doesn’t do out of the box, but not to worry, Niket shows how you can move templates across datastores by accessing the VI API.

 

Even though the VI Toolkit doesn’t have a cmdlet for it, Hal shows that it’s pretty easy to reboot or shut down an ESX host with PowerShell.

If you need to add an unregistered VM to ESX or VC, Luc shows how you can register a VM based on its VMX file. One of these days we’ll be adding an Add-VM cmdlet that will make this really easy, but this is a workable solution in the meantime.

 

With the Toolkit it’s really easy to get a listing of all disks associated with a VM, however it doesn’t help you identify what disk it is within the VM itself. This week, a couple of solutions have been proposed, one from adavidm and one from Hugo Peeters. Both these scripts rely on a combination of some of the advanced data available through VI API and also getting information out of a Windows VM via WMI

As a demonstration of the power of VIX, I’ve chosen to show you how to change IP addresses of a Windows VM. You may want to buckle up for this.

First, grab the VIX API installable from VMware’s site. In this case we’ll be using the Windows version (because that is the VM I happen to be writing this post from). The install is quick and puts all the files into “%PROGRAMFILES%\VMware\VMware VIX”.

Lets get our command prompt open:

Cool, now lets check the IP of our Windows VM:

Now, lets change it:

C:\Program Files\VMware\VMware VIX>vmrun -T esx -h https://esx.example.com/sdk -u nerv\cody.bunch -p apassword -gu Administrator -gp anotherpassword  runProgramInGuest “[sanstorage1] test/test.vmx” c:\windows\system32\netsh int ip set address “Local Area Connection” static 192.168.15.25 255.255.255.0 192.168.15.1

(That is all one line, the blog wrapped it)

Now for the lovely error!

Not rightly sure on that one. I’ve opened an SR for it. We’ll see how it goes.

So this will need further investigation on my part. On the surface it looks really cool:

“The VIX API allows development of scripts and programs to automate operations in guest virtual machines.”

Read that again. Now process. Automate operations IN the guest VM. Go here for the release notes.

This has been reported by vm/etc and vinternals, but I think it deserves quite a bit more attention. Take a moment to read the posts. The free version of ESXi Update 3 now supports read/write FULL remote admin via the RCLI, and the other api’s. Meaning, that VMware took and made it just that much cooler.  Thanks!