[Engine-devel] Floating Disk feature description
Hi, Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk Best Regards, Daniel
On 02/01/2012 07:04 PM, Daniel Erez wrote:
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
some questions/notes: 1. why do you need a floating/not floating state? isn't a disk floating if it was detached from all VMs? or is that only a helper property to optimize lookups? 2. you mention fields of disks (Floating/Shared/Managed) 2.1 do we have a definition of "Managed" disk somewhere? I assume unmanaged would be a direct LUN, but i think we need a better terminology here. 2.2 same goes for "floating" actually... do we really want to tell the user the disk is "floating"? I guess suggestion welcome for a better name. 2.3 finally, for shared, maybe more interesting is number of VMs the disk is connected to, rather than just a boolean (though i assume this increases complexity for calculation, or redundancy of data, and not a big issue) 3. List of Storage Domains in which the selected Disk resides. this is only relevant for template disks? maybe consider splitting the main grid if looking at tempalte disks or vm disks, and show for vm disks the storage domain in main grid? maybe start with vm disks only and not consider template disks so much? 4. "Templates (visible for disks that reside in templates) List of Templates to which the selected Disk is attached. " same comment as above of maybe consider only vm disks for now. and also a question - how can a template disk belong to more than a single template? which again hints for a template disk you would want another view, with the template name in the main grid 5. Tree: 'Resources' vs. 'free disks' while i understand why separating them - naming is very confusing. maybe a single node in tree and a way to filter the search from the right side grid in some manner for known lookups (relevant to other main tabs as well?) 6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me. or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase. I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM) 7. related features - data ware house may be affected by disks being unattached, or shared between multiple disks.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 9:08:56 AM Subject: Re: [Engine-devel] Floating Disk feature description
On 02/01/2012 07:04 PM, Daniel Erez wrote:
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
some questions/notes: 1. why do you need a floating/not floating state? isn't a disk floating if it was detached from all VMs? or is that only a helper property to optimize lookups?
Yes, the floating state is an indication whether the disk is attached to any VM. It's not a persistent property on the disk, but rather a DB view calculated value.
2. you mention fields of disks (Floating/Shared/Managed)
2.1 do we have a definition of "Managed" disk somewhere? I assume unmanaged would be a direct LUN, but i think we need a better terminology here.
Indeed, we're looking for a better teminology. Suggestions are welcomed...
2.2 same goes for "floating" actually... do we really want to tell the user the disk is "floating"? I guess suggestion welcome for a better name.
"unattached" has been mentioned once as an alternative.
2.3 finally, for shared, maybe more interesting is number of VMs the disk is connected to, rather than just a boolean (though i assume this increases complexity for calculation, or redundancy of data, and not a big issue)
Actually, as part of the "Shared raw disk" feature, we do want to display the number of VMs (and probably a list too) the disk is connected to - in the 'Disks' sub-tab (under VMs main tab). Hence, it might be rather simple to show that number also in the Disks main tab (the list of VMs will be displayed under VMs sub-tab).
3. List of Storage Domains in which the selected Disk resides. this is only relevant for template disks?
Yes, it's only for cloned templates.
maybe consider splitting the main grid if looking at tempalte disks or vm disks, and show for vm disks the storage domain in main grid? maybe start with vm disks only and not consider template disks so much?
Miki?
4. "Templates (visible for disks that reside in templates) List of Templates to which the selected Disk is attached. "
same comment as above of maybe consider only vm disks for now. and also a question - how can a template disk belong to more than a single template?
Yes, for now, a template disk cannot belong to more than a single template. However, won't we like to have a shared disk for a template in the future?
which again hints for a template disk you would want another view, with the template name in the main grid
5. Tree: 'Resources' vs. 'free disks' while i understand why separating them - naming is very confusing. maybe a single node in tree and a way to filter the search from the right side grid in some manner for known lookups (relevant to other main tabs as well?)
For now, we've agreed that sorting abilities in columns is needed for easing the orientation.
6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me.
or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase.
I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM)
Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user.
7. related features - data ware house may be affected by disks being unattached, or shared between multiple disks.
On 02/02/2012 12:25 PM, Daniel Erez wrote: > > ----- Original Message ----- >> From: "Itamar Heim"<iheim@redhat.com> >> To: "Daniel Erez"<derez@redhat.com> >> Cc: engine-devel@ovirt.org >> Sent: Thursday, February 2, 2012 9:08:56 AM >> Subject: Re: [Engine-devel] Floating Disk feature description >> >> On 02/01/2012 07:04 PM, Daniel Erez wrote: >>> Hi, >>> >>> Floating Disk feature description Wiki page: >>> http://www.ovirt.org/wiki/Features/DetailedFloatingDisk >> some questions/notes: >> 1. why do you need a floating/not floating state? isn't a disk >> floating >> if it was detached from all VMs? >> or is that only a helper property to optimize lookups? >> > Yes, the floating state is an indication whether the disk is attached to any VM. > It's not a persistent property on the disk, but rather a DB view calculated value. > >> 2. you mention fields of disks (Floating/Shared/Managed) >> >> 2.1 do we have a definition of "Managed" disk somewhere? >> I assume unmanaged would be a direct LUN, but i think we need a >> better >> terminology here. > Indeed, we're looking for a better teminology. Suggestions are welcomed... > >> 2.2 same goes for "floating" actually... do we really want to tell >> the >> user the disk is "floating"? >> I guess suggestion welcome for a better name. > "unattached" has been mentioned once as an alternative. Google says the world prefers 'detached': ~196M entries vs. ~5.7M entries for 'unattached'. Y. > >> 2.3 finally, for shared, maybe more interesting is number of VMs the >> disk is connected to, rather than just a boolean (though i assume >> this >> increases complexity for calculation, or redundancy of data, and not >> a >> big issue) > Actually, as part of the "Shared raw disk" feature, we do want to display the number of VMs > (and probably a list too) the disk is connected to - in the 'Disks' sub-tab (under VMs main tab). > Hence, it might be rather simple to show that number also in the Disks main tab > (the list of VMs will be displayed under VMs sub-tab). > >> 3. List of Storage Domains in which the selected Disk resides. >> this is only relevant for template disks? > Yes, it's only for cloned templates. > >> maybe consider splitting the main grid if looking at tempalte disks >> or >> vm disks, and show for vm disks the storage domain in main grid? >> maybe start with vm disks only and not consider template disks so >> much? > Miki? > >> 4. "Templates (visible for disks that reside in templates) List of >> Templates to which the selected Disk is attached. " >> >> same comment as above of maybe consider only vm disks for now. >> and also a question - how can a template disk belong to more than a >> single template? > Yes, for now, a template disk cannot belong to more than a single template. > However, won't we like to have a shared disk for a template in the future? > >> which again hints for a template disk you would want another view, >> with >> the template name in the main grid >> >> 5. Tree: 'Resources' vs. 'free disks' >> while i understand why separating them - naming is very confusing. >> maybe a single node in tree and a way to filter the search from the >> right side grid in some manner for known lookups (relevant to other >> main >> tabs as well?) > For now, we've agreed that sorting abilities in columns is needed for easing the orientation. > >> 6. permissions not available for disks? >> at all? >> what do you mean power user would be able to attach them by their >> type? >> does it mean they can associate any shared disk in the system? I hope >> i'm misunderstanding, as doesn't make sense to me. >> >> or is this caveat specific to the user portal and not the admin? >> not allowing creating a floating disk from user portal is not a >> problem >> in my view for this phase. >> >> I assume anyone can add a disk on a storage domain they have quota >> to. >> who can edit a disk? remove a disk? attach disk to VM (which gives >> them >> ability to edit the disk) >> (attach disk to VM obviously requires permission on both disk and VM) > Since we won't support permissions on disks entities (at first stage), > as a compromise for the power user portal, we've agreed to simply hide > floating non shared disks from the user. > >> 7. related features >> - data ware house may be affected by disks being unattached, or >> shared >> between multiple disks. >> >> >> >> >> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Daniel Erez" <derez@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Miki Kenneth" <mkenneth@redhat.com>, engine-devel@ovirt.org Sent: Thursday, February 2, 2012 12:25:52 PM Subject: Re: [Engine-devel] Floating Disk feature description
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 9:08:56 AM Subject: Re: [Engine-devel] Floating Disk feature description
On 02/01/2012 07:04 PM, Daniel Erez wrote:
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
some questions/notes: 1. why do you need a floating/not floating state? isn't a disk floating if it was detached from all VMs? or is that only a helper property to optimize lookups?
Yes, the floating state is an indication whether the disk is attached to any VM. It's not a persistent property on the disk, but rather a DB view calculated value.
2. you mention fields of disks (Floating/Shared/Managed)
2.1 do we have a definition of "Managed" disk somewhere? I assume unmanaged would be a direct LUN, but i think we need a better terminology here.
Indeed, we're looking for a better teminology. Suggestions are welcomed...
2.2 same goes for "floating" actually... do we really want to tell the user the disk is "floating"? I guess suggestion welcome for a better name.
"unattached" has been mentioned once as an alternative.
2.3 finally, for shared, maybe more interesting is number of VMs the disk is connected to, rather than just a boolean (though i assume this increases complexity for calculation, or redundancy of data, and not a big issue)
Actually, as part of the "Shared raw disk" feature, we do want to display the number of VMs (and probably a list too) the disk is connected to - in the 'Disks' sub-tab (under VMs main tab). Hence, it might be rather simple to show that number also in the Disks main tab (the list of VMs will be displayed under VMs sub-tab).
3. List of Storage Domains in which the selected Disk resides. this is only relevant for template disks?
Yes, it's only for cloned templates.
maybe consider splitting the main grid if looking at tempalte disks or vm disks, and show for vm disks the storage domain in main grid? maybe start with vm disks only and not consider template disks so much?
Miki? Good point - we can do either by a column and sortby or by two-interchangeable tabs. There are two many properties we would like to sort by, that's way I suggested the column way.
4. "Templates (visible for disks that reside in templates) List of Templates to which the selected Disk is attached. "
same comment as above of maybe consider only vm disks for now. and also a question - how can a template disk belong to more than a single template?
Yes, for now, a template disk cannot belong to more than a single template. However, won't we like to have a shared disk for a template in the future?
which again hints for a template disk you would want another view, with the template name in the main grid
5. Tree: 'Resources' vs. 'free disks' while i understand why separating them - naming is very confusing. maybe a single node in tree and a way to filter the search from the right side grid in some manner for known lookups (relevant to other main tabs as well?)
For now, we've agreed that sorting abilities in columns is needed for easing the orientation.
6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me.
or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase.
I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM)
Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user.
7. related features - data ware house may be affected by disks being unattached, or shared between multiple disks.
----- Original Message ----- From: "Miki Kenneth" <mkenneth@redhat.com> Sent: Thursday, February 2, 2012 2:10:54 PM ...
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
some questions/notes: 1. why do you need a floating/not floating state? isn't a disk floating if it was detached from all VMs? or is that only a helper property to optimize lookups?
Yes, the floating state is an indication whether the disk is attached to any VM. It's not a persistent property on the disk, but rather a DB view calculated value.
2. you mention fields of disks (Floating/Shared/Managed)
2.1 do we have a definition of "Managed" disk somewhere? I assume unmanaged would be a direct LUN, but i think we need a better terminology here.
Indeed, we're looking for a better teminology. Suggestions are welcomed...
2.2 same goes for "floating" actually... do we really want to tell the user the disk is "floating"? I guess suggestion welcome for a better name.
"unattached" has been mentioned once as an alternative.
2.3 finally, for shared, maybe more interesting is number of VMs the disk is connected to, rather than just a boolean (though i assume this increases complexity for calculation, or redundancy of data, and not a big issue)
Actually, as part of the "Shared raw disk" feature, we do want to display the number of VMs (and probably a list too) the disk is connected to - in the 'Disks' sub-tab (under VMs main tab). Hence, it might be rather simple to show that number also in the Disks main tab (the list of VMs will be displayed under VMs sub-tab).
3. List of Storage Domains in which the selected Disk resides. this is only relevant for template disks?
Yes, it's only for cloned templates.
maybe consider splitting the main grid if looking at tempalte disks or vm disks, and show for vm disks the storage domain in main grid? maybe start with vm disks only and not consider template disks so much?
Miki? Good point - we can do either by a column and sortby or by two-interchangeable tabs. There are two many properties we would like to sort by, that's way I suggested the column way.
I actually believe that Itamar's suggestion of "start with vm disks only and not consider template disks so much" is better and simpler; Template Disks aren't the reason for implementing the Disks main tab anyway: there shouldn't be to many template disks in the system and they are not floating/shared, they cannot be attached/detached, etc. Having two grids in a main tab isn't consistent with the current graphical "language" of the GUI. We can still have a single grid with a column for indication for "VM Disk vs. Template Disk", however having there also a column of "storage domain" or "template name" is problematic ("storage domain" column is problematic for Template Disks, since they can reside on multiple storage domains; "template name" is problematic, since it is relevant only for templates' disks).
4. "Templates (visible for disks that reside in templates) List of Templates to which the selected Disk is attached. "
same comment as above of maybe consider only vm disks for now. and also a question - how can a template disk belong to more than a single template?
Yes, for now, a template disk cannot belong to more than a single template. However, won't we like to have a shared disk for a template in the future?
which again hints for a template disk you would want another view, with the template name in the main grid
Again, as I stated above - maybe worth ignoring Templates' Disks altogether in the Disks main tab context.
5. Tree: 'Resources' vs. 'free disks' while i understand why separating them - naming is very confusing. maybe a single node in tree and a way to filter the search from the right side grid in some manner for known lookups (relevant to other main tabs as well?)
For now, we've agreed that sorting abilities in columns is needed for easing the orientation.
6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me.
or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase.
I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM)
Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user.
7. related features - data ware house may be affected by disks being unattached, or shared between multiple disks.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 02/02/2012 12:25 PM, Daniel Erez wrote: ...
6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me.
or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase.
I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM)
Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user.
I still think we won't find a decent way to model this without permissions, regardless of the power user portal. we'll hit too many problems. I'll look into this a bit more.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 4:29:30 PM Subject: Re: [Engine-devel] Floating Disk feature description
On 02/02/2012 12:25 PM, Daniel Erez wrote: ...
6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me.
or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase.
I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM)
Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user.
I still think we won't find a decent way to model this without permissions, regardless of the power user portal. we'll hit too many problems. I'll look into this a bit more.
I agree that permissions on disks are the right solution. But, if not possible to have disk permissions in the next version, as a compromise, maybe we can somehow use Quota. i.e, only users with permissions to consume from the Quota the disk resides on can attach the disk to another VM (if unattached). It can work to shared disks as well. There are some problems in this solution, though, as not everyone will use Quotas, you might want to share disks regardless of Quota, Thoughts?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 02/02/2012 07:05 PM, Oved Ourfalli wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Daniel Erez"<derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 4:29:30 PM Subject: Re: [Engine-devel] Floating Disk feature description
On 02/02/2012 12:25 PM, Daniel Erez wrote: ...
6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me.
or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase.
I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM)
Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user.
I still think we won't find a decent way to model this without permissions, regardless of the power user portal. we'll hit too many problems. I'll look into this a bit more.
I agree that permissions on disks are the right solution.
But, if not possible to have disk permissions in the next version, as a compromise, maybe we can somehow use Quota. i.e, only users with permissions to consume from the Quota the disk resides on can attach the disk to another VM (if unattached). It can work to shared disks as well.
There are some problems in this solution, though, as not everyone will use Quotas, you might want to share disks regardless of Quota,
quota is fine for a permission to add a floating disk, as quotas are the way we manage permissions to add disks to VMs as well. problem is with 'add/import external disk', which would be a system wide permission (that should be ok, it is not a permission on a disk, rather on system). my problem is with permission on the created (or detached) disks - who can edit/delete/attach them (and attach is a special case, as it requires checking permission on both disk and vm)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 9:08:56 AM Subject: Re: [Engine-devel] Floating Disk feature description
On 02/01/2012 07:04 PM, Daniel Erez wrote:
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
some questions/notes: 1. why do you need a floating/not floating state? isn't a disk floating if it was detached from all VMs? or is that only a helper property to optimize lookups?
2. you mention fields of disks (Floating/Shared/Managed)
2.1 do we have a definition of "Managed" disk somewhere? I assume unmanaged would be a direct LUN, but i think we need a better terminology here.
2.2 same goes for "floating" actually... do we really want to tell the user the disk is "floating"? I guess suggestion welcome for a better name.
2.3 finally, for shared, maybe more interesting is number of VMs the disk is connected to, rather than just a boolean (though i assume this increases complexity for calculation, or redundancy of data, and not a big issue)
3. List of Storage Domains in which the selected Disk resides. this is only relevant for template disks? maybe consider splitting the main grid if looking at tempalte disks or vm disks, and show for vm disks the storage domain in main grid? maybe start with vm disks only and not consider template disks so much?
4. "Templates (visible for disks that reside in templates) List of Templates to which the selected Disk is attached. "
same comment as above of maybe consider only vm disks for now. and also a question - how can a template disk belong to more than a single template?
which again hints for a template disk you would want another view, with the template name in the main grid
5. Tree: 'Resources' vs. 'free disks' while i understand why separating them - naming is very confusing. maybe a single node in tree and a way to filter the search from the right side grid in some manner for known lookups (relevant to other main tabs as well?) I agree - we need to find a nicer way. Maybe Eldan can help.
6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me.
or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase.
I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM) This is a huge caveat!!! and we need to find a way to allow accessing floating disks from the Power User portal. Tough I understand the complexity, let's think what can be done to overcome at least the attach process.
7. related features - data ware house may be affected by disks being unattached, or shared between multiple disks.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 02/01/2012 07:04 PM, Daniel Erez wrote:
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
Best Regards, Daniel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image) 1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide. 2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever? Y.
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 10:27:06 AM Subject: Re: [Engine-devel] Floating Disk feature description
On 02/01/2012 07:04 PM, Daniel Erez wrote:
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
Best Regards, Daniel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image)
Disk and Image are the same ("Disk" is the RHEV-M term for VDSM's "Image"). Both of them means: the collection of "volumes" (or, "DiskImages", in RHEV-M terminology) that comprise the full disk. We have no problem using either terminology, however might be confusing either way. [BTW, a floating disk can't conatin snapshots - so it doesn't really matter if you are talking about disk, image, diskImage or volume - they are all the same]
1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide.
The enforcement for uniqueness has been suggested for avoiding a list of duplicate named disks in the Disks main tab and for identifying a specific disk. Probelm is that any disk theoretically can be floating, so you cannot differentiate between the disks using the VM name to which it is attached, for example (moreover, some of the disks in the system are shared, so which VM name will you use?...) Maybe we can use some other attribute for identification?
2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever?
Currently, Export is done in a VM/Template level. Support in export/import (floating) disks is a new functionality which requires additional thinking/design/etc.
Y.
On 02/02/2012 01:35 PM, Daniel Erez wrote:
----- Original Message -----
From: "Yaniv Kaul"<ykaul@redhat.com> To: "Daniel Erez"<derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 10:27:06 AM Subject: Re: [Engine-devel] Floating Disk feature description
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
Best Regards, Daniel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 02/01/2012 07:04 PM, Daniel Erez wrote: 0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image) Disk and Image are the same ("Disk" is the RHEV-M term for VDSM's "Image"). Both of them means: the collection of "volumes" (or, "DiskImages", in RHEV-M terminology) that comprise the full disk. We have no problem using either terminology, however might be confusing either way. [BTW, a floating disk can't conatin snapshots - so it doesn't really matter if you are talking about disk, image, diskImage or volume - they are all the same]
If they are the same, then please use the term 'image'. And it looks like the feature is 'floating single-volume image' . I wonder if the limitation is really an issue or not. Can't think of a real use case it would be, but here's an imaginary one: before attaching it to a VM (or after and before running), I'd take a snapshot, then run the VM, do whatever, and revert before/after detaching, so the floating would go back to its original state.
1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide. The enforcement for uniqueness has been suggested for avoiding a list of duplicate named disks in the Disks main tab and for identifying a specific disk.
Understood, but it's not good enough. Need to solve this, as it's not practical to ask me not to share a property with you - which both us do not really share.
Probelm is that any disk theoretically can be floating, so you cannot differentiate between the disks using the VM name to which it is attached, for example (moreover, some of the disks in the system are shared, so which VM name will you use?...)
The fact VM names are unique is also an annoying, problematic issue, but I imagine there are less VMs than disks, and most are going to be FQDN based anyway. 'system' and 'data' are quite common names for disks, whereas VM names might be more original. Anyway, both don't scale.
Maybe we can use some other attribute for identification?
The real identification can be done via the serial number, no harm in displaying that cryptic ID in the UI. Makes us look professional. Of course, it makes more sense to use the volume UUID. May come handy in locating it physically on disk, if it exists.
2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever? Currently, Export is done in a VM/Template level. Support in export/import (floating) disks is a new functionality which requires additional thinking/design/etc.
Right, so lets add 'currently not supported'. Y.
Y.
----- Original Message ----- From: "Yaniv Kaul" <ykaul@redhat.com> Sent: Thursday, February 2, 2012 1:43:58 PM
On 02/02/2012 01:35 PM, Daniel Erez wrote:
----- Original Message -----
From: "Yaniv Kaul"<ykaul@redhat.com> To: "Daniel Erez"<derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 10:27:06 AM Subject: Re: [Engine-devel] Floating Disk feature description
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
Best Regards, Daniel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 02/01/2012 07:04 PM, Daniel Erez wrote: 0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image) Disk and Image are the same ("Disk" is the RHEV-M term for VDSM's "Image"). Both of them means: the collection of "volumes" (or, "DiskImages", in RHEV-M terminology) that comprise the full disk. We have no problem using either terminology, however might be confusing either way. [BTW, a floating disk can't conatin snapshots - so it doesn't really matter if you are talking about disk, image, diskImage or volume - they are all the same]
If they are the same, then please use the term 'image'.
As I said - no technical problem doing that, however in the engine we use the term "Disk" and the current name of the relevant VMs sub-tab is "Disks" and the name of the new main tab would be "Disks" (or "Virtual Disks"), etc. - so it will be strange to call the feature "floating image" when "floating" is going to be column in a GUI grid titled "Disks". I assume that you can also find explanations of why using the term "Disk" is confusing and "Image" is better; I am just genuinely not sure what is less confusing.
And it looks like the feature is 'floating single-volume image' . I wonder if the limitation is really an issue or not. Can't think of a real use case it would be, but here's an imaginary one: before attaching it to a VM (or after and before running), I'd take a snapshot, then run the VM, do whatever, and revert before/after detaching, so the floating would go back to its original state.
1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide. The enforcement for uniqueness has been suggested for avoiding a list of duplicate named disks in the Disks main tab and for identifying a specific disk.
Understood, but it's not good enough. Need to solve this, as it's not practical to ask me not to share a property with you - which both us do not really share.
Probelm is that any disk theoretically can be floating, so you cannot differentiate between the disks using the VM name to which it is attached, for example (moreover, some of the disks in the system are shared, so which VM name will you use?...)
The fact VM names are unique is also an annoying, problematic issue, but I imagine there are less VMs than disks, and most are going to be FQDN based anyway. 'system' and 'data' are quite common names for disks, whereas VM names might be more original. Anyway, both don't scale.
Maybe we can use some other attribute for identification?
The real identification can be done via the serial number, no harm in displaying that cryptic ID in the UI. Makes us look professional. Of course, it makes more sense to use the volume UUID. May come handy in locating it physically on disk, if it exists.
2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever? Currently, Export is done in a VM/Template level. Support in export/import (floating) disks is a new functionality which requires additional thinking/design/etc.
Right, so lets add 'currently not supported'. Y.
Y.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: engine-devel@ovirt.org, "Daniel Erez" <derez@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com> Sent: Thursday, February 2, 2012 4:45:30 PM Subject: Re: [Engine-devel] Floating Disk feature description
----- Original Message ----- From: "Yaniv Kaul" <ykaul@redhat.com> Sent: Thursday, February 2, 2012 1:43:58 PM
On 02/02/2012 01:35 PM, Daniel Erez wrote:
----- Original Message -----
From: "Yaniv Kaul"<ykaul@redhat.com> To: "Daniel Erez"<derez@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 10:27:06 AM Subject: Re: [Engine-devel] Floating Disk feature description
Hi,
Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
Best Regards, Daniel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 02/01/2012 07:04 PM, Daniel Erez wrote: 0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image) Disk and Image are the same ("Disk" is the RHEV-M term for VDSM's "Image"). Both of them means: the collection of "volumes" (or, "DiskImages", in RHEV-M terminology) that comprise the full disk. We have no problem using either terminology, however might be confusing either way. [BTW, a floating disk can't conatin snapshots - so it doesn't really matter if you are talking about disk, image, diskImage or volume - they are all the same]
If they are the same, then please use the term 'image'.
As I said - no technical problem doing that, however in the engine we use the term "Disk" and the current name of the relevant VMs sub-tab is "Disks" and the name of the new main tab would be "Disks" (or "Virtual Disks"), etc. - so it will be strange to call the feature "floating image" when "floating" is going to be column in a GUI grid titled "Disks". I assume that you can also find explanations of why using the term "Disk" is confusing and "Image" is better; I am just genuinely not sure what is less confusing. This is inconsistency I agree, but I think that from the User perspective we should stick with either Disk or Drive. In any OS of a Server/Desktop the term rather Disk or Drives.
And it looks like the feature is 'floating single-volume image' . I wonder if the limitation is really an issue or not. Can't think of a real use case it would be, but here's an imaginary one: before attaching it to a VM (or after and before running), I'd take a snapshot, then run the VM, do whatever, and revert before/after detaching, so the floating would go back to its original state.
1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide. The enforcement for uniqueness has been suggested for avoiding a list of duplicate named disks in the Disks main tab and for identifying a specific disk.
Understood, but it's not good enough. Need to solve this, as it's not practical to ask me not to share a property with you - which both us do not really share.
Probelm is that any disk theoretically can be floating, so you cannot differentiate between the disks using the VM name to which it is attached, for example (moreover, some of the disks in the system are shared, so which VM name will you use?...)
The fact VM names are unique is also an annoying, problematic issue, but I imagine there are less VMs than disks, and most are going to be FQDN based anyway. 'system' and 'data' are quite common names for disks, whereas VM names might be more original. Anyway, both don't scale.
Maybe we can use some other attribute for identification?
The real identification can be done via the serial number, no harm in displaying that cryptic ID in the UI. Makes us look professional. Of course, it makes more sense to use the volume UUID. May come handy in locating it physically on disk, if it exists.
2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever? Currently, Export is done in a VM/Template level. Support in export/import (floating) disks is a new functionality which requires additional thinking/design/etc.
Right, so lets add 'currently not supported'. Y.
Y.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 02/02/2012 05:13 PM, Miki Kenneth wrote:
If they are the same, then please use the term 'image'.
As I said - no technical problem doing that, however in the engine we use the term "Disk" and the current name of the relevant VMs sub-tab is "Disks" and the name of the new main tab would be "Disks" (or "Virtual Disks"), etc. - so it will be strange to call the feature "floating image" when "floating" is going to be column in a GUI grid titled "Disks". I assume that you can also find explanations of why using the term "Disk" is confusing and "Image" is better; I am just genuinely not sure what is less confusing. This is inconsistency I agree, but I think that from the User perspective we should stick with either Disk or Drive. In any OS of a Server/Desktop the term rather Disk or Drives.
I'd go with what the REST API calls them right now, as changing it would be the painful part.
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> Sent: Friday, February 3, 2012 12:47:35 PM
On 02/02/2012 05:13 PM, Miki Kenneth wrote:
If they are the same, then please use the term 'image'.
As I said - no technical problem doing that, however in the engine we use the term "Disk" and the current name of the relevant VMs sub-tab is "Disks" and the name of the new main tab would be "Disks" (or "Virtual Disks"), etc. - so it will be strange to call the feature "floating image" when "floating" is going to be column in a GUI grid titled "Disks". I assume that you can also find explanations of why using the term "Disk" is confusing and "Image" is better; I am just genuinely not sure what is less confusing. This is inconsistency I agree, but I think that from the User perspective we should stick with either Disk or Drive. In any OS of a Server/Desktop the term rather Disk or Drives.
I'd go with what the REST API calls them right now, as changing it would be the painful part.
REST API uses the term "disks", so I think that the current terminology for this feature should remain as is (it is also consistent with Miki's argument).
On 02/02/2012 01:35 PM, Daniel Erez wrote: ...
1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide.
The enforcement for uniqueness has been suggested for avoiding a list of duplicate named disks in the Disks main tab and for identifying a specific disk. Probelm is that any disk theoretically can be floating, so you cannot differentiate between the disks using the VM name to which it is attached, for example (moreover, some of the disks in the system are shared, so which VM name will you use?...) Maybe we can use some other attribute for identification?
I agree with Kaul here - you can't expect disk name to be unique. makes sense to make it unique inside same VM, but as you mentioned, there is an issue with floating disks. I suggest we consider disk ID would be a generated id humanoids can follow (not uuid), and a field for description. converting the uuid from hexadecimal to a full alphanumeric representation will probably give a short enough id we can live with[1] i.e., the disk real ID would be represented to the user as a short alphanumeric ID they cannot change. import/clone/etc. change the disk uuid anyway, so we'll get a new ID for these disks. i did a fast calculation it will be a a string of 12 characters with 36 alphanumeric to cover 128bit UUID - hope i didn't do it too fast
participants (6)
-
Daniel Erez -
Einav Cohen -
Itamar Heim -
Miki Kenneth -
Oved Ourfalli -
Yaniv Kaul