Closed Bug 438954 Opened 17 years ago Closed 17 years ago

Create a VMWare Workstation 6 Linux unit test VM on tinderbox

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: roc, Assigned: phong)

References

Details

Attachments

(1 file)

screenshot of error when trying to use the downloadable ref platform in vmware workstation
17.81 KB, image/png
Details
We're constantly bugged by random test failures especially, lately, on centos5. One really powerful way to track these down would be to use VMWare Workstation 6's record-and-reply feature to record the test runs of a unit test tinderbox. If the tests fail, we can save the log (and the snapshot at the start of the test run) and developers can rerun the exact test run and debug the failure with VMWare's patched gdb. You seem to be able to run Workstation 6.5 beta as a guest in an ESX host: http://www.thincomputing.net/blog/vmware-workstation-6.5-beta-1-refresh-re-adds-esx-support.html Please please please find a way to make this happen.
Assignee: reed → nobody
Component: Tinderbox Platforms → Release Engineering
QA Contact: dbaron → release
Assignee: nobody → lukasblakk
Priority: -- → P2
Would it work for you to have a downloadable version of a current unittest vm, similar to the one here: http://wiki.mozilla.org/ReferencePlatforms/Linux-Public If that would meet your needs, we can ask for a clone of qm-centos5-03 which has been having intermittent failures on tests and this clone can be scrubbed and turned into a downloadable vm.
Status: NEW → ASSIGNED
That would be a good start, but we really also need that VM running in Tinderbox in recording mode so that when an intermittent failure appears, people will notice and and we can debug that particular failure from the record.
This really would be a fantastic way to catch the failures on Linux and make them reproducible. Perhaps we can just spin up a new VM instance of the centos machines with recording on?
AFAIK the VM has to be running in Workstation to make this work, right? I don't think we have any VMs running in Workstation, they're all on ESX. (Although IT is the right group to ask that question of).
(In reply to comment #4) > AFAIK the VM has to be running in Workstation to make this work, right? I don't > think we have any VMs running in Workstation, they're all on ESX. (Although IT > is the right group to ask that question of). I believe this is true. It's a Workstation 6+ feature, afaik.
Justin: Not sure what RelEng can do here. Should this bug be assigned to IT for setup of VMware workstation?
Assignee: lukasblakk → nobody
Status: ASSIGNED → NEW
Component: Release Engineering → Release Engineering: Future
Priority: P2 → P3
All our infra is ESX or GSX, which does not support the record-replay. What I'd suggest is see if we see the issues on the mac mini that Lukas is setting up, if not, put Workstation on the windows mini and try it out. We can get releng the license and hardware, and help with the p2v, but should be a joint thing headed (I think) by releng based on the output of the tests. Sound ok?
We now know there are for sure code/test related issues that would be good to debug (see my post in newsgroups). Mention this so we don't block this behind the physical hardware setup. If in practice we are resource constrained this can wait. If we have a VM Image + Wiki docs I'd be happy to setup an instance on my local mini set to track this down.
given we'll have the image, we should be able to bring up another mini at the same time and hand off to Lukas for setup (or anyone else for that matter). Does anyone care what guest OS is (linux/windows)? Linux would prob be easiest given it doesn't need a windows license.
Needs to be linux - also to be useful we will have to be able to hand the image (or local machine access) to a developer once it fails.
And I'm seriously happy to do this locally - not a threat to get you to over-prioritize this :-)
If we set up a standalone Linux Workstation VM on dedicated hardware and it never goes randomly orange, then at least we've learned something, and we have one good test box for Tinderbox :-).
So this is going to be a mini running the CentOS 5 ref platform we use for unittest. Phong has the image for this. Can we call it bm-centos5-workstation-01.build.mozilla.org Unless anyone wants it to be on a different network than build. If it's on the build network, I can connect it to the staging-master unittest staging waterfall.
Status: NEW → ASSIGNED
Assignee: nobody → phong
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
The mini is on your desk. Let me know when it's ready for me to move it to the colo.
Do we have any progress on this?
I'm still working on this intermittently over the week.
I'll need a VMWare workstation serial number. The evaluation one that I got has expired already. Do we have one?
Status: ASSIGNED → NEW
There's probably one allocated to me that I'm not using anymore - Lukas can take that one, if it exists.
So, I have VMWare workstation setup, and tried to use the downloadable ref platform and set the recording feature, but I ran into this error. I will try to create a new vm from scratch next and see what happens.
Phong - i'm going to put this box back on your desk, if you can put it up on the build network as: moz2-linux-workstation.build.mozilla.org then i can continue to tweak on it from Toronto.
can you put a note on it so I don't it mixed up with other mini on my desk.
Status: NEW → ASSIGNED
moz2-linux-workstation.build.mozilla.org 10.2.71.180
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Did the "try this out" portion of this bug get spun out somewhere else? I can't seem to find the bug if it did. Note that Chris Pearce got record and replay debugging working locally in workstation: http://pearce.org.nz/2009/03/setting-up-vmware-to-record-replay-and.html
I've posted feedback on my experience using record-replay here: http://communities.vmware.com/thread/199654 I found that it's hampered by its slow speed, and unreliability. If it was faster, it would be considerably more awesome. It still can be useful, but it's slow and somewhat frustrating to use.
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: