flexVDI Blog

follow us on

This is our stop

I stand before you today with a heavy heart to share some important news regarding flexVDI | Open Full-Stack VDI . It is with great regret that we must announce the closure of our platform. This decision has been driven by recent developments that have profoundly impacted our ability to provide the services we once offered.

FlexVDI was founded on the principles of innovation and dedication to delivering cutting-edge solutions in the realm of virtual desktop infrastructure. Our commitment to our users has always been unwavering, and we have strived to provide a seamless and efficient experience.

However, the landscape of technology is ever-evolving, and sometimes, unforeseen changes occur that challenge the very foundations of our operations. In this case, the closure of RedHat’s development of Spice as a protocol has left us with no choice but to discontinue our services. Spice has been a critical component of our platform, and without it, we are unable to continue operating at the level of excellence that our users have come to expect.

We understand that this announcement may come as a disappointment to our valued users, and we want to express our deepest gratitude for your trust and support throughout our journey. We have explored all possible avenues to adapt to this new reality, but regrettably, continuing our operations is no longer feasible.

As we wind down our operations, our team will be available to assist with any questions or concerns you may have. We will work diligently to ensure a smooth transition for all our users and provide guidance on how to migrate to alternative solutions.

While this chapter of flexVDI | Open Full-Stack VDI may be coming to a close, we remain hopeful for the future of virtual desktop infrastructure and the emergence of new technologies. We want to thank you for being a part of our community and for allowing us the privilege of serving you.

Once again, we extend our heartfelt thanks for your support over the years. We hope that you will find the right path forward in this evolving landscape of technology.

Thank you.

Javier Sánchez

CEO – flexVDI

Released flexVDI agent 3.1.10

Bug fixed: flexvdi-agent could stop answering requests with log “Too many open files”.

Under some error conditions when starting a guest, like when some needed resource was missing, a thread could be blocked forever in flexvdi-agent, not closing its open files. If the error condition persisted for a long time, this threads accumulated, and the flexvdi-agent process reached its “max open files” limit and was unable to open more, which also prevented it from opening new network connections for serving requests.

A similar situation happened too when flexvdi-guest-agent was not able to orderly close its connection, leading to a blocked thread in flexvdi-agent, and it has also been fixed.

The new release can be updated executing in the flexVDI hosts:

# yum -y update flexvdi-agent

Released kmod-ocfs2-flexvdi-k1160-1.5.0-2

Redhat/CentOS kernel 3.10.0-1160.62 and upper has a symbol removed[1] breaking compatibility. This prevents kmod-ocfs2-flexvdi-k1160-1.5.0-1.el7.x86_64.rpm to be loaded, so when using newer kernels, OCFS2 filesystems where unavailable until kernel was downgraded again to < 3.10.0-1160.62.

We have published a new release of package kmod-ocfs2-flexvdi-k1160-1.5.0-2.el7.x86_64.rpm, that solves this situation.

When updating host kernel 1160 in a flexVDI hosts using OCFS2, remember to update kmod-ocfs2-flexvdi-k1160 too.

If you want to update this package now, just run:

yum update kmod-ocfs2-flexvdi-k1160-1.5.0

This command will also install the new kernel if needed, which will be used after the next reboot of the server.

References

1. kernel-3.10.0-1160.62.1.el7 RPM for x86_64 Listing of changes in the kernel package, including the change with title “get rid of fget_light()”.

2. Updating flexVDI software

Released flexVDI Manager 3.1.13

Another security release.

  • Includes logback 1.2.9 that fixes the low severity vulnerability CVE-2021-42550. Exploiting this vulnerability requires the attacker being able to write to the logging.xml config file of the flexVDI Manager appliance.
  • We have removed the write permission of logging.xml file even for the file owner, in flexvdi Manager appliances being updated. In 3.1.12 the permission change affected only new installations.

flexVDI Manager is available for update running flexvdi-config command on the host where the current manager is running. Instructions are available here. Also it can be manually downloaded from portal.flexvdi.com, for servers not connected to the internet.

Released flexVDI Manager 3.1.12

