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

Re: [libvirt] [PATCH] Openvz: how to use a nondefault config

2009/4/2 Daniel P. Berrange <berrange redhat com <mailto:berrange redhat com>>

    On Thu, Apr 02, 2009 at 06:36:15PM +0400, Evgeniy Sokolov wrote:
     > Config /etc/vz/conf/ve-XXX.conf-sample define there are many
     > like  memory, CPU etc. This parameters are not properties of
     > Daniel, usage of pre-defined configs in really usefull. Can we create
     > additional tag inside <domain></domain>?

    The trouble with this is that given the XML config of a guest, you can
    no longer determine what its configuration is, because a large amount
    of configuration is hidden in this opaque 'template'.

And in kvm/qemu case there is a lot of hidden information too :)
In OpenVZ case we don't loose any info (see below).

    If we're to support templates, I think we need to make them first class
    objects, so you can query what templates exist, and see their associated
    config settings.

    eg, expose a simple API


      int virConnectListDomainTemplates(virConnectPtr conn, const char
      virDomainTemplatePtr virDomainTemplateLookupbyName(virConnectPtr
    con, const char *name)
      char *virDomainTemplateGetXMLDesc(virDomainTemplatePtr tmpl);
      virDomainTemplatePtr virDomainTemplateDefineXML(virConnectPtr
    conn, const char *xml)
      int virDomainTemplateUndefine(virDomainTemplatePtr tmpl);
      int virDomainTemplateFree(virDomainTemplatePtr tmpl);

    Then, we could either include a <template>$NAME</template> parameter in
    the XML for a guest. Or have an alternate API for creating guests

      virDomainCreateXMLWithTemplate(virConnectPtr conn,
                                     const char *xmlDesc,
                                     const char *template)

    It depends whether we'd want to track the template <-> guest association
    forever, or just use it once to fill-in the guest XML and then forget
    about the template after that.

Template <-> guest association don't need. Information is used only once.

So, we will extend libvirt API by
and will include <template>$NAME</template> to <domain></domain>.

Daniel, is it correct?

It doesn't matter in OpenVZ case: template (or, "config", in openvz terminology) is used only
once, when container is creating. But then per-container "copy" is created,
and it is already used by libvirt to keep information about container. Per-container OpenVZ config keeps the name of the original config (in ORIGIN_SAMPLE variable).
ORIGIN_SAMPLE is not used by OpenVZ, and don't need. It is saved to config for using external tools.

Is there need for "Template API" in case of other hypervisors?


Libvir-list mailing list
Libvir-list redhat com

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