Re: [libvirt] [PATCH 02/35] qemu: domain: Format storage source node names into private data
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(a)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 :)
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)