Loadrunner Controller crashing on VMWare

[Jacks]

Hi All,

We are trying to install LR on VMWare virtual systems. But when we start the controller it is failing stating that failed to open blank document. Controller was initiated with Admin privileges. There are two IP address for controller machine(Local network and Admin network).

Can anybody please let us know where would be issue laying? This will help us to troubleshoot.
Thanks in advance.

--
Regards
JS

[Sameh Abdelhamid]

Yes.
Dont run the install via Remote Desktop. Install VNC on it, and do it through VNC client.
Mercury used to always say that RDP affected the install cuase you're not at the 'client'. I thought they were bluffing, but it turned out to be true.
Cheers.

--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

[sameh abdelhamid]

Yes.
Dont run the install via Remote Desktop. Install VNC on it, and do it
through VNC client.
Mercury used to always say that RDP affected the install cuase you're
not at the 'client'. I thought they were bluffing, but it turned out
to be true.
Cheers.

[Jacks]

We copied all files to destination and then installed there.
We did it using both ways. But still problem persist.
Whats your opnion on having two IP address and two NIC cards which system is using?

Regards,
JS

--
Regards
JS

[Sameh Abdelhamid]

There is nothing wrong with using 2 network cards..

Most webservers have them.

[James Pulley]

Performance test tools (any vendor) + virtualization = bad magic for all sorts of uncontrolled influences in your test bed. It will impact your initial conditions, your ability to repeat and you will be handing developers who don't like your results a nice shiny aluminum baseball bat to beat you with when you call their code (child) ugly.

It will cost you far more in time, political challenges and lost value than if you spent the 5k and purchased a bank of matching machines for controller, load gen and hot spare use. If you're going to invest the 100k++ in LR, it is to your benefit to get the dedicated generators to add to test integrity

---

From: Jacks <jacks...@gmail.com>

Date: Fri, 6 Nov 2009 10:59:20 +1300

To: <LoadR...@yahoogroups.com>; lr-loadrunner<LR-Loa...@googlegroups.com>

Subject: Loadrunner Controller crashing on VMWare

[Sam Abdelhamid]

James, 

Although you raise some valid and interesting points, I do not believe your statements are all that accurate. 

Virtual machines for load generators have been available since early releases of LR. In saying this, if the VM is setup correctly and the amount of vusers are not exceeded for the ram allocation (each vuser needs 1/2 mb of ram) and the amount of threads that each user access does not max out the cpu, the VM can run fine. 

You don't need a bank of matching machines for a load generator. It's just generating load....lets be honest here, as long as the cpu and ram can handle the application and there is enough utilization for the OS to run and the vusers to run, you have no issue. 

At the end of the day, Virtualizing Load generators is normal, and happens ALOT in large organizations. Its just one of those thing's you have to live with.  

[James Pulley]

Here's my perspective, grounded in solid test practices and direct observations of how, why and where Virtualization and Performance test tools collide and continue to collide in organizations

(1)  The goals that drive the use of load generators on virtualized instances run counter to the goals of high integrity tests.   The goal for virtualization is the maximize the use of available hardware by placing as many virtual instances of operating systems on the hardware as is possible.   With performance testing your goal is the maximize the impact on your application and minimize the influence your test bed has on the performance of the virtual users.   You want maximal performance out of these virtual users and this OS instance.

(2)  I have yet to meet a VMWARE, XEN, Microsoft Virtual Server or KVM environment where load generators were not located alongside other non-test VM instances.   This sets up a problem in basic testing

• Constantly changing initial conditions from test to test.   Each virtual machines state is uncontrolled and running independently.  In software virtualized environments the hypervisor is constantly in control of how resources are parsed out to the VMs based upon requests to access the hardware .   As the broker the hypervisor will make decisions to rob resources from one instance to give to another instance on the same VM host. 
• Uncontrolled influences while the test is ongoing.   Each of the demands of the other VMs constantly shift the mix of resources available to your VM while the test is ongoing.   This is before you add the uncontrolled demands of the shared network interfaces, etc...
• Repeatability.   The constantly shifting sands of initial conditions and uncontrolled influences while the test is ongoing make it almost impossible to meet the absolute demand that your test be repeatable with substantially similar results.   At the end of your testing any third party should be able to take your application definition, your test definition, your data, your load test environment setup and reproduce your results.   Throw Virtualization in the mix and you can pretty much toss repeatability out the window.

(3)  VM Clock drift.  The system clock is also virtualized and occasionally has to resync with the physical system clock.   This system clock is tied to your virtual user timing directly and the amount of drift is unpredictable and ungovernable.   I refuse to accept a situation where I have known clock drift which can occur in the middle of a timing record.

