Re: [Engine-devel] Stable PCI Addresses design wiki

On 12/04/2011 10:34 AM, Livnat Peer wrote: > On 12/04/2011 10:21 AM, Omer Frenkel wrote: >> >> ----- Original Message ----- >>> From: "Livnat Peer"<lpeer(a)redhat.com> >>> To: "Ayal Baron"<abaron(a)redhat.com> >>> Cc: engine-devel(a)ovirt.org >>> Sent: Sunday, December 4, 2011 10:04:30 AM >>> Subject: Re: [Engine-devel] Stable PCI Addresses design wiki >>> >>> On 12/04/2011 09:23 AM, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> >>>>> Send from my iPhone . >>>>> >>>>> >>>>> On 3 בדצמ 2011, at 20:38, Yaniv Kaul<ykaul(a)redhat.com> wrote: >>>>> >>>>>> On 12/03/2011 11:26 AM, Livnat Peer wrote: >>>>>>> On 12/01/2011 05:27 PM, Itamar Heim wrote: >>>>>>>> On 12/01/2011 04:09 PM, Miki Kenneth wrote: >>>>>>>>> I know that we are talking about only stable addresses, but I >>>>>>>>> would >>>>>>>>> like to broaden the scope a bit >>>>>>>>> (don't kick me guys)... >>>>>>>>> Shouldn't we keep a run-time configuration vs "saved/commit" >>>>>>>>> configuration. >>>>>>>>> By run time I mean: the current memory/cpu/disks/address per >>>>>>>>> VM >>>>>>>>> and by >>>>>>>>> "stable" I mean the "one in the DB". >>>>>>>>> That way, I'm going to be able to change properties in the >>>>>>>>> stable >>>>>>>>> config, which will not affect the running one >>>>>>>>> (and vice versa). >>>>>>>>> >>>>>>>>> Maybe this is totally different feature - but I decide to >>>>>>>>> throw >>>>>>>>> it on >>>>>>>>> the table. >>>>>>> It is a different feature ;) >>>>>>> >>>>>>>> shouldn't that be part of the snapshot improvements design? >>>>>>>> >>>>>>> What Miki is looking for, miki please correct me if i am wrong, >>>>>>> is >>>>>>> the >>>>>>> ability to change VM configuration while the VM is running and >>>>>>> expect >>>>>>> the changes to apply starting from the next VM run. >>>>>> In addition, turn a reboot of a VM into shutdown + run with the >>>>>> new >>>>>> parameters. >>>>>> That way an admin can tell a user 'I increased your VM's memory, >>>>>> reboot at your own preferred time and you'll have the extra >>>>>> memory'. >>>>>> (of course, hot-plugging memory is cooler). >>>>>> Y. >>>>> Agreed. >>>>>>> For the above feature to be 'complete' Miki wants to be able to >>>>>>> view >>>>>>> what is the VM current configuration (the one used when the VM >>>>>>> started) >>>>>>> and what is the configuration for the next run. >>>>>>> >>>>>>> After the VM is stopped you have only one configuration (the one >>>>>>> for the >>>>>>> next run). >>>>>>> >>>>>>> I guess i can see why you associated it with snapshots, as we >>>>>>> can >>>>>>> look >>>>>>> at it as a temporary VM configuration snapshot, but i think it >>>>>>> is >>>>>>> another functionality (especially in UI/client perspective). >>>>> I don't mind on what feature you implement this ... I think when >>>>> you >>>>> design a change in functionality in existing flow, you need to >>>>> look >>>>> at the broader scope, at that is why I mentioned. >>>> So let's broaden the scope just a little more. As a user, I would >>>> like to be able to revert my configuration changes to "last known >>>> good" (and no, I'm not talking about live snapshots, only config >>>> changes, because I don't want to revert my data changes on disk). >>>> I would store multiple versions of the config (20?) and let the >>>> user go back (without the need to remember what the config was. >>>> >>> A nice addition. >>> To summarize what was suggested so far: >>> >>> 1. changing configuration while VM is running (apply on next-run) >>> 2. reflecting to the user current configuration vs. 'next-run' >>> configuration >>> 3. switch to the new configuration on restart >>> 4. keeping vm configuration 'history' (either explicitly or >>> implicitly) >>> and enabling roll-back to a specific configuration. >> the last one sounds like snapshot without disks? >> > I agree. maybe an addition is to take it implicitly if the feature is > turned on, like local history in eclipse. > > Livnat You will be saving the HW config per snapshot regardless, right?

Y. > >>> Anything else? >>> >>> Livnat >>> >>> >>>>> Btw, Livnat, let's start with having it on the engine, ui can >>>>> follow >>>>> later on... >>>>> >>>>>>> Livnat >>>>>>> >>>>>>> >>>>>>>>> Miki >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Eli Mesika"<emesika(a)redhat.com> >>>>>>>>>> To: engine-devel(a)ovirt.org >>>>>>>>>> Sent: Wednesday, November 30, 2011 5:17:42 PM >>>>>>>>>> Subject: Re: [Engine-devel] Stable PCI Addresses design wiki >>>>>>>>>> >>>>>>>>>> Hi again >>>>>>>>>> The following is a design draft for a new feature of >>>>>>>>>> oVirt-engine >>>>>>>>>> planned for 3.1 >>>>>>>>>> >>>>>>>>>> The feature allow devices in guest virtual machines to retain >>>>>>>>>> the >>>>>>>>>> same PCI address allocations as other devices are added or >>>>>>>>>> removed >>>>>>>>>> from the guest configuration. This is particularly important >>>>>>>>>> for >>>>>>>>>> Windows guests in order to prevent warnings or reactivation >>>>>>>>>> when >>>>>>>>>> device addresses change. >>>>>>>>>> >>>>>>>>>> This feature is supported by libvirt and should be >>>>>>>>>> implemented >>>>>>>>>> by >>>>>>>>>> RHEVM and VDSM. >>>>>>>>>> >>>>>>>>>> When creating a VM, QEMU allocates PCI addresses to the guest >>>>>>>>>> devices, these addresses are being reported by libvirt to >>>>>>>>>> VDSM >>>>>>>>>> and >>>>>>>>>> VDSM should report it back to RHEVM. RHEVM should persist the >>>>>>>>>> PCI >>>>>>>>>> addresses and report it as part of the VM configuration on >>>>>>>>>> the >>>>>>>>>> next >>>>>>>>>> run. If a change to the VM devices occurred RHEVM should >>>>>>>>>> detect >>>>>>>>>> the >>>>>>>>>> change and persist the new PCI addresses. >>>>>>>>>> >>>>>>>>>> Please review. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Eli Mesika >>>>>>>>>> Redhat ISRAEL >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Eli Mesika"<emesika(a)redhat.com> >>>>>>>>>>> To: engine-devel(a)ovirt.org >>>>>>>>>>> Sent: Wednesday, November 30, 2011 5:06:37 PM >>>>>>>>>>> Subject: [Engine-devel] Stable PCI Addresses design wiki >>>>>>>>>>> >>>>>>>>>>> http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 >>> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel