incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: advice: trying to fix secondary/iso nfs storage on KVM
Date Wed, 26 Sep 2012 21:21:10 GMT
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.su@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.su@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:shadowsor@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.su@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:shadowsor@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
>> > <shadowsor@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?

Mime
View raw message