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

[Fabian Grünbichler]

> Fabian Grünbichler <f.gruenbichler at proxmox.com> hat am 13.01.2025 10:52 CET geschrieben:
> 
>  
> > DERUMIER, Alexandre <alexandre.derumier at groupe-cyllene.com> hat am 13.01.2025 09:27 CET geschrieben:
> > 
> >  
> > > +    my $path = PVE::Storage::path($storecfg, $volid);
> > 
> > >>is this guaranteed to be stable? also across versions? and including
> > >>external storage plugins?
> > 
> > it can't be different than the value we have use for command line
> > generation. But I think that I should use $path directly (It's working
> > for block/file  ,  but I think it'll not work with ceph,gluster,...)
> > I need to reuse the code used to generated the blockdev commande line.
> > 
> > Another way, maybe a better way,is to parse the tree from the top node
> > (the throttle-group) where the name is fixed.  and look for fmt|file
> > chain attached to this node.
> > 
> > (I just need need to check when we are a doing live renaming, we have 2
> > files nodes, with the newer file node not attached to the tree before
> > the switch)
> > 
> > 
> > 
> > > +
> > > +    my $node = find_blockdev_node($nodes, $path, 'fmt');
> > 
> > >>that one is only added in a later patch.. but I don't think lookups
> > >>by path are a good idea, we should probably have a deterministic node
> > >>naming concept instead? e.g., encode the drive + snapshot name?
> > 
> > I really would like to have something deterministic but:
> > 
> > - devices node are 31 characters max.   (snapshot name can be more big)
> > - we can't rename a node  (but we are renaming files for snapshot over
> > time)
> > 
> > 
> > As Fiona said, we could have random names and do 1 lookup each time to
> > list them.
> > 
> > (I really need to have our own name, because blockdev-reopen, for live
> > renaming of files, is not working with autogenerated block# name)
> 
> 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' ;)). relying on $path being stable definitely won't work.

something more to add to this - if it is impossible to map back using the structure alone, we might need to somehow keep track ourselves for the full livecycle of the VM? e.g., find a way to attach the "volid+snap" information to a block node as metadata, or to add such a mapping inside the VM or alongside it? OTOH, that approach would then break if a user does a manual QMP block operation (but those are error prone already anyway)