On 03/02/2015 11:12, Amit Shah wrote:
-S is just the same.
(just putting this in w/o actually checking..)
Does -S and -incoming differ in the 'do not read disks' case? I
recall we had to add consistency checks so that the destination qemu
didn't inadvertently read disk metadata on
On (Fri) 30 Jan 2015 [10:50:26], Paolo Bonzini wrote:
On 30/01/2015 10:38, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 01:21 PM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert
Eric Blake ebl...@redhat.com writes:
On 01/29/2015 08:15 AM, Daniel P. Berrange wrote:
./bin/qemu-system-x86_64 -nographic -nodefaults -qmp-command
{execute: migrate-set-capabilities,
arguments:{capabilities:[{capability:xbzrle,state:true}]}}'
-qmp-command '{execute:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 01:21 PM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
So what would the .args_type look like in qmp-commands.hx; something like
this?
.args-type =
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 29/01/2015 16:22, Dr. David Alan Gilbert wrote:
I'm a bit worried about whether starting an incoming migrate afterwards is
different in any subtle way. I can see there are a handful of devices that
have
On 30/01/2015 11:02, Dr. David Alan Gilbert wrote:
Yes; I've not got a clue what it's effect is, but given it's glued into
the block code I'm sure that breaking it will be subtle and nasty. I'm
also reasonably sure it's probably going to do something different in the
loadvm
case which is
Dr. David Alan Gilbert dgilb...@redhat.com writes:
* Markus Armbruster (arm...@redhat.com) wrote:
Dr. David Alan Gilbert dgilb...@redhat.com writes:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 29/01/2015 16:22, Dr. David Alan Gilbert wrote:
I'm a bit worried about whether starting an incoming migrate afterwards is
different in any subtle way. I can see there are a handful of devices that
have 'runstate_check(RUN_STATE_INMIGRATE)' calls in, and thus I'm not sure
that starting a
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 30/01/2015 10:38, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 01:21 PM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
On 30/01/2015 10:38, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 01:21 PM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
So what would the .args_type look like in
On Fri, Jan 30, 2015 at 09:38:50AM +, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 01:21 PM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
So what would the
Dr. David Alan Gilbert dgilb...@redhat.com writes:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 08:54 AM, Dr. David Alan Gilbert wrote:
The idea of a QMP command to trigger incoming
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 08:54 AM, Dr. David Alan Gilbert wrote:
The idea of a QMP command to trigger incoming migration looks
reasonable. We can probably use a qapi union for a nicer syntax,
something like:
{execute: migrate-incoming, arguments: {
From: Dr. David Alan Gilbert dgilb...@redhat.com
For an incoming migration it's potentially useful to be able to set
capabilities and parameters prior to opening the connection, while
a separate option for that would have been possible it seems better
to give access to all the existing migration
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
So what would the .args_type look like in qmp-commands.hx; something like
this?
.args-type = type:s,port:-i,host:-s,command:-s
No, it would be more like the blockdev-add interface, where one command
accepts a dictionary object
On Thu, Jan 29, 2015 at 03:06:37PM +, Dr. David Alan Gilbert (git) wrote:
From: Dr. David Alan Gilbert dgilb...@redhat.com
For an incoming migration it's potentially useful to be able to set
capabilities and parameters prior to opening the connection, while
a separate option for that
On Thu, Jan 29, 2015 at 03:22:55PM +, Dr. David Alan Gilbert wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Jan 29, 2015 at 03:06:37PM +, Dr. David Alan Gilbert (git)
wrote:
From: Dr. David Alan Gilbert dgilb...@redhat.com
For an incoming migration it's
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 08:15 AM, Daniel P. Berrange wrote:
./bin/qemu-system-x86_64 -nographic -nodefaults -qmp-command '{execute:
migrate-set-capabilities,
arguments:{capabilities:[{capability:xbzrle,state:true}]}}'
-qmp-command '{execute:
On Thu, Jan 29, 2015 at 03:46:35PM +, Dr. David Alan Gilbert wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Jan 29, 2015 at 03:22:55PM +, Dr. David Alan Gilbert wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Jan 29, 2015 at 03:06:37PM +,
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Jan 29, 2015 at 03:06:37PM +, Dr. David Alan Gilbert (git) wrote:
From: Dr. David Alan Gilbert dgilb...@redhat.com
For an incoming migration it's potentially useful to be able to set
capabilities and parameters prior to
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Jan 29, 2015 at 03:22:55PM +, Dr. David Alan Gilbert wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Jan 29, 2015 at 03:06:37PM +, Dr. David Alan Gilbert (git)
wrote:
From: Dr. David Alan Gilbert
On 01/29/2015 08:54 AM, Dr. David Alan Gilbert wrote:
The idea of a QMP command to trigger incoming migration looks
reasonable. We can probably use a qapi union for a nicer syntax,
something like:
{execute: migrate-incoming, arguments: {
type: tcp, port: 44 } }
vs.
{execute:
On 01/29/2015 08:15 AM, Daniel P. Berrange wrote:
./bin/qemu-system-x86_64 -nographic -nodefaults -qmp-command '{execute:
migrate-set-capabilities,
arguments:{capabilities:[{capability:xbzrle,state:true}]}}'
-qmp-command '{execute: query-migrate-capabilities}' -incoming tcp::444
I'm
On 01/29/2015 08:46 AM, Dr. David Alan Gilbert wrote:
Howver, something like:
-incoming pause
followed by the monitor command later should work - how do you feel
about that?
We still don't have a working QMP loadvm (right now, we rely on QMP-HMP
passthrough to do loadvm). Adding a
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 08:46 AM, Dr. David Alan Gilbert wrote:
Howver, something like:
-incoming pause
followed by the monitor command later should work - how do you feel
about that?
We still don't have a working QMP loadvm (right now, we rely
On 01/29/2015 01:21 PM, Dr. David Alan Gilbert wrote:
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
So what would the .args_type look like in qmp-commands.hx; something like
this?
.args-type = type:s,port:-i,host:-s,command:-s
No, it
* Eric Blake (ebl...@redhat.com) wrote:
On 01/29/2015 09:28 AM, Dr. David Alan Gilbert wrote:
So what would the .args_type look like in qmp-commands.hx; something like
this?
.args-type = type:s,port:-i,host:-s,command:-s
No, it would be more like the blockdev-add interface,
27 matches
Mail list logo
