Yes in the olden days when we were on 3.5 and DAS I would get the pink screen of death and new Perc firmware fixed that. Just a stupid question but I assume you don't have a maint contract with VMWare or you would have opened a case with them right? In the past when I've has similar issues as this they've been able to resolve it for me over a webex very quickly.
-----Original Message----- From: Kurt Buff [mailto:[email protected]] Sent: Thursday, April 08, 2010 9:05 PM To: NT System Admin Issues Subject: Re: OTish: ESX 3.5 guest won't boot You are reading my mind... On Thu, Apr 8, 2010 at 17:01, Klint Price <[email protected]> wrote: > No problem.... I have had some 2950's on ESX go haywire with DAS when there > was high IO going on, requiring a reboot. You may want to check for newer > firmware for the card and related hardware. > > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Thursday, April 08, 2010 4:07 PM > To: NT System Admin Issues > Subject: Re: OTish: ESX 3.5 guest won't boot > > BTW... > > Damian and Klint and Karl: Thanks for your help on this. I really appreciate > it. > > Kurt > > On Thu, Apr 8, 2010 at 15:39, Klint Price <[email protected]> wrote: >> Remember to power off all guests, and put in maintenance mode in case you >> need to reboot several times. You may also want to shut off auto power-on >> so you can bring them back online one at a time. >> >> -----Original Message----- >> From: Klint Price [mailto:[email protected]] >> Sent: Thursday, April 08, 2010 3:38 PM >> To: NT System Admin Issues >> Subject: RE: OTish: ESX 3.5 guest won't boot >> >> Ok, a 2950 has dual core Xeons. Don't worry about the 90% on Proc 0 as your >> average load is coming in around 60%. >> >> Let me know the results of your reboot process. >> >> -----Original Message----- >> From: Kurt Buff [mailto:[email protected]] >> Sent: Thursday, April 08, 2010 3:24 PM >> To: NT System Admin Issues >> Subject: Re: OTish: ESX 3.5 guest won't boot >> >> Dual proc, dual core. >> >> Proc 0 = 90.72% avg >> Proc 1 = 50.18% avg >> Proc 2 = 49.49% avg >> Proc 4 = 49.74% avg >> >> Total is 59.74% avg >> >> But it's been higher than that all the time I've been troubleshooting >> this problem. >> >> Kurt >> >> On Thu, Apr 8, 2010 at 15:12, Klint Price <[email protected]> wrote: >>> 90% utilization after downing two servers? Is that 90% on a single core, >>> or 90% total? >>> >>> How many other VMs do you have on the LUN(s) that are still powered on? >>> Any more than the two referenced below? >>> >>> What is the output / top CPU utilization pct for the processes found by >>> running: >>> >>> #top (from SSH) >>> >>> (exit with CTRL-C) >>> >>> >>> >>> -----Original Message----- >>> From: Kurt Buff [mailto:[email protected]] >>> Sent: Thursday, April 08, 2010 3:04 PM >>> To: NT System Admin Issues >>> Subject: Re: OTish: ESX 3.5 guest won't boot >>> >>> In line... >>> >>> On Thu, Apr 8, 2010 at 14:40, Klint Price <[email protected]> wrote: >>>> 1) I wouldn't expect a power on to work until you can get this command to >>>> work: >>>> >>>> vmkfstools -P /vmfs/volumes/esx2\:storage1/sus/sus.vmdk >>>> >>>> The host needs to be able to read from the disk. >>> >>> Reasonable. >>> >>>> 2) Do you have an additional non-production server on the same LUN >>>> that can be powered off, with an attempt to restart your current down >>>> server? Result? >>>> Will the 2nd non-production server power back on? >>> >>> Yes. It's acting in a similar way - I logged in, and it shut down >>> fine, but it won't power up now. Nor will a machine that I had >>> powered >>> >>>> 3) All things DR considered, can you schedule a reboot tonight? If >>>> so, you may want to consider re-seating the HBA and drives, clear >>>> dust (which can cause cards to overheat), and reboot. >>> >>> Gotcha. >>> >>> One last thing for the moment: I've been looking at the performance >>> chart for this box, and see that CPU utilization is hovering around >>> 90%. I've got one VM that seems pretty far out of line from its >>> normal CPU utilization (our Win2k TS server), and another that's a >>> bit higher than normal (our Win2k3 file/print server). >>> >>> I'm thinking of kicking the one person using the TS server off and >>> rebooting, and seeing what that does to the situation, before >>> downing the other machine. >>> >>> Kurt >>> >>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >>> >>> >>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
