Virtualbox
Van Chocstraw
marrgol
> How do you increase the size of a virtual disk (.vdi)?
I don't think you can... What you can do is create a new bigger .vdi
and clone the old one to the new, e.g. using your favourite tool
from within the virtual machine (clonezilla? Norton Ghost? dd?) or
VBoxManage clonehd old.vdi new.vdi --existing
command (I've just done it this way on 3.0.10). UUID of the new disk
will be different from the old, so you may have to correct configuration
of the installed OS (e.g. if using disk by-id and/or by-UUID?).
--
mrg
Van Chocstraw
I decided to just create another .vdi and attach it as a slave. Then I
partitioned and formated it and install my new programs on it instead of
the master. Plenty of room now.
David Bolt
Van Chocstraw painted this mural:
Okay, this is a bit late but...
> How do you increase the size of a virtual disk (.vdi)?
You can't, at least not without the tools provided with the VirtualBox
package.
However, after a little fiddling, I've written a quick and dirty app,
extend-disc-image, that will clone an image, expanding it in the
process. It handles both fixed and expanding VDI images, and it should
be available from the buildservice, when it finishes building it and it
gets distributes to the various mirrors. It should eventually be
available from here:
<URL:http://download.opensuse.org/repositories/home://davjam79://console/openSUSE_11.0/>
<URL:http://download.opensuse.org/repositories/home://davjam79://console/openSUSE_11.1/>
<URL:http://download.opensuse.org/repositories/home://davjam79://console/openSUSE_11.2/>
<URL:http://download.opensuse.org/repositories/home://davjam79://console/openSUSE_Factory/>
and the package name is extend-disc-image-0.0.1-1.1.${arch}.rpm .
At the moment, while there is some error-checking, it's not
foolproof[0]. It does check to see if the source and destination image
names are the same, and aborts if they are. However, it doesn't check
if you're going to overwrite a file, which means creating a link to the
source image and then passing that as the destination file name will
result in the source image being destroyed. Simple answer for that is
"Just Don't Do That(TM)". I may add a check to try and prevent this in
the future. Then again, if someone is stupid enough to do this...
Another check is to make sure you're extending the image, so negative
sizes will cause it to abort, as will sizes that take it to 2TBytes,
or larger. VirtualBox has a 2TByte limit, so this should prevent
creating an image that it can't handle.
What it doesn't do is check to see if there is enough space to create
the extended image, so you do need to make sure there is enough space
for the clone image.
[0] Even if I tried making it foolproof, it wouldn't be long before
someone created a better fool.
Regards,
David Bolt
--
Team Acorn: www.distributed.net OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s
openSUSE 10.3 32b | openSUSE 11.0 32b | | openSUSE 11.2 32b
openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b |
RISC OS 4.02 | RISC OS 3.11 | openSUSE 11.1 PPC | TOS 4.02
David Bolt
houghi painted this mural:
<snip>
>> At the moment, while there is some error-checking, it's not
>> foolproof[0]. It does check to see if the source and destination image
>> names are the same, and aborts if they are. However, it doesn't check
>> if you're going to overwrite a file, which means creating a link to the
>> source image and then passing that as the destination file name will
>> result in the source image being destroyed. Simple answer for that is
>> "Just Don't Do That(TM)". I may add a check to try and prevent this in
>> the future. Then again, if someone is stupid enough to do this...
>
> A simple `test -f $FILE && exit` should be enough not to overwrite
> anything.
As it's coded in C, something more like:
if(!(out=fread(input_filename,"rb")))
{
// tell them it'll overwrite a file, close open files
// free up allocations and then abort
}
is what I'll most likely add, but I honestly have no idea whether I
should. Some may feel it's good to add that extra protection, while
others may feel it's a mild annoyance having to delete a pre-existing
file before creating a new clone[0].
>> What it doesn't do is check to see if there is enough space to create
>> the extended image, so you do need to make sure there is enough space
>> for the clone image.
>
> Rip that part from makeSUSEdvd.
As above, I can't do that, and I don't yet know how to do it in C.
[0] Another thing I've been thinking about is, when cloning the drive,
changing the UUID so the original and "clone" can be listed under the
VirtualBox Media Manager at the same time.
David Bolt
houghi painted this mural:
> David Bolt wrote:
>> As it's coded in C, something more like:
>
> What is wrong with bash? Everything should be written in bash! The
> kernel should be written in bash!
At least you didn't say it should run inside emacs :)
>> if(!(out=fread(input_filename,"rb")))
^
Should be !!
>> {
>> // tell them it'll overwrite a file, close open files
>> // free up allocations and then abort
>> }
>>
>> is what I'll most likely add, but I honestly have no idea whether I
>> should. Some may feel it's good to add that extra protection, while
>> others may feel it's a mild annoyance having to delete a pre-existing
>> file before creating a new clone[0].
>
> I thought longer then 3 seconds about it now and at least a warning
> should be in place.
I just added the above check[0] and uploaded it for building. The new
version should be finished and published soon.
> "The file 'XYZ.dvi' exists. Do you want to overwrite it?"
Personally, I don't like these.
> After that: "This will permananently delete XYZ.dvi. Is this ok?"
> After that: "'xyz.dvi' is moved to 'xyz.dvi.bak' Are you releay sur this
> can be deleted?"
And these would really start to annoy.
> OK, perhaps not the last ones.
Thank goodness for that.
[0] Also added some error checking for read and write errors. Still
haven't figured out how to make sure there's enough free space, and I
also haven't added anything to change the UUID. Changing the UUID is
probably going to be in the next version.
David Bolt
I painted this mural:
> On Friday 20 Nov 2009 07:22, while playing with a tin of spray paint,
> houghi painted this mural:
<snip>
> Some may feel it's good to add that extra protection, while
> others may feel it's a mild annoyance having to delete a pre-existing
> file before creating a new clone[0].
I've added this, so now existing files won't get overwritten.
>>> What it doesn't do is check to see if there is enough space to create
>>> the extended image, so you do need to make sure there is enough space
>>> for the clone image.
>>
>> Rip that part from makeSUSEdvd.
>
> As above, I can't do that, and I don't yet know how to do it in C.
And I've added a space check, so no more trying to create 2TB fixed
images with only 400GB free. 2TB expanding images can still be created.
>
> [0] Another thing I've been thinking about is, when cloning the drive,
> changing the UUID so the original and "clone" can be listed under the
> VirtualBox Media Manager at the same time.
And this has been added as well. I even added a little counter so it
doesn't look like it's fallen asleep while cloning/extending the image.
marrgol
>> How do you increase the size of a virtual disk (.vdi)?
>
> You can't, at least not without the tools provided with the VirtualBox
> package.
Doesn't using VirtualBox mean you have them?
> However, after a little fiddling, I've written a quick and dirty app,
> extend-disc-image, that will clone an image, expanding it in the
> process. It handles both fixed and expanding VDI images
Unless you're doing it as an exercise you're trying to duplicate:
$ VBoxManage createhd --filename new.vdi --size 20480 \
--variant Standard
$ VBoxManage clonehd old.vdi new.vdi --existing
And this already changes UUID... :-)
--
mrg
David Bolt
marrgol painted this mural:
Interesting. I hadn't found anywhere showing this prior to knocking up
the app and the only link I've found, so far at least, that shows this
method is here:
http://www.attackr.com/resize-an-existing-vdi-virtualbox-image-easily/
which also appears to have been posted today.
marrgol
>> $ VBoxManage createhd --filename new.vdi --size 20480 \
>> --variant Standard
>> $ VBoxManage clonehd old.vdi new.vdi --existing
>
> Interesting. I hadn't found anywhere showing this prior to knocking up
> the app and the only link I've found, so far at least, that shows this
> method is here:
>
> http://www.attackr.com/resize-an-existing-vdi-virtualbox-image-easily/
>
> which also appears to have been posted today.
Well, I thought I mentioned it in my very first post in this thread
some ten days ago?... ;-) But it's true that the "--existing" option
seams to be undocumented so far.
--
mrg
David Bolt
marrgol painted this mural:
<snip>
> Well, I thought I mentioned it in my very first post in this thread
> some ten days ago?... ;-)
I had to Google it and, indeed, you did mention it.
> But it's true that the "--existing" option
> seams to be undocumented so far.
Looks like it. The VirtualBox forums have quite a few posts with the
same question, and all i kept finding was "create a new drive and
clone the contents to it using gparted, clonezilla, or similar"
I had originally thought about creating an app that did indeed just
extend the VDI, enlarging the map as required, but thought cloning
would be much easier to do. I might go back and write the app that
doesn't need to create the clone, but then comes the question about
what to do if there's an error during the enlarging. That could render
the old image useless, which means a backup would be required "just in
case", and then I might as well just create a cloned image in exactly
the manner my app does right now.
Paul J Gans
>On Friday 20 Nov 2009 08:21, while playing with a tin of spray paint,
>houghi painted this mural:
>> David Bolt wrote:
>>> As it's coded in C, something more like:
>>
>> What is wrong with bash? Everything should be written in bash! The
>> kernel should be written in bash!
>At least you didn't say it should run inside emacs :)
>>> if(!(out=fread(input_filename,"rb")))
> ^
>Should be !!
I'm not sure. I suspect "fopen" was meant. In that
case a NULL is returned on failure to open. That
is a synonym for FALSE. So the if will succeed if
a NULL is returned, which I think is the desired
behavior. But I may be wrong about that.
--
--- Paul J. Gans
David Bolt
Paul J Gans painted this mural:
> David Bolt <blackl...@davjam.org> wrote:
>>>> if(!(out=fread(input_filename,"rb")))
>> ^
>>Should be !!
>
> I'm not sure. I suspect "fopen" was meant.
I spotted the my missing ! but didn't spot the fread. I think I'm going
to have to give my proofreader the sack. Apparently he's not doing a
very good job of spotting errors.
> In that
> case a NULL is returned on failure to open. That
> is a synonym for FALSE. So the if will succeed if
> a NULL is returned, which I think is the desired
> behavior. But I may be wrong about that.
As originally written, and using fopen rather than fread, NULL is
returned on error and a pointer if it succeeds. As I'm looking to find
out if I can open the file, I need to check if the return value is a
pointer. The ! inverts the values and so NULL, which is logically the
same as 0, becomes 1 while the pointer, which could be virtually any
address in the memory space, becomes 0. The statement block enclosed by
the if() would then be executed if I failed to open the file. Since I'm
supposed to be checking for the file being successfully opened, I need
to check for a non-NULL return, and so need the second ! to invert the
first.
I could have easily just dropped the !! but I like to make sure I know
what I'm checking if I go back and look at the code some years from
now. I've learnt that the hard way by trying to figure out wtf I was
trying to do in some of the code I wrote 10-15 years ago.
Will Honea
> I could have easily just dropped the !! but I like to make sure I know
> what I'm checking if I go back and look at the code some years from
> now. I've learnt that the hard way by trying to figure out wtf I was
> trying to do in some of the code I wrote 10-15 years ago.
David, that should be a formalized specification for all code: after 10
years add a comment to all operations reading:
; WTF??
I recently had to update some code written (by someone else) in the mid
90's. The stuff was replete with #if (0)... #endif blocks that about drove
me nuts until I recalled that the compiler in use at the time had some
weird responses to conditional compile blocks and this was someone's
workaround. Need I ask your opinion of "self documenting languages"?
--
Will Honea
David Bolt
Will Honea painted this mural:
> David Bolt wrote:
>
>> I could have easily just dropped the !! but I like to make sure I know
>> what I'm checking if I go back and look at the code some years from
>> now. I've learnt that the hard way by trying to figure out wtf I was
>> trying to do in some of the code I wrote 10-15 years ago.
>
> David, that should be a formalized specification for all code: after 10
> years add a comment to all operations reading:
>
> ; WTF??
You mean it isn't standard practise?
> I recently had to update some code written (by someone else) in the mid
> 90's.
That's a recipe for hair loss.
> The stuff was replete with #if (0)... #endif blocks that about drove
> me nuts until I recalled that the compiler in use at the time had some
> weird responses to conditional compile blocks and this was someone's
> workaround.
At least you knew why it was used.
> Need I ask your opinion of "self documenting languages"?
You mean other than they usually aren't self documenting, at least to
someone that isn't the author of the code or someone quite familiar
with it? Having said that, I do at least now pick function and variable
names that give some idea as to what they're supposed to be used for.
I now like to add a lot of comments to my code to say what I was doing,
and it doesn't matter whether I'm writing something in C or shell
script. I want to know just what I was trying to do when I look at it
some time later. And, as for the possible complaints that all these
comments increase the size of the sources? Well, drive space is a lot
cheaper than someone time.
David Bolt
houghi painted this mural:
> David Bolt wrote:
>>> Need I ask your opinion of "self documenting languages"?
>>
>> You mean other than they usually aren't self documenting, at least to
>> someone that isn't the author of the code or someone quite familiar
>> with it? Having said that, I do at least now pick function and variable
>> names that give some idea as to what they're supposed to be used for.
>
> Nah, I think he is talking about perl.
I'm glad I wasn't drinking when I read that.