przemoc / vidma Goto Github PK

View Code? Open in Web Editor NEW

12.0 4.0 0.0 220 KB

Utility for manipulating virtual disk images: VDI.

Home Page: http://tinyurl.com/vbox-vidma

License: GNU General Public License v2.0

C 100.00%

c vdi virtualbox

vidma's Introduction

vidma - Virtual Disks Manipulator

vidma is a utility for manipulating virtual disk images. It can show basic information about the image or resize it. Resizing is done by in-place modification of a file holding the image or by creating modified copy of such file.

Supported formats

VDI - Virtual Disk Image
Format introduced by VirtualBox and mostly used by VirtualBox. It has a few variants, but only two types, fixed and dynamic, are handled by vidma.

Requirements

little-endian machine, e.g. x86, x86-64
Windows or POSIX OS, e.g. BSD, Linux, Mac OS X

Bugs

If you find any bug, then please create a new issue in the project's GitHub page and describe the problem there, unless someone already did it before you.

Remember to provide following information:

What system do you have?
(uname -a, lsb_release -drc)
What compiler do you use? (if you have built vidma manually)
(cc -v)
What vidma version are you using?
(first line of vidma output)
What have you done?
(run history and check the commands used to compile and run vidma)
If problem regards corrupted image, then paste information about the original image and the one after failed modification.
(vidma original_image_file, vidma modified_image_file)

Development

Roadmap

Stages:

alpha (works for me?)
- 0.0.x
- 0.1.x
- 0.2.x
beta (works for you?)
- 0.3.x
- 0.4.x
release candidate (works for everyone?)
- 0.5.x
ready (just works!)

Hacking

Don't waste your time until vidma will be close to beta stage. I mean it.
I am aware of many shortcomings (some are listed in issues w/ todo label) and they will be eventually addressed (in no particular order).

I won't accept any pull request before releasing version 0.2.0. ;-)

CAUTION!

Program is in ALPHA stage, therefore may be HARMFUL and UNSAFE!
You have been warned! USE AT YOUR OWN RISK! NO WARRANTY!

To reduce possible damages of in-place operation ALWAYS BACKUP YOUR IMAGE or just do not use them at all.

vidma's People

Contributors

Stargazers

Watchers

vidma's Issues

Support VDIs created in recent VirtualBox versions

There are some assumptions in the code that can be relaxed.

Implement decent option parsing

vidma [OPTION]... FILE [OPERATION [PARAMETER]...]... [\; FILE [OPERATION [PARAMETER]...]...]...

Support for defining many operations in one vidma invocation should be useful. Support for working on many files in one invocation doesn't look that important, but could be useful too. It may require also automatic stdin/stdout folding to make possible and meaningful below command:

vidma test.vdi export \; test.vmdk import

which could be substituted by (possibly less efficient):

vidma test.vdi export | vidma test.vmdk import

It must be checked whether above options model is achievable using one of following mechanisms:

getopt
Rusty's opt
my (written for pcspk) popt
RedHat's popt
argopt
(other open source solutions)

Support operations

Operations:

info - default one
check
cat
resize
import
export
mount
internal - format specific actions and modifications

VDI specific actions and modifications:

--compact
--linearize
--format=FORMAT
--blk-count=BLK_COUNT
--bam-alignment=ALIGNMENT
--bam-offset=OFFSET
--data-alignment=ALIGNMENT
--data-offset=OFFSET
--do-not-move-bam
--do-not-move-data
...

It's advisable to implement operations for particular formats on top of format specific actions and modifications. Format specific actions/modifications may be useful for power users.

This issue will be splitted in future.

Remove code from the header

common.h has some platform-dependent code that must be extracted from it before any further development.

start fail when enlarger vdi disk space

VBox 3.1.2.56127
host system: ArchLinux
guest system: winxp professional

a error message is displayed when start guest system:

A disk read error occurred
press Ctrl+Alt+Delete to restart

Support more virtual disk formats

Most common ones beside VDI:

VMDK - Page | Virtual Disk Format 1.1
VHD - Page | Virtual Hard Disk Image Format Specification 1.0
QCOW2 - The QCOW2 Image Format

Less known:

QED - Specification
Parallels'

Something is likely wrong when calculating the minimum block count

Hi,

Thanks for the tool it is useful !
I noticed however that the minimum block count was wrong in my case, it wouldn't allow me to shrink a virtual disk size.
I commented out that check and everything worked out OK. See description below :

-- tests on Jul 28,2012 :

romain@host:[/opt/vboxes]$ vidma test.vdi 8448
Recognized file format:
        Virtual Disk Image (vdi)

Requested disk resize
from                130047 block(s)
to                    8448 block(s)
(each block has    1048576 bytes)
But minimal possible block count equals
                4294967295 block(s)
Resize aborted.

comment out that check in vdi.c :

diff --git a/vdi.c b/vdi.c
index 5cfc600..652c795 100644
--- a/vdi.c
+++ b/vdi.c
@@ -322,12 +322,12 @@ static int resize_confirmation(vdi_start_t *vdi, int fin, int fout,
        if (vdi->header.type == VDI_DYNAMIC) {
                find_last_blocks(vdi, fin, &last_blk_no, &last_blk_pos);
                min_blk_count = max_u32(last_blk_no, last_blk_pos) + 1;
-               if (new_blk_count < min_blk_count) {
-                       ui->log("But minimal possible block count equals\n"
-                               "     %21u block(s)\n",
-                               min_blk_count);
-                       return FAILURE;
-               }
+//             if (new_blk_count < min_blk_count) {
+//                     ui->log("But minimal possible block count equals\n"
+//                             "     %21u block(s)\n",
+//                             min_blk_count);
+//                     return FAILURE;
+//             }
        }

        ui->log("\nDisk size will change\n"

works out OK :

Recognized file format:
        Virtual Disk Image (vdi)

Requested disk resize
from                130047 block(s)
to                    8448 block(s)
(each block has    1048576 bytes)

Disk size will change
from          136364163072 bytes (         130047 MB)
to              8858370048 bytes (           8448 MB)

Image size will change
from            1453850624 bytes (           1386 MB)
to              1453850624 bytes (           1386 MB)

Resize operation in fact will create resized copy of the image.
NOTE    UUID of the new image will be the same as old one.
NOTE    Input file is safe and won't be modified.

Are you sure you want to continue? (y/N) y

Operation: Resize
[1/4] Copying blocks: 1386/1386 Done
[1/4] Syncing
[1/4] Data copied (1386 blocks in 4734 ms = ~306 B/us)
[2/4] Updating block allocation map: Done
[2/4] Syncing
[3/4] Updating file size: Done
[3/4] Syncing
[4/4] Updating header: Done
[4/4] Syncing
Operation finished

header.offset.data               = 00080000 524288
header.disk.size                 = 0000000210000000 8858370048
header.disk.blk_count            = 00002100 8448
header.disk.blk_count_alloc      = 0000056a 1386
header.lchs.cylinders            = 00000000 0
header.lchs.heads                = 00000000 0
header.lchs.sectors              = 00000000 0

The VM worked fine afterwards.
I had prior to the resize defragmented and shrunk the vm partition of the windows guest down with gparted live CD, to the size that i then requested with vidma.

Something must be wrong in find_last_blocks, but i have not investigated further.
Let me know what you think,

Regards,
Romain.