The latest libvirt(bundled in rhel 6.3) has this limitation, you can't create duplicate storage pool with the same host/path, thus breaks some of the logic in the current code. To fix the issue, we need to list all the available storage pools on kvm host, check one by one: if any one of storage pools has the same attribute(for nfs, it's host and path, for dir storage, it's path) as we are looking for, then return.
> -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Wednesday, September 26, 2012 1:32 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: advice: trying to fix secondary/iso nfs storage on KVM > > 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?
