On Fri, Nov 24, 2017 at 5:50 PM, FERNANDO FREDIANI <fernando.frediani(a)upx.com>= ; wrote:

I have made a Export of the same VM created in oVirt to a server running pure qemu/KVM and which creates new VMs profiles with vram 65536 and it turned on the Windows 10 which run perfectly with that configuration.

Was reading some documentation that it may be possible to change the file /usr/share/ovirt-engine/conf/osinfo-defaults.propert= ies in order to change it for the profile you want but I am not sure how these changed should be made if directly in that file, on another one just with custom configs and also how to apply them immediatelly to any new or existing VM ? I am pretty confident once vram is increased that should resolve the issue with not only Windows 10 VMs, but other as well.

Anyone can give a hint about the correct procedure to apply this change ?

Thanks in advance.
Fernando

Hi Fernando,

based on this:

https://www.ovir= t.org/develop/release-management/features/virt/os-info/

you should create a file of kind

/etc/ovirt-engine/osinfo.conf.d/20-overload.propertie= s

but I think you can only overwrite the multiplier and not directly the vgamem (or vgamem_mb in rhel 7) values

so that you could put something like this inside it:

os.windows_10.devices.display.vramMultiplier.value =3D 2 os.windows_10x64.devices.display.vramMultiplier.value =3D 2

I think there are no values for vgamem_mb

I found these two threads in 2016

http://lists.ovirt.org/pipermail/u= sers/2016-June/073692.html

that confirms you cannot set vgamem

and

http://lists.ovirt.org/pipermail/u= sers/2016-June/073786.html

that suggests to create a hook

Just a hack that came into mind:

in a CentOS vm of mine in a 4.1.5 environment I see that by default I get this qemu command line

-device qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_= size=3D33554432,vram64_size_mb=3D0,vgamem_mb=3D16,bus=3Dpci.0,add= r=3D0x2

Based on this:

https://www.ovirt.or= g/documentation/draft/video-ram/

you have

vgamem =3D 16 MB * number_of_heads

I verified that if I edit the vm in the gui and set Monitors=3D4 in console section (but with the aim of using only the first head) and then I power off and power on the VM, I get now

-device qxl-vga,id=3Dvideo0,ram_size=3D<= wbr>268435456,vram_size=3D134217728,vram64_size_mb=3D0,vgamem_mb=3D64,= bus=3Dpci.0,addr=3D0x2

I have not a client to connect and verify any improvement: I don't know if you will be able to use all the new ram in the only first head with a better experience or if it is partitioned in some way...

Could you try eventually?

Gianluca

On 7 Mar 2= 018, at 14:03, FERNANDO FREDIANI <fernando.frediani(a)upx.com> wrote:

= =
Hello = Gianluca
Resurrecting this topic. I made the changes as pe= r your instructions below on the Engine configuration but it had no effect on the VM graphics memory. Is it necessary to restart the Engine after adding the 20-overload.properties file ? Also I don't think is necessary to do any changes on the hosts right ?

correct on both

On the recent updates has anything changed in the terms on= how to change the video memory assigned to any given VM. I guess it is something that has been forgotten overtime, specially if you are running a VDI-like environment whcih depends very much on the video memory.

there were no changes recen= tly, these are the most recent guidelines we got from SPICE people. They mi= ght be out of date. Would be good to raise that specifically (the performan= ce difference for default sizes) to them, can you narrow it down and post t= o sp= ice-devel(a)lists.freedesktop.org?

michal

Let me know.
Thanks
Fernando Frediani

On 24/11/2017 20:45, Gianluca Cecchi wrote:

On Fri, Nov 24, 2017 at 5:50 PM, FERNANDO FREDIANI <fernando.frediani(a)upx.com> wrote:

I have made= a Export of the same VM created in oVirt to a server running pure qemu/KVM and which creates new VMs profiles with vram 65536 and it turned on the Windows 10 which run perfectly with that configuration.
Was reading some document= ation that it may be possible to change the file /usr/share/ovirt-engine/conf/osinfo-defau= lts.properties in order to change it for the profile you want but I am not sure how these changed should be made if directly in that file, on another one just with custom configs and also how to apply them immediatelly to any new or existing VM ? I am pretty confident once vram is increased that should resolve the issue with not only Windows 10 VMs, but other as well.
= Anyone can give a hint about the correct procedure to apply this change ?
Thanks in advance.
Fernando

Hi Fernando,

based on this:

https://www.ovirt.org/develop/release-mana= gement/features/virt/os-info/

you should create a file of kind

