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>
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
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|