Hi folks, I identified a problem with the migration code that Red Hat QE found and thought you'd like to see it:
https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20 Very, very briefly: drive-mirror inserts a filter node that changes what bdrv_get_device_or_node_name() returns, which causes a migration problem. Ignorant question #1: Can we multi-parent the filter node and source-node? It looks like at the moment both consider their only parent to be the block-job and don't have a link back to their parents otherwise. 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.) A simple way to do this might be a "child_unfiltered" BdrvChild role that simply bypasses the filter that was inserted and serves no real purpose other than to allow the child to have a parent link and find who it's """real""" parent is. Because of flushing, reopen, sync, drain &c &c &c I'm not sure how feasible this quick idea might be, though. - Corollary fix #1: call error_setg if the bitmap node name that's about to go over the wire is an autogenerated node: this is never correct! (Why not? because the target is incapable of matching the node-name because they are randomly generated AND you cannot specify node-names with # prefixes as they are especially reserved! (This raises a related problem: if you explicitly add bitmaps to nodes with autogenerated names, you will be unable to migrate them.)) --js
