Description of problem: I was trying to reproduce https://bugzilla.redhat.com/1862701 exactly as for the attached screenshots. In my case, for some strange reason (a wrong/overloaded mirror???), downloading the disk image from https://dl.fedoraproject.org/pub/fedora/linux/releases/32/Cloud/x86_64/images/Fedora-Cloud-Base-32-1.6.x86_64.qcow2 took more than 10 minutes: NAME PHASE PROGRESS RESTARTS AGE datavolume.cdi.kubevirt.io/fedora-vm-rootdisk ImportInProgress 86.25% 0 10m So, after 10 minutes, a readiness probe error got triggered on virt-launcher pod and this caused its VMI object to be destroyed and recreated. A the end the VM successfully started as expected but we have a lot of noise in user facing events. See the attached screenshot. I also got VMI related error events with: (combined from similar events): server error. command SyncVMI failed: "LibvirtError(Code=1, Domain=10, Message='internal error: process exited while connecting to monitor: 2020-08-07T10:23:03.895236Z qemu-kvm: -blockdev {\"driver\":\"file\",\"filename\":\"/var/run/kubevirt-private/vmi-disks/rootdisk/disk.img\",\"node-name\":\"libvirt-2-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"}: Could not open '/var/run/kubevirt-private/vmi-disks/rootdisk/disk.img': Permission denied')" Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. try to start a VM from UI wizard specifying a URL source 2. ensure that CDI takes more than 10 minutes to download the source disk 3. Actual results: - many VMI related error events - VMI got deleted and recreated after 10 minutes Expected results: No false negative events if the download is progressing Additional info:
Created attachment 1710792 [details] VMI killed and recreated
@Israel, @Stu, should this bug be on Virt? (removing useless events from the log vs making them disappear in the UI)
Moving this BZ to virtualization for proper tracking. This isn't a UX BZ
If this issue can be reproduced, here is what should happen, to provide hints where to look for a fix: 1) We check if all datavolumes are imported 2) if they are not imported, we don't create a pod 3) once all DVs are done with the import, we create the pod
Try to reproduce this with CNV-2.6.0
Summary: Was unable to reproduce this issue on CNV-2.6.0 (cnv/virt-operator/v2.6.0-106) 1) Created a VM( on a cluster in US) from the UI Wizard, using a link from (EMEA) 2) Download took more than 10 mins and no false negative events observed anymore. Attaching a screenshot shortly.
Cannot reproduce in the current release CNV-2.6.0