<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2014年01月16日 08:28, Ian Wells wrote:<br>
    </div>
    <blockquote
cite="mid:CAPoubz7hbHoQAQ133HCRi=FnZizzo=Lkokk7ke755k2c57sPMg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">To clarify a couple of Robert's points, since we
        had a conversation earlier:<br>
        On 15 January 2014 23:47, Robert Li (baoli) <span dir="ltr"><<a
            moz-do-not-send="true" href="mailto:baoli@cisco.com"
            target="_blank">baoli@cisco.com</a>></span> wrote:<br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div
style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"> 
                ---  do we agree that BDF address (or device id,
                whatever you call it), and node id shouldn't be used as
                attributes in defining a PCI flavor?
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Note that the current spec doesn't actually exclude it
              as an option.  It's just an unwise thing to do.  In
              theory, you could elect to define your flavors using the
              BDF attribute but determining 'the card in this slot is
              equivalent to all the other cards in the same slot in
              other machines' is probably not the best idea...  We could
              lock it out as an option or we could just assume that
              administrators wouldn't be daft enough to try.<br>
              <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div
style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"> 
                      * the compute node needs to know the PCI flavor.
                [...]
                <div>                  - to support live migration, we
                  need to use it to create network xml</div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I didn't understand this at first and it took me a
              while to get what Robert meant here.<br>
              <br>
              This is based on Robert's current code for macvtap based
              live migration.  The issue is that if you wish to migrate
              a VM and it's tied to a physical interface, you can't
              guarantee that the same physical interface is going to be
              used on the target machine, but at the same time you can't
              change the libvirt.xml as it comes over with the migrating
              machine.  The answer is to define a network and refer out
              to it from libvirt.xml.  In Robert's current code he's
              using the group name of the PCI devices to create a
              network containing the list of equivalent devices (those
              in the group) that can be macvtapped.  Thus when the host
              migrates it will find another, equivalent, interface. 
              This falls over in the use case under </div>
          </div>
        </div>
      </div>
    </blockquote>
    but, with flavor we defined, the group could be a tag for this
    purpose, and all Robert's design still work, so it ok, right?<br>
    <blockquote
cite="mid:CAPoubz7hbHoQAQ133HCRi=FnZizzo=Lkokk7ke755k2c57sPMg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>consideration where a device can be mapped using more
              than one flavor, so we have to discard the use case or
              rethink the implementation.<br>
              <br>
              There's a more complex solution - I think - where we
              create a temporary network for each macvtap interface a
              machine's going to use, with a name based on the instance
              UUID and port number, and containing the device to map. 
              Before starting the migration we would create a
              replacement network containing only the new device on the
              target host; migration would find the network from the
              name in the libvirt.xml, and the content of that network
              would behave identically.  We'd be creating libvirt
              networks on the fly and a lot more of them, and we'd need
              decent cleanup code too ('when freeing a PCI device,
              delete any network it's a member of'), so it all becomes a
              lot more hairy.<br>
              -- <br>
            </div>
            <div>Ian.<br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>