Nov 122010

While building some basic VMware Training I thought I needed a lab environment for my colleagues to test things out. For this I simply created an empty VMware Template in ESX and I imported this template into VMware Lab Manager (did I already said that I love this product?).

So After creating a basic environment containing a DC, a VCenter, an XP machine and 2 ESX servers I wanted to install ESX 4.0. However during this process I received the following error:

“Could not format a vmfs volume.” At first I thought, “What the hell???? It’s just a VMDK file… Just format that bloody…” So of course I started shouting at my computer like every technical engineer would do… Luckily I was working at home using a VPN connection to our lab so no one could hear me. 😉


I was a bit intrigued with it… what went wrong? I thought that this would become interesting. So after I found my senses I popped up a new browser tab and went to Google. After a while I found a blog post stating that it might have to do with NFS storage. However I’m running this on our FC SAN environment. So although this might be an issue, it wasn’t the exact issue I had. However it made me think about it.

VMware Lab Manager uses linked clones. What if… what if this was causing the issue? So I created a simple lab with just one ESX server inside of it, and I enabled the option “Full Clone”


Ok that seems to work. I could install ESX! But now what? Can I still use the “capture to  library” option to capture and share my setup for my colleagues? This is because there is no option to do a full clone for the ESX servers when I choose to clone to workspace. It states:  “Create a Linked Clone of All Virtual Machines or Selected Virtual Machines”

Nope, that didn’t work either.

Ok, But then what. How can i create a virtual test environment to teach my colleagues some VMware stuff without going to expensive training. They don’t need to certify themselves, they only need to know the basics about it…

But still there is an another option, what if I use Archive to Library instead of Capture to Library and then share it? That might work out since over here I do get an option to create full clones. Also I could share this one and in this case you also won’t have an issue with customizations and stuff.


So creating the archive is what I did. After a while (enough time to drink some coffee) it was finished. But now what, I still couldn’t use it?

I still need to deploy it to my workspace in order to get it work, so I choose from my library the option: “Clone to workspace”

And hey, now I get an Option to do full clones. That looks promising isn’t it?


So testing this setup brought me to a “Hurray!” moment because It passed the 10% error limit. 🙂 And yes it did finished the installation.


I took me about 2 hours to solve and test this out, shouting included of course. 🙂 It’s time for a nice cup of coffee.

Anyhow, to recap the issue. The problem that the vmfs volume couldn’t be formatted lies in the fact that that I was using linked clones or an original ESX configuration. Somehow ESX didn’t liked that and crashes. Full clones however are working fine, though you might understand that this can become an issue when you lack storage.

May 032010

Since I’m currently busy with installing multiple ESX servers in our test environment, I needed to create about 32 DNS records. Well since I’m lazy and I’ve really been loving Powershell I thought it would be a nice challenge to use PowerShell and of course the powerful DNScmd command. Since we have a logical IP plan, I could use the following script.

1..32 | % {iex ([string]::format(“dnscmd /RecordAdd ESXhost{0} /createPTR A 192.168.10.{0}”,$_))}

Of course there are many other ways. For example, using a CSV file to import the DNS records.

For example:

Import-CSV c:\DNS.csv | foreach {dnscmd /RecordAdd $_.Zone $_.hostname /createPTR A $_.IPaddress}

However, keep in mind that PowerShell uses comma separated files and not the semicolon separated file which Excel automatically creates. So for example, use:


Instead of:


Mar 292010

While creating a deployment script for ESX using UDA (Ultimate Deployment Appliance) I found something pretty annoying which took some time before I figured it out. While creating my post script, I thought to create it in the /tmp folder. Since the /tmp directory is IMHO just a temp directory I figured that it would be the best place. Also, because I had to install 32 ESX hosts, I had no plans to do this manually. 🙂

Anyhow, In this script I would create just the VMkernel port for VMotion. The script would be run only once during the first boot. But somehow it didn’t run. After googleing and searching forums I finally found this article from VMware:

User-created files in the ESX /tmp directory are deleted with each host reboot
If you or the users you support store temporary files, such as application-generated log files, in the ESX /tmp directory, you will lose these files each time the host reboots.

Workaround: Do not use the ESX /tmp directory to store user-generated files and directories.

So… for some reason the VMware team “decided” to clear out the /tmp directory. Don’t know why though. However, after changing the path it worked flawlessly. 🙂 I don’t know if this will be fixed in the future but I do know this is something to watch for. During some searches, I noticed it worked in previous versions of ESX, however I don’t have any experience with that. Anyhow, sometimes I shouldn’t be lazy and just read the release notes. Even if they are huge. 🙂