Re: How to insert a dummy NIC

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

 



On 3/11/19 5:05 AM, wferi@xxxxxxx 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).

_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users



[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux