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
