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 >>>>> [email protected] >>>>> 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). Other than delete can you think of other complicated scenarios? >> >>> * What do we want to do when creating a template from VM with shared >>> disk - Should User choose whether to create a template with/without the >>> shared disk? >>> >> >> If a user is creating a template from VM the configuration should be >> identical to the VM. >> >>> Blocking shared disk from template means creating the template without >>> the shared disk, the implementation for it is to check if the disk is >>> shared or not. >>> I think that if GUI will support attaching shared disk to multiple VMs, >>> there is no strong use case for allowing adding shared disk to a template. >> >> I am not sure what the above comment means but remember that we have API >> users as well as UI. >> >> I think that if we don't have a strong case for not supporting shared >> disk in templates the default should be to support it. >> >>>> >>>> Livnat >>>> >> > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
