> > The management tooI just needs to convert the config - looks quite easy to > me. > > It's not an easy problem. This is why there is no central vm-images.com where > everyone can share/sell virtual appliances. You cannot trivially convert > between > VMware, oVirt, proxmox, Xen, EC2, etc.
For that case, I added the ability to write several different config files into a VMA archive. So If someone want to distribute an appliance, he can simply add a config file for each manager. > > > 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?) > > block/nbd.c already exists so it saves you from writing the QEMU-side code to > export data to another process. Is there some documentation about that NBD protocol? > The archive writer program opens a listen socket for each block device that is > being backed up. Then it handles NBD WRITE requests from QEMU. I still think using a specific protocol is wrong. You don't want to use NDB if you can directly talk to some backup server?