Re: [PATCH 7/9] libxl: Stubdom emulator type

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

 



On Fri, Mar 13, 2015 at 02:09:34PM -0600, Jim Fehlig wrote:
> Marek Marczykowski-Górecki wrote:
> > Xen have feature of having device model in separate domain (called stub
> > domain). Add <stubdomain> element to allow selecting such configuration.
> > Emulator path is still used for qemu running in dom0 (if any). Libxl currently
> > do not allow to select stubdomain path.
> >
> > Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> > ---
> >  docs/formatdomain.html.in     | 13 +++++++++++++
> >  docs/schemas/domaincommon.rng | 10 ++++++++++
> >  src/conf/domain_conf.c        | 14 ++++++++++++++
> >  src/conf/domain_conf.h        |  3 ++-
> >  src/libxl/libxl_conf.c        |  8 ++++++++
> >  5 files changed, 47 insertions(+), 1 deletion(-)
> >
> > Changes in v4:
> >  - change <emulator type='stubdom'> to separate <stubdomain> element
> >
> > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> > index fb0a0d1..054f48f 100644
> > --- a/docs/formatdomain.html.in
> > +++ b/docs/formatdomain.html.in
> > @@ -1670,6 +1670,19 @@
> >        </dd>
> >      </dl>
> >  
> > +    <dl>
> > +      <dt><code>stubdomain</code></dt>
> > +      <dd>
> > +        <span class="since">Since 1.2.13</span>, the optional <code>stubdomain</code>
> > +          element contains <code>enabled</code> yes/no/default attribute. If enabled
> > +          Emulator will be launched in stub domain (Xen only). Currently there
> > +          is no way to provide path to that emulator. Note that in most cases
> >   
> > + this emulator will be in addition to one in dom0.
> 
> Why does a stubdomain need an emulator (running in dom0) to serve as a
> backend?  Wouldn't it be better to give the stubdomain direct access to
> the resources it needs?  Otherwise, It seems to defeat stubdomain's
> purpose of moving the emulator execution out of dom0.  At least the Xen
> wiki describes this as primary motivation for studomains
> 
> http://wiki.xen.org/wiki/Device_Model_Stub_Domains

Two reasons:
1. To host video/keyboard (vfb/vkb) backends for stubdomain - stubdomain
have no simple way to expose VNC server to the network.
2. To host a console backend. Xenconsoled supports only one console per
domain, but qemu in stubdomain needs at least three (logs, pipe to save
the state and another one to restore the state during save/restore).

Actually in Qubes OS we have our own GUI agent, so the first point is not
needed. And we broke the second one just to get rid of qemu in dom0...
I'll be more than happy if/when xenconsoled will get support for more
than one console device per domain.

> > +          <code>emulator</code> element described above still controls the path
> > +          to the dom0 instance.
> > +      </dd>
> > +    </dl>
> >   
> > +
> 
> I think it would be good to add an example above the description.  E.g.
> along the lines of Daniel's previous example
> 
>   <devices>
>     <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
>     <stubdomain enabled="yes|no"/>
>   </devices>

Ok, I'll add it in the next patch version (if any).

