[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] libxl: modify domain config when moving domain to another cpupool



On Wed, Oct 3, 2018 at 12:45 PM George Dunlap <dunlapg@xxxxxxxxx> wrote:
>
> On Wed, Oct 3, 2018 at 12:29 PM Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >
> > On Wed, Oct 03, 2018 at 12:02:24PM +0100, George Dunlap wrote:
> > > On Tue, Oct 2, 2018 at 3:20 PM Juergen Gross <jgross@xxxxxxxx> wrote:
> > > >
> > > > Today the domain config info contains the cpupool name the domain was
> > > > started in only if the cpupool was specified at domain creation. Moving
> > > > the domain to another cpupool later won't change that information.
> > > >
> > > > Correct that by modifying the domain config accordingly.
> > > >
> > > > Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> > >
> > > Would it be better to do this the same way the scheduling parameters
> > > was done -- by adding this to libxl_retrieve_domain_configuration()?
> > > That way the cpupool would show up in `xl list -l` as well (I think).
> >
> > This already modifies the saved state file, there will not be mismatch
> > between the saved state and the state in hypervisor. `xl list -l` should
> > work just fine.
>
> If you do it Juergens way, `xl list -l` will show things you have
> *changed*, but not the defaults.  If you do it the way the scheduling
> parameters was done, the pool name will be shown even if there was no
> pool specified in the config file, nor the vm migrated from the
> default pool to a different one.

But of course, we have the same problem that if the cpupool doesn't
exist on the far side, the migration will fail (I'm guessing?).  I
think this is surprising, and at very least undocumented.  Is it worth
considering having it fall back to the default cpupool instead?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.