Bug 768859 - hotplug failed when the image file located in /root directory
Summary: hotplug failed when the image file located in /root directory
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gunannan Ren
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-19 08:08 UTC by yanbing du
Modified: 2012-11-28 17:28 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-28 17:28:53 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description yanbing du 2011-12-19 08:08:18 UTC
Description of problem:
 When hotplug a disk from /root directory to a guest, virsh command will output an error and hotplug failed. But if the image file locate in other directory, such as /var/lib/libvirt/images, hotplug will successful.
BTW, no matter selinux is enforcing or permissive, it will get the same result.

Version-Release number of selected component (if applicable):
libvirt-0.9.8-1.el6.x86_64
qemu-kvm-0.12.1.2-2.209.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a image file in /root directory,
   #qemu-img create -f raw foo.img 10M

2. Set selinux to permissive.
   #setenforce 0
3. hotplug the image to a guest,
   #virsh attach-disk test /root/foo.img vdb
   error: Failed to attach disk
   error: internal error unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk1' could not be initialized

or use XML file
   #cat disk.xml
   <disk type='file' device='disk'>
     <driver name='qemu' type='raw'/>
     <source file='/root/foo.img'/>
     <target dev='vdb' bus='virtio'/>
   </disk>
   #virsh attach-device test disk.xml
   error: Failed to attach device from disk.xml
   error: internal error unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk1' could not be initialized
  
Actual results:
As step 3 described.

Expected results:
Can hotplug successful.

Additional info:

guest log:
2011-12-19 06:33:34.162+0000: starting up
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name test -uuid d2e6f0e5-fc5f-e285-1464-0297f8023705 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/var/lib/libvirt/images/vm5.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/libvirt/images/temp.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:cd:9f:67,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -devic!
 e usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
char device redirected to /dev/pts/2

libvirtd.log:
2011-12-19 06:49:01.354+0000: 22109: error : qemuMonitorJSONCheckError:322 : internal error unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk1' could not be initialized
2011-12-19 06:59:02.077+0000: 22113: error : qemuMonitorJSONCheckError:322 : internal error unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk1' could not be initialized

Comment 1 Dave Allan 2011-12-19 15:26:15 UTC
You're getting this result because qemu runs as user qemu who can't read /root.

Comment 2 weizhang 2011-12-20 02:19:37 UTC
(In reply to comment #1)
> You're getting this result because qemu runs as user qemu who can't read /root.

But we can save domain to /root, right? I think we can also attach a disk from /root. If it is really not supported because of permission, then the error information should be improved.

Comment 3 Dave Allan 2011-12-20 16:07:02 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > You're getting this result because qemu runs as user qemu who can't read /root.
> 
> But we can save domain to /root, right? I think we can also attach a disk from
> /root. If it is really not supported because of permission, then the error
> information should be improved.

No, you cannot save the domain to /root.  

I agree that the error messages are not great.  I'll reopen so that making them clearer can be investigated.

Comment 5 Gunannan Ren 2012-05-12 15:56:07 UTC
The error message couldn't be reproduced in upstream, only on RHEL version.

Comment 8 Dave Allan 2012-11-19 16:10:32 UTC
(In reply to comment #5)
> The error message couldn't be reproduced in upstream, only on RHEL version.

What did libvirt report when it failed the hotplug?

Comment 9 Gunannan Ren 2012-11-20 08:36:12 UTC
The disk hotplug is successful using libvirt upstream code.
libvirt first uses qemu json command "one" to add drive image. If qemu command "one"  failed, libvirt tries to use qemu json command "two" to do the same work. Finally it succeeded.

one:
{"execute":"drive_add","arguments":{"pci_addr":"dummy","opts":"file=/root/foo.img,if=none,id=drive-virtio-disk1,format=raw"},"id":"libvirt-8"}

two:
{"execute":"human-monitor-command","arguments":{"command-line":"drive_add dummy file=/root/foo.img,if=none,id=drive-virtio-disk1,format=raw"},"id":"libvirt-9"}

The libvirt version on this bug is using the following qemu json command line
{"execute":"__com.redhat_drive_add","arguments":{"file":"/root/foo.img","id":"drive-virtio-disk1","format":"raw"},"id":"libvirt-8"}

The qemu command will report error:
{"id":"libvirt-8","error":{"class":"DeviceInitFailed","desc":"Device 'drive-virtio-disk1' could not be initialized","data":{"device":"drive-virtio-disk1"}}}

If libvirt uses the fist way on RHEL7, there is probably no such a problem.

Comment 10 Dave Allan 2012-11-20 14:13:55 UTC
(In reply to comment #9)
> If libvirt uses the fist way on RHEL7, there is probably no such a problem.

Guannan, please confirm the RHEL7 behavior.  Thanks.

Comment 13 Gunannan Ren 2012-11-28 07:55:27 UTC
On RHEL7, when you try to attach a disk which is located in /root, libvirt will report error:

# virsh attach-disk rhel6qcow2 /root/foo.img vdb
error: Failed to attach disk
error: operation failed: open disk image file failed

When we create a disk in /var/lib/libvirt/images/foo.img and attach it into guest. it succeeded.

# virsh attach-disk rhel6qcow2 /var/lib/libvirt/images/foo.img vdb
Disk attached successfully

Comment 14 Dave Allan 2012-11-28 17:28:53 UTC
(In reply to comment #13)
> On RHEL7, when you try to attach a disk which is located in /root, libvirt
> will report error:
> 
> # virsh attach-disk rhel6qcow2 /root/foo.img vdb
> error: Failed to attach disk
> error: operation failed: open disk image file failed

Ok, great; I will close the BZ then.


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