Re: [Engine-devel] SharedRawDisk feature detail

From: "Ayal Baron" <abaron(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt; Cc: engine-devel(a)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(a)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.

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.

> _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel