[Engine-devel] VM disks

[Mike Kolesnik]

> On 19/02/12 20:56, Daniel Erez wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: engine-devel at 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
> 
> 
>