Yeah, that's what we want. What generates a random one is the existing one we use, getStoragePoolByUri:
uuid = UUID.randomUUID().toString(); On Wed, Sep 26, 2012 at 3:19 PM, Edison Su <edison...@citrix.com> wrote: > After taking a look at the code carefully... What we really do is: don't > generate a random uuid, but using > uuid = UUID.nameUUIDFromBytes( > new String(sourceHost + > sourcePath).getBytes()).toString(); > instead. > >> -----Original Message----- >> From: Edison Su [mailto:edison...@citrix.com] >> Sent: Wednesday, September 26, 2012 2:09 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: advice: trying to fix secondary/iso nfs storage on KVM >> >> 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?
