All this code is very much hacked together to try and get things working in a reasonably reliable manner. It may have flaws, may be unpolished, or not even fully automated. Since pretty much noone uses HyperVM anymore anyway, I don't think this is too much of an issue.
Do not under any circumstances attempt to use this code without first backing up all user and VPS data. Use at your own risk.
This is going to take some attention and time to set up properly, and you'll be on your own for parts of it... but honestly, there's not really an alternative for mass HyperVM transfers.
adminHyperVM user, and not an auxiliary account.
size,vpsid. You can gather this through running
du -sh /vz/private/*on each node, creating one giant list out of results from all nodes, and replacing tabs with commas.
public_htmlto your document root for the HTTPd.
.phpfiles in the document root to set the database configuration.
input.csvwith the data from the first database dump.
locationsvariable holds a structure with all the nodes for the current locations.
new_serversholds a structure defining how many new nodes exist for each 'category' in each location. In the existing script, these are marked as 12, 34, and 56, but you can use any numeric value here. If you increase or decrease the amount of categories, be sure to change the code elsewhere to reflect this. Change the code from line 43 to 48, to sort the plans into the right categories. Change the hostname in line 73 to reflect your hostname format.
sorted.csv. You now have your existing VPSes planned uniformly across the number of nodes you have for each category in each location.
run.py, and set the correct database configuration in each.
run.pyto use the correct SMTP login details, sender address, and panel login details.
run.pyto reflect what you want to send to your users.
report.phpto set a 'reporting key' that is used by the HyperVM panel to authenticate itself to your reporting script.
hypervm/bin/common/(you'll need to restore these after the migration!).
patchdirectory into the
switchserver.phpfiles. Note that it has to be replaced in two places in each of the files!
run.pywill start the migration. Using the
--resumeflag will make it skip the initial notification e-mail phase. Do this when for whatever reason the script has terminated, and you wish to restart it.
mark_done.pywith the name of the target node as first parameter. It will assume that the currently transfering/failed VPS has finished migrating, send a success e-mail, and move on to the next.
status.pywill give you a human-readable overview of the current status for each node.
failed.pywill give you an overview of the relevant information for all transfers that are in the 'failed' state, and need manual attention.