Hi,
it's me again, with some problems (again) :-).
I'm working on the dynamic attachment of interfaces to virtual guests.
I'm trying to follow the convention as we discussed (and agreed on) earlier at the meeting. But based on the experience I had with it, I find it a little confusing.
I think we should decouple the physical an virtual world by default and if someone will need to combine them, he should know what he's doing.
Here's an example of current status:
Machine #1: <netmachineconfig> <info hostname="192.168.122.11" libvirt_domain="RHEL6" rootpass="redhat"/> <netdevice hwaddr="52:54:00:2E:D5:A8" network="test_net" phys_id="1" type="eth"/> <netdevice hwaddr="52:54:00:90:23:0c" network="test_net" phys_id="2" type="eth"/> <-- this one is virtual because the MAC doesn't exist </netmachineconfig>
Machine #2: <netmachineconfig> <info hostname="192.168.122.10" libvirt_domain="Fedora16-clone" rootpass="redhat"/> <netdevice hwaddr="52:54:00:91:01:9c" network="test_net" phys_id="1" type="eth"/> </netmachineconfig>
The network="test_net" attribute makes it look like that LNST will somehow take care of connecting all the devices together. But it won't be able to connect virtual devices to physical ones.
I like this solution:
Machine #1: <netmachineconfig> <info hostname="192.168.122.11" libvirt_domain="RHEL6" rootpass="redhat"/> <netdevice hwaddr="52:54:00:2E:D5:A8" phys_id="1" type="eth"/> <netdevice hwaddr="52:54:00:90:23:0c" bridge="virbr0" phys_id="2" type="eth"/> </netmachineconfig>
Machine #2: <netmachineconfig> <info hostname="192.168.122.10" rootpass="redhat"/> <netdevice hwaddr="52:54:00:91:01:9c" phys_id="1" type="eth"/> </netmachineconfig>
Let's drop network completely and add 'bridge' parameter to interfaces that can be dynamically created. It will indicate to what bridge will be the new interface connected to.
In this case, fist machine is virtual, its first interface is virtual, but is marked physical and LNST will assume, that the user did the configuration. The second device will be created dynamically.
The second machine is a bare metal and again, user is responsible for all the configuration.
LNST should care only for interfaces that it actually can control. If there's some device marked physical, we should consider it properly configured by the user and don't touch that. LNST cannot go to lab and swap wires or something ...
I will demonstrate it tomorrow at the meeting.
Radek :)
lnst-developers@lists.fedorahosted.org