fog / fog-libvirt

libvirt provider for fog
MIT License
16 stars 42 forks source link

Q35 chipset support? #76

Closed stove-panini closed 11 months ago

stove-panini commented 4 years ago

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?

plribeiro3000 commented 4 years 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?

stove-panini commented 4 years ago

@plribeiro3000 I'd like to pass the value to server.xml.erb

plribeiro3000 commented 4 years ago

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.

github-actions[bot] commented 3 years ago

This issue has been marked inactive and will be closed if no further activity occurs.

ekohl commented 3 years ago

I opened https://github.com/fog/fog-libvirt/pull/94 which should make it easier to fix this.

github-actions[bot] commented 3 years ago

This issue has been marked inactive and will be closed if no further activity occurs.

jhoblitt commented 1 year ago

Could this issue be reopened? This is needed for running EL9 VMs.

jhoblitt commented 1 year ago

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.

ekohl commented 1 year ago

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.

jhoblitt commented 1 year ago

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.

ekohl commented 1 year ago

https://github.com/fog/fog-libvirt/pull/127 aims to do exactly that.

jhoblitt commented 1 year ago

127 aims to do exactly that.

Aye, I'm just offering justification as to why #127 makes sense.