Bug 877240

(In reply to comment #0)
> Description of problem:
> Boot a guest and create a snapshot, then try to create the image with the
> same filename as the backing file, it will prompts 'Error: Trying to create
> an image with the same filename as the backing file', but QMP did not give a
> correctly errno information to OpenFileFailed error.
> 
> Expected results:
> the errno value to OPenFileFailed's error message should some thing like:
> Permission denied.
> eg:
> {"error": {"class": "OpenFileFailed", "desc": "Could not open
> '/dev/vg_sluo_live_snapshot/sluo-snap1': Permission denied", "data":
> {"filename": "/dev/vg_sluo_live_snapshot/sluo-snap1",
> "__com.redhat_error_message": "Permission denied"}}}
> 
> Error: Trying to create an image with the same filename as the backing file
> Could not open '/dev/vg_sluo_live_snapshot/sluo-snap1': Permission denied
> 
The most important thing to check is the more complete 'desc' key. It's very important that add the errno string (as returned by strerror()) and the errno value to OPenFileFailed's error message. please correct me if any error & thx.

Best Regards.
sluo

The problem here is that bdrv_img_create() returns -EINVAL to callers, and qmp_transaction() uses that to build the error message. It prints the correct message on HMP because bdrv_img_create() also calls error_report(), which doesn't work on QMP.

I have a series pending upstream that does the Right Thing to fix this issue, which is to propagate the Error object from bdrv_img_create():

  https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03509.html

I don't think it's feasible to backport this to 6.4, though.

Jeff, feel free to reassign the bug to me if this works better for you.

(In reply to comment #3)
> Jeff, feel free to reassign the bug to me if this works better for you.

Luiz, since you are already addressing this upstream, I will go ahead and do that.  Thanks.

Updated summary and proposing this bz to 6.5, as I don't think we'll have time to fix this for 6.4.

*** Bug 876024 has been marked as a duplicate of this bug. ***

List of patches (top to bottom):

71c7981 block: bdrv_img_create(): add Error ** argument
9b37525 qemu-img: img_create(): pass Error object to bdrv_img_create()
a930091 qemu-img: img_create(): drop unneeded goto and ret variable
43e1704 qmp: qmp_transaction(): pass Error object to bdrv_img_create()
cf8f242 qmp: qmp_drive_mirror(): pass Error object to bdrv_img_create()
d92ada2 block: bdrv_img_create(): drop unused error handling code

These patches depend on error_setg() and error_setg_errno(). I reimplement them for RHEL-6 in the series for bug 952873; setting BZ dependency.

I tested the backport as follows:
(1) edited the spec file to enable RHEV features for the RHEL build too:

diff --git a/redhat/qemu-kvm.spec.template b/redhat/qemu-kvm.spec.template
index b45381d..7b66383 100644
--- a/redhat/qemu-kvm.spec.template
+++ b/redhat/qemu-kvm.spec.template
@@ -414,7 +414,8 @@ cd qemu-kvm-x86_64-build
             --disable-smartcard-nss \
             --enable-usb-redir \
             %{fake_machine_arg} \
-            %{disable_rhev_features_arg}
+            %{disable_rhev_features_arg} \
+            --enable-rhev-features

 echo "config-host.mak contents:"
 echo "==="

(2) After adding another virtio disk to the guest and starting the guest,
executed the following qmp commands over libvirtd:

  virsh qemu-monitor-command --domain fw-seabios63.g-rhel63.e-rhel63 \
      --cmd '{ "execute": "blockdev-snapshot-sync", "arguments": { "device":
             "drive-virtio-disk1", "snapshot-file": "/tmp/sn1.img", "format":
             "qcow2" } }'

  {"return":{},"id":"libvirt-10"}

This created the new image file in /tmp/sn1.img.

  ls -l /tmp/sn1.img

  -rw-r--r--. 1 qemu qemu 262144 Apr 18 20:38 /tmp/sn1.img

Then I repeated the previous QMP monitor command, the response was this
time:

  {
    "id":"libvirt-11",
    "error":{
      "class":"GenericError",
      "desc":"Error: Trying to create an image with the same filename as the backing file",
      "data":{
        "message":"Error: Trying to create an image with the same filename as the backing file"
      }
    }
  }

