[Engine-devel] SharedRawDisk feature detail

[Yaniv Kaul]

On 02/05/2012 04:40 PM, Oved Ourfalli wrote:
>
> ----- Original Message -----
>> From: "Maor"<mlipchuk at redhat.com>
>> To: "Itamar Heim"<iheim at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Sunday, February 5, 2012 3:14:35 PM
>> Subject: Re: [Engine-devel] SharedRawDisk feature detail
>>
>> On 02/03/2012 04:59 PM, Itamar Heim wrote:
>>> On 02/02/2012 05:15 PM, 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.
>>> 1. Affected oVirt projects
>>> i'm pretty sure the history data warehouse will need to adapt to
>>> this.
>>>
>>> 2. "The shared raw disk feature should provide the ability to
>>> attach
>>> disk to many VMs with safe concurrent access,"
>>> this could be read as if ovirt or vdsm somehow provides a mechanism
>>> for
>>> safe concurrent access.
>>> maybe something like "to multiple VMs that can handle concurrent
>>> access
>>> to a shared disk without risk of corruption".
>>> and having just written this - sounds like setting this flag at UI
>>> level
>>> should include a prompt to the user to make sure they understand
>>> that
>>> flagging the disk as shared *will* lead to corruption if it is
>>> attached
>>> to virtual machines which do not support and expect it to be shared
>>> with
>>> other virtual or physical machines[1]
>> I agree, I will change it.
>>> 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."
>>> 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 there is such a use-case in clustered environments (DB cluster, for example), in which you have several disks that are not shared (OS, applications, etc.), and several disks that are shared (DB disks).
> In this case, in order to create this clustered environment, it will be nice if you create a template with the regular disks, create a pool from it, and attach all the VMs in the pool the shared DB disks.
> (It would be even nicer if the shared disk will be a part of the template, and when creating VMs from it they will have have a "link" to this shared disk - but I agree that it may be complex so maybe we should leave it aside for now).
>
> Thoughts?

Unless you have a correct 'uniqifying' process ('sysprep' for Windows), 
this is really not going to work.
For example, even Windows sysprep fails at times. We've known for quite 
some time that it does not make the DTC UUID unique, so when 
cloning+sysprep'ing the system, you are still left with severe 
connectivity issues at the DTC RPC level.
I therefore assume other applications may suffer from it as well (how do 
you make a RHEVM instance unique? which fields in the DB, config files, 
etc. do you have to re-create?).
Y.


>
>>> 5. "Quota has to be taken in consideration, for every new feature
>>> that
>>> will involve consumption of resources managed by it."
>>>
>>> I thought quota is not relevant in this feature.
>> Why not?
>> Quota should be taken in consideration when adding new shared raw
>> disk,
>> or moving a disk to other domains. We should also notice that shared
>> raw
>> disk should not consume more quota when sharing the disk with
>> different VMs.
>>
>>> 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.
>>> same as for floating disks, i find it hard to imagine a flow in
>>> which if
>>> someone flagged a disk as shared, suddenly everyone can have access
>>> to it.
>>> same as my statement of floating disks - I'll spend some more time
>>> to
>>> reflect on this specific part.
>>>
>>> [1] an external LUN based disk could be shared with a physical
>>> server as
>>> well.
>> _______________________________________________
>> 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