Bug 2010391

Summary:	Live Migration of EFI Windows VM fails
Product:	Container Native Virtualization (CNV)	Reporter:	vsibirsk
Component:	Virtualization	Assignee:	sgott
Status:	CLOSED NOTABUG	QA Contact:	Israel Pinto <ipinto>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.9.0	CC:	cnv-qe-bugs, dgilbert, fdeutsch, kbidarka, lpivarc, mprivozn, sgott, zpeng
Target Milestone:	---
Target Release:	4.10.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-12-14 20:23:06 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:

Description vsibirsk 2021-10-04 14:52:41 UTC

Description of problem:
Live Migration of EFI Windows VM fails

Version-Release number of selected component (if applicable):
oc get clusterversions.config.openshift.io -A
NAME      VERSION      AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.9.0-rc.4   True        False         4d      Cluster version is 4.9.0-rc.4

oc get csv -n openshift-cnv
NAME                                      DISPLAY                    VERSION   REPLACES                                  PHASE
kubevirt-hyperconverged-operator.v4.9.0   OpenShift Virtualization   4.9.0     kubevirt-hyperconverged-operator.v4.8.2   Succeeded

How reproducible:
~80%

Steps to Reproduce:
1.Create Windows VM with efi enabled
2.Live Migrate VM


Actual results:
Migration fails

Expected results:
Migration succeeded

Additional info:
Attached VM yaml, VMI describe, old and new virt-launcher logs

oc -n virt-general-efi-secureboot-test-vm-with-efi-secureboot get pods
NAME                                                            READY   STATUS      RESTARTS   AGE
virt-launcher-windows-efi-secureboot-1633352933-8043447-6dtkh   0/1     Completed   0          15m   --> New
virt-launcher-windows-efi-secureboot-1633352933-8043447-ztnjx   1/1     Running     0          16m   --> Old

Comment 5 sgott 2021-10-06 12:19:52 UTC

The curious part here is that presence of EFI seems to affect the situation. Do you have access to the migration metrics?

How reproducible is this issue (with default parameters)? Could you attempt to reproduce this on a new cluster.

Could you also check if a second attempt to migrate the VM succeeds?

Comment 7 sgott 2021-10-06 13:16:43 UTC

Per comment #4, there exists a mitigation. By the way, there should be a setting directly on the HCO CR to accomplish the same thing. Thus this is not a candidate for a blocker (the migration succeeds given more time).

Michal, can somebody from virt help us understand why migrations with EFI take so much longer than others?

Comment 8 Michal Privoznik 2021-10-06 14:47:35 UTC

(In reply to sgott from comment #7)

> Michal, can somebody from virt help us understand why migrations with EFI
> take so much longer than others?

Honestly, I don't have any idea. This doesn't ring any bells. Let me drag David in. Meanwhile, is it possible to get debug logs?

Comment 9 Dr. David Alan Gilbert 2021-10-06 14:56:16 UTC

Weird; the '151161827009 seconds' is obviously bogusly large (~4793 years...)
The only obvious thing I can think about EFI is making sure that the efi vars file gets migrated OK.