Description of problem: Following scenario "virt-install w/ qcow2" from https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization_qcow2 I got this traceback: newman@dhcp-lab-124 SPECS $ virt-install --connect qemu:///system --name rawhide-qcow2 --ram 1024 --disk path=/var/lib/libvirt/images/rawhide.qcow2,format=qcow2,size=6 --location http://download.englab.brq.redhat.com/pub/fedora/linux/development/x86_64/os --os-variant fedora12 Starting install... Retrieving file .treeinfo... | 2.4 kB 00:00 ... Retrieving file vmlinuz... | 7.1 MB 00:00 ... Retrieving file initrd.img... | 45 MB 00:01 ... Allocating 'rawhide.qcow2' | 0 B 00:00 ERROR internal error unable to start guest: char device redirected to /dev/pts/2 qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.VjmKwU' Domain installation may not have been successful. If it was, you can restart your domain by running 'virsh start rawhide-qcow2'; otherwise, please restart your installation. ERROR internal error unable to start guest: char device redirected to /dev/pts/2 qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.VjmKwU' Traceback (most recent call last): File "/usr/bin/virt-install", line 933, in <module> main() File "/usr/bin/virt-install", line 829, in main start_time, guest.start_install) File "/usr/bin/virt-install", line 884, in do_install dom = install_func(conscb, progresscb, wait=(not wait)) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install return self._do_install(consolecb, meter, removeOld, wait) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1077, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error unable to start guest: char device redirected to /dev/pts/2 qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.VjmKwU' When run as ordinary user. Version-Release number of selected component (if applicable): python-virtinst-0.500.0-3.fc12.noarch libvirt-0.7.1-1.fc12.x86_64 Linux dhcp-lab-124.englab.brq.redhat.com 2.6.31-14.fc12.x86_64 #1 SMP Tue Sep 15 03:48:57 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux How reproducible: well, always Steps to Reproduce: 1. run the command 2. 3. Actual results: backtrace Additional info: SELINUX=permissive SELINUXTYPE=targeted But not AVC seen.
Just noticed with virt-manager too. Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: char device redirected to /dev/pts/2 qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.CZ8Rrp' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 1489, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install return self._do_install(consolecb, meter, removeOld, wait) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1077, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error unable to start guest: char device redirected to /dev/pts/2 qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.CZ8Rrp' '
Okay, we need to fix this As a workaround, you need to do: $> chmod 0+x /home/newman/ /home/newman/.virtinst /home/newman/.virtinst/boot/ so that qemu can get at the images
Suggestion is that virtinst should use something like /tmp/virst-$user/boot instead since we can't control the permissions of /home/$user
adding dwalsh What will we have to do wrt to selinux for this? Previously the selinux policy could point to the known location ~/.virtinst/boot, which we could restorecon. How will tmp work in that respect? Are there any security implications of using /tmp over /home?
Cole what is the behaviour of virt-install supposed to be here? Is this run as root? We can label in these different location, but what is the fundamental problem here, since it does not seem to be an SELinux problem yet.
Libvirt now runs qemu process as the 'qemu' user (previously as 'root), which doesn't have search permissions for the average user's home directory. This breaks URL installs via virt-install, because we download the kernel/initrd to ~user/.virtinst/boot by default. Whatever user we run virt-install as doesn't affect the what user the qemu binary is run as. It is suggested that we change this URL download location to something under /tmp, and I was curious what selinux policy changes would need to made to accomodate that. Currently ~/.virtinst/boot is referenced in the selinux-policy AFAIK.
The assumption that /tmp is the same for the user QEMU is the same as dwalsh is a faulty assumption. This is virt-manager/virt-install running as dwalsh downloading a file and then tells libvirt to launch a qemu running as UID qemu to read the file? Is this your framework. We cannot cp the file into a directory controlled by libvirt, because of size?
I don't much like the idea of moving stuff back into /tmp again - $HOME/.virtinst was a good move to make. I think perhaps we should make use of ACLs, and set an xplicit ACL qemu+x On $HOME when we store data there that QEMU needs to use. This is better than simply chmoding o+x, because it is restricted to just the QEMU user, and it is obvious why the change was made & thus trivially reverted
That sounds ok with me and would not need to change any policy, but is a user allowed to do this? setfacl -m u:qemu:x virt-clone.log setfacl: virt-clone.log: Operation not permitted [Exit 1] Or are you going to have libvirt do this?
(In reply to comment #9) > That sounds ok with me and would not need to change any policy, but is a user > allowed to do this? > > setfacl -m u:qemu:x virt-clone.log > setfacl: virt-clone.log: Operation not permitted > [Exit 1] > Not sure why that doesn't work, it works fine for me. > Or are you going to have libvirt do this? No, virtinst will be doing it. This should be working in virtinst-0.500.0-4: we will use setfacl to try and correct these permissions. Testing is appreciated since there still be problems.
*** Bug 522710 has been marked as a duplicate of this bug. ***
Let's assume that fixed it :-) * Thu Sep 24 2009 Cole Robinson <crobinso> - 0.500.0-4.fc12 - Fix path permissions for kernel/initrd download location (bz 523960) Folks, please do re-open if you still see this issue