[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] altering domain memory limit

> 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.