[Libvir] Is it possible to add an interface to intercept the migration process?
Hi All, I'm thinking about if it possible to add an interface to let user specified action to happen on destination during the migration, this should be useful for migrating things that have different paths on source and destination. Allowing specified action(callback) to happen at a time point, e.g., after the config file is transfered and before starting the vm, can bring in a lot of flexibilities considering the migration of devices which are shared but have different paths/views. Giving the dest a chance to recognize these devices and update the config, and then start the vm probably is helpful there. Comment? Thanks, Jack
Meng Ran wrote:
Hi All,
I'm thinking about if it possible to add an interface to let user specified action to happen on destination during the migration, this should be useful for migrating things that have different paths on source and destination.
Allowing specified action(callback) to happen at a time point, e.g., after the config file is transfered and before starting the vm, can bring in a lot of flexibilities considering the migration of devices which are shared but have different paths/views. Giving the dest a chance to recognize these devices and update the config, and then start the vm probably is helpful there.
Comment?
First of all this would have to be supported by a hypervisor (eg. Xen) before we could add it to libvirt. In general I'm not sure how this could work for migration at all. Live migration copies the memory image while the guest is still running, so there is no point where the user action could run. Even offline migration only transfers the memory, not the disk, so if you need to reconfigure something on disk, you can just do it before starting the migration. Perhaps you're thinking of shutting down the guest and copying its disk image to another machine and starting the guest up there? In that case there should be ample opportunity to make changes to the disk by just mounting it on the host. I think Platespin support this for their "V2V" migration. If I've missed something about what you're trying to do, let me know. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Hi Richard, Thanks for your reply. Actually I'm thinking about how to recognize the same storage (probably external), not things on them. Sometimes storages are shared between hosts but have different paths to access, e.g., for fibre channel storages. So an update to the conf file is probably needed here to let the dest attach 'right' storages. Mirroring/iSCSI is not the case I'm considering. Best regards, Jack Richard W.M. Jones wrote:
Meng Ran wrote:
Hi All,
I'm thinking about if it possible to add an interface to let user specified action to happen on destination during the migration, this should be useful for migrating things that have different paths on source and destination.
Allowing specified action(callback) to happen at a time point, e.g., after the config file is transfered and before starting the vm, can bring in a lot of flexibilities considering the migration of devices which are shared but have different paths/views. Giving the dest a chance to recognize these devices and update the config, and then start the vm probably is helpful there.
Comment?
First of all this would have to be supported by a hypervisor (eg. Xen) before we could add it to libvirt.
In general I'm not sure how this could work for migration at all. Live migration copies the memory image while the guest is still running, so there is no point where the user action could run. Even offline migration only transfers the memory, not the disk, so if you need to reconfigure something on disk, you can just do it before starting the migration.
Perhaps you're thinking of shutting down the guest and copying its disk image to another machine and starting the guest up there? In that case there should be ample opportunity to make changes to the disk by just mounting it on the host. I think Platespin support this for their "V2V" migration.
If I've missed something about what you're trying to do, let me know.
Rich.
------------------------------------------------------------------------
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Jack Meng wrote:
Hi Richard,
Thanks for your reply. Actually I'm thinking about how to recognize the same storage (probably external), not things on them. Sometimes storages are shared between hosts but have different paths to access, e.g., for fibre channel storages. So an update to the conf file is probably needed here to let the dest attach 'right' storages.
Mirroring/iSCSI is not the case I'm considering.
I'm still a bit unclear about what you're trying to do. Is the external storage mounted on the guest at the point when you're doing the migration? If it is connected then you'd need to umount it before migration and mount it (with a new device name) afterwards. Possibly an update to /etc/fstab would be in order too. This seems to preclude live migration and requires cooperation from the guest during migration, so no special support by the HV is required. You can just signal to the guest that it is about to be migrated and needs to do the umount/rename and wait until after it has been migrated to signal it again to remount. If the external storage is actually your root filesystem then you are probably s.o.l at this point. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Jack Meng wrote:
Hi Richard,
Thanks for your reply. Actually I'm thinking about how to recognize the same storage (probably external), not things on them. Sometimes storages are shared between hosts but have different paths to access, e.g., for fibre channel storages. So an update to the conf file is probably needed here to let the dest attach 'right' storages.
Mirroring/iSCSI is not the case I'm considering.
I'm still a bit unclear about what you're trying to do. Is the external storage mounted on the guest at the point when you're doing the migration? If it is connected then you'd need to umount it before migration and mount it (with a new device name) afterwards. Possibly an update to /etc/fstab would be in order too. This seems to preclude live migration and requires cooperation from the guest during migration, so no special support by the HV is required. You can just signal to the guest that it is about to be migrated and needs to do the umount/rename and wait until after it has been migrated to signal it again to remount. Will this hurt applications/services running on the guest? However, that is not my point. I'm thinking about if hypervisors see
Richard W.M. Jones wrote: these external storages with different paths and they are attched to guest as block devices. Best regards, Jack
If the external storage is actually your root filesystem then you are probably s.o.l at this point.
Rich.
------------------------------------------------------------------------
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 18, 2007 at 05:29:53PM +0800, Jack Meng wrote:
Thanks for your reply. Actually I'm thinking about how to recognize the same storage (probably external), not things on them. Sometimes storages are shared between hosts but have different paths to access, e.g., for fibre channel storages. So an update to the conf file is probably needed here to let the dest attach 'right' storages.
Frankly this is a a solved problem already. If you need persistent device names, don't use /dev/sdN. With SAN you can use device mapper multipath to make your devices appear as /dev/mpath/<WWN> where WWN is the world world name for the LUN. Or you can setup udev rules to give a similar persistent name. 'man scsi_id' Re-writing config files in Xen or libvir is just the wrong place todo this. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Hi Dan, Thanks for the info, /Jack
-----邮件原件----- 发件人: libvir-list-bounces@redhat.com [mailto:libvir-list-bounces@redhat.com] 代表 Daniel P. Berrange 发送时间: 2007年10月18日 23:28 收件人: Jack Meng 抄送: libvir-list@redhat.com; mengran@tsinghua.org.cn 主题: Re: [Libvir] Is it possible to add an interface to intercept themigration process?
On Thu, Oct 18, 2007 at 05:29:53PM +0800, Jack Meng wrote:
Thanks for your reply. Actually I'm thinking about how to recognize the same storage (probably external), not things on them. Sometimes storages are shared between hosts but have different paths to access, e.g., for fibre channel storages. So an update to the conf file is probably needed here to let the dest attach 'right' storages.
Frankly this is a a solved problem already. If you need persistent device names, don't use /dev/sdN.
With SAN you can use device mapper multipath to make your devices appear as /dev/mpath/<WWN> where WWN is the world world name for the LUN. Or you can setup udev rules to give a similar persistent name. 'man scsi_id'
Re-writing config files in Xen or libvir is just the wrong place todo this.
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (5)
-
Daniel P. Berrange -
Jack Meng -
Jack.Meng
-
Meng Ran -
Richard W.M. Jones