vidma - Virtual Disks Manipulator (tool for resizing VDI)

Discussions related to using VirtualBox on Linux hosts.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: vidma - new utility for resizing fixed-size VDI

Post by mpack »

sej7278 wrote:my thoughts exactly, i'm not in the slightest interested in clonevdi for just those reasons (or the opposite of those reasons, you know!)
also, being commandline i prefer.
I sometimes despair of the Linux heads. You guys just don't seem to get that, for the vast majority of computer users today, a command line is a relic from the dark ages. My personal attitude is that being forced to use a command line to perform common tasks in ordinary circumstances is frankly a sign of laziness or incompetence or both on the part of the programmer. Certainly it is a sign that one should be looking for alternatives.
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - new utility for resizing fixed-size VDI

Post by przemoc »

mpack wrote:Wow, you get distracted for five minutes and suddenly everybody is talking about you behind your back! :-)
Today - talks, tomorrow - snaps. Be prepared for the worst! ;)
mpack wrote:
przemoc wrote:[mpack's CloneVDI tool] can only create new image, which is optionally expanded version of original one. It cannot shrink (at all) and increase VDI size in-place.
As Microsoft likes to say, "that behaviour is by design". IMHO, only a fool makes significant and risky in-place mods without making a backup copy of the VDI first. And if you need to copy the file anyway then what exactly is the advantage of doing anything "in place"?
Fool? Harsh words. One year ago I created vidma prototype (and the source code wasn't touched until this week; I just reached a conclusion that after small polishing and releasing it may be useful for sb; to be honest then I didn't know about CloneVDI), because I was low on disk space. There can be other reasons for such "foolish" behavior. Copying .vdi before resizing is just my advice, because vidma is in alpha stage and not well-tested. It works for me and should for you, but no warranty. Risky? Sure, expanding in-place original VDI is problematic if power failure (or SIGINT, SIGKILL, etc.) hits you before the end of this operation, but this will be partially fixed in future versions.
mpack wrote:On the "shrink" feature, this also was not an oversight. My existing interface (and underlying code) is perfectly capable of doing it, were it not for the fact that I put code in there to explicitly prevent it, i.e. to complain if the new size is smaller than the existing disk. I cannot imagine what useful purpose is served by the ability to shrink the virtual size of a disk (as opposed to compacting to reduce the actual size of the image file). IMHO, users often find that they made the disk too small and want to enlarge it. I don't remember reading a single post from a user wanting to reduce the virtual size of the disk. Put such a useless but potentially disasterous feature in the hands of novice users? No thanks!
Who said this tool is intended for novice users? Novice user can be also unaware of differences between virtual disk, partition and file system, i.e. identify one thing with the other and be surprised seeing that expanded vdi != expanded C: in Windows. It depends on a definition of novice user, but I can agree that shrinking is generally more dangerous operation, i.e. needs more attention before doing it.

You've made your own decisions, I've made my... Variety is a good thing and I don't see any problems with coexistence of our projects.
mpack wrote:
sej7278 wrote:my thoughts exactly, i'm not in the slightest interested in clonevdi for just those reasons (or the opposite of those reasons, you know!)
also, being commandline i prefer.
I sometimes despair of the Linux heads. You guys just don't seem to get that, for the vast majority of computer users today, a command line is a relic from the dark ages. My personal attitude is that being forced to use a command line to perform common tasks in ordinary circumstances is frankly a sign of laziness or incompetence or both on the part of the programmer. Certainly it is a sign that one should be looking for alternatives.
De gustibus et coloribus non est disputandum. What can I say more? E.g. even on Windows I'm using command-line-oriented tools. FAR is the one of my first executed programs every time I boot into Windows, but many users prefer Total Commander. What does it mean? That I likely count among niche of happy CLI apps users, nothing more. Still, Windows shell aka cmd.exe is terrible and I think this the main reason why Windows people dislike command-line. :-)
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: vidma - new utility for resizing fixed-size VDI

Post by mpack »

przemoc wrote:
mpack wrote:IMHO, only a fool makes significant and risky in-place mods without making a backup copy of the VDI first.
Fool? Harsh words. ... Copying .vdi before resizing is just my advice, because vidma is in alpha stage and not well-tested.
My comment (ditto for other comments) was not an attack aimed at you, it was a simple (but emphatic) statement of a widely recognized fact: that one would be foolish to make potentially damaging edits to your only copy of important data. I doubt that statement is controversial, and it would be true regardless of alpha, beta, release etc lifecycle stage, and regardless of how well tested the tool in question has been.
przemoc wrote:
mpack wrote:On the "shrink" feature, this also was not an oversight. My existing interface (and underlying code) is perfectly capable of doing it, were it not for the fact that I put code in there to explicitly prevent it, i.e. to complain if the new size is smaller than the existing disk. I cannot imagine what useful purpose is served by the ability to shrink the virtual size of a disk (as opposed to compacting to reduce the actual size of the image file). IMHO, users often find that they made the disk too small and want to enlarge it. I don't remember reading a single post from a user wanting to reduce the virtual size of the disk. Put such a useless but potentially disasterous feature in the hands of novice users? No thanks!
Who said this tool is intended for novice users?
I have no problem with advanced features that serve a useful purpose - though one should of course attempt to accomodate novices too if possible. What I saw no point in was having a feature which is useless to advanced users and disasterous in the hands of a novice.
przemoc wrote:You've made your own decisions, I've made my... Variety is a good thing and I don't see any problems with coexistence of our projects.
Same here. I'm content to let users decide which tool they wish to use.
sej7278
Volunteer
Posts: 1003
Joined: 5. Sep 2008, 14:40
Primary OS: Debian other
VBox Version: PUEL
Guest OSses: Solaris, Linux, Windows, OS/2, MacOSX, FreeBSD
Contact:

Re: vidma - new utility for resizing fixed-size VDI

Post by sej7278 »

mpack wrote:
sej7278 wrote:my thoughts exactly, i'm not in the slightest interested in clonevdi for just those reasons (or the opposite of those reasons, you know!)
also, being commandline i prefer.
I sometimes despair of the Linux heads. You guys just don't seem to get that, for the vast majority of computer users today, a command line is a relic from the dark ages. My personal attitude is that being forced to use a command line to perform common tasks in ordinary circumstances is frankly a sign of laziness or incompetence or both on the part of the programmer. Certainly it is a sign that one should be looking for alternatives.
a decent design would be to have the backend as commandline and optionally wrap a cross-platform gui around it - such as QT as used by virtualbox itself; so you're not forced to use a gui.

i usually find that i start off using the gui and then want to automate things and do things faster so switch to the commandline and never look back - one example being a windows-only dvd transcoder, once i realised it was only using mencoder as a backend, i just wrote a script to do it in linux and can now transcode 4 dvd's at once under linux with one command; so i don't even need to boot a windoze vm to transcode a single dvd.

windoze "heads" don't get it as they've only seen rubbish like the dos prompt.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: vidma - new utility for resizing fixed-size VDI

Post by mpack »

sej7278 wrote:a decent design ... so you're not forced to use a gui
First, I don't believe in two part designs: it just adds more failure modes with few benefits. Second, you are not forced to use a GUI - command line lovers can continue to use VBoxManage or the OPs tool. I don't see QT as a credible - or necessary - alternative to Win32. First the fact that it's now owned by Nokia makes me concerned abouts its long term status. Also it would bulk out the download (presently less than 100K) with absolutely no benefit for the majority of my users.
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator

Post by przemoc »

vidma 0.0.2 has been released

See NEWS file for user visible changes.
Go to the 1st post for general information.

It's mostly a maintenance release, because previous version did not work with VDIs created in VirtualBox 4.

P.S. It's not the last version in this year. I promise. ;)
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator (tool for resizing VDI)

Post by przemoc »

vidma 0.0.3 has been released

See NEWS file for user visible changes.
Go to the 1st post for general information.

Finally you can resize dynamic VDI files using vidma.
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator (tool for resizing VDI)

Post by przemoc »

vidma 0.0.3a has been released

See NEWS file for user visible changes.
Go to the 1st post for general information.

Manual page has been added.

BTW Since version 0.0.3 vidma is in PLD Linux Distributiion repositories.
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator (tool for resizing VD

Post by przemoc »

vidma 0.0.3b has been released

See NEWS file for changes.
Go to the 1st post for general information.

It's mostly I'm-not-dead-yet release. :)
Code was "waiting" in my local repository to be pushed into github for months. I didn't have time to implement any noteworthy feature in the end, but you can clearly see changes to ease adding GUI in the future (and if it will happen, then it will be Qt - of course optional, so you'll be always able to build vidma without GUI). But if I was going to push, why not release a new version? So I did.

