Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Running Ubuntu 12.04 we have 12 interfaces on the hypervisor which we want to expose in each vm. When we use only interface elements in the xml, we get the interfaces but we can't predict/control whether eth0 in the VM connects to eth0 on the HV. We've tried using the PCI bus numbering as seen in lspci to control it, but that doesn't seem to work.

Should we be defining our networks in a separate element in a network xml on the HV, or how should we configure?

sample from current xml for vm:

<interface type='hostdev'>
  <source dev='eth3' mode='vepa'>
    <address type='pci' domain='0x0000' bus='0x16' slot='0x10' function='0x1'/>
  </source>
  <target dev='macvtap0'/>     
</interface>
<interface type='bridge'>
  <source bridge='br4'/>
  <target dev='vnet0'/>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

The regular means to consistent mapping of NICs in Linux is by specifying the MAC address in the NIC definitions, or by using udev's 70-persistent-net-rules

If you define a MAC in the domXML (using bridged or macvtap passthrough modes), you control that MAC and can define it in the VM. If you are using vepa (you should have a switch that supports 802.1Qbg) then the MAC of the attached NIC should propagate into the VM and you can specify on which NIC in the VM the interface will reside (using udev or NIC configs or both)

share|improve this answer
    
Thanks!We are using pass-through vepa, but those eth devices line up nicely once we specifiy the PCI bus numbers. Its the bridged ethernet interfaces on the conventional PHYs that ren;t lining up. –  John P. Fisher Dec 7 '12 at 16:43
    
oops not used to stack exchange.... ( I should mention we are the OEM, designing a generic default plan) we are planning on random MAC addresses because we need up to 192 VMs in each box, theoretically more, and they should be transferable from HV to HV. Is there a good way to manage MAC addresses in a pool? I don't know of one. –  John P. Fisher Dec 7 '12 at 16:44
    
When you set a VM up, the MAC is written in the interface section of domxml, so it persists when the VM migrates between hosts. BTW, if you are the OEM for vepa equipment, and you want to play nice with libvirt, you should be talking to the libvirt developers in the #virt channel on OFTC IRC servers, and probably start testing with Fedora, not Ubuntu –  dyasny Dec 7 '12 at 18:18
    
So let me try to understand, randomizing the MAC addresses is in effect a global pool already. If the rules for ordering the eth devices in the VM are in the VM ( udev), then it will pass to another ( suitable) HV without trouble. ......tested: using the udev/rules file I can re-order the interfaces based on known MAC address. So....how to automate the creation of VMs based on a generic disk image and generic xml file. We'd have to wrap something around the virsh create process to change the udev/rules file once the MACs are created, or maybe use virsh commands. Thanks. –  John P. Fisher Dec 7 '12 at 20:00
    
so you're after something like sysprep for Linux? RHEL has sys-unconfig for that... Maybe if you describe what it is exactly you are trying to do, and not feed me spoonfuls of information, I'd be able to help. BTW, talking about pools, this is an approach I took when I was writing the Cisco VM-FEX integration for oVirt/RHEV, I wonder if this approach is right for you as well? Qbh and Qbg are pretty much the same after all... Take a look: ovirt.org/VDSM-Hooks/vmfex –  dyasny Dec 7 '12 at 21:03
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.