Trying to convert from .img to .vdi using "convertfromraw": VERR_VD_INVALID_SIZE

[tirengarfio@gmail.com]

Hi,

I'm getting this error when trying to convert a .img file to .vdi file.

VBoxManage convertfromraw file.img file.vdi
Converting from raw image file="file.img" to file="file.vdi"...
Creating dynamic image with size 814188811483 bytes (776471MB)...
VBoxManage: error: VD: The given disk size 814188811483 is not aligned on a sector boundary (512 bytes)
VBoxManage: error: Error code VERR_VD_INVALID_SIZE at /home/vbox/vbox-6.0.10/src/VBox/Storage/VD.cpp(6231) in function int VDCreateBase(PVDISK, const char*, const char*, uint64_t, unsigned int, const char*, PCVDGEOMETRY, PCVDGEOMETRY, PCRTUUID, unsigned int, PVDINTERFACE, PVDINTERFACE)
VBoxManage: error: Cannot create the disk image "file.vdi": VERR_VD_INVALID_SIZE

I got the .img file using "dd" command.

Im using VB 6.0.10 on Ubuntu 14.04.

[fth0]

Ensure that the file size of file.img is a multiple of 512.

[tirengarfio@gmail.com]

How can I do that? just adding bs=512 to the "dd" command?

EDIT: yeah, I have used "qemu-img resize test.img 800G" and the conversion to .vdi is working ok! I have set 800G because my file was 766GB.

[mpack]

the conversion to .vdi is working ok!

There is no conversion going on, all convertfromraw does is put a VDI header ahead of any file you give it. So if the IMG is garbage then the result disk's content will be garbage.

The reason I say that is that I can't think of any legitimate disk imaging process that creates a disk image that isn't a multiple of 512 bytes. If it isn't a raw disk image then "convertfromraw" will create garbage out.

[tirengarfio@gmail.com]

I'm converting a 800GB .img file to .vdi. How big will be the file .vdi file? also 800GB? In that case I will not have enough size in my disk.. any solution?

[socratis]

How can I do that? just adding bs=512 to the "dd" command?

I don't know what your host is, or what the 'dd' implementation is, but from the 'man' page on my OSX host I see (emphasis mine):

$ man dd
NAME
     dd -- convert and copy a file

SYNOPSIS
     dd [operands ...]

DESCRIPTION
     The dd utility copies the standard input to the standard output.  Input
     data is read and written in 512-byte blocks.  If input reads are short,
     input from multiple reads are aggregated to form the output block.  When
     finished, dd displays the number of complete and partial input and output
     blocks and truncated input records to the standard error output.

     The following operands are available:

     bs=n     Set both input and output block size to n bytes, superseding the
              ibs and obs operands.  If no conversion values other than
              noerror, notrunc or sync are specified, then each input block is
              copied to the output as a single block without any aggregation
              of short blocks.
...

So, unless you specifically set the 'bs' operand to something non-default, it should be a 512-byte multiple.

[socratis]

Convert from .img to .vdi: about the final size of the .vdi file

I honestly don't see the reason that you had to create a new thread... Merged it with the thread that was already dealing with the issue.

I'm converting a 800GB .img file to .vdi. How big will be the file .vdi file?

It depends on how the conversion is done. If the "conversion" discards zeroed out blocks, then it will be smaller. But, since you're doing a 'dd', I would expect the image (.img) to be the same size as your original hard drive. After that, I don't know how 'VBoxManage convertfromraw' would work. Chances are it discards the zeroed out blocks...

In that case I will not have enough size in my disk.. any solution?

Get an external HD?

[tirengarfio@gmail.com]

There is no conversion going on, all convertfromraw does is put a VDI header ahead of any file you give it.

Thanks for your help guys, the conversion is taking a lot of time, so it is creating a new .vdi file from scratch, is that ok?

[socratis]

Creating dynamic image with size 814188811483 bytes (776471MB)...

the conversion is taking a lot of time, so it is creating a new .vdi file from scratch, is that ok?

You are copying a file with a size of 814188811483 bytes (= 795106261.21 KB = 776470.96 MB = 758.27 GB). Wouldn't you expect that copying 758 GB would take some time? Yes, it sounds normal.

Do you have the available free space on your destination for such a big file? You don't want to run out of space at the 93% of the conversion done...

[tirengarfio@gmail.com]

Do you have the available free space on your destination for such a big file? You don't want to run out of space at the 93% of the conversion done...

Right now I have 309GB free available and the .vdi file is 240GB now. Is there any chance that the final .vdi file will just be 550GB or less?

[socratis]

Unfortunately my crystal ball is at the shop for repairs...

Seriously now, I honestly don't know, how can I possibly know? If I was in your shoes, I wouldn't take that chance. I wouldn't want my host to run out of free space. I've seen things, bad things happening in such a scenario, mostly corrupted files...

[mpack]

I'm pretty sure that "convertfromraw" will not discard zero blocks. AFAIK it isn't running a disk cloning function - because the raw file isn't treated as a disk image, just as a raw file. All that convertfromraw does is create a header then append the data.

So yes, it will be 800GB plus the header.

If it's a genuine disk image (doubtful), with a filesystem it recognizes, then CloneVDI can clone a raw file and compact it at the same time. As a Win32 app you'll need Wine to run it on a Linux host.

[tirengarfio@gmail.com]

Well, finally I got one more 1.5 TB disk. Starting to convert again..

[tirengarfio@gmail.com]

The conversion to .vdi has finished. So I have created a virtual machine, but now Im getting this below when trying to start the virtual machine:

foo.png (6.24 KiB) Viewed 8482 times

[mpack]

This was explained above. Garbage In, Garbage Out. If you can't explain why the "img" file was a strange size then the entire process was suspect from the start.