[libvirt-users] How to insert a dummy NIC

[Laine Stump]

On 3/11/19 5:05 AM, wferi at niif.hu wrote:
> Hi,
> 
> I have to host (with KVM) an appliance which does not use its second and
> third NIC.  They have to be present in the guest, but they'd better stay
> totally disconnected from anything in the host.  "Second" and "third"
> apparently means bus order.  Let's consider virtio devices only.  I think
> the best technical solution is adding -device virtio-net-pci,addr=0x3 and
> similar options to the KVM command line, without any corresponding
> -netdev options (better ideas welcome).  QEMU emits "Warning: nic
> virtio-net-pci.2 has no peer" messages, but that's expected.  I can even
> do this much using the <qemu:commandline> element, but libvirt assigns
> the 0x3 address to other virtio devices, leading to collision.  Is there
> a way to "reserve" a bus address for such manually added devices without
> assigning explicit addresses to all other devices in the configuration?


I think qemu is going to be upset by anything that has no backend to the 
emulated device.

As for libvirt reserving addresses that (from its point of view are 
otherwise unused - no, there's no way to do that; if a PCI address isn't 
used by a device in the libvirt config, it is considered fair game for 
assigning to a new device, and we've never considered such an option.

> 
> Things I also tried (and found inadequate):
> 
> * Using "generic ethernet connection" for the dummy NICs.  Close, but
>    requires extra permissions for accessing /dev/net/tun, and technically
>    feels a little inferior to using a peerless network device like above.

What version is your libvirt? extra permissions for qemu using 
type='ethernet' (beyond what's required for a type='network' or 
type='bridge') have not been required since libvirt-1.3.3, released on 
April 6, 2016 (this was the result of commit 9c17d665f). If your libvirt 
is that old, you *really* should update to something newer. If it's 
*not* that old, then you're just working with out of date documentation.


> 
> * TCP tunnel server.  Even more inferior, does not require extra
>    permissions but leaves even looser ends (listening sockets).  Also, the
>    RelaxNG grammal does not let me specify a model for this interface
>    type, so maintaining bus order with respect to the virtio interfaces is
>    impossible.  A grammar bug?
> 
> * Using a dummy VLAN in the bridge.  This is what I temporarily settled
>    for, but this requires global agreement and still technically inferior,
>    so I'd like to move away.
> 
> * A <network> without forwarding.  Still inferior, and also requires
>    configuration sharing across the host cluster.
> 

Does it matter if the interface is online or not?

I would recommend using an expansion of this:

    <interface type='ethernet'>
       <link state='down'/>
       ...

Your guest will have a network device in the desired position, qemu will 
be satisfied that the device has a backend, libvirt will know there is a 
device there so it won't give the PCI address away to somebody else, and 
the tap device will be IFF_DOWN, so there will be no possibility of 
network traffic accidentally leaking into the host (which would already 
be nearly impossible unless someone separately assigned an IP address to 
the host side of the tap device).