This patch does two things to improve the current condition of suspend and resume: 1. Register ''xm resume'' with the xm command line argument parser so the corresponding xm_resume() function will be called. 2. Allow users to supply either a domain name, domid, or uuid to identify the target of a suspend or resume operation (instead of how it is now, where only a uuid will work). Signed-off-by: Chris Bookholt <hap10@tycho.ncsc.mil> There''s at least one additional problem (that this patch doesn''t address) effecting domains that are started, suspended, resumed, and finally shutdown. Affected domains remain in the xend''s list of running domains when instead they should revert back to a dormant state with domid of -1. A work around is to restart xend after the effected domains have been shutdown, which causes the domains to correctly appear as dormant, but clearly this restart shouldn''t be necessary. -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Nov 21, 2006 at 04:45:13PM -0500, Chris wrote:> This patch does two things to improve the current condition of suspend > and resume: > > 1. Register ''xm resume'' with the xm command line argument parser so the > corresponding xm_resume() function will be called. > > 2. Allow users to supply either a domain name, domid, or uuid to > identify the target of a suspend or resume operation (instead of how it > is now, where only a uuid will work). > > Signed-off-by: Chris Bookholt <hap10@tycho.ncsc.mil>Apologies are due to Chris for apparently plagiarising this patch -- I had missed his fixes and then subsequently addressed those same problems myself. Sorry about that, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Nov 21, 2006 at 04:45:13PM -0500, Chris wrote:> There''s at least one additional problem (that this patch doesn''t > address) effecting domains that are started, suspended, resumed, and > finally shutdown. Affected domains remain in the xend''s list of running > domains when instead they should revert back to a dormant state with > domid of -1. A work around is to restart xend after the effected > domains have been shutdown, which causes the domains to correctly appear > as dormant, but clearly this restart shouldn''t be necessary.I believe that this is fixed (or certainly, it''s better) with xen-unstable changeset 12566. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor wrote:> On Tue, Nov 21, 2006 at 04:45:13PM -0500, Chris wrote: > >> There''s at least one additional problem (that this patch doesn''t >> address) effecting domains that are started, suspended, resumed, and >> finally shutdown. Affected domains remain in the xend''s list of running >> domains when instead they should revert back to a dormant state with >> domid of -1. A work around is to restart xend after the effected >> domains have been shutdown, which causes the domains to correctly appear >> as dormant, but clearly this restart shouldn''t be necessary. > > I believe that this is fixed (or certainly, it''s better) with xen-unstable > changeset 12566. > > Ewan. >I think you''re right; seems to be fixed from what I can tell. However, I think found another problem. :) Rebooting a managed domain seems to fail with an exception that the rebooted domain''s name already exists. Clearly, the managed domain''s name does and should exist to Xend because it''s hanging out in the lifecycle area. There''s a call to checkName() in XendDomainInfo''s __init__() method that''s the source of the exception, though I''m debating the merits of where to make changes. It might be enough to relax checkName() to allow creation of XendDomainInfo instances with non-unique domain names if they only conflict with managed domains that are not running and soon to be replaced. Although, it would seem more safe if an existing XendDomainInfo instance were re-used when a reboot occurs. Any thoughts? Hopefully I can figure out how to implement the latter approach in the next day or two. Cheers -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Nov 29, 2006 at 11:22:46AM -0500, Chris wrote:> Ewan Mellor wrote: > > On Tue, Nov 21, 2006 at 04:45:13PM -0500, Chris wrote: > > > >> There''s at least one additional problem (that this patch doesn''t > >> address) effecting domains that are started, suspended, resumed, and > >> finally shutdown. Affected domains remain in the xend''s list of running > >> domains when instead they should revert back to a dormant state with > >> domid of -1. A work around is to restart xend after the effected > >> domains have been shutdown, which causes the domains to correctly appear > >> as dormant, but clearly this restart shouldn''t be necessary. > > > > I believe that this is fixed (or certainly, it''s better) with xen-unstable > > changeset 12566. > > > > Ewan. > > > > I think you''re right; seems to be fixed from what I can tell. > > However, I think found another problem. :) Rebooting a managed domain > seems to fail with an exception that the rebooted domain''s name already > exists. > > Clearly, the managed domain''s name does and should exist to Xend because > it''s hanging out in the lifecycle area. > > There''s a call to checkName() in XendDomainInfo''s __init__() method > that''s the source of the exception, though I''m debating the merits of > where to make changes. It might be enough to relax checkName() to allow > creation of XendDomainInfo instances with non-unique domain names if > they only conflict with managed domains that are not running and soon to > be replaced. Although, it would seem more safe if an existing > XendDomainInfo instance were re-used when a reboot occurs. > > Any thoughts?Yes, you''re right. I think we''re relying upon the fact that the XendDomainInfo instances aren''t necessarily unique, so I''ve put a fix in comparing the UUIDs of the VMs as specified on that instance. That should do the trick. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor wrote:> On Wed, Nov 29, 2006 at 11:22:46AM -0500, Chris wrote: > >> Ewan Mellor wrote: >>> On Tue, Nov 21, 2006 at 04:45:13PM -0500, Chris wrote: >>> >>>> There''s at least one additional problem (that this patch doesn''t >>>> address) effecting domains that are started, suspended, resumed, and >>>> finally shutdown. Affected domains remain in the xend''s list of running >>>> domains when instead they should revert back to a dormant state with >>>> domid of -1. A work around is to restart xend after the effected >>>> domains have been shutdown, which causes the domains to correctly appear >>>> as dormant, but clearly this restart shouldn''t be necessary. >>> I believe that this is fixed (or certainly, it''s better) with xen-unstable >>> changeset 12566. >>> >>> Ewan. >>> >> I think you''re right; seems to be fixed from what I can tell. >> >> However, I think found another problem. :) Rebooting a managed domain >> seems to fail with an exception that the rebooted domain''s name already >> exists. >> >> Clearly, the managed domain''s name does and should exist to Xend because >> it''s hanging out in the lifecycle area. >> >> There''s a call to checkName() in XendDomainInfo''s __init__() method >> that''s the source of the exception, though I''m debating the merits of >> where to make changes. It might be enough to relax checkName() to allow >> creation of XendDomainInfo instances with non-unique domain names if >> they only conflict with managed domains that are not running and soon to >> be replaced. Although, it would seem more safe if an existing >> XendDomainInfo instance were re-used when a reboot occurs. >> >> Any thoughts? > > Yes, you''re right. I think we''re relying upon the fact that the > XendDomainInfo instances aren''t necessarily unique, so I''ve put a fix in > comparing the UUIDs of the VMs as specified on that instance. That should do > the trick.I''ll be sure test your solution when it appears in the changelog list. There may be more than one way to skin this cat; for grins here is another way to approach the name conflict issue. This patch checks to see if the domain being rebooted is managed and, if so, calls XendDomain.domain_start() instead of calling XendDomain.domain_create(). I think the main advantage is Xend doesn''t tend toward creating non-unique XendDomainInfo instances. This may not mean much now, but in the future it might be a useful property, especially if the XendDomain.domain_lookup() implementation ever changes. I''ll leave that for you to decide. That said, don''t go replacing the patch you''ve written with this one because I hadn''t finished working out the kinks yet. Just consider this submission food for thought. Cheers -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel