Steve Hiner's questions

I have a Cisco/Meraki MS225 switch with four SFP+ ports. I have a fiber optic module in one of those ports. All five of the DOM values are showing as in critical state. I'm suspicious that the thresholds are set incorrectly and that's at least part of the problem.

In the popup when hovering over the graph, you can see that it shows the high warning at zero degrees and high alarm at 3.1 degrees.

On the Cisco site (https://documentation.meraki.com/MS/Monitoring_and_Reporting/MS_Temperature_Thresholds), I find that the critical temperatures are well above the 57 degrees the module is currently at.

That makes me question all the other thresholds (though I don't know what would truly represent concerning values for those parameters yet). Those other thresholds have similarly odd values.

For instance, the transmit power:

The Low Warn and High Alarm are the same value and the Low Alarm and High Warn are the same value. Seems like something is seriously messed up, unless this is just a UI error in the Meraki Dashboard.

So, there are two questions:

• Are these thresholds held in the switch, in the Meraki Dashboard settings or in the fiber module itself?
• Wherever they are, can they be changed or reset and how?

I've been using PowerChute 4.3 network appliance on my ESXi host for a while now. I followed the instructions to download and install the appliance update to 4.4.1 this morning using the official tar.gz file. The update appeared to go well.

Now when I browse to powerchute:6547 it requests my login as usual. After I login the appliance issues a 302 redirect to localhost:6547/index.html. Obviously that doesn't work because localhost is my computer. If I try to browse to the appliance in a separate tab it just immediately redirects to localhost because I'm already logged in. I did try rebooting the appliance to see if that would help but it did not.

Any idea how to fix this or do I need to delete the appliance, install a fresh copy, configure it, and commit to never doing it by an in-place upgrade again no matter how easy it seems like it should be.

Edit: Setting up a new 4.4.1 appliance I notice that the configuration asks for a hostname. Maybe the original 4.3 has the hostname unset or set for 'localhost'. If I knew where that setting is held I could SSH into the vm and update that setting.

I have a Dell Poweredge R630 with 4 drives in a RAID. I'm not sure if it's RAID 10 or RAID 5 because I didn't order or set up the server originally and I'm just the default network admin, it's not my primary job. The server is running vSphere Essentials ESXi 6.7 and it hosts half a dozen VMs.

I use Altaro VM backup running in a VM on another host to backup this host as well as an ESXi 6.5 host. When I started backing up the VMs on this host I found that the backups would randomly fail. Any given night 2 or 3 of the 5 VMs I'm backing up would fail but not the same VMs each night. A couple weeks ago they started to always fail.

In working with Altaro support to find out why it was failing they found this in the Altaro logs:

2019/09/24 00:11:31.034: DISKLIB-LINK : "san://snapshot-155[Storage] VMName/[email protected]:[email protected]/XXX" : failed to open (Unknown error). 
2019/09/24 00:11:31.034: DISKLIB-CHAIN : "san://snapshot-155[Storage] VMName/[email protected]:[email protected]/XXX" : failed to open (Unknown error). 
2019/09/24 00:13:18.446: VixDiskLib: Detected DiskLib error 2338 (NBD_ERR_NETWORK_CONNECT). 
2019/09/24 00:13:18.446: VixDiskLib: VixDiskLib_Read: Read 437 sectors at 19619760 failed. Error 14009 (The server refused connection) (DiskLib error 2338: NBD_ERR_NETWORK_CONNECT) at 5235.

Their support says these log entries, I assume the last line in particular, came directly from the host.

Not being an ESXi expert I'm not totally sure which log files to look at in ESXi to try to figure out what is going wrong, to confirm it's a drive problem on the host, and to determine which drive it is so I can replace it. So far the vCenter is not raising any alerts or warnings about a drive problem and the host is not indicating a problem with the array.

Another data point: Most of these VMs are running Windows. Each of those is running Windows backup internally to a separate drive and those all complete with no errors. I find it interesting that Windows is able to backup its drives from inside the VM but there is a read error when ESXi is making the backup from outside.

I'm moving my Small Business Server 2000 to newer hardware. I used Acronis TrueImage to create an image of the partitions on the current 250GB IDE drive and restored the images to partitions on a 750GB SATA drive. The new mainboard is an Intel D915GEV.

When I boot the system it makes it part way through then BSODs with:

STOP: 0x0000007B INACCESSIBLE_BOOT_DEVICE

If I boot in safe mode I can see that it's loading lots of drivers and the BSOD happens when it tries to switch into the graphical boot. That means the drive isn't totally inaccessible.

I'm currently operating under the theory that this is caused by the fact that my original Server 2000 doesn't have drivers for the SATA controller on the new motherboard. The early part of the boot process must be handled by the BIOS and it only fails when Windows tries to take over the file access.

I know you can use F6 during a fresh install to add drivers but that doesn't seem to help me since I'm not installing fresh. Even so, I have not been able to track down SATA drivers for this board even though I have found all the other drivers on Intel's site. It appears that there aren't specific drivers for the SATA controller.

What's the best way to handle this?

I made sure I can always go back to the old hardware but I'd really like to get this running on the newer hardware. The hardware is pretty similar - it's not like I'm doing a major hardware upgrade, it's even the same processor and this mainboard is really similar to one this install used to run on. (The old hardware failed so I had to quickly move to new hardware, now I'm trying to move it back to the replacement hardware Intel sent as a warranty replacement.)