[Engine-devel] Low Level design for HotPlug/HotUnplug feature
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
This is a multi-part message in MIME format. --------------070407050209030401020600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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' ?). 2. Missing/questions: - Permissions? Quota? - Explain how disk is created in the first place. - Database (tables, etc.) - Which cluster level is required? - Is it an async or sync task? - Can you plug a system disk? - Can you unplug multiple at a time? - What happens when you plug too many? - How do you determine where (PCI bus-wise) to plug them? - Any CanDoAction to allow/disallow plug/unplug from specific systems? - I suspect we'd be happier with some agent cooperation before unplugging - is this done by QEMU? Not detailed anywhere. - Link to KVM/QEMU feature description for it, if such exist, would be nice. - Does it affect taking a snapshot? Live or not? - Does it affect exporting a VM? I reckon you export with all disks, with their plug/unplug status? Y. --------------070407050209030401020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 01/09/2012 11:21 AM, Michael Kublin wrote: <blockquote cite="mid:a326aab2-28ec-4147-9265-9554cc356077@zmail14.collab.prod.int.phx2.redhat.com" type="cite"> <pre wrap="">Hi, the follow link is providing a low level design for HotPlug/HotUnplug feature : <a class="moz-txt-link-freetext" href="http://www.ovirt.org/wiki/Features/DetailedHotPlug">http://www.ovirt.org/wiki/Features/DetailedHotPlug</a> . The feature is simple and design is short Regards Michael _______________________________________________ Engine-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <br> 1. Corrected some typos, spelling, backend->engine, 'REST API' -> 'API', etc. (didn't fix ' <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> storage procedures' - but I think you've meant 'stored procedures' ?).<br> 2. Missing/questions:<br> - Permissions? Quota? <br> - Explain how disk is created in the first place.<br> - Database (tables, etc.)<br> - Which cluster level is required?<br> - Is it an async or sync task?<br> - Can you plug a system disk?<br> - Can you unplug multiple at a time?<br> - What happens when you plug too many?<br> - How do you determine where (PCI bus-wise) to plug them?<br> - Any CanDoAction to allow/disallow plug/unplug from specific systems?<br> - I suspect we'd be happier with some agent cooperation before unplugging - is this done by QEMU? Not detailed anywhere.<br> - Link to KVM/QEMU feature description for it, if such exist, would be nice.<br> - Does it affect taking a snapshot? Live or not?<br> - Does it affect exporting a VM? I reckon you export with all disks, with their plug/unplug status?<br> <br> Y.<br> <br> <br> <br> <br> </body> </html> --------------070407050209030401020600--
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' ?). 2. Missing/questions: - Permissions? Quota? - Explain how disk is created in the first place. - Database (tables, etc.) - Which cluster level is required? - Is it an async or sync task? - Can you plug a system disk? - Can you unplug multiple at a time? - What happens when you plug too many? - How do you determine where (PCI bus-wise) to plug them? - Any CanDoAction to allow/disallow plug/unplug from specific systems? - I suspect we'd be happier with some agent cooperation before unplugging - is this done by QEMU? Not detailed anywhere. - Link to KVM/QEMU feature description for it, if such exist, would be nice. - Does it affect taking a snapshot? Live or not? - Does it affect exporting a VM? I reckon you export with all disks, with their plug/unplug status?
In addition: - will you allow it during live migration (qemu allows it)? - Are you expecting events to pop? - You call it 'hotplug' but mention only disk device, what about memory/cpu/ any other pci card? - How do you define a system disk? Some VM may boot from pxe/nfsroot/etc - 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
Y.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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' ?). 2. Missing/questions: - Permissions? Quota? - Explain how disk is created in the first place. - Database (tables, etc.) - Which cluster level is required? - Is it an async or sync task? - Can you plug a system disk? - Can you unplug multiple at a time? - What happens when you plug too many? - How do you determine where (PCI bus-wise) to plug them? - Any CanDoAction to allow/disallow plug/unplug from specific systems? - I suspect we'd be happier with some agent cooperation before unplugging - is this done by QEMU? Not detailed anywhere. - Link to KVM/QEMU feature description for it, if such exist, would be nice. - Does it affect taking a snapshot? Live or not? - Does it affect exporting a VM? I reckon you export with all disks, with their plug/unplug status?
In addition: - will you allow it during live migration (qemu allows it)? - Are you expecting events to pop? - You call it 'hotplug' but mention only disk device, what about memory/cpu/ any other pci card? - How do you define a system disk? Some VM may boot from pxe/nfsroot/etc - 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
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) - 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
----- 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 > >
<snip> On 09/01/12 16:04, Michael Kublin wrote:
----- 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
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@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
sorry for top posting (and maybe not directly related) but: - is there a list of "free disks"? or a disk is always attached to a VM? Miki ----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Michael Kublin" <mkublin@redhat.com> Cc: dlaor@redhat.com, engine-devel@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@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
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@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
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Michael Kublin" <mkublin@redhat.com> Cc: dlaor@redhat.com, engine-devel@ovirt.org, "Yaniv Kaul" <ykaul@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@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
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@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
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
Can you make sure the storage supports that?
[SNIP]
- 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
IMO this behaviour is wrong. We should not prevent user from running hot plug on an unsupported system, just warn that this operation might fail and can crash the VM (downstream versions can warn that it is unsupported). E.g. if user installed a service pack on a windows not listed that adds support for hotplug, why should we prevent running the action? or worse, a new windows version is released and users of the existing system would not be able to hot plug. Alternatively, the list of OSs on which this works can be customizable by user in which case a knowledgeable user would modify at her own risk. IIRC there is an 'other' os type when creating a VM, why block on this? again, either warn or allow customizing behaviour.
- I suspect we'd be happier with some agent cooperation before unplugging - is this done by QEMU? Not detailed anywhere.
This is not currently planned, but should definitely be on the road map (need to add to the feature page and state that it will not be covered in 3.1)
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Michael Kublin" <mkublin@redhat.com> Cc: dlaor@redhat.com, engine-devel@ovirt.org Sent: Sunday, January 15, 2012 12:35:26 PM Subject: Re: [Engine-devel] Low Level design for HotPlug/HotUnplug feature
[SNIP]
> - 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
IMO this behaviour is wrong. We should not prevent user from running hot plug on an unsupported system, just warn that this operation might fail and can crash the VM (downstream versions can warn that it is unsupported). E.g. if user installed a service pack on a windows not listed that adds support for hotplug, why should we prevent running the action? or worse, a new windows version is released and users of the existing system would not be able to hot plug.
Alternatively, the list of OSs on which this works can be customizable by user in which case a knowledgeable user would modify at her own risk.
IIRC there is an 'other' os type when creating a VM, why block on this? again, either warn or allow customizing behaviour. I second. I think that we are being "over protective" on the admin. I tend to agree that warning should be a better behavior (if the VM is not damaged, just BSOD, than this is up to the admin to handle it)
> - I suspect we'd be happier with some agent cooperation > before > unplugging - is this done by QEMU? Not detailed anywhere.
This is not currently planned, but should definitely be on the road map (need to add to the feature page and state that it will not be covered in 3.1) _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
<snip>
- 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?
3.1 cluster
- 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.
How would one export a shared disk? [snip]
- 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
I thought we're making 'system disk' devoid of meaning and not adding any logic to such annotations... [snip]
Suppose, we unplug and then re-plug a disk, will VDSM expect the disk be in the same device path as before? More generic, will the unplugging and plugging keep the PCI device path as the same as before? On 2012-1-9 17:21, 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
-- Shu Ming<shuming@linux.vnet.ibm.com> IBM China Systems and Technology Laboratory
----- Original Message -----
Suppose, we unplug and then re-plug a disk, will VDSM expect the disk be in the same device path as before? More generic, will the unplugging and plugging keep the PCI device path as the same as before?
No guarantee for that. For example, suppose you unplug a disk, plug another disk then re-plug the first one. Unplug is just like removing a physical disk from your machine, the disk does not have any property stating what PCI address it had. It would be nice though if the address were kept and when plugging, if the address is not taken then use the same one and if taken then remove address and let the system choose where to place it...
On 2012-1-9 17:21, 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
-- Shu Ming<shuming@linux.vnet.ibm.com> IBM China Systems and Technology Laboratory
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 16/01/12 22:10, Ayal Baron wrote:
----- Original Message -----
Suppose, we unplug and then re-plug a disk, will VDSM expect the disk be in the same device path as before? More generic, will the unplugging and plugging keep the PCI device path as the same as before?
No guarantee for that. For example, suppose you unplug a disk, plug another disk then re-plug the first one. Unplug is just like removing a physical disk from your machine, the disk does not have any property stating what PCI address it had.
It would be nice though if the address were kept and when plugging, if the address is not taken then use the same one and if taken then remove address and let the system choose where to place it...
ack. Basically when you unplug the disk the management clears the device address and the device is left with no address. next time you plug the device and run the VM the management will learn the new address and persist it. Livnat
On 2012-1-9 17:21, 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
-- Shu Ming<shuming@linux.vnet.ibm.com> IBM China Systems and Technology Laboratory
_______________________________________________ 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
participants (7)
-
Ayal Baron -
Dor Laor -
Livnat Peer -
Michael Kublin -
Miki Kenneth -
Shu Ming -
Yaniv Kaul