Snapshot selection bug

[Jonathan-Caruana]

Hello,

We experienced a singular bug with our ManageIQ instance when we try to restore a snapshot. We realize that sometimes, when we restore, the state of the VM was not that we expected.

For example : single VM with 3 snapshots

the selection is on the latest snapshot, and now i want to restore de previous one, and so i click on it :

Notice the creation date of the snapshot is exactly the same of the latest. And if i click one more time (even if i already selected the correct one) :

Now i'ts good, the date seems really match the original created date of this particular snapshot.

To reproduce, just select a VM that it have two snapshots at least and click on one then the other repeatedly. You will see the created date will not be the good one at each attempt.

Now to prevent this situation we click many times on the snapshot to be sure that is the correct one but it's clearly a bug.

For information, this bug is also present on the latest version.

Environment

VM on oVirt, CentOS Stream release 8, petrosian-1.20230912222549_a07cb46

gems

[root@vs-inf-prd-miq-fr-502 data]# gem env
Ignoring ffi-1.15.0 because its extensions are not built. Try: gem pristine ffi --version 1.15.0
Ignoring psych-3.3.1 because its extensions are not built. Try: gem pristine psych --version 3.3.1
RubyGems Environment:
  - RUBYGEMS VERSION: 3.2.33
  - RUBY VERSION: 3.0.4 (2022-04-12 patchlevel 208) [x86_64-linux]
  - INSTALLATION DIRECTORY: /opt/manageiq/manageiq-gemset
  - USER INSTALLATION DIRECTORY: /root/.local/share/gem/ruby
  - RUBY EXECUTABLE: /usr/bin/ruby
  - GIT EXECUTABLE: /usr/bin/git
  - EXECUTABLE DIRECTORY: /opt/manageiq/manageiq-gemset/bin
  - SPEC CACHE DIRECTORY: /root/.local/share/gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /etc
  - RUBYGEMS PLATFORMS:
     - ruby
     - x86_64-linux
  - GEM PATHS:
     - /opt/manageiq/manageiq-gemset
     - /usr/share/gems
     - /usr/local/share/gems
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
     - "gem" => "--install-dir=/usr/local/share/gems --bindir /usr/local/bin"
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /opt/manageiq/manageiq-gemset/bin
     - /usr/local/sbin
     - /usr/local/bin
     - /usr/sbin
     - /usr/bin
     - /root/bin

[Fryguy]

@agrare Can you look at this one? It might be a UI bug.

[agrare]

Interesting I wonder if this is because ovirt has that "active" snapshot could be causing an off-by-one error? I'll try to reproduce.

[Jonathan-Caruana]

@agrare i just tried with another VM with VMWare as provider and it's exactly the same behaviour.

Regards,

[agrare]

Okay I set up a test on VMware.

I created 4 files, and after each file I shutdown and took a snapshot of the same name:
snapshot1, snapshot2, snapshot3, current

In vSphere I revert to snapshot3 and power the VM on again I expect to see files snapshot1, snapshot2, and snapshot3 and not to see the file current. Confirmed that is what I see.

I re-create the file current and shutdown, then did a refresh with MIQ and reverted to snapshot3 in MIQ, power the VM on and confirmed I only see the snapshot1, snapshot2, and snapshot3 files.

Now I attempt to revert to snapshot2, I confirm it is trying to revert to the correct snapshot:

 #<ManageIQ::Providers::Vmware::InfraManager::Snapshot:0x00007f2854ee35d0
  id: 143,
  uid: "2025-07-10T17:23:01.706477Z",
  parent_uid: "2025-07-10T17:17:06.784203Z",
  name: "snapshot2",
  description: "",

[----] D, [2025-07-10T15:19:21.235665#36596:a7a8] DEBUG -- evm: MIQ(ManageIQ::Providers::Vmware::InfraManager#vm_revert_to_snapshot) AG: vm_revert_to_snapshot: options [{:user_event=>"Console Request Action [vm_revert_to_snapshot], VM [ag-cp4ai-ia-4-6-0]", :snMor=>"2025-07-10T17:23:01.706477Z"}]

I see "You are here" under snapshot2

And I only see snapshot1 and snapshot2 files

[agrare]

This is definitely a UI bug, I do see the issue you describe where you click between snapshots and the "Created On" date doesn't match with the real date of the snapshot. Since we use the snapshot date as the "ref" (for consistency between the vSphere and Host APIs for SSA) if we send down the wrong "date" it will revert to the wrong snapshot.

Assigning @GilbertCherrie

[Jonathan-Caruana]

Hello,

Any idea about the resolution time to fix it?

Regards,

[GilbertCherrie]

This should be fixed once this pr is merged: #9639