>> 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

Am 29.08.2012 09:49, schrieb Invisible:
>>>> 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?

Don't know; if that's the case, how come you didn't seem to know about 
that concept?

Post a reply to this message

On 8/28/2012 1:32, Invisible wrote:
> If you put the disks from one VM into another VM, then the other VM
> *becomes* the first VM.

Well there you go. You have a VM on your desktop machine, and now you want 
to run it in the colo facility.

-- 
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

On 8/29/2012 0:49, Invisible wrote:
> Isn't this how /all/ VM products work?

It depends how you configure them. This is additional space overhead, remember.

-- 
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