 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 29 Aug 2012 08:53:51 +0100, Invisible wrote:
>>>> 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?
Given that you don't seem to understand how linked clones work or how
they are, I'm suggesting that maybe you should read up on the idea rather
than making wild assumptions about it.
> 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.
Correct. And if you delete the base vmdk image, what would you expect to
happen when using a linked clone?
> I don't know off the top of my head how Virtual Box does it.
And the VirtualBox documentation does in fact describe this. But hey, at
least you're saying "I don't know how it does this" rather than making an
incorrect assumption based on no knowledge. So that's progress. ;)
> 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).
I'm working with a product right now that actually does this in order to
personalize the image. The underlying virtualization technology is
XenServer, and the developers opted to create a LiveCD ISO to boot the VM
from that customizes the image (due to a lack of APIs in XenServer to do
this). They transfer the disk files to a temporary VM that mounts them
after booting the LiveCD image.
One benefit is that this allows them to be hypervisor-agnostic - it's a
technique that works with any hypervisor that can boot from an ISO.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Given that you don't seem to understand how linked clones work or how
> they are, I'm suggesting that maybe you should read up on the idea rather
> than making wild assumptions about it.
> Correct.
So my understanding is correct, and this constitutes making "wild
assumptions"?
> And if you delete the base vmdk image, what would you expect to
> happen when using a linked clone?
VMware won't let you do that.
None of which explains why I have to manage disk images and VMs
separately in Virtual Box, when they are nearly synonymous.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29/08/2012 04:18 PM, Darren New wrote:
> 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.
So... you just move the entire VM. I'm still not seeing why you would
want to move just the disk.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 30 Aug 2012 08:50:25 +0100, Invisible wrote:
>> Given that you don't seem to understand how linked clones work or how
>> they are, I'm suggesting that maybe you should read up on the idea
>> rather than making wild assumptions about it.
>
>> Correct.
>
> So my understanding is correct, and this constitutes making "wild
> assumptions"?
Your understanding of the mechanics is correct, but your conclusions are
not.
>> And if you delete the base vmdk image, what would you expect to happen
>> when using a linked clone?
>
> VMware won't let you do that.
Right, and neither will VBox.
> None of which explains why I have to manage disk images and VMs
> separately in Virtual Box, when they are nearly synonymous.
Because they /aren't/. A disk image can be used by multiple VMs. You
understand the mechanics, but your conclusion that they're "nearly
synonymous" is faulty.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> None of which explains why I have to manage disk images and VMs
>> separately in Virtual Box, when they are nearly synonymous.
>
> Because they /aren't/. A disk image can be used by multiple VMs. You
> understand the mechanics, but your conclusion that they're "nearly
> synonymous" is faulty.
A virtual machine is just a simulation of a computer. You can create and
destroy an unlimited number of them at will. The only thing that
distinguishes one from another is the data it does or does not have on
it - i.e., the disk image(s).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 30 Aug 2012 21:31:56 +0100, Orchid Win7 v1 wrote:
>>> None of which explains why I have to manage disk images and VMs
>>> separately in Virtual Box, when they are nearly synonymous.
>>
>> Because they /aren't/. A disk image can be used by multiple VMs. You
>> understand the mechanics, but your conclusion that they're "nearly
>> synonymous" is faulty.
>
> A virtual machine is just a simulation of a computer. You can create and
> destroy an unlimited number of them at will. The only thing that
> distinguishes one from another is the data it does or does not have on
> it - i.e., the disk image(s).
Well, no, there's the virtual hardware configuration as well.
But again, when dealing with linked clones, you have a common base and
then things change from VM to VM. Linked clones use both a common disk
and their own differentiating disk overlays that make them unique.
As such, disks/VMs are not "nearly synonymous".
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 30.08.2012 22:31, schrieb Orchid Win7 v1:
>>> None of which explains why I have to manage disk images and VMs
>>> separately in Virtual Box, when they are nearly synonymous.
>>
>> Because they /aren't/. A disk image can be used by multiple VMs. You
>> understand the mechanics, but your conclusion that they're "nearly
>> synonymous" is faulty.
>
> A virtual machine is just a simulation of a computer. You can create and
> destroy an unlimited number of them at will. The only thing that
> distinguishes one from another is the data it does or does not have on
> it - i.e., the disk image(s).
Think of VMs as mainboards (+ CPU and memory installed), and disk images
as hard drives.
You can disconnect a hard drive from one mainboard and plug it into
another, can't you?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30/08/2012 11:14 PM, clipka wrote:
> Think of VMs as mainboards (+ CPU and memory installed), and disk images
> as hard drives.
>
> You can disconnect a hard drive from one mainboard and plug it into
> another, can't you?
Sure, you /can/... but why would you /want/ to?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 31 Aug 2012 08:23:39 +0100, Orchid Win7 v1 wrote:
> On 30/08/2012 11:14 PM, clipka wrote:
>> Think of VMs as mainboards (+ CPU and memory installed), and disk
>> images as hard drives.
>>
>> You can disconnect a hard drive from one mainboard and plug it into
>> another, can't you?
>
> Sure, you /can/... but why would you /want/ to?
Because you're upgrading the hardware and want to preserve your data?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-08-30 03:50, Invisible a écrit :
> On 29/08/2012 04:18 PM, Darren New wrote:
>> 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.
>
> So... you just move the entire VM. I'm still not seeing why you would
> want to move just the disk.
Because the colo facility may offer you different numbers of CPUs, RAM,
disk space, NICs, DVD drives, etc...
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
