[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] creating VM disk with

From: Fam Zheng
Subject: Re: [Qemu-discuss] creating VM disk with
Date: Tue, 3 May 2016 09:36:54 +0800
User-agent: Mutt/1.6.0 (2016-04-01)

On Fri, 04/29 16:02, Nguyễn Thùy Linh wrote:
> Hello,
> I am working on booting a VM using qemu. My scenario: I have *n* VMs,
> first, I boot the 1st VM completely, then boot the rest VMs at the same
> time.
> I found out there are two ways to create a VM disk from image:
>    1. using *qemu-img convert*: this command will create a disk with the
>    same size of image. When VM is booted, VM use this disk to load OS. If I
>    have many VMs, each VM owns an independent disk.
>    2. using *qemu-img create*: this command will create an empty VM disk.
>    When VM is booted, qemu will load necessary kernel data from image to this
>    disk. If I have many VMs, each VM has an empty disk.
> All VM disks is created from one image. What I expect is, in the 2nd way,
> when I boot the 1st VM, the image will be cached in memory, then, the other
> VMs will load image from cache. Therefore, the boot time of the other VMs
> might be faster.

IIUC, you are using a shared backing image across multiple VMs.

> However, when I run this experiment, I observe that the image is not cached
> in the memory. Every VM has to read kernel data from physical disk (where
> image stored).
> My question is if image is cached in memory or not?

It depends on your command line to start QEMU:

    qemu-system-x86_64 -drive file=...,cache=none

will instruct QEMU to disable host page cache.

What you are asking is probably let QEMU use page cache:

    qemu-system-x86_64 -drive file=...,cache=writeback


    qemu-system-x86_64 -drive file=...,cache=writethrough

Refer to http://wiki.qemu.org/download/qemu-doc.html for the meaning of cache

It's also possible to use separate cache modes for the top image and the
backing image:


So your reading from the backing image will be accelerated by the host page


reply via email to

[Prev in Thread] Current Thread [Next in Thread]