<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      <div class="moz-signature"> <a class="moz-txt-link-abbreviated" href="mailto:lagarcia@br.ibm.comn">lagarcia@br.ibm.comn</a> 10/23/2014 08:43
        AM, simonjin wrote:<br>
      </div>
    </div>
    <blockquote cite="mid:5448DBB8.2010006@linux.vnet.ibm.com"
      type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <br>
      <div class="moz-cite-prefix">在 2014年10月22日 20:28, Aline Manera 写道:<br>
      </div>
      <blockquote cite="mid:5447A2FE.2070603@linux.vnet.ibm.com"
        type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        <br>
        <div class="moz-cite-prefix">On 10/22/2014 10:20 AM, Aline
          Manera wrote:<br>
        </div>
        <blockquote cite="mid:5447A11B.5030201@linux.vnet.ibm.com"
          type="cite">
          <meta content="text/html; charset=UTF-8"
            http-equiv="Content-Type">
          <br>
          <div class="moz-cite-prefix">On 10/22/2014 07:24 AM, simonjin
            wrote:<br>
          </div>
          <blockquote cite="mid:544777B2.8050505@linux.vnet.ibm.com"
            type="cite">
            <meta content="text/html; charset=UTF-8"
              http-equiv="Content-Type">
            <title></title>
            On 10/22/2014 01:48 AM, Aline Manera wrote:
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">
              <meta content="text/html; charset=UTF-8"
                http-equiv="Content-Type">
              <br>
              <div class="moz-cite-prefix">On 10/20/2014 12:50 AM,
                simonjin wrote:<br>
              </div>
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <meta http-equiv="content-type" content="text/html;
                  charset=UTF-8">
                <div class="moz-text-html" lang="x-unicode"> Hi all,<br>
                  <br>
                  I'm presenting here my proposal for the feature "Guest
                  migration" which<br>
                  is expected to be implemented for Kimchi 1.4.
                  <h2> Description </h2>
                  Migrate guest vm within peer/host discovered by Kimchi
                  peers using openSLP.<br>
                  In the first stage 1, only do migration will be
                  supported, <br>
                  in stage2, migrateCancel and migrateMonitor will be
                  supported.<br>
                  <br>
                  <b>Migration Mode: </b><br>
                  1. Support libvirt tunnelled transport  managed by
                  direct migration.<br>
                  2. Only support Live migration mode.<br>
                  3. Only support migration over TCP <br>
                  <br>
                  <b>Migration Capability Check</b><br>
                  -  Source libvirtd/client should be able to connect
                  destination libvirtd.<br>
                  -  CPU architectures compare(X86 vs PPC). <br>
                  -  No PCI device passthrough.<br>
                  -  In a shared storage pool and the pool can be
                  access/write by destination.<br>
                  <br>
                  <h2> REST API </h2>
                  Only one new REST command will be added in stage 1.
                  <h4> Syntax </h4>
                  <tt>POST /vms/</tt><tt><i>&lt;vm-name&gt;</i></tt><tt>/migrate</tt></div>
              </blockquote>
              <br>
              You will have a data object informing the destination host<br>
              <br>
              POST /vms/&lt;vm-name&gt;/migrate {host: ...}<br>
              <br>
            </blockquote>
            ok, the json data will be {host:ip, user:username,
            passwd:password}<br>
            <br>
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <div class="moz-text-html" lang="x-unicode">
                  <h4> Parameters: </h4>
                </div>
              </blockquote>
              <br>
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <div class="moz-text-html" lang="x-unicode"><small>in
                    config.py.in: <br>
                    <br>
                            ('migration_destination_timeout', '21600',<br>
                                'Maximum time the destination waits for
                    the migration to finish. <br>
                               21600 should be enough since all the
                    peers will be in the same LAN'),<br>
                    <br>
                            ('migration_max_bandwidth', 'unlimited',<br>
                                  'default in libvirt is unlimited'),<br>
                    <br>
                            ('migration_downtime', '500',<br>
                                'Maxmium allowed downtime for live
                    migration in milliseconds '<br>
                                '(anything below 100ms is ignored) if
                    you do not care about '<br>
                                'liveness of migration, set to a very
                    high value, such as '<br>
                                '600000.'),<br>
                  </small></div>
              </blockquote>
              <br>
              I don't think we need to allow user edits those values so
              there is no need to add them to config.py.in<br>
              <br>
            </blockquote>
            It's better to put them in kimchi.conf to allow user to edit
            just in case the migration failed due to them.<br>
            <br>
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <div class="moz-text-html" lang="x-unicode"><small> </small>
                  <h4> Return: </h4>
                  An asynchronous Task with "<tt>target_uri</tt>"
                  containing "<tt>/vms/&lt;</tt><tt><i>new-vm-name</i></tt><tt>&gt;</tt>".<br>
                  As expected with any Task, the cloning process can be
                  tracked by<br>
                  checking the corresponding task's status. <br>
                  <br>
                  <b>Do_migration step:</b><br>
                  -  migration source check .<br>
                </div>
              </blockquote>
              <br>
              What kind of verification will be done?<br>
              Storage pool and network? Guest permission settings?<br>
              <br>
            </blockquote>
            will do <b>Migration Capability Check </b>described above<b>.<br>
              <br>
            </b>
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <div class="moz-text-html" lang="x-unicode"> -  connect
                  migration destination, guest vm config/params transfer
                  and setup.<br>
                </div>
              </blockquote>
              <br>
              How will it be done?<br>
              From libvirt doc, I can see different types of migration,
              which one is the best solution for Kimchi?<br>
              <br>
              For reference: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://libvirt.org/migration.html">http://libvirt.org/migration.html</a><br>
              <br>
            </blockquote>
            It will be tunneled + P2P migration, <br>
            so the API will be like:  <br>
                  do_migrate = dom.migrateToURI2(dest, muri, None,<br>
                            libvirt.VIR_MIGRATE_LIVE |<br>
                            libvirt.VIR_MIGRATE_PEER2PEER |<br>
                            libvirt.VIR_MIGRATE_TUNNELLED |<br>
                            libvirt.VIR_MIGRATE_ABORT_ON_ERROR,<br>
                            None, maxbandwidth)<br>
            <br>
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <div class="moz-text-html" lang="x-unicode"> - 
                  migration source prepare.<br>
                  -  do actually migration.<br>
                </div>
              </blockquote>
              <br>
              Does libvirt python API have native support for that?<br>
              <br>
            </blockquote>
            Will wrapper the native libvirt python API and put it in a
            task.<br>
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <div class="moz-text-html" lang="x-unicode"> -  recover
                  if failed.<br>
                </div>
              </blockquote>
              <br>
              Probably, on fail, some leftovers will be on destination
              server. How will you do the clean up?<br>
            </blockquote>
            Will destroy remote vm instance on destination and resume
            source vm is being paused. <br>
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite"> Will it be a communication between the Kimchi
              servers? </blockquote>
            the migration communication will be between to libvirtd.
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">What about if the destination server does not
              have a Kimchi setup?<br>
              <br>
            </blockquote>
            the destination server is discovered by kimchi, which will <span
              class="Apple-style-span" style="border-collapse: separate;
              color: rgb(0, 0, 0); font-family: 'Times New Roman';
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: 2; text-indent: 0px; text-transform: none;
              white-space: normal; widows: 2; word-spacing: 0px;
              font-size: medium;"><span class="Apple-style-span"
                style="border-collapse: collapse; color: rgb(51, 51,
                51); font-family: arial; font-size: 19px; line-height:
                20px;">guaranty it has a kimchi setup.<br>
              </span></span></blockquote>
          <br>
          So can not I migrate my guest to a new server without Kimchi?<br>
        </blockquote>
        <br>
        What about I am migrating from Kimchi to ovirt/openstack?<br>
        <br>
      </blockquote>
      Migration should be only between kimchi peers, <br>
      there is no way to migrate to ovirt/openstack host via kimchi API.<br>
    </blockquote>
    I agree there is no way to migrate to oVirt/OpenStack. However, from
    our perspective, this should not matter.<br>
    <br>
    As you said on your proposal "Source libvirtd/client should be able
    to connect destination libvirtd.". So, the only thing that should
    matter is whether we have a libvirt running on the other side or
    not. This is what we need to check (and I think libvirt API checks
    this for us and return an error if it doesn't find a libvirt running
    on the destination). From a migration perspective, it doesn't matter
    if the destination is running Kimchi, oVirt, OpenStack or any other
    management tool. We should only check if libvirt is running and, if
    it is running and the migration is successful, we are good.<br>
    <br>
    On the Kimchi UI, we will, of course, have an easy way to select a
    Kimchi peer and migrate to it if Federation is on and other peers
    have discovered but we need to give the option to the user, IMO, to
    select an arbitrary IP where they know libvirt is running to migrate
    the VM to that host.<br>
    <br>
    Best regards,<br>
    <br>
    Leonardo Garcia<br>
    <blockquote cite="mid:5448DBB8.2010006@linux.vnet.ibm.com"
      type="cite"> <br>
      <blockquote cite="mid:5447A2FE.2070603@linux.vnet.ibm.com"
        type="cite">
        <blockquote cite="mid:5447A11B.5030201@linux.vnet.ibm.com"
          type="cite"> <br>
          <blockquote cite="mid:544777B2.8050505@linux.vnet.ibm.com"
            type="cite"><span class="Apple-style-span"
              style="border-collapse: separate; color: rgb(0, 0, 0);
              font-family: 'Times New Roman'; font-style: normal;
              font-variant: normal; font-weight: normal; letter-spacing:
              normal; line-height: normal; orphans: 2; text-indent: 0px;
              text-transform: none; white-space: normal; widows: 2;
              word-spacing: 0px; font-size: medium;"><span
                class="Apple-style-span" style="border-collapse:
                collapse; color: rgb(51, 51, 51); font-family: arial;
                font-size: 19px; line-height: 20px;"> <br>
                -Simon<br>
              </span></span>
            <blockquote cite="mid:54469C8B.5040604@linux.vnet.ibm.com"
              type="cite">
              <blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
                type="cite">
                <div class="moz-text-html" lang="x-unicode"> -  do
                  finish if migration successful.<br>
                  <br>
                  <br>
                  Comments are welcome!<br>
                </div>
                <pre class="moz-signature" cols="72">-- 
Yun Tong Jin, Simon
Linux Technology Center, Open Virtualization project
IBM Systems &amp; Technology Group
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:jinyt@cn.ibm.com">jinyt@cn.ibm.com</a>, Phone: 824549654 </pre>
              </blockquote>
              <br>
            </blockquote>
            <br>
            <br>
            <pre class="moz-signature" cols="72">-- 
Yun Tong Jin, Simon
Linux Technology Center, Open Virtualization project
IBM Systems &amp; Technology Group
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:jinyt@cn.ibm.com">jinyt@cn.ibm.com</a>, Phone: 824549654 </pre>
          </blockquote>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" 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>
      </blockquote>
      <br>
      <br>
      <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>