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

----- Original Message ----- > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > To: "Ayal Baron" <abaron(a)redhat.com&gt; > 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&gt; 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?

> > 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&quot;&lt;emesika(a)redhat.com&gt; >>>>>>>> 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&quot;&lt;emesika(a)redhat.com&gt; >>>>>>>>> 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 >