(4)  Try to monitor your Load Generators.   You are at the mercy of whatever your hypervisor tells you is in use  in the way of resources.   I have had VMs from multiple vendors report greater than 100% CPU collective virtualization and the clock drift makes the per second clock drift makes the "per second" stats highly suspect.  Monitoring the host OS for the virtual machines adds its own set of complexities associated with trying to decouple the influences of your VM from others.

(5)  There is no fundamental benefit to placing more than one Load Generator instance on the same physical host.   Yes, I have also observed this a lot in VM environments.   All you are doing is adding overhead.

 

I am not stating that virtualization is universally bad.   Heck, I used it everyday with certain components of LoadRunner such as VUGEN, where I can setup clean environments for specific protocols for recording and development.   It even works out very well with the analysis tool.   But for anything that has a time basis that you are going to make a decision upon....run run run very fast and very far.     The reasons to deploy Virtualization in production are many and sound, but the needs for basic testing principals, consistency in documented initial conditions, consistency and repeatability of the test trump the reasons to fit into the standard VM model for an organization.    Performance test tools are primarily a risk management tool from a business perspective.   Tossing virtualization into the mix adds risk back into  what should be a risk averse set of activities.

 

You're right, it's deployed quite widely in this fashion, but mass does not imply a best practice.   There are probably dozens of behaviors organizations engage in everyday from a performance  test perspective that dramatically impact their test results and these practices are engaged far often than are the best practices associated with performance testing.   The frequency of use does not imply correctness in action.

 

In the end if you are compelled to use virtualized generators then as testers we are compelled to document deviations from testing best practices associated with documented and consistent initial conditions, steps to reproduce and expected results, absence or inclusion of a working hypothesis, the inclusion of control factors in the test and repeatability of the results.     It is this documentation of the known deviations from best practices distributed with your test results which becomes the aluminum baseball bat for the developer to go "Chicago" on you.    And they are not going to go after the CFO who mandated the use of virtualization, they are going to go after the Performance Test team for showing up with less than high integrity results.

 

As to the reasons why the bank of seven

1 host for the controller

1 Host for a "control" generator to execute a single virtual user of each type during a performance test.   You will be able to observe differences  between load generator induced influence in your test execution by observing the differences between behavior of users on your control generator versus the running average of the remainder of your population.   If application influence is king, then both your control group and your global group will decay in performance at the same rate.   Where you have a load generator influenced response time then you will observe a decay in the response time for your global group but your control group will either be unaffected or perhaps get a little faster as influences from the global group are used less aggressively against the app.

1 Hot Spare/Parts Cannibal.   It is still true that one machine in seven will fail within the next 18 months.   And yes, it will likely happen in the midst of a short turnaround testing effort.   By having matched hardware you can either use this machine as a parts cannibal, a hot host to press into a particular duty, or a hot host to rebalance load to if you observe that your global and control groups are being mismatched in performance

4 Primary load generators.   4GB of memory - Windows XP sp3/4 32 bit - 250GB of HD space - Co processed video card - Ideally intelligent disk controllers and network cards with TCP Offload Engines (TOE).   Remember, this is a test bed.   You want your hardware to be boring and work all of the time.   LoadRunner is still a 32 bit app for Load Generation and your application under test cannot tell across the network whether it is a 16 bit, 32 bit, 64 bit or bit sliced microprocessed computer that is connecting to it as a client.   Don't use Windows Server.   There are no dependencies in LoadRunner which mandate the use server and all it does is steal resources that can be better used for Virtual Users.   Windows XP is still the most promiscuous of generators, supporting all protocols.

 

I will open up the offer.   If you have a CIO and CFO that mandate virtualization I will be happy to get on the phone with anyone here and their end client organization to discuss the tradeoffs involved in this decision.   I will do this at no cost as this is a bad testing practice and should be discouraged and stopped in our profession.   You may contact me at mailto:LRVirtua...@jamespulley.com to request this service.  I have all sorts of disaster stories to share and how the end result was prolonged/delayed testing, assignment of errors to the app and budget dollars spent to chase down an engineering ghost when in fact it was the influence of the load test bed which caused the issue, high load tests impacting production instances on other VMs located on the same VM hosts.   The end goal of management with virtualization is to save money and I can point to all sorts of examples associated with this practice in testing where this goal was turned on its head.

 

James Pulley   

---

From: Sam Abdelhamid [mailto:sam.abd...@gmail.com]
Sent: Friday, November 06, 2009 8:25 AM
To: lr-loa...@googlegroups.com
Subject: Re: Loadrunner Controller crashing on VMWare

[Luca.C...@cedacri.it]

Return Receipt

Your Re: Loadrunner Controller crashing on VMWare
document:

was Luca Cattaneo/Cedacrinord_Spa/IT
received
by:

at: 06/11/2009 14.43.00