[Top][All Lists]

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

Re: [Qemu-devel] Swap disks virtualization

From: Kevin Wolf
Subject: Re: [Qemu-devel] Swap disks virtualization
Date: Mon, 13 Mar 2017 12:21:32 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 13.03.2017 um 04:42 hat Christopher Pereira geschrieben:
> We are currently providing Linux swap disks with QEMU driver, virtio
> bus and qcow2 type.
> Do you know any alternatives that provide better performance?
> Considering that swap disks contain less critical data, QEMU could
> avoid disk IOs by using unassigned memory whenever possible. This
> could also be handled by the underlying linux filesystem of course.
> Can we tell QEMU to use the linux swap disk for creating a guest
> swap disk? What's the state of the art regarding swap disks
> virtualization?

I think the state of the art is to give the VMs enough memory rather
than making them use a swap disk. If the amount of memory required by
each VM changes dynamically, you can use memory ballooning or hotplug to
increase or decrease the memory size while the VM is running. If you
overcommit the memory, the VMs will automatically be part of the host's
swapping (with all performance implications of swapping, so I think
you'll still want to avoid it on the host, too).

But if you really, really want to use a swap disk in the VM for some
reason, there are three things that I would do:

1. Most importantly, set a good cache mode, cache=unsafe sounds
   perfectly fine here because you're not interested in the state of the
   image after a crash.

2. Consider putting the image on a tmpfs on the host. cache=unsafe will
   already make sure that qemu never forces Linux to write out the data
   in its cache with an fsync() call, but Linux will still do background
   writeouts. With tmpfs, that won't happen. Of course, the downside is
   that you're using actual host memory for it and rely on the host
   kernel to swap out the tmpfs rather than data of host processes,
   which may or may not work out. But I understand that this is more or
   less what you're asking for.

3. You're unlikely to use any interesting features with this image, so
   using raw instead of qcow2 could be possible. Don't expect too much
   here, especially if your qcow2 image is preallocated, but if you can
   use raw, it's always the best performing option.

Even with this, you still have the virtual disk I/O overhead for
accessing the VM's swap space, so it will never be as fast as just
giving the VM more memory.


reply via email to

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