diff --git a/blog/guide-to-server-hosting.html b/blog/guide-to-server-hosting.html index f7aac51..0ccc298 100644 --- a/blog/guide-to-server-hosting.html +++ b/blog/guide-to-server-hosting.html @@ -75,12 +75,13 @@

Run virtual machines

-

Virtual machines allow you to use your server as multiple servers at once, with different operating systems, services, files, etc.

+

Virtual machines allow you to use your server as multiple servers at once, with different operating systems, services, files, etc. If you're self-hosting this is a great way to separate concerns, having one system for each distinct task.

Additional services/potential guides

diff --git a/blog/setup-kvm-bridge.html b/blog/setup-kvm-bridge.html new file mode 100644 index 0000000..20fecdb --- /dev/null +++ b/blog/setup-kvm-bridge.html @@ -0,0 +1,53 @@ + + + + + + + + + + + + + Setup a bridge network for KVM + + + +
+

Setup a bridge network for KVM

+
+ +
+
+ +
+
+

A bridge network is a means to connect/bridge different networks together to act like a single network. This allows any connections to the bridge network to get their own internal IPs, and work as you'd expect a completely new physical PC to work.

+

Heading

+
+ +
+

References

+ + +
+
+ + + + + diff --git a/blog/setup-qemu-kvm.html b/blog/setup-qemu-kvm.html new file mode 100644 index 0000000..4b97581 --- /dev/null +++ b/blog/setup-qemu-kvm.html @@ -0,0 +1,44 @@ + + + + + + + + + + + + + Setup KVM/QEMU virtualisation + + + +
+

Setup KVM/QEMU virtualisation

+
+ +
+
+ +
+
+

This is an intro, you gotta believe me

+

Heading

+
+
+ + + + + diff --git a/blog/virsh-cheatsheet.html b/blog/virsh-cheatsheet.html new file mode 100644 index 0000000..3fce9bb --- /dev/null +++ b/blog/virsh-cheatsheet.html @@ -0,0 +1,104 @@ + + + + + + + + + + + + + Virsh Cheatsheet + + + +
+

Virsh Cheatsheet

+
+ +
+
+ +
+
+

Virsh is an extremely powerful tool for managing KVM/QEMU virtual machines. From restarting, to changing hardware, snapshotting, and cloning machines. I'll cover the basics of Virsh here, as it's all I personally use.

+

List VMs

+ 
virsh list
+

List all, including offline vms

+ 
virsh list --all
+ +

Start/Stop

+ 
virsh start $vm
+ 
virsh shutdown $vm
+ 
virsh reboot $vm
+

If the VM refuses to shutdown, etc. destroy performs an ungraceful shutdown

+ 
virsh destroy $vm
+ +

Autostart

+ 
virsh autostart $vm
+ 
virsh autostart $vm --disable
+ +

Rename

+ 
virsh domrename $vm $new_name
+ +

Delete

+ 
virsh undefine $vm
+

Delete Snapshots

+

If your VM has Snapshots it won't delete as simply, so delete those first

+

List the snapshots

+ 
virsh snapshot-list --domain $vm
+

And delete each snapshot with the following

+ 
virsh snapshot-delete --domain $vm --snapshotname $snapshot
+

Deleting with all storage

+

Delete the VM along with all the virtual storage

+ 
virsh undefine --domain $vm --remove-all-storage
+ +

Snapshots

+

Create

+

Save a snapshot of the VMs current state

+ 
virsh snapshot-create-as --domain $vm --name "$snapshot_name"
+

Restore/Revert

+

Revert the VM to the state it was in during the snapshot

+ 
virsh snapshot-revert $vm $snapshot_name
+

Delete Snapshot

+

Delete the snapshot, this doesn't delete anything else related to the VM

+ 
virsh snapshot-delete --domain $vm --snapshotname $snapshot_name
+ +

Drive management

+ +

Change Memory

+

In variantions of 512M, 1G, etc

+ 
virsh setmem $vm $ram
+ 
virsh setmaxmem $vm $ram
+ +

Change vCPU cores

+

This is a little more tricky, as it involves editing the XML file

+ 
virsh edit $vm
+

Then edit the vcpus section, change between the tags

+ 
<vcpu placement='static'>$vcpus</vcpu>
+ +

Connect via serial/console

+

This is a means to connect to your VMs via terminal

+ 
virsh console $vm
+

To do this you will likely need to first run the following command on the VM itself. This won't be required if you created the VM with console, but best to double check.

+ 
systemctl enable serial-getty@ttyS0.service
+ +
+
+ + + + + diff --git a/blog/vm-seperation-of-concerns.html b/blog/vm-seperation-of-concerns.html new file mode 100644 index 0000000..c48425b --- /dev/null +++ b/blog/vm-seperation-of-concerns.html @@ -0,0 +1,87 @@ + + + + + + + + + + + + + VM/Server Seperation of Concerns + + + +
+

VM/Server Seperation of Concerns

+
+ +
+
+ +
+
+

Seperation of Concerns is a principle used in Computer Science that helps seperate functionality, making things easier to work with, and avoiding issues that could occur with too much going on in one place

+

Why seperate concerns for a server?

+

Simple, once your server has a lot of services, and functionality going on, it gets hard to maintain, and can cause additional issues. For example, if a service dies and requires a reboot, that will end up rebooting all your other services too.

+ +

How to seperate concerns

+

Some people will seperate each service into their own VM, however I don't believe this to be efficient (in all cases).

+

What I recommend is to take your server needs, and break them down into logical blocks, adding each of these blocks to their own VMs. This will keep certain things contained alone, as you want them seperated as much as possible (NAS, etc).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Concern/VMServices
Production Web ServerNginxPHPCertBot
Staging Web ServerNginxPHPCertBotmariaDB
NASOpenMediaVault
SQL servermariaDB
Torrent BoxTransmissionVPN (to external)SonarrRadarrOmbi
+ +

Why not use a dedicated server for each concern?

+

You can! No-one's going to stop you, but unless each concern requires (i.e. needs the dedicated hardware/isolation) its own dedicated server, it's hugely redundant. Again NAS as an example, would be good for a dedicated machine, as it'll be safer if there's no additional chance it goes down due to failure of an unrelated service.

+

Virtual Machines are wonderful, as they allow you to make use of more powerful/high spec machines while minimising the wasted usage...

+
+
+ + + + +