Last Wednesday I’d been asked nicely by my junior to help him porting Redhat 5.3 machine (physical boot from HP SAN) to new vSphere environment. Knowing that a P2V is not possible for this kind of setup, we have decided to let the Redhat image and everything remain in SAN storage but this time we will make it run on the virtual hardware instead. To minimize the risk for the existing LUN, we asked HP engineer to duplicate the LUN with new LUN ID for us and present it to all ESXi hosts.

Once the duplicated LUN is ready, we had created a new virtual machine(VM) (Redhat 5.3 64bit) with enough memory and then added a RDM disk by selecting the duplicate LUN (physical mode) to this VM. Next, we try boot the image and as expected, the boot process was failed and produced “kernel panic” error. Without doubt this is something to do with an old initrd image which wasn’t able to find a suitable driver for LSI controller during the boot process.
So, I’ve restart the VM and as usual I went in to rescue mode and recreate a new initrd image with below command :

$mkinitrd -v -f –without-dmraid /boot/initrd-2.6.18-vmware.img 2.6.18-92.el5

Surprisingly, unlike when we do P2V here, this command wasn’t working at all. Although I managed to mount all the partition without error and then $chroot it, few times I got error “no kernel modules 2.6.18-92.el5″ when I try to run $mkinitrd. When I succeed, boot process still failed with “kernel panic” error. After few times we rebooted it, I’ve decided to make new initrd image with a difference set of command as below :

$new-kernel-pkg –mkinitrd –depmod –install 2.6.18-92.el5

and finally, the VM now able to boot successfully without problem.
Summary :

• Duplicate existing LUN,
• Present duplicated LUN to ESXi hosts
• Add new VM with RDM disk (physical mode)
• Reboot the VM into Redhat rescue mode (redhat cd/dvd)
• Make new initrd with $new-kernel-pkg –mkinitrd –depmod –install 2.6.18-92.el5
• Reboot the VM

ariyossss

Yes I know it’s not recommended as stated in the KB (vCenter Best Practice) but due to unreasonable request from my user, I have no choice but to test whether it is possible to let vCenter service running on domain controller machine. As suggested elsewhere, I have to install vCenter application first before I can dcpromo the machine. So the process can be summarized as below :

• Prepare the machine
• Install vCenter
• Change vCenter ADAM port
• Run dcpromo

To test this out, I’ve created one VM running on VMware Workstation 7 and install it with Windows Server 2008 R2. Once finished, I proceed with vCenter 4.1 installation and use SQL Express as for vCenter database. The installation finished as expected and vCenter service can running fine without issue.

Now, I need to change vCenter ADAM. Since AD Ldap will use port 389, to avoid port conflict, ADAM port must use other than port 389 (3899). To do this,

• Open CMD and run c:>net stop VMwareVCMSDS
• c:>dsdbutil
• dsdbutil:>activate instance VMwareVCMSDS
• dsdbutil:>LDAP port 3899
• dsdbutil:>SSL port 6369
• dsdbutil:>quit
• c:>net start VMwareVCMSDS

To verify that my vCenter ADAM now is using port 3899, I’ve checked it with c:>netstat -an. To make the changes permanent, I’ve modified instance.cfg (Windows Server 2008 R2 C:\ProgramData\VMware\VMware VirtualCenter) and change port 389 to 3899. Then, restart the server and verify your vCenter service is running fine.

From now on, you can proceed with dcpromo. Although I will not discuss it here, you can always refer to this site for how to install your first domain controller.

p/s : This is not supported by VMware at all.