Open Stack

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
<vishvananda at gmail.com>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     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110910/63ea709f/attachment.html>