HI fellas,
For a customer of ours, we are trying to restore several VMs hosted on our VMware platform to a new location on the same platform. But after mounting the VMs when starting the Instant Recovery we get the errors on conflicts with static MAC addresses and the instance UUIDs.
To elaborate, we're running ESXi 6.7 on which we run vCloud Director to create multitenancy. Our customer needs to test some VM settings which requires reservations on resources, which in return would mean a big chunk of our resources in total are being set aside just for this customer. Obviously we aren't very excited about that prospect so we thought we'd just recover the necessary VMs into a new organization (resource pool), put a reservation on that which would minimize the impact and have them test it.
But as stated above, after starting and finishing the Instant Recovery all of those VMs show the errors on the static MAC addresses (which I don't that much) and the UUID conflicts. This, I believe, also prevents the Auto Discovery of those VMs, which means the VMs don't show in vCloud Director. If I can't get those machines visible in vCloud Director I can't let the partner test anything.
Btw, I did choose for all of the VMs to generate new UUIDs and added the _restored suffix so they would have unique names. But seeing the results I'm thinking this option isn't working or not enforced somehow.
Anybody around who could give me a nudge into the right direction or who has dealt with something similar?
Thanks!
-
- Service Provider
- Posts: 73
- Liked: 10 times
- Joined: Sep 19, 2018 12:11 pm
- Full Name: Frank Wijmans
- Location: The Netherlands
- Contact:
-
- Product Manager
- Posts: 14716
- Liked: 1702 times
- Joined: Feb 04, 2013 2:07 pm
- Full Name: Dmitry Popov
- Location: Prague
- Contact:
Re: Instant Recovery UUID conflict
Hello Frank,
It looks like a bug to be honest (new VM UUID, and name prefix should be enough to resolve VMware conflicts). Can you please raise a ticket and share the case ID with us (debug log analysis is required anyway to understand the root cause)? Thank you in advance!
It looks like a bug to be honest (new VM UUID, and name prefix should be enough to resolve VMware conflicts). Can you please raise a ticket and share the case ID with us (debug log analysis is required anyway to understand the root cause)? Thank you in advance!
Who is online
Users browsing this forum: No registered users and 58 guests