[PATCH 7/7] qemudomainsnapshotxml2xmltest: Add test case for a snapshot with 'inactiveDomain' element

Peter Krempa pkrempa at redhat.com
Mon Sep 26 11:38:22 UTC 2022


On Mon, Sep 26, 2022 at 12:07:07 +0100, Daniel P. Berrangé wrote:
> On Thu, Aug 25, 2022 at 11:46:10AM +0200, Peter Krempa wrote:
> > Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> > ---
> >  .../memory-snapshot-inactivedomain.xml        | 148 ++++++++++++++++++
> >  tests/qemudomainsnapshotxml2xmltest.c         |   2 +
> >  2 files changed, 150 insertions(+)
> >  create mode 100644 tests/qemudomainsnapshotxml2xmlout/memory-snapshot-inactivedomain.xml
> 
> snip
> 
> > diff --git a/tests/qemudomainsnapshotxml2xmlout/memory-snapshot-inactivedomain.xml b/tests/qemudomainsnapshotxml2xmlout/memory-snapshot-inactivedomain.xml
> > new file mode 100644
> > index 0000000000..3acc6d952b
> > --- /dev/null
> > +++ b/tests/qemudomainsnapshotxml2xmlout/memory-snapshot-inactivedomain.xml
> > @@ -0,0 +1,148 @@
> 
> 
> > +  <cookie>
> > +    <cpu mode='custom' match='exact' check='full'>
> > +      <model fallback='forbid'>qemu64</model>
> > +      <feature policy='require' name='x2apic'/>
> > +      <feature policy='require' name='hypervisor'/>
> > +      <feature policy='require' name='lahf_lm'/>
> > +      <feature policy='disable' name='svm'/>
> > +    </cpu>
> > +    <slirpHelper/>
> > +  </cookie>
> > +</domainsnapshot>
> 
> As best I can tell this  <cookie> element is undocumented and further
> contains arbitrary undocumented hypervisor specific XML content :-(
> 
> This is really horrible and really should have been hidden behind a
> driver specific XML namespace.
> 
> Can someone explain more about the <cookie> ?

AFAIK it's something akin to the migration cookie, but for the save
image/snapshot it's stored inside the snapshot XML, rather than passed
via a side-band.

IIUC it's required also in the snapshot XML (not just in the save image
XML) as internal snapshots don't store the XML in-band.

> If this is a strictly output only element, which applications are
> not expected to parse or interpret, just pass along "as is", then
> it is possible we can fix/improve this, to clearly demarcate what
> is our public XML schema and what is opaque driver specific schema.

It's indeed private and driver specific. There's a driver specific
callback to format it.


More information about the libvir-list mailing list