----- 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