VM /ETC

Posts Tagged ‘snapshot’

Your vSphere VMs may be running from snapshots even though you didn’t create them. That is, if a scheduled job which auto creates snapshots runs into a datastore with insufficient free space. In this scenario a special Consolidate Helper snapshot will be created. 

The following screenshot shows the mysterious snapshot as I found it on my lab domain controller

In my case, the scheduled job that needs to create and then normally commit the snapshot is a Veeam Backup and Replication job. At some point in the life of my lab I did run out of space, and although it’s not an issue anymore, the snapshot still exists even when the jobs aren’t running! I was a bit surprised that backup jobs could even complete with this snapshot in place.

VMware KB article 1003302 explains that the Consolidate Helper snapshot is actually created when trying to commit (delete all) a snapshot.

Read the rest of this entry »

This session is moderated by Ron Oglesby, Service Director – Virtualization for Glass House Technologies. This is a Datadomain session that I anticipate to be a about the design and implementation issues faced by various Datadomain customers. No internet connection in this room so this will be a delayed post.

Like all the other sessions, the disclaimer slide is shown. I’ve learned from the last session not every session is going to have “forward looking” statements. Ron even commented that the slide was put in all the VMworld 2008 presentations by the VMware legal team.

Ron begins by discussing storage being the number one cost in a virtualization implementation. Snapshots, backups, and VM replication and cloning result in the need for large amounts of storage. Complicate this with the need for faster recovery, management automation, and increasing retention and compliance requirements help skyrocket the storage design footprint. Storage is implemented for virtualization too often as an afterthought.

Ron explains the session is about options for storing and replicating snapshots of VMs and the storage ramifications of server consolidation. The session will also illustrate how deduplication and virtualization complement each other.

The rest of the session was customer testimonials. The following are various comments from the customers that caught my attention. Read the rest of this entry »

This post is a supporting post to the discussion earlier this week sparked by Scott Lowe’s tip on avoiding ESX snapshots when using SAN device snapshots. NetApp’s SnapManager for Virtual Infrastructure (SMVI) is discussed as a solution for streamlining the coordination of snapshots between ESX and the SAN. Luckily, Nick Triantos from NetApp joined the discussion on Scott’s blog with some “under the hood” information: Read the rest of this entry »

To clone a virtual machine with VirtualCenter you have to power off the guest, but what if your next maintenance window isn’t any time soon, you can’t afford to schedule the outage, or you just need a copy of the VM during normal business hours? Did you know that making a copy of a running, powered on VM is possible. At a high level the process requires a snapshot to freeze the VM’s original disk which in turn allows you to clone the frozen disk. This is essentially the way VCB, vRanger, or any of the live VM backup products work. Therefore, cloning a powered on VM can be accomplished with a little Console command magic.

I want to acknowledge that researching this method was inspired by the VMTN Virtualization Roundtable Episode 1 Podcast’s coverage of snapshots. Specifically Eric Siebert mentions that using VMware Converter as an alternative to committing snapshots is not the best option and offers the idea of using vmkfstools to do the job. Read the rest of this entry »

Carlo Costanzo over at ipmer.com has a great post about how to quickly and easily solve issues resulting from VM snapshots. As Carlo points out, too many administrators misunderstand the ESX snapshot to be a point in time backup and unfortunately do not realize it is instead a live and growing file. More often than not the snapshot is forgotten until the LUN is completely out of space at which time the VM is unstable. Trying to commit the snapshot becomes a time consuming burden.

The post 70GB Snapshot, YIKES! explains how Carlo used some “outside of the box” thinking to use VMware Converter to rescue VMs without going through the commit process. The idea is so simple it’s brilliant! Carlo writes:

Read the rest of this entry »

When you use VCB you have to specify either ESX root or VC2 administrator credentials. These credentials are added and easily found stored in the required vcb-pre-backup and vcb-post-backup .bat files, and the config.js file when using a third party backup integration module. Therefore, a best practice is to create a new user that has the required permissions for backing up VMs. The new user, vcbuser, will allow you to keep your administrator and root accounts secure.

In the latest version of VC, VC2.5, the vcbuser role and permissions are predefined and called “VMware Consolidated Backup User”. The steps in this post are intended only for VC2.02 and earlier.

To create the vcbuser do the following: 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“.