qvm-backup-restore --replace-existing option

[andrewdavidwong]

Description

Add an option that replaces existing VMs with VMs with the same name from the backup.

Example use case

Two Qubes machines with all the same VMs. Use one for a while. The VMs on the other machine are stale. To update them, you have to remove them all first. This option would make it easier.

[marmarek]

While I see it being useful in some cases, it would be extremely easy to shoot in the foot using this option. For example after replacing your only template you discover that one one just restored doesn't work for any reason. Or accidentally select too many VMs to restore and override not stale one.
If you really want to do this, IMO better have some script that will replace appropriate VMs, after restoring them with qvm-backup-restore --rename-conflicting. Probably also possible using Salt, but not sure if easier.

[marmarek]

While I see it being useful in some cases, it would be extremely easy to shoot in the foot using this option. For example after replacing your only template you discover that one one just restored doesn't work for any reason. Or accidentally select too many VMs to restore and override not stale one.
If you really want to do this, IMO better have some script that will replace appropriate VMs, after restoring them with qvm-backup-restore --rename-conflicting. Probably also possible using Salt, but not sure if easier.

[andrewdavidwong]

it would be extremely easy to shoot in the foot using this option.

Wouldn't that depend on how it's implemented (e.g., positive confirmation with a list of VMs to be replaced)?

For example after replacing your only template you discover that one one just restored doesn't work for any reason. Or accidentally select too many VMs to restore and override not stale one.

How is this different from all the other ways users can accidentally destroy their VMs? Updating your only template can render it unusable, qvm-remove doesn't even require confirmation, etc.

[andrewdavidwong]

it would be extremely easy to shoot in the foot using this option.

Wouldn't that depend on how it's implemented (e.g., positive confirmation with a list of VMs to be replaced)?

For example after replacing your only template you discover that one one just restored doesn't work for any reason. Or accidentally select too many VMs to restore and override not stale one.

How is this different from all the other ways users can accidentally destroy their VMs? Updating your only template can render it unusable, qvm-remove doesn't even require confirmation, etc.

[andrewdavidwong]

If the reply is, "Well, in those other cases, you have the option of reverting the changes from a backup," then the same reasoning applies here. Just because you're replacing VMs doesn't mean you shouldn't have a backup the of the VMs you're replacing (or be willing to lose them).

[andrewdavidwong]

If the reply is, "Well, in those other cases, you have the option of reverting the changes from a backup," then the same reasoning applies here. Just because you're replacing VMs doesn't mean you shouldn't have a backup the of the VMs you're replacing (or be willing to lose them).