Forum Discussion
I went through an "in-place" physical to virtual migration recently and my general steps were as follows. This assumes that all IP addressing, hostnames, and so forth will remain the same, and allows you to use the standard HA failover method as the old active and new standby will be clustered together briefly.
- Deploy the new VEs to the same software version as the source systems.
- Reset the masterkey on your source systems to the same value for each member in the cluster, and record it.
modify /sys crypto master-key prompt-for-password
- Create a UCS archive for each source system, and store them somewhere safe.
- On the destination VEs, set their masterkeys to match that of the source system.
modify /sys crypto master-key prompt-for-password
- Upload the UCS archives to the destination.
- Set the destination hostnames to match the source, and license the boxes. Create an archive at this point in case something goes wrong.
- Shut down the standby unit, and re-IP the destination unit to match. (You could disable the box at the network level too, if you like. In my recent experience with this, we only had access to the AOM, so a power-off was appropriate.)
- Load the UCS using the command
load /sys ucs no-license no-platform-check
At this point the new system should attempt to load the config. I did this on 11.5.4 and it needed a few edits to the config file, so just make the edits needed and continue attempting
load sys config
until the errors go away. This may vary on particular software releases.
Once the configuration loads, you can then reassign your VLANs to the correct interfaces, adjusting for tagged or untagged modes. If you were running a trunk previously, you'll have to remove the VLANs from that first.
At this point if everything worked out, then you should be able to see the cluster failover status as Standby. Configsync might even work too, if your software versions are the same. Compare the network maps on each, check the logs, then you could force your active to standby, then verify things look good. If everything is OK, repeat the steps and migrate the config from the other box.
Over all this method worked pretty well for us and we migrated 10 boxes this way. The nice thing about this process is that you don't need to stage any temporary self-IPs
To speak to your question about DNSSEC, I think that as long as your masterkey values match, then you shouldn't have any trouble with loading the configuration. As with anything, try to test as best you can, but hopefully someone may have an answer for you.
Hope this helps!