07-18-2021, 08:47 AM
It happens that NanoKVM was the first truly free service I got a NAT-VPS from since I joined this community -ie it's running for 17 months and counting.. The specs are indeed modest but the service is astonishingly reliable and with pretty good overall performance as well.
Recently I asked for a VM migration from the Eygelshoven/Netherlands (NL) node to its Nuremberg/Germany (DE) node. This request was motivated by the desire to upgrade the RAM to 2GB, the Nuremberg/Germany node being the only one having that option available. @Neoon graciously created a new VM on the Nuremberg node as his Proxmox setup doesn't support clustering.
This review's objective is to attempt a comparison of the 2 VMs which will largely reflect:
1-> the performance of the 2 nanoKVM nodes and
2-> the way Neoon partitioned(/capped) their resources among the running VMs on them.
Before we begin, here are the nodes setup based on this NanoKVM info_page:
(*) Code tag used because data are formatted as a table
From the above table we can see that the German(/DE) node uses a recent, highly perfrmant desktop CPU backed by 64GB of non-ECC DDR4 RAM and an NVMe SSD storage while the NL's node has a 2K12 E5-class server CPU backed by 32GB ECC DDR3 RAM and SATA-based SSD storage.
With those specs in mind, we can now turn our attention into how my 2 NanoKVM VMs are doing on those 2 nodes, performance-wise. Before we get started, I must say that I will also break down this review into a series of posts each one dealing with one resource only.
In this post, I'll only pinpoint to the chipsets, ie the QEMU's machine type, used by NanoKVM VMs.
To answer the question of what virtual hardware did NanoKVM put into their NAT-VPS(s) ?
1. NanoKVM VMs Used Machine-type:
As shown below both NanoKVM VMs are using the most recent version of the old PC machine-type (ie pc-i440fx-5.2, as of QEMU version 5.2.0.) using the latest Seabios version: 1.14.0, released on Aug. 2020.
As we'll see going forward, both VMs are using the same virtual hardware config. The only difference I've noticed in the full output of 'lshw' command is that the DE node's VM is missing the memory virtio_balloon driver. This is demonstrated by listing the loaded virtIO drivers into the kernel:
> NL node VM:
> DE node VM:
We may comeback to this later..
Stay tuned for the next post!..
Recently I asked for a VM migration from the Eygelshoven/Netherlands (NL) node to its Nuremberg/Germany (DE) node. This request was motivated by the desire to upgrade the RAM to 2GB, the Nuremberg/Germany node being the only one having that option available. @Neoon graciously created a new VM on the Nuremberg node as his Proxmox setup doesn't support clustering.
This review's objective is to attempt a comparison of the 2 VMs which will largely reflect:
1-> the performance of the 2 nanoKVM nodes and
2-> the way Neoon partitioned(/capped) their resources among the running VMs on them.
Before we begin, here are the nodes setup based on this NanoKVM info_page:
Code: (Select All)
The Nuremberg (DE) node The Eygelshoven (NL) node
---------------------------------------------------------------------------
CPU: Intel i9-9900K @ 3.60GHz Intel Xeon E5-2643 @ 3.30GHz
Memory: 64GB DDR4 32GB ECC DDR3
HDD: 2x 1TB NVMe (SW Raid 1) 2x 240GB SSD (SW Raid 1)
Traffic: Unlimited @ 1000Mbit 2TB @ 1000MbitFrom the above table we can see that the German(/DE) node uses a recent, highly perfrmant desktop CPU backed by 64GB of non-ECC DDR4 RAM and an NVMe SSD storage while the NL's node has a 2K12 E5-class server CPU backed by 32GB ECC DDR3 RAM and SATA-based SSD storage.
With those specs in mind, we can now turn our attention into how my 2 NanoKVM VMs are doing on those 2 nodes, performance-wise. Before we get started, I must say that I will also break down this review into a series of posts each one dealing with one resource only.
In this post, I'll only pinpoint to the chipsets, ie the QEMU's machine type, used by NanoKVM VMs.
To answer the question of what virtual hardware did NanoKVM put into their NAT-VPS(s) ?
1. NanoKVM VMs Used Machine-type:
As shown below both NanoKVM VMs are using the most recent version of the old PC machine-type (ie pc-i440fx-5.2, as of QEMU version 5.2.0.) using the latest Seabios version: 1.14.0, released on Aug. 2020.
Code: (Select All)
[root @ natvps ~]# lshw
natvps.example.com
description: Computer
product: Standard PC (i440FX + PIIX, 1996)
vendor: QEMU
version: pc-i440fx-5.2
width: 64 bits
capabilities: smbios-2.8 dmi-2.8 vsyscall32
configuration: boot=normal uuid=xxxxxxxxx
*-core
description: Motherboard
physical id: 0
*-firmware
description: BIOS
vendor: SeaBIOS
physical id: 0
version: rel-1.14.0-0-xxxxxxxxxxxxxx-prebuilt.qemu.org
date: 0x/0x/201x
size: 96KiB
.......................Code: (Select All)
[root @ natvps ~]# lshw -businfo
Bus info Device Class Description
====================================================
system Standard PC (i440FX + PIIX, 1996)
bus Motherboard
memory 96KiB BIOS
............
pci@0000:00:00.0 bridge 440FX - 82441FX PMC [Natoma]
pci@0000:00:01.0 bridge 82371SB PIIX3 ISA [Natoma/Triton II]
............As we'll see going forward, both VMs are using the same virtual hardware config. The only difference I've noticed in the full output of 'lshw' command is that the DE node's VM is missing the memory virtio_balloon driver. This is demonstrated by listing the loaded virtIO drivers into the kernel:
> NL node VM:
Code: (Select All)
[root @ natvps_NL ~]# lsmod | grep virt
virtio_balloon 20480 0
virtio_net 53248 0
net_failover 24576 1 virtio_net
virtio_scsi 20480 2Code: (Select All)
[root @ natvps_DE ~]$ lsmod | grep virt
virtio_net 53248 0
net_failover 24576 1 virtio_net
virtio_scsi 20480 2We may comeback to this later..
Stay tuned for the next post!..