VM /ETC

Archive for the ‘SAN’ Category

Avoiding storage array snapshot pitfalls in a VMware environment is an article and tip published by Scott Lowe for Searchvmware.com. Scott discusses the design challenges and implications of combining the snapshot abilities of VMware ESX with the SAN based snapshot features of storage devices. The tip points out that incorrect configuration of VMware ESX with the storage device could lead to inconsistent and unusable images when trying to recover VMs.

“Because these snapshots are not, by default, integrated in any way with VMware ESX Server, we have to perform a few extra steps to ensure consistently reliable and usable storage array snapshots.”

Read all of Scott’s tip at the link to the article above.

My “2 cents” on this is that trying to configure the combination of the two snapshots manually might not Read the rest of this entry »

John Troyer from VMTN has hosted the first podcast episode of VMware Communities Roundtable and has posted a summary of the call notes at VMware Communities Roundtable podcast #1 | VMTN Blog. I am honored to have one of my “things that make you go hmmmm” (on the Quick Migration vs VMotion discussion) posts listed as a reference for one of the topics of the episode.

John announces the new series and the objective of the Roundtable podcasts with the following summary:

“Each week, we’ll bring together experts and leaders from the VMware Communities and virtualization blogs to discuss the interesting topics in virtualization. Think of this as if it were a group meeting up at VMworld over a pint to chat about the latest news.”

The episode lasts somewhere between 50 minutes to an hour and is a recorded call between John and an attendee list consisting of some of the virtualization community’s top minds from all over the world. VMware Community profiles of the individuals contributing to episode 1 are:

• Steve Beaver – sbeaver
• Tom Howarth
• Alex Mittell – mittell
• Eric Siebert – esiebert7625
• Edward Haletky -Texiwill
• Dave Mishchenko

Go to John’s VMTN post to listen or download the podcast, but the following is my quick summary and take-aways from the call. Read the rest of this entry »

I was helping a customer P2V a large development SQL server this week and ran into a VMFS configuration issue that failed the conversion. We were using the Converter Enterprise for VirtualCenter 2.5 plugin. Almost as soon as we kicked off the job it failed with an error starting with “file size is larger than the maximum size supported by datastore”. The VMFS LUN we were using as the target was an empty 1.5 TB volume, and the new VM consisted of 2 virtual disks that totaled roughly 450 GB. We had plenty of room, but the problem was not the available storage space. Instead, the issue was that we exceeded the maximum possible .vmdk size for the default VMFS 1MB block setting.

When you add new storage to an ESX host and you format the LUN with the VMFS file system you have to choose what block size setting you want to use. See the screenshot for the dropdown box used to make this choice. Notice the Maximum file size description supposedly provided to help you understand this setting. It’s hardly intuitive in my opinion, so let me try to translate – Choosing the block size determines what maximum possible .vmdk size can be created on this LUN.

If you do not change the default setting when you format a VMFS LUN
Read the rest of this entry »

When planning P2V migrations there is always a handful of servers that have huge disk requirements. A network file share could be as large as several terabytes. User Home Directories can also cause large, cumbersome servers that present unique challenges when migrating to virtual infrastructure. Given that VMware VI3 has a 2 TB VMFS volume limitation as well as a 2 TB .vmdk limitation, there is a better option. Consolidate your shares to a Read the rest of this entry »

While doing some research to get ready to implement the new ESX 3.5 storage vmotion feature I came across some helpful blog posts, and a script that will be a real time saver.

Unlike the vmotion we are used to, you can not right click on a vm in the vi client and initiate a storage vmotion. You have to download VMware-VIRemoteCLI and install it. The VIRemoteCLI can be downloaded as:

* a virtual appliance
* a windows installer
* a linux installer

Once the RemoteCLI is installed in Windows for example, Read the rest of this entry »

VMware Communities: New Script for moving vm to another … contains a thread from this summer about cold migrating a VM from local storage of an ESX server to iSCSI storage. The post contains the code (original and updated versions) for a script to automate this process. The final version allows the migration of a VM to any ESX storage location. I have added the vm-relocate.sh script to the Files page as well.

This script is handy if you do not have Read the rest of this entry »

My customer had a couple of ESX hosts. Both ESX hosts had access to (4) 250 GB VMFS LUNs on fiber attached IBM storage. After upgrading their SAN controller in order to allow them to have the more storage partitions for booting several blades from SAN, the LUNs were no longer available to the ESX hosts. The LUN IDs were changed when the storage controller was upgraded and ESX began complaining that the LUNs were snapshot volumes.

The resolution was simple enough and is documented in VMware’s KB article titled “VMFS Volume Can Be Erroneously Recognized as a Snapshot“:

To resolve issues with invisible LUNs on certain arrays:

1. In the VI Client, select the host in the inventory panel.

2. Click the Configuration tab and click Advanced Settings.

3. Select LVM in the left panel and set LVM.DisallowSnapshotLUN to 0 in the right panel.
   Warning: When LVM.DisallowSnapshotLUN is set to 0, no snapshot LUNs should be presented to the ESX Server host. Otherwise, data corruption may result. For details, see “State 3 – EnableResignature=no, DisallowSnapshotLUN=no” on page 110 of the SAN Configuration Guide at www.vmware.com/pdf/vi3_esx_san_cfg.pdf.

4. Rescan all VMFS volumes.

After the rescan, all VMFS volumes are available.

The issue resurfaced in slightly different form when I added 3 new ESX hosts to the environment. The existing 4 VMFS LUNs never appeared as available storage to the new hosts even though the zoning was correct. Rescanning from the storage adapters did not help. When I went to manually add the storage I could see the LUNs but I was warned:

The current disk layout will be destroyed. All file systems and data will be destroyed permanently.

That was enough to make me stop and research again. It turns out that the LUNs were appearing to the new hosts as snapshot volumes as well, so I had to make the same LVM.DisallowSnapshotLUN change as above.

If you actually do use snapshot LUNs then there is another fix to this issue detailed in VMware’s KB article titled “Resignaturing VMFS3 Volumes That Are Not Snapshots“.