[Engine-devel] VM disks
Hi, These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest. Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome). After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode. Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk? I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines. Thank you, Livnat
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: engine-devel@ovirt.org Sent: Saturday, February 18, 2012 7:07:01 PM Subject: [Engine-devel] VM disks
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome). After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
+1 on that (regardless of whether the disk is shared or not). IMO - in the case of shared disk we should make it as clear as possible to the user/admin that the added disk is shared, but the flow should be exactly the same.
Thank you, Livnat _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Oved Ourfalli" <ovedo@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, February 19, 2012 9:48:31 AM Subject: Re: [Engine-devel] VM disks
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: engine-devel@ovirt.org Sent: Saturday, February 18, 2012 7:07:01 PM Subject: [Engine-devel] VM disks
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it These should be in a one step, otherwise the clients (rest and gui) will need to pool us for every disk Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it These is just simple as a hot plug , should be and it is easy implement as one step It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome). After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows Agreed, should be in one step (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk? I don't see a reason also.
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
+1 on that (regardless of whether the disk is shared or not). IMO - in the case of shared disk we should make it as clear as possible to the user/admin that the added disk is shared, but the flow should be exactly the same. Also agreed
Thank you, Livnat _______________________________________________ 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: "Michael Kublin" <mkublin@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, February 19, 2012 9:59:51 AM Subject: Re: [Engine-devel] VM disks
----- Original Message -----
From: "Oved Ourfalli" <ovedo@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, February 19, 2012 9:48:31 AM Subject: Re: [Engine-devel] VM disks
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: engine-devel@ovirt.org Sent: Saturday, February 18, 2012 7:07:01 PM Subject: [Engine-devel] VM disks
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it These should be in a one step, otherwise the clients (rest and gui) will need to pool us for every disk Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it These is just simple as a hot plug , should be and it is easy implement as one step It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome). After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows Agreed, should be in one step (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk? I don't see a reason also.
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
+1 on that (regardless of whether the disk is shared or not). IMO - in the case of shared disk we should make it as clear as possible to the user/admin that the added disk is shared, but the flow should be exactly the same. Also agreed
+1 I think that any disk (new/attached) should be activated (plugged) by default. It seems less confusing to the user and probably a better UX. Joining the operations would save the client redundant disk status polling.
Thank you, Livnat _______________________________________________ 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 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome).
true, you'll be asked to provide an option for the initial state in that case.
After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
so hotunplug would make the disk floating, as it will detach it as well?
On 19/02/12 12:35, Itamar Heim wrote:
On 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome).
true, you'll be asked to provide an option for the initial state in that case.
After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
so hotunplug would make the disk floating, as it will detach it as well?
In short - yes. The user will be able to attach/detach disk, the implementation would be to hotplug or simply plug according to the VM status (up or not) .
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, February 19, 2012 1:23:56 PM Subject: Re: [Engine-devel] VM disks
On 19/02/12 12:35, Itamar Heim wrote:
On 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome).
true, you'll be asked to provide an option for the initial state in that case.
After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
so hotunplug would make the disk floating, as it will detach it as well?
In short - yes.
The user will be able to attach/detach disk, the implementation would be to hotplug or simply plug according to the VM status (up or not) .
What about disks with snapshots? By the current design of floating disks, detaching a disk with snapshots can be done only by collapsing and marking the snapshots as broken. Thus, removing a disk momentarily might be problematic without Plugged/Unplugged status. Maybe we should keep the current Activate/Deactivate buttons for disks in addition to encapsulating attach/detach and plug/unplug commands. So, adding/attaching a new disk will plug the disk automatically while allowing the user deactivating a disk temporarily.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 19/02/12 20:56, Daniel Erez wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, February 19, 2012 1:23:56 PM Subject: Re: [Engine-devel] VM disks
On 19/02/12 12:35, Itamar Heim wrote:
On 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome).
true, you'll be asked to provide an option for the initial state in that case.
After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
so hotunplug would make the disk floating, as it will detach it as well?
In short - yes.
The user will be able to attach/detach disk, the implementation would be to hotplug or simply plug according to the VM status (up or not) .
What about disks with snapshots? By the current design of floating disks, detaching a disk with snapshots can be done only by collapsing and marking the snapshots as broken. Thus, removing a disk momentarily might be problematic without Plugged/Unplugged status.
when taking the snapshots the user can choose if he wants to have the shared disk or direct lun in the snapshot or not, once the user makes the call that would be reflected in the snapshot configuration.
Maybe we should keep the current Activate/Deactivate buttons for disks in addition to encapsulating attach/detach and plug/unplug commands. So, adding/attaching a new disk will plug the disk automatically while allowing the user deactivating a disk temporarily.
IIUC that's the original design which I am suggesting to change. We got negative feedback on a similar approach with regard to storage domains I suspect it will be even more acute when it comes to VM disks which is much more common. Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 19/02/12 20:56, Daniel Erez wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, February 19, 2012 1:23:56 PM Subject: Re: [Engine-devel] VM disks
On 19/02/12 12:35, Itamar Heim wrote:
On 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome).
true, you'll be asked to provide an option for the initial state in that case.
After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
so hotunplug would make the disk floating, as it will detach it as well?
In short - yes.
The user will be able to attach/detach disk, the implementation would be to hotplug or simply plug according to the VM status (up or not) .
What about disks with snapshots? By the current design of floating disks, detaching a disk with snapshots can be done only by collapsing and marking the snapshots as broken. Thus, removing a disk momentarily might be problematic without Plugged/Unplugged status.
when taking the snapshots the user can choose if he wants to have the shared disk or direct lun in the snapshot or not, once the user makes the call that would be reflected in the snapshot configuration.
What derez meant is that once disk is detached from VM it cannot retain it's history, as today snapshot data is part of the VM definition and not the single disk, so then all it's images should be collapsed, especially if it is to be attached to an entirely different VM.
Maybe we should keep the current Activate/Deactivate buttons for disks in addition to encapsulating attach/detach and plug/unplug commands. So, adding/attaching a new disk will plug the disk automatically while allowing the user deactivating a disk temporarily.
IIUC that's the original design which I am suggesting to change. We got negative feedback on a similar approach with regard to storage domains I suspect it will be even more acute when it comes to VM disks which is much more common.
I think the downside of improving UX like you suggest (by chaining the atomic commands in the client IIUC), is that the client needs to poll us repetitively which poses several issues such as performance and the need for the client to manage a "transaction". Since these cases of the need to run several commands in a "flow" is increasing, maybe we need to offer a generic API that allows to run several commands in a simple flow (simple BPEL style perhaps?) and take the load off the clients.
Livnat
Top posting: It's not that I am for breaking the flow to create/attach/activate, but we need to consider all the use cases. Just want to highlight a use case, and pls find the solution for it: I've a VM with 4 different disks on 4 different storage domains. What will happen if the on Run VM when one of the SDs is inaccessible? Of course the VM should be able to run, but the Disk on the inaccessible SD should be "off/down"? Note that if the Disk on the inaccessible SD is "boot" disk, the Run VM should probably fail, or ? Thanks, Miki ----- Original Message -----
From: "Mike Kolesnik" <mkolesni@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, February 20, 2012 2:14:13 PM Subject: Re: [Engine-devel] VM disks
On 19/02/12 20:56, Daniel Erez wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, February 19, 2012 1:23:56 PM Subject: Re: [Engine-devel] VM disks
On 19/02/12 12:35, Itamar Heim wrote:
On 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome).
true, you'll be asked to provide an option for the initial state in that case.
After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
so hotunplug would make the disk floating, as it will detach it as well?
In short - yes.
The user will be able to attach/detach disk, the implementation would be to hotplug or simply plug according to the VM status (up or not) .
What about disks with snapshots? By the current design of floating disks, detaching a disk with snapshots can be done only by collapsing and marking the snapshots as broken. Thus, removing a disk momentarily might be problematic without Plugged/Unplugged status.
when taking the snapshots the user can choose if he wants to have the shared disk or direct lun in the snapshot or not, once the user makes the call that would be reflected in the snapshot configuration.
What derez meant is that once disk is detached from VM it cannot retain it's history, as today snapshot data is part of the VM definition and not the single disk, so then all it's images should be collapsed, especially if it is to be attached to an entirely different VM.
Maybe we should keep the current Activate/Deactivate buttons for disks in addition to encapsulating attach/detach and plug/unplug commands. So, adding/attaching a new disk will plug the disk automatically while allowing the user deactivating a disk temporarily.
IIUC that's the original design which I am suggesting to change. We got negative feedback on a similar approach with regard to storage domains I suspect it will be even more acute when it comes to VM disks which is much more common.
I think the downside of improving UX like you suggest (by chaining the atomic commands in the client IIUC), is that the client needs to poll us repetitively which poses several issues such as performance and the need for the client to manage a "transaction".
Since these cases of the need to run several commands in a "flow" is increasing, maybe we need to offer a generic API that allows to run several commands in a simple flow (simple BPEL style perhaps?) and take the load off the clients.
Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
This is a multi-part message in MIME format. --------------050009000602080805050601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,
These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest.
Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it
Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it
It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome). After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.
And since you probably can't find a good reason to have two steps for storage domain, lets fix this as well. (Downstream RFE https://bugzilla.redhat.com/show_bug.cgi?id=567585 - discuss only the export domain, but I'm quite sure it's applicable to other domains as well) Y.
Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk?
I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines.
Thank you, Livnat _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--------------050009000602080805050601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 02/18/2012 07:07 PM, Livnat Peer wrote: <blockquote cite="mid:4F3FDAB5.9020203@redhat.com" type="cite"> <pre wrap="">Hi, These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest. Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome). After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode.</pre> </blockquote> <br> And since you probably can't find a good reason to have two steps for storage domain, lets fix this as well.<br> (Downstream RFE <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=567585">https://bugzilla.redhat.com/show_bug.cgi?id=567585</a> - discuss only the export domain, but I'm quite sure it's applicable to other domains as well)<br> Y.<br> <br> <blockquote cite="mid:4F3FDAB5.9020203@redhat.com" type="cite"> <pre wrap=""> Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk? I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines. Thank you, Livnat _______________________________________________ Engine-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <br> </body> </html> --------------050009000602080805050601--
participants (8)
-
Daniel Erez -
Itamar Heim -
Livnat Peer -
Michael Kublin -
Mike Kolesnik -
Miki Kenneth -
Oved Ourfalli -
Yaniv Kaul