[Fwd: Re: File-backed VBDs Migration help]

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: File-backed VBDs Migration help]

Jonathan Wheeler
James Bulpin wrote:

> Jonathan,
>
> If you only want migration for maintanence purposes then you could
> probably put up with a small downtime during the migration. How about
> having your "migrate" sequence as:
>
> xm save mydomain /path/mydomain.save
> rcp [or whatever] /path/mydomain.save otherhost:/path/mydomain.save
> rcp /path/mydomain-vbd.img otherhost:/path/mydomain-vbd.img
>
> then on otherhost:
>
> xm restore /path/mydomain.save
>
> (Disclaimer: I've not tried this but I can't see any reason why it
> wouldn't work.)
>
> Downtime would be dictated by the size of your save and vbd files and
> the speed of the network between the hosts.
>
> James

Thanks James,

I tried that out, and it appeared to work ok. The guest didn't pick up
the new time, but perhaps that's just how it works - I'm still rather
new to all this.

I would definitely prefer to not have the downtime associated with
copying the larger images across the network.
Do I have any other options that don't involve using a nfs server as a
single point of failure?

Thanks,
Jonathan.



_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: File-backed VBDs Migration help]

James Bulpin
Jonathan,

An alternative to using file-backed VBDs would be DRBD on top of local
disk partitions. DRBD will allow you to have mirrored volumes on the
source and target machines of the migration. DRBD will allow background
synchronisation of the replicas so that are almost in sync before you
perform the migration (or lazy synchronisation after the migration).
There still has to be a step where the domain stops and the DRBD
primary/secondary assignment is changed. This will generally be quick.

This can be most easily done using save and restore with drbd primary
and secondary commands issued between saving and restoring. I have done
this with non-live migration (which is essentially just save and restore
without having to have a named file) but it required a very dirty hack
to libxc.

There has been some discussion here recently of DRBD which you may want
to look at.

Regards,

James

Jonathan Wheeler wrote:

> James Bulpin wrote:
>
>
>>Jonathan,
>>
>>If you only want migration for maintanence purposes then you could
>>probably put up with a small downtime during the migration. How about
>>having your "migrate" sequence as:
>>
>>xm save mydomain /path/mydomain.save
>>rcp [or whatever] /path/mydomain.save otherhost:/path/mydomain.save
>>rcp /path/mydomain-vbd.img otherhost:/path/mydomain-vbd.img
>>
>>then on otherhost:
>>
>>xm restore /path/mydomain.save
>>
>>(Disclaimer: I've not tried this but I can't see any reason why it
>>wouldn't work.)
>>
>>Downtime would be dictated by the size of your save and vbd files and
>>the speed of the network between the hosts.
>>
>>James
>
>
> Thanks James,
>
> I tried that out, and it appeared to work ok. The guest didn't pick up
> the new time, but perhaps that's just how it works - I'm still rather
> new to all this.
>
> I would definitely prefer to not have the downtime associated with
> copying the larger images across the network.
> Do I have any other options that don't involve using a nfs server as a
> single point of failure?
>
> Thanks,
> Jonathan.
>
>
>
> _______________________________________________
> Xen-users mailing list
> [hidden email]
> http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users