Bug 184393

I didn't realize that the xen kernels had changed back to the old style naming
convention and yum wasn't updating them, so I just installed the latest from
work and will reboot and test when I get home to see if this is still a problem
on x86/smp box.

Thank you,

Reproduced on my test box with a fresh rawhide install.  Going to look into it.

Fixed.  Caused by selinux policy fun. 

It seems as though this bug has reserfaced.  Applied updates on fc5 today and ...

Error: Error creating domain: I need 385 MiB, but dom0_min_mem is 256 and
shrinking to 256 MiB would leave only 739 MiB free.

I too have the same problem:

# cat /proc/version
Linux version 2.6.16-1.2080_FC5xen0 (bhcompile.redhat.com) (gcc
version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Tue Mar 28 04:13:51 EST 2006
# sestatus -v
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 20
Policy from config file:        targeted

Process contexts:
Current context:                user_u:system_r:unconfined_t
Init context:                   system_u:system_r:init_t
/sbin/mingetty                  system_u:system_r:getty_t
/usr/sbin/sshd                  system_u:system_r:unconfined_t:SystemLow-SystemH igh

File contexts:
Controlling term:               user_u:object_r:devpts_t
/etc/passwd                     system_u:object_r:etc_t
/etc/shadow                     system_u:object_r:etc_t
/bin/bash                       system_u:object_r:shell_exec_t
/bin/login                      system_u:object_r:login_exec_t
/bin/sh                         system_u:object_r:bin_t -> system_u:object_r:she
ll_exec_t
/sbin/agetty                    system_u:object_r:getty_exec_t
/sbin/init                      system_u:object_r:init_exec_t
/sbin/mingetty                  system_u:object_r:getty_exec_t
/usr/sbin/sshd                  system_u:object_r:sshd_exec_t
/lib/libc.so.6                  system_u:object_r:lib_t -> system_u:object_r:lib _t
/lib/ld-linux.so.2              system_u:object_r:lib_t -> system_u:object_r:ld_
so_t
# rpm -qa|egrep -i "xen|selinux"
libselinux-python-1.30-1.fc5
selinux-policy-targeted-2.2.29-3.fc5
kernel-xen0-2.6.16-1.2080_FC5
xen-3.0.1-4
libselinux-devel-1.30-1.fc5
libselinux-1.30-1.fc5
selinux-policy-2.2.29-3.fc5

Could this bug be re-opened please?

Thanks in advance.

I tried enabling the SELinux bool, 'xend_disable_trans' - didn't help though:

Starting install...
Using config file "/etc/xen/vm1".
Error: Error creating domain: I need 513 MiB, but dom0_min_mem is 256 and
shrinking to 256 MiB would leave only 2263 MiB free.
If your install has exited, you can restart your guest by running
'xm create -c vm1'.  Otherwise, you can reconnect to the console
by running 'xm console vm1'

<aol> Me too! </aol>

Same FC5 as above.  Is there a selinux bool that can be switched for xen that'll
fix this temporarily?

 I've recently hit this, it used to work (last week) but this week I just get:

# free
             total       used       free     shared    buffers     cached
Mem:        717164     280624     436540          0      26460      95220
Swap:      1572856        132    1572724
Total:     2290020     280756    2009264
# getenforce
Permissive
# xm create -c fc-rawhide
Using config file "/etc/xen/fc-rawhide".
Going to boot Fedora Core (2.6.15-1.2054_FC5xenU)
  kernel: /vmlinuz-2.6.15-1.2054_FC5xenU
  initrd: /initrd-2.6.15-1.2054_FC5xenU.img
Error: Error creating domain: I need 257 MiB, but dom0_min_mem is 256 and
shrinking to 256 MiB would leave only 491 MiB free.

...as you can see it isn't an SELinux policy issue, as SELinux is not enforcing.

It may not be a policy issue, but the error doesn't occur when selinux=disabled
is set or the kernel is booted with selinux=0.

I upgraded my xen kernel to hopefully fix bug# 181856 ("BUG: soft lockup 
detected on CPU#0!").  My current xen0 kernel:

Linux version 2.6.16-1.2096_FC5xen0 (bhcompile.redhat.com) 
(gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Wed Apr 19 05:38:34 EDT 
2006

I manually upgraded the xenU kernel to release 2096 via lomount to no avail.  
pygrub shows:

Going to boot Fedora Core (2.6.16-1.2096_FC5xenU)
  kernel: /vmlinuz-2.6.16-1.2096_FC5xenU
  initrd: /initrd-2.6.16-1.2096_FC5xenU.img
Error: Error creating domain: I need 2049 MiB, but dom0_min_mem is 256 and 
shrinking to 256 MiB would leave only 17927 MiB free.

Used to work fine, definitely not a lack of memory problem...  the box 
recently received a bunch of updated rpms via yum update which broke xen.  I'm 
off to try booting with selinux=0 per above suggestions.

xend.log:

Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/xen/web/SrvBase.py", line 85, in 
perform
    return op_method(op, req)
  File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", 
line 82, in op_create
    raise XendError("Error creating domain: " + str(ex))
XendError: Error creating domain: I need 2049 MiB, but dom0_min_mem is 256 and 
shrinking to 256 MiB would leave only 17927 MiB free.
[2006-04-20 20:30:45 xend.XendDomainInfo] DEBUG (XendDomainInfo:177) 
XendDomainInfo.create(['vm', ['name', 'omitted'], ['memory', '2048'], 
['on_reboot', 'restart'], ['on_crash', 'restart'], ['vcpus', '1'], 
['bootloader', '/usr/bin/pygrub'], ['image', ['linux', 
['kernel', '/var/lib/xen/vmlinuz.c5rcf_'], 
['ramdisk', '/var/lib/xen/initrd.kqa0AP'], ['args', 'ro 
root=/dev/VolGroup00/LogVol00 rhgb quiet'], ['vcpus', '1']]], ['device', 
['vbd', ['uname', 'file:/some/path/omitted'], ['dev', 'xvda'], 
['mode', 'w']]], ['device', ['vif', ['mac', '00:16:3e:12:fa:a4']]]])
[2006-04-20 20:30:45 xend.XendDomainInfo] DEBUG (XendDomainInfo:283) 
parseConfig: config is ['vm', ['name', 'omitted'], ['memory', '2048'], 
['on_reboot', 'restart'], ['on_crash', 'restart'], ['vcpus', '1'], 
['bootloader', '/usr/bin/pygrub'], ['image', ['linux', 
['kernel', '/var/lib/xen/vmlinuz.c5rcf_'], 
['ramdisk', '/var/lib/xen/initrd.kqa0AP'], ['args', 'ro 
root=/dev/VolGroup00/LogVol00 rhgb quiet'], ['vcpus', '1']]], ['device', 
['vbd', ['uname', 'file:/some/path/omitted'], ['dev', 'xvda'], 
['mode', 'w']]], ['device', ['vif', ['mac', '00:16:3e:12:fa:a4']]]]
[2006-04-20 20:30:45 xend.XendDomainInfo] DEBUG (XendDomainInfo:379) 
parseConfig: result is {'ssidref': None, 'uuid': 
None, 'on_crash': 'restart', 'on_reboot': 'restart', 'image': ['linux', 
['kernel', '/var/lib/xen/vmlinuz.c5rcf_'], 
['ramdisk', '/var/lib/xen/initrd.kqa0AP'], ['args', 'ro 
root=/dev/VolGroup00/LogVol00 rhgb quiet'], ['vcpus', '1']], 'on_poweroff': 
None, 'cpus': None, 'name': 'omitted', 'backend': [], 'vcpus': 
1, 'cpu_weight': None, 'vcpu_avail': None, 'memory': 2048, 'device': [('vbd', 
['vbd', ['uname', 'file:/some/path/omitted'], ['dev', 'xvda'], 
['mode', 'w']]), ('vif', ['vif', 
['mac', '00:16:3e:12:fa:a4']])], 'bootloader': '/usr/bin/pygrub', 'cpu': 
None, 'maxmem': None}
[2006-04-20 20:30:45 xend.XendDomainInfo] DEBUG (XendDomainInfo:1142) 
XendDomainInfo.construct: None 0
[2006-04-20 20:30:45 xend.XendDomainInfo] DEBUG (XendDomainInfo:1174) 
XendDomainInfo.initDomain: 14 1.0
[2006-04-20 20:30:45 xend] DEBUG (balloon:88) Balloon: free 133; need 2049.
[2006-04-20 20:30:45 xend] DEBUG (balloon:97) Balloon: setting dom0 target to 
16134.
[2006-04-20 20:30:45 xend.XendDomainInfo] DEBUG (XendDomainInfo:923) Setting 
memory target of domain Domain-0 (0) to 16134 MiB.
[2006-04-20 20:30:50 xend.XendDomainInfo] ERROR (XendDomainInfo:189) Domain 
construction failed
Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 
182, in create
    vm.initDomain()
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 
1203, in initDomain
    balloon.free(m + fudge)
  File "/usr/lib64/python2.4/site-packages/xen/xend/balloon.py", line 114, in 
free
    raise VmError(
VmError: I need 2049 MiB, but dom0_min_mem is 256 and shrinking to 256 MiB 
would leave only 17927 MiB free.
[2006-04-20 20:30:50 xend.XendDomainInfo] DEBUG (XendDomainInfo:1290) 
XendDomainInfo.destroy: domid=14
[2006-04-20 20:30:50 xend.XendDomainInfo] DEBUG (XendDomainInfo:1298) 
XendDomainInfo.destroyDomain(14)
[2006-04-20 20:30:50 xend] ERROR (SrvBase:87) Request create failed.
Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/xen/web/SrvBase.py", line 85, in 
perform
    return op_method(op, req)
  File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", 
line 82, in op_create
    raise XendError("Error creating domain: " + str(ex))
XendError: Error creating domain: I need 2049 MiB, but dom0_min_mem is 256 and 
shrinking to 256 MiB would leave only 17927 MiB free.
[root@d6850 log]#

Checked the upstream forums, nothing there.  Hope the above helps.

#xm create -c daDevel
Using config file "/etc/xen/daDevel".
Going to boot Fedora Core (2.6.16-1.2080_FC5xenU)
  kernel: /vmlinuz-2.6.16-1.2080_FC5xenU
  initrd: /initrd-2.6.16-1.2080_FC5xenU.img
Error: Error creating domain: I need 257 MiB, but dom0_min_mem is 256 and
shrinking to 256 MiB would leave only 740 MiB free.

#xm create -c daDevel
Using config file "/etc/xen/daDevel".
Going to boot Fedora Core (2.6.16-1.2096_FC5xenU)
  kernel: /vmlinuz-2.6.16-1.2096_FC5xenU
  initrd: /initrd-2.6.16-1.2096_FC5xenU.img
Error: Error creating domain: I need 257 MiB, but dom0_min_mem is 256 and
shrinking to 256 MiB would leave only 740 MiB free.

# rpm -qa|egrep -i "xen|selinux"
libselinux-1.30-1.fc5
xen-3.0.1-4
selinux-doc-1.25.2-1
kernel-xen0-devel-2.6.16-1.2096_FC5
libselinux-1.30-1.fc5
libselinux-python-1.30-1.fc5
kernel-xen0-2.6.16-1.2080_FC5
selinux-policy-2.2.29-3.fc5
selinux-policy-targeted-2.2.29-3.fc5
kernel-xen0-devel-2.6.16-1.2080_FC5
kernel-xen0-2.6.16-1.2096_FC5

#setenforce 0

setenforce does not fix the issue. I will retry with selinux=0.

Adding selinux=0 to the module line in grub does fix the issue. However,
disabling selinux is not the solution for me. Note: A relabel is required if you
add selinux=0 and then remove it. The relabel took about 15 minutes for me.

title Fedora Core (2.6.16-1.2096_FC5xen0)
        root (hd0,0)
        kernel /xen.gz-2.6.16-1.2096_FC5
        module /vmlinuz-2.6.16-1.2096_FC5xen0 ro root=/dev/VolGroup00/LogVol02
rhgb quiet selinux=0
        module /initrd-2.6.16-1.2096_FC5xen0.img

title Fedora Core (2.6.16-1.2080_FC5xen0)
        root (hd0,0)
        kernel /xen.gz-2.6.16-1.2080_FC5
        module /vmlinuz-2.6.16-1.2080_FC5xen0 ro root=/dev/VolGroup00/LogVol02
rhgb quiet selinux=0
        module /initrd-2.6.16-1.2080_FC5xen0.img

Another way to make it work (until I run into a number of other SELinux related
problems is) is by restricting the amount of memory dom0 is allowed to use, by
adding the kernel parameter: dom0_mem to you grub.conf.

title Fedora Core (2.6.16-1.2096_FC5xen0)
        root (hd0,0)
        kernel /xen.gz-2.6.16-1.2096_FC5
        module /vmlinuz-2.6.16-1.2096_FC5xen0 ro root=/dev/VolGroup00/LogVol02
rhgb quiet dom0_mem=512M
        module /initrd-2.6.16-1.2096_FC5xen0.img

title Fedora Core (2.6.16-1.2080_FC5xen0)
        root (hd0,0)
        kernel /xen.gz-2.6.16-1.2080_FC5
        module /vmlinuz-2.6.16-1.2080_FC5xen0 ro root=/dev/VolGroup00/LogVol02
rhgb quiet dom0_mem=512M
        module /initrd-2.6.16-1.2080_FC5xen0.img

 Dropping dom0_mem=512M onto the kernel cmd line didn't help me, however
downgrading selinux-policy to the GA versions:

selinux-policy-2.2.23-15
selinux-policy-targeted-2.2.23-15

...reproducibly fixed the problem. I'm assuming the newer policy is tickling a
bug somewhere else in the kernel, and not causing the problem directly ... but
that fixes it anyway (you'll probably want to reboot afterwards, as a pile of
Xen things got relabled).

- Does loading the initial policy again only trigger the problem?

- Do you see any problems on bare metal?

- What did Jeremy do the first time to fix this?

In some newer versions of selinux-policy, what seems to be a typo crept in:

"xen_device_t" replaced "xend_device_t" on several lines in
/etc/selinux/targeted/contexts/files/file_contexts

Setting these back to "xend_device_t" and running restorecon (may have to force)
against the affected paths may help (got me back up and running but my errors
were different).

I'm still a SELinux newb, so keep the flame on low.

Thanks

My apologies -- correct path was /etc/selinux/targeted/modules/active/file_contexts

This doesn't seem to fix the memory problem on i386 for me, but does return
x86_64 to working order after selinux policy updates..

 This is correct:

% ll -Z /dev/xen | egrep xen
crw-------  root     root     system_u:object_r:xen_device_t   evtchn
% egrep xen /usr/share/selinux/devel/include/kernel/devices.if | egrep xen_device
                type device_t, xen_device_t;
        allow $1 xen_device_t:chr_file rw_file_perms;
                type device_t, xen_device_t;
        allow $1 xen_device_t:chr_file manage_file_perms;
                type device_t, xen_device_t;
        type_transition $1 device_t:chr_file xen_device_t;


...and as I said in comment #14, the problem doesn't go away if you turn SELinux
into non-enforcing mode ... only if you don't load the policy.

 This is now working for me with kernel-2.6.16-1.2122_FC5.