PowerCLI: Delete all snapshots by name

I have the issue that we use a cloud automation software, which for whatever reason failed to delete the hypervisor snapshots.

Now I was looking into a quick way to delete all those 520 snapshots with PowerCLI, and I found something pretty quick.

 

Based on that, I came up with my own quick PowerCLI one-liner, that’ll list all VMs and their snapshots:

Now, I could use another one-liner to delete all snapshots, that’ll look like this:

However, this will either crash an ESXi host (because the amount of the snapshots is too much) or overwealm the storage. So in the end I used a script like this:

This’ll limit the maximum amount of snapshots to delete at times to 5 (or 10 if you change the $maxtasks value).

Quick-Add a bunch of Virtual Machine Port-Groups from CSV

Well, I’m currently migrating between different cluster layouts, and I had to create the new PortGroups on the old hosts, in order for me to switch between old and new hosts.

 

And the corresponding CSV would look like this:

 

VMware templates: post-processing for SUSE Linux Enterprise Server and openSUSE

Well, I’ve been fiddling around with SLES and openSUSE VMware templates. I know it’s a stupid idea when you have a PXE server from which you could install this in a matter of minutes (seriously the SLES PXE installation takes about 5 minutes).

However, when dealing with DMZ’s (yeah, they exist!) you usually don’t have any PXE servers there. So I decided to go with simple VMware templates (like we do with Windows already), but had to iron out a few kinks.

  1. There’s no way to run a set of scripts after the deployment scripts from VMware have been run
  2. The hostname isn’t changed everywhere (/etc/postfix/main.cf for example)

 

So of I went and wrote a short (70 line ..) init script, which will do exactly that.

You’ll also need to create a file (/etc/template), which’ll hold the template’s hostname and will be used for the comparison if VMware’s post-processing is already finished.

vmware-config-tools.pl finished with “Could not find Parent Node”

Well, today I encountered a old problem (or so I thought). Basically a specific udevadm version causes the vmware-config-tools.pl script to error out like this:

 

I’ve had encountered this before in the past, and before there was some explanation on the VMware forums, which I couldn’t locate. Lucky me, the VMware Tools updater keeps modified versions of vmware-tools-config.pl around. So I ended up creating this short diff, so that I may find it in the future – if I still need it:

 

VMware ESXi – Free memory limits corrected

Well, a coworker of mine asked me about this. Since I didn’t know (yeah, I don’t know everything) I went to my trusted friend – Google – and searched for it. There seems to be a lot of confusion about this, so I thought I’d clarify this.

I ended up putting a license to one of my hosts in vCenter.

VMware ESXi Free Edition  Memory Limit

 

Yeah well, the host has a bit more memory than the allowed 32GB vRAM per Socket (the host has two sockets) – thus you’re allowed to have 64GB RAM if your host has two sockets.

Installserver: Publish a VMware ESX ISO – register-vmware

Here’s an old script, that also uses the magic provided by pxe-menu-generation (the script I posted before), but for VMware ESX/ESXi.

VMware Auto Deploy already registered / RuleEngine

I had this weird plugin error the other day which bothered me on Friday. I decided to go fixing it. So after poking around in the vCenter installed software list. I couldn’t find the Auto Deploy in the list, so I figured due to my recent vCenter reinstallation while keeping the database, I forgot to reinstall Auto Deploy.

I went ahead and started the Auto Deploy setup from the DVD again, until I received this weird looking error. Apparently the setup thought (and decided correctly) that Auto Deploy was already installed in my vCenter.

So after a bit of googling, I found this nice explanation on how to manually deregister Auto Deploy from my vCenter. So here are steps retyped:

  1. Run the setup an hold at the window where you’re informed that Auto Deploy is already installed. Copy the MSI package from %TEMP%{RANDOM-GUID} to C:TEMP
  2. Unpack the setup files from the msi
  3. Manually deregister Auto Deploy using autodeploy-register
  4. Run the Auto Deploy setup again

2. Unpack the setup files:

Open a command prompt and extract the msi using msiexec

3. Switch to C:TEMPautodeployProgram FilesVMwareVMware vSphere Auto Deploy and run autodeploy-register.exe against your vCenter installation

4. After that command completes, you simply can run the setup from the DVD again. Afterwards the RuleEngine errors were gone (simply because Auto Deploy is installed again) and Auto Deploy is working again.

Reoccurring memory limits in vCenter

We recently had, after we migrated from vSphere 4 to vSphere 5, a memory limit in size of the configured memory on each and every VM. Since memory limits on VM level pretty much destroy performance, I went ahead an wrote this simple script to remove all memory limits on all VMs that don’t have “Unlimited” configured:

This script is basically what the guy over at get-admin.com did, just only for memory limits.

PowerCLI & Windows jump list for recent items set to zero

Today I had to install PowerCLI on my workstation. When I tried launching it for the first time, it simply opened and closed again instantly. After browsing the VMware community for this error and not finding a useful solution, I ended up googling the error. As it turns out, this only happens when you did set the “Number of recent items to display in jump lists” to something less than 4.

After changing the limit to something greater than 4, it just works. This appears to be a Powershell bug.

VMware Consolidated Backup and TRANSPORT_MODE=”hotadd”

As the title says, I’ve been playing with vCB (inside a VM) and the TSM integration with newer (>6.0) clients for work. Result of all this work should be a feasibility study. We’re currently thinking about replacing our VMware server(s) with ESXi. But as most of you know, if you install ESXi, you simply can’t install anything (well, you can .. on ~100KB of disk space, which is compared to a TSM client weighing roughly 120MB nothing!). As we would like the possibility to backup VMs on image-level, I went looking at solutions.

  1. VMware Data Recovery
  2. VMware Consolidated Backup
  3. vRanger, ……

As I was looking for something that wouldn’t cost us any money (thus excluding the third), I took a look at vDR and vCB. One point I do have to give to vDR is, that it’s damn fast. Only bad thing about vDR is that it doesn’t integrate at all with TSM, and it ain’t supported to install a TSM client inside the vDR VM. So vDR was also done for.

Only remaining thing was vCB. I remember way back when TSM didn’t support vCB directly, at which time it was *quite* the hassle to configure. But with newer TSM clients (as in the newer 6.x ones), IBM decided to integrate support for it. Which makes setting things up quite easy. You may think at least.

Since I wanted to use “hotadd” as transport mode for the vmdk’s (which is basically creating a snapshot of the vmdk and assigning that snapshot to the vCB VM), I did have to tinker around with some JavaScript files in %ProgramFiles%VMwareVMware Consolidated Backup. Sure, it isn’t supported by VMware (which is a bit lame since they announced the EOL for vCB with the upcoming vSphere version), but I didn’t want to open a support request. I’m lazy, yep:

Change DEFAULT_TRANSPORT_MODE in utils.js from “san” to “hotadd“. But apparently this only solved the backup method for vmdk-level, but not for file-level backups. The file-level is still gonna use nbd (network block device), which kinda sucks since the backup is going out via network.

After doing that, the hotadd mode is still gonna fail, since apparently the denoted “VMware Consolidated Backup User” (vcb-user in my case) also needs permissions onto the datastore. The permissions the handbook sets for the user are okay, you just need to apply that role to your datastore(s) containing the VMs you want to backup too! Otherwise vcbMounter is gonna fail with a rather cryptic error telling you that it doesn’t have sufficient rights to create a linked clone.