[libvirt-users] How to insert a dummy NIC

[wferi at niif.hu]

Laine Stump <laine at redhat.com> writes:

> On 3/11/19 5:05 AM, wferi at niif.hu wrote:
>
>> 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?
>
> 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.

Understood; thanks for confirming this.

>> 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.

Yes, it's really that old, 1.2.9 from Debian jessie.  Works just fine
for our purposes and very stable in our environment.  We hit several
problems (deadlocks and crashes) with earlier versions before settling
here, so I'm not exactly looking forward to upgrading to 5.0, but
testing will start in the near future.

> Does it matter if the interface is online or not?

No, it doesn't matter.

> 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).

Thanks for this, it looks like a good compromise for after the upgrade.
Those tap devices are still somewhat ugly, but so is specifying qemu
command line options and bus addresses.  And who knows, maybe qemu
eventually implements the null netdev backend mentioned on IRC and I
can have the best possible dummy interfaces for this... appliance.
-- 
Regards,
Feri