1. 09 3月, 2020 1 次提交
    • M
      qemu: Tell secdrivers which images are top parent · 13eb6c14
      Michal Privoznik 提交于
      When preparing images for block jobs we modify their seclabels so
      that QEMU can open them. However, as mentioned in the previous
      commit, secdrivers base some it their decisions whether the image
      they are working on is top of of the backing chain. Fortunately,
      in places where we call secdrivers we know this and the
      information can be passed to secdrivers.
      
      The problem is the following: after the first blockcommit from
      the base to one of the parents the XATTRs on the base image are
      not cleared and therefore the second attempt to do another
      blockcommit fails. This is caused by blockcommit code calling
      qemuSecuritySetImageLabel() over the base image, possibly
      multiple times (to ensure RW/RO access). A naive fix would be to
      call the restore function. But this is not possible, because that
      would deny QEMU the access to the base image.  Fortunately, we
      can use the fact that seclabels are remembered only for the top
      of the backing chain and not for the rest of the backing chain.
      And thanks to the previous commit we can tell secdrivers which
      images are top of the backing chain.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1803551Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
      13eb6c14
  2. 05 3月, 2020 8 次提交
  3. 04 3月, 2020 17 次提交
  4. 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
  5. 26 2月, 2020 4 次提交
  6. 25 2月, 2020 2 次提交
  7. 24 2月, 2020 2 次提交
  8. 23 2月, 2020 5 次提交