On 27/08/2012 08:42 PM, Jim Henderson wrote:
> FWIW, I use VirtualBox on Linux pretty much daily, never have stability
> problems at all.

You never had it pop up and say "This process has performed an illegal 
operation and must be terminated. Do you wish to send an error report"? 
(Oh, well, I guess you wouldn't be seeing a Windows-specific error 
message on Linux... But you get what I'm saying.)

You never had a VM working perfectly, and then the next day VirtualBox 
utterly /refuses/ to start that VM? (Like, you click "start", and either 
nothing happens or VirtualBox instantly crashes.)

You never had it refuse to delete a snapshot for no defined reason? 
(E.g., you have a VM powered down, you take a snapshot, realise you 
wanted to do something first, go to delete the snapshot you just made, 
and it says "sorry, I can't do that Dave".)

> I'm also not sure what you  mean by "manag[ing] disks and VMs separately"
> - the GUI that I use (which is the default GUI AFAIK) doesn't do that.

When you create a VM, it asks to create a virtual disk. (Which isn't 
surprising; VMware does this also.) But it seems to want to put all the 
VM files in one place, and all the virtual disk files in another place. 
And it asks me if I want to reuse one of my existing disk files. (Why 
would I *ever* want to do that??) And when I delete a VM, this does 
/not/ delete the disk image files with it. I have to manually do that 
from the disk management window.

Maybe the GUI is completely different on Linux or something. But on 
Windows, you can't even edit a snapshot description while the VM it 
belongs to is running. (I can understand, from a technical perspective, 
how that could end up not working. What I can't figure out is why the 
heck nobody has fixed this. It can't be that damned hard...)

Post a reply to this message

On Mon, 27 Aug 2012 21:59:13 +0100, Orchid Win7 v1 wrote:

> On 27/08/2012 08:42 PM, Jim Henderson wrote:
>> FWIW, I use VirtualBox on Linux pretty much daily, never have stability
>> problems at all.
> 
> You never had it pop up and say "This process has performed an illegal
> operation and must be terminated. Do you wish to send an error report"?
> (Oh, well, I guess you wouldn't be seeing a Windows-specific error
> message on Linux... But you get what I'm saying.)

Nope, never.

> You never had a VM working perfectly, and then the next day VirtualBox
> utterly /refuses/ to start that VM? (Like, you click "start", and either
> nothing happens or VirtualBox instantly crashes.)

Nope, never.  I've even had my entire Linux DE crash on me and I've been 
able to restart the VM when it came back up.

What version are you running?  Sounds like an old version maybe, or just 
that the Windows version is garbage and you should use the Linux 
version.  I've had nothing but good luck with the Linux version - enough 
so that I stopped using even VMware Player.

> You never had it refuse to delete a snapshot for no defined reason?
> (E.g., you have a VM powered down, you take a snapshot, realise you
> wanted to do something first, go to delete the snapshot you just made,
> and it says "sorry, I can't do that Dave".)

Nope, never had it do that, either.

>> I'm also not sure what you  mean by "manag[ing] disks and VMs
>> separately"
>> - the GUI that I use (which is the default GUI AFAIK) doesn't do that.
> 
> When you create a VM, it asks to create a virtual disk. (Which isn't
> surprising; VMware does this also.) But it seems to want to put all the
> VM files in one place, and all the virtual disk files in another place.
> And it asks me if I want to reuse one of my existing disk files. (Why
> would I *ever* want to do that??) And when I delete a VM, this does
> /not/ delete the disk image files with it. I have to manually do that
> from the disk management window.

All of my VMs' disk files are with the configuration, but this actually 
makes sense on a couple different levels, because you can do 'linked 
cloning', in which case deleting the disk file would affect multiple VMs 
(ie, it would break them).  But in the Linux GUI, you do have the option 
when deleting a VM to also delete the disk files at the same time if 
they're not linked/in use by another VM.

> Maybe the GUI is completely different on Linux or something. But on
> Windows, you can't even edit a snapshot description while the VM it
> belongs to is running. (I can understand, from a technical perspective,
> how that could end up not working. What I can't figure out is why the
> heck nobody has fixed this. It can't be that damned hard...)

That works just fine on Linux.

Jim

Post a reply to this message

On 8/27/2012 13:59, Orchid Win7 v1 wrote:
> asks me if I want to reuse one of my existing disk files. (Why would I
> *ever* want to do that??) And when I delete a VM, this does /not/ delete the
> disk image files with it.

I think you just answered your own question.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

>> asks me if I want to reuse one of my existing disk files. (Why would I
>> *ever* want to do that??) And when I delete a VM, this does /not/
>> delete the disk image files with it.
>
> I think you just answered your own question.

How so?

If you put the disks from one VM into another VM, then the other VM 
*becomes* the first VM. All VMs are essentially identical; the disks are 
the only thing that makes them different. Either you want to delete a 
VM, or you don't. So deleting the settings file and then still using the 
existing disks is a nonsensical thing to do.

Post a reply to this message

On Tue, 28 Aug 2012 09:32:03 +0100, Invisible wrote:

>>> asks me if I want to reuse one of my existing disk files. (Why would I
>>> *ever* want to do that??) And when I delete a VM, this does /not/
>>> delete the disk image files with it.
>>
>> I think you just answered your own question.
> 
> How so?
> 
> If you put the disks from one VM into another VM, then the other VM
> *becomes* the first VM. All VMs are essentially identical; the disks are
> the only thing that makes them different. Either you want to delete a
> VM, or you don't. So deleting the settings file and then still using the
> existing disks is a nonsensical thing to do.

Not if the disk is a data disk, or is used as something other than the 
boot disk.

Or if it's a base for multiple linked clones where you started from a 
common base, but the clones are different.  It's not unusual at all, for 
example, when testing networked setups of identical OSes to create a 
common base image and then customize multiple linked clones.

Jim

Post a reply to this message

>> If you put the disks from one VM into another VM, then the other VM
>> *becomes* the first VM. All VMs are essentially identical; the disks are
>> the only thing that makes them different. Either you want to delete a
>> VM, or you don't. So deleting the settings file and then still using the
>> existing disks is a nonsensical thing to do.
>
> Not if the disk is a data disk, or is used as something other than the
> boot disk.

Wouldn't you just clone the disk for something like that? (Otherwise 
only one VM can access it at a time.)

> Or if it's a base for multiple linked clones where you started from a
> common base, but the clones are different.

Then wouldn't each clone have its own local cloned disk image?

Post a reply to this message

Am 28.08.2012 18:03, schrieb Orchid Win7 v1:
>>> If you put the disks from one VM into another VM, then the other VM
>>> *becomes* the first VM. All VMs are essentially identical; the disks are
>>> the only thing that makes them different. Either you want to delete a
>>> VM, or you don't. So deleting the settings file and then still using the
>>> existing disks is a nonsensical thing to do.
>>
>> Not if the disk is a data disk, or is used as something other than the
>> boot disk.
>
> Wouldn't you just clone the disk for something like that? (Otherwise
> only one VM can access it at a time.)
>
>> Or if it's a base for multiple linked clones where you started from a
>> common base, but the clones are different.
>
> Then wouldn't each clone have its own local cloned disk image?

Virtual Box is pretty smart when it comes to saving disk space: When you 
clone a disk image, it "freezes" the original disk's state into a save 
point, and the clone will actually be a reference to that save point 
plus a delta tracking any changes.

Likewise, the original disk will further on be managed as that "frozen" 
state plus another delta tracking any changes made by /that/ VM.

(Note that a "frozen" state itself may already be a reference to an 
earlier save point plus a delta.)

Post a reply to this message

On Tue, 28 Aug 2012 17:03:25 +0100, Orchid Win7 v1 wrote:

>>> If you put the disks from one VM into another VM, then the other VM
>>> *becomes* the first VM. All VMs are essentially identical; the disks
>>> are the only thing that makes them different. Either you want to
>>> delete a VM, or you don't. So deleting the settings file and then
>>> still using the existing disks is a nonsensical thing to do.
>>
>> Not if the disk is a data disk, or is used as something other than the
>> boot disk.
> 
> Wouldn't you just clone the disk for something like that? (Otherwise
> only one VM can access it at a time.)

No, and no.

Linking the clone means that you don't waste the disk space with 
duplicate data.

And no, only one VM can *write* to it at a time, but multiple VMs can 
*read* from it at the same time.  Changes get written to a secondary file 
that contains the differences between the combined images and the base 
image - just like a snapshot.

>> Or if it's a base for multiple linked clones where you started from a
>> common base, but the clones are different.
> 
> Then wouldn't each clone have its own local cloned disk image?

Again, no.  That's not what a linked clone is.

I might be inclined to suggest "RTFM", as the VirtualBox and VMware 
documentation both describe what a linked clone is.  Rather than assume 
what it is and then make statements based on those assumptions, you could 
actually learn what the idea is behind it.

Jim

Post a reply to this message

>>> Or if it's a base for multiple linked clones where you started from a
>>> common base, but the clones are different.
>>
>> Then wouldn't each clone have its own local cloned disk image?
>
> Virtual Box is pretty smart when it comes to saving disk space: When you
> clone a disk image, it "freezes" the original disk's state into a save
> point, and the clone will actually be a reference to that save point
> plus a delta tracking any changes.

Isn't this how /all/ VM products work?

Post a reply to this message

>>> Or if it's a base for multiple linked clones where you started from a
>>> common base, but the clones are different.
>>
>> Then wouldn't each clone have its own local cloned disk image?
>
> Again, no.  That's not what a linked clone is.
>
> I might be inclined to suggest "RTFM", as the VirtualBox and VMware
> documentation both describe what a linked clone is.  Rather than assume
> what it is and then make statements based on those assumptions, you could
> actually learn what the idea is behind it.

Oh, so now you're claiming that I don't know how VMware works?

When you create a VM, it starts with one file for the disk image. Each 
time you take a snapshot, it stops writing to the current image file, 
and creates a new file which is a delta against the previous one. When 
you make a "full clone", it copies all the data. When you create a 
"linked clone", it creates a new VM, but it's base disk image is just a 
delta against the linked VM, just like a snapshot.

I don't know off the top of my head how Virtual Box does it.

I'm still not seeing why you would want to transfer a disk from one VM 
to another - except perhaps, as you say, for data transfer (if you can't 
get a more sane method to work).

Post a reply to this message