[Engine-devel] Stable PCI Addresses design wiki

Ayal Baron abaron at redhat.com
Sun Dec 4 10:00:14 UTC 2011 


----- Original Message -----
> On 12/04/2011 10:34 AM, Livnat Peer wrote:
> > On 12/04/2011 10:21 AM, Omer Frenkel wrote:
> >>
> >> ----- 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?

Implementation wise - yes.  IMO feature wise it is not which is why I specifically made the differentiation.  Under the hood you can run a "live snapshot without disks" but when I expose this to the user, it is not as a diskless live snapshot.  I want to implicitly save configurations and let user start-up the vm with old configs.

> >>
> > 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?
> 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 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
> >>>
> > _______________________________________________
> > 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
>

More information about the Devel mailing list