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

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.

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