Hi all, >From what I've gathered, it seems that we have basically four options at hand. I think it's important to notice, however, that whatever comes out of this will probably be, as Avi said, a "low-end" solution. IMHO there's room to have both the high-end libvirt-like approach, and the "shell replacer" approach.
So let's see: 1- We could go the way of the patches I've posted, adding the comments everyone's made. 1a- It's a good idea to actively signal QEMU to read command line options from the image file, and not have it on by default. 1b- As Avi said, there are many guest-related options that would be good to store _somewhere_. The user always has the option of using qemu-img to review the options that the VM is going to use. I think that having a "valid" set of options that the user can store will complicate things too much. 2- We could bump qcow's version number and add command line options as "first-class citizens" of the image world. 2a- As Anthony suggested, it could be a good starting point to make sure these version transition happen in a smoother way. 3- We could add command line options as plain text in the image itself. Sounds (to me) risky and not very user friendly. 4- We could have configuration files associated with the host and guests. 4a- Embedded XML. 4b- Separate files. What do you guys think? I'm partial to 1 or 2. Since the beginning my approach was that of a simple solution for a simple feature. Cheers, Jorge