All 0s UUID, PernixData and the AMIDEDOS Fix

Let me start off by saying this isn’t an issue directly with PernixData FVP.  This is a subsequent issue with PernixData FVP caused by Supermicro not putting a UUID on the motherboards I bought. Two problems for the price of one.

I ran across an issue with the three whitebox Supermicro boards that I purchased for my home lab. I was attempting to install PernixData FVP on them to do some testing, when I ran across a strange issue. After I installed the host extension VIB on all my machines, only one of them would show up in the PernixData tab in vCenter. And when I would reboot them or uninstall the host extension, one of the other ones would show up.

Given that it’s a simple VIB install command, I didn’t figure it was anything to do with the installation itself but I uninstalled it anyway and by uninstalling and paying very close attention, I found my issue right away. The host UUID of the system was all 0s.

uuid_pic1I opened up the ‘prnxcli’ on one of my other hosts and verified my guess. As you can see, both UUIDs are all 0s. This was playing hell with the FVP Management server and my guess is it didn’t know which host was which.

uuid_pic2I did some quick searching and found this KB article discussing the issue, but it didn’t give me much in the way of how to fix the problem other than to contact the manufacturer. Given that the system is running an American Megatrends Inc, BIOS, I did some quick searching around and found a utility that will auto generate a UUID and hopefully resolve the issue. Finding the download was kind of a pain so I improvised after I found a link to a Lenovo posting and then I found it on the Lenovo driver site. All you need is the AMIDEDOS.EXE file, nothing more so you can get it from the following BIOS download.   Just download this file and extract the executable. I put it on a DOS USB key that I formatted using Rufus.

uuid_pic3Then I just booted up my host to the USB key and ran the following command:

 amidedos.exe /su auto

According to the instruction file, this will auto generate a new UUID for the system. You should see a screen similar after it performs the change.

uuid_pic4I went ahead and booted up my host to see if the change took affect and it looks like it did!

uuid_pic5I went ahead and changed the UUID on the other two hosts and booted them all back up. When I got into vCenter, I noticed that the PernixData Management Server was still seeing strange SSDs from my hosts. I removed all three hosts from vCenter and re-added them, restarted the PernixData Management Server and now magically all the host SSDs showed up correctly when I went to add them to the Flash Cluster.

uuid_pic6All in all, this was a perfect storm which I seem very good at creating from time to time. As much as I cursed trying to figure it out at first, it was fun learning about something I’ve never ran across.

Getting the PernixData FVP Acceleration Policy from the CLI

When I was building out the PernixData/SnapMirror script, I was playing around with the ‘Set-PrnxAccelerationPolicy’ command. What I noticed that there wasn’t any ‘Get-PrnxAccelerationPolicy’. A quick tweet and I got response from the PernixData product management, Bala Narasimhan. He pointed me to a command that you can run that will give you some feedback and you can figure this out pretty easily. This command is only available within FVP 1.5.

The first thing we need to do is pull up the lab. I have two datastores and a VM that are being accelerated in both write-through and write-back to demonstrate the differences.

pernix_accel_cli_pic1We’re going to run the following commands to list out the policy. Per Bala, we’re not going to see ‘Write-Back’ or ‘Write-through’ in the output. We’ll see a number returned. The numbers represent the policy being applied.

pernix_accel_cli_pic2As you can see we’re getting the ‘cachePolicy’ value of 3 and of 7. These values represent:

3 – Write-Through

7 – Write-Back

Thanks again Bala for the quick help!

Automating NetApp SnapMirror and PernixData FVP Write-Back Caching v1.0

I wanted to toss up a script I’ve been working on in my lab that would automate the transition of SnapMirror volumes on a NetApp array from using Write Back caching with PernixData’s FVP, to Write Through so you can properly take snapshots of the underlying volumes for replication purposes. This is just a v1.0 script and I’m sure I’ll modify it more going forward but I wanted to give people a place to start.

Assumptions made:

  • You’re accelerating entire datastores and not individual VMs.
  • The naming schemes between LUNs in vCenter and Volumes on the NetApp Filer are close.


  • You’ll need the DataONTAP Powershell Toolkit 3.1 from NetApp. Its community driven but you’ll still need a NetApp login to download it. It should be free to sign up. Here’s a link to it.
  • You’ll need to do some credential and password building first, the instructions are in the comments of the script.
  • You’ll need to be running FVP version 1.5.

What this script does:

  • Pulls the SnapMirror information from a NetApp Controller, specifically Source and Destination information based on ‘Idle’ and ‘LagTimeTS’ status. The ‘LagTimeTS’ timer is adjustable so you can focus in on SnapMirrors that have a distinct schedule based on lag time and aren’t currently in a transferring state.
  • Takes the name of the volumes in question and passes them through to the PernixData Management Server for transitioning from Write Back to Write Through and waiting an adjustable amount of time for the volume to change to Write Through and cache to de-stage back to the array.
  • Performs a SnapMirrorUpdate of the same volumes originally pulled and waits for an adjustable amount of time for the snapshots to take place
  • Resets the datastores back into Write Back with 1 Network peer (adjustable).

Comments and suggestions are always welcomed. I’m always open to learning how to make it more efficient and I’m sure there are several ways to tackle this.

You can download the script from here.