Sunday, June 21, 2009

Going to VMworld 2009!

Oh happy day! Yesterday, we got final confirmation that a colleague and I are going to VMworld in San Francisco in August. Due to the economic crisis and all it has been a bit of a struggle to get the approval, so it was quite the relief.

I was in Las Vegas last year for VMworld 2008 and it was cool so I'm really looking forward to San Francisco this year.

Saturday, June 20, 2009

Howto: Getting the Navisphere Agent for ESX Server

There are several post in the forum about where to download the EMC Navisphere agent. Navisphere is an agent that you install in the Service Console on your ESX Server which helps to manage EMC Clariion storage systems. Click here for more info.

The agent is not publicly available for download. If you have a partner login, then I believe you can download it at .

The way to go to get the agent is via your storage department. Either they can get the login for you or have them contact EMC, then they will send the software. Navissphere is shipped together with the Clariion storage systems on the Navisphere Server Support CD (see this article page 16). But contact EMC if you want to be sure to have the latest version.

In this document on page 7, it is stated that Navisphere v6.22 is compatible with ESX v3.5

Wednesday, June 17, 2009

ESX 4.0 in Workstation - requires Intel-VT

I have been running ESX 3.5 and ESX 4.0 in VMware Workstation 6.5.1 for a while on my Lenovo T61 from work without any problems. A prerequisite for doing this, at least for ESX 4.0 (an probably also for Hyper-V) as it runs 64-bit, is that the CPU supports virtualisation mode - which in the Intel terminology is called Intel-VT - an which has to be enabled in the BIOS. The T61 is about one year old and has Intel-VT, so I thought that it was standard on all newer Intel processors. But oh-no, this is not the case. I recently purchased a Dell Studio 17 for private use with a Intel Core Duo 2 T6400 processor and I thought that I was in the good house. But - no Intel-VT support. Everything else was in order, 4 GB of memory, Windows 7 64-bit and so on. This was a bit disappointing. If your're looking to buy a new laptop, then check that this feature comes with the CPU. I found an article on ZDnet which lists a number of processors and wheather they have Intel-VT enabled.

The following has been copied from the ZDnet article. YES means that the CPU type supports Intel-VT:

Saturday, June 13, 2009

vCenter Converter Standalone 4 - ports used

We're doing quite a few P2V conversions at the moment, and that means that we see all kinds of weird errors, conversion failures, and connection issues. P2V is definitely not an exact science.

One thing that is recommended to have in order is that proper network ports are opened.

VMware has written a good KB article that explains which ports are used.

If you have server with Converter Standalone installed on it, and you have trouble connecting to the source physical computer, then first make sure that Windows Firewall is disabled. If that doesn't work, then install the Converter application directly on the source computer. Then you will need outbound 443 TCP connection to vCenter (former Virtual Center) (it's assumed that port 443 TCP is open inbound on the vCenter server, of course).

To test if ports are open, open a CMD prompt and run following command:

telnet 'vCenter ip' 443

(without the ' ') If the DOS prompt goes black, then the connection is good. Othervise you will get a 'can't connect' or something similar)

If you P2V directly to an ESX server, then ports 902, 903, and 443 TCP are used.

If you, for some reason, can't get port 443 opened, then a workaround is as follows:

  • Install the Converter directly on the source system
  • If you have an existing test VM in the same IP range, then create a new disk and attach that to the test VM.
  • Make a Windows share on the new disk
  • From the Converter choose to export to standalone virtual machine in Workstation format and then coose to place files on the share just created
  • After export, change the VLAN to an IP range that doesn't have any firewalls blocking
  • Import the VM from within vCenter

Thursday, June 11, 2009

P2V of domain controller

Summary: Cold clone P2V of domain controllers works just fine.

We had to migrate two root domain controllers the other day at work. I knew that domain controllers in particular can give you trouble when being converted / migrated, so I researched it a bit and found a useful article on which linked to a very good VMware KB article . This KB recommends that in stead of migrating, then deploy a fresh VM and do a 'dcpromo' and then shut down the physical server after. I like this way as it moves the responsibility away from the VMware team and over to the application responsible.

However, we did not have enough time to do the recommended solution, so we whent for P2V. We did cold clone because hot migration is likely to go wrong and it is not supported by Microsoft.

There were FSMO roles on the DC's, so before we began, we had the AD guy move all the roles over to one of the servers. Then we took the other one down and P2V'ed it. We resized the disks to save SAN space which was not a problem. When it came back up, the AD guy tested and then moved FSMO roles over to the migrated DC. And then we migrated the other one. After both had been migrated, the AD guy tested again.

If your responisbility area does not cover the application layer, which it does not for me in this case, then arrange for an application responisble to test the app before it is released into production. It may sound banal, but it is sometimes overlooked when the pace is fast and only basic OS testing is done.

Time synchronization

There are several ways of setting up time synchronization. One important point is that there should be only one source for synchronization for all the DC's. There's a feature in VMware tools, where you can synchronize the VM against the ESX - this we did not use. We let Windows take care of the synchronisation. If you have a mixed environment of DCs (bare metal and virtual), then you can let a bare metal DC sync to an external source, and then let all the other DC's sync to the bare metal DC.

We had the PDC emulator sync with a dedicated physical NTP server, and then let the second DC sync with the PDC emulator. The ESX servers sync with the physical NTP server - but no synchronization between VM and ESX server. Read this article for further info on time sync.

Update: In a KB article (KB 888794) from Microsoft about considerations when hosting DC's in a virtual environment, there is one important paragraph about forced unit access (FUA) which has resulted in some confusion. The paragraph states:

"If the virtual hosting environment software correctly supports a SCSI emulation mode that supports forced unit access (FUA), unbuffered writes that Active Directory performs in this environment are passed to the host operating system. If forced unit access is not supported, you must disable the write cache on all volumes of the guest operating system that host the Active Directory database, the logs, and the checkpoint file. "

According to VMware, forced unit access (FUA) is supported on VMware. Here's the answer from VMware technical support:

-----Original Message-----
From: VMware Technical Support []
Sent: 24. februar 2010 11:25
To: (Jakob Fabritius Nørregaard)
Subject: Re: VMware Support Request SR# 1490632591

** Please do not change the subject line of this email if you wish to

respond. **

Hello Jakob,

Forced Unit Access is supported by VMware. A large number of customer's have virtualized Domain Controllers which is evident in the community forums.

Thanks & Best Regards

Derek Collins

Technical Support Engineer

VMware Global Support Services


VMware Technical Support Knowledge Base"

Saturday, June 6, 2009

Howto: 101 Scripting ESX server installation on vSphere 4

I have been wanting to look into scripted ESX installations for a while now but haven't gotten around to it untill now. At first glance it looks a bit complicated - there a several much used deployment tools around (e.g. EDA and UDA), people are posting bunches of deployment scripts etc. I wanted to know the absolute basics - what is the simplest way to script an ESX installation?

First off, I recommend that you download the ESX and vCenter Server Installation Guide and read pp. 43-58 on scripting installations. This documentation helped me to get started more than posts on the web.
On ESX 4, there are two built-in scripts that you can run when you boot the installation CD: 'ESX scripted install to first disk' and 'ESX scripted install to first disk (overwrite VMFS)'. But that's a little boring as these scripts can't be modified.

In stead, we can let ESX server generate a script for us based on your own installation. I like this way as it simplifies things compared to the very comprehensives scripts out there - and it fits to your environment. Better to have a simple script that works than to have a do-it-all script that doesn't. You can always expand it later.

When you install ESX 4 in the default graphical mode, then a Kicstart script (ks.cfg) with your specific settings is generated and placed in the /root/ folder of your ESX installation. Make a copy of this file, as this is the one we will be using as our base script.

