> > In future, we can allow to pass multiple config files - the vma > > archive format can already handle that. > > My point is that QEMU has no business dealing with the management tool's VM > configuration file. And I think the management tool-specific archive format > also > shouldn't be in QEMU. > > How will a proxmox user restore a VMA file generated with oVirt since the > configuration file comes from the management layer? They can't because the > VMA is specific to the management layer and should be handled there, not > inside > QEMU.
The management tooI just needs to convert the config - looks quite easy to me. > QEMU must provide the mechanism for point-in-time backups of block devices - > your backup block job implements this. > > Where I disagree with this patch series is that you put the management tool- > specific archive format writer into QEMU. That is outside the scope of QEMU. > The management tool should tell QEMU to take the backups of block devices > and do a live migration to file. > > The management tool can use a NBD server if it wants to capture all the block > device backups into a single archive. And the management tool can bundle the > VM configuration into that archive too. But those steps are beyond the scope > of > QEMU. > > The approach I'm suggesting is more modular. For example, the backup block > job can also be used to copy out the state of a disk into a new > qcow2 file. OK, I can try to split the code. But I think I will simply define a 'protocol' instead of using an NBD server (what for?) > > > > +## > > > > +# @backup: > > > > +# > > > > +# Starts a VM backup. > > > > +# > > > > +# @backup-file: the backup file name # # @format: format of the > > > > +backup file # # @config-filename: #optional name of a > > > > +configuration file to include into # the backup archive. > > > > +# > > > > +# @speed: #optional the maximum speed, in bytes per second # # > > > > +@devlist: #optional list of block device names (separated by ',', ';' > > > > +# or ':'). By default the backup includes all writable block devices. > > > > +# > > > > +# Returns: the uuid of the backup job # # Since: 1.5.0 ## { > > > > +'command': 'backup', 'data': { 'backup-file': 'str', > > > > + '*format': 'BackupFormat', > > > > + '*config-file': 'str', > > > > + '*devlist': 'str', '*speed': 'int' > > > > +}, > > > > > > devlist should be ['String']. > > > > I want to be able to use that command on the human monitor. > > That is no longer possible if I use ['String']? > > Good question. I don't know the answer but perhaps Luiz or Anthony do (CCed)? > > > > > diff --git a/qmp-commands.hx b/qmp-commands.hx index > > > > 799adea..17e381b > > > > 100644 > > > > --- a/qmp-commands.hx > > > > +++ b/qmp-commands.hx > > > > @@ -889,6 +889,18 @@ EQMP > > > > }, > > > > > > > > { > > > > + .name = "backup", > > > > + .args_type = "backup-file:s,format:s?,config- > file:F?,speed:o?,devlist:s?", > > > > + .mhandler.cmd_new = qmp_marshal_input_backup, > > > > + }, > > > > + > > > > + { > > > > + .name = "backup-cancel", > > > > + .args_type = "", > > > > + .mhandler.cmd_new = qmp_marshal_input_backup_cancel, > > > > + }, > > > > > > We might want to more than one backup if the guest has multiple disks. > > > For example, the database disk is backed up independently of the main OS > disk. > > > > > > This API only allows one backup to run at a time. > > > > I do not want multiple backup jobs. You can easily run 2 jobs in sequence to > solve above use case. > > Why do you not want multiple backup jobs? It makes perfect sense to separate > database disks from main OS disks. They have different backup characteristics > (how often to back up, how to restore) so it's likely that users will ask for > multiple backup jobs at the same time. Let's get the QMP interfaces right so > that > it can be supported in the future, if not right away. So you want to pass the 'uuid' to backup-cancel?