Created attachment 1516473 [details]
events

Created attachment 1516474 [details]
migration state

Created attachment 1516475 [details]
VM state after migration

The CLI output looks correct, thus this looks like a UI issue. Reassigning.

Indeed a UI but, changing the component

https://github.com/kubevirt/web-ui-components/pull/158

Will verify the bug in a new build which has live migration enabled.

moving to 2.0, migration is not allowed in 1.4

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

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