This script is to be copied to the root of the installation ISO. To do that, you need an ISO modifying tool like MagicISO (you need to pay 29$ to make ISO's larger than 300 MB). Open the ESX 4 installation ISO in MagicISO and copy the ks.cfg file into the root of the ISO.

Now, boot your server with the ESX ISO. When the first installation screen shows as below, then hit F2 to get 'other options'. Then shift down to the 'ESX scripted install using USB ks.cfg'. We will not be installing from USB, we will just use the command as a template and modify it to get the ks.cfg script from the CD in stead.

Modify the boot options command like this:

Boot options initrd=initrd.img vmkopts=debugLogToSerial:1 mem=512M ks=cdrom:/ks.cfg quiet

That's it. This will do a basic scripted installation of the ESX 4 server...

Mini troubleshooting: I tried to reinstall the ESX server that I had already installed, which means that there is already a VMFS partitioned disk on the server. So the clearpart command needed the --overwritevmfs flag to work. Furthermore, in the partitioning section I had to comment out some lines and in stead uncomment the 'part' commands with the --firstdisk flags.

I have pasted the basic script below for reference.

----------------sample ks.cfg----------------------
# Don't edit script in notepad or Word. Use Notepad++ or like app


keyboard dk

auth --enablemd5 --enableshadow

#I have added the '--overwritevmfs' flag which is
#necessary when reinstalling an existing ESX

clearpart --overwritevmfs --firstdisk

install cdrom

#The encrypted password is taken from the original
#graphical install

rootpw --iscrypted $1$k364YM8i$CyveR0PWuw294uX8HLzcE0

timezone --utc 'Europe/Stockholm'

network --addvmportgroup=true --device=vmnic0 --bootproto=dhcp

part '/boot' --fstype=ext3 --size=1100 --onfirstdisk
part 'none' --fstype=vmkcore --size=110 --onfirstdisk
part 'Storage1' --fstype=vmfs3 --size=8604 --grow --onfirstdisk

virtualdisk 'esxconsole' --size=7604 --onvmfs='Storage1'

part 'swap' --fstype=swap --size=600 --onvirtualdisk='esxconsole'
part '/var/log' --fstype=ext3 --size=2000 --onvirtualdisk='esxconsole'
part '/' --fstype=ext3 --size=5000 --grow --onvirtualdisk='esxconsole'

%post --interpreter=bash

----------------sample ks.cfg EOF----------------------

Tuesday, June 2, 2009

New memory hot add feature in vSphere 4

In the new vSphere, there is a new feature - hot add memory and CPU. This is very cool as downtime can be avoided which is, at least in my company, very helphul during daily operations. To enable these features, do the following:
  1. Make sure the virtual machine hardware is upgraded to version 7 (right click the VM, choose 'Upgrade Virtual hardware', see below).
  2. Go to edit settings for the VM, then the options tab -> Memory/CPU hotplug and enable the two features (see below).
This is all very fine. However, for the features to work, you need a compatible VM OS. And Win2k3 Standard isn't supported. For Windows, it is primarily Enterprise Edition and Datacenter Edition that will work for win2k3. For Win2k8 at least hot add memory will work for all editions 32-bit and 64-bit. See the VMware Compability Guide or for compatible guest operating systems.

Update 2013.07.23: The CPU hot add will auto register the new CPUs in the guest OS for win2k8 R2 Datacenter and Enterprise edition (at least in vSphere 5), see compability chart here. Not for Standard edition. See demonstration here.

Monday, June 1, 2009

iSCSI on a Windows box with Starwind

If you want to run shared storage in e.g. a test setup, then Starwind's iSCSI application can be recommended. Earlier, I have tried Openfiler (iSCSI in a linux distro VM) which works fine, It's not too complicated to configure, but still it's much easier with Starwind iSCSI in a Windows environment. The application is free but there's a 2 TB storage limit.

Starwind installation guide. It's easy to install, just go next next done. Load the serial key, connect to the localhost (user: test, pw: test), add a new device, and then follow install guide page pp 5.

For a guide on how to configure iSCSI in ESX 3 and 4, click here

A typical test setup could be one physcial host with 8 GB of memory and one quad core cpu. Check for a list of compatible whitebox ESX hardware.

From ESX 4 it's possible to run ESX as a VM within an ESX. Even VMotion will work (go to for a demonstration). And if you have a VM with an iSCSI target running on it, then you have a full enterprise setup running on one box.