Quantcast
Channel: VMware Communities: Message List - Backup & Recovery
Viewing all articles
Browse latest Browse all 5692

Migration from 5.8 to 6.1 Issues

$
0
0

I ran through the migration from 5.8 to 6.1 today mostly with the help of this article; http://kb.vmware.com/kb/2127665

The admin guide for VDP 6.1 had less than a page on the migration steps, and left a lot out which was covered in the above kb.

I had some problems that mad the whole process take many hours when it seemed like it should have taken less than one.

For instance, leaving a secondary DNS server in the setup wizard would cause the hostname to not resolve. I tried adding to the resolve.conf file, rebooting, checked nslookup multiple times where it returned the expected results, and still it would fail. Until I removed the secondary address at which point it ran perfectly. I vaguely remember a similar issue back in the 5.5 version days, but I would hope that if it's a known bug that would have been fixed or the secondary section would have been removed.

I also had a strange issue with the root password. When trying to configure the migration it asks for the FQDN and root password. Despite being able to log in with the root credentials that I knew were correct via the console alongside this wizard it would always fail! I tried restarting the source appliance, enabling SSH, running a manual integrity check. Nothing worked. It wasn't until I changed the root password to one with symbols instead of just upper, lowercase, and numbers, that it finally succeeded. Strange! maybe it just needed to be changed, not necessarily that symbols were involved. no idea!

I love the idea that you migrate to a new appliance and point the old disks to the new VM to save storage space by not needing to have 2 huge VDP VMs, but in my case it didn't seem to be handled as gracefully as I would have liked. After the configuration of the new appliance it shuts down the source VM, but keeps the original disks mapped to it. In the linked kb article it suggests deleting the original VM when the migration is finished, but if you do that without checking you'll be destroying your new VM too!

The kb also suggests running a backup of the boot disk as an archive, but at least in my case the new VDP backup portal doesn't even show the old one as an option to backup.

Maybe these issues were my fault somehow, but I'm just not so impressed with this migration process after going through it. I understand why it had to be done this way, but there are definitely some speed bumps.

 

On to my question; prior to deleting the original VM should I do something to remove it from the web client drop-down list? The old name still shows as a selection to connect to.


Viewing all articles
Browse latest Browse all 5692