Backups: option to reuse the current VM (in-place restore)

[atodorov-storpool]

Description The current workflow for restoring from a backup is as follows (as far as I can understand it, please correct me if I am wrong):

• The user click on the Restore button in the Backup tab to restore a VM from a backup:
  • The VM disk backups are extracted from the backup storage. and imported into an Image datastore as new images
  • The VM Metadata, stored with the backups, is used to define a new VM Template that uses the restored new images from the image datastore.
• The user/administrator must manually review the new VM Template and updated/fixed whenever the Restore script can't handle.
• Then the user/admin must terminate the old VM to free resources like IP reservations and so on.
• Finally, the user/admin could instantiate a new VM instance fromt the backup VM template in place of the terminated VM.

So, as you see there are a lot of steps and a lot of internal knowledge needed by the user to complete a single restore task. This is experience that is not needed with any other Cloud Management platform. So I don't belive it is usable on practice...

Use case The common use case the backup needed for recovery is very close to the current state of the VM. So this proposal to use the existing metadata in OpenNebula and only replace the disks. All of the other metadata could be altered on the current VM too - if needed. That way. I believe, much less data need to be processed/replaced/altered that when defining a new VM. For the end user perspective - it copuld have the VM up and running from the backup after a single click. Well, definitely with a confirmation dialog. Also, it will ease the stress on the billing department too ;)

Interface Changes Option to restore a VM using the runnig VM metadata instead of defining a new instance. Also option to select what to be the default behaviour. Driver changes - To terminate the VM, replace the disks on the KVM host, optionally (if preferred by the user) alter the contextualization and the networking, then resume the VM.

Sunstone

• New VM state (LCM, 71, RESTORE)
• New VM action (one.vm.restore)

Additional Context Having a VM in complete previous state maybe have its use case, but IMHO it is not to broad one. Because usually the VM is linked with some kind of billing, in that billing there various aspects of the service could be accounted/billed, etc.

Progress Status

• [x] Code committed
• [ ] Testing - QA
• [ ] Documentation (Release notes - resolved issues, compatibility, known issues)

[rsmontero]

We have been disusing this internally and, what we call "in-place" restore is something we want to tackle, We'll keep this issue to address this feature.

However, I don't agree that the current restore procedure is cumbersome and requires knowledge. First you are assuming that the VM still lives and even that you want to restore the VM in the same host/cluster. In general this is not true, if you want to restore a previous point for a running VM a disk or system snapshost is much better option than a backup.

Backup and snapshotting are different things but both have their use cases, you should not be using one for the other.

The restore procedure needs to select (and we are in the process of giving more options) what you want to preserve (this is a common practice in other backup solutions like Veeam etc...) So, to some extent the user needs to decide what needs to be restored. We can give more options like (--no-ip or --no-nic``) but having the ability to fine tune what is restored, We think is a nice feature. We aim to a trade-off because having tens of toggles is even a worse solution, so we will provide some more high level options, and leave the user to fine tune the rest (if fine tune is needed)

[rsmontero]

Even more important as incremental backups impose important limitations for snapshots.

[vichansson]

Needs tests + docs