1. 06 2月, 2020 1 次提交
  2. 04 2月, 2020 24 次提交
  3. 03 2月, 2020 2 次提交
  4. 02 2月, 2020 1 次提交
  5. 30 1月, 2020 4 次提交
    • J
      Add a space before ending a comment · 49882b33
      Ján Tomko 提交于
      Also add a space after the start in some of the cases.
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
      49882b33
    • 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
    • L
      conf: parse/format <teaming> subelement of <interface> · fb0509d0
      Laine Stump 提交于
      The subelement <teaming> of <interface> devices is used to configure a
      simple teaming association between two interfaces in a domain. Example:
      
        <interface type='bridge'>
          <source bridge='br0'/>
          <model type='virtio'/>
          <mac address='00:11:22:33:44:55'/>
          <alias name='ua-backup0'/>
          <teaming type='persistent'/>
        </interface>
        <interface type='hostdev'>
          <source>
            <address type='pci' bus='0x02' slot='0x10' function='0x4'/>
          </source>
          <mac address='00:11:22:33:44:55'/>
          <teaming type='transient' persistent='ua-backup0'/>
        </interface>
      
      The interface with <teaming type='persistent'/> is assumed to always
      be present, while the interface with type='transient' may be be
      unplugged and later re-plugged; the persistent='blah' attribute (and
      in the one currently available implementation, also the matching MAC
      addresses) is what associates the two devices with each other. It is
      up to the hypervisor and the guest network drivers to determine what
      to do with this information.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      fb0509d0
    • L
      qemu: add capabilities flag for failover feature · cad65f22
      Laine Stump 提交于
      Presence of the virtio-net-pci option called "failover" indicates
      support in a qemu binary of a simplistic bonding of a virtio-net
      device with another PCI device. This feature allows migration of
      guests that have a network device assigned to a guest with VFIO, by
      creating a network bond device in the guest consisting of the
      VFIO-assigned device and a virtio-net-pci device, then temporarily
      (and automatically) unplugging the VFIO net device prior to migration
      (and hotplugging an equivalent device on the migration
      destination). (The feature is called "failover" because the bond
      device uses the vfio-pci netdev for normal guest networking, but
      "fails over" to the virtio-net-pci netdev once the vfio-pci device is
      unplugged for migration.)
      
      Full functioning of the feature also requires support in the
      virtio-net driver in the guest OS (since that is where the bond device
      resides), but if the "failover" commandline option is present for the
      virtio-net-pci device in qemu, at least the qemu part of the feature
      is available, and libvirt can add the proper options to both the
      virtio-net-pci and vfio-pci device commandlines to indicate qemu
      should attempt doing the failover during migration.
      
      This patch just adds the qemu capabilities flag "virtio-net.failover".
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      cad65f22
  6. 29 1月, 2020 7 次提交
  7. 27 1月, 2020 1 次提交