iSCSI multipath configuration from CLI only ESXi 4.0

I have already booked my VCAP-DCA exam for 20th of December to have a deadline. So I again started reading through VCAP-DCA blueprint and study guide by Edward Grigson. At the same time I making a task list of things to practice in command line as it is my weakest point in VMware knowledge alongside with scripting and power-cli. Still have 35 days to cover at least basics of those.

Yesterday, I have played with iSCSI multipathing on a lab that I just rebuilt from the scratch and decided to document all the commands I used to be able to refresh this knowledge couple of the days before taking the exam. I will  included all steps I took before I could have ssh access to my ESXi host. Surely, all this information can be easily found in Google, but it is nice to have all you need in one place, isn't it?

Brief description of the lab config:
I have two hosts: ESXi and ESX 4.0 and one FreeNAS virtual appliance. Each host has 3 vmnics. Vmnic0 is solely for management purpose. Vmnic 1 and 2 are configured in separate network for iSCSI connections. FreeNAS has only 1 Nic and 1 IP Address on which there are 2  iSCSI targets presented.

Let's start.

P2V conversion of a server with SAN disks attached

This is a short guide for those who had never done cold cloning of the server with SAN disks presented. It was my first experience and definitely not the last one so I decided to write down all steps I took.

P2V conversion process for me has been always quite simple. I always used vCenter integrated converter to run hot cloning since configuration of the the servers I had converted was quite consistent and simple, e.g. Windows 2003 or 2008, couple of volumes on local RAID1, standard windows services and applications running on the server.

However, this week I was asked to do P2V for several GIS servers running Oracle databases on SAN disks.  Surely, I could run hot cloning and convert those SAN disks into standard vmdk files, however, I didn't like the size of SAN disks (each is about 1TB) for the following  reasons: 

• it takes too long to move such vmdk files to another VMFS
• most of the VMFS datastores don't have enough free space to accommodate such disks. 

To be on the safe side I decided to google a bit for the best practices of P2V. I read couple of articles and found very useful link which I posted below. I also ran a quick test P2V conversion with a server with similar specs to my GIS servers to make sure I won't face problems with SAN disks presented as RDM disks to VM.

The adventure started when I tried to find VMware Converter's cold clone ISO. I couldn't find it anywhere until I found a post on VMware communities that explained where I can get it. First of all, your vmware account needs to have the proper license to let you download ISO file. Here you can find the latest version of VMware vCenter Converter BootCD. You can make sure it is there by clicking Show Details in Components section. Once  you click Download button you will be able to select only BootCD ISO file for download.

Ok, here comes step-by-step guide that worked for me, which doesn't guarantee it will work for you the same way :) take your time to go through all the steps and make sure they are relevant and correct for your environment.

1. First and most important thing is to collect as much information as possible source server. I found this very useful document called P2V Check list. Generally speaking, it is much more than a simple checklist. You can adjust it to your needs and situation, but basically, it will give you very consistent approach to P2V conversion. In my case it might be very useful if the P2V process would fail and I had to restore all services and configuration on the source physical server.
2. Disable all  services that are dependant on SAN disks. In my situation I had documented the status of all Oracle services first and then set their Startup type to Disabled. This is to prevent their failure or database corruption on the first power on of cloned Virtual Machine.  I will restore original status once I make sure RDM disks are correctly presented and recognized by VM.
3. Shut down the server and unpresent SAN disks on your storage controller. Here I  made a mistake. I unpresented SAN disk too late, when VMware converter had already scanned all hardware. So, when I ran the converter task it gave me the  "Unable to determine Guest Operating system". Once I booted server again from cold clone ISO the problem has gone.
4. Boot server from cold clone ISO. 
5. Setup networking - I used DHCP settings. The main thing is to make sure your switch port where the server is connected to is configured with Auto/Auto settings because you can't change Server's NIC speed and duplex settings from VMware Converter.
6. Run Import Machine task and go through wizard. I didn't notice anything special there that could make me to scratch my head. I have only selected VMware Tools installation to have all drivers for new virtual hardware installed on first start of the VM and chose not to power on the VM when the conversion is over
7. Once P2V is completed revise the virtual hardware and then power on the VM
8. Unpresent the SAN disks from physical server
9. Uninstall all Multipath software. In my case I couldn't get my SAN disk back online on the VM until I uninstall HP DSM and Emulex software from the VM.
10. Present SAN disks to all ESXi hosts. Make sure the LUN number is consistent accross all ESXi hosts.
11. Shutdown VM and add SAN disks as RDM disks - you can use them either in Physical or Virtual compatibility mode. Look at your Check list from step 1 and make sure you add them on separate SCSI controller and in the correct order. 
12. Make sure you can see the content of the disks once you powered on VM
13. Change the services you disabled in Step 2  to back Automatic startup type.
14. Reboot VM and check if all applications run properly

Hope it will save you some time on such a routine task.

PS Actually, I don't think the disks' order in step 10  is important. MS Windows is supposed to automatically recognize all disks it has been ever connected to since it saves and stores all disks' signatures in registry to map partitions to drive letters. Though I didn't dare to test this idea with the production server :)

If you find this post useful please share it with any of the buttons below.