From: Juan Quintela <quintela@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Peter Xu <peterx@redhat.com>,
qemu-devel@nongnu.org, Laurent Vivier <lvivier@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState
Date: Fri, 09 Jun 2017 19:30:32 +0200 [thread overview]
Message-ID: <87lgp183wn.fsf@secure.mitica> (raw)
In-Reply-To: <877f0lgsxu.fsf@dusky.pond.sub.org> (Markus Armbruster's message of "Fri, 09 Jun 2017 16:02:37 +0200")
Markus Armbruster <armbru@redhat.com> wrote:
> Test compile gripes:
>
> hw/xen/xen-common.c: In function ‘xen_init’:
> hw/xen/xen-common.c:147:5: warning: implicit declaration of function ‘register_compat_prop’ [-Wimplicit-function-declaration]
> register_compat_prop("migration", "store-global-state", "off");
> ^~~~~~~~~~~~~~~~~~~~
> hw/xen/xen-common.c:147:5: warning: nested extern declaration of ‘register_compat_prop’ [-Wnested-externs]
>
> You might want to install Xen development packages to catch such issues
> earlier.
>
> Test run:
>
> $ qemu-system-x86_64 -device migration,help
> migration.skip-section-footer=bool
> migration.store-global-state=bool
> migration.only-migratable=bool
> migration.skip-configuration=bool
>
> What would adding this device do?
Parameters, capabilities, options for migration.
This was what we discussed on irc. We want to have a way to control
migration features that depend on versions.
So we disable new features for old machine types (normal thing that we
do). But right now, creating such a new feature requires creating a
couple of functions to set/clear the feature, adding includes on the
destination side, etc.
This was supposed to be a global property (or a qemu_opt, or whatever).
Just something that could be enabled/disabled easily on machine types,
and if possible independently of machine types. This (for instance)
would allow that store-global-state is disabled by defaulte for
machine-2.9 (I forgot the exact name for the machine type), but I can
enable it by hand. That is very handy for testing.
So, I think that the question is, how/where can we set that kind of
properties?
At least for me, being able to *also* set migration
capabilities/parameters with this mechanism on the command line would be
very nice, for instance
-global migration.xbzrle on
or
-global migration.max-speed 2G
I don't care about what is the exact syntax, or where we hang them,
i.e. a new device, a new list, somewhere that already exist. That is
what we ask for advice.
Thanks for the review and the suggestions.
Later, Juan.
next prev parent reply other threads:[~2017-06-09 17:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 3:48 [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState Peter Xu
2017-06-09 3:48 ` [Qemu-devel] [PATCH v2 1/6] machine: export register_compat_prop() Peter Xu
2017-06-09 7:41 ` Juan Quintela
2017-06-09 3:48 ` [Qemu-devel] [PATCH v2 2/6] migration: let MigrationState be a qdev Peter Xu
2017-06-09 7:42 ` Juan Quintela
2017-06-09 13:39 ` Markus Armbruster
2017-06-12 4:46 ` Peter Xu
2017-06-12 16:13 ` Eduardo Habkost
2017-06-13 3:52 ` Peter Xu
2017-06-13 11:27 ` Eduardo Habkost
2017-06-19 9:09 ` Markus Armbruster
2017-06-21 9:28 ` Peter Xu
2017-06-09 3:48 ` [Qemu-devel] [PATCH v2 3/6] migration: move global_state.optional out Peter Xu
2017-06-09 7:43 ` Juan Quintela
2017-06-09 13:40 ` Eduardo Habkost
2017-06-09 17:33 ` Juan Quintela
2017-06-12 8:18 ` Peter Xu
2017-06-13 3:41 ` Peter Xu
2017-06-13 11:16 ` Eduardo Habkost
2017-06-14 2:52 ` Peter Xu
2017-06-16 7:58 ` Peter Xu
2017-06-16 14:34 ` Eduardo Habkost
2017-06-19 6:31 ` Peter Xu
2017-06-09 3:49 ` [Qemu-devel] [PATCH v2 4/6] migration: move only_migratable to MigrationState Peter Xu
2017-06-09 7:43 ` Juan Quintela
2017-06-09 3:49 ` [Qemu-devel] [PATCH v2 5/6] migration: move skip_configuration out Peter Xu
2017-06-09 7:45 ` Juan Quintela
2017-06-09 3:49 ` [Qemu-devel] [PATCH v2 6/6] migration: move skip_section_footers Peter Xu
2017-06-09 7:47 ` Juan Quintela
2017-06-09 8:39 ` Peter Xu
2017-06-09 10:47 ` Eric Blake
2017-06-12 4:37 ` Peter Xu
2017-06-09 7:48 ` [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState Juan Quintela
2017-06-09 8:40 ` Peter Xu
2017-06-09 14:02 ` Markus Armbruster
2017-06-09 17:30 ` Juan Quintela [this message]
2017-06-12 7:24 ` Peter Xu
2017-06-19 8:58 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgp183wn.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=lvivier@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.