[Kimchi-devel] Kimchi-devel Digest, Vol 23, Issue 121

Tue Oct 27 18:26:18 UTC 2015

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 at ovirt.org wrote on 10/27/2015 12:00:03 PM:
>>>
>>> > On 10/27/2015 11:13 AM, Frank Novak wrote:
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > kimchi-devel-bounces at ovirt.org wrote on 10/27/2015 08:31:49 AM:
>>> > >
>>> > > > Date: Mon, 26 Oct 2015 16:08:11 -0200
>>> > > > From: <dhbarboza82 at gmail.com>
>>> > > > To: Kimchi Devel <kimchi-devel at ovirt.org>
>>> > > > Subject: [Kimchi-devel] [PATCH 0/3] Live migration backend
>>> > > > Message-ID: 
>>> <1445882894-10208-1-git-send-email-dhbarboza82 at gmail.com>
>>> > > >
>>> > > > From: Daniel Henrique Barboza <dhbarboza82 at 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.

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 at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151027/67436c8f/attachment.html>