Re: bitmap migration bug with -drive while block mirror runs

[Peter Krempa <pkrempa@redhat.com>]

On Tue, Oct 01, 2019 at 17:26:13 +0200, Max Reitz wrote:
> On 01.10.19 16:53, Vladimir Sementsov-Ogievskiy wrote:
> > 01.10.2019 17:34, Max Reitz wrote:
> >> On 01.10.19 16:27, Vladimir Sementsov-Ogievskiy wrote:
> >>> 01.10.2019 17:13, Max Reitz wrote:
> >>>> On 01.10.19 16:00, Vladimir Sementsov-Ogievskiy wrote:
> >>>>> 01.10.2019 3:09, John Snow wrote:

[...]

> Well, I’d think it should be on the one with the same node name, but it
> appears others don’t want a node-name-based mapping, so maybe I should
> just stop trying to be part of the discussion. :-)
> 
> > Still, if you don't like skipping explicit filters, I'm OK with implicit only, it will
> > fix the bug we are saying about.
> > 
> > But why you don't like creating some additional explicit filters on target (prior to
> > migration process) which we didn't have on source?
> 
> Because I feel like (without having too much insight into migration, I
> admit) that migration is generally a process where you move from one VM
> to another, but both should have the same configuration.  If you want to

During migrations you might want to change backends of the devices
though. (E.g. reconfigure disk paths) or network connections so that the
VM works on the different host.

In addition some bits of migration are not symmetrical. In libvirt we
use a blockdev/drive-mirror to copy over disks if you request migration
with non-shared storage. The destination runs an NBD server and the
source runs the blockjob to copy it over. There can't be symmetry in
this case.

> change the configuration, you do that before or after the migration.
> (I’d think.)