[Engine-devel] Stable PCI Addresses design wiki

Sun Dec 4 09:00:45 UTC 2011

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