<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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=windows-1252"
        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=windows-1252"
          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=windows-1252">
          <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>
    <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>
  </body>
</html>