[Engine-devel] 'deactivate' disk - what's the use case?
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. TIA, Y.
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
TIA, Y. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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), 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
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.
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
On 06/12/2012 12:47 PM, Livnat Peer 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
On 12/06/12 12:40, Yaniv Kaul wrote: 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.
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
On 12/06/12 14:14, Yaniv Kaul wrote:
On 06/12/2012 12:47 PM, Livnat Peer 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
On 12/06/12 12:40, Yaniv Kaul wrote: 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
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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 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
On 12/06/12 12:40, Yaniv Kaul wrote: 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) 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@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
On 06/17/2012 12:44 PM, Simon Grinberg wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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 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
On 12/06/12 12:40, Yaniv Kaul wrote: 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. 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@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
On 06/17/2012 12:44 PM, Simon Grinberg wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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 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
On 12/06/12 12:40, Yaniv Kaul wrote: 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@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
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message ----- From: "Ori Liel" <oliel@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <simon@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@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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 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
On 12/06/12 12:40, Yaniv Kaul wrote: 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@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
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (5)
-
Itamar Heim -
Livnat Peer -
Ori Liel -
Simon Grinberg -
Yaniv Kaul