Bug 1661870

Summary: [Web UI] VM state Migrating / Running after successful migration
Product: Container Native Virtualization (CNV) Reporter: Israel Pinto <ipinto>
Component: User ExperienceAssignee: Filip Krepinsky <fkrepins>
Status: CLOSED ERRATA QA Contact: Radim Hrazdil <rhrazdil>
Severity: high Docs Contact:
Priority: high    
Version: 1.4CC: cnv-qe-bugs, dshchedr, gouyang, ipinto, mgoldboi, ncredi, rhrazdil, tjelinek
Target Milestone: ---   
Target Release: 2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 2.0.0-9.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-24 20:15:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
events
none
migration state
none
VM state after migration none

Description Israel Pinto 2018-12-24 06:41:31 UTC 
Description of problem:
After successful migration with share PVC on NFS.
In the web UI the VM state is reported as: Running and Migrating

Version-Release number of selected component (if applicable):
CNV: v0.12.0-alpha.2

How reproducible:
100%

Steps to Reproduce:
1. Create VM with share PVC on NFS 
2. Migration VM with migration job (CLI) 
3. Check VM state on the UI

Actual results:
In the web UI the VM state is reported as: Running and Migrating


Expected results:
VM state should be Migrating and when migration done and VM is running on destination node VM state should be Running 

Attaching UI screenshots
Comment 2 Israel Pinto 2018-12-24 06:42:53 UTC 
Created attachment 1516473 [details]
events
Comment 3 Israel Pinto 2018-12-24 06:43:19 UTC 
Created attachment 1516474 [details]
migration state
Comment 4 Israel Pinto 2018-12-24 06:45:18 UTC 
Created attachment 1516475 [details]
VM state after migration
Comment 5 Fabian Deutsch 2019-01-02 13:44:59 UTC 
The CLI output looks correct, thus this looks like a UI issue. Reassigning.
Comment 9 Tomas Jelinek 2019-01-03 10:01:47 UTC 
Indeed a UI but, changing the component
Comment 10 Tomas Jelinek 2019-01-08 10:50:35 UTC 
https://github.com/kubevirt/web-ui-components/pull/158
Comment 11 Guohua Ouyang 2019-01-21 08:18:38 UTC 
Will verify the bug in a new build which has live migration enabled.
Comment 12 Tomas Jelinek 2019-01-31 08:01:49 UTC 
moving to 2.0, migration is not allowed in 1.4
Comment 13 Radim Hrazdil 2019-06-10 15:02:58 UTC 
Verified that VM is in Running state after migration. Version kubevirt-web-ui-container-v2.0.0-14.7
Verified with the following VM Manifest:

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  annotations:
    name.os.template.kubevirt.io/centos7.0: CentOS 7.0
  selfLink: /apis/kubevirt.io/v1alpha3/namespaces/default/virtualmachines/asdfafasf
  name: test
  namespace: default
  labels:
    app: test
    flavor.template.kubevirt.io/small: 'true'
    os.template.kubevirt.io/centos7.0: 'true'
    vm.kubevirt.io/template: centos7-desktop-small
    vm.kubevirt.io/template-namespace: openshift
    workload.template.kubevirt.io/desktop: 'true'
spec:
  dataVolumeTemplates:
    - metadata:
        creationTimestamp: null
        name: test-rootdisk
      spec:
        pvc:
          accessModes:
            - ReadWriteMany
          dataSource: null
          resources:
            requests:
              storage: 10Gi
          storageClassName: nfs-rwm
        source:
          http:
            url: >-
              https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img
      status: {}
  running: true
  template:
    metadata:
      creationTimestamp: null
      labels:
        kubevirt.io/domain: test
        kubevirt.io/size: small
        vm.kubevirt.io/name: test
    spec:
      domain:
        cpu:
          cores: 1
          sockets: 1
          threads: 1
        devices:
          disks:
            - bootOrder: 1
              disk:
                bus: virtio
              name: rootdisk
          inputs:
            - bus: virtio
              name: tablet
              type: tablet
          interfaces:
            - bootOrder: 2
              macAddress: '02:ba:01:00:00:04'
              masquerade: {}
              name: nic0
          rng: {}
        machine:
          type: ''
        resources:
          requests:
            memory: 2G
      evictionStrategy: LiveMigrate
      hostname: test
      networks:
        - name: nic0
          pod: {}
      terminationGracePeriodSeconds: 0
      volumes:
        - dataVolume:
            name: test-rootdisk
          name: rootdisk

And following PV:
kind: PersistentVolume
apiVersion: v1
metadata:
  name: rhrazdil-nfs-vol1
  annotations:
    pv.kubernetes.io/bound-by-controller: 'yes'
  finalizers:
    - kubernetes.io/pv-protection
spec:
  capacity:
    storage: 20Gi
  nfs:
    server: <>
    path: /rhrazdilnfs/vol1
  accessModes:
    - ReadWriteMany
  claimRef:
    kind: PersistentVolumeClaim
    namespace: default
    name: test-rootdisk
    uid: 5bebaf6f-8b8f-11e9-9364-664f163f5f0f
    apiVersion: v1
    resourceVersion: '89488'
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs-rwm
  volumeMode: Filesystem
Comment 15 errata-xmlrpc 2019-07-24 20:15:50 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1850