From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: .img on nfs, relative on ram, consuming mass ram Date: Thu, 16 Sep 2010 15:48:18 +0200 Message-ID: <4C922022.50404@amd.com> References: <20100915113941.9536341d.f.tournier@iut.univ-paris8.fr> <4C91DEDD.9030508@amd.com> <20100916140139.e5c4a8fe.f.tournier@iut.univ-paris8.fr> <4C9207AA.9070009@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?ISO-8859-1?Q?TOURNIER_Fr=E9d=E9ric?= , "kvm@vger.kernel.org" To: Stefan Hajnoczi Return-path: Received: from tx2ehsobe005.messaging.microsoft.com ([65.55.88.15]:5677 "EHLO TX2EHSOBE010.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754808Ab0IPNvK convert rfc822-to-8bit (ORCPT ); Thu, 16 Sep 2010 09:51:10 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Stefan Hajnoczi wrote: > 2010/9/16 Andre Przywara : >> TOURNIER Fr=E9d=E9ric 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 n= fs, >>> 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 de= tails. >> In a nutshell you just specify the original image and add -snapshot = to the >> command line. >=20 > -snapshot creates a temporary qcow2 image in /tmp whose backing file > is your original image. I'm not sure what you mean by "This will put > the backing store into "normal" RAM"? Stefan, you are right. I never looked into the code and because the fil= e=20 in /tmp is deleted just after creation there wasn't a sign of it. =46or some reason I thought that the buffer would just be allocated in=20 memory. Sorry, my mistake and thanks for pointing this out. So Fred, unfortunately this does not solve your problem. I guess you ru= n=20 into a general problem. If the guest actually changes so much of the=20 disk that this cannot be backed by RAM in the host, you have lost. One solution could be to just make (at least parts of) the disk=20 read-only (a write protected /usr partition works quite well). If you are sure that writes are not that frequent, you could think of=20 putting the overlay file also on the remote storage (NFS). Although thi= s=20 is rather slow, it shouldn't matter if there aren't many writes and the= =20 local page cache should catch most of the accesses (while still being=20 nice to other RAM users). Regards, Andre. >=20 > Stefan > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >=20 --=20 Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12