----- Original Message ----- Belongs-To/Attached-To/

----- Original Message ----- Neither. There is no such thing as a VM disk or a Template disk. There are ReadOnly disks and Writeable disks. It just so happens that currently we only support read-only disks in templates, but we will probably remove this limitation in the future.

----- Original Message ----- 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.

----- Original Message ----- Indeed, it is related to the actual requirement afaiu. 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? Why? 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.