/etc/ovirt-engine/osinfo.conf.d= /20-overload.properties

but I think you can only overwrite the multipli= er and not directly the vgamem (or vgamem_mb in rhel 7) values

so that you could put something like this insid= e it:

os.windows_10.devices.display.vramMultiplier.va= lue =3D 2
os.windows_10x64.devices.display.vramMultiplier.value =3D 2

I think there are no values for vgamem_mb

I found these two threads in 2016

http://lists.= ovirt.org/pipermail/users/2016-June/073692.html

that confirms you cannot set vgamem

and

http://lists.= ovirt.org/pipermail/users/2016-June/073786.html

that suggests to create a hook

Just a hack that came into mind:

in a CentOS vm of mine in a 4.1.5 environment I= see that by default I get this qemu command line

-device qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,vram64_size_mb=3D0,vg= amem_mb=3D16,bus=3Dpci.0,addr=3D0x2

Based on this:

https://www.ovirt.org/documentation/draft/video-ram/<= /a>

you have

vgamem =3D 16 MB * number_of_heads

I verified that if I edit the vm in the gui and set Monitors=3D4 in console section (but with the aim of using only the first head) and then I power off and power on the VM, I get now

-device qxl-vga,id=3Dvideo0,ram_size=3D<= wbr class=3D"">268435456,vram_size=3D134217728,vram64_size_= mb=3D0,vgamem_mb=3D64,bus=3Dpci.0,addr=3D0x2

I have not a client to connect and verify any improvement: I don't know if you will be able to use all the new ram in the only first head with a better experience or if it is partitioned in some way...

Could you try eventually?

Gianluca

_______________________________________________
Users mailing= list
Users(a= )ovirt.org
http://lists.ovirt.org/mailman/listinfo/users<= br class=3D"">

On 7 Mar 2018, at 14:03, FERNANDO FREDIANI <fernando.frediani(a)upx.com> wrote:

Hello Gianluca

Resurrecting this topic. I made the changes as per your instructions below on the Engine configuration but it had no effect on the VM graphics memory. Is it necessary to restart the Engine after adding the 20-overload.properties file ? Also I don't think is necessary to do any changes on the hosts right ?

correct on both

On the recent updates has anything changed in the terms on how to change the video memory assigned to any given VM. I guess it is something that has been forgotten overtime, specially if you are running a VDI-like environment whcih depends very much on the video memory.

there were no changes recently, these are the most recent guidelines we got from SPICE people. They might be out of date. Would be good to raise that specifically (the performance difference for default sizes) to them, can you narrow it down and post to=C2=A0spice-devel(a)lists.freedeskt= op.org?

michal

Let me know.
Thanks

Fernando Frediani

On 24/11/2017 20:45, Gianluca Cecchi wrote:

On Fri, Nov 24, 2017 at 5:50 PM, FERNANDO FREDIANI <fernando.frediani(a)upx.com> wrote:

I have made a Export of the same VM created in oVirt to a server running pure qemu/KVM and which creates new VMs profiles with vram 65536 and it turned on the Windows 10 which run perfectly with that configuration.

Was reading some documentation that it may be possible to change the file /usr/share/ovirt-engine/conf/os= info-defaults.properties in order to change it for the profile you want but I am not sure how these changed should be made if directly in that file, on another one just with custom configs and also how to apply them immediatelly to any new or existing VM ? I am pretty confident once vram is increased that should resolve the issue with not only Windows 10 VMs, but other as well.

Anyone can give a hint about the correct procedure to apply this change ?

Thanks in advance.
Fernando

Hi Fernando,

based on this:

https://www.ovirt.org/develop/release-management/features/virt/os-info/

you should create a file of kind

/etc/ovirt-engine/osinfo.conf.d/20-overload.properties

but I think you can only overwrite the multiplier and not directly the vgamem (or vgamem_mb in rhel 7) values

so that you could put something like this inside it:

os.windows_10.devices.display.vramMul= tiplier.value =3D 2
os.windows_10x64.devices.display.vramMultiplier.value =3D 2

I think there are no values for vgamem_mb

I found these two threads in 2016
http://lists.= ovirt.org/pipermail/users/2016-June/073692.html

that confirms you cannot set vgamem

and

http://lists.= ovirt.org/pipermail/users/2016-June/073786.html

that suggests to create a hook

Just a hack that came into mind:

in a CentOS vm of mine in a 4.1.5 environment I see that by default I get this qemu command line

-device qxl-vga,id=3Dvideo0,ram_size= =3D67108864,vram_size=3D33554432,vram64_size_mb=3D0,vgamem_mb=3D16,bus=3Dpci.0,addr=3D0x2

