1. 14 2月, 2020 1 次提交
  2. 06 2月, 2020 1 次提交
  3. 04 2月, 2020 1 次提交
  4. 30 1月, 2020 1 次提交
    • L
      qemu: support interface <teaming> functionality · eb9f6cc4
      Laine Stump 提交于
      The QEMU driver uses the <teaming type='persistent|transient'
      persistent='blah'/> element to setup a "failover" pair of devices -
      the persistent device must be a virtio emulated NIC, with the only
      extra configuration being the addition of ",failover=on" to the device
      commandline, and the transient device must be a hostdev NIC
      (<interface type='hostdev'> or <interface type='network'> with a
      network that is a pool of SRIOV VFs) where the extra configuration is
      the addition of ",failover_pair_id=$aliasOfVirtio" to the device
      commandline. These new options are supported in QEMU 4.2.0 and later.
      
      Extra qemu-specific validation is added to ensure that the device
      type/model is appropriate and that the qemu binary supports these
      commandline options.
      
      The result of this will be:
      
      1) The virtio device presented to the guest will have an extra bit set
      in its PCI capabilities indicating that it can be used as a failover
      backup device. The virtio guest driver will need to be equipped to do
      something with this information - this is included in the Linux
      virtio-net driver in kernel 4.18 and above (and also backported to
      some older distro kernels). Unfortunately there is no way for libvirt
      to learn whether or not the guest driver supports failover - if it
      doesn't then the extra PCI capability will be ignored and the guest OS
      will just see two independent devices. (NB: the current virtio guest
      driver also requires that the MAC addresses of the two NICs match in
      order to pair them into a bond).
      
      2) When a migration is requested, QEMu will automatically unplug the
      transient/hostdev NIC from the guest on the source host before
      starting migration, and automatically re-plug a similar device after
      restarting the guest CPUs on the destination host. While the transient
      NIC is unplugged, all network traffic will go through the
      persistent/virtio device, but when the hostdev NIC is plugged in, it
      will get all the traffic. This means that in normal circumstances the
      guest gets the performance advantage of vfio-assigned "real hardware"
      networking, but it can still be migrated with the only downside being
      a performance penalty (due to using an emulated NIC) during the
      migration.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      eb9f6cc4
  5. 29 1月, 2020 2 次提交
  6. 25 1月, 2020 3 次提交
  7. 17 1月, 2020 1 次提交
  8. 16 1月, 2020 2 次提交
  9. 08 1月, 2020 2 次提交
  10. 07 1月, 2020 1 次提交
  11. 03 1月, 2020 1 次提交
  12. 19 12月, 2019 6 次提交
  13. 18 12月, 2019 1 次提交
    • D
      qemu_command: tidy up qemuBuildHostdevCommandLine loop · aed9bcd1
      Daniel Henrique Barboza 提交于
      The current 'for' loop with 5 consecutive 'ifs' inside
      qemuBuildHostdevCommandLine can be a bit smarter:
      
      - all 5 'ifs' fails if hostdev->mode is not equal to
      VIR_DOMAIN_HOSTDEV_MODE_SUBSYS. This check can be moved to the
      start of the loop, failing to the next element immediately
      in case it fails;
      
      - all 5 'ifs' checks for a specific subsys->type to build the proper
      command line argument (virHostdevIsSCSIDevice and virHostdevIsMdevDevice
      do that but within a helper). Problem is that the code will keep
      checking for matches even if one was already found, and there is
      no way a hostdev will fit more than one 'if' (i.e. a hostdev can't
      have 2+ different types). This means that a SUBSYS_TYPE_USB will
      create its command line argument in the first 'if', then all other
      conditionals will surely fail but will end up being checked anyway.
      
      All of this can be avoided by moving the hostdev->mode comparing
      to the start of the loop and using a switch statement with
      subsys->type to execute the proper code for a given hostdev
      type.
      Suggested-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      aed9bcd1
  14. 17 12月, 2019 17 次提交