> The difference between this approach and Dietmar's series is that the backup > archive format is implemented outside QEMU and runs as a separate program. > > This way, management tools like proxmox, oVirt, OpenStack, and others can > provide their preferred backup archive formats without modifying QEMU.
So you propose that everyone should use another backup format - this is a bad thing because it lead to interoperability problems (vendor lock-in?) > This has many advantages: > > * 'block-backup' composes with 'migration' and other commands, unlike the > monolithic 'backup' command designed just for writing backup archives Yes, but you can add that easily on top of my patches. > > * Backup code can be updated or added outside the QEMU release cycle > > * Choice of language, coding style, and license for backup code > > * Less QEMU code to test and maintain The question is why you would want to write and maintain your own backup solution? This is an disadvantage, not an advantage. If we have working code inside qemu, everybody can use it. This will lead to better testing, more stable code, and finally we can even try to make backup/restore work across different management frameworks. So while you have "Less QEMU code to test and maintain", it will lead to more code you have to test and maintain - not inside qemu, but outside qemu ;-)
