Yes, you are right, getStoragePoolbyURI is the right one.
> -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Wednesday, September 26, 2012 2:03 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: advice: trying to fix secondary/iso nfs storage on KVM > > It looks like the aforementioned getStoragePoolbyURI takes care of > this, that is it takes the host/path, generates a UUID based on it, > and then searches existing storage pools for it. If none is found, it > creates a new one, otherwise it uses the existing pool. > > So would changing KVMStoragePoolManager.java to do getStoragePoolbyURI > instead of getStoragePoolByUri be enough to fix? > > On Wed, Sep 26, 2012 at 2:58 PM, Edison Su <edison...@citrix.com> wrote: > > 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?
