[libvirt] configuring a disconnected <interface>

[Laine Stump]

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.