+1 I've seen a lot of users and some of our customers use qemu-kvm-ev in production. However, we need to check if qemu-kvm-ev has 100% feature parity (I remember my colleague Andrija suggesting something which was missing in either stock qemu-kvm or qemu-kvm-ev).
Regards. ________________________________ From: Slavka Peleva <slav...@storpool.com.INVALID> Sent: Wednesday, February 23, 2022 23:58 To: dev <dev@cloudstack.apache.org> Subject: Re: [Discussion] CentOS 7 KVM binaries Hi Daniel, +1 for qemu-kvm-ev. We also advise our customers to use it. Best regards, Slavka On Fri, Feb 18, 2022 at 8:51 PM Simon Weller <swel...@ena.com.invalid> wrote: > Daniel, > > We've used qemu-kvm-ev in production for years. A number of the > enhancements we've pushed into Cloudstack have required it. I think you'll > find that most cloud providers based on Centos (or Alma/Rocky) are also > using it. > > -Si > ________________________________ > From: Daniel Salvador <gutoveron...@apache.org> > Sent: Friday, February 18, 2022 9:53 AM > To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> > Subject: [Discussion] CentOS 7 KVM binaries > > Hi all, hope you are doing fine. > > The following discussion emerged from PR #5297[¹]. > > It is a known fact that, regarding KVM functionalities, CentOS7 default's > QEMU binary is quite limited. This is due to the removal of some features > of KVM default binary in CentOS (like VM's volume live migration, > memory/CPU hotplug/hot-unplug, live disk snapshot, and so on); more > information can be found in CentOS forum's thread[²]. > > In my point of view, such limitations in the default QEMU binary in CentOS > make it unfeasible to build a cloud with CentOS and the default QEMU > binary, as operators lose a lot of useful/important operations or have to > go through workarounds, which cause VM's disruption (e.g. having to stop a > VM to migrate the volume between different storage pools, which triggers a > secondary storage usage). There is an alternative binary, "qemu-kvm-ev", > which supports more features than the default one. Probably, most people > using KVM with CentOS are using the "ev" binary (I might be wrong though, > however, that seems to be the case when looking at the users' list). > > PR #5297[¹] ran into one of the CentOS7 default's QEMU binary limitations > (live disk snapshot). The easiest solution (and, IHMO, is the best option) > is to guide users to upgrade CentOS7 QEMU binary to "qemu-kvm-ev". > > Further, it is important to mention that in our experience, it is not > possible to run a highly available cloud environment with CentOS7 and the > default binaries. In a cloud environment with thousands of VMs, sooner or > later the need to hotplug (increase) CPU/RAM, migrate volumes across > different storage pool tyles (such as iSCSI <> NFS), or some other type of > operation appear, and operators/final customers do not want service > disruption. Our customers, for instance, never shut down VMs for these > kinds of operations, and that is only possible because they are all using > KVM with Ubuntu now. > > Moreover, CentOS7 is getting close to its EOL. Therefore, We do not think > that CloudStack should limit its features due to a dying operating system > that presents very limited features by default. > > With that said, it would be interesting if dev/users that use CentOS7 could > share their experiences with the "qemu-kvm-ev" in this thread, so we can > decide which way to go. Or, users that only use the default binary, if they > are satisfied with it. > > If almost no one is relying on default CentOS7 binaries, we could define as > a step in the documentation, that when using CentOS7 people must use the > "ev" binary. This would free us to evolve ACS more freely and avoid > headaches with workarounds to a limited operating system when there are > alternatives out there. > > > [¹] https://github.com/apache/cloudstack/pull/5297 > [²] https://forums.centos.org/viewtopic.php?t=65618 >
