On Thu, Mar 22, 2007 at 01:56:25PM +0900, Masayuki Sunou wrote: > Hi > > The message which a cause of an error is hard to detect is displayed when > "virsh setmaxmem" sets the maximum memory of an active domain less than > Used Memory. > > -------------------------------------------------------------------------------- > # virsh setmaxmem 0 4096 > libvir: Xen error : failed Xen syscall ioctl 8518692 > libvir: Xen Daemon error : POST operation failed: (xend.err "(22, 'Invalid argument')") > libvir: error : library call virDomainSetMaxMemory failed, possibly not supported > -------------------------------------------------------------------------------- > > This patch displays the message which is easier to detect the cause of > an error to a user. > > -------------------------------------------------------------------------------- > # virsh setmaxmem 0 4096 > error: 4096 is less than current used memory. > -------------------------------------------------------------------------------- Hum, this sounds useful from a user interraction perspective, but I have a doubt about it, first it's a bit racy, i.e. the memory usage could change between the GetInfo call and the SetMaxMem one, but my main problem is that I'm afraid this would prevent the possibility of automatic memory resize in some case. Assume a paravirtual guest kernel, supporting memory resizing, then it could in theory shrink its memory footprint if asked for (migrating dirty pages to swap dynamically for example). Such a mechanism sounds important to load balance usage between multiple guests sharing a host, and I'm afraid your patch would block that capacity just because Xen does not accept that operation in that version. I'm afraid that patch - even if limited to virsh - is unfortunately not a good idea, as usual the preferred way would be to get xend fixed to return a better error message, so I prefer to decline applying that patch as is. I'm also wondering if virDomainSetMemory() should not be called first to try to shrink and then only make the check of the current memory usage, the problem is that memory shrinking is likely to be a long operation in that case since it certainly gonna involve moving blocks to disk. I Cc'ed Rik who may have a more complete opinion on guest memory shrinking. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/