I have setup a CentOS 3.8 x86_64 VM within Fusion. I have installed VMWare tools and run vmware-config-tools.pl and picked an initial screen resolution. However, my chosen resolution never seems to take effect, either immediately or after a reboot of the guest AND my guest OS window never resizes on the fly to auto-fit when I full-screen it or click-drag to resize it. Auto-fitting does work fine for a Windows XP VM though -- but that one wasn't created in Fusion.
Is there a known incompatibility with CentOS 3.8 (which is, in theory, RHEL 3)? Or did I miss a configuration step somewhere? Is there something I'm supposed to have in the vmx file to enable the auto-fit behavior? I looked at the Windows XP VM's vmx file and didn't see anything there but since it is a different OS, I'm not sure they'd have the same options anyway.
Note that I am running the vmware tools app -- I have it setup to run whenever I login to my VM. Which also means I'm starting up the OS in run level 5.
xrandr doesn't seem to list any of the resolutions I'd like to use either.
Try re-running the VMware Tools configuration script and specifying the widest resolution you'd like the guest to go at that time.
One other thing I meant to point out is that I'd really like to be able to move the VM window to fill an external screen (1200x1600 resolution) when I'm at my desk, but also use it, not full screen, on the MacBookPro screen (1680x1050) when not at my desk. I don't think I can set svga.maxWidth and svga.maxHeight and get that kind of resolution change, right?
Is this really entered as a number of bits instead of a number of bytes?
I've tried entering it as you suggested (that is, as a # of bits, while the VM was powered down, and after editing, I powered it on,) but it doesn't seem to have any effect on my problem. The linux desktop / root window doesn't resize when I make the guest window larger, nor does it resize when I make it full screen. This is true whether the guest window is on the MBP's screen or on an external screen.
In playing around with it, it does seem to snap to certain SMALLER window sizes when I resize the guest window. These sizes are all shown when I do an 'xrandr -q' but none of them is larger in width than 1152 pixels, nor taller in height than 900 pixels. In fact, the largest IS 1152x900. I'd like my VM window to be in the neighborhood of either 1650x932 or 1200x1500.
Clearly it looks like something is limiting what the virtual video adapter will let the screen resolution be set to but for the life of me, I can't figure out what. Is it something in the vmx file? Is it something in XF86Config? (I haven't edited the latter since running vmware-tools-config.pl modified it.)
>Is this really entered as a number of bits instead of a number of bytes?
I removed my comments about bytes since I couldn't find any authoritative reference on this units of vramsize. But I didn't do exhaustive search last night.
I do realize 32-bits / 8 bits = 4 bytes, so perhaps the calculation should 1600 x 1200 x 4. What I do know the limit for VRAM is 128 MB so most users that adjust the value either set it to 64 MB or 128 MB for Vista Aero (also requires 3D) or similar vram-heavy applications.
I found an ESX Release note that actually has an example for 1600 x 1200 as follows:
[b]Configuring Virtual Machines for Larger Screen Resolutions[/b]
You can now enable larger screen resolutions in a virtual machine. A screen resolution of 1600X1200 is supported, provided you allocate sufficient memory to the virtual VRAM for the virtual machine. The suggested option settings for a 1600X1200 screen display are:
svga.maxWidth = 1600
svga.maxHeight = 1200
svga.vramSize = 7680000[/i]
7680000 / (1600 * 1200) = 4, confirming the assumption for a maximum depth of 32-bit. So the units are bytes.
Okay, so I tried setting the vramsize to 7,680,000 (formatted that way here for readability reasons -- no commas in the actual value.) in the VMX file and when I start up the guest, the desktop still won't auto-resize larger than 1152x900. Though it does auto-resize to smaller guest windows.
There must be something other than vramsize that is limiting my guest's desktop / root-window size. Does anyone have any ideas on what it could be? Could it be some hard-coded limit in the VMware driver for RH 3?
Try re-running the VMware Tools configuration script and specifying the widest resolution you'd like the guest to go at that time.
Alrighty, I re-ran that. I'm noticing an error in the output that I don't remember seeing previously. I'm not sure what the error means and I'm not sure if its because I've done something wrong in my vmx file or not.
Here's the svga lines in my vmx file:
svga.maxWidth=1700
svga.maxHeight=1600
svga.vramSize=10880000
And here's the output of X config section when running vmware-config-tools.pl. Note the lines about __stack_chk_fail in the vmware drivers.[/b] Is that normal?
Do you want to change your guest X resolution? (yes/no) \[no] yes
Please choose one of the following display sizes (1 - 15):
\[10] "1400x1050"
\[11] "1440x900"
\[12] "1680x1050"
\[13] "1600x1200"
\[14] "1920x1200"
\[15] "2364x1773"
Please enter a number between 1 and 15:
XFree86 Version 4.3.0 (Custom Build: 4.3.0-115.EL)
Release Date: 15 August 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.21-47.0.1.EL.centos3.XFS.2smp x86_64 \[ELF]
Build Date: 10 January 2007
Build Host: sillage.bis.pasteur.fr
Before reporting any problems, please make sure you are using the most
recent XFree86 packages available from Red Hat by checking for updates
at http://rhn.redhat.com/errata or by using the Red Hat Network up2date
tool. If you still encounter problems, please file bug reports in the
XFree86.org bugzilla at http://bugs.xfree86.org and/or Red Hat
bugzilla at http://bugzilla.redhat.com
Module Loader present
OS Kernel: Linux version 2.4.21-47.0.1.EL (centos@sillage.bis.pasteur.fr) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56)) #1 SMP Thu Oct 19 10:20:02 EDT 2006 PF
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/vmware-config7/XF86ConfigLog.2377", Time: Fri Jan 26 15:42:11 2007
(++) Using config file: "/tmp/vmware-config7/XF86Config.2377"
X is running fine with the new config file.
Symbol __stack_chk_fail from module /usr/X11R6/lib64/modules/drivers/vmware_drv.o is unresolved!
Symbol __stack_chk_fail from module /usr/X11R6/lib64/modules/drivers/vmware_drv.o is unresolved!
Starting VMware Tools services in the virtual machine:
Switching to guest configuration: \[ OK ]
Guest filesystem driver: \[ OK ]
Mounting HGFS shares: \[ OK ]
Guest memory manager: \[ OK ]
Blocking file system: \[ OK ]
DMA setup: \[ OK ]
Guest operating system daemon: \[ OK ]
The configuration of VMware Tools e.x.p build-36674 for Linux for this running
kernel completed successfully.
You must restart your X session before any mouse or graphics changes take
effect.
Ignoring the error reported in the above post, I shutdown and rebooted the guest OS (since it was runlevel 5, that seemed the easiest way to restart X.)
This helped, but only partially I'm afraid. Now, on my MBP's screen (1680x1050) resolution, I can click the green button on the guest window and maximize it to almost take up everything but the OS provided menubar / status bar (where your app menus show) -- it just doesn't take up all the width of the screen for some reason. (xvidtune -show reports 1676x989 instead of 1680x989.) But this is a very minor problem.
The remaining problem is that dragging the guest window onto the external screen (resolution is 1200x1600 -- yes, its an LCD standing on its side) and trying to maximize still only gives me a maximum of 1100x1000 size. No amount of dragging the window sizer, nor clicking the green maximize button will make it larger. Is this a result of having picked option 12? Or is it a result of it being on an external screen? Or is it a result of the screen being rotated?
Do I just need to pick the largest possible possible option in vmware-config-tools so that my max width is greater than 1600?
Having picked option 15 (2364x1773) and restarted the guest OS yet again, I am now able to 'maximize' the guest window on the external screen and get a 1200x1600 desktop / root-window!!!
However, when the guest OS starts it creates an initial window size larger than either of my actual monitors. I suspect it really is 2364x1773. And this does not auto-resize to fit the guest window. Luckily, I can just barely see the login & password fields on either monitor so its not critical, but I'd suggest finding a way to auto-fit the login screen, or do something to ensure that the start-up size fits the actual monitor the VM guest window is currently on.
What is your OS's uname -a and gcc -v? The error above in a newer entry point in the linux kernel which will either require you to upgrade the kernel or (re-)build the VMware tools with -fno-stack-protector in CFLAGS in the Makefile.
uname -a:
Linux localhost.localdomain 2.4.21-47.0.1.EL #1 SMP Thu Oct 19 10:20:02 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux[/i]
gcc -v:
Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56)[/i]
This is the most up-to-date I believe I can get on CentOS3. At least I did a full 'yum update' a few days ago.
I didn't realize the source for VMWare tools was included in the install.
I've seen the entry point defined in the 2.6 kernel, I don't know in what rev Red Hat would have ported into their 2.4 kernel trunk.
I have also seen that perhaps the linkage for this entry point requires gcc 4.1, but I don't know how valid that is, I have built the tool drivers in debian with 3.x and other distros with 4.x.
The complete source to the tools is not[/b] publically available but many of the subsystem driver sources are there. Here's a listing from the Fusion Linux ISO:
tar tvfz VMwareTools-e.x.p-36674.tar.gz | grep source
-rrr-- root/root 194560 2006-12-15 02:23:15 vmware-tools-distrib/lib/modules/source/vmblock.tar
-rrr-- root/root 81920 2006-12-15 02:23:25 vmware-tools-distrib/lib/modules/source/vmmemctl.tar
-rrr-- root/root 92160 2006-12-15 02:23:40 vmware-tools-distrib/lib/modules/source/vmdesched.tar
-rrr-- root/root 245760 2006-12-15 02:23:44 vmware-tools-distrib/lib/modules/source/vmxnet.tar
-rrr-- root/root 409600 2006-12-15 02:23:54 vmware-tools-distrib/lib/modules/source/crosstalk.tar
-rrr-- root/root 634880 2006-12-15 02:24:01 vmware-tools-distrib/lib/modules/source/vmhgfs.tar
Additionally I'm rusty at resolving .o symbol references using ar, ranlib, libtool, etc. Maybe a VMware engineer can shed some more light on this.
Note that I am running the vmware tools app -- I have
it setup to run whenever I login to my VM. Which
also means I'm starting up the OS in run level 5.
Where did you get the version of VMware Tools you installed? If it's one of the various repackagings floating around on the Internet, such as the one from cvut, be aware that (unless I'm mistaken) that's the version of tools for Workstation 5 and its siblings. But Fusion has (and requires) a newer version of Tools; the only other place you'll find it is in the Workstation 6 beta.
So, if you haven't already done so, try installing the version of Tools that comes with Fusion. The menu pulldown (Virtual Machine -> Install VMware Tools) is just the first step for Linux VMs; you then have to do a barrage of commands as root. This Wks 5.5 page is still pretty valid:
http://www.vmware.com/support/ws55/doc/ws_newguest_tools_linux.html#wp1127214
In RHEL-esque distros, /mnt/cdrom is /media/cdrom or /media/cdrecorder.
Anyhow, maybe you've already done this, in which case maybe this guidance will help somebody else out.
Based on the output above it's probably Fusion's tools:
tar tvfz VMwareTools-e.x.p-36674.tar.gz | grep vmware_drv.o
-rrr-- root/root 79653 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XFree86-4/4.x/vmware_drv.o
-rrr-- root/root 34135 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XFree86-4/4.2.x/vmware_drv.o
-rrr-- root/root 43795 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XFree86-4/4.3.x/vmware_drv.o
-rrr-- root/root 65481 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XFree86-4/4.3.x_64/vmware_drv.o
-rrr-- root/root 43795 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XOrg/6.7.x/vmware_drv.o
-rrr-- root/root 65449 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XOrg/6.7.x_64/vmware_drv.o
-rrr-- root/root 43795 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XOrg/6.8.x/vmware_drv.o
-rrr-- root/root 65449 2006-12-15 02:23:25 vmware-tools-distrib/lib/configurator/XOrg/6.8.x_64/vmware_drv.o
hilo:/Volumes/VMware Tools rcardona$ tar xvfz vmware-tools-distrib/lib/configurator/XFree86-4/4.3.x_64/vmware_drv.o[/code]
Notably this object file: vmware-tools-distrib/lib/configurator/XFree86-4/4.3.x_64/vmware_drv.o. I can't seem to extract any symbol dependencies out of the object file in OS X though.
Note that I am running the vmware tools app -- I have
it setup to run whenever I login to my VM. Which
also means I'm starting up the OS in run level 5.
Where did you get the version of VMware Tools you
installed?
This is a new VM that was created from scratch using Fusion. The version of tools that is installed came from doing the Virtual Macine -> Install VMware Tools menu option. Selecting that resulted in an ISO mounted as a cd, from which I then installed the rpm, and then ran vmware-config-tools.pl.
Since this is CentOS 3.8, I told Fusion that the VM was for RH 3. I'm assuming Fusion picked the right version of the tools, but perhaps it did not and that's the problem? I'm not familiar with where Fusion may be storing the various ISO images, nor how to tell exactly whether I have the right version or not.
rcardona2k, I'm not sure what you want me to do since you say the complete sources aren't there for rebuilding, at least not in the public domain.
>Since this is CentOS 3.8 ... I'm not familiar with where Fusion may be storing the various ISO images, nor how to tell exactly whether I have the right version or not.
The ISOs are by OS types: freebsd, linux, netware, solaris, and windows but they support multiple versions and variations in their contents. The location of the ISOs is: /Library/Application Support/VMware Fusion/isoimages. The reason I used grep for linux is that there are over tens of megs of sources and binaries!
>rcardona2k, I'm not sure what you want me to do since you say the complete sources aren't there for rebuilding, at least not in the public domain.
Sources are not always required when you have object files (.o) to work with because the static linker is responsible for resolving imported references.
What I'm saying might work is upgrading to gcc 4.1.x and uninstall/re-install the tools. If the kernel entry point for __stack_chk_fail is missing in CentOS, then re-installing the tools under gcc 4.1 might reconfigure appropriately to avoid the error. If it doesn't then your other choices are a lot less trivial.
rcardona2k, I appreciate the effort you're going through to try and get rid of that error message!
However, the whole point of my VM is to be able to tell whether we can use VMware Fusion to build and test some software on the standard release of RHEL3 (which CentOS claims to be.) I admit I'm no Linux expert, but wouldn't upgrading gcc mean that all my software builds are now being done on a non-standard version of RHEL3? If so, then that's not a usable solution for me.
I haven't noticed any problems with my video now that I've set the vmware-config-tools resolution to a really large value. Is this error message really going to cause a problem?
>rcardona2k, I appreciate the effort you're going through to try and get rid of that error message!
>I haven't noticed any problems with my video now that I've set the vmware-config-tools resolution to a really large value. Is this error message really going to cause a problem?
LOL, the amount of effort has probably exceeded the severity of the warning, this I admit is true. If you're happy with the current setup there's not a need to belabor this further.
To answer your other question, the differences between gcc 3.x and 4.x are disruptive enough that there's a gcc-selector available (at least on OS X) in /usr/sbin called gcc_select. Installing gcc could change other things that are not so easy to undo, so you can totally stay with what you have.
A good developer is taught to achieve no warnings, no errors at all costs. Not that I'm calling myself a good developer...