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

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

>> 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