On Wed, Mar 04, 2015 at 08:34:26PM +0000, Daniel P. Berrange wrote: > On Thu, Feb 19, 2015 at 10:19:22PM +0100, Marek Marczykowski-Górecki wrote: > > On Thu, Feb 19, 2015 at 01:45:52PM -0700, Jim Fehlig wrote: > > > Marek Marczykowski-Górecki wrote: > > > > Xen have feature of having device model in separate domain (called stub > > > > domain). Add a 'type' attribute to 'emulator' element to allow selecting > > > > such a configuration. > > > > > > Or maybe 'mode', describing the mode in which the emulator runs: as a > > > process or as a VM. > > > > > > > Emulator path is still used for qemu running in dom0 (if > > > > any). Libxl currently do not allow to select stubdomain path. > > > > > > > > > > That seems to overload a single <emulator>. Would it be better to have > > > multiple <emulators>? E.g. > > > > > > <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> > > > <emulator mode='stubdomain'>/usr/lib/xen/bin/stubdom-dm</emulator> > > > > So the existence of <emulator mode='stubdomain'/> would enable this feature? > > What if someday the default will be to run stubdomain emulator - how > > the user can disable it in such case? > > This suggests to me we need to have two separate controls. > First an attribute / element somewhere saying what device > mode is used, and the second (optionally) saying what the > path to the stubdom emulator is. > > eg no stubdomain: > > <devices> > <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> > ... > </devices> > > Stubdomain with default path > > <devices> > <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> > <stubdomain enabled="yes|no"/> > </devices> > > Stubdomain with custom path > > > <devices> > <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> > <stubdomain enabled="yes|no"> > <emulator>/usr/lib/xen/bin/stubdom-dm</emulator> > </stubdomain> > </devices> I like this approach :) > We can of course not worry about this 3rd option until libxl actually > supports this. So, just implement <stubdomain enabled="yes|no"/> > for now. If <stubdomain> is not listed in the XML from the application, > the XML post-parse callback can be used by the hypervisor to fill in > the default either <stubdomain enabled="yes"/> or <stubdomain enabled="no"/> > as appropriate. So that copes with xen changing its default in the > future I see libvirt has cool virTristateBool type, which I will use here. So the lack of <stubdomain> element will mean "use hypervisor default". As in many other places I think. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
Attachment:
pgpkAvxcAsKhM.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list