Bug 1913577
Summary: | Windows guest has no disk after v2v converting to rhv4.4 if convert guest via rhv-upload and not install drivers for guest from virtio-win during conversion | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | mxie <mxie> | ||||||||||
Component: | virt-v2v | Assignee: | Richard W.M. Jones <rjones> | ||||||||||
Status: | CLOSED NOTABUG | QA Contact: | tingting zheng <tzheng> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 8.4 | CC: | chhu, jsuchane, juzhou, kkiwi, mzhan, rjones, tgolembi, tyan, tzheng, xiaodwan, zili | ||||||||||
Target Milestone: | rc | Keywords: | Reopened, Triaged | ||||||||||
Target Release: | 8.4 | ||||||||||||
Hardware: | x86_64 | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2021-06-16 10:22:19 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
mxie@redhat.com
2021-01-07 07:32:28 UTC
Created attachment 1745203 [details]
vdsm.log
Created attachment 1745210 [details]
engine.log
Created attachment 1745211 [details]
virt-v2v-convert-windows-guest-rhv-upload-without-virtio-win.log
This looks same as the bug we saw already in June. - transfer is marked as finalized - we fail to attach disk to VM because image is locked - few seconds later transfer is again marked as finalized and lock is removed Was there any bug opened on virt-v2v or on RHV regarding this at that time? (In reply to Tomáš Golembiovský from comment #4) > This looks same as the bug we saw already in June. > > - transfer is marked as finalized > - we fail to attach disk to VM because image is locked > - few seconds later transfer is again marked as finalized and lock is removed > > > Was there any bug opened on virt-v2v or on RHV regarding this at that time? There is a similar bug. https://bugzilla.redhat.com/show_bug.cgi?id=1849861 Thanks Xiaodai, marking as duplicate. *** This bug has been marked as a duplicate of bug 1849861 *** I think they are different bugs, the failed reason of bug1913577 is "VAR__ACTION__ATTACH_ACTION_TO,VAR__TYPE__DISK,ACTION_TYPE_DISK_INTERFACE_UNSUPPORTED", but the failed reason of bug1849861 is "VAR__ACTION__ATTACH_ACTION_TO,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_IS_LOCKED", details info can be found in engine.logs of bugs. So bug1913577 should be reopen. The engine.log of bug1913577: ....... 2021-01-06 14:20:46,472+08 INFO [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-39) [6cf842f3] Lock Acquired to object 'EngineLock:{exclusiveLocks='[8b968e5e-e3a2-47e4-a0e6-3305804fcd60=VM_DISK_BOOT, 19ed4885-90b3-42e0-9df8-3a022fccc3ce=DISK]', sharedLocks=''}' 2021-01-06 14:20:46,521+08 WARN [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-39) [6cf842f3] Validation of action 'AttachDiskToVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__ATTACH_ACTION_TO,VAR__TYPE__DISK,ACTION_TYPE_DISK_INTERFACE_UNSUPPORTED,$osName Windows 2016 x64 2021-01-06 14:20:46,522+08 INFO [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-39) [6cf842f3] Lock freed to object 'EngineLock:{exclusiveLocks='[8b968e5e-e3a2-47e4-a0e6-3305804fcd60=VM_DISK_BOOT, 19ed4885-90b3-42e0-9df8-3a022fccc3ce=DISK]', sharedLocks=''}' 2021-01-06 14:20:46,527+08 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-39) [6cf842f3] EVENT_ID: VM_IMPORT_FROM_CONFIGURATION_ATTACH_DISKS_FAILED(175), VM esx7.0-win2019-x86_64 has been imported from the given configuration but the following disk(s) failed to attach: 19ed4885-90b3-42e0-9df8-3a022fccc3ce. ...... The engine.log of bug1849861: ...... 2020-06-22 10:31:44,682+08 INFO [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-1287) [ea347a0] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[3695bc4e-a21f-4dde-ac86-2eb0966314ee=VM_DISK_BOOT, fd95ca53-bd87-423e-8ad3-c7a5e0b66a45=DISK]', sharedLocks=''}' 2020-06-22 10:31:44,683+08 WARN [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-1287) [ea347a0] Validation of action 'AttachDiskToVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__ATTACH_ACTION_TO,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_IS_LOCKED 2020-06-22 10:31:44,692+08 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1287) [ea347a0] EVENT_ID: VM_IMPORT_FROM_CONFIGURATION_ATTACH_DISKS_FAILED(175), VM ova_vm_nvV has been imported from the given configuration but the following disk(s) failed to attach: fd95ca53-bd87-423e-8ad3-c7a5e0b66a45. ....... Richard, any updates or thoughts on how to progress on this one? I missed this one, but the bottom line here is that our customers all have virtio-win (so uninstalling it is not a valid test case), and RHV only supports guests using virtio drivers, not the very slow emulated drivers. So even if we were to fix this to make it work (assuming it is really a bug in v2v), it wouldn't be a supported configuration in the end. IOW this is not a bug. (In reply to Richard W.M. Jones from comment #13) > I missed this one, but the bottom line here is that our customers > all have virtio-win (so uninstalling it is not a valid test case), > and RHV only supports guests using virtio drivers, not the very slow > emulated drivers. So even if we were to fix this to make it work > (assuming it is really a bug in v2v), it wouldn't be a supported > configuration in the end. > > IOW this is not a bug. If v2v converts guest without virtio-win is not a valid test case, I think v2v should depend on virtio-win in case customers forget to install virtio-win on v2v server I'm slightly surprised that we don't have that dependency (even on RHEL 8). But yes I agree, we should have it, at least on RHEL. Can you file a new bug about that - I'm doing a virt-v2v build later today. |