Hey Bala, there are many test cases - help us narrow down what you need...

• Technology test cases - like testing if vMotion works, or that HA works, or that DRS works - this is typical Proof of Concept testing done at the very early stages of virtualization when you don't quite believe that VMware products are as fantastic as they claim!
• Performance test cases - this should be using a standard benchmark, not some home-grown, cobbled-together test case - the purpose being to see how many "transactions per second" or "users per virtual machine" are possible.
• Operational test cases - these can range from testing standard operational procedures, such as rebooting an ESX server, to documentation testing (installing an ESX server) or troubleshooting (checking that alerts from ESX Server reach your operations centre monitoring console).
• System test cases - checking that the components work well together, like ESX Server and CLariion over iSCSI

Of course, you may already have a list of the above and details of how you would test a physical OS installation like Microsoft Windows 2008, and you are looking for similar steps?

Please provide more detail.

Thanks

Steve

Let's see if I understand: you want to test that your design is fit for purpose? Example: You have designed and built a cluster, now you want to test that HA works, etc.

OK, that's pretty straight-forward. I have a document on one of my other systems but can't get that until tomorrow. Until then, here's how I would approach this:

* Make sure that the design includes targets to test against. For example, if you have designed and built HA, then under what conditions will it provide high-availability (e.g. host only? or host and VM?), what are the conditions to trigger a failover (e.g. pull a network cable out), what alerts should be triggered and received, what is the expected recovery scenario, what are the actions required, how do you return to normal / close the test. In summary:

1 - Conditions - set the test conditions before you start

2 - Triggers - what are the trigger events (these are the events that would happen in "normal" production, and the ones you will pretend / mimic in test - like a network fail).

3 - Alerts - what events should you see, and where, and by whom?

4 - Actions - what actions are required by Support staff?

5 - Recovery - what is the recovery procedure

If you apply the same approach across all components of the system, you have a good test plan. Here is a rough list of components to test:

1. Virtual machine - usual application and OS errors, check they still work. Trigger a blue screen. Power cycle a VM. Change the configuration - is this monitored for audit?
2. ESX Host - have you signed off the hardware against the HCL (that's a test) and tested the memory, as well as the BIOS settings? Is the ESX configuration as expected? Does the server power on / power off as expected? Can you reboot it? Can you log on remotely / on console etc. Can you manage the host from VC? Do NICs failover? Do HBAs failover? Do power units fail over? Test external network and fabric switches for failover.
3. VirtualCenter - usual build tests (is it configured as per design), operational test (reboot / logon / configure etc), failover (if you have redundant VC), OS tests, stop/start VC, SDK tess ... lots more
4. HA - testing HA is fit for purpose
5. DRS - does it behave as expected under load - generate load with benchmarks (see performance on vmware.com for lots of benchmark ideas)

There are many more, but you get my drift... perhaps we should collaborate on writing this up into a proven practice on VIOPS?

Thanks

Steve

Hi David, I propose the following... what do you think...

1) You (or someone else) creates the document in the Management zone. That takes about 90 seconds, instructions are here: How to create a proven practice document

(I could create the doc, but then I would be noted as the Author and I'm fed up of seeing my name everywhere!)

2) We fill in the metadata/headings (explained in the "How to" document above) and then write up a bulleted list of headings / outline of the content.

3) Then we post a discussion thread / invite people to comment and contribute, and fill in the blanks.

Building the document over time works really well and is a method I've used before a few times. That way, you can put in what you need without feeling you have to write the whole thing.

Why don't you make a start with creating the doc, filling in the headers and the outline as above, or whatever you think the outline should be, then click "Submit for Approval" and we'll take it from there.

Once the doc is in decent shape we'll promote it via blogs and on VMTN and other websites.

Cheers!

Steve

Hi all - Happy New year !! Has there been any follow-up in regards to developing this document?

Chuck

I appoligize for the delay, but got sidetrack on some other projects. Hopefully will post what I have today.

Here is a link to the document draft. Please feel free to respond with any changes. Will continue to add cases as time allows. There is a draft awaiting approval but feel free to comment on anything.

http://viops.vmware.com/home/docs/DOC-1271