incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: advice: trying to fix secondary/iso nfs storage on KVM
Date Wed, 26 Sep 2012 21:08:35 GMT
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