cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: advice: trying to fix secondary/iso nfs storage on KVM
Date Wed, 26 Sep 2012 20:58:37 GMT
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 []
> Sent: Wednesday, September 26, 2012 1:32 PM
> To:
> Subject: Re: advice: trying to fix secondary/iso nfs storage on KVM
> I also notice that LibvirtComputingResource calls getStoragePoolByURI
> getStoragePoolByURI calls getStoragePoolByUri per
> 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 <>
> 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?

View raw message