Honestly, I have repetitively deployed DMPVV mutiple times in order to get it right.

1. You really need to make sure you have read Dell OpenManage Software Compatibility Matrix before installing any OM software because you need to upgrade the firmware for BIOS/iDrac/Lifecycle to their respective minimum requirement as stated in the guide.

2. DMPVC DOES NOT NEED to use a DHCP server

I even created a W2K8 R2 DHCP server, but found there is a place in menu for me to configurate the fix IP for the appliance.

3. DMPVC cannot start in vCenter saying some wired permission problem, things like Access Denied!

The problem is because I registered the vCenter using IP in DMPVV, but used host name when I login with vSphere client, after I changed hostname to IP, everything worked. Probably it’s my DNS not working properly, anyway, IP is fine for my case.

4. Connection Profile doesn’t work, then I found out you have to turn on Remote Enablement during the installation of OMSA on ESX.

The reason you see that error message about “OMSA is not installed” could be due to that when you installed the OMSA, you didn’t install it with -c option which installs the “Remote Enablement” component of OMSA. And our appliance talks to OMSA thought its remote enablement layer. Without successfully connect to OMSA, the iDrac connection will fail too as we correlate the correct iDrac IP with the server by getting the iDrac IP from OMSA first. Please reinstall the OMSA with –c option and that should solve your issue. Once you pass the connection test from the connection profile, please make sure to run inventory from the Job Queue by clicking the “Run Now”.

That indeed was the fix, and the -c is listed in the user guide for the command line, however there is no explanation in the user guide why it needs to be there, so I did not re-run the OMSA 6.4 installer. Perhaps the OMSA team could add the -c switch to the -x (for express) switch for OMSA, so that it is automatically included? Also according to the OMSA 6.4 install manual, if you run the -x switch it runs the express setup with all options included and ignores any other switches, apparently this is not true.

For OMSA 7.0

Run the following command to perform an express install with Remote Enablement parameters:
sh linux/supportscripts/srvadmin-install.sh -c -x

-c is for Remote Enablement
-x is for Express

Then start the applicable services by running the following command:
sh linux/supportscripts/srvadmin-services.sh start

5. License Disappeared

Sometimes after a reboot or DMPVV reset to factory default, license disappear, I have to re-deploy the whole thing again, well, the last successful re-install only took me 5 minutes as I have done it over 6 times.

6. CANNOT contact iDrac (SOLVED, but UNSOLVED for the time being)

My iDRAC subnet is on a separate switch, so COS Service Console obviously won’t work, this was by design as I want to physically separate all network segments, and it’s not routable. I knew in order for default DMPVC to work is to put COS and DRAC network on the same network segment which is NOT SECURE as far as I concern. Why doesn’t DMPVV give us an option to specify the subnet for iDrac and add another network adapter for this purpose?

During the research, I also found out by using Alt+F2, login as readonly with default admin password, then you can perform some network trouble shooting such as ping and tracepath.

Anyway, I still can’t figure out a way to route the traffic from DMPVC to iDrac via vCenter server without using a L3 router or firewall device. Is it possible to use route add on vCenter Windows server to redirect the DMPVV traffic to iDrac? If you know, please let me know.

So I was not able to test the firmware upgrade feature, but I am 100% sure it’s utilizing iDrac’s USC firmware updating feature to fetch firmware from ftp.dell.com and then perform the upgrade on the background, it’s the same as if you reboot the server and press F10 USC.

7. Service Temporarily Unavailable

DMPVC web server always crashes, probably due to I gave it 1GB (reduced from 3GB), after I changed to 2GB, it stopped crashing, but still loading the host page is extremely slow, around 2 minutes. Oh, DMPVV is a resource eater,taking up 2GB of ram fully and 100% CPU cycle when it’s connecting to the host.

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Apache/2.2.3 (CentOS) Server at xxx.xxx.xxx.xxx Port 443

8. Proxy to get firmware

This is the same issue as the above pt 6, see it’s going to bite back anyway, there is no direct connecting to Internet from within DMPVV, so you have to use a proxy server to download firmware, a better way would be adding a 3rd network adapter and connecting to your External port, hope this can be changed in the next release.

Finally, some good readings (total 3 parts) can be found on Virtual Life Style web site.

One of the coolest features I want to highlight is the PXE-less provisioning of the hypervisor to a physical server. This uses a combination of the Lifecycle Controller and iDRAC to deploy an installation ISO to the server. And since it is really tightly integrated with the VMware stack, the host is added to vCenter and configured using Host Profiles automatically, resulting in a true zero-touch deployment of a server. How cool!

In fact, there is a How to video regarding “Auto Discovery & Hypervisor Deployment – Dell Management Plug-In for VMware vCenter ”

One last word to add, I do think Dell Management Plug-In for VMware vCenter (DMPVV) is simply a proxy between ESX host and vCenter, still it should be made free as all the features of DMPVV can be achieved using different Dell server management products together. DMPVV is just a fancy toy that made all of them into a single product instead.

FYI, 12th generation servers such as R720/R620 doesn’t have to use OMSA as it it’s completely agent-less and no longer depends on OMSA agents within ESX hosts in order for DMPVV to work.