diff options
Diffstat (limited to 'results/classifier/105/KVM/905095')
| -rw-r--r-- | results/classifier/105/KVM/905095 | 391 |
1 files changed, 391 insertions, 0 deletions
diff --git a/results/classifier/105/KVM/905095 b/results/classifier/105/KVM/905095 new file mode 100644 index 000000000..262e7c51d --- /dev/null +++ b/results/classifier/105/KVM/905095 @@ -0,0 +1,391 @@ +KVM: 0.766 +graphic: 0.712 +device: 0.709 +mistranslation: 0.708 +instruction: 0.692 +semantic: 0.683 +assembly: 0.681 +boot: 0.675 +network: 0.669 +socket: 0.659 +other: 0.658 +vnc: 0.644 + +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. + |