[libvirt] RFC: Migration with NPIV

[Paolo Bonzini]

Il 20/11/2012 11:17, Daniel P. Berrange ha scritto:
> If we do the mapping of HBAs to guest domains using storage
> pools, then at a guest level, migration requires zero work.

I guess that means adding <disk type='volume'>?

> It is simply upto the management app to create the storage
> pool on the destination host with the same Name + UUID, but
> with the secondary WWNN/WWPN. The nice thing about this, is
> that you don't need to hardcode details of a secondary
> WWNN/WWPN up-front. The management app can just decide on
> those at the time it performs the migration, so 99% of the
> time there will only need to be a single vHBA setup on the
> SAN. During migration the mgmt app can setup a second
> vHBA for the target host, and once complete, delete the
> original vHBA entirely. 

Right, I think this is the right approach because it lets us preceed
step-by-step.

As a further step, creation and deletion of the HBAs can be moved to
libvirt as in Osier's proposal.  I don't like making the
primary/secondary explicit in the XML, but perhaps you could add a pool
of WWNN/WWPNs (really just two of them) to the pool, and pass the active
pair to the destination in the migration cookie.  The destination can
then pick one that doesn't match.

To really make things "require zero work" also for the sysadmin, you
could have a "delayed open" option for QEMU disks.  It would let us
recycle the same WWNN/WWPN on both the source and destination, but you
would have to shut down the vHBA on the source and bring it up on the
destination while the guest is down.  I'm afraid that this would cause
too much downtime for the guest, since you have to wait for the
destination to finish scanning devices.

Paolo