Bug 2177835

Summary: When provisioning multiple VMs with ISOs from Satellite, deployment fails because of storage pool name conflicts
Product: Red Hat Enterprise Linux 7 Reporter: Allie DeVolder <adevolder>
Component: virt-managerAssignee: virt-mgr-maint
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.9CC: berrange, gveitmic, hongzliu, juzhou, tyan, tzheng
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-15 21:08:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2177837    
Bug Blocks:    

Description Allie DeVolder 2023-03-13 16:43:19 UTC
Description of problem: 

When provisioning multiple VMs with ISOs from Satellite, deployment fails because of storage pool name conflicts

Version-Release number of selected component (if applicable):
libvirt-4.5.0-36.el7_9.5.x86_64

How reproducible:
100%


Steps to Reproduce:
1. Provision multiple VMs from Satellite using ISOs for boot media

Actual results:

VMs fail to be created because libvirt creates a storage pool for the provided ISO using a name based on the ISO specified, so other VMs fail because that storage pool name is already in use.

Expected results:

Multiple VMs provisioned as expected from Satellite.

Additional info:

This can be worked around by implemented a time delay between VMs, but this is severely hindering in a production environment.

Comment 3 Daniel Berrangé 2023-03-14 10:31:49 UTC
(In reply to Allie DeVolder from comment #0)
> Description of problem: 
> 
> When provisioning multiple VMs with ISOs from Satellite, deployment fails
> because of storage pool name conflicts

snip

> VMs fail to be created because libvirt creates a storage pool for the
> provided ISO using a name based on the ISO specified, so other VMs fail
> because that storage pool name is already in use.

Libvirt just uses the storage pool name that it is told to use by the client application.

IOW, the problem of picking non-unique pool names originates in whatever code Satellite is running to provision the VM, rather than in libvirt.

Comment 4 Daniel Berrangé 2023-03-14 10:33:31 UTC
Re-assigning to virt-manager, since the corresponding rhel-8 bug 2177837 shows virt-install as the app responsible

Comment 6 John Ferlan 2023-08-15 21:08:45 UTC
CLOSEing as WONTFIX. There is very little likelihood of any fix being implemented for RHEL7 mainly due to resources.  The work around suggested in the dependent bug 2177837 using a retry timeout loop should work fine in RHEL7 too.