I recently had to move all resources under two vCenter Servers to two different vCenter Servers. Then retire the source vCenter Servers. Both source vCenter Servers were in the same SSO domain. Fortunately, the source did not have many hosts and VMs and I wanted to bring over as much as I could.
I wanted to do my best not to leave anything behind at the destination vCenter Server. Most are obvious in my list below, but some may be easily forgotten if not used often. Below is a list of what I moved over and other settings to note in case moving to a completely new vCenter Server. A few have export/import wizards in vCenter and can of course be scripted for several others.
- vDS – export/import
- Host profiles – export/import
- Customization specification – export/import
- Custom attributes – output in RVTools
- Folders – output in RVTools
- vCenter Settings – SMTP, database retention policy, etc
- Alarms – custom/edited alarms
- vCenter Server License
- Cluster settings – HA, DRS, and EVC
- Datastore clusters
- Content libraries
- Scheduled tasks
There are some third party apps to keep in mind. Make sure to reconfigure backups to point to the new vCenter Server. Third party plug-ins will need to be registered to the new vCenter Server.
Here are somethings not to worry about since they pertain to the hosts and remain with or without a vCenter Server.
- Standard switches
- Access to fiber channel storage
- VM settings and notes
Events and tasks for a VM will persist when the VM is in the new vCenter Server. However, performance data for VMs is lost. Also, performance data, events, and tasks for hosts will be lost when a host is added to a new vCenter Server.
The next articles will focus on two different ways I migrated the hosts to the new vCenter Servers.
Migrate Resources to a New vCenter Server (Part 1)
Migrate resources to a new vCenter Server – Methods for Migrations (Part 2)
Migrate resources to a new vCenter Server – Cross vCenter vMotion Utility (Part 3)
Migrate resources to a new vCenter Server – Unregister old vCenter Servers (Part 4)
VMware has an article for this error, but I think it should also mention to check templates. I had a template that was not showing it was being used by the vDS. The template was still tied to the vDS since it was using a port group on the vDS before it was converted to a template. I converted template to a VM, changed the port group, and converted the VM back to a template. Then I was able to remove the host from the vDS.
The resource ‘XXXX’ is in use. vDS NAME port XXXX is still on host NAME connected to NAME nic=4000 type-vmNic
I have two personal announcements that I am excited to share. I was selected as a VMware vExpert for 2018. One of my goals with this blog was it to assist in being recognized as a vExpert. I am happy I reached that my first year. There’s other contributions I made to the community that helped, such as the VMTN forums and VCAP Google+ community. Hopefully, I can be more active and achieve this status two years in a row.
I passed the AWS Certified SysOps Administrator – Associate exam. One challenging aspect of AWS exams is the passing score changes without warning and the passing score to reach. I took the exam the last day the specific version was available and fortunately passed with a 91%.
I recently had a strange problem with SRM 6.5 when I tried to open it in the flash or HTML5 client. Error said, “Failed to retrieve pairs from Site Recovery Manager Server at https://SRMaddress:9086/vcdr/vmoni/sdk. Cannot complete login due to an incorrect user name or password”. No service account passwords were recently changed. The error did not specify what user name failed.
I checked out SRM’s logs, which are located in C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs. I found only found one set of errors in the log. The message displayed another administrator, but nothing that SRM should be trying to use. A few messages in it were, “AuthorizeManager::AddCOnnection returned false for user…” and “Failed to login session…Insufficient privileges for user…”.
I could not find any information on any of the errors, except for a VMTM community post that saved me. The answer was so simple that I did not believe it would work until I tried it for myself. Daniel Soltau had a comment to login to vCenter at both sites in separate clients at the same time. It worked! SRM opened fine. I wanted to post this solution in hope that this reaches more people that have this strange SRM problem.
I deployed a Cisco UCS B200 server with a VIC 1380 and created a service profile from a template I always use. I assigned the service profile to the server and installed ESXi. I noticed the server was having network connectivity problems. It was intermittently dropping packets on a continuous ping.
I narrowed down that the issue was only occurring on a NIC going though Fabric Interconnect A. The network connectivity was fine on Fabric Interconnect B. No other servers were having the issue. I did more troubleshooting at that point with Cisco TAC.
Turns out the service profile was the issue. I unassigned the service profile, created a new profile from the same template, and assigned it to the server. Then network connectivity was working fine.
Next week will be one year since I launched my blog. I started off strong with posting articles and then I started to slip. I wish I had more time to write articles. I was tied up preparing for the VCAP6-DCV Design Exam the last few months of last year. It took more time than I expected to pass it. Then I started a new job in December, which has been keeping me quite busy. I am not focusing on VMware as much with this job as compared to my two previous jobs. I am working a lot with storage and Windows Server Failover Clustering. I am getting more settled into the job and hope to be able to write more articles.
I finally passed the VCAP6-DCV Design Exam after about 4 months of studying. This makes me a VCIX since I passed the VCAP5-DCA last year. I do not recommend anyone to take this exam.
I thought I could be different than the many others that failed the test their first and second attempts. However, I was like a lot of other people. This exam is extremely difficult and has many flaws.
My biggest complaint was on a drag and drop question. I was frustrated because I studied a lot and from many different sources. I was surprised to not be familiar enough to even attempt to answer one question. I eventually figured out why I was not ready for the question. It was based on a 5.5 objective; Describe layered security considerations, including but not limited to Trust Zones. That objective is not on the 6 exam objectives. I used many different sources when studying and no one mentioned this topic. VMware should base the exam off of the objectives they list on their site for the respective version of the exam.
I have a smaller example of another flaw. A host is referred to by different words on various questions. Sometimes a host was called a server or node. One questions used the word server to refer a host and also for a virtual machine from what I gathered by the context of the question.
On the other hand, the deploy exam was straight forward and a rewarding experience. I gained a lot from it and knew where I stood when studying and taking the exam. The design exam is the complete opposite.
I see why many others, including VMware employees, recommend to not even take the VCAP6-DCV design exam. I completely agree. I highly recommend to take the VCP 6.5 and then take the VCAP on 6.5 if that’s what it takes to avoid the VCAP6 design exam.
VMware’s KB 2113917 for repointing vCenter to a new PSC within the same site on vSphere 6 is straightforward. Only requires one command to run on the vCenter Server. However, the repoint will not work if the proxy setting is enabled on the vCenter Server. This is a bug and hopefully will be fixed in a future patch.
Below is the error message after running the repoint command with the proxy enabled.
Please check the configuration and retry
Using curl to test the port connectivity was fine for port 443 on the PSC. I could even access the page that is in the error message. tcpdump between the vCenter Server and PSC showed information on the proxy. That is odd since the repoint shouldn’t need a proxy. The proxy is there so the vCenter Server can get out for updates.
The proxy can be disabled on the vCenter Server’s Appliance Management UI; https://:5480 Then go to Networking…Proxy Settings…Edit and uncheck ‘Use a proxy server’. Restart the vCenter Server and run the repoint command again.