Re: [Engine-devel] [vdsm] reserve virtio-balloon device created by libvirt
On 04/29/2012 04:19 PM, Dan Kenigsberg wrote:
On Sun, Apr 29, 2012 at 07:24:52AM -0400, Andrew Cathrow wrote:
----- Original Message -----
From: "Dan Kenigsberg"<danken@redhat.com> To: "Gal Hammer"<ghammer@redhat.com> Cc: vdsm-devel@lists.fedorahosted.org Sent: Sunday, April 29, 2012 7:19:10 AM Subject: Re: [vdsm] reserve virtio-balloon device created by libvirt
On Mon, Apr 23, 2012 at 04:00:55PM +0300, Gal Hammer wrote:
On 23/04/2012 12:26, Mark Wu wrote:
Hi guys,
I saw that an option to create balloon device was added by Gal in http://gerrit.ovirt.org/1573 I have a question about it. Why don we preserve the old default behaviour? I know it's not supported by ovirt-engine now, but I can't figure out what will break if it's not disabled explicitly. So do you think we can just make use of the balloon device added by libvirt?
We didn't change the old behavior.
Libvirt creates by default a memory-balloon device, so vdsm defaults was to disable it by adding a "none"-type device. This was done because vdsm didn't include an option to add such device.
My patch added an option to create a memory-balloon through vdsm. If the user didn't request to add the device, the behavior is same as before, disabling the memory-balloon.
I feel that it would be best not to flip Vdsm's default at the moment, even though it is the opposite of libvirt's. I would consider to flip them only after your (Mark's) patches are in, tested, and proven worthwhile for the common case.
Currently, without any management for the balloon, reserving a guest PCI device was deemed wasteful.
On the other side of the fence - We know that we do need to do ballooning - In the (next?) release we'll end up adding this support - There's no harm (see next point) in adding the device now in fact it saves a config change on upgrade.
Well, there is a surprise factor, for someone running a guest generated in a previous version. Suddenly, after Vdsm upgrade, it would see an additional device. At the least, I would like Vdsm to have a configurable option to keep the old behavior.
please take into consideration engine has an algorithm testing max number of devices and it should be aware of newly introduced devices by vdsm or it will overflow.
- While it takes up a PCI slot it's going to be very, very rare deployments that will ever see the limit, libvirt/virtmanager/virt-install has done this forever without seeing push back.
_______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On 04/30/2012 07:30 PM, Itamar Heim wrote:
On 04/29/2012 04:19 PM, Dan Kenigsberg wrote:
On Sun, Apr 29, 2012 at 07:24:52AM -0400, Andrew Cathrow wrote:
----- Original Message -----
From: "Dan Kenigsberg"<danken@redhat.com> To: "Gal Hammer"<ghammer@redhat.com> Cc: vdsm-devel@lists.fedorahosted.org Sent: Sunday, April 29, 2012 7:19:10 AM Subject: Re: [vdsm] reserve virtio-balloon device created by libvirt
On Mon, Apr 23, 2012 at 04:00:55PM +0300, Gal Hammer wrote:
On 23/04/2012 12:26, Mark Wu wrote:
Hi guys,
I saw that an option to create balloon device was added by Gal in http://gerrit.ovirt.org/1573 I have a question about it. Why don we preserve the old default behaviour? I know it's not supported by ovirt-engine now, but I can't figure out what will break if it's not disabled explicitly. So do you think we can just make use of the balloon device added by libvirt?
We didn't change the old behavior.
Libvirt creates by default a memory-balloon device, so vdsm defaults was to disable it by adding a "none"-type device. This was done because vdsm didn't include an option to add such device.
My patch added an option to create a memory-balloon through vdsm. If the user didn't request to add the device, the behavior is same as before, disabling the memory-balloon.
I feel that it would be best not to flip Vdsm's default at the moment, even though it is the opposite of libvirt's. I would consider to flip them only after your (Mark's) patches are in, tested, and proven worthwhile for the common case.
Currently, without any management for the balloon, reserving a guest PCI device was deemed wasteful.
On the other side of the fence - We know that we do need to do ballooning - In the (next?) release we'll end up adding this support - There's no harm (see next point) in adding the device now in fact it saves a config change on upgrade.
Well, there is a surprise factor, for someone running a guest generated
surprise == another minor reason for windows guest to re-activate.
in a previous version. Suddenly, after Vdsm upgrade, it would see an additional device. At the least, I would like Vdsm to have a configurable option to keep the old behavior.
In qemu we have a compatibility level controlled by -M flag. VDSM should have a similar compatibility level and defaults shouldn't normally change in minor releases.
please take into consideration engine has an algorithm testing max number of devices and it should be aware of newly introduced devices by vdsm or it will overflow.
It is good timing to change the algorithm too. IIRC the algorithm has some hard coded assumptions about qemu. Instead, it would be better to consult w/ qemu in run time and get the free pci slots number and any other limits. Soon qemu will support pci bridges and this will increase the number of pci devices and virtio-scsi will insert some other calculation factor.
- While it takes up a PCI slot it's going to be very, very rare deployments that will ever see the limit, libvirt/virtmanager/virt-install has done this forever without seeing push back.
_______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/05/12 01:28, Dor Laor wrote:
On 04/30/2012 07:30 PM, Itamar Heim wrote:
On 04/29/2012 04:19 PM, Dan Kenigsberg wrote:
On Sun, Apr 29, 2012 at 07:24:52AM -0400, Andrew Cathrow wrote:
----- Original Message -----
From: "Dan Kenigsberg"<danken@redhat.com> To: "Gal Hammer"<ghammer@redhat.com> Cc: vdsm-devel@lists.fedorahosted.org Sent: Sunday, April 29, 2012 7:19:10 AM Subject: Re: [vdsm] reserve virtio-balloon device created by libvirt
On Mon, Apr 23, 2012 at 04:00:55PM +0300, Gal Hammer wrote:
On 23/04/2012 12:26, Mark Wu wrote: > Hi guys, > > I saw that an option to create balloon device was added by Gal in > http://gerrit.ovirt.org/1573 > I have a question about it. Why don we preserve the old default > behaviour? I know it's not supported by ovirt-engine now, but I > can't > figure out what will break if it's not disabled explicitly. So do > you > think we can just make use of the balloon device added by libvirt?
We didn't change the old behavior.
Libvirt creates by default a memory-balloon device, so vdsm defaults was to disable it by adding a "none"-type device. This was done because vdsm didn't include an option to add such device.
My patch added an option to create a memory-balloon through vdsm. If the user didn't request to add the device, the behavior is same as before, disabling the memory-balloon.
I feel that it would be best not to flip Vdsm's default at the moment, even though it is the opposite of libvirt's. I would consider to flip them only after your (Mark's) patches are in, tested, and proven worthwhile for the common case.
Currently, without any management for the balloon, reserving a guest PCI device was deemed wasteful.
On the other side of the fence - We know that we do need to do ballooning - In the (next?) release we'll end up adding this support - There's no harm (see next point) in adding the device now in fact it saves a config change on upgrade.
Well, there is a surprise factor, for someone running a guest generated
surprise == another minor reason for windows guest to re-activate.
in a previous version. Suddenly, after Vdsm upgrade, it would see an additional device. At the least, I would like Vdsm to have a configurable option to keep the old behavior.
In qemu we have a compatibility level controlled by -M flag. VDSM should have a similar compatibility level and defaults shouldn't normally change in minor releases.
please take into consideration engine has an algorithm testing max number of devices and it should be aware of newly introduced devices by vdsm or it will overflow.
It is good timing to change the algorithm too. IIRC the algorithm has some hard coded assumptions about qemu. Instead, it would be better to consult w/ qemu in run time and get the free pci slots number and any other limits.
The engine uses the hard coded limitation for example when adding a disk (using a pci slot) to a VM when the VM is down (no qemu to consult with).
Soon qemu will support pci bridges and this will increase the number of pci devices and virtio-scsi will insert some other calculation factor.
The engine will have to adjust to that.
- While it takes up a PCI slot it's going to be very, very rare deployments that will ever see the limit, libvirt/virtmanager/virt-install has done this forever without seeing push back.
_______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (3)
-
Dor Laor -
Itamar Heim -
Livnat Peer