On Tue, 2016-01-05 at 18:17 +, Ian Jackson wrote:
> So any code trying to use this for your snapshotting case is already
> broken and cannot be fixed without introducing a new API (probably one
> which generates separate suspend/unsuspend events).
Remus does seem to work at least to the exten
Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
> On 05/01/16 15:40, Ian Jackson wrote:
> > Would you like to prepare a patch ?
>
> I don't have a repro of the issue. This thread was merely me triaging
> an issue reported by Wen, given some `
On 05/01/16 15:40, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
>> On 04/01/16 17:46, Ian Jackson wrote:
>>> Suppose a domain goes into SHUTDOWN with reason code SUSPEND. Then
>>> later it is resumed again (perh
Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
> On 04/01/16 17:46, Ian Jackson wrote:
> > Suppose a domain goes into SHUTDOWN with reason code SUSPEND. Then
> > later it is resumed again (perhaps the migration failed). And later
> > it shuts
On 04/01/16 17:46, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
>> On 04/01/16 15:31, Ian Jackson wrote:
>>> * It is not possible to resume the domain in the source after it has
>>> suspended.
>> This function
Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
> On 04/01/16 15:31, Ian Jackson wrote:
> > * It is not possible to resume the domain in the source after it has
> > suspended.
>
> This functionality exists and is already used in several circ
On 04/01/16 15:31, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
>> On 25/12/2015 03:06, Wen Congyang wrote:
>>> Another problem:
>>> If migration fails after the guest is suspended, we will resume it in the
&g
On Mon, 2016-01-04 at 15:31 +, Ian Jackson wrote:
> [...]
> The daemonic xl exits in this situation because it expects the
> migration machinery to tidy up the domain.
>
> * It is not possible to resume the domain in the source after it has
> suspended.
Isn't supposed to be, isn't that
On Mon, 2016-01-04 at 15:31 +, Ian Jackson wrote:
>
> From 00c4fc6495078026d68f3fdd88bfd29a8ad483d7 Mon Sep 17 00:00:00 2001
> From: Ian Jackson
> Date: Mon, 4 Jan 2016 15:13:14 +
> Subject: [PATCH] libxl: Fix doc comment ref to DOMAIN_DEATH
>
> The doc comment for libxl_evdisable_domain
Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
> On 25/12/2015 03:06, Wen Congyang wrote:
> > Another problem:
> > If migration fails after the guest is suspended, we will resume it in the
> > source.
> > In this case, we cannot shutd
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 04 January 2016 10:36
> To: Paul Durrant; Wen Congyang
> Cc: xen devel; Ian Campbell; Ian Jackson; Wei Liu
> Subject: Re: [Xen-devel] question about migration
>
> On 04/01/16 1
On 04/01/16 10:28, Paul Durrant wrote:
>> -Original Message-
> [snip]
>>> We send the I/O request to the default I/O request server, but no backing
>>> DM hands it. We wil wait the I/O forever..
>> Hmm yes. This needs fixing.
>>
>> CC'ing Paul who did the ioreq server work.
>>
>> This
> -Original Message-
[snip]
> > We send the I/O request to the default I/O request server, but no backing
> > DM hands it. We wil wait the I/O forever..
>
> Hmm yes. This needs fixing.
>
> CC'ing Paul who did the ioreq server work.
>
> This bug is caused by the read side effects of
On 25/12/2015 03:06, Wen Congyang wrote:
On 12/25/2015 09:45 AM, Wen Congyang wrote:
On 12/24/2015 08:36 PM, Andrew Cooper wrote:
On 24/12/15 02:29, Wen Congyang wrote:
Hi Andrew Cooper:
I rebase the COLO codes to the newest upstream xen, and test it. I found
a problem in the test, and I can
On 25/12/2015 01:45, Wen Congyang wrote:
On 12/24/2015 08:36 PM, Andrew Cooper wrote:
On 24/12/15 02:29, Wen Congyang wrote:
Hi Andrew Cooper:
I rebase the COLO codes to the newest upstream xen, and test it. I found
a problem in the test, and I can reproduce this problem via the migration.
Ho
On 25/12/2015 00:55, Wen Congyang wrote:
On 12/24/2015 08:36 PM, Andrew Cooper wrote:
On 24/12/15 02:29, Wen Congyang wrote:
Hi Andrew Cooper:
I rebase the COLO codes to the newest upstream xen, and test it. I found
a problem in the test, and I can reproduce this problem via the migration.
On 12/25/2015 09:45 AM, Wen Congyang wrote:
> On 12/24/2015 08:36 PM, Andrew Cooper wrote:
>> On 24/12/15 02:29, Wen Congyang wrote:
>>> Hi Andrew Cooper:
>>>
>>> I rebase the COLO codes to the newest upstream xen, and test it. I found
>>> a problem in the test, and I can reproduce this problem via
On 12/24/2015 08:36 PM, Andrew Cooper wrote:
> On 24/12/15 02:29, Wen Congyang wrote:
>> Hi Andrew Cooper:
>>
>> I rebase the COLO codes to the newest upstream xen, and test it. I found
>> a problem in the test, and I can reproduce this problem via the migration.
>>
>> How to reproduce:
>> 1. xl cr
On 12/24/2015 08:36 PM, Andrew Cooper wrote:
> On 24/12/15 02:29, Wen Congyang wrote:
>> Hi Andrew Cooper:
>>
>> I rebase the COLO codes to the newest upstream xen, and test it. I found
>> a problem in the test, and I can reproduce this problem via the migration.
>>
>> How to reproduce:
>> 1. xl cr
On 24/12/15 02:29, Wen Congyang wrote:
Hi Andrew Cooper:
I rebase the COLO codes to the newest upstream xen, and test it. I found
a problem in the test, and I can reproduce this problem via the migration.
How to reproduce:
1. xl cr -p hvm_nopv
2. xl migrate hvm_nopv 192.168.3.1
You are the ve
Hi Andrew Cooper:
I rebase the COLO codes to the newest upstream xen, and test it. I found
a problem in the test, and I can reproduce this problem via the migration.
How to reproduce:
1. xl cr -p hvm_nopv
2. xl migrate hvm_nopv 192.168.3.1
The migration successes, but the vm doesn't run in the t
21 matches
Mail list logo
