On 02/10/2018 16:42, Andrew Cooper wrote: > On 02/10/18 15:19, Juergen Gross wrote: >> Add an option to specify the cpupool on the target machine when doing >> a migration of a domain. Currently a domain is always migrated to the >> cpupool with the same name as on the source machine. >> >> Specifying "-c <cpupool>" will migrate the domain to the specified >> cpupool on the target machine. Specifying an empty string for <cpupool> >> will use the default cpupool (normally "Pool-0") on the target machine. >> >> Signed-off-by: Juergen Gross <jgr...@suse.com> >> --- >> docs/man/xl.pod.1.in | 5 +++++ >> tools/xl/xl.h | 1 + >> tools/xl/xl_cmdtable.c | 3 +++ >> tools/xl/xl_migrate.c | 15 ++++++++++----- >> tools/xl/xl_saverestore.c | 10 +++++++++- >> 5 files changed, 28 insertions(+), 6 deletions(-) >> >> diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in >> index b74764dcd3..62f7c0f039 100644 >> --- a/docs/man/xl.pod.1.in >> +++ b/docs/man/xl.pod.1.in >> @@ -451,6 +451,11 @@ domain. See the corresponding option of the I<create> >> subcommand. >> Send the specified <config> file instead of the file used on creation of the >> domain. >> >> +=item B<-c> I<cpupool> >> + >> +Migrate the domain to the specified <cpupool> on the target host. Specifying >> +an empty string for <cpupool> will use the default cpupool on <host>. >> + > > Is this the wisest way to extend the interface? We already have -C to > specify new configuration, and only have 26*2 short options to use. > > What if the user could supply a xl.cfg snippet on the command line to be > merged over the existing configuration? That would allow any parameter > to be changed, rather than just the cpupool.
I'm not opposed to that suggestion, but I believe the cpupool is rather special: it is more like a migration target specification than a domain parameter. In case you are mostly concerned by burning another short option letter I can switch to using --cpupool= syntax. And TBH: I consider the -C option being quite dangerous. While I can understand why it is present it is still a rather hacky approach for a general problem. Same applies to the capability to modify random settings of the domain config. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
