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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list