Closed stove-panini closed 11 months ago
@stove-panini What exactly are you not finding? How to get the current chipset through fog-libvirt
or how to pass the value to the server.xml.erb
file?
@plribeiro3000 I'd like to pass the value to server.xml.erb
Hmmm. I don't blame you. it is kind of a mess here.
So all models include Fog::Libvirt::Util
which should be defined at fog/libvirt/util.rb
but is instead defined at fog/libvirt/models/compute/util/util.rb
.
This mixin has a method called to_xml
defined here:
def to_xml template_name = nil
# figure out our ERB template filename
erb = template_name || self.class.to_s.split("::").last.downcase
path = File.join(File.dirname(__FILE__), "..", "templates", "#{erb}.xml.erb")
template = File.read(path)
ERB.new(template, nil, '-').result(binding)
end
As you can see it pass the current object to the template so the ERB
template will have all attributes accessible as parameters.
This issue has been marked inactive and will be closed if no further activity occurs.
I opened https://github.com/fog/fog-libvirt/pull/94 which should make it easier to fix this.
This issue has been marked inactive and will be closed if no further activity occurs.
Could this issue be reopened? This is needed for running EL9 VMs.
q35 is documented as being the low bar for running EL9: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/assembly_feature-support-and-limitations-in-rhel-9-virtualization_configuring-and-managing-virtualization#recommended-features-in-rhel-9-virtualization_feature-support-and-limitations-in-rhel-9-virtualization
If it possible to configure libvirt to default to q35, I have not been able to figure out how to do so. Thus, in order to support EL9 VMs we either need to get changes merged into libvirt, fog-libvirt, or both.
Some libvirt background: today we don't set the machine at all. This means libvirt chooses a default. If you set it, you should query the capabilities using virConnectGetDomainCapabilities. This returns the various available machine types. For example on my Fedora 38 machine for x86_64:
<machine maxCpus='255'>pc-i440fx-7.2</machine>
<machine canonical='pc-i440fx-7.2' maxCpus='255'>pc</machine>
<machine maxCpus='288'>pc-q35-5.2</machine>
<machine maxCpus='255'>pc-i440fx-2.12</machine>
<machine maxCpus='255'>pc-i440fx-2.0</machine>
<machine maxCpus='1'>xenpv</machine>
<machine maxCpus='255'>pc-i440fx-6.2</machine>
<machine maxCpus='288'>pc-q35-4.2</machine>
<machine maxCpus='255'>pc-i440fx-2.5</machine>
<machine maxCpus='255'>pc-i440fx-4.2</machine>
<machine maxCpus='255'>pc-i440fx-5.2</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.5</machine>
<machine maxCpus='255'>pc-q35-2.7</machine>
<machine maxCpus='288'>pc-q35-7.1</machine>
<machine maxCpus='255'>pc-i440fx-2.2</machine>
<machine maxCpus='255'>pc-i440fx-2.7</machine>
<machine maxCpus='288'>pc-q35-6.1</machine>
<machine maxCpus='128'>xenfv-3.1</machine>
<machine canonical='xenfv-3.1' maxCpus='128'>xenfv</machine>
<machine maxCpus='255'>pc-q35-2.4</machine>
<machine maxCpus='255'>pc-i440fx-7.1</machine>
<machine maxCpus='288'>pc-q35-2.10</machine>
<machine maxCpus='1'>x-remote</machine>
<machine maxCpus='288'>pc-q35-5.1</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.7</machine>
<machine maxCpus='288'>pc-q35-2.9</machine>
<machine maxCpus='255'>pc-i440fx-2.11</machine>
<machine maxCpus='288'>pc-q35-3.1</machine>
<machine maxCpus='255'>pc-i440fx-6.1</machine>
<machine maxCpus='288'>pc-q35-4.1</machine>
<machine maxCpus='255'>pc-i440fx-2.4</machine>
<machine maxCpus='255'>pc-i440fx-4.1</machine>
<machine maxCpus='255'>pc-i440fx-5.1</machine>
<machine maxCpus='255'>pc-i440fx-2.9</machine>
<machine maxCpus='1'>isapc</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.4</machine>
<machine maxCpus='255'>pc-q35-2.6</machine>
<machine maxCpus='255'>pc-i440fx-3.1</machine>
<machine maxCpus='288'>pc-q35-2.12</machine>
<machine maxCpus='288'>pc-q35-7.0</machine>
<machine maxCpus='255'>pc-i440fx-2.1</machine>
<machine maxCpus='288'>pc-q35-6.0</machine>
<machine maxCpus='255'>pc-i440fx-2.6</machine>
<machine maxCpus='288'>pc-q35-4.0.1</machine>
<machine maxCpus='255'>pc-i440fx-7.0</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.6</machine>
<machine maxCpus='288'>pc-q35-5.0</machine>
<machine maxCpus='288'>pc-q35-2.8</machine>
<machine maxCpus='255'>pc-i440fx-2.10</machine>
<machine maxCpus='288'>pc-q35-3.0</machine>
<machine maxCpus='255'>pc-i440fx-6.0</machine>
<machine maxCpus='288'>pc-q35-7.2</machine>
<machine canonical='pc-q35-7.2' maxCpus='288'>q35</machine>
<machine maxCpus='288'>pc-q35-4.0</machine>
<machine maxCpus='128'>xenfv-4.2</machine>
<machine maxCpus='288'>microvm</machine>
<machine maxCpus='255'>pc-i440fx-2.3</machine>
<machine maxCpus='255'>pc-i440fx-4.0</machine>
<machine maxCpus='255'>pc-i440fx-5.0</machine>
<machine maxCpus='255'>pc-i440fx-2.8</machine>
<machine maxCpus='288'>pc-q35-6.2</machine>
<machine maxCpus='255'>pc-q35-2.5</machine>
<machine maxCpus='255'>pc-i440fx-3.0</machine>
<machine maxCpus='288'>pc-q35-2.11</machine>
That suggests to me you can use machine="q35"
and it should pick pc-q35-7.2
for you, while pc
is pc-i440fx-7.2
. https://specs.openstack.org/openstack/nova-specs/specs/wallaby/implemented/libvirt-default-machine-type.html describes that pc
is the default on x86_64.
I dug through the libvirt source a couple of months ago and it appeared that the default machine type is hardcoded with no config file mechanism to change the default. Unless we get an upstream change merged and included in EL9, our only option to support EL9 VMs is for fog to set the machine type at VM creation time.
https://github.com/fog/fog-libvirt/pull/127 aims to do exactly that.
127 aims to do exactly that.
Aye, I'm just offering justification as to why #127 makes sense.
Hi, I'm using this gem by way of Foreman's libvirt provider. I'm having trouble figuring out a non-hacky way to create a machine based on the newer Q35 chipset. Currently, I'm simply editing server.xml.erb and adding
machine='q35'
into the<os><type>
key and switching the IDE cdrom for a SATA one.I believe that changes to server.xml.erb are necessary insofar as replacing the Q35-incompatable IDE bus, but I'm having trouble finding a way to specify a machine's chipset from libvirt's Ruby API.
Any suggestions so that I could possibly get a real PR going?