It can show basic information about the image or resize the virtual disk it contains.
Resizing is done by:
- creating modified copy of the image (original one is safe as it's not being modified at all) or
- in-place modification of the image
vidma INPUT_FILE # show information about the INPUT_FILE image vidma INPUT_FILE NEW_SIZE_IN_MB # resize the INPUT_FILE image in-place vidma INPUT_FILE NEW_SIZE_IN_MB OUTPUT_FILE # create resized image of INPUT_FILE into OUTPUT_FILE # (OUTPUT_FILE must be different than INPUT_FILE!)Resize operation requires your confirmation, so don't panic when you hit Enter without rechecking all the arguments provided to vidma before.
Check also manual page for details on command-line syntax and more.
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 in-place operations at all.
To avoid in-place modifications always provide output file in the command line, which must be different than input file.
PLEASE USE ONLY THE LATEST VERSION.
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.
- little-endian machine, e.g. x86, x86-64
- Windows or POSIX OS, e.g. BSD, Linux, Mac OS X
What's new in version 0.0.4 (2012-12-31)
- Unallocated blocks of zeroes are handled now properly (important for shrinking dynamic images). Bug discovered thanks to Romain Guinot.
- Non-zero extra blocks are supported now.
- Upcoming image size change is shown before the resize operation, along with the required free space for the operation and free space that is available on the volume at this moment.
- Messages printed by vidma have been slightly changed.
- Simple configure script has been added. You have to run it before invoking make. Building outside of the source directory is now supported.
- Manual page has been added.
- Resizing dynamic VDI files is finally supported!
First expanding will (almost) always move blocks, but next ones will do it only if you cross 255 GB boundary, and again for ~512 GB, etc. In future it will be fixed, i.e. all block moving will be avoided for second and further resizes if block size equals multiple of 1 megabyte (I haven't seen any image "breaking" this rule in the wild, but it's possible).
Even shrinking is possible, but only if does not involve discarding of allocated blocks. In future it will be also fixed with implementation of block linearization.
- Many restrictive assumptions about supported VDI files has been removed. Images created in VirtualBox 4.x should work fine now. Still only fixed ones can be resized.
- Before resizing user gets information about upcoming operation and question whether it should be really performed.
- Resizing strategy has been changed. Old one was almost always moving blocks, which is simply stupid and inefficient. Now if data offset can be preserved, i.e. there is enough space for block allocation map, block moving will be avoided. If it cannot be avoided, then new data offset will be aligned to megabyte. It nicely prevents from moving blocks in possible future resizes (unless you cross 255 GB boundary).
- Running in Windows 2000 is possible now.
- Nothing, it's just the first public version.
GNU General Public License v2
Links
git clone [url=git://github.com/przemoc/vidma.git]git://github.com/przemoc/vidma.git[/url]
Repositories: GitHub
Source code: tar.gz archive from master branch
Executables: Windows (32-bit)
Packages: ArchLinux [0.0.3b in AUR], PLD [0.0.4]
Manual page: vidma(1)
Reporting issues: please read Bugs section of README file
Latest release direct links
Source code (tar.gz): 0.0.4 @przemoc.net, 0.0.4 @github.com
Windows 32-bit executable (exe): 0.0.4 @przemoc.net, 0.0.4 @github.com
Walk-throughs
Building vidma straight from git repository and converting 2 GB fixed VDI into 75 GB dynamic VDI (Linux, v0.0.3b+)
Creating 1 GB fixed VDI in VBoxManage and resizing it in vidma (Windows, v0.0.4)
Some details on VDI format
There is so called virtual machine, VM for short. It's the "virtual computer" that you run in VirtualBox (VB). It has many components, just like real computer, some of them are (hard) disks, or virtual (hard) disks if we want to be precise, sometimes called VD or VHD for short. VDI is one of formats of virtual disk images, introduced by VB and mostly used by it. VDI stands for "VirtualBox Disk Image" (or "Virtual Disk Image"). VDI has a few variants like fixed, dynamic and some snapshot related ones (snapshot images are not supported by vidma yet).
VDI consists of 3 areas:
- preheader + header (start),
- block allocation map (BAM),
- allocated blocks (data).
BAM is populated with 3 types of entries:
- allocated block (the only one used in fixed VDI),
- zero-filled (unallocated) block,
- unallocated block.
You have to understand that vidma works only at virtual disk level, i.e. it can resize your VDI, but it won't alter its partitions and partition table before or after the change. It's up to you - you can do it using e.g. GParted that is available in the handy Parted Magic bootable live CD.
With vidma you can shrink the VD in-place.
If it's a fixed VDI, there is no restriction upon new size, so be extremely careful. You'll see below warning in such cases. You should perform such operation only when you're sure that it's safe - that usually requires shrinking partitions before shrinking the virtual disk image.
WARNING Shrinking disk in-place means IRRETRIEVABLY LOSING DATA KEPT BEYOND NEW SIZE!If it's a dynamic VDI, then there is one simple restriction: you cannot lose any data - so it's not as flexible as in the case of fixed one, but it's quite safe. But... relying solely on blocks with data (allocated or zeroes) is not enough to be 100% safe, because filesystem format (rarely modifying whole partition nowadays) could simply not modify the last sector of the partition and similarly user's files could not reach that point either yet. In such case you can shrink the image more than you should, making last partition(s) geometry no longer correct, breaking file system size metadata (if stored), and so on... literally asking for lots of trouble. But unless you use such image and make the damage running it under VM, this image is perfectly fine in terms of data stored in it and can be "cured" by enlarging it to the point where last partition ends.
Afterword
I repeat it once again: This tool is not well tested, so always have a backup of image you want to modify in-place. OTOH I hope that VB community will help me here by testing it on wide range of platforms (currently only little-endian machines are supported) and finding bugs.