On 10/27/2015 11:13 AM, Frank Novak wrote:
kimchi-devel-bounces(a)ovirt.org wrote on 10/27/2015 08:31:49 AM:
> Date: Mon, 26 Oct 2015 16:08:11 -0200
> From: <dhbarboza82(a)gmail.com>
> To: Kimchi Devel <kimchi-devel(a)ovirt.org>
> Subject: [Kimchi-devel] [PATCH 0/3] Live migration backend
> Message-ID: <1445882894-10208-1-git-send-email-dhbarboza82(a)gmail.com>
>
> From: Daniel Henrique Barboza <dhbarboza82(a)gmail.com>
>
> This patch series implements the first release of the Live (and cold!)
> migration in Kimchi.
>
> *** Requirements for a VM migration ***
>
> - shared storage. The disk/storage path must be the same at the origin
> and destination.
Is this a temporary restriction in kimchi?
We otherwise do support live migration w/ storage...
I guess I've expressed myself poorly there. What I meant was that the VM
must be in the same
storage pool at both hosts (shared storage). For example, a NFS/iSCSI
storage pool that contains
both the source and destination. The idea is that the migration process
will only copy the VM
RAM - the disks would be accessible by the VM at the destination from
the same path.
I am aware that there is an option to copy the storage (non-shared
storage migration) but I've found
out that it isn't that supported by Red Hat for example:
https://access.redhat.com/solutions/60034
"Live migration with non-shared storage in RHEL6/RHEV3.* is a deprecated
functionality, but under certain circunstances and with some
limitations, it works fine. In RHEL7, this feature has been disabled."
However, if some distro that Kimchi supports still have support for non
shared migration, we can
add this option as well.
>
> - password-less login
>
> - enough resorces in the destination host to allocate the VM
>
>
> Limitations of this first version and possible candidates for future
work:
>
> - do not automate the process of password-less login (but it is able to
> verify this condition)
>
> - due to the above limitation, the 'user' parameter value is only
'root'
> at this moment
>
> - do not verify the 'shared storage' condition
>
> - do not verify same hypervisor/arch conditions
>
> - the origin VM will shutdown after migration (not sure if can be
helped)
>
Ahh, shutdown where, if it was running on source, it should be running
on destination..
clearly it will not be on source anymore..
Yeah, that was my reasoning when seeing the VM shutting down
automatically in the
source after the migration was successful.
Daniel
>
>
Cheers,
Frank
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel