01-07-2021, 07:00 AM
If you're still with me at this point then you're really serious about recreating a KVM VPS guest as close specs-wise as you can get/afford with your locally available resources. Thus, please, read on!
In the previous posts I've shown how to clone a block device over the network (Post #1) and how to build a KVM guest around it (Post #2). In this one, we'll learn how to fine-tune the virt-install command as to make it create a KVM VM that meets a set of requirements. As an example here, the requirements will be meeting Phoenix VPS-9 specs as close as possible in their details.
To achieve this goal we'll need 2 things:
Before we get started, I must say that I will break down this(/the original) post into a series of smaller less overwhelming posts approximating VirMach VPS-9 specs at each step of the way. Thus in this post, I'll only focus on VPS-9 chipsets, ie the QEMU's machine type.
Please be aware that I'm using Fedora Server 33 as my KVM host.
A Closer Look at VirMach VPS-9 Specs --Phoenix VPS-9 as an example
The first question we should try to answer is what virtual hardware did VirMach put in their P4V-sponsored VPS-9(s) ? To figure that out any VPS-9 holder can simply run the lshw command and read its output, like so in VPS-9@Buffalo:
For obvious reasons, I redacted the output but will show, subsequently, the relevant sections in more details by class of hardware.
1. VirMarch's VPS-9 Used Machine-type:
As shown above (in the core and pci section) and below (see system and businfo outputs), VPS-9 is using a dated 64bit version of the PC machine-type, which is an alias of pc-i440fx-rhel6.6.0 which still uses a rather outdated Seabios version: 0.5.1.
With the above information in mind, we're able to fine-tune our virt-install command like so:
Why setting the machine-type is important in this case?.. The answer is simply because not setting it will cause libvirt to use QEMU's current default value on Fedora which is 'q35' (Q35 + ICH9, 2009), while setting it to 'pc' (i440FX + PIIX, 1996) will set the machine-type to the most recent version of the old PC machine-type (ie pc-i440fx-5.1, as of now.)
If you need to use the most recent pc-i440fx-rhelx.x.x, then you need to use RHEL or CentOS as the KVM host.
In the next post we'll take a look at fine-tuning the guest CPU.
In the previous posts I've shown how to clone a block device over the network (Post #1) and how to build a KVM guest around it (Post #2). In this one, we'll learn how to fine-tune the virt-install command as to make it create a KVM VM that meets a set of requirements. As an example here, the requirements will be meeting Phoenix VPS-9 specs as close as possible in their details.
To achieve this goal we'll need 2 things:
- on the one hand, we need to know a bit more about VirMach's Phoenix VPS-9 internals and,
- on the other hand, we need to be familiar enough with the virt-intall command as to let it build a VM with that fine-tuned spec.
Before we get started, I must say that I will break down this(/the original) post into a series of smaller less overwhelming posts approximating VirMach VPS-9 specs at each step of the way. Thus in this post, I'll only focus on VPS-9 chipsets, ie the QEMU's machine type.
Please be aware that I'm using Fedora Server 33 as my KVM host.
A Closer Look at VirMach VPS-9 Specs --Phoenix VPS-9 as an example
The first question we should try to answer is what virtual hardware did VirMach put in their P4V-sponsored VPS-9(s) ? To figure that out any VPS-9 holder can simply run the lshw command and read its output, like so in VPS-9@Buffalo:
Code: (Select All)
[root @ kvm-Post2Host-.... ~]# lshw
kvm-post2host-buffalo
description: Computer
product: KVM
vendor: Red Hat
version: RHEL 6.6.0 PC
width: 64 bits
capabilities: smbios-2.4 dmi-2.4 smp vsyscall32
configuration: boot=normal family=Red Hat Enterprise Linux uuid=.................................
*-core
description: Motherboard
physical id: 0
*-firmware
description: BIOS
vendor: Seabios
physical id: 0
version: 0.5.1
date: 01/01/2007
size: 96KiB
*-cpu:0
description: CPU
product: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
vendor: Intel Corp.
physical id: 401
bus info: cpu@0
slot: CPU 1
size: 2GHz
capacity: 2GHz
width: 64 bits
capabilities: ...................__ENABLED_CPU_EXTENDIONS_LIST__.......................
*-cpu:1
description: CPU
product: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
vendor: Intel Corp.
physical id: 402
bus info: cpu@1
slot: CPU 2
size: 2GHz
capacity: 2GHz
width: 64 bits
capabilities: ...................__ENABLED_CPU_EXTENDIONS_LIST__.......................
*-memory
description: System Memory
physical id: 1000
size: 8GiB
capabilities: ecc
configuration: errordetection=multi-bit-ecc
*-bank
description: DIMM RAM
physical id: 0
slot: DIMM 0
size: 8GiB
width: 64 bits
*-pci
description: Host bridge
product: 440FX - 82441FX PMC [Natoma]
vendor: Intel Corporation
physical id: 100
bus info: pci@0000:00:00.0
version: 02
width: 32 bits
clock: 33MHz
*-isa
description: ISA bridge
product: 82371SB PIIX3 ISA [Natoma/Triton II]
vendor: Intel Corporation
physical id: 1
bus info: pci@0000:00:01.0
version: 00
width: 32 bits
clock: 33MHz
capabilities: isa bus_master
configuration: ......................
*-ide
description: IDE interface
product: 82371SB PIIX3 IDE [Natoma/Triton II]
vendor: Intel Corporation
physical id: 1.1
bus info: pci@0000:00:01.1
logical name: scsi1
version: 00
width: 32 bits
clock: 33MHz
capabilities: ide isa_compat_mode bus_master emulated
configuration: driver=ata_piix latency=0
resources: .......................
*-cdrom
description: SCSI CD-ROM
product: QEMU DVD-ROM
vendor: QEMU
physical id: 0.0.0
bus info: scsi@1:0.0.0
logical name: /dev/cdrom
logical name: /dev/sr0
version: 0.12
capabilities: removable audio
configuration: ......................
*-usb
description: USB controller
product: 82371SB PIIX3 USB [Natoma/Triton II]
vendor: Intel Corporation
physical id: 1.2
bus info: pci@0000:00:01.2
version: 01
width: 32 bits
clock: 33MHz
capabilities: uhci bus_master
configuration: driver=uhci_hcd latency=0
resources: ..................
*-usbhost
product: UHCI Host Controller
vendor: Linux ............ uhci_hcd
physical id: 1
bus info: usb@1
logical name: usb1
version: 4.18
capabilities: usb-1.10
configuration: .............
*-bridge
description: Bridge
product: 82371AB/EB/MB PIIX4 ACPI
vendor: Intel Corporation
physical id: 1.3
bus info: pci@0000:00:01.3
version: 03
width: 32 bits
clock: 33MHz
capabilities: bridge
configuration: driver=piix4_smbus latency=0
resources: ............
*-display
description: VGA compatible controller
product: GD 5446
vendor: Cirrus Logic
physical id: 2
bus info: pci@0000:00:02.0
version: 00
width: 32 bits
clock: 33MHz
capabilities: vga_controller rom
configuration: driver=cirrus latency=0
resources: .........................
*-network
description: Ethernet controller
product: Virtio network device
vendor: Red Hat, Inc.
physical id: 3
bus info: pci@0000:00:03.0
version: 00
width: 32 bits
clock: 33MHz
capabilities: msix bus_master cap_list rom
configuration: driver=virtio-pci latency=0
resources: ....................
*-virtio0
description: Ethernet interface
physical id: 0
bus info: virtio@0
logical name: eth0
serial: ...................
capabilities: ethernet physical
configuration: .......................
*-scsi
description: SCSI storage controller
product: Virtio block device
vendor: Red Hat, Inc.
physical id: 4
bus info: pci@0000:00:04.0
version: 00
width: 32 bits
clock: 33MHz
capabilities: scsi msix bus_master cap_list
configuration: driver=virtio-pci latency=0
resources: .....................................
*-virtio1
description: Virtual I/O device
physical id: 0
bus info: virtio@1
logical name: /dev/vda
size: ................................
*-volume:0
description: EXT3 volume
vendor: Linux
physical id: 1
bus info: virtio@1,1
logical name: /dev/vda1
logical name: /
version: 1.0
............................
*-volume:1
description: Linux swap volume
physical id: 2
bus info: virtio@1,2
logical name: /dev/vda2
version: 1
size: ..........................
*-memory
description: RAM memory
product: Virtio memory balloon
vendor: Red Hat, Inc.
physical id: 5
bus info: pci@0000:00:05.0
version: 00
width: 32 bits
clock: 33MHz (30.3ns)
capabilities: bus_master
configuration: driver=virtio-pci latency=0
resources: ...................
*-virtio2 UNCLAIMED
description: Virtual I/O device
physical id: 0
bus info: virtio@2
configuration: driver=virtio_balloon
*-pnp00:00
.....................................
[root@kvm-Post2Host-.... ~]#For obvious reasons, I redacted the output but will show, subsequently, the relevant sections in more details by class of hardware.
1. VirMarch's VPS-9 Used Machine-type:
As shown above (in the core and pci section) and below (see system and businfo outputs), VPS-9 is using a dated 64bit version of the PC machine-type, which is an alias of pc-i440fx-rhel6.6.0 which still uses a rather outdated Seabios version: 0.5.1.
Code: (Select All)
[root@vps-9 ~]# lshw -c system
my.hostname.com
description: Computer
product: KVM
vendor: Red Hat
version: RHEL 6.6.0 PC
width: 64 bits
capabilities: smbios-2.4 dmi-2.4 smp vsyscall32
configuration: boot=normal family=Red Hat Enterprise Linux uuid=.....
*-pnp00:00
product: PnP device PNP0b00
physical id: 0
capabilities: pnp
configuration: driver=rtc_cmos
[root@vps-9 ~]# lshw -businfo
Bus info Device Class Description
====================================================
system KVM
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]
......With the above information in mind, we're able to fine-tune our virt-install command like so:
Code: (Select All)
virt-install --virt-type=kvm --hvm --arch=x86_64 --machine=pc \
--name=centos8Phoenix \
--os-type=linux --os-variant=centos8 \
--ram=8192 --vcpus=2 \
--disk path=/media/phoenix.img \
--importWhy setting the machine-type is important in this case?.. The answer is simply because not setting it will cause libvirt to use QEMU's current default value on Fedora which is 'q35' (Q35 + ICH9, 2009), while setting it to 'pc' (i440FX + PIIX, 1996) will set the machine-type to the most recent version of the old PC machine-type (ie pc-i440fx-5.1, as of now.)
If you need to use the most recent pc-i440fx-rhelx.x.x, then you need to use RHEL or CentOS as the KVM host.
In the next post we'll take a look at fine-tuning the guest CPU.