In POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-March/msg00591.html
Hi,Eric Blake On RHEL5.7 with libvirt-0.8.2-18.el5,no qemu monitor command can be sent by libvirt virsh command,then how to verify this bug?
Do a device-assignment to test pci-reset PCI-reset will be issued after device is detached from host, before attaching to guest; also, when guest shutdown, a reset to the device should be done before re-assigning to host(pci-stub).
It should also be possible to check the permissions on the various $PCIDEV/* files. For example, when I set up a passthrough pci device for device 0a:0a:0 on my machine, then qemu has access to files under /sys/devices/pci0000:00/0000:00:1e.0/0000:0a:0a.0/. If qemu.conf runs the guest as qemu:qemu instead of root:root, then the owner of $PCIDEV/reset will still be root:root pre-patch, and qemu:qemu post-patch.
Hi,Eric Blake Verified with libvirt-0.8.2-18.el5 and kvm-83-229.el5, but one following problem needs to make sure with you: the steps: 1.Passthrough a pci device to the guest,part of the guest xml is as following: <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/> </source> </hostdev> 2.#virsh start guest 3.when the guest is running,look at the files under /sys/devices/pci0000:00/0000:00:19.0,they all show as root:root ll total 0 -rw-r--r-- 1 root root 4096 Apr 12 04:38 broken_parity_status lrwxrwxrwx 1 root root 0 Apr 12 04:37 bus -> ../../../bus/pci -r--r--r-- 1 root root 4096 Apr 12 04:37 class -rw-r--r-- 1 root root 256 Apr 12 04:52 config -r--r--r-- 1 root root 4096 Apr 12 04:37 device lrwxrwxrwx 1 root root 0 Apr 12 04:55 driver -> ../../../bus/pci/drivers/pci-stub -rw------- 1 root root 4096 Apr 12 04:38 enable -r--r--r-- 1 root root 4096 Apr 12 04:37 irq -r--r--r-- 1 root root 4096 Apr 12 04:38 local_cpus -r--r--r-- 1 root root 4096 Apr 12 04:38 modalias drwxr-xr-x 2 root root 0 Apr 12 04:38 power --w--w---- 1 root root 4096 Apr 12 04:38 remove -r--r--r-- 1 root root 4096 Apr 12 04:52 resource -rw------- 1 root root 131072 Apr 12 04:52 resource0 -rw------- 1 root root 4096 Apr 12 04:52 resource1 -rw------- 1 root root 32 Apr 12 04:52 resource2 lrwxrwxrwx 1 root root 0 Apr 12 04:38 subsystem -> ../../../bus/pci -r--r--r-- 1 root root 4096 Apr 12 04:38 subsystem_device -r--r--r-- 1 root root 4096 Apr 12 04:38 subsystem_vendor --w------- 1 root root 4096 Apr 12 04:37 uevent -r--r--r-- 1 root root 4096 Apr 12 04:37 vendor 4. ps -efZ |grep qemu-kvm system_u:system_r:svirt_t:s0:c322,c554 root 3977 1 8 04:52 ? 00:01:03 /usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name r6.0 -uuid 76efb6d2-673c-41be-9338-bd54877ffc57 -monitor unix:/var/lib/libvirt/qemu/r6.0.monitor,server,nowait -no-kvm-pit-reinjection -boot c -drive file=/var/lib/libvirt/images/r6.0.img,if=virtio,boot=on,format=raw,cache=none -drive if=ide,media=cdrom,bus=1,unit=0,readonly=on,format=raw -net none -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-us -vga cirrus -pcidevice host=00:19.0 -balloon virtio It also shows root 5.Look at the /etc/libvirt/qemu.conf,the following two lines are commented. # The user ID for QEMU processes run by the system instance #user = "root" # The group ID for QEMU processes run by the system instance #group = "root" On rhel5 can we run guest as qemu:qemu?
(In reply to comment #7) > My understanding is that the rhel5 default is to run guests as root:root; so > you do need to temporarily modify qemu.conf to change the #user and #group > lines to be uncommented: > > user="qemu" > group="qemu" > > then restart libvirtd and restart the guest to verify the test results. Until > qemu is running as its own user, you won't see any ownership differences under > /sys/devices for the pci device. Hi,Eric,After I set user="qemu" group="qemu" then restart libvirtd, and start the guest,it will report the following errors: #virsh start r6.0 error: Failed to start domain r6.0 error: internal error Process exited while reading console log output: open /dev/kvm: Permission denied Could not initialize KVM, will disable KVM support qemu: could not open disk image /var/lib/libvirt/images/r6.0.img So I think on rhel5 it doesn't support qemu:qemu, on rhel6 after the guest is started,the owner:group can change to qemu:qmu. I think rhel5 and rhel6 are different.
What are the permissions on /dev/kvm and /var/lib/libvirt? It could be that they are overly restrictive, but that no one has cared in general because of the rhel5 default of running as root:root. On rhel 6, I see: # ls -ld /dev/kvm /var/lib/libvirt/ crw-rw-rw-+ 1 root kvm 10, 232 Apr 7 15:41 /dev/kvm drwxr-xr-x. 8 root root 4096 Apr 7 15:42 /var/lib/libvirt/
According to comment 10 by Alex Williamson,rhel5 reqires root privildeges to run,so look at the files under /sys/devices/pci0000:00/0000:00:19.0,they all show as root:root. Verified with libvirt-0.8.2-18.el5 and kvm-83-229.el5 Passed Steps: 1.Modify the /etc/libvirt/qemu.conf file and config user="root" group="qemu" 2.Service libvirtd restart 3.Passthrough a pci device to the guest,part of the guest xml is as following: <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/> </source> </hostdev> 4.#virsh start guest 5.In the guest,the guest can get the IP address of eth0 host physical address 6.#virsh shutdown guest 7.In the host,the host can get the IP address again 8.#virsh start guest and #virsh reboot guest,all can work well So verified is Passed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Guests connected to a passthrough NIC would encounter kernel panic if you sent a system_reset signal through the QEMU monitor because of a bug in the code. The bug has been fixed and you can now successfully reset the guest as expected.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-1019.html