12:11 p.m.
I just came across this problem while looking for the proper place to
put <ip> info for the host side of <interface type='ethernet'>. I
don't
think there's really anything that can be done about it now, since
everything below has been in place for so long, but maybe it can serve
as a cautionary tale.
Prologue: A week or two ago, I made patches to support <interface
type='ethernet'> in the LXC driver. I did this not because I have a need
for that, but because it seemed like the perfect avenue for
investigating the best way to add IP address and route config to
<interface>, as it is one environment where we have a need *and* the
ability to setup IP info for both the host and guest sides of the
interface. I accomplished this by simply generalizing the existing
<interface type='bridge'> code to not attach the host-side veth device
to a bridge.
This makes all common attributes between type='ethernet' and
type='bridge' consistent, including the configuration of guest-side and
host-side device names, and here we come to the first inconsistency -
the device name for the veth/tap on the host side is in the <target>
element (which I've always been told is supposed to be used for
device-specific info about how the device will be presented on the
*guest* side, but I suppose this is because <interface type='direct'>
uses <source dev='blah'> to provide the name of the physical device that
the macvtap device (named in <target dev='macvblah'/> is attached to).
And I guess because the dev attribute was already in-use in <target> the
much more recently added guest-side name is given in the <guest>
subelement (in LXC at least):
<interface type='ethernet'>
<target dev='hostblah'/> <-- name of veth on host side
<guest dev='guestblah'/> <-- name of veth on guest side
...
Now, this "is what it is". There is no changing it. In particular, the
use of <target dev> for the host-side device name has been in use for so
long and is so deeply ingrained that it's just part of the scenery.
Moving for a minute to the IP address/route info for the guest side is
already configured in the toplevel <ip> and <route> subelements of
<interface>,
<interface type='ethernet'>
<ip address='1.2.3.4' .../>
</interface>
My first thought was to put the <ip> for the host side inside <source>:
<interface type='ethernet'>
<source>
<ip address='1.2.3.5' .../> <-- host side
</source>
<ip address='1.2.3.4' .../> <-- guest side
</interface>
That makes sense to me because it parallels what we do with PCI
addresses for hostdev - the PCI address in <source> tells what the
address is on the host, and the one at the toplevel of <hostdev> tells
what the PCI address will be in the guest. It *doesn't* fit well with
the fact that the device we're setting up is named in <target> though,
so we're already inconsistent, but putting the host-side IP config in
<target> seems like an invitation to mix things up even more in the
future, since <target> is used everywhere else as a place to put stuff
related to what the device looks like in the guest (although... for
<interface>, <target> *is* currently used only for the host-side
tap/veth device name; so maybe we just can define the purpose of
<target> differently in this one case... But I digress).
So I went to the code to add parsing of <ip> inside <source>, and found
that the type-specific data for ethernet has a dev, and that field in
the object is set during parsing from <source dev='blah'/>, *and* that
the openvz driver uses that dev name as the name of the network device
in the *guest*! (even though my understanding of <source> is that it is
supposed to be used for information about the *host* side of any device.
Sigh.) So on openvz, we have this:
<interface type='ethernet'>
<target dev='hostblah'/> <-- name of interface on host side
<source dev='guestblah'/> <-- name of interface on guest side
...
which seems exactly the opposite of what it should be. Note that this
doesn't seem to be documented anywhere except in the few lines in
openvz_driver.c that implement it. (Note that, prior to commit 9a4b705f7
back in 2010, which added support for type='ethernet' in openvz, the
"dev" field was already in the ethernet-specific sub-object of
virDomainNetDef, but it was only used to hold the name of the bridge
that a tap device was attached to when converting from a qemu
commandline to XML (also, as previously stated, for type='direct' it is
used to name the physical device on the host that the macvtap interface
is connected to, i.e. *exactly* the opposite end of the chain). It looks
like the poster of the openvz patch just saw an opportune
existing-but-unused-by-type=ethernet attribute and took advantage, and
it wasn't noticed in review).
I'm actually skeptical that anyone even uses this, since openvz is a
less-used driver, type='ethernet' is less used among interface types,
and even after that it's valid to not provide a name, in which case one
is automatically generated. But there is no way to verify that, so we're
stuck with it. It is true that the LXC version of type='ethernet' was
added only a few days ago, and there hasn't yet been a release, so I
*could* modify it to be consistent with the attribute usage in the
openvz driver. But that would make <interface type='ethernet'> in LXC
inconsistent with <interface type='bridge'> in LXC, which is a much
worse situation. IT seems there is nothing to change. As I said above
"it is what it is".
So why am I writing this message? Partly to just vent frustration (aka
"whine") I suppose :-). Also partly as public testimony that my
seemingly excessive worrying over attribute naming and placement is
justified, and not just OCD. Also, as I said above, as a cautionary tale
that any patch adding *any* XML config knob, or making use of an
existing XML config knob needs extra scrutiny to help minimize such
messes in the future.