Hi. I have issue with incorrect memory side inside vm. I'm try utilize memory balloon (not memory hotplug, because i have guest without memory hotplug (may be)). When domain started with static memory all works fine, but then i'm specify in libvirt memory = 16384 , maxMemory = 16384 and currentMemory = 1024, guest in f/rpoc/meminfo says that have only 603608 Kb memory. Then i set memory via virsh setmem to 2Gb, guest see only 1652184 Kb memory. software versions libvirt: 1.2.10 qemu: 2.3.0 Guest OS: centos 6. qemu.log: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -name 26543 -S -machine pc-i440fx-1.7,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,maxcpus=4,sockets=4,cores=1,threads=1 -uuid 4521fb01-c2ca-4269-d2d6-0000035fd910 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/26543.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,num_queues=1,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/dev/vg4/26543,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,discard=unmap,aio=native,iops=5000 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-1-0,readonly=on,format=raw -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=52 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:00:34:f7,bus=pci.0,addr=0x3,rombar=0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/26543.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-mouse,id=input0 -device usb-kbd,id=input1 -vnc [::]:8,password -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x7 -msg timestamp=on -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru

2015-06-17 17:09 GMT+03:00 Andrey Korolyov <andrey(a)xdel.ru&gt;: > The rest of visible memory is eaten by reserved kernel areas, for us > this was a main reason to switch to a hotplug a couple of years ago. > You would not be able to scale a VM by an order of magnitude with > regular balloon mechanism without mentioned impact, unfortunately. > Igor Mammedov posted hotplug-related patches for 2.6.32 a while ago, > though RHEL6 never adopted them by some reason. Hmm.. Thanks for info, from what version of kernel memory hotplug works? -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru

This is band news =( i have debian wheezy that have old kernel...

Yes, but I`m afraid that I don`t fully understand why do you need this when pure hotplug mechanism is available, aside may be nice memory stats from balloon and easy-to-use deflation. Just populate a couple of static dimms with small enough 'base' e820 memory and use balloon on this setup, you`ll get the reserved memory footprint as small as it would be in setup with equal overall amount of memory populated via BIOS. For example, you may use -m 128 ... {handful amount of memory placed in memory slots} setup to achieve the thing you want.

Whoosh... technically it is possible but it would be an incompatible fork for the upstreams for both SeaBIOS and Qemu, because the generic way of plugging DIMMs in is available down to at least generic 2.6.32. Except may be Centos where broken kabi would bring great consequences, it may be better to just provide a backport repository with newer kernels, but it doesn`t sound very optimistic. For the history records, the initial hotplug support proposal provided by Vasilis Liaskovitis a couple of years ago worked in an exact way you are suggesting to, but its resurrection would mean emulator and rom code alteration, as I said above.

Do You see similar results at Your side? Best regards