Now the good news…
I’m finally back up and running — A great relief, after a very tough couple of days.
Thanks to you all for the ideas and feedback. I really do appreciate the assistance.
I’m still not sure why things changed after the power outage, but I found a work around that works for me, so I’m happy with that.
I came across some suggestions that UEFI booting may may cause issue with the ESXi startup process. I originally did not think that this was my issue, as I believe that I was booting in UEFI mode prior to problems seen after the power outage. When I first tried disabling UEFI boot and using «Legacy» booting I could not get it to boot from the USB thumb drive, it showed a message on the display saying that it was trying to boot from USB, but it would not boot.
I tried adding a MBR partition to the USB drive but still could not get it to boot when in Legacy boot mode. I also tried using the SHIFT-O «runweasel formatwithmbr» boot option to the ESXi installer, but I could not get this to resolve my issue.
As I couldn’t get the ESXi 7.0 or 6.7 installer to boot from USB when in Legacy Boot mode, my next thought was to try booting from a DVD rather than USB. So I burned the ESXi 7.0b iso to a DVD, updated the boot order in BIOS and was able to boot the ESXi installer. The ESXi Installer completed (not failing at the «Initializing InitVMKernel…VMKAcpi_LateInit» step as it did when running in UEFI boot mode from a USB thumb drive).
The next challenge was to install the ESXi 7.0b onto the target boot media. I was hoping that this could be a 16GB USB thumb drive (as I was using prior to the power outage), however it would start loading the required data on the USB thumb drive but got stuck and never completed (it did this on several times, on multiple USB drives). So I tried using a USB hard drive as the target (rather than a USB Flash/Thumb Drive). The data transfer to the USB hard drive worked, and I was able to boot from the USB hard drive in Legacy boot mode. I finally had a working ESXi 7.0b server.
I found that I could access the Datastore on the internal SSD Drive via the web interface to the running ESXi hypervisor, however none of my hypervisor configuration was available (e.g. VM and network configurations, etc.). Luckily I had a backup of the /bootbank/state.tgz file that I used to restore the ESXi hypervisor configuration (via ssh, rcp and tar). Two of the three VMs stored on the internal SSD worked without an issue. The third VM apparently had a corrupted VM disk (.vmdk file) which could not be loaded. Luckily I had a recent backup of the .vmdk file, so this was easily sorted by uploading backup .vmdk file via the ESXi web interface.
Main take away lessons? The importance of a UPS and a regular backup schedule. I did have a UPS but regrettably had not yet got around to connecting this server. Server now connected to UPS, now need to invest some time to setup a UPS signal distribution and auto shutdown system, probably using something like NUT (Network UPS Tools).
Hopefully this may be of assistance to others who experience similar issues. Thanks for the help of all.
Was this post helpful?
thumb_up
thumb_down
If your machine is running out of vmware esxi fatal error 10 resources, this guide may help.
Approved
The software to fix your PC is just a click away — download it now.
I ran into a problem assuming 2 days. I am trying to install VShere 6.0 / 5.5 / 5.0. But I am struggling with this. This is an error
Error loading /s.v00
Fatal error: ten resources shortage
My system configuration raid is that I make three arrays, I configured RAID 1 in addition to RAID 5
Hello men of all ages (and girls),
Just wanted to inform you that you are getting “Internet error /tools.t00 Fatal error: 10 of (resources exhausted)” when you try to run VMware ESXi 5.5 hypervisor on Cisco UCS C240 M3 SFF server – rack mountable with some graphical processors. Follow these steps to customize it:
1. Go to the system (press BIOS F2)
2. PCI Configuration> MMCFG
3. Change the corresponding value from Auto 2 to Go
4. Change the memory value associated with I / O displayed over 4G. You can activate Enabled
5. And re-register each of our systems.
6. The installation is complete.
I hope that in a few days you will solve this problem yourself with the help of my experienced friends from Cisco, not with me 🠙 ‚
Apparently the error still cannot be reproduced on the same system, without the GPU I already have, or on ESXi 5.1. Cisco told me that when it comes to VMware, I hope they will work on it and also create a favorite way to make systems work. Role = “main”>
When
Error loading /tools.t00 < br> Compressed MD5: 39916ab4eb3b835daec309b235fcbc3b
Unpacked MD5: 0000000000000000000000000000000
Fatal error: 10 (no resources)
Error / loading tools.t00
Compressed MD5: Uncompressed 00000000000000000000000000000000
MD5: 00000000000000000000000000000000
Fatal error: 15 (not found)
< br>This issue is often caused by Thunderbolt controller, Which is a new component in these NUC6i7KYK and therefore only the Skull Canyon NUC is affected. Any problems can be resolved by temporarily disabling the Thunderbolt controller during installation.
How to safely install ESXi 6.0 on NUC6i7KYK:
- Create a very bootable USB installer using Rufus (Howto: Bootable ESXi Installer Flash USB Drive) and connect it to the NUC.
- Power on the NUC and press F2 to open the Intel Visual BIOS.
- Go to Advanced> Peripherals> Onboard Peripherals and disable the Thunderbolt controller
- Install ESXi
- Restart the NUC, bring up the BIOS and re-enable the Thunderbolt controller.
The NUC is running the unchanged ESXi 6.0 update option, which is combined with the following:
- Network card I219-LM (PCI-ID: 8086: 15b7)
- NVMe Controller (The NVMe driver that replaces each of our AHCI drivers is included in the entire ESXi image. Packages like xahci are not required)
Complementlinen notes:
- SD-Dos slots do not work with ESXi
- I was unable to test the Thunderbolt port. (Are there TB v3 devices in the home market?)
- If you need additional network adapters, it is best to use a USB 3.0 NIC with William Lam’s vghetto-ax88179 driver.
We had a good week of Hangaround email discussing the bug, chaired by Raymond Hu. With VMware employee William Lam (actually Ghetto) and a terrific new engineer in the background, Bren Stan (TinkerTry) and Ollie Salonen (NUC blog). William Lam also developed a solution with several improved recommended BIOS settings: ESXi on the new Intel NUC Skull Canyon. It’s great to see that we have good people who need support over the weekend, but they don’t work for the company.
When your site tries to install VMware, multiple esxi. The latest Intel NUC Skull Canyon (NUC6i7KYK) 0 installation fails with one of the following error messages:
Approved
The ASR Pro repair tool is the solution for a Windows PC that’s running slowly, has registry issues, or is infected with malware. This powerful and easy-to-use tool can quickly diagnose and fix your PC, increasing performance, optimizing memory, and improving security in the process. Don’t suffer from a sluggish computer any longer — try ASR Pro today!
Internet Error /tools.t00
Compressed MD5: 39916ab4eb3b835daec309b235fcbc3b
Unpacked MD5: 0000000000000000000000000000000
Neustranimation error: 10 (resource related output)
These complications are caused by the Thunderbolt controller, which is a new part of the NUC6i7KYK, and therefore the Skull Canyon NUC is actually tampered with. You can also resolve the issue by temporarily disabling the Thunderbolt controller during installation.
We’ve had an excellent email discussion of the bug every week, chaired by Raymond Hu. With VMware contributor William Lam (actually Ghetto) and therefore the background engineer, Braren Paul (TinkerTry) and Ollie Salonen (NUC blog). William Lam also wrote about a solution with other recommended BIOS settings: ESXi on Intel’s new NUC Skull Canyon platform. It’s very nice to see that we certainly have smart people who can bring unnecessary things that don’t come.Owned by a company to work on weekends.
-
#1
Long-time lurker.
Recently installed ESXi 6.7u1 and the monitoring seems funky. The monitor tabs claim to show a max of a hour, but when I sign in they show between 5 and 15 minutes on the VMs and less on the host. The host monitor will grow up to ~15 minutes and then truncate to 0. I’ve never seen a hours history.
ESXi standalone, booting off USB, swap on (ssd) datastore, on evaluation license.
Service vpxa set as Start/Stop w Host but it looks like it isn’t running on login but then starts.
/var/lib/vmware/hostd/stats/hostAgentStats-20.stats accumulation file is present (although as they don’t use rrd who knows what the hell is in it)
Is this expected or because I haven’t poked it with vCenter?
-
#2
I’m seen this before too (in 6.0 and 6.5, its not specific to 6.7).
I think ESXi has attempted to optimize one of the Manage > System > Advanced Settings for you and that reduction in log size / minutes / whatever it is => the cause.
Personally, I find all 60 minutes of the Performance Monitor to be relatively worthless, so I didn’t put more than a couple minutes into trying to figure out the issue. A clean install eventually remedied it (if memory serves).
-
#3
Possibly fixed in 6.7 U3
You might intermittently stop seeing performance charts of ESXi hosts in the embedded VMware Host Client or any web-based application that connects to the vCenter Server system, including the vSphere Client and vSphere Web Client. An internal issue causes hostd to delete available performance counters information for some ESXi hosts.
-
#4
I wouldn’t be able to comment on such … yet …
argh
-
#5
Confirmed fixed in 6.7u3: both host and vms now show an hour of monitor data.
Best of luck with your page allocation — crashed thumb drive?
-
#6
Confirmed fixed in 6.7u3: both host and vms now show an hour of monitor data.
- Thanks for the follow up — I’m still not sure this was a bug per se, I think that ESXi simply optimizes resource allocation for monitoring purposes — but that is just a guess.
- I had encountered it myself previously, but it must have been 1 year+ ago and I don’t recall it being persistent.
- BTW — you mention vxpa in your original post, but I bet it is the vmsyslogd service and not vxpa as I killed that service and the monitor keep chugging along. (just wanted to add that)
Best of luck with your page allocation — crashed thumb drive?
- I wish it was something so easily remedied and thanks for the kind words.
- I added a link to the issue below — which to be honest I don’t fully understand — but I do know that:
- 6.7U2 + Optane 900p as boot drive & UEFI = no issue
- 6.7U3 (clean install) + Optane 900p as boot drive & LEGACY or UEFI = no dice
- 6.7U3 (clean install) + USB drive & LEGACY = no issue
- But I refuse to boot off USB, if only because I haven’t pulled the servers in many months to service anything and it is a complete PITA as they are mounted vertically, stacked against the wall. I’m OCD so I’d have to put the USB drive on the motherboard header LOL, so I’ll flip back to 6.7U2.
- Seems like there are always vmware gremlins out there to surprise you with upgrades and what not (personal experience = fail rate > success rate).
Ack by vmware, but not advertised as a known bug with release notes. OK fine, not like I would have checked anyway. esxi cannot boot after updating to 6.7 u3! how … |VMware Communities
We’ve found the bug and are testing a fix.
Booting in legacy BIOS mode is the easiest workaround. However I realize some of you have systems that won’t boot in that mode for one reason or another.
You might consider reinstalling 6.7u2, using the option to preserve VMFS volumes on the disk. That’s the next most straightforward solution for now, though obviously there is some pain in that…
-
#7
I’m also in the «page allocation…out of resources» camp with 6.7u3 grrr
I only have UEFI boot on my home server, so can’t do legacy boot even if I wanted to
-
#8
I’m also in the «page allocation…out of resources» camp with 6.7u3 grrr
I only have UEFI boot on my home server, so can’t do legacy boot even if I wanted to![:(]( "Frown :(")
- I hate it for you, but it isn’t as lonely in this boat now.
- If I read that workaround correctly part of it was to disable VT-d
- I’ve never purported to know as much as the average STH member, but isn’t that sort of like saying:
- If I read that workaround correctly part of it was to disable VT-d
- vmware: Here is your type 1 hypervisor, and it relies on various technologies to best balance virtualization workloads / performance, the most important being Intel VT-d, but by the way, you have to turn that off with our freshest release.
- svtkobra7: I got your secure boot right here … a miniature schnauzer and .300 AAC Blackout = all the security I need … what’s next ice cream made with no milk?
- vmware: Also, we do hope that you had the intuition to search for this issue in advance, as we definitely made no note of the bug, but in our own words do acknowledge «some pain in that…»
- svtkobra7: Sends vicious attack schnauzer to do his thing.
[ as frustrated as you … to the point I’m creating hypothetical conversations LOL ]
If you happen to stubble on a resolution, would you be kind enough to post it here? I’ll do the same of course.
NB: jk about .300
-
#10
It may work, if you can get the damned thing to install in the first place without breaking anything else in the process, but it’s a kludge at best, VMware need to do better than that and stop treating folks like their beta testers