* Dan Kenigsberg <dan...@redhat.com> [2012-08-19 07:36]:
> On Fri, Aug 17, 2012 at 08:10:40AM -0500, Ryan Harper wrote:
> > * Dan Kenigsberg <dan...@redhat.com> [2012-08-16 15:59]:
> > > On Thu, Aug 16, 2012 at 10:53:17AM -0500, Ryan Harper wrote:
> > > > * Dan Kenigsberg <dan...@redhat.com> [2012-08-16 03:37]:
> > > > > Dan Kenigsberg has posted comments on this change.
> > > > > 
> > > > > Change subject: Fix vdsm-faqemu VM launch failure on hosts with newer 
> > > > > libvirt
> > > > > ......................................................................
> > > > > 
> > > > > 
> > > > > Patch Set 1: I would prefer that you didn't submit this
> > > > > 
> > > > > (1 inline comment)
> > > > > 
> > > > > ....................................................
> > > > > File vdsm_hooks/faqemu/vdsm-faqemu
> > > > > Line 20: 
> > > > > Line 21: qemu_argv += filter(lambda x: x != "-enable-kvm", 
> > > > > sys.argv[1:])
> > > > > Line 22: # libvirt 0.9.10+ checks for the presence of /dev/kvm to 
> > > > > provide 
> > > > > Line 23: # better error messages, but this breaks this hook, fake it 
> > > > > out
> > > > > Line 24: os.system("touch /dev/kvm")
> > > > > how can this work? this script runs as vdsm.
> > > > 
> > > > # sudo -u vdsm touch /dev/kvm  
> > > > touch: cannot touch `/dev/kvm': Permission denied
> > > > 
> > > > But I can assure you that it did work.  I didn't just touch the file as
> > > > root.  I installed the faqemu hook and /dev/kvm is owned by root.  Are
> > > > you sure hooks run as vdsm?
> > > 
> > > Yes. They are called by hooks.py's execCmd.
> > > However I was wrong about this script being a hook script: it is the
> > > emulator used by libvirt instead of qemu. Again, I am very much
> > > surprised that this runs as root - libvirt's default is qemu:qemu.
> > 
> > Agreed, I'm not quite sure what's going on here as the VMs indeed are
> > running as non-root qemu user:
> 
> Could libvirt be running the emulator twice? Once as root to check
> -help, and then as qemu?

I was just thinking that, but I'm pretty sure we'd throw an error on
access.

(platechiller) ~ % sudo bash
[sudo] password for rharper: 
(platechiller) tmp % touch /dev/kvmtest
(platechiller) tmp % ls -al /dev/kvmtest
-rw-r--r-- 1 root root 0 Aug 20 08:37 /dev/kvmtest
(platechiller) tmp % exit
exit
(platechiller) ~ % whoami
rharper
(platechiller) ~ % touch /dev/kvmtest
touch: cannot touch `/dev/kvmtest': Permission denied


