flexVDI Blog

follow us on

Released flexvdi-agent v3.0.6

Changelog from flexVDI Agent v3.0.5

  • Fix listing network interfaces
  • Do not try to use huge pages explicitly. Transparent huge pages are used automatically if they are available.
  • Kill libvirtd if checking the domains’ status is stuck for too long:
    As of libvirt 3.9.0-14.el7_5, there is a bug that hungs libvirtd for unknown reasons. This renders the flexVDI platform unusable. If the agent suspects the libvirtd daemon to be hung, it kills it. Systemd automatically respawns it moments later and the problem is (temporally) solved.

Released flexVDI Manager v3.0.4

Changelog from flexVDI Manager v3.0.3

  • Added globally unique desktop policy parameters: such a parameter will generate values that are unique among all the guests of the platform, not only the desktop policy it applies to.
  • Allow multiple values of the desktop policy attribute. Now, you do not need to write all the desktop policies for a user in a comma-separated list.
  • Fixed image creation task to avoid timing out too soon. This could happen with images created on filesystems that do not support the fallocate operation (CIFS, NFS, …)
  • Fixed destroying VDI sessions when the desktop’s guest was in a transitory unknown state.

Released RHEL and CentOS 7.5

Last month, Red Hat Entreprise Linux 7.5 was released, and CentOS 7.5 followed shortly after. We have been working to make sure that our packages install correctly in this new revision of these popular operating systems. In particular, having an easily upgradeable OCFS2 kernel module (kmod) has been problematic, and there are some things you should know before you update your system.

Problems of binary kmod RPMs

Distributing binary kernel modules in RPM packages has two main problems:

  1. Kernel modules are compiled against a certain kernel version. You cannot (always) use a kernel module with a kernel that has a different version.
  2. By default, yum will let you install several versions of the kernel package, but only one version of other packages.

Problem 1 is partially solved by Red Hat in the following way: Each new version of the RHEL operating system comes with a major revision of their base kernel: 3.10.0-514 in RHEL 7.3, -693 in RHEL 7.4, -862 in RHEL 7.5, etc. For each major revision, Red Hat publishes several updates in the form of minor revisions, like 3.10.0-862.2.3, but maintains the same ABI across different minor revisions. This means that a kernel module compiled for 3.10.0-862 will be usable with any minor revision of this kernel (that is, until RHEL 7.6 is released). For this reason, we need to provide an OCFS2 kmod package for each kernel major revision.

Which takes us to problem 2: we can have several kernel packages installed, but only one OCFS2 kmod. Solving this is not trivial. The solution we have adopted is to release a kmod package for each major revision, not with a different version, but with a different name: kmod-ocfs2-flexvdi-k514, kmod-ocfs2-flexvdi-k693, kmod-ocfs2-flexvdi-k862, and so on. In this way, any number of them may be installed at the same time, since they install to different paths and do not conflict with each other.

Why do you have to care about this?

This solution is no perfect, though: being different packages, yum will not update them automatically. That is, when RHEL / CentOS 7.6 is released, a new major revision XYZ of the base kernel will be published and you will have to install the kmod-ocfs2-flexvdi-kXYZ package manually. The same applies if you are going to update from 7.4 to 7.5 shortly. Luckily, we provide a small hint to help you avoid booting into a kernel without the corresponding OCFS2 module: the flexvdi metapackage conflicts with any kernel version for which a suitable kmod package does not exist yet. Meanwhile, we will keep working on making the upgrade process easier for you.