VMware Cloud Community
Virtual_Instani
Contributor
Contributor
Jump to solution

Portable snapshots?

Looking for a proof of concept here. I'm running Vi3 with ESX 3.5. I have a remote team running ESX3.5 but I can't give them access to my Vi3.

I need to provide some VM's to them for testing purposes but they have bandwidth limitations. So I can't afford the time to send a fresh VM copy each time we update the test environment because of the size. We've already shrunk the VM's as small as we can.

Is there any way to keep a copy of my VM synch'd with theirs by using snapshots? Here's the high-level idea:

  1. Create the big VM's at my location and ship on portable storage

  2. The remote site imports those VM's, but locks them down and doesn't power them on. They clone them and test on the clones.

  3. When an update of the VM's is needed, I snapshot my copy and update my copy of the VM's

  4. My resulting snapshots and any dependent config files will be small enough in size to travel over ftp to the remote site in a timely manner.

  5. Remote site updates their locked copies so that they are in synch with mine.

I tried testing this myself in my environment. When I powered on the VM representing the remote site, it said the parent disk had been modified and wouldn't power on. Seems like in theory this might work - I just don't know how painful the manual tweaks would be and whether or not it's recommended. We're looking into other options but all of them have pros/cons - this just seemed worth looking into.

Tags (3)
Reply
0 Kudos
1 Solution

Accepted Solutions
kjb007
Immortal
Immortal
Jump to solution

This isn't going to be easy, to put it mildly. The second part of your attempt should have worked, and you will have needed the vmx file as well. Or at least a modified vmx. The vmx file will have the reference in it for the current snapshot, or the last one you took. From there, the snapshot chain will need to be in tact in order for the vm to boot. As long as you copy over both snapshots, and then update the vmx file to point to the latest snapshot, this should work.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB

View solution in original post

Reply
0 Kudos
9 Replies
kjb007
Immortal
Immortal
Jump to solution

You would have to keep the first snapshot always in place, and ship your secondary snapshot instead. For example, you'd take a snapshot and then send your main disk over as you describe. Then, the next time you need to send, you'd take another snapshot, and send that over, etc.

The message you are receiving is due to the CID chain no longer matching. Everytime a vm is restarted, the CID chain is updated with a random alphanumeric string that is added to the vmdk descriptor files. This is how the snapshots are kept in sync. If you tried to start a vm with the original disk, the snapshots would no longer work. Second, the remote site would also have to work off of a snapshot, and that would need to go away, because your snapshot won't match their snapshot, so this would get very confusing, at the very least.

What you can do, is have them download the descriptor file for your main disk, and any snapshots you may be using and their descriptor files as well, so the chain is kept in tact. This should allow you to do what you are attempting.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos
Virtual_Instani
Contributor
Contributor
Jump to solution

Thanks for the suggestion - I'm sure this can work.

I did give it a try and no matter what I do, I can't get the snapshot to show up on the copied version.

Here's what I did (see screenshots to follow).

  • Synch Snapshot Test A is my master copy

  • Synch Snapshot Test B is my remote copy

  1. Created VM "A" and made a snapshot (Version 1)

  2. Copied entire directory to new folder on same datastore

  3. Registered copied version through vCenter as VM "B"

  4. Updated VM "A" and made a snapshot (Version 2)

  5. Copied snapshot disk and descriptors from VM "A" to VM "B"

    • When this didn't work, I copied everything from VM "A" to VM "B" except for the .vmx and the base "Synch Snapshot Test A-flat.vmdk"

Reply
0 Kudos
RParker
Immortal
Immortal
Jump to solution

You are trying to engineer something that doesn't work for ESX. So try as you might you won't get this to work.

What you want is a site replicator that will replicate your VM's. that's the best and probably only way you will accomplish this.

http://www.vizioncore.com/vReplicator.html

Reply
0 Kudos
kjb007
Immortal
Immortal
Jump to solution

This isn't going to be easy, to put it mildly. The second part of your attempt should have worked, and you will have needed the vmx file as well. Or at least a modified vmx. The vmx file will have the reference in it for the current snapshot, or the last one you took. From there, the snapshot chain will need to be in tact in order for the vm to boot. As long as you copy over both snapshots, and then update the vmx file to point to the latest snapshot, this should work.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

Hello,

I would do the following the first time:

