flexVDI 3.0 is a major revision of the flexVDI Software Suite. Its main features are:
- It is distributed as a bunch of RPM packages, through a yum repository, that can be installed on either Red Hat Enterprise Linux 7 or CentOS 7. There is no more installation media, just an easy installer that will configure everything for you.
- Many of the components it is based on have been upgraded:
- QEMU/KVM 2.9.0, based on RHEV 7 packaged version, with small additions.
- libvirt 3.2.0, as shipped by RHEL 7.4.
- SPICE server 0.12.8, based on RHEL 7.4 packaged version, with small additions.
- OCFS2 1.5.0 and OCFS2 tools 1.8.5.
- You can now review your support contract and your user licenses through the flexVDI Customer Portal. Then, easily assign them to your platform through flexvdi-config.
- Many small improvements:
- Support for USB3 devices.
- Fine-grained RAM allocation in megabytes instead of gigabytes.
- Support for hugepages where available.
- Legacy options have been removed.
Since this is a major revision, API compatibility is broken with previous versions. You will need flexVDI Dashboard 3.0 to manage your new platform, and the upgrade process requires to stop your platform while you upgrade it.
Before you stop your platform prior to upgrading to flexVDI 3.0, make sure you follow these steps. In this way, you will avoid common errors that could trash your flexVDI platform.
- Upgrade to the latest revision of flexVDI 2.2. Upgrade the distribution on all your hosts, and the flexVDI Manager, to their latest version.
- Plan your local storage layout. If you installed flexVDI 2.2 with its default partitioning options, you will have a /boot partition and three LVM volumes: /home, swap and the root filesystem. The best way to upgrade is to either remove everything and make a fresh install, or keep /home, so you already have guest images in place. The later option is best suited if you have files that you want to keep using, but make sure to back up all important files before going on with the reinstallation. Files to back up include, but are not limited to:
- /flexvdi/volatile: volatile images you do not want to remove.
- /flexvdi/local: sysprep answer files, etc.
- /home: guest images and templates.
- /flexvdi/media_servers/cifs: Files served by the optional CIFS/SMB server hosted by a flexVDI Host.
- Other files you may have stored in the system.
- Plan your network layout. This usually means just repeating your flexVDI 2.2 network layout. Make sure to create the same virtual bridges in the same subnets, or or you will have to reconfigure the network of every Guest.
- Stop all your virtual machines and prevent users from connecting to the platform. Remember stopping clones, and setting the number of precreated desktops to "0" in Desktop Policies.
- Back up your flexVDI Manager Database, as explained in flexVDI Manager Backup and keep it somewhere safe; /flexvdi/backup will disappear during the upgrade.
Just in case I was not clear enough: Back up your flexVDI Manager Database. If you delete your old Manager instance without backing it up, you will have to rebuild your platform configuration by hand.
Install RHEL 7 or CentOS 7
Once you have your platform prepared, and your database backup in a safe place, reboot your servers and install your operating system of choice. Remember to review the partitioning layout if you want to keep your old
/home partition. When the installation finishes, run
yum update to update your system to the latest version, and reboot the machine if the update installed a new kernel.
Installation on systems that support UEFI
flexVDI 2.2 only supported installation on BIOS-based systems. However, if your server uses UEFI, you may want to install CentOS 7 or RHEL 7 in UEFI mode. In that case, if you want to keep your old data partitions, you have to convert the MBR partition table in the boot disk to a GPT table. To do so, follow these simple steps:
- Start the CentOS 7 installer in UEFI mode.
- As soon as the graphical interface appears, change to terminal 2.
- Locate your boot disk device (with lsblk, for instance). Let's say it is /dev/sdb.
gdisk /dev/sdb, and just enter command 'w' to write the new GPT table to disk.
- Reboot and start the CentOS 7 installer in UEFI mode again.
- Install normally, but in the partition manager window you have to create a 200 MB partition for
/boot/efi, of EFI type. One simple way is to shrink the
- You have to create the same virbrx virtual bridges that existed in the 2.2 installation, as the guests will need them to create their network interfaces.
- You have to use the same IP address and hostname for your servers. Otherwise the Manager will identify them as new hosts and mark the old ones as down, and Pools and storage objects will keep referencing the original host names.
- You have to mount your external volumes in the same mount point, or they will not be found.
Then, in one of your hosts, install the flexVDI Manager 3.0 and recover your database backup following these steps:
Install the Manager instance, but stop after changing the default password.
DO NOT register your hosts at this point. During registration, the hosts and the manager share some keys, and they will not match after you restore the database backup in the next step. If you accidentally register one or more hosts at this point, you will have to register them again later. To do that, first stop the flexvdi-agent service and delete the file
- Restore the database backup, as explained in the flexVDI Manager backup guide.
- Finish the Manager installation process by registering all your hosts again with the new Manager instance, and install your user licenses.
- Recreate the OCFS2 cluster configuration as it was in the 2.2 installation, so that Volumes can be mounted again.
- Enjoy your new flexVDI 3.0 platform!!
There are two additional things you need to fix in some cases:
- If you have a single host installation and you created the cifs Media Storage with flexvdi-config, the Samba server will not be configured in your new installation. In order to create the cifs Media Storage again, first remove it with the Dashboard.
- If you kept cloned guests or volatiles from your old platform, the location of their base images will have changed, and they will fail to start. Run the command
/usr/sbin/fix_2.2_clones.shin all your hosts to automatically fix the base image location in all your clones. It will fix all the clones found in any of your Image Storages, but you can pass any additional path to look for clones as argument, e.g.