This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [RFC] [XEND] Lifecycle changes 0/7

To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [RFC] [XEND] Lifecycle changes 0/7
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Fri, 14 Jul 2006 15:31:03 +0100
Delivery-date: Fri, 14 Jul 2006 07:31:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
Hello all,

This email will be followed by a series of patches, for your comment.

At the moment, Xend manages domains only as long as they are running; there is
no equivalent, as far as Xend is concerned, of a machine that is turned off.
If you want to manage virtual machines as a long-term entity, one that can be
turned off and on, with an understanding of the disks it uses and the vifs
that it has configured, then you have to manage that yourself.  The xendomains
script does some of this -- if you put the configuration file into
/etc/xen/auto, then xendomains will shut it down when the host is stopped, and
bring it up when the host restarts -- and other people are using home-grown
wrapper mechanisms for config file management, where they need something a bit
more complicated than that.

We would like to improve this scheme for a number of reasons.  Firstly, we are
working on a full Xen Management API, to allow the Xen CIM providers, SuSE's
YaST, Red Hat's Virtual Machine Manager, and other third party tools to manage
Xen.  We'd like these tools to be able manage virtual machines over the longer
term, but to do that, Xend needs to understand the wider VM lifecycle, since
it is Xend that is managing the incoming messages.

Secondly, using a shell script (xendomains) to manage these things is fragile,
and it's harder to extend the scheme when Xend has some state and xendomains
has other bits.

To this end, we propose moving the xendomains functionality into Xend.  xm
will gain some extra commands:

  xm new    -- Create a VM but don't start it.
  xm delete -- Remove the VM permanently.
  xm start  -- Start a VM that you created with xm new.

xm create keeps basically the same semantics as before, for backwards
compatibility: xm create is now equivalent to xm new followed by xm start.

xm shutdown shuts down the VM, but it is now still present in Xend, and can be
started again using xm start without needing to pass a configuration file
(as you would have to do if you were using xm create).

There is still some work left to do on these patches, in particular the work
to reproduce the auto-shutdown/auto-suspend behaviour of xendomains is still a
bit green, but now seemed a good time to put them out for comment.

These patches are all by Alastair Tse; many thanks to him for the hard work
and professionalism he's shown while delivering this patch set.

Your views are welcome!


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [RFC] [XEND] Lifecycle changes 0/7, Ewan Mellor <=