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

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Michael Kublin" <mkublin(a)redhat.com&gt; Cc: dlaor(a)redhat.com, engine-devel(a)ovirt.org 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(a)redhat.com&gt; >> To: "Michael Kublin" <mkublin(a)redhat.com&gt; >> Cc: dlaor(a)redhat.com, "Yaniv Kaul" <ykaul(a)redhat.com&gt;, >> engine-devel(a)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(a)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. >>>> - 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. >>> 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(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