Bug 850611 - Can not start the default network - or create new network
Can not start the default network - or create new network
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2012-08-21 20:58 EDT by Steve Kieu
Modified: 2012-08-23 18:52 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-23 10:50:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Kieu 2012-08-21 20:58:13 EDT
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
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:80:47:06'/>
  <ip address='' netmask=''>
      <range start='' end='' />

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:
Actual results:

Expected results:

Be able to create and activate the network

Additional info:

Kernel:  uname -r

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-21 21:00:48 EDT

(but the other one working also have the same)
Comment 3 Steve Kieu 2012-08-21 21:12:31 EDT
looks like selinux is not the reason, problem still after I ran 
setenforce 0
service libvirtd restart
Comment 4 Laine Stump 2012-08-22 23:52:23 EDT
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 00:51:34 EDT
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 10:50:11 EDT
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 18:52:53 EDT
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.