----- Original Message ----- > > ----- Original Message ----- > > From: "Ayal Baron" <aba...@redhat.com> > > Sent: Wednesday, July 4, 2012 9:29:55 AM > > > > ----- Original Message ----- > > > On 07/03/2012 06:44 PM, Miki Kenneth wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> Hey, > > > >> > > > >> https://bugzilla.redhat.com/show_bug.cgi?id=828089 > > > >> > > > >> I would like add a search option for searching disks of a VM > > > >> or > > > >> Template, > > > >> > > > >> Please suggest a name for the search option, > > > >> In the 'view' level we call it 'entity_type', but maybe 'type' > > > >> is > > > >> nicer ? (or not too specific?) > > > > Belongs-To/Attached-To/ > > > Part of? > > > > So what do you do with a disk that is both in a template and > > attached > > read-only to a VM? (no, we do not currently support it, but we will > > as there is no reason not to). > > When a container references the disk, that is not a property of the > > disk so there should be no column indicating that when looking at > > the disk. > > The disk is either read only or read write, that's it. The column > > should state that. > > I think that "read-only/read-write" is not related to "attached to > Template(s)/attached to VM(s)/attached to both (not supported yet)".
Indeed, it is related to the actual requirement afaiu. > Moreover, wouldn't we want "read-only/read-write" to be per > VM/Template, and not a property of the Disk itself (i.e. a disk can > be writable in VM1 and read-only in VM2/Template1)? As opposed to > the "attached to Templates/attached to VMs" information, which is > clearly a property of the Disk (well, not a "real" property, as Ayal > has also mentioned - it is calculated information, based on the You can mount a r/w disk as read-only in a VM, so how to mount it is indeed a vm-disk relationship. However, a disk can be immutable (iso, read-only snapshot as we use for templates, etc). I've seen 2 RFEs here: 1. Be able to differentiate between disks (currently when you create a template from a VM then the disks would have the same alias and user has to stand on the disk itself to differentiate. As a result, what was requested is this column, however, if we create 2 templates from the same VM (different times so different content) the disks would end up still having the same alias, so this column would be useless for that purpose. What we need to do is: 1. make sure that by default we give different aliases to disks when creating a template 2. allow user to change the aliases when creating 3. allow user to change the aliases on existing disks (even when part of a template) Second type of request I've seen is about the types of operations that can be performed on the disks. The differences I know of are: 1. VM disks can only be moved between SDs - This has to do with the disk being r/w. You cannot have 2 copies of the same disk (you can clone it, but then you'd have 2 different disks with different UUIDs). 2. Template disks can only be copied between domains - This is actually not exactly true, as it can be copied, and also deleted from a domain (as long as one copy remains somewhere), just no 'move' operation. But again, the reason we can have multiple copies of the same disk (and one disk entity in engine referencing them all) is because it is immutable (i.e. read only). 3. Currently "template" disks cannot be deleted - This is the tricky one. "Template" disks are similar to "Shared disks" in the sense that there are multiple VMs using them. However, depending on the implementation, sometimes there is no problem in deleting the object (when using storage array cloning) and sometimes there is (with current images implementation). With the new image implementation in vdsm (no code committed yet) you should always be able to 'delete' the disk and underlying it would perform the correct operation (in case of file system - just delete it because we have hard links to it in each VM, in case of storage offloading - actually delete it and in case of block domains simply remove the image tag). So in fact, I see no reason why the user should not be able to delete the disk. As you can see, in the scenarios above there isn't a single case where 'attached-to-object(s)-of-type template/VM' is relevant. Are there additional use cases/something else which I'm missing? > entities to which the disk is attached to; still, it is interesting > information that "deserves" a column in the Disks main-grid IMO. Why? > ["read-only/read-write" is interesting information as well, and > should also be displayed - don't know if in the main grid or in the > VMs/Templates sub-tabs - probably worth a separate discussion] > On top of all this, our current approach to templates is quite limited. Our templates are comprised of 3 elements: 1. immutable disks 2. hardware configuration 3. migration domain + network config (which hosts can run it, what specific networks to attach to, etc). There is no reason for a user not to be able to mix and match. e.g. Provision from a disk with Fedora 16 + LibreOffice + whatever Hardware profile Medium (2 cores, 4GB memory. ...) Host Cluster - whatever (different than the one the VM used to create the template is in with different networks) In this view, for convenience, user could be able to create predefined profiles containing everything, but doesn't have to. Assuming we want to go down this path (open for discussion), then the column we're discussing would be totally irrelevant and wrong. > > > > > > > > >> > > > >> > > > >> Thanks, > > > >> > > > >> > > > >> > > > >> Regards, > > > >> Asaf > > > >> > > > >> > > > >> > > > >> > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
