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 meta
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. Da
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
* 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 'runstate_check(RUN_STATE_I
* 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
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 startin
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 w
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 loo
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" 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/20
* 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?
>
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" 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:
Eric Blake 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": "query-migrate
"Dr. David Alan Gilbert" 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 mig
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,comman
* 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 i
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
* 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", "a
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 } }
>> v
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
* 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 (righ
* 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-comm
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). Addin
* 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
* 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"
> >
> > For an incoming migration it's potentially useful to be able to set
> > capabilities and parameters prior to opening the con
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"
> > >
> > > For an incoming migration it's potent
On Thu, Jan 29, 2015 at 03:06:37PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> 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
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"}' -inc
From: "Dr. David Alan Gilbert"
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 capabilities, para
28 matches
Mail list logo
