I see these save/restore updates in 'bk changes -R' -- my last pull was
Monday a week ago. And yes, using xc_dom_create.py for restore sounds
like exactly the right idea; had just hit that realization myself late
last night.
Pulling 1.2 at this instant; I'll exercise it and let you know how it
goes.
Steve
On Tue, Feb 10, 2004 at 07:55:36PM -0000, Williamson, Mark A wrote:
> > ...and a few other things. Right now migration is via reboot, not
> > suspend; haven't had a chance to troubleshoot resume further.
>
> We've improved the front-end to the resume functionality since you
> highlighted the problenm, so you may want to have a look at the modified
> tools if you have time.
>
> The previous version xc_dom_control.py just called linux_restore in the
> Xc library in order to reload a domain's memory state. That didn't
> recreate all of the VBDs, or set up the appropriate VFR (Virtual
> Firewall Router) state, which was the problem you'd experienced.
>
> I'm not sure what version of the tools you're using. We now use
> 'xc_dom_create.py' to start / restore domains - this can reads it's
> configuration from a file, using the '-f' option. We use
> xc_dom_control.py to control running domains.
>
> Using the latest tools stuff, you domains should be restored using
> xc_dom_create.py, specifying the original configuration file as usual,
> with the '-f' flag (which provides information for setting up the VFR /
> VBDs again) but also the domain memory state file, using the '-L' flag
> for 'Load domain state from file'. That way, the VBD / VFR state gets
> put back before the domain is restarted.
>
> Also, the save option of xc_dom_control.py is now 'suspend' and it stops
> and destroys the copy of the domain in memory after it has been
> suspended to disk (so it can't change it's persistent storage, etc.,
> which would otherwise confuse the image you if resume from file later).
>
> > This is all to support a production Xen cluster rollout that I plan to
> > have running by the end of this month. I really don't want to go back
> > to UML at this point, and if I don't have this cluster
> > running by March
> > I'm in deep doo-doo -- so I'm committed to working full-time on Xen
> > tools now. ;-}
>
> Thanks for the contribution! And good luck, too!
>
> Mark
>
--
Stephen G. Traugott (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@xxxxxxxxxxxxx
http://www.stevegt.com -- http://Infrastructures.Org
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home