---
title: "VM-Operator: Upgrading — Issues to watch out for"
description: >-
  Information about issues to watch out for when upgrading the VM-Operator.
layout: vm-operator
---

# Upgrading

## To version 4.0.0

  * The VmViewer conlet has been renamed to VmAccess. This affects the
    [configuration](https://vm-operator.jdrupes.org/user-gui.html).
    Configuration information using the old path
    `/Manager/GuiHttpServer/ConsoleWeblet/WebConsole/ComponentCollector/VmViewer`
    is still accepted for backward compatibility until the next major version,
    but should be updated.

    The change of name also causes conlets added to the overview page by
    users to "disappear" from the GUI. They have to be re-added.

    The latter behavior also applies to the VmConlet conlet which has been
    renamed to VmMgmt.

  * The configuration property `passwordValidity` has been moved from component
    `/Manager/Controller/DisplaySecretMonitor` to
    `/Manager/Controller/Reconciler/DisplaySecretReconciler`. The old path is
    still accepted for backward compatibility until the next major version,
    but should be updated.

  * The standard [template](./runner.html#stand-alone-configuration) used
    to generate the QEMU command has been updated. Unless you have enabled
    automatic updates of the template in the VM definition, you have to
    update the template manually. If you're using your own template, you
    have to add a virtual serial port (see the git history of the standard
    template for the required addition).

## To version 3.4.0

Starting with this version, the VM-Operator no longer uses a stateful set
with replica set to 1 to (indirectly) start the pod with the VM. Rather
it creates the pod directly. This implies that the PVCs must also be created
by the VM-Operator, which needs additional permissions to do so (update of
`deploy/vmop-role.yaml). As it would be ridiculous to keep the naming scheme
used by the stateful set when generating PVCs, the VM-Operator uses a
[different pattern](controller.html#defining-disks) for creating new PVCs.

The change is backward compatible:

  * Running pods created by a stateful set are left alone until stopped.
    Only then will the stateful set be removed.

  * The VM-Operator looks for existing PVCs generated by a stateful
    set in the pre 3.4 versions (naming pattern "*name*-disk-*vmName*-0")
    and reuses them. Only new PVCs are generated using the new pattern.

## To version 3.0.0

All configuration files are backward compatible to version 2.3.0.
Note that in order to make use of the new viewer component,
[permissions](https://mnlipp.github.io/VM-Operator/user-gui.html#control-access-to-vms)
must be configured in the CR definition. Also note that
[display secrets](https://mnlipp.github.io/VM-Operator/user-gui.html#securing-access)
are automatically created unless explicitly disabled.

## To version 2.3.0

Starting with version 2.3.0, the web GUI uses a login conlet that
supports OIDC providers. This effects the configuration of the
web GUI components.

## To version 2.2.0

Version 2.2.0 sets the stateful set's `.spec.updateStrategy.type` to
"OnDelete". This fails for no apparent reason if a definition of
the stateful set with the default value "RollingUpdate" already exists.
In order to fix this, either the stateful set or the complete VM definition
must be deleted and the manager must be restarted.
