9:15 a.m.
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
8:59 a.m.
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]
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.
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)
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.
6. future work - Permissions should be added for disk entity
so who can add a shared disk?
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.
7:14 a.m.
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?
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.
8:40 a.m.
----- Original Message -----
From: "Maor" <mlipchuk(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: engine-devel(a)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?
>
> 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:13 a.m.
On 02/05/2012 04:40 PM, Oved Ourfalli wrote:
----- Original Message -----
> From: "Maor"<mlipchuk(a)redhat.com>
> To: "Itamar Heim"<iheim(a)redhat.com>
> Cc: engine-devel(a)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(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
11 a.m.
On 02/05/2012 03:40 PM, Oved Ourfalli wrote:
...
>> 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?
that we can wait with an interesting enough use case before we pursue
this and ignore it for simplification for now.
10:59 a.m.
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).
>
> 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.
4:35 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Maor" <mlipchuk(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Yaniv Dary" <ydary(a)redhat.com>, "Miki
Kenneth" <mkenneth(a)redhat.com>
Sent: Sunday, February 5, 2012 6:59:32 PM
Subject: Re: [Engine-devel] SharedRawDisk feature detail
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).
Not sure what you mean here. I do think that if you have a pool of
Servers (rather than desktops),
It is a valid use case to be able have a shared raw disk attached to it.
I agree that this can be handled later on - but I would like the design at list to handle
it.
>>
>> 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.
3:22 p.m.
----- 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:03 a.m.
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.
- Move VM is deprecated in 3.1.
- 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 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?
Livnat
4:06 p.m.
I started writing the changes in the email but got tired of it and just made a bunch of
changes in the wiki (impossible to track in email, such things should be done using
etherpad or something).
A few questions though:
plugged vs. enabled - I thought we converged on attached/detached and enabled/disabled and
not plugged/unplugged?
* Shared disks are attached with R/W permissions.
- What about enabling R/O ? (esp. for stateless/pools)
* Template disks should not be shared.
- Why not? (read only)
* When exporting a VM, only the disks which are not shared will be exported.
- Why is the above not treated the same as a snapshot? the configuration will reference
the shared disk as unplugged? (or will it and it's just not clear?)
I didn't touch stateless/pools but should be fixed to reflect comments on this
thread.
Is Remove shared disk and Delete shared disk the same thing? if so, why the dual
terminology?
I don't quite follow the logic determining which section is under functionality and
which under user experience. For example, why do you have a 'Delete shared disk'
section in the Ux section but not a 'Move shared disk' section (there is no shared
disk specific logic visible in the delete action UI).
* Disk name should be generated automatically based on the vm name and disk number in the
VM. Description will be empty.
* New disk should enforce the user to enter a name for the disk.
- Huh? the above 2 items seem like an oxymoron, but I may be missing something...
* Attach/Detach of a shared disk can be performed only when the VM is in status
'down'.
- Why? under the functionality section you clearly stated that attaching a disk will
result in it being attached but disabled...
----- Original Message -----
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.
- Move VM is deprecated in 3.1.
- 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 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?
Livnat
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:17 a.m.
On 13/02/12 00:06, Ayal Baron wrote:
I started writing the changes in the email but got tired of it and
just made a bunch of changes in the wiki (impossible to track in email, such things should
be done using etherpad or something).
A few questions though:
plugged vs. enabled - I thought we converged on attached/detached and enabled/disabled
and not plugged/unplugged?
* Shared disks are attached with R/W permissions.
- What about enabling R/O ? (esp. for stateless/pools)
Do we have ack from libvirt that attaching disk in r/o mode actually
works? (I know we opened a bug for testing this but i can't find the bug
- Haim?)
* Template disks should not be shared.
- Why not? (read only)
* When exporting a VM, only the disks which are not shared will be exported.
- Why is the above not treated the same as a snapshot? the configuration will reference
the shared disk as unplugged? (or will it and it's just not clear?)
It is not the same case as snapshot. We don't have in the export domain
the shared image.
I didn't touch stateless/pools but should be fixed to reflect
comments on this thread.
Is Remove shared disk and Delete shared disk the same thing? if so, why the dual
terminology?
I don't quite follow the logic determining which section is under functionality and
which under user experience. For example, why do you have a 'Delete shared disk'
section in the Ux section but not a 'Move shared disk' section (there is no shared
disk specific logic visible in the delete action UI).
* Disk name should be generated automatically based on the vm name and disk number in the
VM. Description will be empty.
* New disk should enforce the user to enter a name for the disk.
- Huh? the above 2 items seem like an oxymoron, but I may be missing something...
The first line is referring to upgrade flow (it is under the upgrade
section), the second line is the behavior going forward.
I agree this is confusing, Maor I suggest you remove the general
behavior from the upgrade section.
* Attach/Detach of a shared disk can be performed only when the VM is
in status 'down'.
- Why? under the functionality section you clearly stated that attaching a disk will
result in it being attached but disabled...
I agree with Ayal on this.
Attach/Detach a disk should be enabled regardless if the VM is running
or not, this applies to all disks not only to shared disk.
Maor, few more questions:
* "Regular disk can become a shared raw disk, by editing the existing
disk and marking the 'share disk' property type."
There are limitation to this, for example disk with snapshots can not be
shared (we support only shared raw disks etc.)
* "When removing a VM with shared disks attached to it, the shared disks
will not be deleted. "
If the shared disk is not attached to any other VM, why don't we delete it?
I think we should behave with it as any other disk.
Maybe going forward when deleting a VM we should ask if to remove the
disks as well. This logic can apply to shared disk in the same way, I
don't think we should have a special logic around this for shared disks.
* The VDSM owner is missing from the doc, and vdsm is missing from the
affected projects.
Livnat
----- Original Message -----
> 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.
>
> - Move VM is deprecated in 3.1.
>
> - 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 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?
>
>
> Livnat
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
1:59 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Maor" <mlipchuk(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Haim Ateya" <hateya(a)redhat.com>
Sent: Monday, February 13, 2012 9:17:41 AM
Subject: Re: [Engine-devel] SharedRawDisk feature detail
On 13/02/12 00:06, Ayal Baron wrote:
> I started writing the changes in the email but got tired of it and
> just made a bunch of changes in the wiki (impossible to track in
> email, such things should be done using etherpad or something).
>
> A few questions though:
>
> plugged vs. enabled - I thought we converged on attached/detached
> and enabled/disabled and not plugged/unplugged?
>
> * Shared disks are attached with R/W permissions.
> - What about enabling R/O ? (esp. for stateless/pools)
>
Do we have ack from libvirt that attaching disk in r/o mode actually
works? (I know we opened a bug for testing this but i can't find the
bug
- Haim?)
>
> * Template disks should not be shared.
> - Why not? (read only)
>
> * When exporting a VM, only the disks which are not shared will be
> exported.
> - Why is the above not treated the same as a snapshot? the
> configuration will reference the shared disk as unplugged? (or
> will it and it's just not clear?)
>
It is not the same case as snapshot. We don't have in the export
domain
the shared image.
> I didn't touch stateless/pools but should be fixed to reflect
> comments on this thread.
>
> Is Remove shared disk and Delete shared disk the same thing? if so,
> why the dual terminology?
> I don't quite follow the logic determining which section is under
> functionality and which under user experience. For example, why
> do you have a 'Delete shared disk' section in the Ux section but
> not a 'Move shared disk' section (there is no shared disk specific
> logic visible in the delete action UI).
>
>
> * Disk name should be generated automatically based on the vm name
> and disk number in the VM. Description will be empty.
> * New disk should enforce the user to enter a name for the disk.
> - Huh? the above 2 items seem like an oxymoron, but I may be
> missing something...
>
The first line is referring to upgrade flow (it is under the upgrade
section), the second line is the behavior going forward.
I agree this is confusing, Maor I suggest you remove the general
behavior from the upgrade section.
> * Attach/Detach of a shared disk can be performed only when the VM
> is in status 'down'.
> - Why? under the functionality section you clearly stated that
> attaching a disk will result in it being attached but disabled...
>
>
I agree with Ayal on this.
Attach/Detach a disk should be enabled regardless if the VM is
running
or not, this applies to all disks not only to shared disk.
Maor, few more questions:
* "Regular disk can become a shared raw disk, by editing the existing
disk and marking the 'share disk' property type."
There are limitation to this, for example disk with snapshots can not
be
shared (we support only shared raw disks etc.)
* "When removing a VM with shared disks attached to it, the shared
disks
will not be deleted. "
If the shared disk is not attached to any other VM, why don't we
delete it?
I think we should behave with it as any other disk.
Maybe going forward when deleting a VM we should ask if to remove the
disks as well. This logic can apply to shared disk in the same way, I
don't think we should have a special logic around this for shared
disks.
Do we plan to support deleting disks in the disks tab? (as part of supporting
floating disks)
If not then we should delete the disk (as we won't be able to delete it after the last
VM using it is deleted....).
If we do, then I think we should indeed ask the user whether he would like to delete those
disks or not (in case it is the last VM).
Deleting it implicitly might be wrong, as these disks might contain data that the user
would like to attach to a new VM.
* The VDSM owner is missing from the doc, and vdsm is missing from
the
affected projects.
Livnat
>
> ----- Original Message -----
>> 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.
>>
>> - Move VM is deprecated in 3.1.
>>
>> - 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 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?
>>
>>
>> Livnat
>>
>> _______________________________________________
>> 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
11:44 a.m.
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?
* 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?
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.
Livnat
1:17 a.m.
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.
* 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
>
3:44 a.m.
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.
> * 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
>>
11:44 a.m.
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).
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
>>>
>
2:19 p.m.
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).
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?
4:17 p.m.
----- 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
4:20 a.m.
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
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.
My personal feeling is that this is the common use case.
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.
Although this is
a valid use case, I think this is very confusing and defeat the "notion" of
shared. So I would defer on this one for now.
> _______________________________________________
> 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
2:27 p.m.
On 02/15/2012 12:20 PM, Miki Kenneth wrote:
...
> 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.
My personal feeling is that this is the common use case.
my view is the use case of shared disk defined at template level is
nice, but can be done at a later phase. the higher priority would be to
actually support a shared disk, even if user needs to attach it to the
VMs they instantiated from the template.
so we need to remember the template use case, and not do things making
it more complex later, but can also do some validations preventing it if
it makes things more complex.
4452
days inactive
4465
days old
20 comments
7 participants
participants (7)
-
Ayal Baron -
Itamar Heim -
Livnat Peer -
Maor -
Miki Kenneth -
Oved Ourfalli -
Yaniv Kaul