Hi, Dan I and Sunou investivate this issue. virsh setmem commands directry writes xenstore(memory/target) by using xenStoreDomainSetMemory()@xs_internal.c. This data (memory/target) is read by PVdomain balloon driver directly. As you know, xenstore just pass through the data between inter domain. For this reason, virsh setmem must protect at xs_internal.c not on Xen-side Anyway xm mem-set uses setMemoryTarget()@XendDomainInfo.py and write xenstore(memory/target). This path can be protected by XenD fixes. How should we do? Thanks Atsushi SAKAI Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx> wrote: > Hi, Dan > > O.K. > > I will asking Xen-devel with policy forcing patch. > > Thanks > Atsushi SAKAI > > "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > > > On Wed, Mar 07, 2007 at 06:43:14AM -0500, Daniel Veillard wrote: > > > On Tue, Mar 06, 2007 at 02:40:24PM +0900, Masayuki Sunou wrote: > > > > Hi > > > > > > > > The minimum value of the memory guarded with virsh setmem is 4096KB(4MB). > > > > In general, when host's memory is set to 4MB, the host stops. > > > > > > > > Therefore, I propose the patch to which host's minimum value of the memory > > > > is guarded by 256MB. > > > > > > I have run guests in 64MB of memory, so 256 as an arbitrary limit sounds > > > way too high to me. There is some places in libvirt code where 64 is the limit > > > (e.g. xend_parse_sexp_desc() if ((cur_mem > 63) && (cur_mem != max_mem)) ...) > > > so if we set a limit here too that should be homogenized (using a constant > > > in internal.h preferably). > > > > This still feels wrong to me - I'm don't like the idea of libvirt enforcing > > policy decisions, particularly when they're compiled in. With the current > > bloated Xen python stack we probably won't go below 64 MB, but we won't always > > be managing Xen, nor will Xen forever be stuck with a python stack (i hope :-). > > I'd say that if possible XenD should be fixed to honour dom0_min_memory in all > > cases, rather than just when ballooning down to start a guest. > > > > Regards, > > Dan. > > -- > > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| > > |=- Perl modules: http://search.cpan.org/~danberr/ -=| > > |=- Projects: http://freshmeat.net/~danielpb/ -=| > > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| > > > > -- > > Libvir-list mailing list > > Libvir-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/libvir-list > > > -- > Libvir-list mailing list > Libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list