On Fri, Sep 12, 2014 at 10:50:18AM +0100, Ian Campbell
wrote:> On Fri, 2014-09-12 at 10:31 +0100, Wei Liu wrote:
> > On Fri, Sep 12, 2014 at 10:29:09AM +0100, Ian Campbell wrote:
> > > On Fri, 2014-09-12 at 10:11 +0100, Wei Liu wrote:
> > > > On Fri, Sep 12, 2014 at 09:35:22AM +0100, Wei Liu wrote:
> > > > [...]
> > > > > I presume the pool name changed after the split and you
once speficied a
> > > > > pool name in your VM config file. If so:
> > > > >
> > > > > This is a limitation of xl. You can rename the pool
name to its original
> > > > > name (presumably "Pool-0") and try again. I
think this will be fixed in
> > > > > 4.5.
> > > > >
> > > >
> > > > Actually no. In the end we still need a way to transform a
pool name a
> > > > pool id. Without a daemon keeping track of the change
it's not likely to
> > > > be fixed in the future.
> > >
> > > I thought the pool name was stored in xenstore, in which case it
should
> > > be updated when the pol is renamed, shouldn't it?
> > >
> >
> > The culprit is that pool name stored in guest config is not updated...
>
> Oh right. That's a tricky one to resolve.
>
> In theory we could arrange to store the pool-id in the stashed config
> (e.g. after your json stuff), but then that probably doesn't work with
> migration (since poolname->poolid is per host, I think?).
>
The remote host will still use pool name to identify what pool to use.
> Iterating over all saved configs updating their pool-name doesn't
sounds
> very nice either.
>
This is my thought as well.
I'm now trying to figure out if this is a functional regression or
something never worked (hence the question to ask about "last working
version"). If that's a functional regression and users are very eager
to
get it fixed, we can figure out a way to fix it or workaround it.
Wei.
> Ian.