Hi, This patch fixed ''xm reboot'' to work as you expected with the wait option. The completion of a VM reboot is detected by observing that its Domain-ID changes. Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> Best regards, Kan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/8/06 11:20 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:> This patch fixed ''xm reboot'' to work as you expected with the wait > option. The completion of a VM reboot is detected by observing that > its Domain-ID changes. > > Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>What happens currently? Can ''xm reboot'' wait forever because it races the re-creation of the domain? We need a better test than domid. It''s not guaranteed that a domain will get a new domid when it restarts. Perhaps xend should support the wait option (since it is involved in the restart), or we could add a restart sequence count to xenstore (but xm oughtn''t to access xenstore directly). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Keir,>On 7/8/06 11:20 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote: > >> This patch fixed ''xm reboot'' to work as you expected with the wait >> option. The completion of a VM reboot is detected by observing that >> its Domain-ID changes. >> >> Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> > >What happens currently? Can ''xm reboot'' wait forever because it races the >re-creation of the domain? >Currently ''xm reboot --wait'' never ends. (But VM reboot is completed.) The wait option waits for the domain termination by chekcing current domain list (server.xend.domains). But the domain termination cannot be detected because the domain is recreated immediately.>We need a better test than domid. It''s not guaranteed that a domain will get >a new domid when it restarts. Perhaps xend should support the wait option >(since it is involved in the restart), or we could add a restart sequence >count to xenstore (but xm oughtn''t to access xenstore directly). >I will remake patch based on your advice. Best regards, Kan> -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, This patch fixed ''xm reboot'' to work as you expected with the wait option. This patch adds a restart sequence counter to xenstore. The completion of a VM reboot is detected by observing that its restart sequence counter changes. Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> Best regards, Kan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Could you possibly comment about this patch? http://lists.xensource.com/archives/html/xen-devel/2006-08/msg01125.html Best regards, Kan>Hi, > >This patch fixed ''xm reboot'' to work as you expected with the wait >option. This patch adds a restart sequence counter to xenstore. >The completion of a VM reboot is detected by observing that >its restart sequence counter changes. > > >Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> > >Best regards, > Kan > > >-------------------------------text/plain------------------------------- >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Aug 21, 2006 at 04:11:19PM +0900, Masaki Kanno wrote: Content-Description: Mail message body> Hi, > > This patch fixed ''xm reboot'' to work as you expected with the wait > option. This patch adds a restart sequence counter to xenstore. > The completion of a VM reboot is detected by observing that > its restart sequence counter changes. > > > Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>Applied, thank you. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I think it''d be neater to add a ''synchronous'' flag to the shutdown RPC, than to expose a restart counter to xm via a special new server command. Would it be hard to delay the RPC response in xend (and either have xend return a failure response on a timeout, or have xm wait for the RPC response on a timeout)? -- Keir On 28/8/06 2:04 pm, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:> Hi, > > Could you possibly comment about this patch? > > http://lists.xensource.com/archives/html/xen-devel/2006-08/msg01125.html > > Best regards, > Kan > >> Hi, >> >> This patch fixed ''xm reboot'' to work as you expected with the wait >> option. This patch adds a restart sequence counter to xenstore. >> The completion of a VM reboot is detected by observing that >> its restart sequence counter changes. >> >> >> Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> >> >> Best regards, >> Kan >> >> >> -------------------------------text/plain------------------------------- >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Keir, Could you teach about the ''synchronous flag'' in detail? Is the ''synchronous flag'' a interface that requests the response from xend to xm to be delayed until the reboot of domU is completed? Best regards, Kan> >I think it''d be neater to add a ''synchronous'' flag to the shutdown RPC, than >to expose a restart counter to xm via a special new server command. Would it >be hard to delay the RPC response in xend (and either have xend return a >failure response on a timeout, or have xm wait for the RPC response on a >timeout)? > > -- Keir > >On 28/8/06 2:04 pm, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote: > >> Hi, >> >> Could you possibly comment about this patch? >> >> http://lists.xensource.com/archives/html/xen-devel/2006-08/msg01125.html >> >> Best regards, >> Kan >> >>> Hi, >>> >>> This patch fixed ''xm reboot'' to work as you expected with the wait >>> option. This patch adds a restart sequence counter to xenstore. >>> The completion of a VM reboot is detected by observing that >>> its restart sequence counter changes. >>> >>> >>> Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> >>> >>> Best regards, >>> Kan >>> >>> >>> -------------------------------text/plain------------------------------- >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 31/8/06 3:56 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:> Hi Keir, > > Could you teach about the ''synchronous flag'' in detail? > Is the ''synchronous flag'' a interface that requests the response > from xend to xm to be delayed until the reboot of domU is completed? > > Best regards, > KanThat''s the idea, yes. It seems neater to have xend provide this feature directly rather than place detail sof its implementation in xm itself by making the ''restart counter'' available across RPC. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>On 31/8/06 3:56 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote: > >> Hi Keir, >> >> Could you teach about the ''synchronous flag'' in detail? >> Is the ''synchronous flag'' a interface that requests the response >> from xend to xm to be delayed until the reboot of domU is completed? >> >> Best regards, >> Kan > >That''s the idea, yes. It seems neater to have xend provide this feature >directly rather than place detail sof its implementation in xm itself by >making the ''restart counter'' available across RPC.Hi Keir, Currently, xm reboot command processing is the almost following sequences. Currently: ------------------------------+------------------------+--------------- xm |xend |domU(VM1) ------------------------------+------------------------+--------------- xm create VM1 | | | VM1.restart_count==0 | xm reboot VM1 | | VM1.getRestartCount() <-----------> | : Counter is 0 | | VM1.shutdown(''reboot'') <----------> | | VM1.shutdown <-----------> + | | | | | shutdown | | processing | | | VM1.getRestartCount() <-----------> | | : Counter is 0, no count up| <-------------- + | VM1.destroy | | VM1.create | | VM1.restart_count++ | | | VM1.getRestartCount() <-----------> | : Counter is 1, count up! | | | | info("Domain VM1 rebooted") | | | | ------------------------------+------------------------+--------------- If xm/xend implemented ''synchronous flag'' which was your idea, I think that xm reboot command is the almost following sequences. Am I right? Synchronous flag: ------------------------------+------------------------+--------------- xm |xend |domU(VM1) ------------------------------+------------------------+--------------- xm create VM1 | | | | xm reboot VM1 | | VM1.shutdown(''reboot'',sync)-------> | | | VM1.shutdown <-----------> + | | | | | | | shutdown | | | processing | | | | wait | | | | | <-------------- + | | VM1.destroy | V | VM1.create | <------- Completion response | | | info("Domain VM1 rebooted") | | | | ------------------------------+------------------------+--------------- If a user rebooted one VM, both implementations are the same for execute time of xm reboot command. However, xm reboot command has ''all'' option. If a user rebooted all VMs with ''all'' option, I think that the execute time of xm reboot command lengthen in proportion to the number of VM. Synchronous flag(--all): ------------------------------+------------------------+--------------- xm |xend |domU ------------------------------+------------------------+--------------- xm create VM1 | | xm create VM2 | | | | xm reboot --all | | VM1.shutdown(''reboot'',sync)-------> | | | VM1.shutdown <-----------> + | | | | | | | shutdown | | | processing | | | | wait | | | | | <-------------- + | | VM1.destroy | V | VM1.create | <------- Completion response | | | info("Domain VM1 rebooted") | | VM2.shutdown(''reboot'',sync)-------> | | | VM2.shutdown <-----------> + | | | | | | | shutdown | | | processing | | | | wait | | | | | <-------------- + | | VM2.destroy | V | VM2.create | <------- Completion response | | | info("Domain VM2 rebooted") | | | | ------------------------------+------------------------+--------------- As for the current implementation, if a user rebooted all VMs with ''all'' option, shutdown processing of each VM is executed in parallel. Best regards, Kan> > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel