[libvirt] [PATCH 09/10] libxl: Stubdom emulator type
Marek Marczykowski-Górecki
marmarek at invisiblethingslab.com
Thu Mar 5 15:48:47 UTC 2015
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150305/ae49ef15/attachment-0001.sig>
More information about the libvir-list
mailing list