Anthony Liguori wrote: > 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.
It's not as bad as that -- the user has to remember only option (or have a qemu-trusted script that supplies the option). But I agree that the feature is now much less compelling, and that the new option is needed. > >> 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. > For which use case? management-full or management-less? A managed system will want to supply arguments out of a central database. For a management-less use case, the config file is a hassle. ------------------------------------------------------------------------- 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
