admin.loadVMs should reload existing VMs if version is changed

[Nuttymoon]

Describe the bug
After upgrading a VM to a newer version, the API call admin.loadVMs do not detect the change, leaving the VM in the old version.

To Reproduce

• AvalancheGo service is started
• Check VMs current versions with info.getNodeVersion
• Overwrite the VM binary in the plugins directory with another version
• Call admin.loadVMs: API return is empty
• When checking info.getNodeVersion, notice that VM version is unchanged

Expected behavior
To minimize node downtime, admin.loadVMs should be able to detect a version change and reload the VMs that have indeed changed.

Screenshots
(I am using symlinks in the plugins directory)

• info.getNodeVersion result (there is a version display bug for the Subnet EVM but see below that version 0.1.1 is linked):

  {
    "jsonrpc": "2.0",
    "result": {
      "version": "avalanche/1.7.6",
      "databaseVersion": "v1.4.5",
      "gitCommit": "4b891d48d1fb9a71dd3397b73980d630a9f6227f",
      "vmVersions": {
        "avm": "v1.7.6",
        "evm": "v0.8.6",
        "platform": "v1.7.6",
        "subnetevm": ""
      }
    },
    "id": 1
  }

• VM upgrade in plugins folder

  ll -A /opt/avalanche/avalanchego/current/plugins/
  # Before upgrade
  total 2
  lrwxrwxrwx 1 avalanche avalanche 57 Mar 21 14:51 evm -> /opt/avalanche/avalanchego/avalanchego-v1.7.6/plugins/evm*
  lrwxrwxrwx 1 avalanche avalanche 55 Mar 21 14:51 subnetevm -> /opt/avalanche/vms/subnetevm/subnetevm-v0.1.1/subnetevm*
  # After upgrade
  total 2
  lrwxrwxrwx 1 avalanche avalanche 57 Mar 21 14:55 evm -> /opt/avalanche/avalanchego/avalanchego-v1.7.6/plugins/evm*
  lrwxrwxrwx 1 root      root      55 Mar 21 14:59 subnetevm -> /opt/avalanche/vms/subnetevm/subnetevm-v0.1.2/subnetevm*

• admin.loadVMs result is empty:

  {
    "jsonrpc": "2.0",
    "result": {
      "newVMs": {}
    },
    "id": 1
  }

• info.getNodeVersion result is unchanged
• If we restart the AvalancheGo service, the new VM is loaded and info.getNodeVersion returns:

  {
    "jsonrpc": "2.0",
    "result": {
      "version": "avalanche/1.7.6",
      "databaseVersion": "v1.4.5",
      "gitCommit": "4b891d48d1fb9a71dd3397b73980d630a9f6227f",
      "vmVersions": {
        "avm": "v1.7.6",
        "evm": "v0.8.6",
        "platform": "v1.7.6",
        "subnetevm": "v0.1.2@5661f109a6903cae499b73be41b655cdb350b6f0"
      }
    },
    "id": 1
  }

Operating System
Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-104-generic x86_64)

By submitting this issue I agree to the Terms and Conditions of the Developer Accelerator Program.

[ceyonur]

Thank you for reporting this. We will look into this.

[StephenButtolph]

I really don't consider this a bug... It may be useful to add... but I think that this would result in a lot of confusion if a VM is currently being used, but is no longer the same version... We could shutdown the blockchain and restart it with the new VM version... but I feel like at that point we should just be restarting the node.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

[joshua-kim]

I think the load vms api is just not useful in its current state - I think unless we support #668 we should just deprecate this api.