Jorge Lucángeli Obes wrote: > 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. >
I think if you have to add a new option, the base implementation is wrong. The whole point of this is to simplify things for the user and adding more weird options just makes things more complicated. > 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. > Why is it risky or user unfriendly? From the user's perspective, it's no different from storing it in a snapshot. The user still needs a separate tool (qemu-img) to view and manipulate the command line. The only real user facing difference is that the image itself is now directly executable. This turns out to be a Good Thing in that the user is now aware that he must trust that image which addresses the concern in 1a. > 4- We could have configuration files associated with the host and guests. > 4a- Embedded XML. > 4b- Separate files. > This is a big effort but a config file is the right long term solution. Regards, Anthony Liguori > 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 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
