On 12/06/12 14:14, Yaniv Kaul wrote: > 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. > Y. >
Why detach requires one less click than deactivate, both should require a single click? BTW you should be able to attach and activate disk in a single action (to avoid non-user-friendly behavior like we have for SD). >> >> >>> 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@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