"xl list --long" bug with only 1 CPU pool

"xl list --long" bug with only 1 CPU pool

[Olivier Bonvalet]

Hi,

on Xen 4.4, if you have only one CPU pool, "xl list --long" doesn't work
anymore, throwing error "Illegal pool specified" :

murmillia:~# xl cpupool-numa-split
murmillia:~# 
murmillia:~# xl cpupool-list
Name               CPUs   Sched     Active   Domain count
Pool-node0          16    credit       y         39
Pool-node1          16    credit       y          0
murmillia:~# 
murmillia:~# xl list --long | wc -l
8040

Here, it works fine.
Then I remove one cpupool :

murmillia:~# 
murmillia:~# xl cpupool-destroy Pool-node1
murmillia:~# 
murmillia:~# xl cpupool-list
Name               CPUs   Sched     Active   Domain count
Pool-node0          16    credit       y         39
murmillia:~# 
murmillia:~# xl list --long | wc -l
Illegal pool specified
0

Now, it doesn't work anymore.

Thanks for your work,
Olivier

Re: "xl list --long" bug with only 1 CPU pool

[Wei Liu]

On Thu, Sep 11, 2014 at 11:48:23PM +0200, Olivier Bonvalet wrote:
> Hi,
> 
> on Xen 4.4, if you have only one CPU pool, "xl list --long" doesn't work
> anymore, throwing error "Illegal pool specified" :
> 
> murmillia:~# xl cpupool-numa-split
> murmillia:~# 
> murmillia:~# xl cpupool-list
> Name               CPUs   Sched     Active   Domain count
> Pool-node0          16    credit       y         39
> Pool-node1          16    credit       y          0
> murmillia:~# 
> murmillia:~# xl list --long | wc -l
> 8040
> 
> Here, it works fine.
> Then I remove one cpupool :
> 
> murmillia:~# 
> murmillia:~# xl cpupool-destroy Pool-node1
> murmillia:~# 
> murmillia:~# xl cpupool-list
> Name               CPUs   Sched     Active   Domain count
> Pool-node0          16    credit       y         39
> murmillia:~# 
> murmillia:~# xl list --long | wc -l
> Illegal pool specified
> 0
> 
> Now, it doesn't work anymore.
> 

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.

Wei.

> Thanks for your work,
> Olivier
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: "xl list --long" bug with only 1 CPU pool

[Wei Liu]

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.

Does this ever work with xend? What's the last version of Xen you see it
working?

So in short, do change the pool name after you've created VMs in it. ;-)

Wei.

> Wei.
> 
> > Thanks for your work,
> > Olivier
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

Re: "xl list --long" bug with only 1 CPU pool

[Ian Campbell]

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?

Ian.

Re: "xl list --long" bug with only 1 CPU pool

[Wei Liu]

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...

Wei.

> Ian.

Re: "xl list --long" bug with only 1 CPU pool

[Ian Campbell]

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?).

Iterating over all saved configs updating their pool-name doesn't sounds
very nice either.

Ian.

Re: "xl list --long" bug with only 1 CPU pool

[Wei Liu]

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.