Bug 1805178 - paused vmi should display as PAUSED under the vmi phase
Summary: paused vmi should display as PAUSED under the vmi phase
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Virtualization
Version: 2.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: sgott
QA Contact: Israel Pinto
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-20 12:41 UTC by Kedar Bidarkar
Modified: 2021-05-14 12:01 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-20 13:22:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kedar Bidarkar 2020-02-20 12:41:46 UTC
Description of problem:

It appears currently there is no way to figure out if a VMI is actually PAUSED or RUNNING from the CLI.

[kbidarka@kbidarka-host ~]$ virtctl pause vm vm-fedora-cdisk
VMI vm-fedora-cdisk was scheduled to pause


[kbidarka@kbidarka-host ~]$ oc get vmi -o wide 
NAME              AGE    PHASE     IP            NODENAME                          LIVE-MIGRATABLE
vm-fedora-cdisk   108m   Running   10.129.2.22   kbidarka-c23-f56n5-worker-5llvz   False
[kbidarka@kbidarka-host ~]$ oc get vm -o wide 
NAME              AGE    RUNNING   VOLUME   CREATED
vm-fedora-cdisk   109m   true               true


Version-Release number of selected component (if applicable):

[kbidarka@kbidarka-host ~]$ oc version 
Client Version: v4.4.0

[kbidarka@kbidarka-host ~]$ virtctl version 
Client Version: version.Info{GitVersion:"v0.26.1", GitCommit:"e40ff7965e2aadbf21131626dfa3be85524e3a2c", GitTreeState:"clean", BuildDate:"2020-02-14T19:42:46Z", GoVersion:"go1.12.8", Compiler:"gc", Platform:"linux/amd64"}


How reproducible:


Steps to Reproduce:
1. oc apply -f vm.yaml
2. virtctl start vm 
3. virtctl pause vm <vm-name>
4. oc get vmi

Actual results:

Currently we see the PHASE status for vmi is still Running, even though the VM/VMI was Paused via virtctl


[kbidarka@kbidarka-host ~]$ oc get vmi -o wide 
NAME              AGE    PHASE     IP            NODENAME                          LIVE-MIGRATABLE
vm-fedora-cdisk   108m   Running   10.129.2.22   kbidarka-c23-f56n5-worker-5llvz   False


Expected results:

I think the PHASE status for vmi should be PAUSED and not Running ??

or some other way to quickly figure out whether a VMI is actually RUNNING or PAUSED from CLI.



Additional info:

From the UI, it shows up correctly, whether the VMI is Running or Paused.


Currently from the CLI the only way is to login to the virt_launcher and figure out if the VM is Running or Paused.

[kbidarka@kbidarka-host ~]$ oc rsh virt-launcher-vm-fedora-cdisk-g7rcl
sh-4.4# virsh list 
 Id   Name                      State
----------------------------------------
 1    default_vm-fedora-cdisk   paused

Comment 1 sgott 2020-02-20 13:22:40 UTC
Agreed that we can do better here. We will track this as an enhancement in Jira.

Comment 3 Kevin Alon Goldblatt 2021-05-05 09:37:17 UTC
Hi this bug was deferred in 2.3. Is this planned for resolution soon? Are we tracking this in Jira? It would really help to reflect the correct PHASE of the VMI especially as the UI does reflect it as PAUSED!

Comment 4 sgott 2021-05-14 12:01:51 UTC
Hi Kevin, Currently for a VMI "paused" is exposed as a status condition on the VMI, as it is not a sensible phase of a VMI's lifecycle.

We've been giving this topic some thought over time, and one thing we can agree on is that it's not great for clients to determine logic like this--because it needs to be re-implemented on every platform. We've currently there's a PR in flight that you might be interested in:

https://github.com/kubevirt/kubevirt/pull/5528

This PR is attempting to expose a sensible user facing interpretation of what a VM is doing/not doing. Note, this is at the VM level, not the VMI level.

Another commit you might find interesting is:

https://github.com/kubevirt/kubevirt/pull/5401

In that PR, we're going to distinguish between user-initiated and system-initiated reasons that a VMI was paused (e.g. networked storage is not accessible).


Note You need to log in before you can comment on or make changes to this bug.