Create new vm from snapshot files with a delta

[zenking]

Hi. I need to create a new VM from existing snapshot files. When I choose Custom VM and get to the "Use an existing disk" section, do I choose the flat vmdk or the delta? I'm guessing flat and then it will find the delta.

More info in case it's needed:

We have a Windows 2008 R2 guest running MySQL 5.6 in vSphere 6.0. I'm backing up this VM to a remote location with VM Explorer. The main db user last got a good sql dump almost 2 weeks ago. 4 days ago, he tried to get a new one but it failed and stopped the mysql service. He tried some db checks, but it keeps failing on the larger DBs and stopping the service. He can dump the small DBs, so we've tried tweaking buffers, max limits, etc, but no dice.

I have a snapshot from 5 days ago, and I'm copying that to a new VMFS LUN. We want to create a new vm from that and fire it up to see if we can get a dump from it. I'll disable the networking so that I can fire it up in the client console without worrying about name and ip conflicts.

Does this plan sound viable? And, of course, if you are a db admin and have any other ideas for fixing the current db, that would be awesome. I've already posted to the mysql forum.

Thanks.

[SupreetK · Accepted solution]

Always point to the most recent delta file while using the existing disk option. Unless you are restoring both descriptor and the data disks, you might have to create the relevant descriptor files.

Please consider marking this answer as "correct" or "helpful" if you think your questions have been answered.

Cheers,

Supreet

[a_p_]

Do NOT try to connect a new VM to one of the snapshots, and power it on. This will break the snapshot chain, and will cause file system corruption in the original VM!

Is it an option to have some downtime? In this case, you may consider to shutdown the VM, create a new snapshot, then select the 5 days old snapshot in the Snapshot Manager and "Go To" this one. The new snapshot will allow you to go back to the current state when done.

As an alternative you can always clone the virtual from the required snapshot, and then create a new VM using this cloned virtual disk.

vmkfstools -i /vmfs/volumes/sourceDS/foldername/vmname-00000#.vmdk /vmfs/volumes/targetDS/foldername/vmclone.vmdk -d thin

Please note that the target folder needs to exist prior to using the command.

André

[SupreetK]

Hey a.p.​ As per the description, he is trying to restore the files from the backup to a different datastore. I don't think this should be a problem unless, I'm missing something :smileyconfused:

Cheers,

Supreet

[zenking]

Supreet is correct. The snapshot files are being copied to a brand new LUN. The original VM will stay in its original LUN and will continue running throughout. I would like to disable all networking on the snapshot vm, then start it up and see if I can get the db dump. That should leave the snapshot vm completely isolated so that it doesn't conflict with the original vm, right?

[SupreetK]

Absolutely! Looks good

Cheers,

Supreet

[zenking]

New wrinkle - All of the files finished copying over, so I created the custom vm, but my only choices for the disks in the new datastore were:

sql-server.vmdk

sql-server-000001.vmdk

So the flat and delta disk files did not show up as options during disk selection. I double checked to make sure I was in the new vm datastore. I went ahead and created the vm from the sql-server.vmdk file, which was the larger one. I have not powered on the vm yet. 2 questions:

Did I choose the correct disk?

Should I consolidate the disks before I power it up?

I enabled the "Need Consolidation" column in the client and it says no for that vm, but I don't know if the vm has to be powered on before the host does the consolidation check.

Thanks for any input.

[a_p_]

Each virtual disk file in vSphere consist of two files, a descriptor .vmdk file (a small text file with metadata), and the data .vmdk file (flat, delta, or sesparse).

In most cases - as in this case - it's the descriptor file which has to be used in the VM's configuration. That's why the flat/delta files don't show up.

The file to use - when working with snapshots - is the descriptor .vmdk file of the snapshot that you want to work with. Depending on the client you are using, it may however not be possible to select a snapshot file, and you may have to edit the VM's configuration file (followed by a VM reload, see https://kb.vmware.com/s/article/1026043​).

For details about how snapshot work in VMware products, take a look at e.g. https://kb.vmware.com/s/article/1015180​

André

[zenking]

Thanks, but there isn't a small vmdk file that looks like it would have just metadata; both are large. Here's what's in the DS:

(The real name is different than the generic name I posted earlier, so this is the correct vm).

I don't know why the original files named flat and delta don't show up now. Maybe they get converted to these names during the VM creation? By the way, I'm using the 6.0 version of the C# client.

