1. 29 5月, 2017 2 次提交
    • N
      nodedev: Increase the netlink socket buffer size to the one used by udev · d1eea6c1
      ning.bo 提交于
      When a number of SRIOV VFs (up to 128 on Intel XL710) is created:
      for i in `seq 0 1`; do
        echo 63 > /sys/class/net/<interface>/device/sriov_numvfs
      done
      
      libvirtd will then report "udev_monitor_receive_device returned NULL"
      error because the netlink socket buffer is not big enough (using GDB on
      libudev confirmed this with ENOBUFFS) and thus some udev events were
      dropped. This results in some devices being missing in the nodedev-list
      output. This patch overrides the system's rmem_max limit but for that,
      we need to make sure we've got root privileges.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1450960Signed-off-by: Nning.bo <ning.bo9@zte.com.cn>
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d1eea6c1
    • M
      virCapabilitiesInitCaches: Don't leak @cpus · 6e9e1423
      Michal Privoznik 提交于
      The @cpus is allocated by virFileReadValueBitmap() but never
      freed:
      
      ==21274== 40 (32 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 808 of 1,004
      ==21274==    at 0x4C2E080: calloc (vg_replace_malloc.c:711)
      ==21274==    by 0x54BA561: virAlloc (viralloc.c:144)
      ==21274==    by 0x54BC604: virBitmapNewEmpty (virbitmap.c:126)
      ==21274==    by 0x54BD059: virBitmapParseUnlimited (virbitmap.c:570)
      ==21274==    by 0x54EECE9: virFileReadValueBitmap (virfile.c:4113)
      ==21274==    by 0x5563132: virCapabilitiesInitCaches (capabilities.c:1548)
      ==21274==    by 0x2BB86E59: virQEMUCapsInit (qemu_capabilities.c:1132)
      ==21274==    by 0x2BBEC067: virQEMUDriverCreateCapabilities (qemu_conf.c:928)
      ==21274==    by 0x2BC3DEAA: qemuStateInitialize (qemu_driver.c:845)
      ==21274==    by 0x5625AAC: virStateInitialize (libvirt.c:770)
      ==21274==    by 0x124519: daemonRunStateInit (libvirtd.c:881)
      ==21274==    by 0x554C927: virThreadHelper (virthread.c:206)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      6e9e1423
  2. 27 5月, 2017 1 次提交
  3. 26 5月, 2017 18 次提交
  4. 25 5月, 2017 4 次提交
  5. 24 5月, 2017 10 次提交
  6. 23 5月, 2017 5 次提交
    • P
      qemu: process: Clear priv->namespaces on VM shutdown · 5203975f
      Peter Krempa 提交于
      Otherwise the private data entry would be kept across instances of the
      same VM even if it's not configured to do so.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1453142
      5203975f
    • K
      qemu: Remove unused variables in qemuDomainUpdateDeviceConfig · 3c845817
      Kothapally Madhu Pavan 提交于
      priv and qemuCaps variables are not used anymore.
      Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
      3c845817
    • L
      Revert "qemu: propagate bridge MTU into qemu "host_mtu" option" · 77780a29
      Laine Stump 提交于
      This reverts commit 2841e675.
      
      It turns out that adding the host_mtu field to the PCI capabilities in
      the guest bumps the length of PCI capabilities beyond the 32 byte
      boundary, so the virtio-net device gets 64 bytes of ioport space
      instead of 32, which offsets the address of all the other following
      devices. Migration doesn't work very well when the location and length
      of PCI capabilities of devices is changed between source and
      destination.
      
      This means that we need to make sure that the absence/presence of
      host_mtu on the qemu commandline always matches between source and
      destination, which means that we need to make setting of host_mtu an
      opt-in thing (it can't happen automatically when the bridge being used
      has a non-default MTU, which is what commit 2841e675 implemented).
      
      I do want to re-implement this feature with an <mtu auto='on'/>
      setting, but probably won't backport that to any stable branches, so
      I'm first reverting the original commit, and that revert can be pushed
      to the few releases that have been made since the original (3.1.0 -
      3.3.0)
      
      Resolves: https://bugzilla.redhat.com/1449346
      77780a29
    • J
      libxl: add default listen address for VNC and spice · dbb85e0c
      Jim Fehlig 提交于
      If a VNC listen address is not specified in domXML, libxl
      will default to 127.0.0.1, but this is never reflected in the domXML.
      In the case of spice, a missing listen address resulted in listening
      on all interfaces, i.e. '0.0.0.0'. If not specified, set the listen
      address in virDomainGraphicsDef struct to the libxl default when
      creating the frame buffer device. Additionally, set default spice
      listen address to 127.0.0.1.
      dbb85e0c
    • J
      maint: define a macro for IPv4 loopback address · 975ea20f
      Jim Fehlig 提交于
      Use a macro instead of hardcoding "127.0.0.1" throughout the
      sources.
      975ea20f