flexVDI Blog

follow us on

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.

Released flexVDI Config v3.0.6 and flexVDI Agent v3.0.4

This new versions make adding nodes to an existing OCFS2 cluster more robust.

Changelog from flexVDI Config v3.0.5

  • Adding a node to an OCFS2 will be gracefully handled if the same operation has been attempted before and failed.
  • Dialog title shows menu breadcrumbs to make it easier to follow the current operation.
  • Improved error management. Just the current operation is canceled on any error, showing the user a suitable error message.

Changelog from flexVDI Agent v3.0.3

  • Adding a node to an OCFS2 will be gracefully handled if the same operation has been attempted before and failed.

Released flexVDI Gateway v3.0.2 and flexVDI WebPortal v3.0.2

Great news! We have improved our Gateway component and WebPortal appliance to make your life easier. Now, you can use your WebPortal as a Gateway for native clients too, besides serving the HTML5 client. In this way, deploying a WebPortal instance in your platform is the easiest and most secure way to provide a single entry point.

Changelog from flexVDI Gateway v3.0.1

  • The following options and related functionality has been removed as being of little use: RejectUsers, HostDict, CacheFiles
  • HijackAll option is removed, now all the connections from a flexVDI Client are always managed by the same Gateway instance.
  • Proxy the local host by default: if a connection is received without requesting a desktop to the Manager first, it will be redirected to the local host.
  • Better error reporting.

Changelog from flexVDI WebPortal v3.0.1

  • Include flexVDI Gateway 3.0.2
  • Menu option to enable/disable the flexVDI HTML5 Client web interface. By disabling it, you can use the WebPortal instance just as a Gateway for the native clients.