Based on this:

https://www.ovirt.org/documentation/draft/video-ram/

you have

vgamem =3D 16 MB * number_of_heads

I verified that if I edit the vm in the gui and set Monitors=3D4 in console section (but with the aim of using only the first head) and then I power off and power on the VM, I get now

-device qxl-vga,id=3Dvideo0,ram_size=3D26843545= 6,vram_size=3D134217728,vram64_size_mb=3D0,vgamem_mb=3D64,bus=3Dpci.0,addr=3D0x2

I have not a client to connect and verify any improvement: I don't know if you will be able to use all the new ram in the only first head with a better experience or if it is partitioned in some way...

Could you try eventually?

Gianluca

_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

On Wed, Mar 7, 2018 at 7:43 PM, Michal Skrivanek <michal.skrivanek= (a)redhat.com> wrote:

On 7 Mar 2018, at 14:03, FERNANDO FREDIANI <fernan= do.frediani(a)upx.com> wrote:

Hello Gianluca

Resurrecting this topic. I made the changes as per your instructions below on the Engine configuration but it had no effect on the VM graphics memory. Is it necessary to restart the Engine after adding the 20-overload.properties file ? Also I don't think is necessary to do any changes on the hosts right ?

correct on both

Hello Fernando and Michal,

at that time I was doing some tests both with plain virt-manager and oVirt for some Windows 10 VMs.

More recently I haven't done anything in that regard again, unfortunately.

After you have done what you did suggest yourself and Michal confirmed, then you can test powering off and then on again the VM (so that the new qemu-kvm process starts with the new parameters) and let us know if you enjoy better experience, so that we can ask for adoption as a default (eg for VMs configured as desktops) or as a custom property to give

=C2=A0

On the recent updates has anything changed in the terms on how to change the video memory assigned to any given VM. I guess it is something that has been forgotten overtime, specially if you are running a VDI-like environment whcih depends very much on the video memory.

there were no changes recently, these are the most recent guidelines we got from SPICE people. They might be out of date. Would be good to raise that specifically (the performance difference for default sizes) to them, can you narrow it down and post to=C2=A0spice-devel(= a)lists.freedesktop.org?

This could be very useful too

Cheers,

Gianluca

On 8 Mar 2= 018, at 14:51, FERNANDO FREDIANI <fernando.frediani(a)upx.com> wrote:

= =
Hello = Gianluca.
As I mentioned previously I am not sure it has a= nything to do with SPICE at all, but with the amount of memory the VM has assigned to it. Proff of it is that when you access with via any Remote Desktop protocol it remains slow as if the amount of video memory wasnt being enough and have seen it crashing several times as well.

It does, because we just follow their recomm= endations:)

<= div class=3D"">
Fernando

On 07/03/2018 16:59, Gianluca Cecchi wrote:

On Wed, Mar 7, 2018 at 7:43 PM, Michal Skrivanek <michal.skrivanek(a)redhat.com> wrote:

On 7 Mar 2018, at 14:03, FERNANDO FRE= DIANI <fernando.frediani(a)u= px.com> wrote:

Hello Gianluca
Resurrecting this topic. I = made the changes as per your instructions below on the Engine configuration but it had no effect on the VM graphics memory. Is it necessary to restart the Engine after adding the 20-overload.properties file ? Also I don't think is necessary to do any changes on the hosts right ?

correct on both

Hello Fernando and Michal,

at that time I was doing some tests both with p= lain virt-manager and oVirt for some Windows 10 VMs.

More recently I haven't done anything in that r= egard again, unfortunately.

After you have done what you did suggest yourse= lf and Michal confirmed, then you can test powering off and then on again the VM (so that the new qemu-kvm process starts with the new parameters) and let us know if you enjoy better experience, so that we can ask for adoption as a default (eg for VMs configured as desktops) or as a custom property to give

On the recent updates has anything changed in the terms on how to change the video memory assigned to any given VM. I guess it is something that has been forgotten overtime, specially if you are running a VDI-like environment whcih depends very much on the video memory.

there were no changes recently, these are the most recent guidelines we got from SPICE people. They might be out of date. Would be good to raise that specifically (the performance difference for default sizes) to them, can you narrow it down and post to <= a href=3D"mailto:spice-devel(a)lists.freedesktop.org" target=3D"_blank" moz= -do-not-send=3D"true" class=3D"">spice-devel(a)lists.freede= sktop.org?

This could be very useful too

Cheers,

Gianluca