path: root/results/classifier/zero-shot/108/other/905095

permissions: 0.783
KVM: 0.766
graphic: 0.712
device: 0.709
PID: 0.688
semantic: 0.683
debug: 0.677
performance: 0.676
boot: 0.675
network: 0.669
socket: 0.659
other: 0.658
vnc: 0.644
files: 0.583

qemu-img can't convert vmdk file: Operation not permitted

There is no reason why the vdmk image can't be converted. Even running it as root does not help.

$ ls -lh
insgesamt 60G
-rw-rw-rw- 1 root   root   479M 2011-09-10 17:47 freetz-linux-1.2.1-disk1.vmdk

$ sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw
qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted
qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk'

I get a similar Error when I try to rum vmdk images directly. After adding a new machine and adding vmdk disks with virt-manager, it tells me when I start the virtual machine:
Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1
kvm: -drive file=/var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: could not open disk image /var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk: Invalid argument

Runnung raw images works perfectly for me.

Hint: i have a symlink set:
/var/lib/libvirt$ ls -lh
insgesamt 12K
drwxr-xr-x 2 root         root 4,0K 2011-07-26 14:30 boot
lrwxrwxrwx 1 root         root    9 2011-08-19 10:47 images -> /home/vms
drwxr-xr-x 2 root         root 4,0K 2011-08-19 09:38 network
drwxr-xr-x 5 libvirt-qemu kvm  4,0K 2011-12-16 04:34 qemu

but this should not be the reason hopefully

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: qemu-kvm 0.14.0+noroms-0ubuntu4.4
ProcVersionSignature: Ubuntu 2.6.38-13.52-generic 2.6.38.8
Uname: Linux 2.6.38-13-generic x86_64
Architecture: amd64
CheckboxSubmission: 8f12e98536291f59719792d89958b124
CheckboxSystem: d00f84de8a555815fa1c4660280da308
Date: Fri Dec 16 04:24:10 2011
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
MachineType: Dell Inc. Latitude E5510
ProcEnviron:
 LANGUAGE=de_DE:en
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-13-generic root=UUID=503213e4-5136-4e60-8a02-7cbd0123dca8 ro quiet splash vt.handoff=7
SourcePackage: qemu-kvm
UpgradeStatus: Upgraded to natty on 2011-08-18 (119 days ago)
dmi.bios.date: 09/08/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A11
dmi.board.name: 023HKR
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2011:svnDellInc.:pnLatitudeE5510:pvr0001:rvnDellInc.:rn023HKR:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E5510
dmi.product.version: 0001
dmi.sys.vendor: Dell Inc.



I just saw that the image format in my last comment was not set right. After changing it from qcow2 to vmdk I get this error when starting the machine:

Error starting domain: operation failed: failed to retrieve chardev info in qemu with 'info chardev'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/engine.py", line 956, in asyncfunc
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 1048, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 330, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: operation failed: failed to retrieve chardev info in qemu with 'info chardev'

To reproduce the problem feel free to download this image:
http://sourceforge.net/projects/freetz-linux/

here's the xml file of the virtual machine

same on a fresh installed up to date ubuntu 11.10:
sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw
qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted
qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk'

up-to-date debian 6.0 says:
# qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img
qemu-img: error while reading

debian testing says:
qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img
qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted
qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk'

