9 Jan
2012
9 Jan
'12
1:04 p.m.
----- Original Message ----- > From: "Livnat Peer" <lpeer@redhat.com> > To: "Michael Kublin" <mkublin@redhat.com> > Cc: dlaor@redhat.com, "Yaniv Kaul" <ykaul@redhat.com>, engine-devel@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@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 > >> - Explain how disk is created in the first place. The disk is added to VM by AddDiskToVMCommand, by default is is plugged > >> - Database (tables, etc.) They are in design > >> - Which cluster level is required? Added to design , it is 3.1 > >> - 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. > >> - 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 > >> - 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 > >> - Does it affect exporting a VM? I reckon you export with all > >> disks, > >> with their plug/unplug status? This one I need to check > > 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@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 > >