On Tue, Mar 9, 2010 at 5:27 AM, Stefan Berger <stefanb@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list