01.10.2019 19:16, Kevin Wolf wrote: > Am 01.10.2019 um 17:57 hat Vladimir Sementsov-Ogievskiy geschrieben: >> 01.10.2019 17:10, John Snow wrote: >>> >>> >>> On 10/1/19 10:00 AM, Vladimir Sementsov-Ogievskiy wrote: >>>>> Otherwise: I have a lot of cloudy ideas on how to solve this, but >>>>> ultimately what we want is to be able to find the "addressable" name for >>>>> the node the bitmap is attached to, which would be the name of the first >>>>> ancestor node that isn't a filter. (OR, the name of the block-backend >>>>> above that node.) >>>> Not the name of ancestor node, it will break mapping: it must be name of >>>> the >>>> node itself or name of parent (may be through several filters) >>>> block-backend >>>> >>> >>> Ah, you are right of course -- because block-backends are the only >>> "nodes" for which we actually descend the graph and add the bitmap to >>> its child. >>> >>> So the real back-resolution mechanism is: >>> >>> - Find the first non-filter ancestor, A >>> - if A is not a block-backend, we must use our node-local name. >>> - if A's name is empty, we must use our node-local name. >>> - If the name we have chosen is not id_wellformed, we have no >>> migration-stable addressable name for this bitmap and the migration must >>> fail! >>> >>> >>> For resolving bitmap addresses via QMP (node, name) pairs; the >>> resolution method would be this: >>> >>> - if the node-name N is a block-backend, descend the tree until we find >>> the first non-filter node V. >>> - if the node-name N is a BlockDriverState, use this node directly. >>> >> >> Looks good for me. >> >> I also think if on destination we have both block-backend with name N and >> block-node with name N and the latter is not (filtered) child of the former, >> we should fail migration of at least that bitmap. (Hope, nobody reuse >> block-backend names as node-names in practice.. (should we restrict it >> explicitly ?)) > > You can't have a node and a BlockBackend of the same name, they share a > single namespace. If you try to do so, you get an error. >
Oh, thanks, that's cool. -- Best regards, Vladimir
