On 12/04/2011 11:00 AM, Yaniv Kaul wrote:
On 12/04/2011 10:34 AM, Livnat Peer wrote:
On 12/04/2011 10:21 AM, Omer Frenkel wrote:
From: "Livnat Peer"<lpeer@redhat.com> To: "Ayal Baron"<abaron@redhat.com> Cc: engine-devel@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@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.
----- Original Message ----- 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?
yes
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@redhat.com> >>>>> To: engine-devel@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@redhat.com> >>>>>> To: engine-devel@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@ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel