I can't do this because i need performance. I'm currently doing some tests. Will post soon. My config's map : NFS & PXE server qemu-kvm host ----------- ------------ | img.img |__________|relimg.img| | readonly| net | | ----------- ------------ Keep in touch and thx for time. Fred. On Thu, 16 Sep 2010 15:48:18 +0200 Andre Przywara <andre.przywara@xxxxxxx> wrote: > Stefan Hajnoczi wrote: > > 2010/9/16 Andre Przywara <andre.przywara@xxxxxxx>: > >> 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. > > > > -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 file > in /tmp is deleted just after creation there wasn't a sign of it. > For some reason I thought that the buffer would just be allocated in > memory. Sorry, my mistake and thanks for pointing this out. > > So Fred, unfortunately this does not solve your problem. I guess you run > into a general problem. If the guest actually changes so much of the > 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 > read-only (a write protected /usr partition works quite well). > If you are sure that writes are not that frequent, you could think of > putting the overlay file also on the remote storage (NFS). Although this > is rather slow, it shouldn't matter if there aren't many writes and the > local page cache should catch most of the accesses (while still being > nice to other RAM users). > > Regards, > Andre. > > > > Stefan > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > -- > Andre Przywara > AMD-Operating System Research Center (OSRC), Dresden, Germany > Tel: +49 351 448-3567-12 > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
