I also notice that LibvirtComputingResource calls getStoragePoolByURI getStoragePoolByURI calls getStoragePoolByUri per KVMStoragePoolManager.java
in LibvirtStorageAdaptor there exists both getStoragePoolByUri and getStoragePoolbyURI. The latter looks like it generates a UUID based on the host/path of the secondary storage, and creates a storage pool based on it if needed. So I'm wondering if we are just calling the wrong one, although this is called many times in LibvirtComputingResource so perhaps we intend both behaviors at certain points. To recap: getStoragePoolByUri will always try to create a new nfs pool with a random UUID getStoragePoolbyURI attempts to generate a UUID from the sourcehost/path and uses that (static UUID) On Wed, Sep 26, 2012 at 2:10 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > I noticed that I can no longer create multiple VMs from ISO. After the > first one, I get an error where the agent is trying to create a > duplicate storage pool, throwing 'Storage source conflict with pool' > > In looking into it, it seems that with ISOs we call > getStoragePoolByURI with the path to the iso > > This generates a new random UUID and attempts to create a storage pool > with this UUID via createStoragePool > > createStoragePool first looks to see if the pool passed already > exists, which it doesn't since we just generated the UUID out of thin > air. Then it attempts to create a new storage pool, and voila, we get > the storage source conflict because we're trying to create a new > storage pool. > > So, I am left with a bunch of questions as to why it was done this > way. Should I find a way to pull the secondary storage's real UUID, > and use that in getStoragePoolByUri/createStoragePool, or should I > continue using a random UUID, but fix createStoragePool to look for an > existing storage source before trying to generate a new nfs storage > pool?
