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 850611 - Can not start the default network - or create new network
Summary: Can not start the default network - or create new network
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-22 00:58 UTC by Steve Kieu
Modified: 2012-08-23 22:52 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-23 14:50:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Steve Kieu 2012-08-22 00:58:13 UTC 
Description of problem:

Can not start the default network - or create new network
It happened only in one of the server, the other is fine. Using virt-manager and go to the Virtual Networks tab and see the default one is not started. Try to start and get the error message: 

Unable to set bridge virbr0 forward_delay: Read-only file system

Remove the default one and attempted to create new one - when activate the new one, the above error message appear again.

Create a xml file look like this
cat netdefault.xml
<network>
  <name>default</name>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:80:47:06'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
    </dhcp>
  </ip>
</network>

in the host it self and run 
virsh net-create netdefault.xml

Same error appear

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

How reproducible:

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:

Be able to create and activate the network

Additional info:

Kernel:  uname -r
2.6.32-279.5.1.el6.x86_64

cat /proc/cmdline 
ro root=/dev/mapper/vg0-root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=129M@0M rd_LVM_LV=vg0/root  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet biosdevname=0
Comment 1 Steve Kieu 2012-08-22 01:00:48 UTC 
SELINUX=enforcing
SELINUXTYPE=targeted

(but the other one working also have the same)
Comment 3 Steve Kieu 2012-08-22 01:12:31 UTC 
looks like selinux is not the reason, problem still after I ran 
setenforce 0
service libvirtd restart
Comment 4 Laine Stump 2012-08-23 03:52:23 UTC 
Something is wrong with your sysfs (i.e. it is probably mounted read-only) - that error is generated when trying to write to /sys/class/net/virbr0/bridge/forward_delay.

Try the following - as root:

1) brctl addbr testbr # create a bridge device to use for test
2) echo 3000 >/sys/class/net/testbr/bridge/forward_delay
3) cat /sys/class/net/testbr/bridge/forward_delay

All three steps should be successful, and the output of the final command should be "2999".

Please try this out and post your results.
Comment 5 Steve Kieu 2012-08-23 04:51:34 UTC 
Found the reason is ..

RedHat default kernel does not support LXC very well esp. the sysfs - so the problem is that when a containter is started, I mount sysfs as readonly inside the CT but the kernel does not think it is for the new namespace - it applies globally. Thus the host sysfs is re-mounted  readonly.

I will fire another bug report about sysfs here soon if I could not find existing related bug . Using vanilla kernel 3.2.18 the problem disappear.
Comment 6 Laine Stump 2012-08-23 14:50:11 UTC 
You shouldn't do anything manually to get sysfs in the container - libvirt should be taking care of all the details necessary to give you a r/o sysfs in the container while maintaining a writable sysfs for the system.

Since a properly working r/w sysfs is an essential prerequisite for libvirt to setup its networks, I'm closing this bug.
Comment 7 Steve Kieu 2012-08-23 22:52:53 UTC 
I did not manually do anything with sysfs, however I use lxc in parallel - libvirt supprot of lxc is limited so I directly use lxc tool to manage them - and inside CT I need sysfs mounted at /sys. This mount is for the CT only, and should not affect the host sysfs - but appearantly with default RedHat kernel, it is. 
By the way it is a separate bug rather than this one.
Note You need to log in before you can comment on or make changes to this bug.