Re: [Kimchi-devel] Kimchi-devel Digest, Vol 23, Issue 121
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 12:00:03 PM:
On 10/27/2015 11:13 AM, Frank Novak wrote:
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 08:31:49 AM:
Date: Mon, 26 Oct 2015 16:08:11 -0200 From: <dhbarboza82@gmail.com> To: Kimchi Devel <kimchi-devel@ovirt.org> Subject: [Kimchi-devel] [PATCH 0/3] Live migration backend Message-ID: <1445882894-10208-1-git-send-email-dhbarboza82@gmail.com>
From: Daniel Henrique Barboza <dhbarboza82@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. > well, PowerKVM at least does.. I haven't checked whether Ubuntu or SLES KVM do..
- 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
On 10/27/2015 03:27 PM, Frank Novak wrote:
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 12:00:03 PM:
On 10/27/2015 11:13 AM, Frank Novak wrote:
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 08:31:49 AM:
Date: Mon, 26 Oct 2015 16:08:11 -0200 From: <dhbarboza82@gmail.com> To: Kimchi Devel <kimchi-devel@ovirt.org> Subject: [Kimchi-devel] [PATCH 0/3] Live migration backend Message-ID:
<1445882894-10208-1-git-send-email-dhbarboza82@gmail.com>
From: Daniel Henrique Barboza <dhbarboza82@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. > well, PowerKVM at least does.. I haven't checked whether Ubuntu or SLES KVM do..
Fair enough. I'll add this support in the next version of this backend
- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 27/10/2015 15:50, Daniel Henrique Barboza wrote:
On 10/27/2015 03:27 PM, Frank Novak wrote:
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 12:00:03 PM:
On 10/27/2015 11:13 AM, Frank Novak wrote:
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 08:31:49 AM:
Date: Mon, 26 Oct 2015 16:08:11 -0200 From: <dhbarboza82@gmail.com> To: Kimchi Devel <kimchi-devel@ovirt.org> Subject: [Kimchi-devel] [PATCH 0/3] Live migration backend Message-ID:
<1445882894-10208-1-git-send-email-dhbarboza82@gmail.com>
From: Daniel Henrique Barboza <dhbarboza82@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. > well, PowerKVM at least does.. I haven't checked whether Ubuntu or SLES KVM do..
Fair enough. I'll add this support in the next version of this backend
Daniel, we can follow the same logic we did for ISO streaming which does not have support on RHEL7 and disable the feature only when the distro does not have support for it. About the code, you can add a feature test to cover it.
- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 10/27/2015 04:20 PM, Aline Manera wrote:
On 27/10/2015 15:50, Daniel Henrique Barboza wrote:
On 10/27/2015 03:27 PM, Frank Novak wrote:
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 12:00:03 PM:
On 10/27/2015 11:13 AM, Frank Novak wrote:
kimchi-devel-bounces@ovirt.org wrote on 10/27/2015 08:31:49 AM:
Date: Mon, 26 Oct 2015 16:08:11 -0200 From: <dhbarboza82@gmail.com> To: Kimchi Devel <kimchi-devel@ovirt.org> Subject: [Kimchi-devel] [PATCH 0/3] Live migration backend Message-ID:
From: Daniel Henrique Barboza <dhbarboza82@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
<1445882894-10208-1-git-send-email-dhbarboza82@gmail.com> 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.
well, PowerKVM at least does.. I haven't checked whether Ubuntu or SLES KVM do..
Fair enough. I'll add this support in the next version of this backend
Daniel, we can follow the same logic we did for ISO streaming which does not have support on RHEL7 and disable the feature only when the distro does not have support for it. About the code, you can add a feature test to cover it.
Noted. Will definitely look into that for a second version of the backend
- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Aline Manera -
Daniel Henrique Barboza -
Frank Novak