Re: .img on nfs, relative on ram, consuming mass ram

[Andre Przywara <andre.przywara@amd.com>]

TOURNIER Frédéric wrote:
> Ok, thanks for taking time.
> I'll dig into your answers.
> 
> So as i run relative.img on diskless systems with original.img on nfs, what are the best practice/tips i can use ?
I thinks it is "-snapshot" you are looking for.
This will put the backing store into "normal" RAM, and you can later 
commit it to the original image if needed. See the qemu manpage for more 
details. In a nutshell you just specify the original image and add 
-snapshot to the command line.

Regards,
Andre.

> 
> Is ramfs more suitable than tmpfs ?
> 
> Fred.
> 
> On Thu, 16 Sep 2010 11:09:49 +0200
> Andre Przywara <andre.przywara@amd.com> wrote:
> 
>> TOURNIER Frédéric wrote:
>>> Hi !
>>> Here's my config :
>>>
>>> Version : qemu-kvm-0.12.5, qemu-kvm-0.12.4
>>> Hosts : AMD 64X2, Phenom and Core 2 duo
>>> OS : Slackware 64 13.0
>>> Kernel : 2.6.35.4 and many previous versions
>>>
>>> I use a PXE server to boot semi-diskless (swap partitions and some local stuff) stations.
>>> This server also serves a read-only nfs folder, with plenty of .img on it.
>>> When clients connects, a relative image is created in /tmp, which is a tmpfs, so hosted in ram.
>>>
>>> And here i go on my 2G stations :
>>> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localtime -soundhw es1370 /tmp/relimg.img
>>> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localtime -soundhw es1370 /dev/shm/relimg.img
>>>
>>> I tried both. Always the same result : the ram is consumed quickly, and mass swap occurs.
>> Which is only natural, as tmpfs is promising to never swap. So it will 
>> take precedence over other RAM (that's why it is limited to half of the 
>> memory by default). As soon as the guest has (re)written more disk 
>> sectors than your free RAM can hold, the system will start to swap out 
>> your guest RAM (and other host applications).
>> So in general you should avoid putting relative disk images to tmpfs if 
>> your host memory is limited. As a workaround you could try to further 
>> limit the tmpfs max size (mount -t tmpfs -o size=512M none /dev/shm), 
>> but this could lead to data loss in your guest as it possibly cannot 
>> back the written sectors anymore.
>>> On a 4G system, i see kvm uses more than 1024, maybe 1200.
>>> And everytime a launch a program inside the vm, the amount of the host free ram (not cached) diminishes, which is weird, because it should have been reserved.
>> KVM uses on-demand paging like other applications. So it will not 
>> reserve memory for your guest (unless you use hugetlbfs's -mempath):
>> $ kvm -cdrom ttylinux_ser.iso -nographic -m 3072M
>> $ top
>>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
>>
>>   6015 user      20   0 3205m 128m 3020 S    2  2.2   0:04.94 kvm 
>>
>>
>> Regards,
>> Andre.
>>
>>> So on a 2G system, swap occurs very fast and the machine slow a lot down.
>>> An on a total diskless system, this leads fast to a freeze.
>>>
>>> I have no problem if i use a relative image on disk :
>>> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localtime -soundhw es1370 -drive file=/mnt/hd/sda/sda1/tmp/relimg.img,cache=none
>> -- 
>> Andre Przywara
>> AMD-Operating System Research Center (OSRC), Dresden, Germany
>> Tel: +49 351 448-3567-12
>>
> 


-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712