qvm-export-vm tool

[rootkovska]

In contrast to qvm-backup this tool, qvm-export-vm should not include other system-wide info besides the select VM(s) the user is willing to export, e.g. with an intention to share with others. This should be simple to implement on Qubes 4 due to non needing to create qubes.xml with complete system information.

[bnvk]

@rootkovska this sounds like an interesting feature / tool especially the "intention to share" aspect. Can you elaborate on implementations? Is it via physical media, network, or both? I've thought about "sharing" in respect to Qubes via tools like ownCloud, Syncthing, or Tahoe LAFS and how this could be a powerful way to utilize properties of Qubes for an interesting / easy to use UX!

[bnvk]

@rootkovska this sounds like an interesting feature / tool especially the "intention to share" aspect. Can you elaborate on implementations? Is it via physical media, network, or both? I've thought about "sharing" in respect to Qubes via tools like ownCloud, Syncthing, or Tahoe LAFS and how this could be a powerful way to utilize properties of Qubes for an interesting / easy to use UX!

[rootkovska]

Like qvm-backup, the tool would only be concerned with creating encrypted blob in a selected AppVM. What the user is gonna do later with that blob (an ordinary file) - upload to cloud, save on a USB stick, send via email - is left up to the user. Like in case of qvm-backup. Only difference: this time the blob would not contain any system-wide info other than the info for the exported VM(s) (if you use qvm-backup it stores a copy of a complete qubes.xml in the backup blob, which contains info about all your VMs and inter-connections between them, regardless of what subset of VMs the user selected for inclusion in the backup).

[rootkovska]

Like qvm-backup, the tool would only be concerned with creating encrypted blob in a selected AppVM. What the user is gonna do later with that blob (an ordinary file) - upload to cloud, save on a USB stick, send via email - is left up to the user. Like in case of qvm-backup. Only difference: this time the blob would not contain any system-wide info other than the info for the exported VM(s) (if you use qvm-backup it stores a copy of a complete qubes.xml in the backup blob, which contains info about all your VMs and inter-connections between them, regardless of what subset of VMs the user selected for inclusion in the backup).

[tasket]

Could add a --no-sysinfo option to qvm-backup and have qvm-export-vm call it as the last step. Also, multiple vms could be packaged this way, which could enable things like customized proxy/appvm pairs.

[tasket]

Could add a --no-sysinfo option to qvm-backup and have qvm-export-vm call it as the last step. Also, multiple vms could be packaged this way, which could enable things like customized proxy/appvm pairs.

[marmarek]

It's tricky to do this with current qvm-backup design goals. It's gloal is to preserve all the VMs with configuration. Which includes things like dependencies between VMs (template, netvm etc). Exporting only selected VMs this way, may be impossible without loosing some information, which we don't want to happen for backups. So, to lower such risk, it should be a separate tool.

[marmarek]

It's tricky to do this with current qvm-backup design goals. It's gloal is to preserve all the VMs with configuration. Which includes things like dependencies between VMs (template, netvm etc). Exporting only selected VMs this way, may be impossible without loosing some information, which we don't want to happen for backups. So, to lower such risk, it should be a separate tool.