libvirt integration XMLs discussion
Hi,
I'm trying to design some new options that will be needed in
LNST recipes for the libvirt integration. Basically, we need to
reflect these new things:
1. Virtual machines - How to mark a virtual machine?
The first point could be easily achievable through one
additional parameter to the <info> tag in netmachineconfig:
<info hostname="10.20.1.5" libvirt_domain="Fedora16"
rootpass="foobar" />
If libvirt_domain is set, the machine is virtual.
2. Detecting/creating controller interface
This could depend on a presence of a hostname. We could either
use existing controller interface set up manually (in case
hostname is present) or let LNST create it's own.
3. Detecting/creating test interfaces
As far as I know, there's no direct way of listing network
interfaces present on a libvirt domain through virsh. Maybe
it's possible to parse it out from the XML dump, but I don't
know if that contains also dynamically attached ones.
In my opinion it would make things easier to mark devices that
will be temporarily created. For instance:
<netdevice id="1" type="eth" phys_id="1"
dynamic="true"
hwaddr="52:54:00:2E:D5:A8"/>
4. Virtual networks / connection points
The last thing necessary is to define connections between
the interfaces to form a network topology.
This is complicated by the fact, that when attaching a device
through virsh attach-interface, you need to specify the libvirt
network to which the device will be connected. And the virtual
network or a bridge must already exist at that time.
There's a couple of options here. We could define "connections"
before we start to define machines:
<connections>
<connection name="abc" type="bridge|direct" />
</connections>
And let machine connect to these connections. Direct connection
could be done by the new kernel driver, bridge would use the
libvirt's virtual networks. Machines would refer to them like
this:
<netdevice id="1" type="eth" phys_id="1"
dynamic="true"
connection="abc" />
This seems kind of straight-forward to me. The other approach
doesn't work with named connections, it forms the connection
relation directly. For instance:
<connections>
<connection source_machine="1" source_interface="1"
target_machine="2" target_interface="1" />
</connections>
This would be limited to direct connections only (which isn't
that much of a problem). It would also have to be placed before
the machine configs, so controller can determine what bridges
have to exist during the device attaching, which is a little
strange.
What do you think about this? Do you see some better way? I might
have missed something ...
Radek