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

Ori Liel oliel at redhat.com
Mon Jun 18 12:31:07 UTC 2012


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

>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



More information about the Devel mailing list