On Fri, Apr 20, 2018 at 09:30:16 +0200, Kevin Wolf wrote:
> Am 19.04.2018 um 17:24 hat Peter Krempa geschrieben:
> > Save and restore node names if we know them in the status XML so that we
> > don't need to recalculate them or don't lose them in some cases.
> >
> > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> > ---
> > src/qemu/qemu_domain.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index e2a8450e2e..224b3b0478 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -1934,6 +1934,9 @@ static int
> > qemuStorageSourcePrivateDataParse(xmlXPathContextPtr ctxt,
> > virStorageSourcePtr src)
> > {
> > + src->nodestorage = virXPathString("string(./nodename/@storage)", ctxt);
> > + src->nodeformat = virXPathString("string(./nodename/@format)", ctxt);
> > +
> > if (virStorageSourcePrivateDataParseRelPath(ctxt, src) < 0)
> > return -1;
>
> This format doesn't look very future-proof. I can see that using
> x->nodestorage and x->nodeformat internally are probably easier for now,
> but while the assumption of exactly two layers (except for backing
> files) is probably correct for most cases, it will become less and less
> common the more we use filter drivers.
>
> Representing an arbitrary tree (or even non-tree graph) in the XML may
> be unpractical now, but please be aware that you'll probably need this
> change in the long run.
Yes. It will need to change e.g. if we allow IO throttling for other
than the top layer. On the other hand it would be impractical to change
to the topology qemu uses where a storage file is two layers minimum, so
we will need to track everyting for one layer of XML.
As the above uses attributes in the XML we can add an arbitrary amount
of them if required.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
