Saving the current state of Virtual Lab VMs?

[kacsp]

We're evaluating running Virtual Labs for our developers to work with in testing their applications and I'm wondering if it's possible for them to make changes to Lab VMs when running, and then somehow save the current state by taking copies of those modified VMs?

I understand that normally when Labs are shut down any changes made to VMs are normally lost, but within Veeam, in 'Virtual Machines', I'm able to view running Lab VMs and also seem to have the ability to use 'Copy Job' & 'VeeamZip' tools on those VMs (though I've not tried either of these yet because I wasn't sure of the outcome). So can these tools be used on running VMs within Virtual Labs, and will they save the current state of those VMs to a copy or Zip?

Alternatively, does anyone know of any way of saving the current state of Lab VMs?

Thanks...

[foggy]

I do not see any barriers in backing up VMs running in the virtual lab, just like any other VMs (though keep in mind that SureBackup job should not finish at the moment when the VM is being backed up). You can target backup jobs to such VMs or use VeeamZIP against them, backup copy jobs then can be used to copy those backups to some secondary location.

[kacsp]

Will this consolidate the contents of the Redo logs onto the base VM files to make an up-to-date copy, and not just a copy of the original VM Replica (our Labs are running on Replicas, not Backups) from before the Lab was started up? Since Lab VMs can't be written to permanently, with changes accumulated in Redo Logs discarded when the Virtual Lab is shut down, I'm just wondering how taking copies or backups of these VMs would work?

[foggy]

Yes, it will be an ordinary backup, saving the VM current state, just like with any other VM.

[kacsp]

Sorry to labour this but what happens to the original Replicas in this case? Are the Redo changes made to VMs whilst the Lab is running written to the original Replica in the course of making a copy or backup, or are they still discarded?

[foggy]

Original backups and replicas are never touched by SureBackup jobs. The changes performed to VMs in a virtual lab are discarded on the SureBackup job completion.

[kacsp]

Thanks for you help, that's clarified things.

Based upon what you've said so far, what VM copy method would you advise I use for efficiency if I wanted to copy VMs from Labs (saving their current state) for later use in their own Application Groups / Virtual Labs? My understanding is, now, that I could use either of VeeamZip, Copy Jobs or, again, Replication Jobs for this? What would be my best, most effective option?

[Vitaliy S.]

I would vote for backup/VeeamZIP jobs, because VMs will be stored in compressed and deduped format and will allow you to save some space on the backup storage. Thanks!

[veremin]

VeeamZIP. The best option whenever you're after instant/one-time backup. Thanks.

[kacsp]

Excellent...I've just taken copies of Virtual Lab VMs, saving current state successfully (using VeeamZip), and then used these as the basis for further, new Virtual Labs; exactly what I was hoping to achieve.

Thanks to all who replied here for your help with this...

[kacsp]

Following on from using VeeamZIP to take backup copies of Virtual Lab VMs to save their state...

After using VeeamZIP, what will happen if I then create an Application Group to hold these newly backed-up VM copies, then use this with a new Virtual Lab run by a new SureBackup job?

If I run SureBackup and try to start the new Virtual Lab at the same time as the Virtual Lab containing the original source VMs, what will happen? Will there be a conflict from trying to run two Virtual Labs containing VMs with the same names?

Would the best solution be to Replicate the VeeamZIP backed-up VMs (so renaming them thru adding new suffixes), and then use these Replicated / renamed VMs in the new Application Group / Virtual Lab / SureBackup Job? Is it necessary to go through this additional name-changing step to be able to run a Lab which contains the newly-copied VMs at the same time as one containing the originals?


Thanks again

[Vitaliy S.]

Technically it should be possible, since these VMs with get a randomized GUID added to their names automatically, this should allow them to be registered in the same VI. The only conflict that you will face will be the conflict in hostnames and network configuration for these VMs. Out of curiosity, can you please clarify why do you want to do that?

[kacsp]

Again...it's about saving the current state of a Virtual Lab. I'm working towards establishing a set of flexible procedures that allow me to generate Virtual Labs based upon the needs at the time. Creating & generating simple Virtual Labs has it's place, but their limitation (from my perspective) is that there isn't an standard option to choose to save the current state of a Virtual Lab's running VMs, which would allow the possibility to either re-use them as the basis for further Labs - essentially 'base-lining' them - or to pick-up where you left off in case of a failure of some sort.

From my point of view, at the moment when I do work on a fresh DC when its brought into a Lab (similarly, with other servers too), I'd like to easily be able to save it's state at the completion point, for use in further Virtual Labs later on (and to provide a current state backup of what I've done to it). From our devs point of view, the same goes; they would also need the ability to save (baseline) the state of their work at major junctures.

Just to update you, working with your previous advice I've figured out how to achieve what I need. This essentially boils down to using VeeamZIP to Backup the running Lab VMs (in their current state), then Importing these backed-up VM copies into Veeam, Restoring them (Entire VMs) TO A NEW LOCATION (this allows their re-naming), and lastly, Replicating them again for use within Application Groups / Virtual Labs. I'm not saying things are perfectly worked out at the moment, but I'm certainly on the road to achieving what we want.

[Vitaliy S.]

Yes, all this makes sense, for some reason I just thought that you would like to run these VMs from different time stamps in parallel using the same virtual lab.