[Engine-devel] Stable PCI Addresses design wiki

Sun Dec 4 11:16:30 UTC 2011

On 12/04/2011 11:00 AM, Yaniv Kaul wrote:
> 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?
>>>
>> 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?

yes

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