Add start of articles for VM guide
Nathan Steel
4 years ago
parent
75d4a6886b
commit
b8130c8aa3
@ -0,0 +1,53 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<meta name="description" content="">
|
||||
<meta name="keywords" content="Blog, articles, template">
|
||||
<meta name="author" content="Nathan (Aney) Steel">
|
||||
<meta name="theme-color" content="white">
|
||||
<meta name="theme-color" content="black">
|
||||
<link rel="stylesheet" type="text/css" href="/main.css">
|
||||
<link rel="icon" type="image/png" href="/images/favicon.svg">
|
||||
<title>Setup a bridge network for KVM</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<header>
|
||||
<h1>Setup a bridge network for KVM</h1>
|
||||
<hr/>
|
||||
<nav>
|
||||
<a href="/">home</a>
|
||||
<a href="/equipment.html">equipment</a>
|
||||
<a href="/projects.html">projects</a>
|
||||
<a href="/blog/">blog</a>
|
||||
<a href="/sitemap.html">misc</a>
|
||||
<a href="/support.html">support</a>
|
||||
</nav>
|
||||
<hr/>
|
||||
</header>
|
||||
|
||||
<main>
|
||||
<section>
|
||||
<p class="intro">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.</p>
|
||||
<h2>Heading</h2>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>References</h2>
|
||||
<ul>
|
||||
<li><a href="#">This one</a></li>
|
||||
<li><a href="#">This other one</a></li>
|
||||
</ul>
|
||||
|
||||
</section>
|
||||
</main>
|
||||
|
||||
<footer>
|
||||
<hr/>
|
||||
<p>Written by <a href="http://aney.co.uk" target="_blank" rel="noopener">@aney</a> with <a href="https://danluu.com/web-bloat/" target="_blank" rel="noopener">web bloat</a> in mind | <a href="https://github.com/Aney/website" target="_blank" rel="noopener">Source Code</a></p>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -0,0 +1,44 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<meta name="description" content="">
|
||||
<meta name="keywords" content="Blog, articles, template, guide, KVM, QEMU, virtualisation">
|
||||
<meta name="author" content="Nathan (Aney) Steel">
|
||||
<meta name="theme-color" content="white">
|
||||
<meta name="theme-color" content="black">
|
||||
<link rel="stylesheet" type="text/css" href="/main.css">
|
||||
<link rel="icon" type="image/png" href="/images/favicon.svg">
|
||||
<title>Setup KVM/QEMU virtualisation</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<header>
|
||||
<h1>Setup KVM/QEMU virtualisation</h1>
|
||||
<hr/>
|
||||
<nav>
|
||||
<a href="/">home</a>
|
||||
<a href="/equipment.html">equipment</a>
|
||||
<a href="/projects.html">projects</a>
|
||||
<a href="/blog/">blog</a>
|
||||
<a href="/sitemap.html">misc</a>
|
||||
<a href="/support.html">support</a>
|
||||
</nav>
|
||||
<hr/>
|
||||
</header>
|
||||
|
||||
<main>
|
||||
<section>
|
||||
<p class="intro">This is an intro, you gotta believe me</p>
|
||||
<h2>Heading</h2>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
<footer>
|
||||
<hr/>
|
||||
<p>Written by <a href="http://aney.co.uk" target="_blank" rel="noopener">@aney</a> with <a href="https://danluu.com/web-bloat/" target="_blank" rel="noopener">web bloat</a> in mind | <a href="https://github.com/Aney/website" target="_blank" rel="noopener">Source Code</a></p>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -0,0 +1,104 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<meta name="description" content="">
|
||||
<meta name="keywords" content="Blog, articles, guide, cheatsheet, virsh, virtual machine">
|
||||
<meta name="author" content="Nathan (Aney) Steel">
|
||||
<meta name="theme-color" content="white">
|
||||
<meta name="theme-color" content="black">
|
||||
<link rel="stylesheet" type="text/css" href="/main.css">
|
||||
<link rel="icon" type="image/png" href="/images/favicon.svg">
|
||||
<title>Virsh Cheatsheet</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<header>
|
||||
<h1>Virsh Cheatsheet</h1>
|
||||
<hr/>
|
||||
<nav>
|
||||
<a href="/">home</a>
|
||||
<a href="/equipment.html">equipment</a>
|
||||
<a href="/projects.html">projects</a>
|
||||
<a href="/blog/">blog</a>
|
||||
<a href="/sitemap.html">misc</a>
|
||||
<a href="/support.html">support</a>
|
||||
</nav>
|
||||
<hr/>
|
||||
</header>
|
||||
|
||||
<main>
|
||||
<section>
|
||||
<p class="intro">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.</p>
|
||||
<h2>List VMs</h2>
|
||||
<pre><code>virsh list</code></pre>
|
||||
<p>List all, including offline vms</p>
|
||||
<pre><code>virsh list --all</code></pre>
|
||||
|
||||
<h2>Start/Stop</h2>
|
||||
<pre><code>virsh start $vm</code></pre>
|
||||
<pre><code>virsh shutdown $vm</code></pre>
|
||||
<pre><code>virsh reboot $vm</code></pre>
|
||||
<p>If the VM refuses to shutdown, etc. destroy performs an ungraceful shutdown</p>
|
||||
<pre><code>virsh destroy $vm</code></pre>
|
||||
|
||||
<h3>Autostart</h3>
|
||||
<pre><code>virsh autostart $vm</code></pre>
|
||||
<pre><code>virsh autostart $vm --disable</code></pre>
|
||||
|
||||
<h2>Rename</h2>
|
||||
<pre><code>virsh domrename $vm $new_name</code></pre>
|
||||
|
||||
<h2>Delete</h2>
|
||||
<pre><code>virsh undefine $vm</code></pre>
|
||||
<h3>Delete Snapshots</h3>
|
||||
<p>If your VM has Snapshots it won't delete as simply, so delete those first<p>
|
||||
<p>List the snapshots</p>
|
||||
<pre><code>virsh snapshot-list --domain $vm</code></pre>
|
||||
<p>And delete each snapshot with the following</p>
|
||||
<pre><code>virsh snapshot-delete --domain $vm --snapshotname $snapshot</code></pre>
|
||||
<h3>Deleting with all storage</h3>
|
||||
<p>Delete the VM along with all the virtual storage</p>
|
||||
<pre><code>virsh undefine --domain $vm --remove-all-storage</code></pre>
|
||||
|
||||
<h2>Snapshots</h2>
|
||||
<h3>Create</h3>
|
||||
<p>Save a snapshot of the VMs current state</p>
|
||||
<pre><code>virsh snapshot-create-as --domain $vm --name "$snapshot_name"</code></pre>
|
||||
<h3>Restore/Revert</h3>
|
||||
<p>Revert the VM to the state it was in during the snapshot</p>
|
||||
<pre><code>virsh snapshot-revert $vm $snapshot_name</code></pre>
|
||||
<h3>Delete Snapshot</h3>
|
||||
<p>Delete the snapshot, this doesn't delete anything else related to the VM</p>
|
||||
<pre><code>virsh snapshot-delete --domain $vm --snapshotname $snapshot_name</code></pre>
|
||||
|
||||
<h2>Drive management</h2>
|
||||
|
||||
<h2>Change Memory</h2>
|
||||
<p>In variantions of 512M, 1G, etc</p>
|
||||
<pre><code>virsh setmem $vm $ram</code></pre>
|
||||
<pre><code>virsh setmaxmem $vm $ram</code></pre>
|
||||
|
||||
<h2>Change vCPU cores</h2>
|
||||
<p>This is a little more tricky, as it involves editing the XML file</p>
|
||||
<pre><code>virsh edit $vm</code></pre>
|
||||
<p>Then edit the vcpus section, change between the tags</p>
|
||||
<pre><code><vcpu placement='static'>$vcpus</vcpu></code></pre>
|
||||
|
||||
<h2>Connect via serial/console</h2>
|
||||
<p>This is a means to connect to your VMs via terminal</p>
|
||||
<pre><code>virsh console $vm</code></pre>
|
||||
<p>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.</p>
|
||||
<pre><code>systemctl enable serial-getty@ttyS0.service</code></pre>
|
||||
|
||||
</section>
|
||||
</main>
|
||||
|
||||
<footer>
|
||||
<hr/>
|
||||
<p>Written by <a href="http://aney.co.uk" target="_blank" rel="noopener">@aney</a> with <a href="https://danluu.com/web-bloat/" target="_blank" rel="noopener">web bloat</a> in mind | <a href="https://github.com/Aney/website" target="_blank" rel="noopener">Source Code</a></p>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -0,0 +1,87 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<meta name="description" content="">
|
||||
<meta name="keywords" content="Blog, articles, virtual machines, seperation of concerns, SoC, optimise">
|
||||
<meta name="author" content="Nathan (Aney) Steel">
|
||||
<meta name="theme-color" content="white">
|
||||
<meta name="theme-color" content="black">
|
||||
<link rel="stylesheet" type="text/css" href="/main.css">
|
||||
<link rel="icon" type="image/png" href="/images/favicon.svg">
|
||||
<title>VM/Server Seperation of Concerns</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<header>
|
||||
<h1>VM/Server Seperation of Concerns</h1>
|
||||
<hr/>
|
||||
<nav>
|
||||
<a href="/">home</a>
|
||||
<a href="/equipment.html">equipment</a>
|
||||
<a href="/projects.html">projects</a>
|
||||
<a href="/blog/">blog</a>
|
||||
<a href="/sitemap.html">misc</a>
|
||||
<a href="/support.html">support</a>
|
||||
</nav>
|
||||
<hr/>
|
||||
</header>
|
||||
|
||||
<main>
|
||||
<section>
|
||||
<p class="intro">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</p>
|
||||
<h2>Why seperate concerns for a server?</h2>
|
||||
<p>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.</p>
|
||||
|
||||
<h2>How to seperate concerns</h2>
|
||||
<p>Some people will seperate each service into their own VM, however I don't believe this to be efficient (in all cases).</p>
|
||||
<p>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).</p>
|
||||
<table>
|
||||
<thead><tr><th>Concern/VM</th><th>Services</th></tr></thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Production Web Server</th>
|
||||
<td>Nginx</td>
|
||||
<td>PHP</td>
|
||||
<td>CertBot</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Staging Web Server</th>
|
||||
<td>Nginx</td>
|
||||
<td>PHP</td>
|
||||
<td>CertBot</td>
|
||||
<td>mariaDB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>NAS</th>
|
||||
<td>OpenMediaVault</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>SQL server</th>
|
||||
<td>mariaDB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Torrent Box</th>
|
||||
<td>Transmission</td>
|
||||
<td>VPN (to external)</td>
|
||||
<td>Sonarr</td>
|
||||
<td>Radarr</td>
|
||||
<td>Ombi</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Why not use a dedicated server for each concern?</h2>
|
||||
<p>You can! No-one's going to stop you, but unless each concern <em>requires</em> (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.</p>
|
||||
<p>Virtual Machines are wonderful, as they allow you to make use of more powerful/high spec machines while minimising the wasted usage...</p>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
<footer>
|
||||
<hr/>
|
||||
<p>Written by <a href="http://aney.co.uk" target="_blank" rel="noopener">@aney</a> with <a href="https://danluu.com/web-bloat/" target="_blank" rel="noopener">web bloat</a> in mind | <a href="https://github.com/Aney/website" target="_blank" rel="noopener">Source Code</a></p>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
Loading…
Reference in New Issue