You might look in /sys/devices/virtual/net, the code traverses each device listed here (each directory), looks for a file called 'bridge', and adds it to a list of bridges. Then it iterates through that list and sees if the name of the bridge matches the KVM traffic label for public, guest traffic. If it does, it looks up the physical device enslaved to that bridge and keeps track of it in the _pifs variable. So first look at the info there and make sure it's populated correctly on your system (both the KVM traffic label and the bridge files/names exist in that location).
Now, how it translates a bridge to a physical device also needs to be looked at. It opens /sys/devices/virtual/net/$bridgename/brif directory, iterates through the files, and looks for one starting with eth, bond, vlan, em, or p*p*. The brif directory generally only has the uplink device and vnet devices (the vm interfaces). So look around your system and see if anything doesn't look right according to that. If the brif directory looks good, then I wonder if you have no traffic labels set and the default detection isn't working. On Fri, Sep 6, 2013 at 3:36 PM, Edison Su <edison...@citrix.com> wrote: > Is there a bridge created on brondg on your kvm host? > The current kvm code will look for all the bridge devices on your kvm host > first, then find out its corresponding physical nic device. > >> -----Original Message----- >> From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com] >> Sent: Friday, September 06, 2013 2:19 PM >> To: dev@cloudstack.apache.org >> Subject: Re: [ACS42] KVM upgrade path to 4.2 >> >> Question for you guys, >> >> I updated the schema on my 4.1.1 cloud. For the most part it works, but >> some hosts that I've updated now fail to deploy VMs do to the following >> error: >> >> -- Instead of creating a guest bridge called 'brbondg-1200' it tries to >> create >> 'br-1200' as if it can not detect my interface names. >> >> Any thoughts? >> >> ----- Original Message ----- >> From: "Prasanna Santhanam" <t...@apache.org> >> To: dev@cloudstack.apache.org >> Sent: Friday, August 30, 2013 9:51:53 AM >> Subject: Re: [ACS42] KVM upgrade path to 4.2 >> >> Hi Edison, >> >> I've just added these steps to the doc bug that was linked to the it at >> CLOUDSTACK-4550 >> >> >> On Fri, Aug 30, 2013 at 12:04:51AM +0000, Edison Su wrote: >> > There is a bug related to KVM upgrade: CLOUDSTACK-4405. The main issue >> is related to guest network bridge name schema is changed, thus migrate vm, >> create new vm will have problem after upgraded to 4.2. >> > If you are using basic network, then don't need to do the following steps. >> > The proposed upgrade paths are: >> > 1. Stick to old network name in 4.2. You can set >> > "network.bridge.name.schema=3.0" in >> > /etc/cloudstack/agent/agent.properties >> > 2. Upgrade to new network name schema, need to do the following steps: >> > a. Install 4.2 cloudstack agent on each kvm host >> > b. Run "cloudstack-agent-upgrade". This script will upgrade all the >> existing bridge name to new bridge name. >> > c. install a libvirt hook: >> > c1. mkdir /etc/libvirt/hooks >> > c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook >> /etc/libvirt/hooks/qemu >> > c3. chmod +x /etc/libvirt/hooks/qemu >> > c4. service libvirtd restart >> > c5. service cloudstack-agent restart The potential issues >> > if you are using above upgrade path 2: >> > 1. If you are using multiple physical bridges, other than the one >> > specified in >> "guest.network.device" in /etc/cloudstack/agent/agent.properties, then the >> vm live migration may have problem. >> > 2. Advanced zone with security group, wont' work. >> > 3. may have old iptables rules left on kvm host, it shouldn't impact guest >> connectivity though. >> >> -- >> Prasanna., >> >> ------------------------ >> Powered by BigRock.com >
