On 02/05/2012 04:40 PM, Oved Ourfalli wrote:
----- Original Message -----
From: "Maor"<mlipc...@redhat.com>
To: "Itamar Heim"<ih...@redhat.com>
Cc: engine-devel@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@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
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
