blob: cd9204ac6b50ccf24cd8fa91ad4bb377af0d6073 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
arm: 0.949
architecture: 0.944
register: 0.933
permissions: 0.930
graphic: 0.929
performance: 0.925
assembly: 0.920
semantic: 0.913
socket: 0.913
virtual: 0.911
debug: 0.910
device: 0.896
kernel: 0.885
network: 0.882
boot: 0.881
PID: 0.879
hypervisor: 0.872
ppc: 0.872
TCG: 0.865
vnc: 0.859
VMM: 0.859
KVM: 0.858
peripherals: 0.855
files: 0.853
mistranslation: 0.841
risc-v: 0.839
user-level: 0.836
x86: 0.791
i386: 0.626
qemu-img convert fails to convert, generates a 512byte file output
I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to convert to VirtualBox .vdi format using qemu, the first stage of extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin' just generates a 512byte file:
{quote}
# Disk DescriptorFile
version=1
CID=36be9761
parentCID=ffffffff
createType="twoGbMaxExtentSparse"
# Extent description
RW 4192256 SPARSE "Ubuntu-s001.vmdk"
RW 4192256 SPARSE "Ubuntu-s002.vmdk"
RW 4192256 SPARSE "Ubuntu-s003.vmdk"
RW 4192256 SPARSE "Ubuntu-s004.vmdk"
RW 4192256 SPARSE "Ubuntu-s005.vmdk"
RW 4192256 SPARSE "Ubuntu-s006.vmdk"
RW 4192256 SPARSE "Ubuntu-s007.vmdk"
RW 4192256 SPARSE "Ubuntu-s008.vmdk"
RW 4192256 SPARSE "Ubuntu-s009.vmdk"
RW 4192256 SPARSE "Ubuntu-s010.vmdk"
RW 20480 SPARSE "Ubunt
{quote}
No stack trace or other output was found. Anything I can add (other than the 20G VM image to reproduce and I'll be happy to provide)
On Thu, May 19, 2011 at 5:17 AM, Andy Brook <email address hidden> wrote:
> Public bug reported:
>
> I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to
> convert to VirtualBox .vdi format using qemu, the first stage of
> extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin' just
> generates a 512byte file:
>
> {quote}
> # Disk DescriptorFile
> version=1
> CID=36be9761
> parentCID=ffffffff
> createType="twoGbMaxExtentSparse"
>
> # Extent description
> RW 4192256 SPARSE "Ubuntu-s001.vmdk"
> RW 4192256 SPARSE "Ubuntu-s002.vmdk"
> RW 4192256 SPARSE "Ubuntu-s003.vmdk"
> RW 4192256 SPARSE "Ubuntu-s004.vmdk"
> RW 4192256 SPARSE "Ubuntu-s005.vmdk"
> RW 4192256 SPARSE "Ubuntu-s006.vmdk"
> RW 4192256 SPARSE "Ubuntu-s007.vmdk"
> RW 4192256 SPARSE "Ubuntu-s008.vmdk"
> RW 4192256 SPARSE "Ubuntu-s009.vmdk"
> RW 4192256 SPARSE "Ubuntu-s010.vmdk"
> RW 20480 SPARSE "Ubunt
> {quote}
>
> Here is the input Ubuntu.vmdk file:
> {quote}
> # Disk DescriptorFile
> version=1
> CID=36be9761
> parentCID=ffffffff
> createType="twoGbMaxExtentSparse"
>
> # Extent description
> RW 4192256 SPARSE "Ubuntu-s001.vmdk"
> RW 4192256 SPARSE "Ubuntu-s002.vmdk"
> RW 4192256 SPARSE "Ubuntu-s003.vmdk"
> RW 4192256 SPARSE "Ubuntu-s004.vmdk"
> RW 4192256 SPARSE "Ubuntu-s005.vmdk"
> RW 4192256 SPARSE "Ubuntu-s006.vmdk"
> RW 4192256 SPARSE "Ubuntu-s007.vmdk"
> RW 4192256 SPARSE "Ubuntu-s008.vmdk"
> RW 4192256 SPARSE "Ubuntu-s009.vmdk"
> RW 4192256 SPARSE "Ubuntu-s010.vmdk"
> RW 20480 SPARSE "Ubuntu-s011.vmdk"
>
> # The Disk Data Base
> #DDB
>
> ddb.toolsVersion = "7240"
> ddb.adapterType = "lsilogic"
> ddb.geometry.sectors = "63"
> ddb.geometry.heads = "255"
> ddb.geometry.cylinders = "2610"
> ddb.virtualHWVersion = "6"
> {quote}
>
> No stack trace or other output was found. Anything I can add (other
> than the 20G VM image to reproduce and I'll be happy to provide)
Please post the output of "qemu-img info Ubuntu.vmdk". I suspect this
image file is not being recognized as vmdk and is being treated as a
raw image, hence the literal copy of its 512-byte sector size
contents.
I have CCed Fam who is working on VMDK image format improvements and
may be able to help here.
Stefan
Can you still reproduce this problem with the latest version of QEMU?
[Expired for QEMU because there has been no activity for 60 days.]
|