Bug 689880 - guest with passthrough nic got kernel panic when send system_reset signal in QEMU monitor
guest with passthrough nic got kernel panic when send system_reset signal in ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
5.6
x86_64 Linux
low Severity high
: rc
: ---
Assigned To: Alex Williamson
Virtualization Bugs
: Triaged
Depends On: 657149 689860
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2011-03-22 13:46 EDT by Alex Williamson
Modified: 2013-01-09 18:41 EST (History)
15 users (show)

See Also:
Fixed In Version: libvirt-0.8.2-18.el5
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: 657149
Environment:
Last Closed: 2011-07-21 06:32:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 3 koka xiong 2011-04-06 23:39:10 EDT
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?
Comment 4 Don Dutile 2011-04-08 11:00:24 EDT
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).
Comment 5 Eric Blake 2011-04-08 11:06:44 EDT
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.
Comment 6 wangyimiao 2011-04-12 06:43:11 EDT
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?
Comment 8 koka xiong 2011-04-12 22:18:45 EDT
(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.
Comment 9 Eric Blake 2011-04-13 11:55:48 EDT
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/
Comment 11 koka xiong 2011-04-13 23:06:14 EDT
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.
Comment 12 Kate Grainger 2011-07-18 02:11:56 EDT
    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.
Comment 13 errata-xmlrpc 2011-07-21 06:32:22 EDT
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

Note You need to log in before you can comment on or make changes to this bug.