Let's back up a minute. All things being equal, aside from the delay in CUPS printing, what else is not working at or beyond par? Is the printing issue the ONLY issue? How long is the delay? Is it between pages or between jobs or just a lag for a given job to start from a cold start (nothing else printing at the moment)? How do the users log/use the system? If telnet or ssh, is there any delay in connecting there? Any changes elsewhere in the environment as part of this upgrade (such as network equipment/configuration, version of linux on the guests, DNS servers, etc)? Anything out of the ordinary in /var/log/messages or the tail of the 'dmesg' output that is present on the guest in question and not when it was physical? I assume the guest's physical form still exists somewhere? How are the cups printers connected to the network and likewise configured in CUPS on the guest? If TCP socket based setup (ie, TCP port 9100), what happens if you open a terminal window on the guest in question and execute a telnet to the printer's IP address on port 9100 (ie, 'telnet <ipaddr> 9100')? Does it connect immediately or is there a delay? Not sure if you have more than one printer, but if so, do all printers exhibit the slowness or just certain ones? In vSphere Client, as I'm sure you are aware, the host and guest both have tabs for "Resource Allocation", "Performance" and "Events". Between periods of printing and non-printing, is there anything that seems out of whack or wildly varying?
Chris is right, you need to install VMware Tools. It is very easy on CentOS 6. When you tell vSphere Client to install VMWare Tools on the CentOS guest, it will connect a small .iso image to the guest, and, if you are running a GUI console for the guest, and are logged in as root, it will likely automount it for you. However it does, you need to locate the mount point, then from, say, /root, extract the tarball on the mounted image. There is a perl script in the extracted folder to install vmware tools. Run it and just take the default for everything (initially at least). You should probably reboot the guest too once it's done as depending on how it finds the guest's environment, it may build a new kernel boot image. Once VMWare Tools is running, the guest will communicate a lot more info back to the host and this will provide additional information about resource utilization at the guest level with respect the ESXi and the host and may help identify bottlenecks at the VMWare level. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Howard White Sent: Tuesday, November 20, 2012 2:05 PM To: [email protected] Subject: Re: [nlug] the continuing saga of the reluctant systems administrator On 11/20/2012 01:42 PM, Chris McQuistion wrote: > What's your disk subsystem with the new ESXi host? How much physical > memory and CPU does the box have and how much have you designated to > your VM's? > > Do you VMWare Tools installed on the Guest VM's? > > Chris > 300GB of mirrored SAS drives on a 3ware RAID controller. 16GB of physical memory with 8GB allocated to guest 1 and 4gb allocated to guest 2. Has one four-core CPU; guest 1 has "3 cores" allocated and guest 2 has one. Top is showing 24k of swap used but current memory used is quite a bit less than 8GB. And yes, Tilghman, vm.swappiness=85. Reading up on VMWare Tools Howard -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
