I would like to migrate the our on premise HiveManager (VM) to the new server cluster that we are getting in. I wanted to have console access (via CentOS) just in case something didn't work right but none of my passwords are working. Would anyone happen to know if console access is restricted to Aerohive Support only? Should I know anything about this migration process before it happens? Any information would be helpful. If I can migrate it by exporting a template then I'm not worried, but if I need to access the filesystem I don't know how I would go about this (as I am unable to log in).
You don't need console access for HM NG VA. NG VA leverages VMware tools. If you have vSphere Essentials, you can configure IP/DNS/hostname for your NG VA using vSphere.
We are actually migrating our HiveManager from ESXi 5.5 (Free Hypervisor) to vSphere 6. Admittedly, I am a little new to migrating VMs and I am just unsure if I would need to have console access to the HiveManager.
I was thinking of moving to NG, but I figured one move at a time would be best.
You are confusing things a bit. You do have console access to HM; that is how you initially configure it. You do not have access to the base OS (CentOS). That is only available to Aerohive engineers. But you do not need access to the base OS in order to migrate.
Migrating a VM can be a very easy process depending upon your setup. And depending upon how you do it, it doesn't even require interaction with the OS of the VM. For example, you would shut down the VM; download and copy the VM files to the new destination; and import the vmx. It really just depends upon how your environment is setup.
It can be a little more complicated if you are migrating HM to new hardware, which is what I'm about to do. Even in this situation, there is no need for access to the base OS. It's just a matter of backing up the database, shutting down the original HM, powering on the new HM with the same host name and IP configuration, restoring the database from the backup that was just taken, and then having support re-initialize the licenses. None of these steps require access to the base OS.
If you are doing a backup/restore, as opposed to just migrating the VM, be aware that if you do a "full backup for upgrades" which includes all the historical reporting and alarm data, the backup and restore process can take hours - this is because the database contents are exported to an XML format and then re-imported into the new system and there are potentially millions of records.
If you are not interested in retaining the historical data, do a "configuration only" backup. The restore then typically takes no more than 15 minutes.