[Engine-devel] SharedRawDisk feature detail

Wed Feb 15 10:20:53 UTC 2012


----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, February 15, 2012 12:17:32 AM
> Subject: Re: [Engine-devel] SharedRawDisk feature detail
> 
> 
> 
> ----- Original Message -----
> > On 02/14/2012 07:44 PM, Livnat Peer wrote:
> > > On 14/02/12 11:44, Maor wrote:
> > >> On 02/14/2012 09:17 AM, Livnat Peer wrote:
> > >>> On 13/02/12 19:44, Maor wrote:
> > >>>> On 02/12/2012 07:03 PM, Livnat Peer wrote:
> > >>>>> On 02/02/12 17:15, Maor wrote:
> > >>>>>> Hello all,
> > >>>>>>
> > >>>>>> The shared raw disk feature description can be found under
> > >>>>>> the
> > >>>>>> following
> > >>>>>> links:
> > >>>>>>    http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk
> > >>>>>>    http://www.ovirt.org/wiki/Features/SharedRawDisk
> > >>>>>>
> > >>>>>> Please feel free, to share your comments.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> Maor
> > >>>>>> _______________________________________________
> > >>>>>> Engine-devel mailing list
> > >>>>>> Engine-devel at ovirt.org
> > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>
> > >>>>> Hi Maor,
> > >>>>>
> > >>>>> - "when taking a VM snapshot, a snapshot of the shared disk
> > >>>>> will not be
> > >>>>> taken."
> > >>>>> I think it is worth mentioning that the shared disk will be
> > >>>>> part of the
> > >>>>> VM snapshot configuration. The disk will appear as unplugged.
> > >>>> Agreed, I changed it to the following:
> > >>>> when taking a vm snapshot, a snapshot of the shared disk
> > >>>> should
> > >>>> not be
> > >>>> taken, although it will be part of the VM snapshot
> > >>>> configuration
> > >>>> and the
> > >>>> disk will appear as unplugged.
> > >>>>>
> > >>>>> - Move VM is deprecated in 3.1.
> > >>>> Right, I removed this anecdote from the wiki.
> > >>>>>
> > >>>>> - It seems from the wiki that shared disk is not supported
> > >>>>> for
> > >>>>> template
> > >>>>> but is supported for VM pool.
> > >>>>> I am not sure how can we do that? iirc we create pool from
> > >>>>> template.
> > >>>> What I was thinking about, is that the administrator can take
> > >>>> a
> > >>>> VM from
> > >>>> the pool and attach it a shared disk, after the VM was created
> > >>>> (for
> > >>>> testing).
> > >>>>
> > >>>> The motivation for adding shared disk was that each entity
> > >>>> that
> > >>>> can be
> > >>>> added with a disk can also be added with shared disk.
> > >>>> Today, Administrator can add a disk to a VM from pool, which
> > >>>> might be
> > >>>> wrong behaviour, so maybe its better not to support it...
> > >>>>>
> > >>>>> What is the complexity of supporting shared disk in
> > >>>>> Templates?
> > >>>>> off the
> > >>>>> top of my head it seems like it is more complicated to block
> > >>>>> shared
> > >>>>> disks in templates than to support it. What do you think?
> > >>>> Implementation wize it might be less complex, the problem is
> > >>>> the
> > >>>> use
> > >>>> cases it raises,
> > >>>> some of them which I'm thinking about are:
> > >>>> * If the disk will be deleted from the DC, should we remove it
> > >>>> from the
> > >>>> template? or leave an indication in the template that there
> > >>>> was
> > >>>> a shared
> > >>>> disk there, maybe should not allow to delete the disk in the
> > >>>> first
> > >>>> place, until it is unattached from the template?
> > >>>
> > >>> Since template configuration is 'read-only' you can not change
> > >>> a
> > >>> disk to
> > >>> be plugged or unplugged.
> > >>> I would say you can not delete a disk that is part of a
> > >>> template
> > >>> regardless if it is shared or not.
> > >> So in that case template with shared disk, will block the user
> > >> from
> > >> removing the shared disk from the DC.
> > >> Won't it will make the flow for the user a bit complicated.
> > >> User who wants to remove the shared disk, will need to remove
> > >> the
> > >> VM's
> > >> which are based on the template and then remove the template it
> > >> self.
> > >
> > > I see the complication of delete, we have similar complications
> > > for
> > > delete regardless of shared disk (deleting disk with snapshots).
> 
> There should be no such thing as 'delete disk with snapshots'
> When deleting a disk the only thing that should be deleted is topmost
> layer.
> The disk does not stop to exist in the history of the VM and when
> reverting to an old snapshot the disk should be there.
> 
> Shared disks have no snapshots so there is no issue in this sense,
> however, if a template has a reference to the disk then deleting the
> disk would effectively modify the template configuration(?) and iirc
> engine does not allow changing template configuration post creation
> (but we had a very long thread on this already).
> 
> > >
> > > Other than delete can you think of other complicated scenarios?
> > 
> > if it makes things more complex, why not postpone this part of the
> > feature to a later phase?
> 
> I think we're approaching this the wrong way.
> There are 2 possible problems we're trying to solve here and having
> the original shared disk as part of the template is the wrong
> solution for both.
> 
> The first problem is - user wants to attach the shared disk to all
> VMs derived from the template - in this case the shared disk is
> *not* a part of the template and what is needed is an automatic way
> to configure newly created VMs that would allow to attach the shared
> disk.
My personal feeling is that this is the common use case.
> 
> The second problem is - user wants the data on the shared disk to be
> part of the template -
> This is the general case for template seeing as a template is a
> *copy* of the original VM with stripped identity.
> in this case what is needed is a *copy* of the data and the fact that
> the disk is shared is coincidental.
> 
> What the above means is that when you create a template from a VM
> with a shared disk the user should choose whether the operation
> would also create a new disk and copy the content of the shared disk
> to it (it is the user's responsibility to make sure that the data
> does not change while this operation is taking place, but we can
> help a little there) or exclude the shared disk from the template.
Although this is a valid use case, I think this is very confusing and defeat the "notion" of shared. So I would defer on this one for now.
> 
> 
> 
> 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>