>>> On 7/17/2008 at 12:45 PM, in message <[EMAIL PROTECTED]>, Ivan <[EMAIL PROTECTED]> wrote: > Hi, > >> Hmm, stop used to be xm shutdown -w >> (at least as coded originally... >> then Xen 3.2 added its registration ideas; >> and I guess various changes have been made; >> so that e.g. if Heartbeat is managing the >> Xen VM; it's defined also via xm new, since we >> wanted the VM to also be visible to other tools >> that depend on registration - e.g. virtman...)
Hi > Excuse me for a bit of an irrelevant hijack but why is this fuzz about > xenstore or I just missed something? (xm new, xenstore sync, etc) Not irrelevant at all ;-) good feedback below and pretty much aligned with our thinking at the time. Jfyi: the original Xen RA was published here: http://lists.community.tummy.com/pipermail/linux-ha/2006-March/018798.html Which I wrote for Xen 3.x in SLES10 at that time (Lars and I did a joint-demo at a conference, of VMs failing over across an IBM Blade rack). > Xenstore is not necessary for HA managed VMs is it? We need few lines of I can't think of any reason; unless considering e.g. authorized definition of VMs as part of a security infrastructure (e.g. can only run registered VMs, and need authn&authz to register and invoke life cycle ops etc). > config to start, stop, monitor, migrate the VM resources by HA, this is Start was originally coded: xm create $OCF_RESKEY_xmfile name=$DOMAIN_NAME and stop xm shutdown -w $DOMAIN_NAME > it. Once the VM is HA managed no traditional management tool should be > used for VMs like xm and virtman or HA gets confused. Right, two brains are generally bad... If Heartbeat is in charge of the resource, then out-of-band control is generally a cause of confusion, same as e.g. umounting a fs behind heartbeat's back... Once the VM is "under management" (by Heartbeat) so to speak, then other managers should not be invoked. > Currently I deleted all my VMs from xenstore, when all shut down virtman > shows nothing. When xm create <> starts a resource virtman will display It's been a while, but iirc, registered VMs still show up even if not running; because they are still known/declared resources to Xen... > the running VM so if you need the GUI graphs, etc you can still have it Yes, that was one of the reasons, wanting to leverage other Xen tools that display graphs / status etc for VMs even if running under Heartbeat's control. > but nobody should manage the VM (start/stop, etc) without notifying HA > so monitoring is the only thing it's useful for. nod. > Perhaps that's the basic usage and something just cannot be stored in xm > config files. If so what is it? Afaik today, it's still possible to start a VM without registering it, and iirc that's still enough also to support migration (the Xen RA was extended later to support live migrate issued by Heartbeat). There might be some other dependencies on registration necessary for basic operations, but generally Xen's idea was to treat registration as a form of declaration of a VM; for asset tracking, monitoring purposes etc, that's a bit more of a stable API compared to e.g. a few config and image files laying around... Hth, Robert >From the original Xen RA: Xen_Status() { xm list $DOMAIN_NAME rc=$? if [ $rc -ne 0 ] then return $OCF_NOT_RUNNING else return $OCF_SUCCESS fi } Xen_Monitor() { Xen_Status } Xen_Start() { if Xen_Status then ocf_log info "Xen domain $DOMAIN_NAME already running." return $OCF_SUCCESS else xm create $OCF_RESKEY_xmfile name=$DOMAIN_NAME rc=$? if [ $rc -ne 0 ] then return $OCF_ERR_PERM else return $OCF_SUCCESS fi fi } Xen_Stop() { if Xen_Status then xm shutdown -w $DOMAIN_NAME rc=$? if [ $rc -ne 0 ] then return $OCF_ERR_PERM else return $OCF_SUCCESS fi else ocf_log info "Xen domain $DOMAIN_NAME already stopped." return $OCF_SUCCESS fi } _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
