Hide Forgot
Description of problem: When I tried to run new created vm, VM failed to run, vdsm log file report that spice failed to access to /dev/shm Workaround : need to restart the vdsm to change permission mode to all users rw. Additional info: rw permission to all users is a security problem. this allows shared memory to be accessible to every user. should to create dedicated directory to spice under /dev/shm/qumenu
come to think of this, if qemu process won't start if it cannot write into /dev/shm, that this is a libvirt bug (or something else, even lower down the stack).
Hi Tomer , Would you please provide following info for bug reproduction ? 1. Which version of libvirt, qemu-kvm , kernel , vdsm did you use when meeting this bug 2. Any Steps to reproduce this bug ? 3. Is there any specific configuration for the guest ? Or libvirt or vdsm to reproduce this bug ? Thanks Vivian
Hi Vivian In fact the bug occurred on rhel5. I don't have a specific scenario how to reproduce this bug, I'll try to reproduce this bug on both OS rhel5 and rhel6, I'll update if I'll have more info. Thanks, Tomer
Hum, if the bug was found only on RHEL-5, I really don't see why that bug is being assigned to RHEL-6, that's bogus. Either provide a way to reproduce this on RHEL-6, or reassign it to RHEL-5, thanks ! Daniel
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
It's pretty easy to reproduce on RHEL6. - install RHEL6 from scratch. make sure that no vdsm is around. - verify that /dev/shm is not writable by qemu:kvm. It's that way by default. - try to start a domain with spice.
(In reply to comment #0) > Description of problem: > > When I tried to run new created vm, VM failed to run, > vdsm log file report that spice failed to access to /dev/shm > > Workaround : > > need to restart the vdsm to change permission mode to all users rw. > > Additional info: > > rw permission to all users is a security problem. > this allows shared memory to be accessible to every user. > should to create dedicated directory to spice under /dev/shm/qumenu I don't think libvirt could control this, qemu doesn't provide any flag of option "-spice" for us to speicify the location of the tmpfs location.
libvirt could chmod /dev/shm to let qemu write there. (or spice should think of a better place to put its statistics)
Yes, The entry under /dev/shm for spice guest (e.g. "/dev/shm/spice.$pid") is created by spice, we can't control the location either in libvirt or in qemu. 5444 int shm_name_len = strlen(REDS_STAT_SHM_NAME) + 20; 5445 int fd; 5446 5447 if (!(reds->stat_shm_name = (char *)malloc(shm_name_len))) { 5448 red_error("stat_shm_name alloc failed"); 5449 } 5450 snprintf(reds->stat_shm_name, shm_name_len, REDS_STAT_SHM_NAME, getpid()); 5451 if ((fd = shm_open(reds->stat_shm_name, O_CREAT | O_RDWR, 0444)) == -1) { 5452 red_error("statistics shm_open failed, %s", strerror(errno)); 5453 } I'm wondering if it's reasonable to chmod /dev/shm in libvirt, the default permision mode of "/dev/shm" is "rw" by all, obviously it's changed by some outside app, chmod in libvirt as a "fix" will be strange then, assuming outside app changed permission mode of /dev/shm to "1000", but finally the entry in /dev/shm for spice guest could be created successfully, and the guest could be started successfully, one will be surprised, and perhaps he'd like file another bug. What I'm thinking is: if changing the permission mode outside, then do all outside, splitting the actions may not be good idea. By the way, vdsmd chmod's /dev/shm to "1777" when startup. # grep '/dev/shm' * -r vdsm/vdsmd: /bin/chmod 1777 /dev/shm So curious what changes it into only "rw" by root.
> the default permission mode of "/dev/shm" is "rw" by all If this is the case in RHEL6, there's no bug here. But as far as I recall that's not the case.
It's "rw" by all indeed. [root@dhcp-* ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.0 (Santiago) [root@dhcp-* ~]# ls -ld /dev/shm/ drwxrwxrwt. 2 root root 160 2011-04-19 05:04 /dev/shm/ [root@dhcp-4-231 ~]#
Same case on RHEL6.1 [root@localhost ~]# reboot Broadcast message from root (/dev/pts/9) at 23:35 ... The system is going down for reboot NOW! [root@localhost ~]# Connection to 10.*.*.* closed by remote host. Connection to 10.*.*.* closed. [osier@Osier ~]$ ssh root@10.*.*.* ssh: connect to host 10.*.*.* port 22: Connection refused [osier@Osier ~]$ ssh root@10.*.*.* root@10.*.*.*'s password: Last login: Wed Apr 27 23:35:36 2011 from vpn1-.nay.redhat.com [root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.1 Beta (Santiago) [root@localhost ~]# ls -ld /dev/shm/ drwxrwxrwt. 2 root root 80 2011-04-27 23:36 /dev/shm/
Is that on a fresh RHEL6 that had never seen vdsm? (vdsm sets this permission explicitly)
yes, no vdsm installed, there are not fresh installed boxes, but I think a reboot is enough, /dev/shm is mounted as the setting in /etc/fstab, I truse it's not changed.
s/there/they/, s/truse/trust/,
Dan, I'm going to close this as WORKSFORME, but of course if you don't see boxes behaving as you expect, please reopen.