[Engine-devel] Stable PCI Addresses design wiki

Sun Dec 4 08:04:30 UTC 2011

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.

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