Virtual devices in recipes

[Radek Pazdera]

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 :)