1. 15 10月, 2019 2 次提交
  2. 14 10月, 2019 3 次提交
    • M
      security: Pass @migrated to virSecurityManagerSetAllLabel · 458d0a8c
      Michal Privoznik 提交于
      In upcoming commits, virSecurityManagerSetAllLabel() will perform
      rollback in case of failure by calling
      virSecurityManagerRestoreAllLabel(). But in order to do that, the
      former needs to have @migrated argument so that it can be passed
      to the latter.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      458d0a8c
    • D
      build: remove use of usleep gnulib module in favour of g_usleep · 27cb4c1a
      Daniel P. Berrangé 提交于
      The usleep function was missing on older mingw versions, but we can rely
      on it existing everywhere these days. It may only support times upto 1
      second in duration though, so we'll prefer to use g_usleep instead.
      
      The commandhelper program is not changed since that can't link to glib.
      Fortunately it doesn't need to build on Windows platforms either.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      27cb4c1a
    • D
      build: link to glib library · cfbe9f12
      Daniel P. Berrangé 提交于
      Add the main glib.h to internal.h so that all common code can use it.
      
      Historically glib allowed applications to register an alternative
      memory allocator, so mixing g_malloc/g_free with malloc/free was not
      safe.
      
      This was feature was dropped in 2.46.0 with:
      
            commit 3be6ed60aa58095691bd697344765e715a327fc1
            Author: Alexander Larsson <alexl@redhat.com>
            Date:   Sat Jun 27 18:38:42 2015 +0200
      
              Deprecate and drop support for memory vtables
      
      Applications are still encourged to match g_malloc/g_free, but it is no
      longer a mandatory requirement for correctness, just stylistic. This is
      explicitly clarified in
      
          commit 1f24b36607bf708f037396014b2cdbc08d67b275
          Author: Daniel P. Berrangé <berrange@redhat.com>
          Date:   Thu Sep 5 14:37:54 2019 +0100
      
              gmem: clarify that g_malloc always uses the system allocator
      
      Applications can still use custom allocators in general, but they must
      do this by linking to a library that replaces the core malloc/free
      implemenentation entirely, instead of via a glib specific call.
      
      This means that libvirt does not need to be concerned about use of
      g_malloc/g_free causing an ABI change in the public libary, and can
      avoid memory copying when talking to external libraries.
      
      This patch probes for glib, which provides the foundation layer with
      a collection of data structures, helper APIs, and platform portability
      logic.
      
      Later patches will introduce linkage to gobject which provides the
      object type system, built on glib, and gio which providing objects
      for various interesting tasks, most notably including DBus client
      and server support and portable sockets APIs, but much more too.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      cfbe9f12
  3. 08 10月, 2019 1 次提交
  4. 27 9月, 2019 1 次提交
    • L
      conf: utility function to update entry in def->nets array · 7e490cda
      Laine Stump 提交于
      A virDomainNetDef object in a domain's nets array might contain a
      virDomainHostdevDef, and when this is the case, the domain's hostdevs
      array will also have a pointer to this embedded hostdev (this is done
      so that internal functions that need to perform some operation on all
      hostdevs won't leave out the type='hostdev' network interfaces).
      
      When a network device was updated with virDomainUpdateDeviceFlags(),
      we were replacing the entry in the nets array (and free'ing the
      original) but forgetting about the pointer in the hostdevs array
      (which would then point to the now-free'd hostdev contained in the old
      net object.) This often resulted in a libvirtd crash.
      
      The solution is to add a function, virDomainNetUpdate(), called by
      qemuDomainUpdateDeviceConfig(), that updates the hostdevs array
      appropriately along with the nets array.
      
      Resolves: https://bugzilla.redhat.com/1558934Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      7e490cda
  5. 19 9月, 2019 1 次提交
  6. 10 9月, 2019 2 次提交
  7. 07 9月, 2019 1 次提交
  8. 06 9月, 2019 1 次提交
  9. 27 8月, 2019 2 次提交
  10. 21 8月, 2019 6 次提交
  11. 09 8月, 2019 9 次提交
  12. 07 8月, 2019 1 次提交
  13. 25 7月, 2019 1 次提交
    • J
      qemu: Add support for overriding max threads per process limit · d5572f62
      Jim Fehlig 提交于
      Some VM configurations may result in a large number of threads created by
      the associated qemu process which can exceed the system default limit. The
      maximum number of threads allowed per process is controlled by the pids
      cgroup controller and is set to 16k when creating VMs with systemd's
      machined service. The maximum number of threads per process is recorded
      in the pids.max file under the machine's pids controller cgroup hierarchy,
      e.g.
      
      $cgrp-mnt/pids/machine.slice/machine-qemu\\x2d1\\x2dtest.scope/pids.max
      
      Maximum threads per process is controlled with the TasksMax property of
      the systemd scope for the machine. This patch adds an option to qemu.conf
      which can be used to override the maximum number of threads allowed per
      qemu process. If the value of option is greater than zero, it will be set
      in the TasksMax property of the machine's scope after creating the machine.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      d5572f62
  14. 15 7月, 2019 1 次提交
  15. 11 7月, 2019 1 次提交
    • D
      lxc: acquire a pidfile in the driver root directory · 64c5b6bc
      Daniel P. Berrangé 提交于
      When we allow multiple instances of the driver for the same user
      account, using a separate root directory, we need to ensure mutual
      exclusion. Use a pidfile to guarantee this.
      
      In privileged libvirtd this ends up locking
      
         /var/run/libvirt/lxc/driver.pid
      
      In unprivileged libvirtd this ends up locking
      
        /run/user/$UID/libvirt/lxc/run/driver.pid
      
      NB, the latter can vary depending on $XDG_RUNTIME_DIR
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      64c5b6bc
  16. 21 6月, 2019 1 次提交
    • D
      remote: delete the avahi mDNS support · 5a148ce8
      Daniel P. Berrangé 提交于
      Libvirtd has long had integration with avahi for advertising libvirtd
      using mDNS when TCP/TLS listening is enabled. For a long time the
      virt-manager application had support for auto-detecting libvirtds
      on the local network using mDNS, but this was removed last year
      
        commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
        Author: Cole Robinson <crobinso@redhat.com>
        Date:   Sat Oct 6 20:55:31 2018 -0400
      
          connect: Drop avahi support
      
          Libvirtd can advertise itself over avahi. The feature is disabled by
          default though and in practice I hear of no one actually using it
          and frankly I don't think it's all that useful
      
          The 'Open Connection' wizard has a disproportionate amount of code
          devoted to this feature, but I don't think it's useful or worth
          maintaining, so let's drop it
      
      I've never heard of any other applications having support for using
      mDNS to detect libvirtd instances. Though it is theoretically possible
      something exists out there, it is clearly going to be a niche use case
      in the virt ecosystem as a whole.
      
      By removing avahi integration we can cut down the dependency chain for
      the basic libvirtd install and reduce our code maint burden.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5a148ce8
  17. 19 6月, 2019 1 次提交
  18. 17 6月, 2019 2 次提交
  19. 30 4月, 2019 2 次提交
  20. 26 4月, 2019 1 次提交