[Engine-devel] Stable PCI Addresses design wiki
Ayal Baron
abaron at redhat.com
Sun Dec 4 07:23:06 UTC 2011
----- 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.
>
> 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
>
More information about the Engine-devel
mailing list