Created attachment 1369094 [details] logs Description of problem: Transient volume is not created after backup VM start with snapshot disk from source VM attached Version-Release number of selected component (if applicable): vdsm-4.20.9.2-1.el7ev.x86_64 How reproducible: Always Steps to Reproduce: 1. Create VM (source VM) with disk attached (storage type doesn't matter) 2. Create a snapshot for the source VM 3. Create a second VM (backup VM) 4. Attach the backup disk snapshot of source VM to the backup VM (via REST) 5. Start backup VM Actual results: Transient directory (/var/lib/vdsm/transient), on the hypervisor that the backup VM was started on, remains empty Expected results: A temp volume should be created. See https://www.ovirt.org/develop/release-management/features/storage/backup-restore-api-integration/ Additional info: Source disk attachment to backup VM in engine.log: 2017-12-17 18:33:55,430+02 INFO [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-6) [diskattachments_create_4b4c0caf-f713] Running command: AttachDiskToVmCommand internal: false. Entities affected : ID: 28929a04-8568-4c1e-93d4-e69b30ca70cd Type: VMAction group CONFIGURE_VM_STORAGE with role type USER, ID: f9ce2743-6f3a-45e6-bc14-331c647a106c Type: DiskAction group ATTACH_DISK with role type USER 2017-12-17 18:33:55,454+02 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-6) [diskattachments_create_4b4c0caf-f713] EVENT_ID: USER_ATTACH_DISK_TO_VM(2,016), Disk source_vm_TestCase6178_1718323959_Disk_0 was successfully attached to VM backup_vm_TestCase6178_1718332886 by admin@internal-authz. Backup VM start in vdsm.log: 2017-12-17 18:33:56,086+0200 INFO (jsonrpc/2) [api.virt] START create(vmParams={'xml'.....
I rather suspect that the engine is setting up the transient attribute properly. Eyal, as the QE contact, could you take a look please?
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Latest vdsm build (vdsm-4.20.11-1.el7ev.x86_64) doesn't contain the fix: #vim /usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/storagexml.py +33 METADATA_KEYS = ('GUID', 'domainID', 'imageID', 'poolID', 'volumeID', 'guestName',) While it should be: METADATA_KEYS = ('GUID', 'domainID', 'imageID', 'poolID', 'volumeID', 'guestName', 'shared') Please change the bug status, thanks.
(In reply to Elad from comment #4) > Latest vdsm build (vdsm-4.20.11-1.el7ev.x86_64) doesn't contain the fix: > > > #vim /usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/storagexml.py +33 > > > METADATA_KEYS = ('GUID', 'domainID', 'imageID', 'poolID', 'volumeID', > 'guestName',) > > While it should be: > > METADATA_KEYS = ('GUID', 'domainID', 'imageID', 'poolID', 'volumeID', > 'guestName', 'shared') > > > Please change the bug status, thanks. Return the bug to 'MODIFIED'. The engine contains the relevant fix but VDSM does not (vdsm-4.20.11-1.el7ev.x86_64).
Transient volume is being created under /var/lib/vdsm/transient/ upon VM start with attached disk snapshot. Used: vdsm-4.20.17-1.el7ev.x86_64 libvirt-3.9.0-7.el7.x86_64 qemu-kvm-rhev-2.10.0-18.el7.x86_64 rhvm-4.2.1.3-0.1.el7.noarch
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.