<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 10/27/2015 03:27 PM, Frank Novak
wrote:<br>
</div>
<blockquote
cite="mid:201510271727.t9RHRQJs013680@d01av04.pok.ibm.com"
type="cite">
<p><br>
<br>
<br>
<tt><a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel-bounces@ovirt.org">kimchi-devel-bounces@ovirt.org</a> wrote on 10/27/2015 12:00:03
PM:<br>
<br>
> On 10/27/2015 11:13 AM, Frank Novak wrote:<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel-bounces@ovirt.org">kimchi-devel-bounces@ovirt.org</a> wrote on 10/27/2015
08:31:49 AM:<br>
> ><br>
> > > Date: Mon, 26 Oct 2015 16:08:11 -0200<br>
> > > From: <a class="moz-txt-link-rfc2396E" href="mailto:dhbarboza82@gmail.com"><dhbarboza82@gmail.com></a><br>
> > > To: Kimchi Devel <a class="moz-txt-link-rfc2396E" href="mailto:kimchi-devel@ovirt.org"><kimchi-devel@ovirt.org></a><br>
> > > Subject: [Kimchi-devel] [PATCH 0/3] Live
migration backend<br>
> > > Message-ID:
<a class="moz-txt-link-rfc2396E" href="mailto:1445882894-10208-1-git-send-email-dhbarboza82@gmail.com"><1445882894-10208-1-git-send-email-dhbarboza82@gmail.com></a><br>
> > ><br>
> > > From: Daniel Henrique Barboza
<a class="moz-txt-link-rfc2396E" href="mailto:dhbarboza82@gmail.com"><dhbarboza82@gmail.com></a><br>
> > ><br>
> > > This patch series implements the first release
of the Live (and cold!)<br>
> > > migration in Kimchi.<br>
> > ><br>
> > > *** Requirements for a VM migration ***<br>
> > ><br>
> > > - shared storage. The disk/storage path must be
the same at the origin<br>
> > > and destination.<br>
> > Is this a temporary restriction in kimchi?<br>
> > We otherwise do support live migration w/ storage...<br>
> ><br>
> <br>
> I guess I've expressed myself poorly there. What I meant
was that the VM <br>
> must be in the same<br>
> storage pool at both hosts (shared storage). For example,
a NFS/iSCSI <br>
> storage pool that contains<br>
> both the source and destination. The idea is that the
migration process <br>
> will only copy the VM<br>
> RAM - the disks would be accessible by the VM at the
destination from <br>
> the same path.<br>
> <br>
> I am aware that there is an option to copy the storage
(non-shared <br>
> storage migration) but I've found<br>
> out that it isn't that supported by Red Hat for example:<br>
> <br>
> <a moz-do-not-send="true"
href="https://access.redhat.com/solutions/60034">https://access.redhat.com/solutions/60034</a><br>
> <br>
> "Live migration with non-shared storage in RHEL6/RHEV3.*
is a deprecated <br>
> functionality, but under certain circunstances and with
some <br>
> limitations, it works fine. In RHEL7, this feature has
been disabled."<br>
> <br>
> <br>
> However, if some distro that Kimchi supports still have
support for non <br>
> shared migration, we can<br>
> add this option as well.<br>
> </tt><br>
<tt>well, PowerKVM at least does.. </tt><br>
<tt>I haven't checked whether Ubuntu or SLES KVM do..</tt><br>
</p>
</blockquote>
Fair enough. I'll add this support in the next version of this
backend<br>
<br>
<blockquote
cite="mid:201510271727.t9RHRQJs013680@d01av04.pok.ibm.com"
type="cite">
<p><tt><br>
> > ><br>
> > > - password-less login<br>
> > ><br>
> > > - enough resorces in the destination host to
allocate the VM<br>
> > ><br>
> > ><br>
> > > Limitations of this first version and possible
candidates for future <br>
> > work:<br>
> > ><br>
> > > - do not automate the process of password-less
login (but it is able to<br>
> > > verify this condition)<br>
> > ><br>
> > > - due to the above limitation, the 'user'
parameter value is only 'root'<br>
> > > at this moment<br>
> > ><br>
> > > - do not verify the 'shared storage' condition<br>
> > ><br>
> > > - do not verify same hypervisor/arch conditions<br>
> > ><br>
> > > - the origin VM will shutdown after migration
(not sure if can be <br>
> > helped)<br>
> > ><br>
> > Ahh, shutdown where, if it was running on source, it
should be running <br>
> > on destination..<br>
> > clearly it will not be on source anymore..<br>
> ><br>
> Yeah, that was my reasoning when seeing the VM shutting
down <br>
> automatically in the<br>
> source after the migration was successful.<br>
> <br>
> <br>
> <br>
> <br>
> Daniel<br>
> <br>
> <br>
</tt><br>
<br>
Cheers,<br>
Frank <br>
<br>
</p>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>