(UPDATED) Workstation and VMPlayer 12.1.0 build-3272444 extended vesa configuration DEPRECATED behaviour at boot time (hardware 12 related?)

[piggyz]

This was a BIG PROBLEM for me for few hours, so it could be for others. This post maybe will eventually try to help other users with the same problem and to advise developers to change this - in my opinion - absolutely deprecable behaviour.

As in the subject, the problem is exactly that,

Advanced considerations.

I like to use extended vesa resolutions with all my guests to properly and quickly configure my guest machines screen resolution at boot time.

With Linux hosts I do use Grub configuration file to setup glxmode to my choosed resolution (usually I like to boot my guests at 1440x900) and I do use glxpayload grub option to keep it from console to the graphical user interface.

Everything was working as expected until I upgraded my guests virtual hardware to the last versiion (12) and I upgraded to latest guest VMware Tools (version 10.0.5-3228253).

To cut it short, after both this tasks (hardware upgrade and new VMware Tools upgrade), ALL my guests keep to ignore the Grub glxmode resolution and they started in VGA mode, keeping it for the whole boot and ending me with a graphical machine configured at VGA resolution Really disappointing. Grub prompt showed me - using the vbeinfo command - the extended vesa bios modes were no more supported.

I could use xorg.conf.d to properly setup the X resolution (in case of Linux guests), or do use drag and drop to resize the guests screen when OS and VMware Tools were properly loaded after boot was complited, then I still had always VGA (or any "non extended" Vesa Bios modes) at boot time in console mode.

What I did to solve the problem.

I then investigated the issue and find the culprit. ALL my virtual guest machines configuration (VMX files) were modified by something (Virtual Hardware 12? New VMware Tools?) with this three strings totally NOT WANTED AND NOT REQUESTED by me:

vmotion.checkpointFBSize = "4194304"

vmotion.checkpointSVGAPrimarySize = "33554432"

svga.guestBackedPrimaryAware = "TRUE"

I don't have idea what those lines properly do, then I finally found - and it was a relief - that simply changing:

svga.guestBackedPrimaryAware = "TRUE"

to

svga.guestBackedPrimaryAware = "FALSE"

solved the problem and my guests again like before respected the glxmode configured in the Grub configuration file and were able to boot any not standard Vesa Bios mode. This was also, obviously, confirmed by the vbeinfo command at Grub prompt.

Now I ask: why developer (or who considering it was not me???) changing the behaviour of such a delicate parameter without any explication?

IMHO, if this is inteded, VMware developers should come back to the old behaviour where svga.guestBackedPrimaryAware (do existed before? I don't reallyknow) it is by default FALSE!

If it is a bug, please, fix it :-(((

UPDATE: it is even worst compared to Iwas supposed it was :-(((( On some machines, I still didn't discover on what base, it is even worst! After shutdown the paramenter

svga.guestBackedPrimaryAware = "FALSE"

it is automagically (!!!) changed back to:

svga.guestBackedPrimaryAware = "TRUE"  :-(((

Now the problem is: how to block this change??? Yes I can still change the VMX file to read only, then I suppose there is another parameter controlling this VM guest configuration autochange! If you have any idea...

Messaggio modificato da piggyz Spelling check

[TracyHuang]

Thanks for the posting!

The option in VMX file: svga.guestBackedPrimaryAware = "FALSE" cannot be saved is as expected, as our developer said.  We use that to indicate that the guest-driver is capable of using guest-backed surfaces.  We tried to save memory in newer hardware versions when we detected that they had a new enough guest-driver.  This has the side-effect of limiting modes on some VESA drivers.

If you want to have a larger resolution mode, would you please try setting a larger vram size by the config option "svga.minVRAM8MB=1", then you may be able to boot the 1440x900 mode.

[piggyz]

Hello and thank you very much for the reply.

Putting the line

svga.minVRAM8MB = "1"

in guest virtual machine configuration (VMX) file sadly didn't helped: resolution is still VGA modes

Here the relevant part of VMX file:

svga.minVRAM8MB = "1"

vmotion.checkpointSVGAPrimarySize = "33554432"

svga.guestBackedPrimaryAware = "TRUE"

vmotion.checkpointFBSize = "4194304"

Thankx in advance to help sorting this - for me - very annoying problem.

[TracyHuang]

Would you please provide VMware.log for our further investigation? It's under your VM install location. Thanks!

[piggyz]

Hello and thank you for your reply.

Here the requested log file for one of the guests: the problem is identical for all the Guest Virtual Machines, so I suppose this is enough for all.

[banackm · Accepted solution]

Sorry, I think that precise config option has changed in recent versions.

Try setting the following config option:

svga.minVRAMSize = 8388608

That should guarantee a minimum of 8MB of VRAM for the VESA modes you're trying to set.

[piggyz]

Hi bm,

this definitely fixed the problem.

Need to say there should be a future KB to explain this VRAM hardware 12 work around to have high resolution Vesa modes at boot time.

It will be usefull for many people I think, considering I suppose this days many people need better screen resolutions than standard Vesa modes supported by default during hardware 12 boot. The new default value and the new routines supported by Hardware version 12 (4 MB virtual video card memory) is not enough to provide them.

Thank you guys at VMware for the interest helpin out with this.