VMware Cloud Community
AramiS_1970
Contributor
Contributor
‎07-22-2009 03:43 AM

ESX 4 boot fails at vsd-mount

Hi,

we have two ESX4 hosts connected to an IBM DS3400 storage system.

With FC cables plugged in both the ESX stops booting at vsd-mount.

With FC cables pulgged out, the ESX boot is ok.

After the ESX is up and running, if i plug the fc cables i can see and succesfully work with my storage LUNS, as well starting al VM.

At any reboot i have to unplug fc cables to allows esx to came up! The problem is the same on both servers.

The problem happens in all cases with or without any lun presented to the esx.

Any ideas?

Thanks.

0 Kudos
31 Replies
dillonrw
Contributor
Contributor
‎10-19-2009 09:37 AM

I am going through this same vsd-mount non sense right now with vmware while trying to boot from SAN. This is OBVIOUSLY a problem that they don't want to deal with. They of course are pushing the blame on an "environmental" issue.. Right! Ok, let me get this straight, it boots 3.5.4 perfectly fine, but when it reboots with 4.0 is bounces me to a busy box? I am really about to get more people involved, while it will be ugly, I'll get an answer one way or another.

0 Kudos
edlaw1974
Contributor
Contributor
‎10-21-2009 07:15 AM

"Then I cleaned out what I could find of 4.0and upgraded once more to 4."

Can you explain how you cleaned out 4.0. It looks like this is what I will have to do as well. Does it wipe out the existing datastore if it is one the same disk?

Thanks in advance.

0 Kudos
Triclaw
Contributor
Contributor
‎10-21-2009 07:44 AM

Edit: had to take the Brackets out and replace them by underscore, misinterpreted by HTTP Code...sorry.

-

Hi edlaw, you keep all VMs and Datastore intact, provided that ESX 3.5 can read all your VMs. So if you already have some VMv7 I don't know what willl happen.

I cleaned out the /boot Folder/Partition as it had insufficient space. You can check the grub.conf for what points to Version 4 and what to Version 3.5. Essentially all Files containing the Version "2.6.18-128" where related to Version 4 and all Files with Version "2.4.21-57" were Version 3.5. I edited the grub.conf by added Hashes (#) before each line with Version. That would prevent the old Version 4 to start ever again (don't know if that was necessary. Then I deleted from my Datastore (it was on my first, but that is based on the config) the Folder esxconsole-_long number_

Summary:

  • delete 2.6 Files from the /boot directory.Have grub.conf help you locate all the files that are from Version 4.

  • edit the grub.conf to # in front of each line that has Version 4

  • delete the "esxconsole-_0123456789abcdefg..._" folder from one of the Datastores.

The Host upgrade Utility that is installed with the vSphere Client will recognize the Server as 3.5. After the above steps the upgrade to Version 4 will succeed once again. The first time I slowly learned by doing how it works and what i need to delete, so don't panic even if the install fails. Boot again in 3.5 and start over, it will still work even after a failed upgrade, as it basically archives the 3.5 rather than deleting it.

After the Upgrade, some VMs were showing as Unknown, and I had to manually had them again through the Datastore Browser, but that is not really a big deal compared to loosing all Data.

Tip: The Fix mentioned earlier seems to help. After the troubles I had I installed all patch bundles i could find. 200906 & 200907 & 200909. Download them as zip, load the zip into the Filesystem and with "esxupdate --bundle -path to zip- update" all patches install easily. After a reboot everything works like a charm.

Enjoy!

T.

0 Kudos
edlaw1974
Contributor
Contributor
‎10-21-2009 08:41 AM

Triclaw,

Thank you for taking the time to explain all of this. I have just cleared out all files with version 2..*. That did give me sufficient space on /boot to perform the upgrade. It is in the process and hopefully I won't lose any data. Thanks again!

Regards,

Ed

0 Kudos
edlaw1974
Contributor
Contributor
‎10-22-2009 07:32 AM

Triclaw,

Thanks for the advice. This worked perfectly. I was worried since the ESX install and datastore were on the same disk but following the steps you detailed worked out and there are no issues. Thanks again!

-Ed

0 Kudos
Triclaw
Contributor
Contributor
‎10-22-2009 07:35 AM

Hi Ed, great news! Good to hear.

Thanks for the update Smiley Happy

T.

0 Kudos
athlon_crazy
Virtuoso
Virtuoso
‎11-03-2009 08:10 AM

OMG, I fall into this same issue. Any workaround for ESX 4.0 fresh install?

vcbMC-1.0.6 Beta

vcbMC-1.0.7 Lite

http://www.no-x.org
0 Kudos
Deeptree
Contributor
Contributor
‎11-04-2009 07:16 AM

Hi all. Just a thought, but if you are only using your external arrays for storage of VMs, and not booting from them for ESX, why don't you just disable the option ROM on the HBAs? Perhaps I am just misunderstanding the question, but this is my first thought.

0 Kudos
Goliath222
Contributor
Contributor
‎11-12-2009 05:10 AM

Hi,

we experienced the same problem with two newly installed ESX Servers, actually patched already. Storage comes from a Netapp CLuster. Our solution was to set the ALUA option on cluster side and configure the ESX Host Utilitys 5.1 like written here :

http://blogs.netapp.com/storage_nuts_n_bolts/2009/08/vsphere-upgrading-from-non-alua-to-alua.html

Regards

Oliver.

0 Kudos
phocksx
Contributor
Contributor
‎08-18-2010 02:58 AM

I can confirm, the second article worked for me.

josh

0 Kudos
lindp
Contributor
Contributor
‎09-20-2010 12:59 AM

Thank you for this! I just had to swap a faulty SCSI card on a Dell PE710 running vSphere 4.1 and all is well after following the instructions on this site:

ESX fails to boot when the disk containing the datastore with esxconsole.vmdk is detected as a snaps...

Regards,

Pelle Smiley Happy

0 Kudos