Closed Bug 809072 Opened 12 years ago Closed 12 years ago

Get NVIDIA card being the default one on w732-ix-test1 and mn-ix-w864-002

Categories

(Infrastructure & Operations :: RelOps: General, task)

x86
macOS
task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: armenzg, Assigned: mlarrain)

References

Details

After this happens I will have to re-evaluate both machines.
Depends on: 808662
Blocks: 780024
This is high priority.
Severity: normal → major
In case that the work in here means loosing OOB console redirection. Here are some info that might be relevant to this bug. I'm re-pasting since info like this is easy to be forgotten and need to be re-investigated (I speak from my own experience): (from bug 758624): (In reply to Jake Watkins [:dividehex] from comment #10) > Coop: > > The following nodes are ready for testing: > ix-multinode-1-C.build.scl1.mozilla.com (CentOS 6.2 x86_64) > ix-multinode-1-D.build.scl1.mozilla.com (CentOS 6.2 i386) > > Note: I have enabled the onboard video since it looks like nvidia addon card > is being detected and switched over to being the primary display > Maybe dividehex was making explicit reference to Linux and does not apply to Windows? (In reply to Matthew Larrain[:MaRu] from comment #17) ... > The other issue we seem to face is that > IPMI will not pass video redirection over a third party video card. This > isn't a complete blocker as it is more a luxury for troubleshooting but as > part of the image deployment requires us to connect to the clients. I have > setup a work around with monitoring from the WDS/MDT box, however this opens > up a new issue that anyone imaging will have to have access to the WDS/MDT > box and the images that it holds where if changes are made could break the > imaging process. I will be online tomorrow to discuss further as I am still > attempting to determine the rest of the potential issues we might face with > these systems.
From a brief discussion yesterday, the three options here are: 1. Fix MDT to work as described in the last quote in the previous comment, and disable the onboard video. Apparently there are problems with this approach, although I don't have details. 2. Configure windows during the install process to run only on the external video card, regardless of how the BIOS started up. Then enable the onboard video for installation purposes. I don't know how difficult this would be. 3. Enable onboard video for installs, then disable it for production. This will require on-site assistance to *re*install a box, though, since (to my knowledge) we can't enable onboard video remotely after it's disabled. Bonus points if we can find a way to control the onboard video status via IMPI protocol or the IPMI web UI. The third option would be very painful, but might be a good short-term workaround to get these into production, followed by accomplishing number 1 or 2 in the full mdt/gpo/pupppet imaging solution that is to follow.
What option is the known to work (if such) and can get me unblocked on the short term? I would like to re-qualify the Win7 32-bit and Win8 64-bit nodes ASAP so we can be sure that things will work. In other words, what is the plan of action? If we need a free node for trying to see which of the three options is the long term solution we could use the node that has XP installed unto it. Thanks in advance!
I'm only worried about the short-term right now. None are known to work. Which will be easiest is up to MaRu.
I am getting a kvm spider hooked up to one of the systems so in case i lose the ability to get into the bios to play around or a preboot environment like winpe. The node I picked is ix-mn-w764-002 which will be changed to ix-mn-w864-002 as soon as dcops makes the changes (I didnt want to confuse them with changing the names first) Then I will push w864 to it with the video card set as the primary card for armen to test with. Hopefully that works for all of us as far as testing goes.
w732 has been switched without a spider attached but we are able to RDP to it. Armen is testing it in staging now.
Assignee: server-ops-releng → mlarrain
Hi MaRu, Do you have a bug keeping track of DCOps helping us to switch to the NVIDIA card for mn-ix-w864-001? If you need to and there is any releng available in your timezone they can disable the slave from slavealloc and stop it at: http://dev-master01.build.scl1.mozilla.com:8041/buildslaves/ix-mn-w864-001 Thanks!
yeah they are moving the spider today at 3:00PM but its for 002 not 001 I am using 001 to finish my testing. 002 is currently named ix-mn-w764-002 but once dcops finishes there work I am going to change DNS/inventory/DHCP for that host and do the video card work for you.
Armen Vinh has hooked up the spider to ix-mn-w864-002 I am making the dhcp/dns/inventory changes now so you are all set come tomorrow morning.
MaRu, I can't access this host. I can't even ping it.
Looks like it needed to be rebooted I wonder if the power options needed to be changed. I went ahead and ran; powercfg -setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c powercfg /change disk-timeout-ac 0 the top command changes the power options to high performance and the second one sets the hdd to never turn off. I think this may have been the case as it was only a matter of an hour between me telling you I could RDP and you not being able to. If you have any other issues please let me know and we can dig down a little deeper.
AFAIK this is resolved fixed.
Summary: Get NVIDIA card being the default one on w732-ix-test1 and mn-ix-w864-001 → Get NVIDIA card being the default one on w732-ix-test1 and mn-ix-w864-002
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.