On Thu, 15 May 2008, Gerd Hoffmann wrote: > It is pretty clear that *supporting* such a configuration is impossible > and that running it on production systems is a really bad idea for the > reasons outlined. > > Nevertheless being able to pass random additional arguments to $emulator > is required for any serious development work. I *hate* to having to > create a wrapper script each time I need to pass in additional > parameters, and I'd *love* to see libvirt being a bit more developer > friendly. > > libvirt & tools should make my life easier, not harder. That includes > my development work, because using that stuff on a daily base will > improve the quality alot. If I stop using libvirt for xenner > development because it is easier to get the job done without we all lose. I support this idea. And also want to point out that as far as I can see now in the documentation, libvirt isn't the holy grail that is semantically correct everywhere from the start (examples: relation between storage pools and the actual domains, statistics of network interfaces by domains, etc.) Adding features that are enabled with #ifdef HAVE_DEVELOPMENT would be a good thing. Also handeling things that are imported in libvirt as 'relative' pointers, and never having to refer to something os/distro specific would be a great starting point. Stefan -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list