RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 857498 - Given a choice of i/f virt-manager defaults to a non-virtualized network bridge
Summary: Given a choice of i/f virt-manager defaults to a non-virtualized network bridge
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager
Version: 6.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: virt-mgr-maint
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2012-09-14 15:39 UTC by James B. Byrne
Modified: 2014-04-10 08:16 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-04-10 08:16:53 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description James B. Byrne 2012-09-14 15:39:01 UTC
Description of problem:
On a kvm hsot system that possesses two bridged network i/fs, br0 and br1, br0 is used for the vnet.  However, guest vms added via virt-manager are assigned eth1(br1) to their virtio nic.  This choice results in an unreachable network error when the new vm is started.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a new kvm host with a single bridged interface (br0/eth0) with a publicly routable IP.

2. Create a new guest with virt-manager accepting defaults and assign IP address from public netblock assigned to br0 during install.  Guest will have a virtio nic on vnet##(br0) and the network will be reachable.

3. Add a second bridge (br1/eth1) on the kvm host with an IP from an non-routable netblock [].

4. Create a second guest vm with virt-manager accepting defaults and assign an IP address from the routable netblock during install.  Guest will have a virtio nic on br1 and the network will be unreachable.
Actual results:
Network is unreachable

Expected results:
Network is reachable.

Additional info:

Comment 2 Geyang Kong 2012-10-15 05:10:37 UTC
I cannot reproduce this bug, list my steps here, if I got something wrong, please tell me what to do

1. Create br0 and make sure I can connect to internet via it.
2. Create a guest with br0 as its NIC.
3. Create br1 by using a NIC cannot access internet.
4. Create the second guest, but choose br0 as its NIC(on my machine, br1 will be its default option at this step)
5. Start the guest and check the network.

Actual result:
1. Network in second guest works well. And I can see its NIC is br0, not br1

My build:

Comment 3 James B. Byrne 2012-10-15 14:13:28 UTC
This may be related or not but I am running into a similar difficulty on a separate 6.3 kvm host, albeit one with only one defined bridge.  Using virt-manager to create a new guest instance, for all instances created after the first, results in an guest that does not have Internet connectivity.  The first guest created has Internet connectivity but no others do. This is after the eth0 configuration is completed and the network is restarted on both guests of course.

In the following example xnet241 was created first and has Internet connectivity, Xnet242 was created later and does not have Internet connectivity. Both were created through virt-manager, although I cannot say with certainty both were created with the same version given the number of updates recently.

Running diff on the /etc/libvirt/qemu/definition files shows this:

diff /etc/libvirt/qemu/xnet241.harte-lyne.ca.xml /etc/libvirt/qemu/xnet242.harte-lyne.ca.xml
<   virsh edit xnet241.harte-lyne.ca
>   virsh edit xnet242.harte-lyne.ca
<   <name>xnet241.harte-lyne.ca</name>
<   <uuid>b0c0c6c5-c464-1dc1-d3a3-f23a6d24e0cd</uuid>
<   <memory unit='KiB'>4194304</memory>
<   <currentMemory unit='KiB'>4194304</currentMemory>
>   <name>xnet242.harte-lyne.ca</name>
>   <uuid>b8117efe-63cb-1bcb-0fb8-3442ea8fed3e</uuid>
>   <memory unit='KiB'>2097152</memory>
>   <currentMemory unit='KiB'>2097152</currentMemory>
<       <source dev='/dev/vg_vhost04/lv_vm_xnet241.harte-lyne.ca_00'/>
>       <source dev='/dev/vg_vhost04/lv_vm_xnet242.harte-lyne.ca_00'/>
.  .   . <block device stuff>
<     <interface type='bridge'>
<       <mac address='52:54:00:6c:35:1a'/>
<       <source bridge='br0'/>
>     <interface type='network'>
>       <mac address='52:54:00:75:f6:52'/>
>       <source network='default'/>
<     <graphics type='vnc' port='-1' autoport='yes' listen=''>
<       <listen type='address' address=''/>
<     </graphics>
>     <graphics type='vnc' port='-1' autoport='yes'/>

So, what would make virt-manager select network for this instance instead of bridge?  This behaviour is consistent with the options shown as available inside virt-manager for when the GUI creates a new instance virt-manager shows "Host device eth0 as not bridged". 

However, these are the contents of /etc/sysconfig/network-scripts/ifcfg-br0 and ifcfg-eth0:

cat /etc/sysconfig/network-scripts/ifcfg-br0
DOMAIN="harte-lyne.ca hamilton.harte-lyne.ca mississauga.harte-lyne.ca"
NAME="System br0 (vhost04)"
[root@vhost04 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
NAME="System eth0 - bridged on br0 (vhost04)"

Manually editing the configuration files of the guests without connectivity to use the bridge corrects the connectivity problem.

virt-manager --version

Comment 4 James B. Byrne 2012-10-15 15:13:42 UTC
I further note on kvm virtual hosts set up earlier that the virt-manager info display for guests shows an NIC 

"Host device vnetxx (Bridge 'brx') <--drop down menu

but on the most recent kvm host I see this instead:

Specify shared device name         <--(drop down menu)
Bridge name: br0                   <--(text box)

And the available shared device names on the later host do not have and choices with (Bridge 'br0') in them.

the virt-manager on both systems show 0.9.0 as their version number but they seem to behave somewhat differently.

Comment 5 Geyang Kong 2012-10-19 08:30:05 UTC
Ennn, OK, I can reproduce this bug now, I noticed your 2nd guest doesn't use network bridge as NIC but using Virtual network 'default' : NAT as its NIC. On my machine, if I configured the eth0 to a bridge, then modify the 1st guest, change the NIC from br0 to Virtual network 'default' : NAT, neither it can visit network, it has nothing related with 1st or 2nd guest.

Comment 7 RHEL Program Management 2014-04-10 08:16:53 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.