1

On a CentOS 7 host, I'm creating a VM from an Amazon Linux 2 qcow2 image:

  • Download Amazon Linux 2 cloud-init image (.qcow2 format)
  • Copy this file, run qemu-img resize to expand it to 40G
  • Define it in my VM using <disk type='file'> and <source file='my_resized_file.qcow2'>

This works - but I'm running ~30 VMs on this host, all running quite heavy Docker workloads - and the disk IO isn't good enough.

I want to try using iothreads, cache=none and io=native as a number of posts online indicate improved performance for SSDs and high-CPU count hosts with these settings. I have plenty of CPU to spare.

I've tried simply adding iothreads=1 to the domain and iothread=1 to the disk, but this fails with the error IOThreads not supported for this QEMU. I presume this is because I'm using disk type=file rather than disk type=block.

I would like to:

  • Use the OS image, and its cloud-init functions
  • Have 40G available to the VM
  • Use raw file type, iothreads, cache=none and io=native for maximum performance

My question is therefore...

How do I get my qcow2 OS image to become a 40G raw block device that I can use with these parameters?

turbonerd
  • 76
  • 5
  • 19
  • [`qemu-img`](https://linux.die.net/man/1/qemu-img)? Should be something like `qemu-img convert -O raw /path/to/image.qcow2 /path/to/image.bin`. – mforsetti May 05 '20 at 10:04
  • Thanks @mforsetti. I've done that bit - and it works. In my latest iteration, I'm using a raw image: ``. This still doesn't work with `iothreads` though. – turbonerd May 05 '20 at 10:10
  • seems like your libvirt guesses that your QEMU [doesn't support](https://github.com/libvirt/libvirt/blob/v6.3.0/src/qemu/qemu_process.c#L5192) IOThreads. – mforsetti May 05 '20 at 12:39
  • Try running `/usr/bin/qemu-system-x86_64 -device virtio-blk-device,help` on your CentOS host. – mforsetti May 05 '20 at 12:49
  • I ran `/usr/libexec/qemu-kvm -device virtio-blk-device,help` and the output listed some device options - but no mention of iothreads. I don't know how to interpret this information though - what does this mean? – turbonerd May 05 '20 at 13:51
  • your QEMU doesn't support IOThreads, what version is your QEMU? IOThreads is supported in QEMU since 2.0. Probably try installing QEMU from EPEL. – mforsetti May 05 '20 at 14:37
  • doh... yup... it's only 1.5!!!! thank you, I'll have a look at the EPEL repo now. – turbonerd May 05 '20 at 14:40

1 Answers1

1

To convert from QCOW2 to RAW image file, use qemu-img convert, for example:

$ qemu-img convert -O raw /path/to/image.qcow2 /path/to/image.bin

IOThreads is supported on QEMU since QEMU 2.0. QEMU 2.0.0 is available on EPEL, so try to run:

# yum -y install epel-release
# yum makecache && yum -y install qemu
mforsetti
  • 2,666
  • 2
  • 16
  • 20
  • Thanks for this @mforsetti, I will award you the green tick shortly :) One last question please - there are tons of packages on EPEL, but none of them are called `qemu-kvm`. I can see `qemu.x86_64 2:2.0.0-1.el7.6` and `qemu-common.x86_64 2:2.0.0-1.el7.6` but would these overwrite the `qemu-kvm` I've got installed? – turbonerd May 05 '20 at 15:34
  • I read somewhere that I could use the `qemu-kvm-ev` variant instead, which replaces my `qemu-kvm` package and has a newer (`2.9` I think?) version of QEMU. Would you recommend that instead? – turbonerd May 05 '20 at 15:39
  • 1
    installing `qemu` requires `qemu-kvm-common`, but also replaces your current `qemu-system-x86` to newer versions. EPEL is compatible with base CentOS repository, so you don't need to worry if you're *replacing* your older QEMU. – mforsetti May 05 '20 at 15:46
  • 1
    about `qemu-kvm-ev`, it's [Virtualization SIG](https://wiki.centos.org/SpecialInterestGroup/Virtualization) variant of QEMU, analog to [RHEV](https://www.redhat.com/en/technologies/virtualization/enterprise-virtualization). To use that repo, do `yum -y install centos-release-qemu-ev && yum makecache`, then install `qemu-kvm-ev` variant rather than `qemu-kvm`. Virtualization SIG did indeed provides newer QEMU versions, compared to EPEL. – mforsetti May 05 '20 at 15:49
  • Thank you! One last question - do you know if the `blk-mq` scheduler has been backported into CentOS kernel `3.10`? Or would it make sense to use the EPEL repo to upgrade to a newer kernel version to access that? Sorry if this is beyond the scope of your expertise or this question. – turbonerd May 05 '20 at 15:52
  • nope, I don't know about that, but EPEL doesn't provide new kernel versions. – mforsetti May 05 '20 at 16:00
  • I think it does: https://elrepo.org/linux/kernel/el7/x86_64/RPMS/ ? But thank you anyway, this has been very useful to me. – turbonerd May 05 '20 at 16:05
  • 1
    RHEL did [backport](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.2_release_notes/index#storage) `blk-mq` to kernel 3.10.0-327 on [release 7.2](https://access.redhat.com/articles/3078#RHEL7), and CentOS should have it already. – mforsetti May 05 '20 at 16:07