This is mainly an security hardening release. The latest release of the flexVDI Manager appliance includes many updated components, including:

  • All available software packages of its base distro, including Linux kernel, openssl, java, and more.
  • Many updated java libraries. Specifically it includes logback 1.2.8, released yesterday. It removes all JDBC code and disables all JNDI code from the base logging framework, before any important vulnerability is found in it.
  • We have set java logging configuration read-only even for the file owner as recommended by security experts.

flexVDI does not use log4j2 logging library but logback, so it is NOT vulnerable to CVE-2021-44228 (aka log4shell). But a new attack family has been discovered, so logback has been hardened removing the functionality that may be vulnerable before some critical vulnerability is found, and we have included this hardened library release. This makes very unlikely that the latest logback and flexVDI are ever affected by something like log4shell.

Also this release fixes a bug: some stopped volatile guests generated by a desktop policy where not being automatically deleted, even with a “stop & delete” action in place. This happened when the guest was already stopped when the “stop” action was requested, so flexVDI Manager decided that the action had failed, and retried forever before deleting it.

flexVDI Manager is available for update running flexvdi-config command on the host where the current manager is running. Instructions are available here. Also it can be manually downloaded from portal.flexvdi.com, for servers not connected to the internet.

flexVDI is not affected by log4shell vulnerability (CVE-2021-44228)

We have been contacted by users worried about the possible impact of the critical CVE-2021-44228 vulnerability in the ubiquitous log4j logging framework.

flexVDI has never used or included Log4j2 in any of its components, so there is no need to update any software distributed by us because of the said vulnerability.

Stay safe.

Released flexVDI Manager 3.1.11

Bug fix release:

99% but not 100% of resources of each host in each pool could be used. Some guests could not be started with a “not enough resources” message, even if there where just enough resources available.

flexVDI manager is available for update running flexvdi-config command on the host where the current manager is running. Instructions are available here. Also it can be manually downloaded from portal.flexvdi.com, for servers not connected to the internet.

Released flexVDI Manager 3.1.10

New resource allocation algorithm, adapted for homogeneous and also heterogeneous host sets.

The new flexVDI Manager distributes load to the physical hosts proportionally to the amount of computing reources (vCPU and vRAM) that they have available. Previous releases gave load to the host with most free available resources, which resulted in the “bigger” machines in a cluster being more loaded than “small” ones.

flexVDI installations where all the hosts have the same amount of RAM and CPUs, will not be affected by this update. flexVDI Manager will behave like always for them.

Notice:
Most flexVDI Manager updates can be performed when users are connected to the platform without being noticed.

If you have flexVDI installed on hosts with the same amounts of vRAM and vCPUS, this update is also completely safe for you. Otherwise, it is recommended that you stop most (>50%) of the guests in every flexVDI pool in your system before updating your flexVDI Manager. Resource allocation will be different with the new flexVDI Manager, which will cause automatic guest migrations, which will temporarily freeze those guests, and can cause some guests to be stopped.

flexVDI manager is available for update running flexvdi-config command on the host where the current manager is running. Instructions are available here. Also it can be manually downloaded from portal.flexvdi.com, for servers not connected to the internet.

Released flexVDI Manager 3.1.9

  • Bug fixed: Due to a race condition, in rare occasions a volatile desktop could be deleted without a good reason, leaving a log line like: 
xxxxxxx [WARN ] [/user/DesktopReaper] 1103||An orphaned Desktop was found. Killing it||Orphaned desktop is DESKTOP_NAME-volatile-yyyyyyyy
  • Desktop deletion by “inactivity actions” is faster now: The “stop & delete” action of volatile desktops caused by “inactivity actions”, now tries to be performed in one time, instead of stopping the desktop, then deleting the session 30 seconds later.
  • Improved logging: problems when executing “inactivity actions” are logged with more detail now.

flexVDI manager is available for update running flexvdi-config command on the host where the current manager is running. Instructions are available here. Also it can be manually downloaded from portal.flexvdi.com, for servers not connected to the internet.

Released flexVDI Manager 3.1.8

  • Added more variety of emulated guest CPUs, supporting some new instruction sets to improve performance of software compiled to make use of it.
  • Updated kernel and 30 more packages of the flexVDI Manager appliance.

flexVDI manager is available for update running flexvdi-config command on the host where the current manager is running. Instructions are available here. Also it can be manually downloaded from portal.flexvdi.com, for servers not connected to the internet.