1. 12 4月, 2018 1 次提交
  2. 03 4月, 2018 2 次提交
  3. 01 4月, 2018 1 次提交
  4. 15 3月, 2018 1 次提交
  5. 23 2月, 2018 1 次提交
  6. 22 2月, 2018 3 次提交
  7. 20 2月, 2018 1 次提交
    • D
      conf: add enum constants for default controller models · a302480d
      Daniel P. Berrangé 提交于
      The controller model is slightly unusual in that the default value is
      -1, not 0. As a result the default value is not covered by any of the
      existing enum cases. This in turn means that any switch() statements
      that think they have covered all cases, will in fact not match the
      default value at all. In the qemuDomainDeviceCalculatePCIConnectFlags()
      method this has caused a serious mistake where we fallthrough from the
      SCSI controller case, to the VirtioSerial controller case, and from
      the USB controller case to the IDE controller case.
      
      By adding explicit enum constant starting at -1, we can ensure switches
      remember to handle the default case.
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      a302480d
  8. 19 2月, 2018 2 次提交
  9. 12 2月, 2018 2 次提交
  10. 09 2月, 2018 2 次提交
  11. 02 2月, 2018 2 次提交
  12. 01 2月, 2018 4 次提交
  13. 17 1月, 2018 1 次提交
  14. 09 1月, 2018 1 次提交
  15. 04 1月, 2018 1 次提交
    • J
      qemu: Use same model when adding hostdev SCSI controller · 07beea6c
      John Ferlan 提交于
      When qemuDomainFindOrCreateSCSIDiskController adds a controller,
      let's use the same model as a currently found controller under the
      assumption that the reason to add the controller in hotplug is
      because virDomainHostdevAssignAddress determined that there were
      too many devices on the existing controller, but only assigned a
      new controller index and did not add a new controller and we
      desire to use the same controller model as any existing controller
      and not take a chance that qemuDomainSetSCSIControllerModel would
      use a default that may be incompatible.
      07beea6c
  16. 21 12月, 2017 2 次提交
    • J
      qemu: Move TCP and haveTLS checks into qemuDomainDelChardevTLSObjects · 715b321d
      John Ferlan 提交于
      Similar to qemuDomainAddChardevTLSObjects let's move the chardev
      source must be TCP and it has the @haveTLS flag set checks before
      trying to delete the TLS objects.
      
      For the Chr device this represents no change; however, for RNG device
      this is an additionaly check that was missed in commit id '68808516'.
      Before adding the objects, TCP and haveTLS are checked.
      715b321d
    • J
      qemu: Introduce qemuDomainDelChardevTLSObjects · 10dcdfa3
      John Ferlan 提交于
      Let's make a comment deletion helper similar to the Add helper
      that can be called after the ExitMonitor.
      
      The modify qemuDomainRemoveChrDevice and qemuDomainRemoveRNGDevice
      to call the helper instead of inlining the copy and pasted code.
      10dcdfa3
  17. 15 12月, 2017 1 次提交
    • L
      qemu: delete exist bandwidth restrictions when they are removed from config · b21163bd
      Laine Stump 提交于
      When the <bandwidth> of an interface is changed with update-device,
      the old settings are cleared with tc, then new settings added with
      tc. But if the <bandwidth has been removed, the old settings weren't
      being removed, so the bandwidth restrictions would still be active on
      the interface although the interface status in libvirt showed that
      they had been removed.
      
      This patch fixes it by calling virNetDevBandwidthClear() if the
      "modification" to the interface bandwidth was to completely clear
      it.
      
      An alternative could have been to modify virNetDevBandwidthSet() to
      always clear existing bandwith settings at the beginning of the
      function (currently it short circuits in that case, doing nothing),
      but that would have led to cases where virNetDevBandwidthClear() was
      now being called in cases where it previously wasn't, and while many
      of those cases would be NOPs, there could be cases where it would
      cause an error. The way this patch works, the ...Clear() function is
      only called in cases where the ...Set() function had previously been
      called successfully, so the risk of regression is minimized.
      
        Resolves: https://bugzilla.redhat.com/1454709
      b21163bd
  18. 14 12月, 2017 2 次提交
  19. 06 12月, 2017 1 次提交
  20. 05 12月, 2017 1 次提交
  21. 25 11月, 2017 3 次提交
  22. 24 11月, 2017 3 次提交
  23. 13 11月, 2017 1 次提交
  24. 08 11月, 2017 1 次提交