[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] txenmon: Cluster monitoring/management



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.