1. 05 3月, 2020 4 次提交
    • P
      util: json: Convert virJSONValueNewObject() to g_new0 · e9153cc6
      Peter Krempa 提交于
      Make it obvious that the function always returns a valid pointer and fix
      all callers.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      e9153cc6
    • M
      qemu_shim: Ignore SIGPIPE · 084c04b5
      Michal Privoznik 提交于
      I've found that if my virtlogd is socket activated but the daemon
      doesn't run yet, then the virt-qemu-run is killed right after it
      tries to start the domain. The problem is that because the default
      setting is to use virtlogd, the domain create code tries to
      connect to virtlogd socket, which in turn tries to detect who is
      connecting (virNetSocketGetUNIXIdentity()) and as a part of it,
      it will try to open /proc/${PID_OF_SHIM}/stat which is denied by
      SELinux:
      
        type=AVC msg=audit(1582903501.927:323): avc:  denied  { search } for  \
        pid=1210 comm="virtlogd" name="1843" dev="proc" ino=37224 \
        scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 \
        tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dir \
        permissive=0
      
      Virtlogd reacts by closing the connection which the shim sees as
      SIGPIPE. Since the default response to the signal is Term, we
      don't even get to reporting any error nor to removing the
      temporary directory.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      084c04b5
    • M
      qemu_shim: Allow other users to enter the root dir · 63af64d7
      Michal Privoznik 提交于
      When virt-qemu-run is ran without any root directory specified on
      the command line, a temporary directory is made and used instead.
      But since we are using g_dir_make_tmp() to create the directory
      it is going to have 0700 mode. So even though we create the whole
      directory structure under it and label everything, QEMU is very
      likely to not have the access. This is because in this case there
      is no qemu.conf and thus distro default UID:GID is used to run
      QEMU (e.g. qemu:kvm on Fedora). Change the mode of the temporary
      directory so that everybody has eXecute permission.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      63af64d7
    • M
      qemu: Don't compare local and remote hostnames on migration · 6799b72d
      Michal Privoznik 提交于
      Libvirt tries to forbid migration onto the same host and it does
      that by checking if local and remote hostnames are the same and
      whether local and remote UUIDs are the same. Well, the latter
      makes sense but the former doesn't really because libvirtd can be
      running inside an UTS namespace and hostnames can appear the same
      on both sides of migration. On the other hand, host UUIDs are
      unique, so rely on them when trying to prevent migration onto the
      same host.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1639596Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      6799b72d
  2. 04 3月, 2020 17 次提交
  3. 27 2月, 2020 1 次提交
    • P
      daemon: set default memlock limit for systemd service · b379fee1
      Pavel Hrdina 提交于
      The default memlock limit is 64k which is not enough to start a single
      VM. The requirements for one VM are 12k, 8k for eBPF map and 4k for eBPF
      program, however, it fails to create eBPF map and program with 64k limit.
      By testing I figured out that the minimal limit is 80k to start a single
      VM with functional eBPF and if I add 12k I can start another one.
      
      This leads into following calculation:
      
      80k as memlock limit worked to start a VM with eBPF which means there
      is 68k of lock memory that I was not able to figure out what was using
      it.  So to get a number for 4096 VMs:
      
              68 + 12 * 4096 = 49220
      
      If we round it up we will get 64M of memory lock limit to support 4096
      VMs with default map size which can hold 64 entries for devices.
      
      This should be good enough as a sane default and users can change it if
      the need to.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1807090Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      b379fee1
  4. 26 2月, 2020 4 次提交
  5. 25 2月, 2020 2 次提交
  6. 24 2月, 2020 2 次提交
  7. 23 2月, 2020 10 次提交