[pve-devel] [PATCH v3 qemu-server 08/11] blockdev: convert drive_mirror to blockdev_mirror

[Fabian Grünbichler]

> DERUMIER, Alexandre <alexandre.derumier at groupe-cyllene.com> hat am 13.01.2025 11:47 CET geschrieben:
> 
>  
> >>something like this was what I was afraid of ;) this basically means
> >>we need to have some way to lookup the nodes based on the structure
> >>of the graph, which probably also means verifying that the structure
> >>matches the expected one (e.g., if we have X snapshots, we expect N
> >>nodes, if we currently have operation A going on, there should be an
> >>extra node, etc.pp. - and then we can "know" that the seventh node
> >>from the bottom must be snapshot 'foobar' ;)). 
> 
> I think it's not a much a problem to follow the graph from top to
> bottom. (as everything attached is have parent-child relationship)
> and
> 
> - for snapshot, we have the snapshot name in the filename
> So we can known if it' a specific snap or the live image.
> 
> 
> for the temporary nodes (when we do block-add, before a mirror or
> switch), we define the nodename, so we don't need to parse the graph
> here.
> 
> 
> 
> >>relying on $path being >>stable definitely won't work.
> 
> I really don't see why the path couldn't be stable ?
> 
> Over time, if something is changing in qemu (for example, rbd://....
> with a new param),
> it'll only be apply on the new qemu process (after restart or live
> migration), so the path in the block-node will be updated too. (live
> migration will not keep old block-nodes infos, the used value are qemu
> command line arguments)
> 
> 
> and the file path is the only attribute in a node that you can't
> update.

the path referenced in the running VM is stable. the path you are looking for in the graph is not. e.g., the path might be something some storage software returns. or udev. or .. and that can change with any software upgrade or not be 100% deterministic in the first place.

let's say you start the VM today and the path returned by the RBD storage plugin is /dev/rbd/XYZ, so that is how the blockdev is opened/the path is recorded. in two weeks, ceph gets updated and now the udev rule or the storage plugin code changes to return the more deterministic /dev/rbd/POOL/XYZ. now the paths don't match anymore. (this is just an example where such a thing happened in practice already ;)).