[Engine-devel] Low Level design for HotPlug/HotUnplug feature

Tue Jan 10 07:57:44 UTC 2012


----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: dlaor at redhat.com, engine-devel at ovirt.org, "Yaniv Kaul" <ykaul at redhat.com>
> Sent: Monday, January 9, 2012 5:44:25 PM
> Subject: Re: [Engine-devel] Low Level design for HotPlug/HotUnplug feature
> 
> 
> <snip>
> 
> On 09/01/12 16:04, Michael Kublin wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Michael Kublin" <mkublin at redhat.com>
> >> Cc: dlaor at redhat.com, "Yaniv Kaul" <ykaul at redhat.com>,
> >> engine-devel at ovirt.org
> >> Sent: Monday, January 9, 2012 3:07:06 PM
> >> Subject: Re: [Engine-devel] Low Level design for HotPlug/HotUnplug
> >> feature
> >>
> >> On 09/01/12 12:17, Dor Laor wrote:
> >>> On 01/09/2012 11:45 AM, Yaniv Kaul wrote:
> >>>> On 01/09/2012 11:21 AM, Michael Kublin wrote:
> >>>>> Hi, the follow link is providing a low level design for
> >>>>> HotPlug/HotUnplug feature
> >>>>> :http://www.ovirt.org/wiki/Features/DetailedHotPlug  .
> >>>>>
> >>>>> The feature is simple and design is short
> >>>>>
> >>>>> Regards Michael
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>>> 1. Corrected some typos, spelling, backend->engine, 'REST API'
> >>>> ->
> >>>> 'API',
> >>>> etc. (didn't fix ' storage procedures' - but I think you've
> >>>> meant
> >>>> 'stored procedures' ?).
> > Thanks
> >>>> 2. Missing/questions:
> >>>> - Permissions? Quota?
> > Regards Quota - has not influence on the feature
> 
> The storage quota enforcement is upon storage creation not disk plug.
> 
> >>>> - Explain how disk is created in the first place.
> > The disk is added to VM by AddDiskToVMCommand, by default is is
> > plugged
> 
> - The disk can be created as part of the VM or as a floating disk.
> - The disk has a property if it is plugged to the VM or not (VM-DISK
> relation property)
> - If the disk is created as a VM disk and it is marked as plugged the
> engine should try to hot plug the disk when the disk is created (if
> the
> VM is running), if it fails the disk should be left unplugged.
> 
> 
> >>>> - Database (tables, etc.)
> > They are in design
> >>>> - Which cluster level is required?
> > Added to design , it is 3.1
> 
> 3.1 cluster or DC?
> 
> Ayal - is there a storage limitation or can we activate this feature
> for
> any 3.1 cluster?
> 
> >>>> - Is it an async or sync task?
> > Sync
> >>>> - Can you plug a system disk?
> > No
> >>>> - Can you unplug multiple at a time?
> > Yes, we have not such limitation, the sane is to plug.
> 
> The engine does not have a single verb for plugging multiple disk in
> one
> action.
I think that question was if it possible to plug/unplug couple of disk in parallel on the same vm, by running couple of hotplug/unplug
in the same time  
> >>>> - What happens when you plug too many?
> > We allow to plug disk which were attached to vm , by
> > AddDiskToVmCommand, a max number of allowed disks is handled there
> 
> >>>> - How do you determine where (PCI bus-wise) to plug them?
> > As I think, the PCI address will be added to most devices at Stable
> > PCI device addresses feature, I will use it
> 
> The engine learns the device address from VDSM (given by libvirt), it
> is
> not editable by the user or the engine at this phase.
> 
> >>>> - Any CanDoAction to allow/disallow plug/unplug from specific
> >>>> systems?
> > The operation will be allowed only for RHEL 5/6, Windows Server
> > 2003 and Windows server 2008 operating systems, added to design
> >>>> - I suspect we'd be happier with some agent cooperation before
> >>>> unplugging - is this done by QEMU? Not detailed anywhere.
> > I will check this
> >>>> - Link to KVM/QEMU feature description for it, if such exist,
> >>>> would be
> >>>> nice.
> >>>> - Does it affect taking a snapshot? Live or not?
> > No, all disk will be passed to snapshots as is
> 
> snapshot includes unplugged disks, part of the snapshot is the VM
> configuration which includes for each disk if it is plugged or not.
> 
> >>>> - Does it affect exporting a VM? I reckon you export with all
> >>>> disks,
> >>>> with their plug/unplug status?
> > This one I need to check
> 
> Export includes all (non-shared) disks and their status.
So, I need to add a new tag to ovf xml of export what name I should take <plugged> </plugged> or something else?

> >>> In addition:
> >>>  - will you allow it during live migration (qemu allows it)?
> > I don't see any technical limitation from my side, but I will check
> >>>  - Are you expecting events to pop?
> >>>  - You call it 'hotplug' but mention only disk device, what about
> >>>    memory/cpu/ any other pci card?
> > The pci card it is another feature, in current version we have only
> > hotplug / unplug for disks and pci card
> >>>  - How do you define a system disk? Some VM may boot from
> >>>    pxe/nfsroot/etc
> > I had a property on the disk which means System, also I have a
> > property that means bootable. I suppose that
> > disk can not be plugged/unplugged with any of them
> >>>  - It should be a nice to have to check if the guest mounts any
> >>>  FS
> >>>    within the disk to be un hot pluged and warn the user
> > Need to be check
> >>
> >> In addition - 2 :
> >>
> >> - plugged/unplugged  disk is a VM property not disk's. (this of a
> >> shared
> >> disk that can be plugged in one VM but unplugged in another)
> > Ok. I will update design
> >> - supporting the best effort flag is not related only to hot plug
> >> disk,
> >> is it supported in the VDSM level on a per disk basis? again
> >> should
> >> not
> >> be a disk property but a VM-Disk relation property.
> >>
> >>
> >>>>
> >>>> Y.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >>
> 
>