Re: [PATCH 09/10] libxl: Stubdom emulator type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]