> Regards,
> Jim
> 
> >      <h4><a name="elementsDisks">Hard drives, floppy disks, CDROMs</a></h4>
> >  
> >      <p>
> > diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> > index 4e4fe9f..539db39 100644
> > --- a/docs/schemas/domaincommon.rng
> > +++ b/docs/schemas/domaincommon.rng
> > @@ -2567,6 +2567,13 @@
> >        <ref name="absFilePath"/>
> >      </element>
> >    </define>
> > +  <define name="stubdomain">
> > +    <element name="stubdomain">
> > +      <attribute name="enabled">
> > +        <ref name="virYesNo"/>
> > +      </attribute>
> > +    </element>
> > +  </define>
> >    <!--
> >        A graphic description, currently in Xen only 2 types are supported:
> >          - sdl with optional display, xauth and fullscreen
> > @@ -4007,6 +4014,9 @@
> >          <optional>
> >            <ref name="emulator"/>
> >          </optional>
> > +        <optional>
> > +          <ref name="stubdomain"/>
> > +        </optional>
> >          <zeroOrMore>
> >            <choice>
> >              <ref name="disk"/>
> > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> > index c430e03..e327e55 100644
> > --- a/src/conf/domain_conf.c
> > +++ b/src/conf/domain_conf.c
> > @@ -14107,6 +14107,9 @@ virDomainDefParseXML(xmlDocPtr xml,
> >      }
> >  
> >      def->emulator = virXPathString("string(./devices/emulator[1])", ctxt);
> > +    tmp = virXPathString("string(./devices/stubdomain/@enabled)", ctxt);
> > +    if (tmp)
> > +        def->stubdomain = virTristateBoolTypeFromString(tmp);
> >  
> >      /* analysis of the disk devices */
> >      if ((n = virXPathNodeSet("./devices/disk", ctxt, &nodes)) < 0)
> > @@ -16064,6 +16067,14 @@ virDomainDefCheckABIStability(virDomainDefPtr src,
> >          goto error;
> >      }
> >  
> > +    if (src->stubdomain != dst->stubdomain) {
> > +        virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> > +                _("Target domain stubdomain '%s' does not match source '%s'"),
> > +                virTristateBoolTypeToString(dst->stubdomain),
> > +                virTristateBoolTypeToString(src->stubdomain));
> > +        goto error;
> > +    }
> > +
> >      if (!virDomainDefFeaturesCheckABIStability(src, dst))
> >          goto error;
> >  
> > @@ -20303,6 +20314,9 @@ virDomainDefFormatInternal(virDomainDefPtr def,
> >  
> >      virBufferEscapeString(buf, "<emulator>%s</emulator>\n",
> >                            def->emulator);
> > +    if (def->stubdomain)
> > +        virBufferAsprintf(buf, "<stubdomain enabled='%s'/>\n",
> > +                          virTristateBoolTypeToString(def->stubdomain));
> >  
> >      for (n = 0; n < def->ndisks; n++)
> >          if (virDomainDiskDefFormat(buf, def->disks[n], flags) < 0)
> > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> > index 36c8131..446f4f0 100644
> > --- a/src/conf/domain_conf.h
> > +++ b/src/conf/domain_conf.h
> > @@ -2108,9 +2108,10 @@ struct _virDomainDef {
> >  
> >      virDomainOSDef os;
> >      char *emulator;
> > -    /* These three options are of type virTristateSwitch,
> > +    /* These four options are of type virTristateSwitch,
> >       * except VIR_DOMAIN_FEATURE_CAPABILITIES that is of type
> >       * virDomainCapabilitiesPolicy */
> > +    int stubdomain;
> >      int features[VIR_DOMAIN_FEATURE_LAST];
> >      int apic_eoi;
> >      int hyperv_features[VIR_DOMAIN_HYPERV_LAST];
> > diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> > index 50ef9d8..8ec3c75 100644
> > --- a/src/libxl/libxl_conf.c
> > +++ b/src/libxl/libxl_conf.c
> > @@ -727,6 +727,14 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
> >              b_info->device_model_version = libxlDomainGetEmulatorType(def);
> >          }
> >  
> > +        /* In case of stubdom there will be two qemu instances:
> > +         *  - in stubdom (libxl uses hardcoded path for this one),
> > +         *  - in dom0 as a backend for stubdom (if needed).
> > +         */
> > +        if (def->stubdomain)
> > +            libxl_defbool_set(&b_info->device_model_stubdomain,
> > +                              def->stubdomain == VIR_TRISTATE_BOOL_YES);
> > +
> >          if (def->nserials) {
> >              if (def->nserials > 1) {
> >                  virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> >   

-- 
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: pgppbGjhAsPju.pgp
Description: PGP signature

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