debian sid says:
qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img
*** glibc detected *** qemu-img: double free or corruption (top): 0x000000000755cd60 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x72656)[0x2b78929df656]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x2b78929e438c]
qemu-img[0x41c4a2]
qemu-img[0x41d1e6]
qemu-img[0x40e6d9]
qemu-img[0x40f247]
qemu-img[0x4055f1]
qemu-img[0x4068ad]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x2b789298bead]
qemu-img[0x404efd]
======= Memory map: ========
00400000-0045a000 r-xp 00000000 91:e6 114343429                          /usr/bin/qemu-img
0065a000-0065f000 rw-p 0005a000 91:e6 114343429                          /usr/bin/qemu-img
0065f000-00a60000 rw-p 0065f000 00:00 0 
0755a000-0757b000 rw-p 0755a000 00:00 0                                  [heap]
2b7891471000-2b7891490000 r-xp 00000000 91:e6 254542713                  /lib/x86_64-linux-gnu/ld-2.13.so
2b7891490000-2b7891492000 rw-p 2b7891490000 00:00 0 
2b7891690000-2b7891691000 r--p 0001f000 91:e6 254542713                  /lib/x86_64-linux-gnu/ld-2.13.so
2b7891691000-2b7891692000 rw-p 00020000 91:e6 254542713                  /lib/x86_64-linux-gnu/ld-2.13.so
2b7891692000-2b7891693000 rw-p 2b7891692000 00:00 0 
2b7891693000-2b789169a000 r-xp 00000000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
2b789169a000-2b7891899000 ---p 00007000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
2b7891899000-2b789189a000 r--p 00006000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
2b789189a000-2b789189b000 rw-p 00007000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
2b789189b000-2b78918b2000 r-xp 00000000 91:e6 89718972                   /usr/lib/libz.so.1.2.3.4
2b78918b2000-2b7891ab1000 ---p 00017000 91:e6 89718972                   /usr/lib/libz.so.1.2.3.4
2b7891ab1000-2b7891ab2000 rw-p 00016000 91:e6 89718972                   /usr/lib/libz.so.1.2.3.4
2b7891ab2000-2b7891ab3000 rw-p 2b7891ab2000 00:00 0 
2b7891ab3000-2b7891ace000 r-xp 00000000 91:e6 115417965                  /usr/lib/librbd.so.1.0.0
2b7891ace000-2b7891ccd000 ---p 0001b000 91:e6 115417965                  /usr/lib/librbd.so.1.0.0
2b7891ccd000-2b7891cce000 rw-p 0001a000 91:e6 115417965                  /usr/lib/librbd.so.1.0.0
2b7891cce000-2b7891eca000 r-xp 00000000 91:e6 115417963                  /usr/lib/librados.so.2.0.0
2b7891eca000-2b78920ca000 ---p 001fc000 91:e6 115417963                  /usr/lib/librados.so.2.0.0
2b78920ca000-2b78920d9000 rw-p 001fc000 91:e6 115417963                  /usr/lib/librados.so.2.0.0
2b78920d9000-2b78920ed000 rw-p 2b78920d9000 00:00 0 
2b78920ed000-2b7892147000 r-xp 00000000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
2b7892147000-2b7892347000 ---p 0005a000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
2b7892347000-2b7892349000 r--p 0005a000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
2b7892349000-2b789234a000 rw-p 0005c000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
2b789234a000-2b789234b000 rw-p 2b789234a000 00:00 0 
2b789234b000-2b789234f000 r-xp 00000000 91:e6 152502901                  /lib/libuuid.so.1.3.0
2b789234f000-2b789254e000 ---p 00004000 91:e6 152502901                  /lib/libuuid.so.1.3.0
2b789254e000-2b789254f000 rw-p 00003000 91:e6 152502901                  /lib/libuuid.so.1.3.0
2b789254f000-2b7892550000 r-xp 00000000 91:e6 254542270                  /lib/x86_64-linux-gnu/libaio.so.1.0.1
2b7892550000-2b789274f000 ---p 00001000 91:e6 254542270                  /lib/x86_64-linux-gnu/libaio.so.1.0.1
2b789274f000-2b7892750000 rw-p 00000000 91:e6 254542270                  /lib/x86_64-linux-gnu/libaio.so.1.0.1
2b7892750000-2b7892767000 r-xp 00000000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
2b7892767000-2b7892966000 ---p 00017000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
2b7892966000-2b7892967000 r--p 00016000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
2b7892967000-2b7892968000 rw-p 00017000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
2b7892968000-2b789296d000 rw-p 2b7892968000 00:00 0 
2b789296d000-2b7892ae7000 r-xp 00000000 91:e6 254542727                  /lib/x86_64-linux-gnu/libc-2.13.so
2b7892ae7000-2b7892ce7000 ---p 0017a000 91:e6 254542727                  /lib/x86_64-linux-gnu/libc-2.13.so
2b7892ceAborted


seems to be an older problem:
https://bugzilla.redhat.com/show_bug.cgi?id=548723

still getting the error while trying to convert a vmdk

how to proceed?

I just generated OVA from vsphere client, then I untarred it and I got a ovf and a vmdk file, how do I convert the vmdk to a readable format by kvm?

Angelo, a workaround for me was to run the freetz image (which in fact is an ubuntu image) with VirtalBox. Then I booted the Machine with a systemrescuecd CD.

In systemrescuecd I extracted the disk image using the dd command (disk druid). You can netcat the raw image via network to your KVM machine. The raw image booted without any problems in KVM.

Hope this works for you.

Confirmed on ubuntu 11.10:
>> qemu-img convert ZendTo-Ubuntu-x64-disk1.vmdk -O raw zend.img
qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk': Operation not permitted
qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk'


Hello,
Could someone please comment on this? There are blogs and such all over the internet talking about how easy it is to use qemu-img convert to convert VMware vmdk's to KVM qcow2's (or other formats). However, every time I do this, no matter what version of Linux or qemu-img I am using, it either a) produces an image but that is only a few MBs and thus obviously unbootable; or b) has the error in comment #9 (Operation not permitted). I see thomas303's workaround but that obviously sounds pretty harsh to be doing on a regular basis as we are looking to support our product on both VMware and KVM. Will this inability to convert vmdk to qcow2 be addressed in qemu soon?

@Neil,

it looks like the 2011 google summer of code project did not succeed.  I don't know of anyone else working on this problem right now.

Actually support upstream has improved a lot in recent qemu (thanks to IBM), and Red Hat are planning on doing further work in this area.

Right now / with old qemu, the best thing is to convert your proprietary vmdk files to a portable format, ie. raw or qcow2, and use that instead.

I retried with ubuntu 16.04, qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.4).

While the original file (freetz vmdk) is not available (they use .ova now), I got another .vmdk file from
http://www.osboxes.org/debian/#debian-8-5-vmware

qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O raw test.raw
qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O qcow2 test.qcow2

Both worked, and I could boot the system I converted from .vmdk using qemu-kvm.

Looks as if this issue got fixed, finally.


I did the same task on totally different images recently and it worked fine.
Thanks for bumping that old bug so we can close it.

That "Debian 8.5 (64bit).vmdk" also works fine with the qemu-img from upstream master branch ==> I'm closing this ticket now for upstream, too.

Description of problem:

qemu-img convert cannot convert a VMDK4 format file to (eg) raw (or
anything else).  It silently produces a large file that mostly
contains zero bytes, and is completely unusable.

Version-Release number of selected component (if applicable):

Tested with qemu-img 0.10.5, 0.11.0, and
git d9a50a366f2178 (2009-12-11).

How reproducible:

Always.

Steps to Reproduce:
1. Export to OVF from VMWare vSphere / ESX 4.0.0.
2. Copy the resultant disk image to a Fedora machine.
3. Check the SHA1 sums (from *.mf file) to make sure image was not
   corrupted during the copy.
4. Run:
     qemu-img convert -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw
5. Try to mount / use the resulting raw file, eg. using guestfish.
  
Actual results:

The raw file contains mostly zeroes, see below.  It contains zeroes
where there should be partition tables, superblocks etc. and so is
totally unusable.

Expected results:

A usable disk image.

Additional info:

Compare the entropy of the VMDK file with the resulting raw disk.
I would expect the entropy to be about the same, but you can see the
raw disk is mostly compressible (zeroes).

  $ ls -l TestLinux-disk1.vmdk
  -rw-rw-r--  1 rjones rjones  887312896 2009-12-18 10:35 TestLinux-disk1.vmdk
  $ gzip -c TestLinux-disk1.vmdk | wc -c
  860846320
  $ gzip -c TestLinux-disk1.raw | wc -c
  8744715