Also, the *-sql-newvm folder has a vmx and vmsd file.

So, I'm wondering if I made the right choice before, or if I should recreate the vm again and choose the 000001 vmdk. And in either case, should I consolidate before powering up? The main reason I'm trying to be careful with this is that these files took 6 hours to copy from the remote location. If the new vm gets corrupted because I've chosen the wrong disk, I'll lose most of a day copying the files again.

Thanks.

[a_p_]

Thanks, but there isn't a small vmdk file that looks like it would have just metadata; both are large

The Datastore Browser displays the descriptor, and the data file as a single entry with the descriptor file's name, and the data file's size.

Also, the *-sql-newvm folder has a vmx and vmsd file.

The .vmx file is the VM's configuration file, and the .vmsd contains information/metadata for the VM's snapshot.

What should be done prior to adding the VM to the inventory, and powering it on, is to ensure that the restored files do not contain any references to the original VM's location (e.g. an absolute path to the original datastore).What I'd like you to do, is to enable SSH on the host, and use e.g. WinSCP to connect to it. From the VM's folder, download the .vmx, .vmsd, and the two small descriptor .vmdk files (WinSCP will show both, the descriptor, as well as data .vmdk files), then compress/zip these files, and attach them to a reply post. Feel free to rename the original file names (and entries) to a generic name, if you don't want to expose the original names.

André

[zenking]

Ah, ok. I used WinSCP to copy the files, so now I understand why they appeared with different names than what the client shows. I'll be able to zip those files and post later today.

Thanks.

[zenking]

Sorry for the delay. I've attached the files. The vmx file in the root folder is the original one that is in the same folder as the vmdk files, so it points to the original vmfs folder. The vmx file in the newvm folder is the one that got created when I created the new vm from the vmdk in the new vmfs folder.

Thanks.

[a_p_]

Sorry if I ask you again, but I just want to make absolutely sure, that we don't mess up the original VM.

Please let me know whether I understand the current situation correctly:

• the restored .vmdk files (2 descriptor, 1 flat, and 1 delta .vmdk file) are located in a datastore's root directory (not in a sub-directory)
• the .vmdk file's which you've attached to your previous reply post are the restored ones
• you've created a new VM and selected one of the restored .vmdk files (sql.vmdk) in the wizard (use existing virtual disk)

Disregarding the fact that the .vmdk files seem to be stored in the root directory, here's what you may do now:

• (optional): create a new directory, and move the 4 restored files into it
• edit the new VM's .vmx file, and replace sql.vmdk with the snapshot's name sql-000001.vmdk
• reload the .vmx file (https://kb.vmware.com/s/article/1026043)
• create a new snapshot, so that the existing .vmdk files will not get modified, and you can always revert to the VM's current state

Note: If the new VM's directory is on the same datastore as the restored .vmdk files, you may move these 4 .vmdk files from the root folder to the VM's folder using the native mv command. With the .vmdk files being located in the VM's base folder, you can omit the .vmdk file's absolute path in the configuration file, i.e. set:

scsi0:0.fileName = "sql-000001.vmdk"

André

[zenking]

OK, thanks. I appreciate you being thorough.

Yes, the files are as you described. All of the restored files are in the root of the new sql vmfs folder. The newvm folder and the vmx and vmsd files in it were created during the new vm creation.

I won't be able to try your suggestions until tomorrow, so I'll post back what happens. Thanks again, and enjoy your weekend.

[zenking]

OK, I was able to restore the vm snapshot and get it to run without disturbing the currently running vm. I wasn't too concerned about creating a new vm id, so I opted to remove the one I created a couple of days ago from inventory, then creating a new one using the 000001 vmdk file. Here is what ultimately worked for this task:

• Create new datastore for the remote snapshot to be restored to
• WinSCP snapshot files from remote server to new datastore
• Take a new snapshot of the currently running vm in the vsphere client
• Create new VM using custom options
  • No networking (so I could run it without having to shutdown the running production VM with the same Windows host name)
  • Select existing disk (vmname-000001.vmdk)

After the vm was created, I immediately got the message that the disks needed to be consolidated, I right clicked the vm and chose Consolidate. After this finished, I was able to start the vm and log into it through the vsphere client console.

Thanks to both of you for all of your help.

[a_p_]

Thanks for the feedback. Glad to hear you were successful.

André