Additions to the xMove script #24
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added several new features -Unless specified, the move script will use the datastores that the VM currently resides on. This includes disks that reside on different datastores -Unless specified, the move script will use the same VDS switch name and portgroup name. This works for multiple NICs -Script will now read in vCenter tags (if any) on the source VC, move the VM, then re-apply the tags on the destination. **Note that the tags and categories will need to be created on the destination VC first Added logic to find the host with the least memory usage inside a cluster. Also added logic to prevent memory overcommitment during moves. Added logic to prevent the moves of VM Hardware Version 4. As specificed in the script, there appears to be a bug that will allow you to move a v4 VM and it will continue to work. However any change (powercycle, vmotion, etc) will cause the VM's NICs to drop their assigned portgroup. The only fix (post move that is) appears to be to power it off so the portgroup disappears then re-set the portgroup. I've only tested the multi-NIC move with a VDS switch but I wrote the logic for a VSS multi-NIC. Might need troubleshooting. I've moved approximately 3000 VMs with the script. Only major issue/annoyance is that large VMs won't move unless there is a ton of freespace on the same datastore. E.g. if you have a 4TB VM on a 5TB datastore, the move will fail the free space check because the move spec doesn't know that the datastore isn't changing. Bummer :(
Typo fix
Another typo
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi William,
This is the first time I've used github so apologies if I'm doing it wrong. I love the script you wrote for cross vCenter/SSO domain migrations. We have a very old DB (I believe it started as a 4.1 DB) that has been upgraded through the years to 6.0u2 but is now suffering from slowness, bugs, etc. We built an entirely clean 6.0u2 VCSA structure with multiple vCenters and needed a way to move our 3k+ VMs over while online.
I added a number of additional features such as:
-Read in list of VMs to move from CSV
-Unless specified, read in source datastore(s) of the VM's disks and set that as the target datastore.
-Unless specified, read in source portgroups/VDSes of the VM and set those on the target side
-Find host with the lowest memory usage and wrote a check to prevent overcommitment
-Wrote a check to prevent movement of HW version 4 VMs. I believe there is a bug (noted in the error message)
-Read in source tags (if they exist) and write those tags to the moved VM
I'm by no means a powershell guru like yourself (or Luc) so I'm sure there are better ways to do some of the things I did but I spent quite a while on the improvements and I've moved nearly 3k VMs so far. I hope that your readers can benefit from the script if they were in a similar position as us. Obviously the new VCSA migration tools could take away a lot of the pain.
Let me know if anything isn't clear. Thanks!
-Alex