[Engine-devel] Stable PCI Addresses design wiki

Sun Dec 4 08:21:43 UTC 2011

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: engine-devel at 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 at 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?

> 
> 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 at redhat.com>
> >>>>>>> To: engine-devel at 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 at redhat.com>
> >>>>>>>> To: engine-devel at 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 at ovirt.org
> >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> Engine-devel mailing list
> >>>>>> Engine-devel at ovirt.org
> >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 