Hopefully I'll release at least one another version this year with more visible changes.
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator (tool for resizing VD

Post by przemoc »

There were small, but rather important improvements since 0.0.3b has been released, so please use the latest version from git. Sorry for late info here on the VB forums.
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator (tool for resizing VD

Post by przemoc »

Building vidma straight from git repository and converting 2 GB fixed VDI into 75 GB dynamic VDI (Linux, v0.0.3b+)
  1. Get vidma from git repository.

    Code: Select all

    przemoc@vostro:~$ git clone git://github.com/przemoc/vidma.git
    Cloning into 'vidma'...
    remote: Counting objects: 172, done.
    remote: Compressing objects: 100% (136/136), done.
    remote: Total 172 (delta 106), reused 57 (delta 31)
    Receiving objects: 100% (172/172), 71.03 KiB, done.
    Resolving deltas: 100% (106/106), done.
  2. Build it and see the usage info.

    Code: Select all

    przemoc@vostro:~$ cd vidma/
    przemoc@vostro:~/vidma$ ./configure 
    przemoc@vostro:~/vidma$ make
    cc -Wall -O2 -std=c99 -Wno-variadic-macros -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -DVIDMA_VERSION="\"v0.0.3b-9-ga48c5a5\""   -c -o main.o main.c
    cc -Wall -O2 -std=c99 -Wno-variadic-macros -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -DVIDMA_VERSION="\"v0.0.3b-9-ga48c5a5\""   -c -o vdi.o vdi.c
    cc -Wall -O2 -std=c99 -Wno-variadic-macros -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -DVIDMA_VERSION="\"v0.0.3b-9-ga48c5a5\""   -c -o ui-cli.o ui-cli.c
    cc -Wall -O2 -std=c99 -Wno-variadic-macros -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -DVIDMA_VERSION="\"v0.0.3b-9-ga48c5a5\""   -c -o common_posix.o common_posix.c
    cc  -o vidma main.o vdi.o ui-cli.o common_posix.o
    przemoc@vostro:~/vidma$ ./vidma 
    vidma - Virtual Disks Manipulator, v0.0.3b-9-ga48c5a5
    (C) 2009-2011 Przemyslaw Pawelczyk
    
    Usage: ./vidma INPUT_FILE [NEW_SIZE_IN_MB [OUTPUT_FILE]]
    
    USE AT YOUR OWN RISK! NO WARRANTY!
    
  3. Check the free space for (new) expanded VDI. (vidma doesn't do it yet)

    Code: Select all

    przemoc@vostro:~/vidma$ df -m ~/vdi/  # do we have enough free space, i.e. more than 76800 MB?
    Filesystem     1M-blocks  Used Available Use% Mounted on
    /dev/sda6          75095 40710     30570  58% /home
    przemoc@vostro:~/vidma$ # no, so we have to switch to dynamic vdi
  4. Check the image information before going further.

    Code: Select all

    przemoc@vostro:~/vidma$ ./vidma ~/vdi/old-fixed.vdi 
    Recognized file format:
            Virtual Disk Image (vdi)
    
    pre.file_info                    = <<< Oracle VM VirtualBox Disk Image >>>
    
    pre.signature                    = beda107f 3201962111
    version                          = 00010001 65537
    header.size                      = 00000190 400
    header.type                      = 00000002 2 (fixed)
    header.flags                     = 00000000 0
    header.offset.bam                = 00001000 4096
    header.offset.data               = 00003000 12288
    header.pchs.cylinders            = 00000000 0
    header.pchs.heads                = 00000000 0
    header.pchs.sectors              = 00000000 0
    header.pchs.sector_size          = 00000200 512
    header.dummy                     = 00000000 0
    header.disk.size                 = 0000000080000000 2147483648
    header.disk.blk_size             = 00100000 1048576
    header.disk.blk_extra_data       = 00000000 0
    header.disk.blk_count            = 00000800 2048
    header.disk.blk_count_alloc      = 00000800 2048
    header.uuid.create               = aef545dd-77a6-418d-83f1-046ca1feb0c4
    header.uuid.modify               = ed52a21b-4bd6-4fa9-8a75-f1fd33b59391
    header.uuid.linkage              = 00000000-0000-0000-0000-000000000000
    header.uuid.parent_modify        = 00000000-0000-0000-0000-000000000000
    header.lchs.cylinders            = 00000000 0
    header.lchs.heads                = 00000000 0
    header.lchs.sectors              = 00000000 0
    header.lchs.sector_size          = 00000200 512
    
  5. Copy the image and convert it to dynamic VDI

    Code: Select all

    przemoc@vostro:~/vidma$ cp -pr ~/vdi/old-fixed.vdi ~/vdi/new.vdi
    przemoc@vostro:~/vidma$ printf '\x01' | dd of=~/vdi/new.vdi bs=1 seek=76 count=1 conv=notrunc  # convert fixed vdi to dynamic
    1+0 records in
    1+0 records out
    1 byte (1 B) copied, 0.00877378 s, 0.1 kB/s
    
  6. Check the new image information. (well, we changed only one byte, not much to check...)

    Code: Select all

    przemoc@vostro:~/vidma$ ./vidma ~/vdi/new.vdi 
    Recognized file format:
            Virtual Disk Image (vdi)
    
    pre.file_info                    = <<< Oracle VM VirtualBox Disk Image >>>
    
    pre.signature                    = beda107f 3201962111
    version                          = 00010001 65537
    header.size                      = 00000190 400
    header.type                      = 00000001 1 (dynamic)
    header.flags                     = 00000000 0
    header.offset.bam                = 00001000 4096
    header.offset.data               = 00003000 12288
    header.pchs.cylinders            = 00000000 0
    header.pchs.heads                = 00000000 0
    header.pchs.sectors              = 00000000 0
    header.pchs.sector_size          = 00000200 512
    header.dummy                     = 00000000 0
    header.disk.size                 = 0000000080000000 2147483648
    header.disk.blk_size             = 00100000 1048576
    header.disk.blk_extra_data       = 00000000 0
    header.disk.blk_count            = 00000800 2048
    header.disk.blk_count_alloc      = 00000800 2048
    header.uuid.create               = aef545dd-77a6-418d-83f1-046ca1feb0c4
    header.uuid.modify               = ed52a21b-4bd6-4fa9-8a75-f1fd33b59391
    header.uuid.linkage              = 00000000-0000-0000-0000-000000000000
    header.uuid.parent_modify        = 00000000-0000-0000-0000-000000000000
    header.lchs.cylinders            = 00000000 0
    header.lchs.heads                = 00000000 0
    header.lchs.sectors              = 00000000 0
    header.lchs.sector_size          = 00000200 512
    
  7. Resize new VDI in-place

    Code: Select all

    przemoc@vostro:~/vidma$ ./vidma ~/vdi/new.vdi 76800  # resize vdi in-place; it's safe, because we still have the original one
    Recognized file format:
            Virtual Disk Image (vdi)
    
    Requested disk resize
    from                  2048 block(s)
    to                   76800 block(s)
    (each block has    1048576 bytes + 0 extra bytes)
    
    Disk size will change
    from            2147483648 bytes (           2048 MB)
    to             80530636800 bytes (          76800 MB)
    
    Image size will change
    from            2147495936 bytes (           2048 MB)
    to              2148532224 bytes (           2049 MB)
    
    Resize operation will be performed in-place.
    WARNING All allocated blocks require moving.
            In case of fail DATA LOSS is highly POSSIBLE!
            Think twice before continuing!
    
    Are you sure you want to continue? (y/N) y
    
    Operation: Resize
    [1/4] Moving blocks: 2048/2048 Done
    [1/4] Syncing
    [1/4] Data moved (2048 blocks by 1036288 bytes in 53033 ms = ~40 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               = 00100000 1048576
    header.disk.size                 = 00000012c0000000 80530636800
    header.disk.blk_count            = 00012c00 76800
    header.disk.blk_count_alloc      = 00000800 2048
    header.lchs.cylinders            = 00000000 0
    header.lchs.heads                = 00000000 0
    header.lchs.sectors              = 00000000 0
    
And that's it. New VDI has the same UUID as the old one, so they cannot coexist in VirtualBox. You have to release the old image (EDIT: You do it from File menu -> Virtual Media Manager accessible also via Ctrl+D shortcut) and register the new one (EDIT: I wasn't clear enough here and it can be misleading for newbies. You don't explicitly register new image, you do it implicitly via attaching it to your VM to a given virtual disk, and you do it in the Storage view from Machine menu -> Settings accessible also via Ctrl+S shortcut). Verify that everything works before deleting the old image.

---

Last step (EDIT: I'm referring to the above step 7) can be done with VBoxManage (EDIT: i.e. instead of using vidma):

Code: Select all

przemoc@vostro:~/vidma$ VBoxManage modifyhd ~/vdi/new.vdi --resize 76800
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
---

In case you'd want to preserve having fixed VDI as new image, you could replace steps 5-7 with following one (assuming you have enough free space):

Code: Select all

przemoc@vostro:~/vidma$ ./vidma ~/vdi/old-fixed.vdi 76800 ~/vdi/new.vdi 
Recognized file format:
        Virtual Disk Image (vdi)

Requested disk resize
from                  2048 block(s)
to                   76800 block(s)
(each block has    1048576 bytes + 0 extra bytes)

Disk size will change
from            2147483648 bytes (           2048 MB)
to             80530636800 bytes (          76800 MB)

Image size will change
from            2147495936 bytes (           2048 MB)
to             80531685376 bytes (          76801 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) 
Last edited by przemoc on 2. Jan 2013, 20:14, edited 4 times in total.
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
JonH
Posts: 37
Joined: 25. Oct 2012, 03:03
Primary OS: Mac OS X other
VBox Version: OSE other
Guest OSses: eComstation, DOS, Win10

Re: vidma - Virtual Disks Manipulator (tool for resizing VD

Post by JonH »

przemoc wrote: And that's it. New VDI has the same UUID as the old one, so they cannot coexist in VirtualBox. You have to release the old image and register the new one. Verify that everything works before deleting the old image.

Last step can be done with VBoxManage:

Code: Select all

przemoc@vostro:~/vidma$ VBoxManage modifyhd ~/vdi/new.vdi --resize 76800
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
@przemoc

Thanks so much for this post. I have gotten as far as completing the above '--resize' and all the steps prior to that seemed to go correctly.
I don't understand what to do next.
In the gui VirtualBox Manager I have the old.vdi
I understand that I have to release it but am not sure how to do that. I can remove it from the gui but don't know if that is 'releasing it'.
I tried to register the new vm and received errors, maybe because I have not used a partition manager yet?

Code: Select all

# VBoxManage registervm /home/jon/"VirtualBox VMs"/eCS_21/eCS_21dyn.vdi
VBoxManage: error: Extra content at the end of the document.
VBoxManage: error: Location: '/home/jon/VirtualBox VMs/eCS_21/eCS_21dyn.vdi', line 1 (0), column 2.
VBoxManage: error: /home/vbox/vbox-4.2.4/src/VBox/Main/src-server/MachineImpl.cpp[469] (nsresult Machine::initFromSettings(VirtualBox*, const com::Utf8Str&, const com::Guid*))
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Machine, interface IMachine, callee nsISupports
VBoxManage: error: Context: "OpenMachine(Bstr(a->argv[0]).raw(), machine.asOutParam())" at line 90 of file VBoxManageMisc.cpp
Just to clarify what I have, here is the contents of my VM directory:

Code: Select all

 # ls -la
total 5351492
drwxr-xr-x 4 jon users       4096 Nov 19 12:11 .
drwxr-xr-x 3 jon users       4096 Nov 17 09:00 ..
drwx------ 2 jon users       4096 Nov 18 22:27 Logs
drwx------ 2 jon users       4096 Nov 17 09:06 Snapshots
-rw------- 1 jon users       7193 Nov 18 23:12 eCS_21.vbox
-rw------- 1 jon users       7192 Nov 18 23:12 eCS_21.vbox-prev
-rw------- 1 jon users 2147495936 Nov 18 23:12 eCS_21.vdi
-rw------- 1 jon users 2148532224 Nov 19 12:23 eCS_21dyn.vdi
-rw------- 1 jon users 1183854592 Nov 18 13:16 ecsClone.vdi
eCS_21dyn.vdi is the one I created using your tool.

So how should I proceed from here?
Thanks, Jon
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator (tool for resizing VD

Post by przemoc »

Short follow-up, because in fact I contacted JohH to explain the stuff the same day he wrote above post. So no, I didn't leave him in the complete dark. ;)
But my first explanations weren't clear enough to him (he misread original how-to and futher explanations, as he admitted later), so I sent him second ones the next day, but without any further response. He knew I was busy lately (I mentioned it in first message to him, so he could forgive me not writing detailed enough response in the first place), and apparently to not bother me more, he sadly went with more laborous way posted in the original thread.Anyway I'll respond here for the record too. It's not really vidma-related stuff, though.
JonH wrote:
przemoc wrote: And that's it. New VDI has the same UUID as the old one, so they cannot coexist in VirtualBox. You have to release the old image and register the new one. Verify that everything works before deleting the old image.

Last step can be done with VBoxManage:

Code: Select all

przemoc@vostro:~/vidma$ VBoxManage modifyhd ~/vdi/new.vdi --resize 76800
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
@przemoc

Thanks so much for this post. I have gotten as far as completing the above '--resize' and all the steps prior to that seemed to go correctly.
I suspect that you read my "Last step can be done with VBoxManage:" as another step, while it was out of the walk-through-showcase (notice the lack of indentation). I guess the sentence lacked "instead" at the end to make it more clear and maybe explicit reference to step 7, which it can replace. Don't worry. Running VBoxManage resizing after vidma resizing brings no harm and no practical change related to data, so it's all fine.
JonH wrote: I don't understand what to do next.
In the gui VirtualBox Manager I have the old.vdi
I understand that I have to release it but am not sure how to do that. I can remove it from the gui but don't know if that is 'releasing it'.
I tried to register the new vm and received errors, maybe because I have not used a partition manager yet?

Code: Select all

# VBoxManage registervm /home/jon/"VirtualBox VMs"/eCS_21/eCS_21dyn.vdi
VBoxManage: error: Extra content at the end of the document.
VBoxManage: error: Location: '/home/jon/VirtualBox VMs/eCS_21/eCS_21dyn.vdi', line 1 (0), column 2.
VBoxManage: error: /home/vbox/vbox-4.2.4/src/VBox/Main/src-server/MachineImpl.cpp[469] (nsresult Machine::initFromSettings(VirtualBox*, const com::Utf8Str&, const com::Guid*))
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Machine, interface IMachine, callee nsISupports
VBoxManage: error: Context: "OpenMachine(Bstr(a->argv[0]).raw(), machine.asOutParam())" at line 90 of file VBoxManageMisc.cpp
As for the error, you shouldn't use registervm on VDI file, because (a) it's not VM (it's image of virtual disk), (b) you don't explicitly register images, you just set them via particular virtual machine settings as the virtual disk. I could be not clear enough before, I guess. In VirtualBox there is so called Virtual Media Manager (available from File menu or by pressing Ctrl+D). In hard drives old VDI has to be released there before you can set the new VDI with the same UUID (universally unique identifier) in your particular virtual machine (you do it in settings of your virtual machine).

I think you're mixing some things and that's why you commited the mistake. Allow me to explain briefly some terms.

There is so called virtual machine, VM for short. It's the "virtual computer" that you run in VirtualBox. 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. VDI stands for "VirtualBox Disk Image". VDI has a few variants like fixed, dynamic and some snapshot related ones.

In your VM virtual disk has no content until you attach an image (of disk) to it or some physical disk. Whenever you attach disk image to VM (Machine menu -> Settings / Ctrl+S go to Storage, choose existing hard disk under SATA / IDE controller or create new one and in attributes you click the icon "Set up the virtual hard disk") it is registered in the Virtual Media Manager, so you cannot attach another VDI having the same UUID, as it breaks the uniqueness rule.
JonH wrote:So how should I proceed from here?
You have to go to Virtual Media Manager (File menu -> Virtual Media Manager / Ctrl+D), choose the old VDI and click Release button (or Ctrl+L shortcut). Now you can go back to storage settings and you'll be able to set your new VDI as the image of the virtual hard disk.

After that you should verify that it boots cleanly etc. Next you have to use GParted (by booting Parted Magic ISO for instance) to resize the partitions, as was already mentioned in the original thread.
JonH wrote:Anyway, after reading all the info again I went ahead with noteirak's suggestion of creating a new hd with vboxmanage. So now I have a fixed size machine, not dynamic, but this will do me for the limited amount of use I anticipate.
If it worked for you, then it's fine, but you could easily resize fixed size image using vidma. It was already mentioned back then in the how-to post at the end of it.

It looks like all the problems arose from your inability to release the old VDI and attach the new one instead, but I'm sure you're aware of it now. I'll edit the how-to in a moment to make it more clear for the prospective future users.
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
JonH
Posts: 37
Joined: 25. Oct 2012, 03:03
Primary OS: Mac OS X other
VBox Version: OSE other
Guest OSses: eComstation, DOS, Win10

Re: vidma - Virtual Disks Manipulator (tool for resizing VD

Post by JonH »

It looks like all the problems arose from your inability to release the old VDI and attach the new one instead, but I'm sure you're aware of it now. I'll edit the how-to in a moment to make it more clear for the prospective future users.
Quite right. Also, I got mixed up between suggests offered by others vs. suggestion offered by you. If I would have printed out your instructions instead of switching back and forth between apps I would have had a better grasp on the big picture.

I've re-read your edited instructions and they are much clearer now. And I also understand the whole thing better now.

Jon
przemoc
Posts: 32
Joined: 4. Sep 2008, 16:02
Primary OS: MS Windows other
VBox Version: PUEL
Guest OSses: Linux, Windows, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD
Location: Poland

Re: vidma - Virtual Disks Manipulator (tool for resizing VD

Post by przemoc »

Happy New Year, VirtualBox Users!

vidma 0.0.4 has been released in New Year's Eve

See NEWS file for changes.
Go to the 1st post for general information.
Last edited by przemoc on 9. Aug 2015, 23:35, edited 1 time in total.
Desktop: NUC11PHKi7C [Core i7-1165G7 @ 2.80GHz, DDR4-3200 32GB RAM, GeForce RTX 2060, M.2 NVMe SSD 2TB] | 32UN880-B
Laptop: ThinkPad T430 (2344-56G) [Core i7 3520M @ 2.9GHz, DDR3-1600 8GB RAM, NVS 5400M, SATA3 SSD 512GB]
Post Reply