Our KVM solution, clulstered and self hosted
Project description
ourkvm
Our KVM solution. Cluster, API and local tools all in one.
API
The API is a rest API enabled by running python -m ourkvm --api
The API is built using FastAPI.
The API requires authentication and uses OpenID connect and JWT for SSO.
This is done using fastapi_resource_server. It's tested against Keycloak using a custom realm, users and roles/groups to isolate permissions.
Tools
The library ships with a Python module that can produce qemu strings that you can use to launch a machine.
It can create local resources such as Qemu disk images, Virtual Machine templates, configuration and .service
files.
These .service
files that the module generates, can be started with systemctl --user start machineX.service
which is described below.
Creating a local virtual machine
$ python -m ourkvm \
--machine-name testmachine \
--namespace testmachine \
--memory 4096 \
--harddrives ./testimg.qcow2:20G,./testlarge.qcow2:40G \
--cdroms ~/archiso/out/*.iso \
--service /etc/systemd/system/ \
--config /etc/qemu.d/testmachine.cfg
The following will create a minimal virtual machine using NAT for networking, headless operation meant to be started with systemctl start testmachine.service
.
Stopping a machine
$ sudo systemctl stop testmachine.service
Using the above example service of testmachine.service
, the service will trigger python -m ourkvm --machine-name testmachine --stop
which will attach to the Qemu QMP socket at /tmp/testmachine.qmp
and execute a poweroff
(followed by qemu-quit
after a grace period if the machine has not yet powered off).
Adding custom networking
$ python -m ourkvm \
--machine-name testmachine \
--namespace testmachine \
--memory 4096 \
--harddrives ./testimg.qcow2:20G,./testlarge.qcow2:40G \
--cdroms ~/archiso/out/*.iso \
--service /etc/systemd/system/ \
--config /etc/qemu.d/testmachine.cfg \
--network '[{"type": "tap", "name": "tap0", "bridge": "ns_br0", "namespace": "testmachine", "attach": true}, {"type": "veth", "name": "vens0", "bridge": "test_bridge", "veth_pair": "vens0_ns"}, {"type": "veth", "name": "vens0_ns", "bridge": "ns_br0", "namespace": "testmachine", "veth_pair": "vens0"}]'
Adding to the previous example, this will add networking according to the following JSON layout:
[
{
"type": "tap",
"name": "tap0",
"bridge": "ns_br0",
"namespace": true,
"attach": true,
},
{
"type": "veth",
"name": "vens0",
"bridge": "test_bridge",
"veth_pair": "vens0_ns"
},
{
"type": "veth",
"name": "vens0_ns",
"bridge": "ns_br0",
"namespace": true,
"veth_pair": "vens0"
}
]
This creates several network components. Beginning from the top of the JSON file (but backwards logically):
- A
tap0
interface attached to the virtual machine - A bridge
ns_br0
connectingtap0
to it - Moving the above two interfaces into a namespace called
testmachine
- Creating a veth-pair of
vens0
<-->vens0_ns
- Creating a bridge called
test_bridge
- Adding
vens0
to thetest_bridge
- Moving
vens0_ns
into the namespacetestmachine
Creating a network chain that looks like the following:
[host] test_bridge <--> vens0--|--vens0_ns <--> ns_br0 <--> tap0 [vm]
.
The API will take care of creating the elaborate network infrastructure, but the CLI does the work for now.
Note: the namespace
declaration in the network struct is True
and will get automatically converted to the --namespace
definition. Specific namespace names can be supplied here instead of the VM should connect between multiple namespaces using bridges or veth interfaces.
Cluster
The cluster is a feature being developer where the aim is to be able to share resources using KVM in a sensible way. Priority will be on static load balancing, but the goal is to have live balancing between cluster nodes.
Contributing
We use tabs over spaces. We follow pep8 to some extent using Flake8 (see .flake8
for exceptions). We follow strict typing using mypy with the --strict
parameter and we require every function to have a associated pytest function under /tests/
.
We welcome PR's on any addition/change. They might not all make it, but we develop straight against main
which is our master branch. Occational vX.y.z-dev
branch might appear to fix an older version while a major release is being on the way. PR's will not be merged until the three GitHub workflows (flake8, mypy and pytest) have completed successfully.
Help
Feel free to open a issue if you think it's a bug or you want to suggest an improvement.
Discussions
Open a discussion on a topic you believe is relevant to discuss or talk about surrounding ourkvm, if it doesn't fit the #help section.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file python-ourkvm-0.0.17.tar.gz
.
File metadata
- Download URL: python-ourkvm-0.0.17.tar.gz
- Upload date:
- Size: 23.7 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/3.7.1 importlib_metadata/4.9.0 pkginfo/1.8.2 requests/2.26.0 requests-toolbelt/0.9.1 tqdm/4.62.3 CPython/3.9.9
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 5377150ed06c6411da09219edc320a09b023eed5a4cdcff78685da8caf4d51ef |
|
MD5 | 95eb86edbcb52d7fb75dc4ce490cbaee |
|
BLAKE2b-256 | aff3e94f1fbf29a8ced232eafaded1b70b740014dace38c4ed456ee644a6d2f9 |
Provenance
File details
Details for the file python_ourkvm-0.0.17-py2.py3-none-any.whl
.
File metadata
- Download URL: python_ourkvm-0.0.17-py2.py3-none-any.whl
- Upload date:
- Size: 30.8 kB
- Tags: Python 2, Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/3.7.1 importlib_metadata/4.9.0 pkginfo/1.8.2 requests/2.26.0 requests-toolbelt/0.9.1 tqdm/4.62.3 CPython/3.9.9
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 60785430fc0ac03708cc67142780ea1182819585a905a97934d89ed804667da8 |
|
MD5 | f77c9db47329f09bb6ecddcd5a4cbe1c |
|
BLAKE2b-256 | 782bcd7390c39db8fa512dd305b9835062941b0ef06f11364ff1510a87b88838 |