Hi Vish,
On 10 August 2012 00:27, Vishvananda Ishaya wrote:
>
> On Aug 9, 2012, at 7:13 AM, "Daniel P. Berrange" wrote:
>
>>
>> With non-live migration, the migration operation is guaranteed to
>> complete. With live migration, you can get into a non-convergence
>> scenario where the guest is di
On Aug 9, 2012, at 7:13 AM, "Daniel P. Berrange" wrote:
>
> With non-live migration, the migration operation is guaranteed to
> complete. With live migration, you can get into a non-convergence
> scenario where the guest is dirtying data faster than it can be
> migrated. With the way Nova curre
On Thu, Aug 09, 2012 at 07:10:17AM -0700, Vishvananda Ishaya wrote:
>
> On Aug 9, 2012, at 1:03 AM, Blair Bethwaite wrote:
>
> > Hi Daniel,
> >
> > Thanks for following this up!
> >
> > On 8 August 2012 19:53, Daniel P. Berrange wrote:
> >> not tune this downtime setting, I don't see how you'
On Aug 9, 2012, at 1:03 AM, Blair Bethwaite wrote:
> Hi Daniel,
>
> Thanks for following this up!
>
> On 8 August 2012 19:53, Daniel P. Berrange wrote:
>> not tune this downtime setting, I don't see how you'd see 4 mins
>> downtime unless it was not truely live migration, or there was
>
> Ye
Daniel,
Thanks for providing this insight, most useful. I'm interpreting this
as: block migration can be used in non-critical applications, mileage
will vary, thorough testing in the particular environment is
recommended. An alternative implementation will come, but the higher
level feature (live-
Hi Daniel,
Thanks for following this up!
On 8 August 2012 19:53, Daniel P. Berrange wrote:
> not tune this downtime setting, I don't see how you'd see 4 mins
> downtime unless it was not truely live migration, or there was
Yes, quite right. It turns out Nova is not passing/setting libvirt's
VIR
>From memory (a fuzzy memory at that!) Nova will fallback to block migration
if believes shared storage is unavailable.
This would explain the delay, but someone who's read the code recently can
confirm...
Thanks,
Kiall
On Aug 8, 2012 11:08 AM, "Daniel P. Berrange" wrote:
> On Wed, Aug 08, 2012
On Tue, Aug 07, 2012 at 04:13:22PM -0400, Jay Pipes wrote:
> On 08/07/2012 08:57 AM, Blair Bethwaite wrote:
> >> I also feel a little concern about this statement:
> >>
> >>> It don't work so well, it complicates migration code, and we are building
> >>> a replacement that works.
> >>
> >>
> >> I
On Wed, Aug 08, 2012 at 09:50:20AM +0800, Huang Zhiteng wrote:
> > But to the contrary. I tested live-migrate (without block migrate)
> > last night using a guest with 8GB RAM (almost fully committed) and
> > lost any access/contact with the guest for over 4 minutes - it was
> > paused for the dura
On 08/07/2012 09:42 PM, Blair Bethwaite wrote:
> On 8 August 2012 11:33, Jay Pipes wrote:
>> Sorry, from your original post, I didn't think you were referring to
>> live migration, but rather just server migration. You had written
>> "Compared to regular (non-block) live migrate", but I read that
> But to the contrary. I tested live-migrate (without block migrate)
> last night using a guest with 8GB RAM (almost fully committed) and
> lost any access/contact with the guest for over 4 minutes - it was
> paused for the duration. Not something I'd want to do to a user's
> web-server on a regula
On 8 August 2012 11:33, Jay Pipes wrote:
> Sorry, from your original post, I didn't think you were referring to
> live migration, but rather just server migration. You had written
> "Compared to regular (non-block) live migrate", but I read that as
> "Compared to regular migrate" and thought you w
On 08/07/2012 08:23 PM, Blair Bethwaite wrote:
> Hi Jay,
>
> On 8 August 2012 06:13, Jay Pipes wrote:
>> Why would you find this surprising? I'm just curious...
>
> The live migration algorithm detailed here:
> http://www.linux-kvm.org/page/Migration, seems to me to indicate that
> only a brief
Hi Jay,
On 8 August 2012 06:13, Jay Pipes wrote:
> Why would you find this surprising? I'm just curious...
The live migration algorithm detailed here:
http://www.linux-kvm.org/page/Migration, seems to me to indicate that
only a brief pause should be expected. Indeed, the summary says,
"Almost un
On 08/07/2012 08:57 AM, Blair Bethwaite wrote:
> Hi Sébastien,
>
> Thanks for responding! By the way, I have come across your blog post
> regarding this and should reference it for the list:
> http://www.sebastien-han.fr/blog/2012/07/12/openstack-block-migration/
>
> On 7 August 2012 17:45, Sébas
Hi Sébastien,
Thanks for responding! By the way, I have come across your blog post
regarding this and should reference it for the list:
http://www.sebastien-han.fr/blog/2012/07/12/openstack-block-migration/
On 7 August 2012 17:45, Sébastien Han wrote:
> I think it's a pretty useful feature, a go
Hi!
I think it's a pretty useful feature, a good compromise. As you said using
a shared fs implies a lot of things and can dramatically decrease your
performance rather than using the local fs. I tested it and I will use it
for my deployment. I'll be happy to discuss more deeply with you about thi
17 matches
Mail list logo