VMWare's OVF metadata says the following about the disk format:

  <References>
    <File ovf:href="TestLinux-disk1.vmdk"
          ovf:id="file1" ovf:size="887312896" />
  </References>
  <DiskSection>
    <Info>Virtual disk information</Info>
    <Disk ovf:capacity="8"
          ovf:capacityAllocationUnits="byte * 2^30"
          ovf:diskId="vmdisk1" ovf:fileRef="file1"
          ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" />
  </DiskSection>

qemu-img 0.10.5 fails in a different way.  It gives the error
message:

  qemu-img: error while reading

qemu-img >= 0.11.0 fail silently, no error message or error code.

I've tried this with several disk images exported from vSphere 4
and they have all failed to convert in the same way.

Test files (at time of writing these are STILL UPLOADING, with ETA
of 2009-12-19).

http://homes.merjis.com/~rich/TestLinux-disk1.vmdk
  SHA1: 2C81BAE89210B075ACC51DA9D025935470149D55
http://homes.merjis.com/~rich/TestLinux.ovf
  SHA1: 30831689B8C6F1B1A1FCBB728769B5F71056A580

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

You don't happen to know if this reproduces with qemu-img > 0.12.x or have a test image I can convert to reproduce handy?

Nothing much has changed in the qemu vmdk block
driver since I looked at it before (I just checked upstream
git), so it's very likely to be still broken.

I have some VMDK images, but I warn you that they
are very large!  If you have somewhere I can upload
them to, I can send some your way ...


This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I just checked upstream git for the driver again,
and apart from code cleanups the code is still the
same as ever.  Therefore moving the bug -> Rawhide.

Updated links:
http://oirase.annexia.org/tmp/TestLinux-disk1.vmdk                              
  SHA1: 2c81bae89210b075acc51da9d025935470149d55                                
http://oirase.annexia.org/tmp/TestLinux.ovf                                     
  SHA1: 30831689b8c6f1b1a1fcbb728769b5f71056a580

Latest qemu-img no longer silently converts to zeroes.  Instead
it gives a strange error:

$ qemu-img convert -f vmdk -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw
qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted
qemu-img: Could not open 'TestLinux-disk1.vmdk'

> qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted

This is probably because qemu-img.c code expects  brdv_open() to return an errno value

    ret = bdrv_open(bs, filename, flags, drv);
    if (ret < 0) {
        error_report("Could not open '%s': %s", filename, strerror(-ret));
        goto fail;
    }

while the vmdk_open function just returns -1 for everything:

   ...
    return 0;
 fail:
    qemu_free(s->l1_backup_table);
    qemu_free(s->l1_table);
    qemu_free(s->l2_cache);
    return -1;
}

and by coincidence, '1 == EPERM'.  There are ~4 codepaths in vmdk_open that could fail, the VMDK magic check and then a couple of reads of metadata

There is hope:
http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg03130.html
http://lists.gnu.org/archive/html/qemu-devel/2011-06/threads.html#00033

The vmdk from "Export as OVF..." doesn't work.
# qemu-img convert -O raw esx4.1-rhel5.7-i386-disk1.vmdk test-vmdk.raw
qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk'
qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk'

I copied a vmdk file from ESX storage directly,and then use qemu-img to convert it to raw,it works.
# qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw
# ll test-vmdk.raw 
-rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw

(In reply to comment #11)
> I copied a vmdk file from ESX storage directly,and then use qemu-img to convert
> it to raw,it works.
> # qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw
> # ll test-vmdk.raw 
> -rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw

*-flat.vmdk files are not VMDK.  They are just raw files
which happen to have a .vmdk extension.  So this doesn't
really prove anything.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This bug has lingered for forever, so I don't think tracking this in Fedora is going to solve much.

Rich, if you can still reproduce this with qemu.git, I'd recommend filing an upstream bug and publishing a reproducer image like you did before.