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


Re: [Xen-devel] altering domain memory limit

To: David Becker <becker@xxxxxxxxxxx>
Subject: Re: [Xen-devel] altering domain memory limit
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 22 Jul 2004 21:39:22 +0100
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Thu, 22 Jul 2004 21:42:17 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 22 Jul 2004 15:38:50 EDT." <20040722193850.GH1642@xxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> Oops, I wasn't clear and meant something a bit simpler.  It appears the
> DOM0_SETDOMAINMAXMEM op does not exist in xm.  libxc has it, but it
> seems to be missing higher up in xend.

Ahh, OK. 

> I was surprised xm didn't cover all the dom0 ops -- unless I'm being
> dumb and missed it.  

'xm' is intended to be a smart UI tool, so it doesn't always make
sense to have a 1:1 mapping between xm commands and the
underlying dom0 op.

>From a UI POV, an 'xm mem max' command should probably do a bit
more than just the dom0 op. If max_mem is set below target_mem it
should automatically reduce target_mem and inform the domain. It
should then watch the domain to check it actually gives up the

For the moment, just hacking in a command to do the dom0 op will

> btw, I've also hit that problem people mentioned before about domains
> restarting too fast to kill.   They are real hard to destroy when the domain
> dies instantly.   Fortunately killing xend itself does the trick.

Yep, it's annoying. We should reboot domains at most once every
30s. (i.e. a long lived domain will reboot immediately, but
looping domains are rate limited.)
> I'd prefer if xm  could accept the domain-name to identify domains
> (as well as the xen assigned domain number).

Yep, that's the conclusion we've come to, and Mike is
implementing. We're inclined to take an even more extreme view
and *never* expose Xen domid's to users: everything will be done
by the domain name. We'll ensure that names are unique across a
cluster, which is necessary for things like migration.


This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Xen-devel mailing list