1. 17 3月, 2017 3 次提交
  2. 16 3月, 2017 1 次提交
  3. 10 3月, 2017 1 次提交
    • M
      qemuProcessHandleMonitorEOF: Disable namespace for domain · e915942b
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1430634
      
      If a qemu process has died, we get EOF on its monitor. At this
      point, since qemu process was the only one running in the
      namespace kernel has already cleaned the namespace up. Any
      attempt of ours to enter it has to fail.
      
      This really happened in the bug linked above. We've tried to
      attach a disk to qemu and while we were in the monitor talking to
      qemu it just died. Therefore our code tried to do some roll back
      (e.g. deny the device in cgroups again, restore labels, etc.).
      However, during the roll back (esp. when restoring labels) we
      still thought that domain has a namespace. So we used secdriver's
      transactions. This failed as there is no namespace to enter.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      e915942b
  4. 08 3月, 2017 1 次提交
  5. 06 3月, 2017 1 次提交
    • M
      qemu: Enforce qemuSecurity wrappers · 4da534c0
      Michal Privoznik 提交于
      Now that we have some qemuSecurity wrappers over
      virSecurityManager APIs, lets make sure everybody sticks with
      them. We have them for a reason and calling virSecurityManager
      API directly instead of wrapper may lead into accidentally
      labelling a file on the host instead of namespace.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      4da534c0
  6. 04 3月, 2017 1 次提交
  7. 24 2月, 2017 3 次提交
  8. 23 2月, 2017 1 次提交
  9. 21 2月, 2017 6 次提交
  10. 16 2月, 2017 1 次提交
  11. 09 2月, 2017 1 次提交
  12. 17 1月, 2017 1 次提交
  13. 10 1月, 2017 1 次提交
  14. 05 1月, 2017 2 次提交
  15. 15 12月, 2016 3 次提交
    • P
      qemu: monitor: Don't resume lockspaces in resume event handler · e8f167a6
      Peter Krempa 提交于
      After qemu delivers the resume event it's already running and thus it's
      too late to enter lockspaces since it may already have modified the
      disk. The code only creates false log entries in the case when locking
      is enabled. The lockspace needs to be acquired prior to starting cpus.
      e8f167a6
    • M
      qemu: Enter the namespace on relabelling · eadaa975
      Michal Privoznik 提交于
      Instead of trying to fix our security drivers, we can use a
      simple trick to relabel paths in both namespace and the host.
      I mean, if we enter the namespace some paths are still shared
      with the host so any change done to them is visible from the host
      too.
      Therefore, we can just enter the namespace and call
      SetAllLabel()/RestoreAllLabel() from there. Yes, it has slight
      overhead because we have to fork in order to enter the namespace.
      But on the other hand, no complexity is added to our code.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      eadaa975
    • M
      qemu: Spawn qemu under mount namespace · bb4e5296
      Michal Privoznik 提交于
      Prime time. When it comes to spawning qemu process and
      relabelling all the devices it's going to touch, there's inherent
      race with other applications in the system (e.g. udev). Instead
      of trying convincing udev to not touch libvirt managed devices,
      we can create a separate mount namespace for the qemu, and mount
      our own /dev there. Of course this puts more work onto us as we
      have to maintain /dev files on each domain start and device
      hot(un-)plug. On the other hand, this enhances security also.
      
      From technical POV, on domain startup process the parent
      (libvirtd) creates:
      
        /var/lib/libvirt/qemu/$domain.dev
        /var/lib/libvirt/qemu/$domain.devpts
      
      The child (which is going to be qemu eventually) calls unshare()
      to create new mount namespace. From now on anything that child
      does is invisible to the parent. Child then mounts tmpfs on
      $domain.dev (so that it still sees original /dev from the host)
      and creates some devices (as explained in one of the previous
      patches). The devices have to be created exactly as they are in
      the host (including perms, seclabels, ACLs, ...). After that it
      moves $domain.dev mount to /dev.
      
      What's the $domain.devpts mount there for then you ask? QEMU can
      create PTYs for some chardevs. And historically we exposed the
      host ends in our domain XML allowing users to connect to them.
      Therefore we must preserve devpts mount to be shared with the
      host's one.
      
      To make this patch as small as possible, creating of devices
      configured for domain in question is implemented in next patches.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      bb4e5296
  16. 14 12月, 2016 1 次提交
    • V
      qemu: Allow use of hot plugged host CPUs if no affinity set · 283e2904
      Viktor Mihajlovski 提交于
      If the cpuset cgroup controller is disabled in /etc/libvirt/qemu.conf
      QEMU virtual machines can in principle use all host CPUs, even if they
      are hot plugged, if they have no explicit CPU affinity defined.
      
      However, there's libvirt code supposed to handle the situation where
      the libvirt daemon itself is not using all host CPUs. The code in
      qemuProcessInitCpuAffinity attempts to set an affinity mask including
      all defined host CPUs. Unfortunately, the resulting affinity mask for
      the process will not contain the offline CPUs. See also the
      sched_setaffinity(2) man page.
      
      That means that even if the host CPUs come online again, they won't be
      used by the QEMU process anymore. The same is true for newly hot
      plugged CPUs. So we are effectively preventing that QEMU uses all
      processors instead of enabling it to use them.
      
      It only makes sense to set the QEMU process affinity if we're able
      to actually grow the set of usable CPUs, i.e. if the process affinity
      is a subset of the online host CPUs.
      
      There's still the chance that for some reason the deliberately chosen
      libvirtd affinity matches the online host CPU mask by accident. In this
      case the behavior remains as it was before (CPUs offline while setting
      the affinity will not be used if they show up later on).
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      Tested-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
      283e2904
  17. 09 12月, 2016 2 次提交
  18. 08 12月, 2016 2 次提交
    • M
      security: Drop virSecurityManagerSetHugepages · ce937d37
      Michal Privoznik 提交于
      Since its introduction in 2012 this internal API did nothing.
      Moreover we have the same API that does exactly the same:
      virSecurityManagerDomainSetPathLabel.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ce937d37
    • M
      qemu: Create hugepage path on per domain basis · f55afd83
      Michal Privoznik 提交于
      If you've ever tried running a huge page backed guest under
      different user than in qemu.conf, you probably failed. Problem is
      even though we have corresponding APIs in the security drivers,
      there's no implementation and thus we don't relabel the huge page
      path. But even if we did, so far all of the domains share the
      same path:
      
         /hugepageMount/libvirt/qemu
      
      Our only option there would be to set 0777 mode on the qemu dir
      which is totally unsafe. Therefore, we can create dir on
      per-domain basis, i.e.:
      
         /hugepageMount/libvirt/qemu/domainName
      
      and chown domainName dir to the user that domain is configured to
      run under.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      f55afd83
  19. 01 12月, 2016 1 次提交
    • L
      qemu: propagate virQEMUDriver object to qemuDomainDeviceCalculatePCIConnectFlags · 9b0848d5
      Laine Stump 提交于
      If libvirtd is running unprivileged, it can open a device's PCI config
      data in sysfs, but can only read the first 64 bytes. But as part of
      determining whether a device is Express or legacy PCI,
      qemuDomainDeviceCalculatePCIConnectFlags() will be updated in a future
      patch to call virPCIDeviceIsPCIExpress(), which tries to read beyond
      the first 64 bytes of the PCI config data and fails with an error log
      if the read is unsuccessful.
      
      In order to avoid creating a parallel "quiet" version of
      virPCIDeviceIsPCIExpress(), this patch passes a virQEMUDriverPtr down
      through all the call chains that initialize the
      qemuDomainFillDevicePCIConnectFlagsIterData, and saves the driver
      pointer with the rest of the iterdata so that it can be used by
      qemuDomainDeviceCalculatePCIConnectFlags(). This pointer isn't used
      yet, but will be used in an upcoming patch (that detects Express vs
      legacy PCI for VFIO assigned devices) to examine driver->privileged.
      9b0848d5
  20. 29 11月, 2016 1 次提交
  21. 28 11月, 2016 1 次提交
    • P
      qemu: capabilities: Don't partially reprope caps on process reconnect · b87a1134
      Peter Krempa 提交于
      Thanks to the complex capability caching code virQEMUCapsProbeQMP was
      never called when we were starting a new qemu VM. On the other hand,
      when we are reconnecting to the qemu process we reload the capability
      list from the status XML file. This means that the flag preventing the
      function being called was not set and thus we partially reprobed some of
      the capabilities.
      
      The recent addition of CPU hotplug clears the
      QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine does not support it.
      The partial re-probe on reconnect results into attempting to call the
      unsupported command and then killing the VM.
      
      Remove the partial reprobe and depend on the stored capabilities. If it
      will be necessary to reprobe the capabilities in the future, we should
      do a full reprobe rather than this partial one.
      b87a1134
  22. 26 11月, 2016 1 次提交
    • J
      qemu: Probe CPU models for KVM and TCG · 7bf6f345
      Jiri Denemark 提交于
      CPU models (and especially some additional details which we will start
      probing for later) differ depending on the accelerator. Thus we need to
      call query-cpu-definitions in both KVM and TCG mode to get all data we
      want.
      
      Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid
      having to squash even more stuff into this single patch. They will all
      be switched back later in separate commits.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      7bf6f345
  23. 25 11月, 2016 1 次提交
    • M
      virstring: Unify string list function names · c2a5a4e7
      Michal Privoznik 提交于
      We have couple of functions that operate over NULL terminated
      lits of strings. However, our naming sucks:
      
      virStringJoin
      virStringFreeList
      virStringFreeListCount
      virStringArrayHasString
      virStringGetFirstWithPrefix
      
      We can do better:
      
      virStringListJoin
      virStringListFree
      virStringListFreeCount
      virStringListHasString
      virStringListGetFirstWithPrefix
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      c2a5a4e7
  24. 23 11月, 2016 3 次提交
    • N
      qemu: drop write-only agentStart · 3c1c5678
      Nikolay Shirokovskiy 提交于
      3c1c5678
    • N
      qemu: agent: cleanup agent error flag correctly · 6ba861ae
      Nikolay Shirokovskiy 提交于
      Sometimes after domain restart agent is unavailabe even
      if it is up and running in guest. Diagnostic message is
      "QEMU guest agent is not available due to an error"
      that is 'priv->agentError' is set. Investiagion shows that
      'priv->agent' is not NULL, so error flag is set probably
      during domain shutdown process and not cleaned up eventually.
      
      The patch is quite simple - just clean up error flag unconditionally
      upon domain stop.
      
      Other hunks address other cases when error flag is not cleaned up.
      
      1. processSerialChangedEvent. We need to clean error flag
      unconditionally here too. For example if upon first 'connected' event we
      fail to connect and set error flag and then connect on second
      'connected' event then error flag will remain set erroneously
      and make agent unavailable.
      
      2. qemuProcessHandleAgentEOF. If error flag is set and we get
      EOF we need to change state (and diagnostic) from 'error' to
      'not connected'.
      6ba861ae
    • N
      qemu: agent: handle agent connection errors in one place · 851ae08e
      Nikolay Shirokovskiy 提交于
      qemuConnectAgent return -1 or -2 in case of different errors.
      A. -1 is a case of unsuccessuful connection to guest agent.
      B. -2 is a case of destoyed domain during connection attempt.
      
      All qemuConnectAgent callers handle the first error the same way
      so let's move this logic into qemuConnectAgent itself. Patched
      function returns 0 in case A and -1 in case B.
      851ae08e