On 06/20/2013 07:42 AM, Dan Kenigsberg wrote: > Hi List, > > Like most of us, I've bought my actual computer with an Ethernet > interface card, that I can connect to a wall jack at will. It's quite > easy to disconnect the Ethernet cable from the wall, as well. > > I would like to expose this behavior to virtual computers, too. Via > libvirt, of course. That's useful, since an admin may need to disconnect > a running VM from a network temporarily, without resorting to > hot-unplugging its nic.
Well, there is already '<link state="up|down"/>', but of course that still requires that the tap be connected to *something*, it's just made to appear to the guest that it's not connected (by using qemu's set_link command), and I think what you really want is something to leave an interface truly "plugged into nothing". > > How should the domxml represent this situation? An interface that is > connected to a specific LAN1 bridge is > > <interface type='bridge'> > <source bridge='LAN1'> > <target dev='vnet1'/> > <model type='virtio'/> > </interface> > > Would the following make sense for an interface with no bridge at the > source? > > <interface type='bridge'> > <source/> > <target dev='vnet1'/> > <model type='virtio'/> > </interface> Since I think it would be a bad idea for "lack of <source>" to indicate connection to some default bridge my opinion is that simple omission of <source> should be enough to indicate a disconnected tap. > > And how about the recommended config for <interface>s, which is > type='network'? Would it make sense to predefine > > <network> > <name>null-bridge-network</name> > <forward mode='bridge'> > <bridge/> > </network> > > so that > > <interface type='network'> > <source network='null-bridge-network'/> > </interface> > > means "keep this interface dangling out there"? Or just allow no <source> again. Hmm. networks do create a problem (which is really just an extension of the idea of moving a running interface from one network to another) - all this discussion is assuming that the networks are implemented in a fashion that uses a tap device to connect the qemu process to the rest of the network. However, there are at least two other types of networks: 1) those that use a macvtap device, 2) those that use PCI passthrough device assignment. In both of those cases it isn't possible to have an interface that is moved from one network to another, nor to completely disconnect it while it is still running; in the case of PCI passthrough, the "connection" is in the actual hardware, and in the case of macvtap the physical device used for connection can only be specified when the macvtap device is created, and can't be modified later (without destroying the macvtap device and creating a new one). At any rate, I guess attempts to do that will just have to return a VIR_ERR_CONFIG_UNSUPPORTED. To summarize all that: 1) I think we can just use an omission of the <source> to indicate that an interface shouldn't be connected to anything, both for type='bridge' and type='network'. 2) If the interface type is anything else, omission of <source> will lead to VIR_ERR_CONFIG_UNSUPPORTED. 3) For type='network', omission of <source> will imply that any eventual connection will be via a tap interface, so a later attempt to modify <source> to connect to a macvtap or pci passthrough network will again give VIR_ERR_CONFIG_UNSUPPORTED. 4) assuming neither (2) nor (3) is encountered, this will lead to a tap device being created and given to qemu, but no connection being made. libvirt is already able to change the bridge that a tap device is attached to, so it shouldn't be difficult to update that code to accept "nothing" as an option. 5) I don't think we need to support "<bridge/>" in networks. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
