[libvirt] [PATCH 02/35] qemu: domain: Format storage source node names into private data

[Peter Krempa]

On Tue, May 01, 2018 at 20:06:43 -0400, John Ferlan wrote:
> 
> 
> On 04/25/2018 11:15 AM, Peter Krempa wrote:
> > 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 at redhat.com>
> > ---
> >  src/qemu/qemu_domain.c                    | 12 ++++++++++++
> >  tests/qemustatusxml2xmldata/modern-in.xml |  4 ++++
> >  2 files changed, 16 insertions(+)
> 
> So, what would cause a need for recalculation?  Or losing them?
> 
> I assume it's "expensive" to query, but then I wonder what trap we could
> fall into by saving them. If we've needed to recalculate or lost them
> before, what's to say that same issue doesn't happen by saving them?

Well. Currently we use node-names only for the 'block-threshold' event
and we get them by querying them from qemu. Since they are not stored in
the XML a libvirtd restart requires us to re-query them.

In the future we will start generating and providing our own node names
to the block layer, so it will be required that we remember them.

Both re-generating and detecting is way more complicated than just
storing them.

> I also assume they don't change after we've saved them, right? I'm not
> opposed to this, it's the OK so how are they to be used and then why if
> they could be lost or needed recalculation would we want to save them?
> Also, what assurances do we have then when they are to be saved that
> they aren't in a condition that caused this patch to be generated.

No, they just are lost on restart.

> If the only way to get the 'real' value is ask QEMU, then why not ask?
> It's not like an alias which we generated it's IIUC something QEMU
> generates and wishes to be referenced in that manner.
> 
> Maybe it's just the wording of the commit that raised the questions ;-)

Umm probably yes. I've had this commit around for a long time :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180502/1915f37e/attachment-0001.sig>