Bug 1526815

Summary: Backup restore API: Transient volume is not created on compatibility version-4.2 after backup VM start with snapshot disk from source VM attached
Product: [oVirt] vdsm Reporter: Elad <ebenahar>
Component: CoreAssignee: Eyal Shenitzky <eshenitz>
Status: CLOSED CURRENTRELEASE QA Contact: Elad <ebenahar>
Severity: high Docs Contact:
Priority: high    
Version: 4.20.9.1CC: amureini, bugs, eshenitz, lveyde, tnisan, ylavi
Target Milestone: ovirt-4.2.1Keywords: Automation, Regression
Target Release: ---Flags: rule-engine: ovirt-4.2+
rule-engine: blocker+
ratamir: testing_plan_complete+
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: vdsm v4.20.13 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-12 11:49:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1534950    
Bug Blocks:    
Attachments:
Description Flags
logs none

Description Elad 2017-12-17 16:59:20 UTC 
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'.....
Comment 1 Allon Mureinik 2017-12-18 10:56:29 UTC 
I rather suspect that the engine is setting up the transient attribute properly.

Eyal, as the QE contact, could you take a look please?
Comment 2 Red Hat Bugzilla Rules Engine 2017-12-18 10:56:34 UTC 
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 ?.
Comment 3 Red Hat Bugzilla Rules Engine 2017-12-18 10:56:34 UTC 
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.
Comment 4 Elad 2018-01-07 13:07:35 UTC 
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.
Comment 5 Eyal Shenitzky 2018-01-07 13:31:10 UTC 
(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).
Comment 6 Elad 2018-01-25 16:35:24 UTC 
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
Comment 7 Sandro Bonazzola 2018-02-12 11:49:45 UTC 
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.