Hello, Sorry for late reply.
Hmm.. regarding to Q1 and Q2, if you go "nova-manage vm live_migration i-xxxxxxx dest", you have to prepare shared storage, no need to move backing file. VIR_MIGRATE_NON_SHARED_INC is not used then. On the other hand, n case of " nova-manage vm block_migration i-xxxxx dest", you dont have to prepare shared storage. backing file is automatically copied to destination, AFAIK. The reason why default flag value is not VIR_MIGRATE_NON_SHARED_DISK is VIR_MIGRATE_NON_SHARED_INC is stable and faster in our test environment. Your situation is backing file was not copied, wasnt it? I appreciate if you tell me your environment in detail. Regards, Kei ________________________________ 差出人: [email protected] [[email protected]] は Vishvananda Ishaya [[email protected]] の代理 送信日時: 2011年9月9日 6:12 宛先: Alex Lyakas CC: [email protected]<mailto:[email protected]> 件名: Re: [Openstack] Questions on nova code: networking & live/offline migration On Sep 6, 2011, at 9:57 AM, Alex Lyakas wrote: Greetings everybody, I have been reading the nova code (pretty close to the latest version) and I have a couple of questions regarding it. Live migration: I see that VIR_MIGRATE_NON_SHARED_INC flag is used, meaning that at destination, the same backing file should be available. (Indeed, the images that are created for instances use backing files in '_base' folder). Question 1: how it is ensured that the backing file on the destination really exists? I.e., '_cache_image' has to be called there for the same image. It looks like this is not ensured at all. If the same image was never spawned earlier on destination, the backing file will not exist there. I verified this and indeed there was no backing file on the destination. live migration should have _base in shared storage so it doesn't need to move. If you are talking about block_migration, then this could definitely be a bug. Question 2: even when the backing file does exist, the image created at the destination looks incorrect, it is not using the backing file! When querying the file on the destination, after live migration, I don't see that it's backed by the cached file: dst# qemu-img info /var/lib/nova/instances/instance-00000441/disk image: /var/lib/nova/instances/instance-00000441/disk file format: qcow2 virtual size: 3.0G (3221225472 bytes) disk size: 50M cluster_size: 65536 While on the source it is backed: src# qemu-img info disk image: disk file format: qcow2 virtual size: 3.0G (3221225472 bytes) disk size: 50M cluster_size: 65536 backing file: /var/lib/nova/instances/_base/af3e133428b9e25c55bc59fe534248e6a0c0f17b (actual path: /var/lib/nova/instances/_base/af3e133428b9e25c55bc59fe534248e6a0c0f17b) again, if you are referring to block_migration, this could be a bug. And indeed, on destination, when I log in into the VM, its image disk is corrupted. Various tools like 'less','vi',sudo' fail to run. When I changed the flag to VIR_MIGRATE_NON_SHARED_DISK, then the whole image was copied, and this time the instance on the destination was fine. So it looks there is some bug on that path when using VIR_MIGRATE_NON_SHARED_INC flag. add_fixed_ip_to_instance path: >From the code it looks like per each network, an instance has exactly one >virtual interface, meaning exactly one MAC address. However, it looks like >this is possible to have multiple fixed_IPs per same virtual_interface. This >is reflected in NetworkManager.get_instance_nw_info(), when adding the info['ips'] = [ip_dict(ip) for ip in network_IPs] entry. (On the other hand, in LibvirtBridgeDriver._get_configurations() only the first IP is taken from this list. ) Although I see that NetworkManager._setup_network() is called on that path, and even generates a new MAC address (in case of FlatDHCP), but a new virtual_interface is not created. What is the purpose of this ability? On the instance we still see a single network interface per each network, correct? tr3buchet. Comments here? Not sure there is a need to have multiple ips on the same nic. Offline migration ("resize"): I see that when using libvirt, this path is not implemented; it is implemented only for Xen. It looks like the following methods need to be implemented: migrate_disk_and_power_off() & finish_migration(). Is there any special reason for not implementing those methods with libvirt? Just that no one has done it. We would love to have this supported in libvirt. Thanks everybody, Alex. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
