Offline VM Migration auto convert RDM to VMDK format

Due to some reconfiguration work we performed on our Virtual Infrastructure, we had required to relocate some of the VM to a different datastore. These VMs which required to be moved had been attached with Raw Device Mapping (RDM). Previously I thought the offline storage migration will not move the RDM over to the datastore as RDM is referring to the raw device from the SAN storage.Actually I was planned to convert the RDM to VMDK which I planned to manual transfer the files I need from RDM to the new virtual disk I created.

In a test yesterday, we found that a offline VM migration will auto convert the RDM which attach to the virtual machine to the VMDK format when I selected the data store to be moved in offline mode. This was really surprise myself and simplify my work actually, as I do not require some manual file transfer from the RDM to the new virtual disk.

Calculation of Max LUN Supported in ESX Server

I found my ESX servers could not recover the 65th LUNs that I tried to present to it and myself did log a support call and still pending the reply from VMWare. Beside that, I found another interesting article with the details below.

Article Copy from VMWare

In Multipathing Configurations the Number of Paths Per LUNIs Inconsistent
The hpsa driver in ESX Server might reduce the number of supportable LUNs below the expected maximum limit of 256 when the controller is used in multipath configurations. In multiplath configurations, if all four paths are configured, the total supportable LUNs is reduced to 64. In certain multipath configurations, because each target path consumes an available LUN slot, the total number of supportable LUNs might be reduced to 60.

Workaround
Reduce the number of LUNs on a server until the product of LUNs and paths is less than 256 (LUNs * Number of paths < 256), and if necessary, reduce the LUN count depending on use of multipath until each LUN has the expected number of paths.
The following example shows a configuration with the maximum supportable LUNs presented to an ESX Server installation on four paths, providing all LUNs with the expected number of usable paths:
Path 1: 63 LUNs seen through this path; Total LUN count (63 + 1 path) is less than 256
Path 2: 63 LUNs seen through this path; Total LUN count (63 + 63 + 2 paths) is less than 256
Path 3: 63 LUNs seen through this path; Total LUN count (63 + 63 + 63 + 3 paths) is less than 256
Path 4: 63 LUNs seen through this path; Total LUN count (63 + 63 + 63 + 63 + 4 paths) = 256

If I do use the formula above to calculate my environment, yes, I am at the full limit of 256 LUNs. I have 2 ESX servers which only have 2 HBA connection, and had no problem to present more than 67 physical LUNs to it until now. What I had done now is, I removed 2 HBA connection from each of my ESX servers, and run the rescan, and I found that the LUN is presented as I expected. Again, I am not confirmed with the solution yet and will do another round confirmation with the VMware engineer on this.

ESX and VM Guest - Round Robin Storage Setting

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 To improve the I/O performance for ESX Virtual Infrastructure, VMware had come out with the round robin option for both ESX and VM guests. Although is an experimental option in the ESX setting today, but I will encourage you all to try this option which provide fail over and load balancing on the storage path to connect to you SAN storage. For VM guests, you will allow to use this when you have RDM - Raw Device Mapping option to direct read write to the physical LUN from your SAN storage without using VMFS.
ESX Hosts

To enable this on ESX host, you need to browse to the configuration tab of the ESX host, and right click the data store and select properties, and click on manage paths option in the GUI wizard. Click on Change button after that, and choose the Round Robin (Experimental) option and click OK. You will need to go through this process 1 by 1 to ensure you had round robin from each ESX host to each of the VMFS Data store.

VM Guests

Just right click the VM

and choose edit setting, and select to the hard disk which has shown as Mapped Raw LUN on the summary tab. Click on the Manage Paths and follow by the change button, and same you can easily

configure to have the Round Robin enable.

Update Manager - VMware Virtual Center for Patching Activities

After couple of months we had performed the patch activities for our ESX hosts and VM guests by using the Update Manager, here is my review of the Update Manager from VMware.

Update Manager had simplified the life of the system engineers who manage the VM farm with the huge number of VM guests and ESX hosts which may require a frequent patch update. Before the Update Manager released, most of the time we had patched the server by using satellite servers, Altiris, SMS and others patching tools. That will require additional cost required to be implemented on the VM guests or esx host due to the licensing agreement from the vendor.

Update Manager is fully compatible with VMware ESX patches update for ESX 3.0, 3.5 and ESX 3i. From the Host level, you will able to get all the patches downloaded by the update manager schedule task once the VMware had officially release their patch on their official system. Update Manager had also integrated well with Microsoft patches as well as others famous software patches like Red Hat, Adobe and etc. It even allow us to patch the template image which we store for deployment purpose, without manual interaction to convert the template back to virtual machine. If you try to patch a windows 2003 template image, the entire process is fully automated. This is really impressive. I had also patch my DR servers which is 30 miles away from my major Data Center, and we had 30 Mb MPLS across the WAN, it worked perfectly without any issue at all, and of course, the patching timing will be slightly longer due to the location of the DR servers.

To get the update manager deployed in your environment, here is couple of step you may need to configure or enable.

A dedicated DB for update manager in the SQL or Oracle - Depend on the choice of database servers you are using. This Database will store all the information and patches to be used for patching purpose. If you have proxy server in your environment, you need to configure the proxy address and port number in the virtual center configuration for Update Manager. Schedule task to refresh and check the latest patches release from the official site, recommend to run the schedule task at least once in a week. I do schedule it to be run on weekly basis, to ensure you getting the latest patches when you try to patch you VM guest or ESX host.

Baseline - baseline is been use to define the patches required for specify product or platform by the update manager. ESX host baseline is been built in by default and categorize under Critical and Non Critical. You are also require to create you own baseline for specify OS and software you are using.

Please make sure you had update manager plug-in install on your virtual infrastructure client. To attach the baseline to the ESX or VMs you would like to deploy, you need to switch the view mode to Virtual machines and template mode, then select the system you would like to patch, and click on the update manager tab on it, and start attach the suitable baseline on it.

After you attach the baseline, right click the virtual machine or ESX host and select Scan. Scan will not actually apply the patches, this is allow the update manager to compare the current patch level for the ESX hosts and Virtual Machines and preview of the number of patches needed to be applied to be compliance. After the scan result display, right click the machine and select remmediate. This will start to apply the patches automatically.

For ESX hosts, you need to Vmotion all the VM guests to another ESX host. This will provide 0 down time during the maintenance, thanks to the cool technology by vmware on Vmotion. This had worked for me all the time. Once the ESX hosts is ready, is recommend to send the ESX host to maintenance mode, then start the remediation after that. Once the patch is completed, it will show the ESX host at a different patch level or update code by vmware release. You can verify this with the VMware website information easily.

For VM guests patching, down time will be required as usual, due to the reboot require from the operating system perspective. Again, this tools is bundle together with the Virtual Infrastructure by VMware, is really useful for the VMware engineers to patch thier VM guests.

The only disadvantage at this moment, SUSE linux is not supported by update manager. According to the VMware, they will soon release the next version of update manager to support patch activities on SUSE Linux VMs.