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

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.

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