1. 31 1月, 2020 1 次提交
    • C
      apparmor: fix qemu_bridge_helper for named profile · 5a21fd51
      Christian Ehrhardt 提交于
      Since a3ab6d42 "apparmor: convert libvirtd profile to a named profile"
      the detection of the subelement for qemu_bridge_helper is wrong.
      
      In combination with the older 123cc3e1 "apparmor: allow
      /usr/lib/qemu/qemu-bridge-helper" it now detects qemu-bridge-helper no
      more with its path, but instead as a proper subelement of the named profile
      like: label=libvirtd//qemu_bridge_helper
      
      In the same fashion the reverse rule in the qemu_bridge_helper
      sub-profile still uses the path and not the named profile label.
      
      Triggering denies like:
      apparmor="DENIED" operation="file_inherit"
        profile="libvirtd//qemu_bridge_helper" pid=5629 comm="qemu-bridge-hel"
        family="unix" sock_type="stream" protocol=0 requested_mask="send receive"
        denied_mask="send receive" addr=none peer_addr=none peer="libvirtd"
      
      This patch fixes the unix socket rules for the communication between
      libvirtd and qemu-bridge-helper to match that.
      
      Fixes: a3ab6d42
      Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1655111Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
      5a21fd51
  2. 30 1月, 2020 13 次提交
    • E
      nwfilter: Use immediate packet delivery mode rather than buffering · 2b082d87
      Erik Skultety 提交于
      Our nwfilter code doesn't set any timeout on the pcap packet buffer which
      means that when DHCP snooping is enabled on a guest interface and
      libvirt is trying to learn the IP address from guest's DHCP traffic, it
      takes up to 4x longer to ping a guest successfully compared to a case
      where nwfilter isn't enabled at all or libvirt uses the cached nwfilter
      leases to populate the corresponding rules to ebtables.
      With the pcap filter and rate limiting already in place, we should be
      able to afford enabling the immediate packet delivery, FWIW immediate
      mode was actually the default prior libpcap-1.5.0 (CentOS 6) regardless
      of whether a buffer was requested.
      
      The lack of any kind of timeout on the pcap buffer messed with the
      libvirt TCK test suite which, even with a generous timeout in place,
      timeouts every single time simply because it takes a while until
      guest actually starts producing any kind of traffic to fill up
      the buffer in place (apart from the DHCP traffic which happens fairly
      early on).
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      2b082d87
    • E
      libpcap: Bump the minimum required version to >= 1.5.0 · 77c53403
      Erik Skultety 提交于
      libpcap-1.5.0 introduced a function to enforce immediate mode (on all
      platforms) which the follow-up patches will rely on.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      77c53403
    • 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
    • M
      apparmor: Drop 'Last modified' comment from profiles · 2f74105d
      Michal Privoznik 提交于
      At the beginning of each profile we have a comment that says when
      the profile was last updated. In theory, it makes sense because
      one can see immediately if they are using an outdated profile.
      However, we don't do a good job in keeping the comments in sync
      with reality and also sysadmins should rather use their package
      manager to find out libvirt version which installed the profiles.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Acked-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
      2f74105d
    • M
      apparmor: Allow some more BIOS/UEFI paths · 8f204fb4
      Michal Privoznik 提交于
      There are two more paths that we are missing in the default
      domain profile: /usr/share/edk2-ovmf/ and /usr/share/sgabios/.
      These exist on my Gentoo box and contain UEFI and BIOS images
      respectively.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Acked-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
      8f204fb4
    • M
      apparmor: Sort paths in blocks in libvirt-qemu profile · 07af71ad
      Michal Privoznik 提交于
      Even though we construct a domain specific profile for each
      domain we start (which should cover domain specific paths), there
      is also another file that is included from the profile and which
      contains domain agnostic paths (e.g. to cover libraries that qemu
      links with). The paths in the file are split into blocks divided
      by comments. Sort the paths in each block individually (ignoring
      case sensitivity).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Acked-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
      07af71ad
    • D
      libxl: support getting and setting parameters for the Credit2 · 849052ec
      Dario Faggioli 提交于
      With Credit2 being Xen default scheduler, it's definitely the case to
      allow Credit2's scheduling parameters to be get and set via libvirt.
      
      This is easy, as Credit and Credit2 have (at least as of now) the very
      same parameters ('weight' and 'cap'). So we can just let credit2 pass
      the scheduler-type check and the same code will work for both.
      Signed-off-by: NDario Faggioli <dfaggioli@suse.com>
      Reviewed-by: NJim Fehlig <jfehlig@suse.com>
      849052ec
    • L
      f0f34056
    • L
      qemu: add wait-unplug to qemu migration status enum · 8a226ddb
      Laine Stump 提交于
      Aside from itinerant error (actually warning) messages due to an
      unrecognized response from qemu, this isn't even necessary - the
      migration proceeds successfully to completion anyway.
      
      (I'm not sure where to see this status reported in the API though - do
      we need to add an extra state, or recognition of a new event somewhere?)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      8a226ddb
    • L
      qemu: allow migration with assigned PCI hostdev if <teaming> is set · 2758f680
      Laine Stump 提交于
      Normally a PCI hostdev can't be migrated, so
      qemuMigrationSrcIsAllowedHostdev() won't permit it. In the case of a a
      hostdev network interface that has <teaming type='transient'/> set,
      QEMU will automatically unplug the device prior to migration, and
      re-plug a corresponding device on the destination. This patch modifies
      qemuMigrationSrcIsAllowedHostdev() to allow domains with those devices
      to be migrated.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      2758f680
    • 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
  3. 29 1月, 2020 26 次提交