Make a snapshot

Shutdown the VM

Copy the contents of the VMName directory from ESX host A to host B

THen boot VM,

make a snapshot again on Host A

shutdown VM on Host A

Copy -delta file for latest snapshot, .vmsn, .vmsd, and .vmx files to appropriate directory on host B

You should then be able to boot VM on Host B and it should have the same snapshot tree as host A.... I have not tried this yet, but I like the idea you have. It should be possible.

Just make sure you never boot on host B without that second snapshot. Every time you copy things it will overwrite the second snapshot. Never let them commit/delete a snapshot either.


Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
Blue Gears and SearchVMware Pro Blogs -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Virtual_Instani
Contributor
Contributor
Jump to solution

One trick...copying the .vmx file itself still didn't show the updated snapshot tree to me. So, I removed VM "B" from the inventory in VIClient. Then, when I re-registered VM "B"...Success!

I know it'll be tricky and user-error-prone, but to generalize; as long as the remote site clones from their synch'd copy and never boots it, then I think this can work for us. The clone will be a new VM with no snapshots, and it'll be in the same state as the most recent snapshot - perfect for them to test with.

At some point we'll probably need to re-send a new base VM since eventually the chain will get too long to manage or use...but in that case we can re-ship on physical media, or do the 12+ hour ftp. I can foresee sending 3-5 or more snapshots a week so I was looking at losing up to 60+ hours a week just letting files copy.

It's at least enough to proceed with proof of concept. I'll look at the replicator solution, but this trick may be our our best bet in the short term. If anything else interesting pops up I'll post it.

THANKS!

Reply
0 Kudos
kjb007
Immortal
Immortal
Jump to solution

The clone idea is even better. Glad to see you got it working. As long as our snapshots don't get too large, you can use this for some time. As you said, every now and then, either you'll have to clone your source vm, or at least delete all your snapshots, and start over.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos
Virtual_Instani
Contributor
Contributor
Jump to solution

an update to this...through a few obstacles we've refined and simplified the process.

Master site = ESX-A

Remote site (no VI connectivity to Master Site) = ESX-B

Initial Setup

  1. Create Master VM on ESX-A

  2. Snapshot Master VM on ESX-A

  3. Power down Master VM on ESX-A

  4. Transfer Master VM's files to remote site and store the synch'd copy on a share at remote site

  5. At remote site, import the synch'd copy using VM Converter (free) to ESX-B

  6. Test on the imported VM on ESX-B (which will be a single vmdk with all snapshots consolidated)

Updating a snapshot

  1. Power on Master VM on ESX-A

  2. Make updates to Master on ESX-A

  3. Power down Master on ESX-A

  4. Snapshot Master on ESX-A

  5. Send all the changed files to remote site. I determined this set of files using a file comparison utility. For us, these files are;

    1. Tthe .vmx from ESX-A (always re-send...points to latest state as current .vmdk)

    2. .vmdk for the snapshot just created

    3. *-delta.vmdk and .vmdk descriptor (2 files) for the new/current "you are here" state

    4. .vmsn for the new Snapshot

    5. .vmsn for the VM itself

  6. At remote site, copy updated files into the shared folder containing the synch'd copy (will overwrite some existing files)

  7. At remote site, re-import the synch'd copy to ESX-B using Converter.

  8. Test on the imported VM on ESX-B (which will be a single vmdk with all snapshots consolidated)

This keeps the remote site from requiring a vCenter license to make clones and is much easier from an end-user perspective. At some point, I assume our snapshot chain will get too long and/or too big and Converter won't like it (or it will take forever to import)...but at that point we'll try going back to the original Master Copy on both sides and starting the chain over. If that doesn't work, we'll have gotten our mileage out of it and will just make a new Master Copy altogether and start the process over again. The first snapshot we applied was ~1GB...the VM itself is 16GB and it imported in less than 15 minutes. So I think we'll be able to apply quite a few updates via snapshots before this process breaks.

Thanks again - this will streamline a few things and mitigate some risks - saving us lots of time and money in the long run on the process side. Even better - on the software $ side, this remote site is operating completely on the free VMWare products (ESXi and Converter)!

Reply
0 Kudos
kjb007
Immortal
Immortal
Jump to solution

Very good. It's always good when "creative" solutions work as we think they should. Let's us come up with more creative solutions.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos