Re: [libvirt] [RFC][PATCH v2 0/2] Dynamic backend setup for macvtap interfaces
On Tue, Mar 9, 2010 at 5:27 AM, Stefan Berger <stefanb(a)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