1. 09 2月, 2017 2 次提交
  2. 08 2月, 2017 1 次提交
    • L
      util: add MTU arg to virNetDevTapCreateInBridgePort() · dd8ac030
      Laine Stump 提交于
      virNetDevTapCreateInBridgePort() has always set the new tap device to
      the current MTU of the bridge it's being attached to. There is one
      case where we will want to set the new tap device to a different
      (usually larger) MTU - if that's done with the very first device added
      to the bridge, the bridge's MTU will be set to the device's MTU. This
      patch allows for that possibility by adding "int mtu" to the arg list
      for virNetDevTapCreateInBridgePort(), but all callers are sending -1,
      so it doesn't yet have any effect.
      
      Since the requested MTU isn't necessarily what is used in the end (for
      example, if there is no MTU requested, the tap device will be set to
      the current MTU of the bridge), and the hypervisor may want to know
      the actual MTU used, we also return the actual MTU to the caller (if
      actualMTU is non-NULL).
      dd8ac030
  3. 07 2月, 2017 2 次提交
  4. 04 2月, 2017 1 次提交
    • J
      util: Fix domain object leaks on closecallbacks · 48ad6009
      John Ferlan 提交于
      Originally/discovered proposed by "Wang King <king.wang@huawei.com>"
      
      When the virCloseCallbacksSet is first called, it increments the refcnt
      on the domain object to ensure it doesn't get deleted before the callback
      is called. The refcnt would be decremented in virCloseCallbacksUnset once
      the entry is removed from the closeCallbacks has table.
      
      When (mostly) normal shutdown occurs, the qemuProcessStop will end up
      calling qemuProcessAutoDestroyRemove and will remove the callback from
      the list and hash table normally and decrement the refcnt.
      
      However, when qemuConnectClose calls virCloseCallbacksRun, it will scan
      the (locked) closeCallbacks list for matching domain and callback function.
      If an entry is found, it will be removed from the closeCallbacks list and
      placed into a lookaside list to be processed when the closeCallbacks lock
      is dropped. The callback function (e.g. qemuProcessAutoDestroy) is called
      and will run qemuProcessStop. That code will fail to find the callback
      in the list when qemuProcessAutoDestroyRemove is called and thus not decrement
      the domain refcnt. Instead since the entry isn't found the code will just
      return (mostly) harmlessly.
      
      This patch will resolve the issue by taking another ref during the
      search UUID process during virCloseCallackRun, decrementing the refcnt
      taken by virCloseCallbacksSet, calling the callback routine and returning
      overwriting the vm (since it could return NULL). Finally, it will call the
      virDomainObjEndAPI to lower the refcnt and remove the lock taken during
      the search UUID processing. This may cause the vm to be destroyed.
      48ad6009
  5. 27 1月, 2017 1 次提交
  6. 25 1月, 2017 1 次提交
  7. 24 1月, 2017 2 次提交
  8. 22 1月, 2017 2 次提交
  9. 20 1月, 2017 1 次提交
    • M
      qemu: set default vhost-user ifname · 57b5e27d
      Michal Privoznik 提交于
      Based on work of Mehdi Abaakouk <sileht@sileht.net>.
      
      When parsing vhost-user interface XML and no ifname is found we
      can try to fill it in in post parse callback. The way this works
      is we try to make up interface name from given socket path and
      then ask openvswitch whether it knows the interface.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      57b5e27d
  10. 18 1月, 2017 2 次提交
  11. 17 1月, 2017 1 次提交
  12. 12 1月, 2017 2 次提交
    • M
      util: Introduce virFileMoveMount · 41816751
      Michal Privoznik 提交于
      This is a simple wrapper over mount(). However, not every system
      out there is capable of moving a mount point. Therefore, instead
      of having to deal with this fact in all the places of our code we
      can have a simple wrapper and deal with this fact at just one
      place.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      41816751
    • M
      lxc: Move lxcContainerAvailable to virprocess · 083fcd06
      Michal Privoznik 提交于
      Other drivers (like qemu) would like to know if the namespaces
      are available therefore it makes sense to move this function to
      a shared module.
      
      At the same time, this function had some default namespaces that
      are checked with every call. It is not necessary - let callers
      pass just those namespaces they are interested in.
      
      With the move the function is renamed to
      virProcessNamespaceAvailable.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      083fcd06
  13. 10 1月, 2017 2 次提交
  14. 09 1月, 2017 3 次提交
    • D
      f1e48297
    • D
      lxc: ensure libvirt_lxc and qemu-nbd move into systemd machine slice · 44f79a0b
      Daniel P. Berrange 提交于
      Currently when spawning containers with systemd, the container PID 1
      will get moved into the systemd machine slice. Libvirt then manually
      moves the libvirt_lxc and qemu-nbd processes into the cgroups associated
      with the slice, but skips the systemd controller cgroup. This means that
      from systemd's POV, libvirt_lxc and qemu-nbd are still part of the
      libvirtd.service unit.
      
      On systemctl daemon-reload, it will notice that libvirt_lxc & qemu-nbd
      are in the libvirtd.service unit for the systemd controller, but in the
      machine cgroups for resources. Systemd will thus move them back into
      the libvirtd.service resource cgroups next time libvirtd is restarted.
      This causes libvirtd to kill off the container due to incorrect cgroup
      placement.
      
      The solution is to ensure that when moving libvirt_lxc & qemu-nbd, we
      also move the systemd cgroup controller placement. Normally this is
      not something we ever want todo, but this is a special case as we are
      intentionally wanting to move them to a different systemd unit.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      44f79a0b
    • M
      virutil: Provide non-linux impl for virGetFCHostNameByFabricWWN · 981d9790
      Michal Privoznik 提交于
      Currently, there's only linux implementation for
      virGetFCHostNameByFabricWWN(). Since the symbol is exported in
      our private symbols we ought to have implementation for other
      platforms too. This also triggers compilation error on FreeBSD:
      
      ../src/.libs/libvirt_driver_storage_impl.a(libvirt_driver_storage_impl_la-storage_backend_scsi.o): In function `createVport':
      /usr/home/jenkins/libvirt-master/systems/libvirt-freebsd/build/src/../../src/storage/storage_backend_scsi.c:740: undefined reference to `virGetFCHostNameByFabricWWN'
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      981d9790
  15. 07 1月, 2017 1 次提交
  16. 05 1月, 2017 2 次提交
  17. 04 1月, 2017 2 次提交
    • A
      util: Fix syntax-check · f0af48f0
      Andrea Bolognani 提交于
      Commit b9cc2483 introduced a new #define but neglected
      to format it properly, thus breaking syntax-check.
      f0af48f0
    • A
      util: Turn virFirewallAddRule() into a macro · b9cc2483
      Andrea Bolognani 提交于
      Clang 3.9 refuses to compile the existing code with the
      following error:
      
        util/virfirewall.c:425:20: error: passing an object that undergoes
                                   default argument promotion to 'va_start'
                                   has undefined behavior [-Werror,-Wvarargs]
            va_start(args, layer);
                           ^
        util/virfirewall.c:420:37: note: parameter of type 'virFirewallLayer'
                                   is declared here
                           virFirewallLayer layer,
                                            ^
      
      This happens because 'layer' is of type virFirewallLayer, which
      is an enum type and not a standard type such as eg. void* or int.
      
      To solve the issue, turn virFirewallAddRule() from a very thin
      wrapper around virFirewallAddRuleFullV() to a macro that expands
      to a call to virFirewallAddRuleFull() - itself a very thin wrapper
      around the aforementioned virFirewallAddRuleFullV() - with no loss
      of functionality or type safety.
      b9cc2483
  18. 02 1月, 2017 2 次提交
    • M
      virmacmap: Don't use hash table dataFree callback · 5dc6169b
      Michal Privoznik 提交于
      Due to nature of operations we do over the string list (more
      precisely due to how virStringListRemove() works), it is not the
      best idea to use dataFree callback. Problem is, on MAC address
      remove, the string list remove function modifies the original
      list in place. Then, virHashUpdateEntry() is called which frees
      all the data stored in the list rendering @newMacsList point to
      freed data.
      
      ==16002== Invalid read of size 8
      ==16002==    at 0x50BC083: virFree (viralloc.c:582)
      ==16002==    by 0x513DC39: virStringListFree (virstring.c:251)
      ==16002==    by 0x51089B4: virMacMapHashFree (virmacmap.c:67)
      ==16002==    by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352)
      ==16002==    by 0x50EF4FD: virHashUpdateEntry (virhash.c:415)
      ==16002==    by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129)
      ==16002==    by 0x51092D5: virMacMapRemove (virmacmap.c:346)
      ==16002==    by 0x402F02: testMACRemove (virmacmaptest.c:107)
      ==16002==    by 0x403F15: virTestRun (testutils.c:180)
      ==16002==    by 0x4032C4: mymain (virmacmaptest.c:205)
      ==16002==    by 0x405A3B: virTestMain (testutils.c:992)
      ==16002==    by 0x403D87: main (virmacmaptest.c:237)
      ==16002==  Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd
      ==16002==    at 0x4C2AD6F: realloc (vg_replace_malloc.c:693)
      ==16002==    by 0x50BB99B: virReallocN (viralloc.c:245)
      ==16002==    by 0x513DC0B: virStringListRemove (virstring.c:235)
      ==16002==    by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124)
      ==16002==    by 0x51092D5: virMacMapRemove (virmacmap.c:346)
      ==16002==    by 0x402F02: testMACRemove (virmacmaptest.c:107)
      ==16002==    by 0x403F15: virTestRun (testutils.c:180)
      ==16002==    by 0x4032C4: mymain (virmacmaptest.c:205)
      ==16002==    by 0x405A3B: virTestMain (testutils.c:992)
      ==16002==    by 0x403D87: main (virmacmaptest.c:237)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      5dc6169b
    • M
      virmacmap: Fix variable handling · 806582a5
      Michal Privoznik 提交于
      In virMacMapRemoveLocked() we have two variables: @macsList and
      @newMacsList. Obviously, @newMacsList is supposed to hold pointer
      to modified list but in fact it holds pointer to the old list.
      It's confusing.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      806582a5
  19. 21 12月, 2016 1 次提交
  20. 20 12月, 2016 2 次提交
    • B
      cgroup: reduce complexity of controller disabling · dbeaa7e6
      Boris Fiuczynski 提交于
      This patch reduces the complexity of the filtering algorithm in
      virCgroupDetect by first correcting the controller mask and then
      checking for potential co-mounts without any correlating
      controller mask modifications.
      
      If you agree that this patch removes complexity and improves
      readability it could simply be squashed into the first patch
      of this series.
      Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
      Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
      Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
      dbeaa7e6
    • B
      cgroup: unavailable controller prevents controller disabling · dfcfe0bb
      Boris Fiuczynski 提交于
      The cgroup controller filtering in virCgroupDetect does not work
      properly if the following conditions are met:
      1) the host system does not have a cgroup controller which
      libvirt requests (unavailable controller) and
      2) libvirt is configured to disable a controller (disabled controller) and
      3) the disabled controller is located before the unavailable controller
      in virCgroupController.
      
      As an example: The memory controller is unavailable and the cpuset
      controller is configured to be disabled.
      In this scenario trying to start a domain results in the error
      error: Controller 'cpuset' is not wanted, but 'memory' is co-mounted: Invalid argument
      
      This error occurs when virCgroupDetect is called with a valid parent group.
      The resulting group created by virCgroupCopyMounts holds for cpuset and
      memory controller empty mount points. The filtering of disabled controllers
      checks for co-mounts by comparing the mount points. The cpuset controller
      causes the filtering to occur before the memory controller is marked as to be
      ignored by modifying the controller mask since it is unavailable.
      Therefore the co-mount detection logic compares the cpuset and memory controller
      mount points and since both are empty the memory controller is regarded
      erroneously as being co-mounted.
      Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
      Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
      Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      dfcfe0bb
  21. 19 12月, 2016 1 次提交
    • J
      util: Introduce virSocketAddrPTRDomain · acd547dc
      Jiri Denemark 提交于
      The API creates PTR domain which corresponds to a given addr/prefix.
      Both IPv4 and IPv6 addresses are supported, but the prefix must be
      divisible by 8 for IPv4 and divisible by 4 for IPv6.
      
      The generated PTR domain has the following format
      
      IPv4: 1.2.3.4.in-addr.arpa
      IPv6: 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.ip6.arpa
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      acd547dc
  22. 17 12月, 2016 1 次提交
  23. 16 12月, 2016 5 次提交