good morning!
i woke up this morning to an inaccessible boot device on an important VM server. I am very new to VM's and inherited the servers when an employee left the company.
Our environment is as follows:
Hardware/OS:
Dell 6650 running Linux (Fedora I think) (see edits) and VMWare 2.5.4 ESX.
The OS of the VM is Windows 2000 Server.
This is not a SAN setup.
Recent Activity:
i upgraded the VMWare software from 5.2.4 (see edits) to 2.5.4 yesterday morning. The VM ran great all day yesterday and last night i woke up to this. Not sure what caused the computer to restart (if anything did) as i cannot get into Windows to research.
Symptoms:
when i start the VM i get the BSOD with inaccessing boot device. As expected, this continues even in safe mode.
Can you please lead me into the right direction to bring this server back online. I really appreciate all you can do for me in this time of need.
*edits
VMWare version was 2.5.2 to 2.5.4 not 5.2.4
The Linux Fedora part appears to not be true. i misunderstood how VMware was to be setup. I thought you had to lay an OS before you installed VMware... that is showing to not be true.
We are running ESX Server
Message was edited by:
NNatic
Message was edited by:
NNatic
Message was edited by:
NNatic
I am confused a bit here
Our environment is as follows:
Hardware/OS:
Dell 6650 running Linux (Fedora I think) and VMWare
2.5.4.
The OS of the VM is Windows 2000 Server.
This is not a SAN setup.
2.5.4 ESX Right? Then there is no Fedora Core - ESX is the OS
Recent Activity:
i upgraded the VMWare software from 5.2.4 to 2.5.4
yesterday morning. The VM ran great all day
yesterday and last night i woke up to this. Not sure
what caused the computer to restart (if anything did)
as i cannot get into Windows to research.
5.2.4 to 2.5.4 - huh?
maybe it is me that is confused
i thought that Linux had to be the OS then you lay VMware on top... if that is not the case then it is just VMware with all Windows OS's
I apoligize for the confusion.
Hope it makes sense now.
The VMware version was 2.2.4 and has been upgraded to 2.5.4 for DST compatibility.
Message was edited by:
NNatic
Go into the MUI (web interface for ESX), go to configure hardware for that VM. Look at the SCSI controller, is it buslogic or lsilogic? If buslogic, change it to LSI or visa-versa. Then try to power on again. Probably just the controller type changed.
Unfortunately this still does not help me - there never was a Version of ESX 2.2.4
Let me see if I can digest what you are saying and determine what you have done.
How are you determining what the previous version was?
Tell me about this upgrade - what process did you use, did you follow any documents?
Message was edited by:
BrianG
3rd time's a charm?
ha ha
2.5.2 to 2.5.4
i put the CD of 2.5.4 in and selected upgrade.
Sorry for the slowness this morning. Youll have to forgive me
I changed it from buslogic and got a black screen saying something along the lines of the computer could not be started... if you would like a detailed error, let me know and i will be more than happy to post it.
I tried every combination of bus logic and LSI none, virtual, and physical with no success.
I changed it back to buslogic and I am getting the BSOD again.
i will see if i can do that tonight. unfortunately we have many users working throughout the weekend so i will need to wait until then as we have a number of needed servers on this VM.
If anyone has anything else to attempt in the meantime i am open for suggestions
I missed the fact that you have other VMs running on this server.
I do not anticipate then that the patch will help this VM, but in order to get where you wanted to be (DST Ready) you will need to patch as noted above.
So this is the only VM that is having problems, huh?
Perhaps the vmdk has become corrupt. A couple of quick things to try.
Rebuild the VM and point at this existing vmdk file.
remove this vmdk from this VM and attach it to a functioning VM as another HDD, you can then look around to see if data is in tact. Do you have a backup of this vmdk? A full backup of this W2K guest? Perhaps a restore is in order.
unfortunately we do not have a backup of this vm.
I pointed another VM to the .dsk file with no success. is that what you referring to?
If not, what is a vmdk file and where are they stored by default.
If you have recovery console installed you can try to stop non-essential services and see if you can find the one that may be causing the problem. We've had problems with IBM Director 4.x agents before.
Alternatively you can run an in-place upgrade on the system. My bet is that a DLL is wrong. VMware has done a pretty poor job making sure the right files are in the right places after VMware tools upgrades. I always have to uninstall the existing VMware tools on certain systems before installing new versions. We also discovered that the msvcrt.dll was the wrong version on some systems and had to be replaced.
Anyway,
1. Backup (clone or export) the vm before you do any more damage
2. Open an SR with vmware.
3. Use recovery console and/or BartPE or WinPE to disable services. First record the status of all services (pain). Then disable all non-essentials (another pain). If that works enable them one at a time (really big pain) to discover what's causing it to blow up
4. Use in-place upgrade to fix the issue. http://support.microsoft.com/kb/292175 This should leave your apps intact and you'll only have to install patches.
" unfortunately we do not have a backup of this vm"
go to www.esXpress.com and download their free version of backups for VI3. This way at least you'll have backups in case you need them, and the software is free.
RESOLVED!!!
i mounted the dsk file to another running vm and looked at the data on it to determine what we caould salvage from the image as we built the new server out... and then i saw it... 0 KB Free! UGGGGGGGGHHHHHHH seems like someone forgot to monitor this server for drive space and we hit the end of the road on her.
Thanks a TON for everyone's time and help.
Please see the last post from me for a rough explanation of what i did.
It works for me also ! I had the same problem... solved now,
Thanks guys..! :smileygrin:
Rgds.
Alejandro G.