Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Edison.su@citrix.com designates
 66.165.176.89 as permitted sender)
From: Edison Su <Edison.su@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Wed, 26 Sep 2012 14:08:35 -0700
Subject: RE: advice: trying to fix secondary/iso nfs storage on KVM
Thread-Topic: advice: trying to fix secondary/iso nfs storage on KVM
Thread-Index: Ac2cKnBR803BoxbeTXiUdoVDdzc8IgAAJlJA
Message-ID: 
 <C66C814C1ABFA8449FF65CB44953A8B4012CBB65BD41@SJCPMAILBOX01.citrite.net>
References: 
 <CALFpzo4-iJF+W1HG=ApqXpKyx4Ohipdxrvs0L_PTU0Yu5v2ohg@mail.gmail.com>
	<CALFpzo5k_ewQXn=0r7s-1X4WmcGJwrfZA5e9hMRLQXFZ=5_P2Q@mail.gmail.com>
	<C66C814C1ABFA8449FF65CB44953A8B4012CBB65BD40@SJCPMAILBOX01.citrite.net>
 <CALFpzo5nQK-EJC5qoyBPgwye4P9a8o7OBaKjppMV=nZeQXNoGA@mail.gmail.com>
In-Reply-To: 
 <CALFpzo5nQK-EJC5qoyBPgwye4P9a8o7OBaKjppMV=nZeQXNoGA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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
>=20
> 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.
>=20
> So would changing KVMStoragePoolManager.java to do getStoragePoolbyURI
> instead of getStoragePoolByUri be enough to fix?
>=20
> 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?