1. 10 9月, 2019 7 次提交
    • L
      qemu: support unmanaged macvtap devices with <interface type='ethernet'> · 51d66b92
      Laine Stump 提交于
      Traditionally, macvtap devices are supported using <interface
      type='direct'>, but that type requires specifying a source device name
      and macvtap mode which can't be altered after the initial device
      creation (and may not even be available to the management software
      that's creating the XML config to feed to libvirt).
      
      But the attributes in the <source> are essentially describing how the
      device will be connected to the network, and if libvirt is to be
      supplied with the name of a macvtap device that has already been
      created, that device will also already be connected to the network
      (and the connection can't be changed). Thus it seems more appropriate
      to use type='ethernet', which was created explicitly for this purpose
      - for devices that have already been (or will be) connected to the
      external network by someone/something outside of libvirt. The fact
      that it is a *macv*tap rather than a contentional tap device is just a
      detail.
      
      This patch supports using an existing macvtap device with <interface
      type='ethernet'> by checking the supplied target dev name to see if it
      is a macvtap device and, when this is the case, calling
      virNetDevMacVLanTapOpen() instead of virNetDevTapCreate(). For
      consistency, this is only done when target managed='no'.
      
      Resolves: https://bugzilla.redhat.com/1723367 (partially)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      51d66b92
    • L
      qemu: support unmanaged target tap dev for <interface type='ethernet'> · 7cd0911e
      Laine Stump 提交于
      If managed='no', then the tap device must already exist, and setting
      of MAC address and online status (IFF_UP) is skipped.
      
      NB: we still set IFF_VNET_HDR and IFF_MULTI_QUEUE as appropriate,
      because those bits must be properly set in the TUNSETIFF we use to set
      the tap device name of the handle we've opened - if IFF_VNET_HDR has
      not been set and we set it the request will be honored even when
      running libvirtd unprivileged; if IFF_MULTI_QUEUE is requested to be
      different than how it was created, that will result in an error from
      the kernel. This means that you don't need to pay attention to
      IFF_VNET_HDR when creating the tap devices, but you *do* need to set
      IFF_MULTI_QUEUE if you're going to use multiple queues for your tap
      device.
      
      NB2: /dev/vhost-net normally has permissions 600, so it can't be
      opened by an unprivileged process. This would normally cause a warning
      message when using a virtio net device from an unprivileged
      libvirtd. I've found that setting the permissions for /dev/vhost-net
      permits unprivileged libvirtd to use vhost-net for virtio devices, but
      have no idea what sort of security implications that has. I haven't
      changed libvrit's code to avoid *attempting* to open /dev/vhost-net -
      if you are concerned about the security of opening up permissions of
      /dev/vhost-net (probably a good idea at least until we ask someone who
      knows about the code) then add <driver name='qemu'/> to the interface
      definition and you'll avoid the warning message.
      
      Note that virNetDevTapCreate() is the correct function to call in the
      case of an existing device, because the same ioctl() that creates a
      new tap device will also open an existing tap device.
      
      Resolves: https://bugzilla.redhat.com/1723367 (partially)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      7cd0911e
    • L
      conf: new "managed" attribute for target dev of <interface type='ethernet'> · 77f72a86
      Laine Stump 提交于
      Although <interface type='ethernet'> has always been able to use an
      existing tap device, this is just a coincidence due to the fact that
      the same ioctl is used to create a new tap device or get a handle to
      an existing device.
      
      Even then, once we have the handle to the device, we still insist on
      doing extra setup to it (setting the MAC address and IFF_UP).  That
      *might* be okay if libvirtd is running as a privileged process, but if
      libvirtd is running as an unprivileged user, those attempted
      modifications to the tap device will fail (yes, even if the tap is set
      to be owned by the user running libvirtd). We could avoid this if we
      knew that the device already existed, but as stated above, an existing
      device and new device are both accessed in the same manner, and
      anyway, we need to preserve existing behavior for those who are
      already using pre-existing devices with privileged libvirtd (and
      allowing/expecting libvirt to configure the pre-existing device).
      
      In order to cleanly support the idea of using a pre-existing and
      pre-configured tap device, this patch introduces a new optional
      attribute "managed" for the interface <target> element. This
      attribute is only valid for <interface type='ethernet'> (since all
      other interface types have mandatory config that doesn't apply in the
      case where we expect the tap device to be setup before we
      get it). The syntax would look something like this:
      
         <interface type='ethernet'>
            <target dev='mytap0' managed='no'/>
            ...
         </interface>
      
      This patch just adds managed to the grammar and parser for <target>,
      but has no functionality behind it.
      
      (NB: when managed='no' (the default when not specified is 'yes'), the
      target dev is always a name explicitly provided, so we don't
      auto-remove it from the config just because it starts with "vnet"
      (VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the
      same pattern of names that libvirt itself uses when it automatically
      creates the tap devices.)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      77f72a86
    • L
      conf: use virXMLFormatElement for interface <target> · 33d02dfc
      Laine Stump 提交于
      This will simplify addition of another attribute to the <target> element
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      33d02dfc
    • L
      qemu: reorganize qemuInterfaceEthernetConnect() · 3c049fad
      Laine Stump 提交于
      This just moves around a few things in qemuInterfaceConnect() with no
      functional difference (except that a few failures that would have
      previously resulted in a "success" audit log will now properly produce
      a "fail" audit). The change is so that adding support for unmanaged
      tap/macvtap devices will be more easily reviewable.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      3c049fad
    • L
      util: make a couple virNetDevMacVlan*() functions public · 3d21ff72
      Laine Stump 提交于
      In virNetDevMacVLanOpen(), The "retries" arg has been removed and the
      value hardcoded as 10, since previously the function was only called
      from one place, so it was always 10.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      3d21ff72
    • L
      util: new function virNetDevMacVLanIsMacvtap() · 1b46566e
      Laine Stump 提交于
      This function returns T if the given name is a macvtap device. This is
      determined by 1) getting the ifindex of the device with that name (if
      there is one), and 2) checking for existence of /dev/tapXX, where "XX"
      is the ifindex learned in (1).
      
      It's also possible to learn this by getting a netlink dump of the
      interface and parsing through it to look for some attributes, but that
      is complicated to figure out, takes longer to execute, and I'm lazy.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      1b46566e
  2. 09 9月, 2019 15 次提交
  3. 07 9月, 2019 3 次提交
  4. 06 9月, 2019 15 次提交