Or perhaps better to modify the existing getStoragePoolByUri to fetch a libvirt connection and then call getStoragePoolbyURI
On Wed, Sep 26, 2012 at 3:03 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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?
