srwsol's Posts

Has anyone who has full maintenance opened an incident about this to VMWare?  Unfortunately I have just the basic essentials kit license, so it would cost me $299 to open an incident.  If somebod... See more...
Has anyone who has full maintenance opened an incident about this to VMWare?  Unfortunately I have just the basic essentials kit license, so it would cost me $299 to open an incident.  If somebody in this thread who is having this problem can open an incident without charge I highly encourage you to do so. Scott W.
Another aspect of this problem, I think, is that you can no longer assign a USB controller as a passthrough device.  It shows in the list of eligible devices and both the vcenter 5.1 web gui and ... See more...
Another aspect of this problem, I think, is that you can no longer assign a USB controller as a passthrough device.  It shows in the list of eligible devices and both the vcenter 5.1 web gui and the vsphere client allow you to select a USB controller as a passthrough device, but when you reboot ESXi the USB controller is still assigned to ESXi as if you had never selected it.  If you select other devices at the same time they are correctly marked as passthrough devices after the reboot so this isn't a user interface problem.  During the limited time I played with it, on an Intel DQ77KB motherboard, I did notice that there were more devices listed as eligible for passthrough, and the description of what each device is was better (some devices on this motherboard under 5.0u1 showed as "unknown").
I'm pretty sure the problem is with the bios and GPT boot disks based on my experience in being able to get it to boot on its own after installing with the mbr option.  I do have bios 0043 instal... See more...
I'm pretty sure the problem is with the bios and GPT boot disks based on my experience in being able to get it to boot on its own after installing with the mbr option.  I do have bios 0043 installed as I just put this machine together a couple of days ago and as part of that I installed the latest bios.  Also, I have UEFI disabled, although I was going to try enabling it if the mbr change didn't work.
Looks like the problem is that the DQ77KB bios has problems with booting from GPT partitions.  I reinstalled ESXi and hit shift-O at the install prompt and typed in  "formatwithmbr" as an install... See more...
Looks like the problem is that the DQ77KB bios has problems with booting from GPT partitions.  I reinstalled ESXi and hit shift-O at the install prompt and typed in  "formatwithmbr" as an install option, and now it boots fine.  I'll see if there is a way to report this problem to Intel.
I'm having this exact same problem.  I just installed ESXi 5 on an Intel DQ77KB motherboard with a 1tb SATA drive and it won't boot normally (the bios says no bootable device found), but if I hit... See more...
I'm having this exact same problem.  I just installed ESXi 5 on an Intel DQ77KB motherboard with a 1tb SATA drive and it won't boot normally (the bios says no bootable device found), but if I hit F10 during the boot process and pick the drive it boots just fine.  I tried disabling all the other possible boot devices in the bios so that this is the only device available and I still get the same results.  I also tried putting the SATA drive on the other port on the motherboard, but with the same results.   I've only got two things left to try.  First, I did install Windows 7 on the SATA drive first so that I could configure the Intel AMT stuff first (you have to do that from Windows), and then I reused that drive for ESXi.  I'm wondering if by having it install over an old Windows installation that something odd happened to the MBR during the install.  My only other option is to try UEFI.  I had read that there were issues with some motherboards and ESXi that would require UEFI boot.  However, none of those issues ever talked about it booting with MBR only if you picked it from the boot screen.
This problem still exists in ESXi 5.  Also it looks like alarm conditions that go from green to red work without the page being updated, but when the alarm condition goes from red to green you ge... See more...
This problem still exists in ESXi 5.  Also it looks like alarm conditions that go from green to red work without the page being updated, but when the alarm condition goes from red to green you get no notification unless the page gets updated first.  I tested this with the redundant power supply.  If the page isn't up or isn't autorefreshing and I pull the plug on one of the power supplies I get an email.  However, if I put the plug back in I don't get an email unless the page gets refreshed to reflect the changed status.  I tried pulling the plug, got the email, and then let the page quit updating automatically.  I then put the plug back in and left everything alone overnight.  No email.  Next morning when I manually refreshed the page, bingo instant email about an event that happend the previous night.  How lame. Does anyone know if there is a CLI command that does what the clicking the update button does on the hardware page, either directed at the host itself or through vcenter?  I was looking for it and so far I haven't been able to find it.   If I do ever find it then I'll just write a script on a timer that does it every few minutes indefinately. I can't for the life of me understand why they can't, or won't, fix this.  It's crazy. Scott W.
Now that it's officially supported to have an authorized_keys file for scripts to access ESXi5 without needing an SSH password, does anyone know if this file is backed up when you do a configurat... See more...
Now that it's officially supported to have an authorized_keys file for scripts to access ESXi5 without needing an SSH password, does anyone know if this file is backed up when you do a configuration backup?  Prior to this I had all the key files on one of the datastores and backed them up that way.  Was just curious if I need to do the same with the authorized_keys file. Scott W.
Andy: ".any alarm triggered for hardware issue needs to be reset manually(which  will trigger "Refreshing CIM data"! I test and can confirm that)" From my testing I didn't have to m... See more...
Andy: ".any alarm triggered for hardware issue needs to be reset manually(which  will trigger "Refreshing CIM data"! I test and can confirm that)" From my testing I didn't have to manually reset the alarm.  All that was necessary was to bring up the page.  This is so silly in that all they have to do is have vcenter server internally do the same thing that happens when you bring up the health monitoring page on a regular, and hopefully user configurable, basis whether or not anyone is logged on and viewing the page.  It really is that simple I think. I'm also looking through the vcenter cli to see if there is a way to cause this to happen in a script, but so far the only hardware status refresh command I see only causes a refresh on the ESXi host, not on vCenter; so the alarm condition in vcenter still isn't cleared by it. Scott W.
I've done a little more testing and what it looks like is happening is that alarms where the status goes from green to red work, although it can take about 15 minutes before you get an email afte... See more...
I've done a little more testing and what it looks like is happening is that alarms where the status goes from green to red work, although it can take about 15 minutes before you get an email after the alarm condition occurs.  However, when the condition is resolved you never get any notification unless you have the hardware status page active in the vsphere client and it autorefreshes. I was testing by pulling the power cord from one of the redundant power supplies.   I have the alarms setup to email me when a hardware status change occurs.  When I pull the cord and the status changes from green to red I get an email within 15 minutes, even if I don't have the vsphere client logged in to vcenter.  However, when I put put the cord back I never get a notification that the alarm condition is cleared UNLESS I have the vsphere client logged into vcenter with the hardware status page up and autorefresh set.  I pulled the cord, waited for the alarm and then put the cord back and left it that way overnight.  The next morning I logged into vcenter via the vsphere client and brough up the hardware health page.  At first the alarm condition was still showing from the previous night that one of the power supplies was down.  After a few seconds the status changed from red to green and at that point I got an email saying that the alarm condition had cleared, a full 10 hours after the actual condition has cleared. What appears to be happening is that vcenter isn't properly polling the host for hardware status changes and that unless you have the hardware status page up it will not reflect changes of hardware status from red to green, but apparently it is polling for changes from green to red.    Now, I've only tested this with the power supply alert as I don't have an easy way to cause some of the other hardware faults. This really needs to be fixed.
I just started experimenting with this and I see the same behavior.  I set some alarms to email me when a hardware failure occurs, and it looks like the email only happens if you refresh the page... See more...
I just started experimenting with this and I see the same behavior.  I set some alarms to email me when a hardware failure occurs, and it looks like the email only happens if you refresh the page in vsphere 5 that shows the hardware sensors.  It's as if there is no polling of the hardware being done, and instead all the alarms are only checked when the page is refreshed.  I pulled the power cord on one of the power supplies on the host and nothing happened until I refreshed the vsphere page that was logged into vcenter.   I hope I'm wrong about this, because if not and the alarm triggers are tied to to the page being refreshed rather than the hardware being polled, then this whole alarm thing is completely worthless. I'm running ESXi 5.0u1 with the patch that just came out yesterday, and the latest version of the vcenter appliance VM. Scott W.