9:17 a.m.
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(a)redhat.com>
To: engine-devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:54 a.m.
On Wed, Nov 30, 2011 at 10:06:37AM -0500, Eli Mesika wrote:
My primary comment on this is that you likely don't want to restrict
yourself to PCI addresses.
If RHEVM intends to use virtio-serial controllers you want to maintain
stable virtio serial addresses
If RHEVM intends to use CCID smartcard controllers you want to maintain
stable CCID device addresses
If RHEVM intends to use SCSI controllers you will want to maintain
SCSI drive addresses
If RHEVM intends to use USB controllers you will want to maintain
USB device addresses
I think you get the idea :-) In general you can say that every single
device listed in the XML will ultimately have an address associated
with it. The type address will vary depending on what type of controller
the device is attached to.
In addition, when you start dealing with these other non-PCI address
types, you will also need to start dealing with controller devices.
eg, if you add a SCSI disk to the XML
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/test/disk0.raw'/>
<target dev='sda' bus='scsi'/>
</disk>
First of all libvirt will want to assign an address to this drive
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/test/disk0.raw'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0'
unit='0'/>
</disk>
Then, if the corresponding controller does not exist already, libvirt
will auto-add a controller device, which itself has an address you will
need to track:
<controller type='scsi' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05' function='0x0'/>
</controller>
In addition, when QEMU gains support for PCI bridges, or multiple PCI
root complexes, there will also be the possibility of dealing with
multiple PCI controllers in the XML too.
So even if you only implement PCI address support in the first iteration,
I'd really encourage you to at least consider how you will cope with the
other address types sooner, rather than later.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
10 a.m.
New subject: [Engine-devel] Quota design page
Hi everyone,
Following the introduction of Quota feature description,
The following link is the design of Quota feature:
http://www.ovirt.org/wiki/Features/Design/Quota
Please feel free, to share your comments.
Thank you,
Maor
4:22 a.m.
On 11/30/2011 05:54 PM, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 10:06:37AM -0500, Eli Mesika wrote:
> http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses
My primary comment on this is that you likely don't want to restrict
yourself to PCI addresses.
If RHEVM intends to use virtio-serial controllers you want to maintain
stable virtio serial addresses
If RHEVM intends to use CCID smartcard controllers you want to maintain
stable CCID device addresses
If RHEVM intends to use SCSI controllers you will want to maintain
SCSI drive addresses
If RHEVM intends to use USB controllers you will want to maintain
USB device addresses
I think you get the idea :-) In general you can say that every single
device listed in the XML will ultimately have an address associated
with it. The type address will vary depending on what type of controller
the device is attached to.
In addition, when you start dealing with these other non-PCI address
types, you will also need to start dealing with controller devices.
eg, if you add a SCSI disk to the XML
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/test/disk0.raw'/>
<target dev='sda' bus='scsi'/>
</disk>
First of all libvirt will want to assign an address to this drive
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/test/disk0.raw'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0'
unit='0'/>
</disk>
Then, if the corresponding controller does not exist already, libvirt
will auto-add a controller device, which itself has an address you will
need to track:
<controller type='scsi' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05' function='0x0'/>
</controller>
In addition, when QEMU gains support for PCI bridges, or multiple PCI
root complexes, there will also be the possibility of dealing with
multiple PCI controllers in the XML too.
So even if you only implement PCI address support in the first iteration,
I'd really encourage you to at least consider how you will cope with the
other address types sooner, rather than later.
Regards,
Daniel
Hi Eli,
- I suggest changing the feature name from stable PCI addresses to
stable device addresses, then document which devices are supported. I
think the first version includes PCI, VirtIO Serial, SCSI, IDE, CCID,
actually anything libvirt supports - right?
- I am missing in the documentation the format of the device addresses
as interchanged between RHEVM and VDSM, specifically i am interested why
use XML and not JSON format for that data.
Thanks, Livnat
4:56 a.m.
my notes:
why adding new parameter to create verb and not using the createInfo? (or this is the
intention?)
if we expect xml to be large, perhaps it would be better to get it from db only before
sending it to vdsm,
to keep the vm object from getting too big, meaning never get it as part of vm dynamic.
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: engine-devel(a)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(a)redhat.com>
> To: engine-devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:09 a.m.
----- Original Message -----
From: "Omer Frenkel" <ofrenkel(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, December 1, 2011 12:56:45 PM
Subject: Re: [Engine-devel] Stable PCI Addresses design wiki
my notes:
why adding new parameter to create verb and not using the createInfo?
(or this is the intention?)
Yes, we will use the createInfo to pass that
if we expect xml to be large, perhaps it would be better to get it
from db only before sending it to vdsm,
to keep the vm object from getting too big, meaning never get it as
part of vm dynamic.
Sure , I have considered that (see Logic Design) in original document:
b. Get the domxml from DAL for each VM we are running (creating)
This will insure that our VM entities are not keeping the domxml inside them,
rather, they will got it on demand
----- Original Message -----
> From: "Eli Mesika" <emesika(a)redhat.com>
> To: engine-devel(a)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(a)redhat.com>
> > To: engine-devel(a)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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
5:21 a.m.
----- Original Message -----
From: "Daniel P. Berrange" <berrange(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Wednesday, November 30, 2011 5:54:34 PM
Subject: Re: [Engine-devel] Stable PCI Addresses design wiki
On Wed, Nov 30, 2011 at 10:06:37AM -0500, Eli Mesika wrote:
> http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses
My primary comment on this is that you likely don't want to restrict
yourself to PCI addresses.
Sure, this is a bad name, have changed that to "Stable Device Addresses"
In the term Device we include PCI, VirtIO Serial, SCSI, IDE, CCID and actually anything
libvirt supports.
Page was changed to :
http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
Thanks
If RHEVM intends to use virtio-serial controllers you want to
maintain
stable virtio serial addresses
If RHEVM intends to use CCID smartcard controllers you want to
maintain
stable CCID device addresses
If RHEVM intends to use SCSI controllers you will want to maintain
SCSI drive addresses
If RHEVM intends to use USB controllers you will want to maintain
USB device addresses
I think you get the idea :-) In general you can say that every single
device listed in the XML will ultimately have an address associated
with it. The type address will vary depending on what type of
controller
the device is attached to.
In addition, when you start dealing with these other non-PCI address
types, you will also need to start dealing with controller devices.
eg, if you add a SCSI disk to the XML
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/test/disk0.raw'/>
<target dev='sda' bus='scsi'/>
</disk>
First of all libvirt will want to assign an address to this drive
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/test/disk0.raw'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0'
unit='0'/>
</disk>
Then, if the corresponding controller does not exist already, libvirt
will auto-add a controller device, which itself has an address you
will
need to track:
<controller type='scsi' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05'
function='0x0'/>
</controller>
In addition, when QEMU gains support for PCI bridges, or multiple PCI
root complexes, there will also be the possibility of dealing with
multiple PCI controllers in the XML too.
So even if you only implement PCI address support in the first
iteration,
I'd really encourage you to at least consider how you will cope with
the
other address types sooner, rather than later.
Regards,
Daniel
--
|: http://berrange.com -o-
| http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o-
| http://virt-manager.org :|
|: http://autobuild.org -o-
| http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o-
| http://live.gnome.org/gtk-vnc :|
8:09 a.m.
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.
Miki
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: engine-devel(a)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(a)redhat.com>
> To: engine-devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:27 a.m.
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.
shouldn't that be part of the snapshot improvements design?
Miki
----- Original Message -----
> From: "Eli Mesika"<emesika(a)redhat.com>
> To: engine-devel(a)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(a)redhat.com>
>> To: engine-devel(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:26 a.m.
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.
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).
Livnat
>
> Miki
>
> ----- Original Message -----
>> From: "Eli Mesika"<emesika(a)redhat.com>
>> To: engine-devel(a)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(a)redhat.com>
>>> To: engine-devel(a)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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:38 p.m.
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.
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).
Livnat
>> Miki
>>
>> ----- Original Message -----
>>> From: "Eli Mesika"<emesika(a)redhat.com>
>>> To: engine-devel(a)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(a)redhat.com>
>>>> To: engine-devel(a)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(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:02 p.m.
Send from my iPhone .
On 3 בדצמ 2011, at 20:38, Yaniv Kaul <ykaul(a)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.
Btw, Livnat, let's start with having it on the engine, ui can follow later on...
>
> Livnat
>
>
>>> Miki
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika"<emesika(a)redhat.com>
>>>> To: engine-devel(a)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(a)redhat.com>
>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:23 a.m.
----- Original Message -----
Send from my iPhone .
On 3 בדצמ 2011, at 20:38, Yaniv Kaul <ykaul(a)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(a)redhat.com>
>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:04 a.m.
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(a)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(a)redhat.com>
>>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:21 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Ayal Baron" <abaron(a)redhat.com>
Cc: engine-devel(a)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(a)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?
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(a)redhat.com>
>>>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:34 a.m.
On 12/04/2011 10:21 AM, Omer Frenkel wrote:
----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "Ayal Baron" <abaron(a)redhat.com>
> Cc: engine-devel(a)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(a)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(a)redhat.com>
>>>>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
3 a.m.
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(a)redhat.com>
>> To: "Ayal Baron"<abaron(a)redhat.com>
>> Cc: engine-devel(a)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(a)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(a)redhat.com>
>>>>>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4 a.m.
----- Original Message -----
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(a)redhat.com>
>>> To: "Ayal Baron"<abaron(a)redhat.com>
>>> Cc: engine-devel(a)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(a)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?
Implementation wise - yes. IMO feature wise it is not which is why I specifically made
the differentiation. Under the hood you can run a "live snapshot without disks"
but when I expose this to the user, it is not as a diskless live snapshot. I want to
implicitly save configurations and let user start-up the vm with old configs.
>>
> 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(a)redhat.com>
>>>>>>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:16 a.m.
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(a)redhat.com>
>>> To: "Ayal Baron"<abaron(a)redhat.com>
>>> Cc: engine-devel(a)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(a)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(a)redhat.com>
>>>>>>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
4524
days inactive
4528
days old
19 comments
9 participants
participants (9)
-
Ayal Baron -
Daniel P. Berrange -
Eli Mesika -
Itamar Heim -
Livnat Peer -
Maor -
Miki Kenneth -
Omer Frenkel -
Yaniv Kaul