Custom Machine Types

I

i8degrees

Member
Mar 29, 2023
12
2
8
Hi you guys,

I am seeking advice on how I might best tackle an issue I have with my setup with Proxmox VE. I shall do my best here to keep my issue as brief and straight to the point as possible; I may omit details that may end up proving vital -- please ask and I will respond back accordingly.

My main workstation -- **pve1.home** -- is a Proxmox `v8.3` node in a three node cluster (*non HA*). I have three operating systems that I maintain for the purpose of software development and the occasional video game. The triple boot setup is:

- Manjaro KDE Linux
- Windows 11 Home x86-64
- MacOS Montery

All three are virtual machines and are of the machine type `pve-q35-XXX`. In order for me to boot MacOS Montery with working audio -- SPDIF optical audio output (digital) and 3.5" stereo jack output (analog) -- requires me to use a `pve-q35.cfg` without an `[audio0]` definition [10], else it conflicts with the OS boot and is unable to recognize the hardware.

If you take a look at `/usr/share/qemu-server/pve-q35.cfg`, you should find somewhere along there a `audio0` definition. Here is what it looks like on my system:

```shell
# FIXME: Remove this audio0 device at the next possible time
# see: https://pve.proxmox.com/pipermail/pve-devel/2019-July/038417.html
# https://pve.proxmox.com/pipermail/pve-devel/2019-July/038428.html
[device "audio0"]
driver = "ich9-intel-hda"
bus = "pcie.0"
addr = "1b.0"
```

When I remove this audio definition from `pve-q35.cfg`, MacOS boots without woes; but I must change it back to the original before I can boot Linux or Windows again with working audio.

I will save you the headache of the underlying reasons here within MacOS as to why I must have it specifically programmed to use the `1b.0f` device and none other. Suffice to say: yes, I do not have nay other choice here, other than to not use the integrated audio chipset. I will not accept defeat!

So, my question essentially is: how might I specify a specific, custom machine type, i.e.: `/usr/share/qemu-server/pve-q35-macos.cfg` in the VM configuration file at `/etc/pve/qemu-server/XXX.conf`?

I have been looking through the source at `/usr/share/perl5/PVE/QemuServer/Machine.pm` where the machine types and variants appear to be defined at. I can see how I could probably add a variant myself, but then I would have to deal with merging my modifications with every new release that dares touch the file(s). I do not wish to do this if at all possible!

I could maybe also inject a file swap during init with a hook script. I do not much care for this idea :-/

In summary, I am searching for a method of specifying my own machine definition type in the VM configuration -- one without the audio0 device definition -- so I can apply the machine variant version to only one VM configuration and then leave the others as-is. All would be well if I could figure this out! :-D

I sincerely appreciate any and all suggestions whatsoever!

Cheers,
Jeff

---

P.S. I have read through all of the mailing list entries. It would appear that the proposal may have been forgotten about, or perhaps shelved for a future date. The developers mention precisely the issue that I have ran into here. I am imagining that this issue I have is why there has yet to be consensus among the developers as to how to handle this? I suppose I must ask on the mailing list in hopes of receiving an answer.

"scorpio" (pve1.home) is a Gigabyte `GA-Z97-UD5H REV 1.2` motherboard with an Intel i7-4790k CPU running on the Haswell era architecture with a Intel 9 Series Chipset Family HD Audio Controller with integrated Realtek codecs
 
Last edited:
I too would love to have that entry removed or at least configurable.

From what I can tell, this old hardcoded config file based Q35 setup is a nightmare because it also ties into live migration.

Personally I believe it needs redesigning/refactoring to allow end user configurability within the Proxmox UI, ie. have the default, but allow configurability per VM.
 
So happy to finally see somebody chime in on this thread! :-) From what I have gathered from grepping through the Perl sources and all, I cannot but agree with you whole hardheartedly; it appears to be in dire need of reconsideration by developer(s) that really know that area and its history and such. I feel that any such modification I dare make would only make things worse as I do not have anything close to the intimacy required I'm afraid.

I suppose that my next step in consideration may be to try and pick up the developer thread linked from back in 2019 as seen here:

```shell
# /usr/share/qemu-server/pve-q35-4.0.cfg
# ...
# FIXME: Remove this audio0 device at the next possible time
# see: https://pve.proxmox.com/pipermail/pve-devel/2019-July/038417.html
# https://pve.proxmox.com/pipermail/pve-devel/2019-July/038428.html
#[audio0]
#...
```

For whatever it is worth, I have made an attempt at overriding the `pve-q35-4.0.cfg` file that gets passed in via `readconfig` in a `args:` in my Proxmox VM configuration file, but I have yet to ever pull the feat off. On occasion, I have tried various formations as the thought passes through my mind... I think one of these days, I may well figure it out! :-D

I can certainly conceive of some rather nasty ways of forcing the file I want read in -- memory pointers indirection, etc but this defeats the whole point of what I ultimately wish to achieve. Ah well... I have not had the time to mess with it as of late.
 
Totally understand you, we can do all kinds of wizardy to make things work the way we want, problem is, it defeats the point of having the virtual management environment in the first place, then we get put-off because ongoing support and management of all the custom tweaks across upgrades just becomes a headache.

TBF, the whole internally coded kvm commandline generation thing with a locked down web-ui is quite limited when it comes to the latest and greatest things QEMU can do. Passing pointers for example just can't work via the UI. I've often thought that it would be nice if one could assign a custom script to a particular VM instantiation logic where we can generate our own KVM commandline.

In the end, I just pool some VMs off to another physical host that I ended up investing in to run a bare linux host with QEMU directly via scripts, not ideal, but that is what Linux is all about.

This thread I started earlier today, relative to this same hardcoded config file:
D

Thread 'Proxmox Devs: Please could you modernize the arcane forced default USB controllers logic??'

This has been requested on a few occasions over the years, but to this day, Proxmox still forces these USB controllers into VMs.
Ovirt and other QEMU/KVM environments don't do it, but Proxmox likes to keep these legacy things hardcoded still in there, really annoying.

I checked the code and it is hard-coded in the file: /usr/share/perl5/PVE/QemuServer.pm

Perl: 
# add usb controllers
    my @usbcontrollers =
        PVE::QemuServer::USB::get_usb_controllers($conf, $bridges, $arch, $machine_version);
    push @$devices, @usbcontrollers if @usbcontrollers;


With modern QEMU, I directly add...
 
Last edited:
You must log in or register to reply here.
Top Bottom