Re: [PATCH 5/9] conf: new "managed" attribute for target dev of <interface type='ethernet'>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 27, 2019 at 09:46:35PM -0400, Laine Stump wrote:
> 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: Laine Stump <laine@xxxxxxxxxx>
> ---
>  docs/formatdomain.html.in                     | 48 +++++++++++++----
>  docs/schemas/domaincommon.rng                 |  5 ++
>  src/conf/domain_conf.c                        | 51 +++++++++++++++----
>  src/conf/domain_conf.h                        |  1 +
>  .../net-eth-unmanaged-tap.xml                 | 35 +++++++++++++
>  .../net-eth-unmanaged-tap.xml                 | 40 +++++++++++++++
>  tests/qemuxml2xmltest.c                       |  1 +
>  7 files changed, 160 insertions(+), 21 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/net-eth-unmanaged-tap.xml
>  create mode 100644 tests/qemuxml2xmloutdata/net-eth-unmanaged-tap.xml

Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux