Memory snapshot import

[olivierlambert]

Since VSS will be removed (see https://github.com/xapi-project/xen-api/pull/3926 ), the only alternative would be to backup a Windows (or any other OS by the way) with its memory, called a checkpoint.

The checkpoint will store both disk blocks (as a regular snap) and memory content. It works "locally", ie doing a checkpoint, restoring the snap and then resume the VM.

However, a backup is not a snapshot: if you lose the SR/host, you'll lose the snapshot. That's why, for example in Xen Orchestra (but also all other agentless backup solution for XenServer/CH), we rely on snapshot, then exporting it, and storing it "somewhere else" (ie a NAS or whatever that's NOT on the host). Then, when you restore it, it's basically a VM import as a "fresh" VM, allowing you to restore on any host you'd like.

Then, we planned to do the same thing in Xen Orchestra with checkpoint. In short, we export both disk and "memory" disk. But for the import (or call it "restore") part, it seems to be impossible to attach a memory disk to a VM. This would be the key to be able to restore VM with its memory on any host and solve the VSS removal.

Obviously, we want to work together and push upstream this contribution, as XCP-ng is currently in the process of vote for enterprise Xen project, joining XAPI project too :+1:

What would the best way to achieve that? Also if you want more details, I'm pinging @julien-f who almost designed the feature on Xen Orchestra side (so he knows far more about this than me).

[edwintorok]

It seems like you are exporting a VM in pieces and assembling it back together, although that is a valid use case that we should try to support did you try exporting the entire VM as xva/ovf and importing that?

[olivierlambert]

1. Yes, for delta backup, we are exporting all VM metadata, then VHD separately, allowing us to export only the diff between VHDs (this might also work for diffing memory disk I suppose, fun stuff :p ). In any case, this will be needed because XVA won't support delta capabilities obviously
2. We'll make some test on XVA, but even if it works, it won't solve the delta scenario. Keeping you posted on that, but if you see the best approach for 1, let's discuss that already :+1:

[olivierlambert]

I'd like to work on 2. in another issue probably, because at least I can say it doesn't work (I exposed the checkpoint as XVA, and reimport worked but no memory checkpoint at all)

[olivierlambert]

For 1, I also remember the issue was to be unable to create directly a "suspended VM" so we could resume it after restore.

[robhoes]

If you "revert" the checkpoint to get back a suspended VM, then you may be able to export and re-import it again.

[olivierlambert]

@robhoes okay so for 2. you say I should:

1. make the checkpoint
2. revert to the checkpoint
3. export
4. import should work and be ready to be resumed?

[robhoes]

...but the revert will destroy the running VM, which is not what you want. So you need to be able to create a new VM from the checkpoint first. I'm not sure if that is possible.

[olivierlambert]

@julien-f will post this afternoon a recap on what was the blocker, so we could focus on finding a way to overcome it :+1: Thanks for you answers so far!

[olivierlambert]

We could close the discussion about relying on XVA: it doesn't work either. So let's focus on the "delta" case :+1:

edit: I followed instruction: checkpoint the VM, revert to it, export the reverted/suspended VM, then imported the XVA, and I ended with an halted VM without any checkpoint available. So we'll discuss about that in another issue, it's not important right now :)

[julien-f]

As @olivierlambert said, exporting the VM ourselves gives us more flexibility like delta export or selecting only some VDIs.

Unfortunately, while we have no issues exporting a checkpoint (i.e. a snapshot in suspended state), we cannot currently import it because we cannot:

• manually create a VM in a suspended state
• set the suspend_VDI to a freshly imported VDI

[olivierlambert]

So what would be the best approach in XAPI to:

1. Create a new VM record with a "suspended" powerstate? (adding an optional field in VM.create? something else?)
2. Set the suspend_VDI for this VM? (no idea where to start for this one)

@edwintorok @robhoes if you have any pointers/ideas, feel free to share it, it will be likely very helpful!

[johnelse]

For 2. how about repurposing VM.set_suspend_VDI? It currently does a checksum to ensure the new VDI has the same content as the old one, but that check could be made optional.

[julien-f]

Maybe we could address both issues by allowing creation of a suspended VM when providing a suspend_VDI in VM.create?

[nagilum99]

@edwintorok

It seems like you are exporting a VM in pieces and assembling it back together, although that is a valid use case that we should try to support did you try exporting the entire VM as xva/ovf and importing that?

How else would you backup e.g. DB VMs? Removing VSS Feature without proper replacement (I only read "dropped", never "replaced by") is a bit of kthxbye Xen. Generally it makes many Windows VM backups to Schrödinger's cat. You don't know if it's fine until you restore...

[stormi]

This issue hasn't been updated but work is being done on this pull request https://github.com/xapi-project/xen-api/pull/4057 and XCP-ng 8.1 already includes an early version of that.

[olivierlambert]

Indeed, it's already in prod for XCP-ng 8.1, we are just waiting for the PR to be merged.

[nagilum99]

Will probably need some time until every backup vendor, supporting XCP-ng/CH/..., will use that feature properly.

[olivierlambert]

Frankly, I would be surprised to see other vendors keeping up on that relatively fast. We could do it with XO because of the way we designed it in the first place (this is an idea we had a long time ago and partially designed XO to be able to do that in the future).

Also, I have the feeling this will not be merged in time for Citrix Hypervisor next release.

[olivierlambert]

Closing since it's now merged upstream AND integrated in XCP-ng 8.1 :+1: