Re: [libvirt] RFC: Migration with NPIV
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