Thanks for replying, Vish. Yes, I meant block migration and not live migration, sorry for the confusion. Offline migration seems quite a nice feature for us, we will see if we can get this implemented perhaps.
Thanks, Alex. On Fri, Sep 9, 2011 at 12:12 AM, Vishvananda Ishaya <[email protected]>wrote: > > 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] > 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
