All Posts

Thanks for the reminder of SKIPRESTORE. I think I have passed the stages of "VMmark setup" and "VMmark wkld setup". I set "SKIPRESTORE" to 1 as you suggested. I am using the 5-min version of the VMMark.cfg file to do only 5-minute run. But the test seems to take forever. ( I am waiting more than 20 minutes) Part of the Active STAFCmds had the following text ... C: vclient0//database//database0.wrf" workload "swingbench" wait stderrtostdout returnstdout sameconsole The database0.wrf has the following output with all the measurements "0" Author : Dominic Giles Version : 2.3.0.83 Results will be written to results.xml. Time Users TPM Nested TPM NCR BP OP PO BO 9:32:54 AM 0 0 0 0 0 0 0 0 9:33:54 AM 0 0 0 0 0 0 0 0 My questions are, 1. Why this output "database0.wrf" is under "vclient0\database" directory, not under "vmmark\result" directory like other workload? 2. If it is a 5-minute test, the test should stop after 5 minutes even though there is a restore operation? Correct? 3. The Benchmarking guide mentioned to rebuild the Redhat kernel to set the interrupt frequency, how this setup will affect this benchmark? 4. I dont think the test is running properly, any suggestion what should I check?

OK, this is the same fix for the trust level problem. I have fixed it. Now I am getting the following error during wkld setup, Stafcmd : FS Copy file: SPECjbb.params failed with RC=17, STAFResult=c:\vmmark\tmp\SPECjbb.props_0 Stafcmd : FS Copy file: SPECjbb.props_0 failed with RC = 48, STAFResult=c:\vmmark\tmp\SPECjbb.props_0 Stafcmd : FS Copy file: javaserverclient.props failed with RC=17, STAFResult=c:\vmmark\tmp\javaserverclient.props_0 Stafcmd : FS Copy file: javaserverclient.props_0 failed with RC = 48, STAFResult=c:\vmmark\tmp\javaserverclient.props_0 I did not find the file SPECjbb.params as part of SPECjbb2005 installation. Any suggestion on what the next step is? Thanks.

in the vmmark/xml file there is a _functions.xml module that does handles the workload specific task in one of several functions with Init, Config, Setup, Run, and GetResults in the name. The Setup phase handles restores that may be needed. FWIW, there is a Database/SKIPRESTORE flag in the VMMARK.CONFIG file that if set to one will by pass the restore of the database that can be useful when just trying to get things running since it can save some time.

I set the default level to 5 according to what you suggested. It seems to pass the trust level problem. But the test ran out of the disk space. ( I only use 16G disk drive) I need to add the space before I go further. Can I ask you - Which file(s) in the VMMark harness is triggering the stop/backup/start db operations? Thanks.

the easiest way is to set the default trust level to 5 TRUST DEFAULT LEVEL 5 or TRUST LEVEL 5 MACHINE *.company.com or TRUST LEVEL 5 MACHINE 10.20.123.* for more info see the STAF instructions on trust levels: http://staf.sourceforge.net/current/STAFUG.htm#HDRTRUSTCFG

I moved the client installation C drive now. I passed the stage of VMsetup test. I am getting the following error during wkld setup, stafcmd: FS Copy file: SPECjbb.params failed with RC=25, STAFResult= Trust level 4 required for FS COPY request. Source machine/user has trust level 3 on TOMACHINE .... I did have the trust level set to 5 in STAF.CFG in both client and server sides. Any suggestion? Thanks.

the easiest way is to set the default trust level to 5 TRUST DEFAULT LEVEL 5 or TRUST LEVEL 5 MACHINE *.company.com for more info see the STAF instructions on trust levels: http://staf.sourceforge.net/current/STAFUG.htm#HDRTRUSTCFG

You mention that you are editting VMMARK.CONFIG.5min - did you also specify that file name in the Arguments entry under "Submit New Job" Functions Tab. if JavaServer/serverpath=C:\apps\SPECjbb2005 and that's where the jbb kit is located on the javaserver VM, it does work. If you move the vclient0 directory into a subdirectory, you also need to update CLIENTROOTDIR as well as any other clientpath parameters in VMMARK.CONFIG Note: The Client systems are required to be installed on the C drive.

No, virtual CPUs have no notion of hyperthreading. ESX Server takes advantage of hyperthreading on the box, but the virtual CPUs are not considered hyperthreaded. So you can think of a virtual CPU as being similar to a single-core non-hyperthreaded CPU.

The VMmark harness does initiate tbench_srv.exe on the client. You may want to tweek FileServer/TSRVDELAY in VMMARK.CONFIG to 10 or 20 and try again. If that doesn't work, then check the message in the fileserver0.wrf file. If you get a can't bind message, try rebooting the client and try again. You can also try changing the FileServer/base_port to some other value tahn 1066. Let me know if it works or not.

>>You should also insure that the tbench_srv.exe is running on the client before the fileserver VM starts. Does 'tbench_srv.exe' need to be executed manually? Can VMMARK initiate the execution?

I would like to clarify the meaning of virtual cpu - Does the virtual cpu imply the logical processor? for example, if ESX is running in a dua-core processor with the hypertheading enabled, is the number of the virtual cpu "4"? or ESX has its own definition of the virtual cpu?

Can you ping vclient0 from the fileserver VM? You might need to add an entry into your /etc/hosts files. Also, do you have any firewalls enabled on your client? You should also insure that the tbench_srv.exe is running on the client before the fileserver VM starts. \- Bruce

I am at the point of testing the fileserver workload alone. I was able to get the correct reply from the dbench client connection test. ('socket options returned 3') but the result file 'fileserver_dbench0.out' had the following messages, Timer started at 1170685003.18 failed to connect to vclient0 - Connection refused client 0 failed to start Timer started at 1170685003.18 failed to connect to vclient0 - Connection refused client 1 failed to start : Timer started at 1170685003.18 FAILED TO START 45 CLIENTS (started 0) Throughput 0 MB/sec 45 procs How do I trouble shooting this error? Thanks.

If you are running a non-standard test and double the number of vCPUs in each VM, then unless you changed something else like load level requested by the individual workloads, there would not be a need to increase Ram or Disk. In the current VMmark beta, only Standby and Fileserver are 1 vCPU VMs, the other 2 are 2 vCPU VMs. In the next beta, we are planning to reduce the memory foot print of the tile by reducing the RAM in the Javaserver and Mailserver VMs to 1GB.