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?

Reply via email to