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

----- Original Message ----- From: "Ori Liel" <oliel(a)redhat.com&gt; To: "Yaniv Kaul" <ykaul(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Simon Grinberg" <simon(a)redhat.com&gt; 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(a)redhat.com&gt; >>> To: "Livnat Peer" <lpeer(a)redhat.com&gt; >>> Cc: engine-devel(a)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(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > >_______________________________________________ >Engine-devel mailing list &gt;Engine-devel(a)ovirt.org >http://lists.ovirt.org/mailman/listinfo/engine-devel