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.
(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.
Re-assigning to virt-manager, since the corresponding rhel-8 bug 2177837 shows virt-install as the app responsible
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.