Finally I tried to create an image in a directory (/var/lib/libvirt/images/)
where qemu-kvm has no write permission:

  virsh qemu-monitor-command --domain fw-seabios63.g-rhel63.e-rhel63 \
      --cmd '{ "execute": "blockdev-snapshot-sync", "arguments": { "device":
             "drive-virtio-disk1", "snapshot-file":
             "/var/lib/libvirt/images/sn1.img", "format": "qcow2" } }'

  {
    "id":"libvirt-12",
    "error":{
      "class":"GenericError",
      "desc":"/var/lib/libvirt/images/sn1.img: error while creating qcow2: Permission denied",
      "data":{
        "message":"/var/lib/libvirt/images/sn1.img: error while creating qcow2: Permission denied"
      }
    }
  }

Reproduce this bug as follow version:
Host :
# uname -r
2.6.32-389.el6.x86_64
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-0.12.1.2-2.355.el6.x86_64

Guest:
# uname -r
2.6.32-358.el6.x86_64

Steps
1.Boot guest 
/usr/libexec/qemu-kvm -m 2G -smp 2 -cpu Penryn -usbdevice tablet -drive file=/home/RHEL-Server-6.4-64-virtio.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,drive=drive-virtio-disk0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,mac=05:10:20:2f:37:26,bus=pci.0,addr=0x4,id=net0 -boot order=cn,menu=on -uuid `uuidgen` -rtc base=utc,clock=host,driftfix=slew -no-kvm-pit-reinjection -monitor stdio -name rhel6.4 -spice port=5830,disable-ticketing -vga qxl  -qmp tcp:0:5555,server,nowait

2.[root@localhost ~]# telnet 10.66.5.160 5555
Trying 10.66.5.160...
Connected to 10.66.5.160.
Escape character is '^]'.
{"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0}, "package": "(qemu-kvm-0.12.1.2)"}, "capabilities": []}}
{"execute":"qmp_capabilities"}
{"return": {}}
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/home/sn1", "format": "qcow2" } }
{"return": {}}
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/home/sn1", "format": "qcow2" } }
{"error": {"class": "OpenFileFailed", "desc": "Could not open '/home/sn1': Invalid argument", "data": {"filename": "/home/sn1", "__com.redhat_error_message": "Invalid argument"}}}

Results:
HMP:
(qemu) blockdev-snapshot-sync drive-virtio-disk0 /home/sn1
Error: Trying to create an image with the same filename as the backing file
Could not open '/home/sn1': Invalid argument

QMP:
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/home/sn1", "format": "qcow2" } }
{"error": {"class": "OpenFileFailed", "desc": "Could not open '/home/sn1': Invalid argument", "data": {"filename": "/home/sn1", "__com.redhat_error_message": "Invalid argument"}}}

QMP not give the detail error info.

Verify this bug as follow version:
Host:
# uname -r 
2.6.32-389.el6.x86_64
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-0.12.1.2-2.376.el6.x86_64

Guest:
2.6.32-358.el6.x86_64

Steps as same as reproduce

Resutls:

HMP:
(qemu) blockdev-snapshot-sync drive-virtio-disk0 /home/sn1
Error: Trying to create an image with the same filename as the backing file

QMP:
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/home/sn1", "format": "qcow2" } }
{"error": {"class": "GenericError", "desc": "Error: Trying to create an image with the same filename as the backing file", "data": {"message": "Error: Trying to create an image with the same filename as the backing file"}}}

Addtional info :
1)Also test the senario of the duplicate bug876024
QMP:
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/lls/ll", "format": "qcow2" } }
{"error": {"class": "GenericError", "desc": "/lls/ll: error while creating qcow2: No such file or directory", "data": {"message": "/lls/ll: error while creating qcow2: No such file or directory"}}}
HMP:
(qemu) blockdev-snapshot-sync drive-virtio-disk0 /tt/ll
Formatting '/tt/ll', fmt=qcow2 size=21474836480 backing_file='/home/sn1' backing_fmt='qcow2' encryption=off cluster_size=65536 
/tt/ll: error while creating qcow2: No such file or directory


According to above test ,this bug fixed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1754.html