> > 
> > qemu     31698  2.0  0.8 997456 71884 ?        Sl   Aug16  25:45 
> > /usr/bin/qemu-kvm 
> 
> > 
> > 
> > > 
> > > 
> > > > 
> > > > It's run as root:
> > > > 
> > > > [root@ichigo-dom228 tmp]# cat /usr/libexec/vdsm/vdsm-faqemu
> > > > #!/usr/bin/python
> > > > 
> > > > import os
> > > > import sys
> > > > 
> > > > qemu_paths = [
> > > >     "/usr/bin/qemu-kvm",
> > > >     "/usr/libexec/qemu-kvm",
> > > > ]
> > > > 
> > > > for qemu_bin in qemu_paths:
> > > >     if os.path.exists(qemu_bin): break
> > > > else:
> > > >     raise RuntimeError, "QEMU binary not found"
> > > > 
> > > > qemu_argv = [ qemu_bin ]
> > > > 
> > > > if not "-no-kvm" in sys.argv:
> > > >     qemu_argv += [ "-no-kvm" ]
> > > > 
> > > > qemu_argv += filter(lambda x: x != "-enable-kvm", sys.argv[1:])
> > > > os.system('id > /tmp/faqemu_id.out')
> > > > os.system('touch /dev/kvm')
> > > > os.execv(qemu_bin, qemu_argv)
> > > > 
> > > > [root@ichigo-dom228 tmp]# cat /tmp/faqemu_id.out 
> > > > uid=0(root) gid=0(root) groups=0(root) 
> > > > context=system_u:system_r:virtd_t:s0-s0:c0.c1023
> > > > 
> > > > 
> > > > > 
> > > > > also, there are less expensive ways to create a file - how about 
> > > > > shipping it in this hook's rpm ?
> > > > 
> > > > Is that really less expensive?  I worry about having an rpm include the 
> > > > file;
> > > > and /dev gets remounted/changed accross reboots; so this wouldn't work.
> > > > 
> > > > What's expensive about a touch?
> > > 
> > > It is, comparing to opening the file for writing
> > > 
> > >     file('/dev/kvm', 'w')
> > 
> > We're launching a VM, an additional exec isn't a lot of overhead.  If
> > someone comes back and says launching the VM took too long and we spend
> > all our time in one os.system('touch') call, then maybe you're right.
> > 
> > (platechiller) ~ % cat touch.py 
> > import os
> > os.system('touch /dev/kvm')
> > (platechiller) ~ % sudo time python touch.py 
> > 0.01user 0.00system 0:00.01elapsed 84%CPU (0avgtext+0avgdata
> >       21328maxresident)k
> > 0inputs+0outputs (0major+2424minor)pagefaults 0swaps
> 
> Yes, one fork is negligible. But they pile up.
> I see no reason to call fork(2) when you actually want open(2).

I still fail to see the significance of the overhead here. we're already in an
exceptional path

1) I had to install faqemu hook
2) I had to be running on a host without kvm (going to be slow anyhow)
3) and this is during VM creation, in which libvirt already execs qemu-kvm no 
less than 3 times.

Since I'd really like to get VM creation working for me, I'll respin.

> 
> > 
> > > 
> > > 
> > > Anyway, I cannot say that I'm happy with this solution: nothing clears
> > > /dev/kvm after the hook is uninstalled, for one's.
> > 
> > /dev/kvm will be removed on reboot since /dev is reconstructed.
> > 
> > The presence of the file doesn't bother loading of the module either:
> > 
> > (platechiller) ~ % ls -al /dev/kvm
> > crw-rw----+ 1 root kvm 10, 232 Aug 17 08:06 /dev/kvm
> > (platechiller) ~ % sudo modprobe -vr kvm_intel kvm 
> > rmmod /lib/modules/3.2.0-29-generic/kernel/arch/x86/kvm/kvm-intel.ko
> > rmmod /lib/modules/3.2.0-29-generic/kernel/arch/x86/kvm/kvm.ko
> > (platechiller) ~ % ls -al /dev/kvm
> > ls: cannot access /dev/kvm: No such file or directory
> > (platechiller) ~ % sudo touch /dev/kvm 
> > (platechiller) ~ % ls -al /dev/kvm
> > -rw-r--r-- 1 root root 0 Aug 17 08:06 /dev/kvm
> > (platechiller) ~ % sudo modprobe -v kvm-intel
> > insmod /lib/modules/3.2.0-29-generic/kernel/arch/x86/kvm/kvm.ko 
> > insmod /lib/modules/3.2.0-29-generic/kernel/arch/x86/kvm/kvm-intel.ko 
> > (platechiller) ~ % ls -al /dev/kvm 
> > crw-rw----+ 1 root kvm 10, 232 Aug 17 08:07 /dev/kvm
> 
> It's less destructive than I thought, but it's not prettier...
> On the other hand, it let's touch the file only when the script is
> enabled.
> 
> Dan.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to