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.
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)
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?
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?
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
