Problem:
There’s no configuration option anymore in the web ui for configuring disk sizes in Compute Profiles or Virtual Machines. Using Compute Profiles configured with n GB disks only creates a 10GB Disk.
Expected outcome:
VMs being created with the right Disk sizes.
Quick update: I’ve noticed that the pool in which the disks are being created is also wrong. Seems like the storage configuration is falling back to defaults if there are any.
I’ve found a workaround for this issue by updating the following file /usr/share/gems/gems/fog-libvirt-0.12.0/lib/fog/libvirt/models/compute/volume.rb with the appropriate values for the default pool name and default disk size.
Hello,
This seems like a bug. Was this behavior working previously, or is it new? Could you provide more details on the VM you’re creating? Which fields did you set in the UI that didn’t work? Is it image-based or network-based? I’m asking to determine if this PR might address some of your issues. Also, could you specify which fields you updated in volume.rb to fix that?
Hi, thanks for reaching out.
I’ve just noticed this behavior today but I’ve upgraded to 3.11 ~ 2 weeks ago.
This behavior did not occur with 3.10 so I’d consider it new.
I’m currently missing the fields for configuring the disk specifications of a compute profile.
If selecting a Compute Profile for the Libvirt host, all fields I have available in the GUI are:
‘Compute profile’
‘Compute resource’
‘CPUs’
‘CPU mode’
‘Memory’
‘Image’
Since I’m using Libvirt, I’m missing a config option to set the attribute for the pool in which to create the disk in as well as the option to specify the disk size.
I’m using Network Provisioning but this shouldn’t make a difference.
I’ve modified the following values in volume.rb:
the default pool name in the function default_pool_name accordingly
name = "local-vm-data"
the default disk size in the function defaults accordingly
:capacity => "32G",
The issue itself is not fixed, but I’m able to use this as a workaround for this environment to be able to provison hosts.
That’s weird… I don’t have a 3.11 instance to check that, but I didn’t find any code changes related to that. Maybe @lstejska knows something about it?
No errors besides Incorrect use of <label for=FROM ELEMENT> which I think is unrelated.
Could this be related to PostgreSQL or python? There were some python3.9 and postgresql updates today which I did. I did run a foreman-installer --scenario katello afterwards though.
Okay, I’ve found the root cause of the issue … it was caused by these packages:
# dnf -4y remove rubygem-fog-proxmox rubygem-foreman_fog_proxmox
Dependencies resolved.
==============================================================================================================================================================================================================================================================================
Package Architecture Version Repository Size
==============================================================================================================================================================================================================================================================================
Removing:
rubygem-fog-proxmox noarch 0.15.0-1.el8 @foreman-plugins 270 k
rubygem-foreman_fog_proxmox noarch 0.16.1-1.fm3_11.el8 @foreman-plugins 28 M
Removing unused dependencies:
rubygem-ipaddress noarch 0.8.3-1.el8 @foreman 65 k
Transaction Summary
==============================================================================================================================================================================================================================================================================
Remove 3 Packages
Freed space: 29 M
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Erasing : rubygem-foreman_fog_proxmox-0.16.1-1.fm3_11.el8.noarch 1/3
Running scriptlet: rubygem-foreman_fog_proxmox-0.16.1-1.fm3_11.el8.noarch 1/3
Erasing : rubygem-fog-proxmox-0.15.0-1.el8.noarch 2/3
Erasing : rubygem-ipaddress-0.8.3-1.el8.noarch 3/3
Verifying : rubygem-fog-proxmox-0.15.0-1.el8.noarch 1/3
Verifying : rubygem-foreman_fog_proxmox-0.16.1-1.fm3_11.el8.noarch 2/3
Verifying : rubygem-ipaddress-0.8.3-1.el8.noarch 3/3
Removed:
rubygem-fog-proxmox-0.15.0-1.el8.noarch rubygem-foreman_fog_proxmox-0.16.1-1.fm3_11.el8.noarch rubygem-ipaddress-0.8.3-1.el8.noarch
Complete!
I’ve checked the logs using foreman-tail 2>&1 when navigating to the compute profiles and I’ve noticed these lines:
2024-09-02T17:34:02 [I|app|3b6bf363] Deface: [WARNING] No :original defined for 'remove_networks_and_volumes_partial', you should change its definition to include:
3b6bf363 | :original => 'eb4c199bc19e113181e82700bff46538b01f8c44'
2024-09-02T17:34:02 [I|app|3b6bf363] Deface: [WARNING] No :original defined for 'remove_networks_and_volumes_partial', you should change its definition to include:
3b6bf363 | :original => '6dc2ea3d0067fe626ab69b442c12610b066eabf1'
2024-09-02T17:34:02 [E|app|3b6bf363] Deface: [ERROR] The original source for 'foreman_fog_proxmox/engine_add_from_profile_to_compute_form' has changed, this override should be reviewed to ensure it's still valid.
I’ve tested the proxmox integration a few months ago and seems like I’ve forgotten they were still on the system.
As of right now I think havin both libvirt and proxmox be present as compute resources could cause this issue. Any thoughts on this?
