1. 29 8月, 2017 10 次提交
  2. 28 8月, 2017 1 次提交
    • A
      qemu: Handle host devices not being available better · 1f433932
      Andrea Bolognani 提交于
      We can't retrieve the isolation group of a device that's not present
      in the system. However, it's very common for VFs to be created late
      in the boot, so they might not be present yet when libvirtd starts,
      which would cause the guests using them to disappear.
      
      Moreover, for other architectures and even ppc64 before isolation
      groups were introduced, it's considered perfectly fine to configure a
      guest to use a device that's not yet (or no longer) available to the
      host, with the obvious caveat that such a guest won't be able to
      start before the device is available.
      
      In order to be consistent, when a device's isolation group can't be
      determined fall back to not isolating it rather than erroring out or,
      worse, making the guest disappear.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1484254Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      1f433932
  3. 27 8月, 2017 4 次提交
  4. 26 8月, 2017 1 次提交
  5. 25 8月, 2017 1 次提交
  6. 18 8月, 2017 8 次提交
  7. 16 8月, 2017 1 次提交
    • J
      qemu: Fix bug assuming usage of default UUID for certificate passphrase · fdab78b5
      John Ferlan 提交于
      If an environment specific _tls_x509_cert_dir is provided, then
      do not VIR_STRDUP the defaultTLSx509secretUUID as that would be
      for the "default" environment and not the vnc, spice, chardev, or
      migrate environments. If the environment needs a secret to decode
      it's certificate, then it must provide the secret. If the secrets
      happen to be the same, then configuration would use the same UUID
      as the default (but we cannot assume that nor can we assume that
      the secret would be necessary).
      fdab78b5
  8. 15 8月, 2017 2 次提交
  9. 10 8月, 2017 2 次提交
  10. 07 8月, 2017 1 次提交
  11. 03 8月, 2017 4 次提交
  12. 02 8月, 2017 2 次提交
  13. 27 7月, 2017 3 次提交