[libvirt] [RFC][PATCH v2 0/2] Dynamic backend setup for macvtap interfaces

[Ed Swierk]

On Tue, Mar 9, 2010 at 5:27 AM, Stefan Berger <stefanb at us.ibm.com> wrote:
> The problem I guess is that the underlying interface can disappear at any
> time due to hotplug leaving you with a race condition at other times as well
> until a watcher thread detects the change and can act, no?

Right. I would point out that the problem isn't limited to
hot-pluggable hardware, though; host vlan and bridge interfaces can
come and go as well. These days, tools like NetworkManager make it
easy for users to reconfigure the network on the fly (especially on
mobile systems) and it's up to applications to deal with such changes.

> What do you pass to Qemu command line? Currently we pass a file descriptor
> of the tap interface...

Currently libvirt passes two options for each interface: -net
nic,model=e1000,vlan=1 creates the virtual NIC, and -net
tap,fd=42,vlan=1 connects it to a tap interface on the host. If you
omit the -net tap option, qemu creates the virtual NIC but leaves it
disconnected. (The option syntax keeps changing but it's the same idea
with -device and -netdev). You can use the getfd and host_net_add
monitor commands to connect the NIC to a backend once qemu is running.

> How do you handle the macvtap description in the VM configuration? Currently
> we have the 'direct' interface description where the link device is written
> into the domain description:
>
>  <devices>
>    <interface type='direct'/>
>    ...
>    <interface type='direct'>
>      <source dev='eth0' mode='vepa'/>
>    </interface>
>  </devices>
>
> http://libvirt.org/formatdomain.html#elementsNICSDirect
>
> Are you reflecting the change to 'eth0' also in case the hotplugged device
> was to appear under another name?

> So currently you would have to attach and detach the direct device. Now in
> your implementation a host unplug would automatically cause the macvtap to
> get unplugged and if a host interface appears it would automatically
> recreate a macvtap linking it to this host interface? Under what conditions
> does this work? Does the new interface have to have the same name? I
> wondering, because some scripts I believe check for the MAC address of the
> device and if it doesn't match the one expected for eth0, it may appear as
> eth1. How are cases handled where I would like it to reconnect to vlan 100
> of the newly connected host interface but I probably have to run some
> command to first create that vlan 100 interface?

I am assuming that the host interface you want to connect to always
keeps the same name.

So if you define the interface with source dev='eth0' then the
hot-plugged NIC has to reappear as eth0 to get libvirt to reconnect it
to the virtual NIC. Similarly if you define the interface with source
dev='vlan0' then however you change the vlan configuration, you need
to call the interface vlan0 to get it reconnected (so this is probably
a bad motivating example; a more descriptive name like "vmvlan" would
be better than "vlan0").

To handle changing the host interface name, we'd want to use some
other property to identify the host interface (perhaps MAC address) or
perhaps add a layer of indirection to the configuration model
(something like the <network> definition you originally proposed). But
I view this issue as complementary to my proposal; I'm deliberately
focusing on just the minimum required to handle reconnecting macvtap
interfaces.

> I suppose the backend setup code is provided and not some external script
> that the user can run to for example have the vlan 100 interface created on
> host hotplug.

I am assuming that the host interface you want to connect to is
created by something other than libvirt (e.g. udev, NetworkManager,
scripts, etc.). Again, all I'm concerned with at the moment is
providing a way for libvirt to reconnect the host interface to the
virtual NIC when it appears.

--Ed