----- Original Message ----- > On 02/05/2012 02:14 PM, Maor wrote: > ... > > >> 3. "The synchronization/clustering of shared raw disk between VMs > >> will > >> be managed in the file system. " > >> > >> either i don't understand what this mean, or it could be read with > >> a > >> misleading meaning. > > Maybe the following rephrase will be more accurate: "The > > synchronization/clustering of shared raw disk between VMs should be > > based on external independent application which will be > > synchronized > > with the guest application." > "The synchronization/clustering of shared raw disk between VMs is the > responsibility of the guests. Unaware guests will lead to corruption > of > the shared disk." > > >> > >> 4. VM Pools > >> VM Pools are always based (at least today) on templates, and > >> templates > >> have no shared disks. > >> I'd just block attaching a shared disk to a VM which is part of a > >> pool > >> (unless there is a very interesting use case meriting this) > > If there is no reason to attach shared disk to a VM from pool, > > maybe its > > also not that relevant to attach shared disk to stateless VM. > > Miki? > > I think pools and stateless are different. I can envision a use case > where stateless guests would use a shared disk (say, in read only for > same data).
Read only is just as relevant to pools as it is to stateless... > > > >> > >> 6. future work - Permissions should be added for disk entity > >> so who can add a shared disk? > > Data Center Administrator or System Administrator will be > > initialized > > with permissions for creating shared raw disk, or changing shared > > disk > > to be unshared. > > Regarding attach/detach disks to/from VM, I was thinking that for > > phase > > one we will count on the user VM permissions. If user will have > > permissions to create new disks on the VM, he will also have > > permissions > > to attach new shared raw disk to it. > > this means they can attach shared disks from other VMs they have no > permission on... > as i said earlier - need to think about this one some more. > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel