From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: engine-devel(a)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.

Thank you, Livnat _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Michael Kublin" <mkublin(a)redhat.com&gt; To: engine-devel(a)ovirt.org Sent: Sunday, February 19, 2012 9:59:51 AM Subject: Re: [Engine-devel] VM disks ----- Original Message ----- > From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; > To: "Livnat Peer" <lpeer(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org > Sent: Sunday, February 19, 2012 9:48:31 AM > Subject: Re: [Engine-devel] VM disks > > > > ----- Original Message ----- > > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > > To: engine-devel(a)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(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

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?

----- Original Message ----- > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > To: "Itamar Heim" <iheim(a)redhat.com&gt; > Cc: engine-devel(a)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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >

From: "Mike Kolesnik" <mkolesni(a)redhat.com&gt; To: "Livnat Peer" <lpeer(a)redhat.com&gt; Cc: engine-devel(a)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(a)redhat.com&gt; > >> To: "Itamar Heim" <iheim(a)redhat.com&gt; > >> Cc: engine-devel(a)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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel