1. 20 4月, 2016 23 次提交
  2. 15 4月, 2016 3 次提交
  3. 06 4月, 2016 1 次提交
  4. 05 4月, 2016 8 次提交
  5. 04 4月, 2016 5 次提交
    • M
      nodedev: Fix parsing of generated XMLs · 17a94ba7
      Martin Kletzander 提交于
      Commit d77ffb68 added not only reporting of the PCI header type, but
      also parsing of that information.  However, because there was no parsing
      done for the other sub-PCI capabilities, if there was any other
      capability then a valid header type name (like phys_function or
      virt_functions) the parsing would fail.  This prevented passing node
      device XMLs that we generated into our own functions when dealing with,
      e.g. with SRIOV cards.
      
      Instead of reworking the whole parsing, just fix this one occurence and
      remove a test for it for the time being.  Future patches will deal with
      the rest.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      17a94ba7
    • L
      qemu: fix alias name for <interface type='hostdev'> · 8f74f527
      Laine Stump 提交于
      Starting with commit f8e712fe, if you start a domain that has an
      <interface type='hostdev' (or that has <interface type='network'>
      where the network is a pool of devices for hostdev assignment), when
      you later try to add *another* interface (of any kind) with hotplug,
      the function qemuAssignDeviceNetAlias() fails as soon as it sees a
      "hostdevN" alias in the list of interfaces), causing the attach to
      fail.
      
      This is because (starting with f8e712fe) the device alias names are
      assigned during the new function qemuProcessPrepareDomain(), which is
      called *before* networkAllocateActualDevice() (which is called from
      qemuProcessPrepareHost(), which is called from
      qemuProcessLaunch()). Prior to that commit,
      networkAllocateActualDevice() was called first.
      
      The problem with this is that the alias for interfaces that are really
      a hostdev (<interface type='hostdev'>) is of the form "hostdevN" (just
      like other hostdevs), while other interfaces are "netN". But if you
      don't know that the interface is going to be a hostdev at the time you
      assign the alias name, you can't name it differently. (As far as I've
      seen so far, the change in name by itself wouldn't have been a problem
      (other than just an outwardly noticeable change in behavior) except
      for the abovementioned failure to attach/detach new interfaces.
      
      Rather than take the chance that there may be other not-yet-revealed
      problems associated with changing the alias name, this patch changes
      the way that aliases are assigned to restore the old behavior.
      
      Old: In the past, assigning an alias to an interface was skipped if it
      was seen that the interface was type='hostdev' - we knew that the
      hostdev part of the interface was also in the list of hostdevs (that's
      part of what happens in networkAllocateActualDevice()) and it would be
      assigned when all the other hostdev aliases were assigned.
      
      New: When assigning an alias to an interface, we haven't yet called
      networkAllocateActualDevice() to construct the hostdev part of the
      interface, so we can't just wait for the loop that creates aliases for
      all the hostdevs (there's nothing on that list for this device
      yet!). Instead we handle it immediately in the loop creating interface
      aliases, by calling the new function networkGetActualType() to
      determine if it is going to be hostdev, and if so calling
      qemuAssignDeviceHostdevAlias() instead.
      
      Some adjustments have to be made to both
      qemuAssignDeviceHostdevAlias() and to qemuAssignDeviceNetAlias() to
      accommodate this. In both of them, an error return from
      qemuDomainDeviceAliasIndex() is no longer considered an error; instead
      it's just ignored (because it almost certainly means that the alias
      string for the device was "net" when we expected "hostdev" or vice
      versa). in qemuAssignDeviceHostdevAlias() we have to look at all
      interface aliases for hostdevN in addition to looking at all hostdev
      aliases (this wasn't necessary in the past, because both the interface
      entry and the hostdev entry for the device already pointed at the
      device info; no longer the case since the hostdev entry hasn't yet
      been setup).
      
      Fortunately the buggy behavior hasn't yet been in any official release
      of libvirt.
      8f74f527
    • L
      qemu: change args to qemuAssignDeviceHostdevAlias() · f09c7139
      Laine Stump 提交于
      In certain cases, we need to assign a hostdevN-style alias in a case
      when we don't have a virDomainHostdevDefPtr (instead we have a
      virDomainNetDefPtr). Since qemuAssignDeviceHostdevAlias() doesn't use
      anything in the virDomainHostdevDef except the alias string itself
      anyway, this patch just changes the arguments to pass a pointer to the
      alias pointer instead.
      f09c7139
    • L
      network: new function networkGetActualType · 3992ff14
      Laine Stump 提交于
      There are times when it's necessary to learn the actual type of a
      network connection before any resources have been allocated
      (e.g. during qemuProcessPrepareDomain()), but in the past it was
      necessary to call networkAllocateActualDevice() in order to have the
      actual type filled in.
      
      This new function returns the type of network that *will be* setup
      once it actually happens, but without making any changes on the host.
      3992ff14
    • M
      qemu: Clear generated private paths · d558fb34
      Martin Kletzander 提交于
      The paths have the domain ID in them.  Without cleaning them, they would
      contain the same ID even after multiple restarts.  That could cause
      various problems, e.g. with access.
      
      Add function qemuDomainClearPrivatePaths() for this as a counterpart of
      qemuDomainSetPrivatePaths().
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      d558fb34