Back again to wrap up this trilogy! Last time we talked about configuring the hardware to be resilient and fault tolerant. This time we’re migrating VM’s off the old server into the new stack and crafting some templates for making new ones easy. Out with the old and in with the new! Lets do this!
Mighty Magnificent Migrations
Before we go building new stuff we need to move over what we already got. Now I have done this once before but I took a very unconventional route. This time it was actually way easier than I anticipated, it helps when you actually read the fucking manual! On the Old host, I make a backup of all the VMs that need to move. Then on the new host, create a new disk store that points to the backup directory of the old host, creating a CIFS Connection.
Once the connection is established and backups are visible to the new host, I just restore it! No code, no command line, all GUI 😀 However, for this site up time is critical so order of operations matter here. To keep things running smooth, the old VM does not go down until the new one gets an IP. Once both are online then its safe to make the IP reservation and change over port forwarding. After that is complete the new server is live and the old VM is shutdown!
Cooking some Delicious Templates
With the important bits out of the way, now we can start working on the new stuff. I plan on making quite a few VM’s and I’m fairly lazy, so I really don’t want to install Ubuntu an N amount of times. This is where Proxmox templates comes in!
When it comes to virtualization there are a lot of ways to skin the server. I have my own flavor of doing templates when it comes to Proxmox. Traditionally, you setup a VM, install all the 3rd party software you are going to use and get it fully updated. After that, shut it down and convert it into a template. From there you can create full/linked clones from that saved template. The difference between linked and full is linked needs that template available at all times since the disk is shared. Full clones are fully independent.
The problem that I have is once you convert the VM into a template, you can no longer turn it on and make changes. This can get extra frustrating if you have VM’s that are linked to that old template, forcing you to keep it until you deal with those dependent VM’s. This is why I just leave my “template” VM’s as a VM, shut them down, spin them up to make changes and then only make full clones of them.
For what I am doing, I really don’t need a ton of templates. In fact I only have two right now. One with a fully configured Webmin install, for really specialized servers and one with Virtualmin to handle the more dynamic and multi-tenant servers.
With both templates setup with the latest and greatest updates and logins configured, the mass cloning can commence!
Brewing up some Security Templates
I’m a bit of a security Nazi *Taps Security+ Cert* and I am a very strong believer in Air gaps. I’m also a strong believer in defense in depth, when you can’t air gap your way out of a problem. This is usually the case 🙂 Since we’re doing a lot of cloning we’re going to need one more thing setup to make this process a lot easier. We’re going to need security groups!
Security groups are the templates of firewall rules. They allow you to setup a set of rules once and then apply the set to your VM’s. Instead of poking a hole for SSH for every VM built, I can just apply a security group. If I need to make changes, I can do so on the group and it will apply to any VM using it.
Also, one extra layer of protection I like to do is source/destination IP’s. I primarily use them for ports that I know are going to be local only. You can really speed up the process using IP Alias’s, by naming IP’s or entire CIDR Blocks! That way if there is an intrusion, the firewall rule checks that the IP is from inside the network. It won’t completely protect me but again its adding enough layers to make them give up.
The Part where I leave you Hanging 🙂
Well you’ve made it this far and unfortunately I’m going to have to leave you with some blue balls. I know I know, you’ve been edging the whole time on what VM’s I’m actually going to clone.
The thing is, I’ve done a lot since I’ve wrote this and if I explained everything up to this point it will be a very long post. So, the next few are going to break down each of the VM’s I’ve spun up long with all the hair pulling headaches that came along for the ride. Just to give you a taste, we got monitoring, mail and remote tools around the corner.