The most important part of the migration is that, while I missed some blocks from my restarts and confusion from some of the log output, it didn't result in enough(nowhere close) downtime to be slashed.
I will be making a few guides in the coming days, which will give you insight into how I run my validator. This is how I hope to lure you into staking with me.
SEMPER FI!
I originally decided to try OVH Cloud as a hosting provider for the Vidulum validator I am wanting to run. When I was with OVH, I wanted to partition out the initial drive that the VPS so that I could add a SWAP partition. This requires you to umount the drive, so naturally, I need to do this in some sort of recovery/CLI mode. It took their support a while to find the answer, which was really a solution embedded in another KB for one of their other products.
I was able to get my problem resolved, you can boot the VPS into a recovery mode to modify the partition. To do so is not well advertised IMO. So I decided to go with my old trusty favorite, Linode.
Here is my referal link for Linode, I highly recommend them.
OVH Options for Starting a new VPS:
Linode options for creating a new node, changing it on the fly, configuring the boot order, and more.
As you can see, Linode is a WAY more robust and encompasing hosting provider.
Check out my LVM performance check
hdparm -tT /my-lvm
And while I deleted my VPS from OVH, the SSD disk drive attached was not getting a great speed. However, since I don't really remember the number nor did I take a picture prior to deleting the service, I will just leave it at that.
If you are hosting a VPS with OVH, I'd love to hear what your results are of the above command? Please comment below
I did admittedly have some issues during the migration. I am going to be working on a 'How to Migrate Your Vidulum Validator' post after this. I will discuss some of these things in more detail there.
First, I got the new node up and sync'd. My first blunder is what I choose to name it in the beginning and being confused about chaning it come time.
You first must init your validator with a name. Since I thought I would 'need' to rename it the same name(my blunder), I named the validator 'temp'.
The other hick-up I ran into was needing to re-add the wallet.
The current Migration guide does not include stpes to add the keys to the keystore list. My key files were present, and the node was working and signing but I was unable to issue commands as the wallet keys weren’t present in the keystore list.
The step I was after is extra, and there isn't anything wrong with the current instructions.
To resolve what I did, I basically ran: (Don't follow this 'guide' blindly, as this is what worked for me an actual guide is coming soon.)
rm -rf config/ NODE_NAME.info keyhash
wget https://raw.githubusercontent.com/vidulum/mainnet/main/genesis.json -O ${HOME}/.vidulum/config/genesis.json
vidulumd init NODE_NAME --chain-id vidulum-1
sudo systemctl restart vidulumd.service
vidulumd keys add WALLET_NAME -i --keyring-backend os
First removing the config directory(after having backed up your keys), then the .info that I first init'd with (temp) and the keyhash file with it.
After, I resync'd up which also re-populates everything we removed. The '-i' flag is for interactive mode. I restored the wallet via the mnemonic, which is the way I recommend.
Create a new keyring passphrase, save it and guard that with yourlife. :D
After all of this, I was able to then issue commands to update my validator, calling the flag
"–from=WALLET_NAME"
I am extremely glad I made the move to Linode and it will add a level of redundancy to the validator that I am overly pleased with!
If you find any of my write-ups helpful, consider staking with my Validator: "Moneta By Erialos"
Or Donating VDL (All donated VDL is used to increase the Validators self delegation)
vdl1zvalykc0hp3jxteasnz626djt724fxkyv73p6k