[Engine-devel] 'deactivate' disk - what's the use case?

[Ori Liel]

>
>
>----- Original Message -----
>From: "Ori Liel" <oliel at redhat.com>
>To: "Yaniv Kaul" <ykaul at redhat.com>
>Cc: engine-devel at ovirt.org, "Simon Grinberg" <simon at redhat.com>
>Sent: Monday, June 18, 2012 3:31:07 PM
>Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
>
>>On 06/17/2012 12:44 PM, Simon Grinberg wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Tuesday, June 12, 2012 2:14:00 PM
>>>> Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
>>>>
>>>> On 06/12/2012 12:47 PM, Livnat Peer wrote:
>>>>> On 12/06/12 12:40, Yaniv Kaul wrote:
>>>>>> On 06/12/2012 12:34 PM, Itamar Heim wrote:
>>>>>>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>>>>>>>> I'm wondering what's the usefulness of having dual action of
>>>>>>>> attach +
>>>>>>>> activate to get a disk properly attached and working in a VM
>>>>>>>> (and the
>>>>>>>> deactivate and detach counterparts).
>>>>>>>>
>>>>>>>> The only reason I can think of is that we've annoyed the user by
>>>>>>>> this
>>>>>>>> useless dual action when working with storage domains in a data
>>>>>>>> center
>>>>>>>> for ages, and we wish to remain consistent and annoy the user in
>>>>>>>> the
>>>>>>>> disks scenario as well, but there may be a reason I'm not aware
>>>>>>>> of.
>>>>>>> deactivated is like having a disk in offline, or hot unplugging
>>>>>>> when
>>>>>>> you still want to retain it in the context of the vm
>>>>>>> configuration
>>>>>> I understand that, I just argue it's quite useless (offline can be
>>>>>> done
>>>>>> from within the guest OS),
>>>>> You can deactivate the disk if for some reason it blocks the guest
>>>>> from
>>>>> starting. I think that if the disk not accessible the VM won't
>>>>> start and
>>>>> then you can deactivate the disk and start the VM.
>>>> You can also detach it to get the same effect with one less click of
>>>> a
>>>> button or an API call.
>>> And then if you did it manually for 20 VMs as a temporary measure, you'll have to re-attach it to the VMs. Will you remember to which VM you should attach each of your floating disks? You may have to now consult event log.
>>> (And in any case you'll need better search capabilities on disk then what you have now)
>>
>>I still fail to see what the common use case for
>>'deactivate-but-not-detach' is.
>
>Perhaps the use case is: "I want to run the VM without this disk, but I don't want 
>to make this disk available for other VMs" (since detached disk is 'up for grabs'.
>

(this is relevant only for non-shareable disks, as shareable disks can be attached to more
than one VM. If we only had only shareable disks in the system, then detach=deactivate).

>>I assume the description for the disk is automatically filled by engine
>>when the disk is created attached to the VM. I'm 99.9% my assumption is
>>naive and I'll open a RFE for it...
>>Y.
>>
>>>
>>> There are use cases to have an off-line disks, the issue is how not to annoy the user.
>>> I think I've suggested in the past that by default:
>>> Attach = Attach + set_Online
>>> Detach = set_offline + Detach.
>>> Unless explicitly stated otherwise by the user.
>>>
>>> Thus you do not annoy the user but still maintain the functionality.
>>>
>>>
>>>> Y.
>>>>
>>>>>
>>>>>> does not work that way in physical hardware
>>>>>> (offline is a logical action within the OS), has very little value
>>>>>> to
>>>>>> the RHEV Admin (unless he's paranoid and afraid that the disk will
>>>>>> become float and someone else would 'steal' it from his VM) and is
>>>>>> annoying to require multiple actions.
>>>>>> Y.
>>>>>>
>>>>>>>> TIA,
>>>>>>>> Y.
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel at ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>
>>
>>_______________________________________________
>>Engine-devel mailing list
>>Engine-devel at ovirt.org
>>http://lists.ovirt.org/mailman/listinfo/engine-devel