[Engine-devel] Stable PCI Addresses design wiki

Sun Dec 4 08:34:25 UTC 2011

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

I agree. maybe an addition is to take it implicitly if the feature is
turned on, like local history in eclipse.

Livnat

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