| Summary: | targeted refresh doesn't work with disks on different domains | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | movciari | ||||||||||||||
| Component: | Providers | Assignee: | Piotr Kliczewski <pkliczew> | ||||||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Ilanit Stein <istein> | ||||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||||
| Priority: | unspecified | ||||||||||||||||
| Version: | 5.7.0 | CC: | cpelland, istein, jfrey, jhardy, masayag, movciari, obarenbo, oourfali, pkliczew | ||||||||||||||
| Target Milestone: | GA | Flags: | istein:
needinfo+
|
||||||||||||||
| Target Release: | 5.8.0 | ||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||
| OS: | Unspecified | ||||||||||||||||
| Whiteboard: | rhev | ||||||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | 2017-02-05 08:39:37 UTC | Type: | Bug | ||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||
| Verified Versions: | Category: | Bug | |||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
| Cloudforms Team: | RHEVM | Target Upstream Version: | |||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
movciari
2016-10-25 13:40:15 UTC
Created attachment 1213924 [details]
rhevm.log
Created attachment 1213928 [details]
evm.log
Created attachment 1213929 [details]
engine.log
Looking at the code I see that we use list of storages during the refresh. In the logs I see that we refresh only one every time: https://mo-3.rhev.lab.eng.brq.redhat.com/ovirt-engine/api/storagedomains/a238d325-4939-469c-ae54-98629770314e This may suggest that initially vm could have only one storage domain. How to observe storage domain changes? What should I look for after the vm refresh? I tried to reproduce this issue with the latest master. I created a vm with 2 disks each on different storage domain. I edited description of this vm to trigger refresh. In the logs I see that both domains were refreshed: https://192.168.1.31:8443/api/storagedomains/ee745353-c069-4de8-8d76-ec2e155e2ca0 https://192.168.1.31:8443/api/storagedomains/94a090ba-7764-40a1-8876-d367dc045bd1 Please retest this with the newest appliance and provide new logs. This bug was reproduced using the following: 1. VM "test_c_u" [guid e73bac7d-1323-42c7-af30-b1c1e9d05261] with disk1-NFS storage domain 1 [guid ends up with 22a] disk2-ISCSI storage domain [guid ends up with a78] rhevm.log contained only api queries for the NFS storage domain. 2. VM "istein" [guid 74ab2700-00f6-4880-9bbf-a0a3808845c8] with disk1-NFS storage domain 1 disk2-NFS storage domain 2 [guid end up with 7ad] rhevm.log contained only api queries for the NFS storae domain 1 Additional info: 1. When VM "test_c_u" was added a 3rd disk, from NFS storage domain 2, rhevm.log contained api queries, on all 3 storage domains, [NFS storage domain 1, ISCSI storage domain, NFS storage domain 2] 2. For a VM "istein1" [guid 74ab2700-00f6-4880-9bbf-a0a3808845c8] with 2 disks from same NFS storage domain, there are several api queries for this NFS storage domain. All the above can be seen in the attached rhevm.log_Dec_19_2016. Created attachment 1233717 [details]
rhevm.log_Dec_19_2016
Relevant part in the rhevm.log start in Dec 19, 5:51:44
Created attachment 1233718 [details]
evm.log_Dec_19_2016.
In continue to comment 9, in the 2 cases of bug reproduction, the VM was added disks, started, and then the rhevm.log, was watched. Ilanit - so in your use-case you create the VMs and that's when you don't see a refresh? Or you stop/start as Michal reported? Moving to 5.8.0. We'll backport if needed once we understand the issue and the impact. Created attachment 1245757 [details]
vms list on vms tab
I'm not convinced this is a bug. There is a specific reason why only the main storage domain is the once being refreshed during the vm targeted refresh. The attachment from comment #15 presents the detailed list of vms, which show the main data store for each vm. Other storage domains (data stores) where the vm has disks on are not listed there, therefore not relevant in that context. Note that the VM entity on manage-iq has a storage attribute (holds the datastore id). This is considered to be the storage associated with the vm and its name is presented on that list. We also have certain assumptions regarding to that storage, i.e. when adding disks via 'reconfigure vm': We don't specify disks, but using that already known storage (until we'll support other data stores...which we currently only do via the restapi/automation) Furthermore, as part of the VM targeted refresh we do refresh all of the VM's disks, therefore we don't miss any information which is relevant only for the specific targeted refresh. Based on the above, I'd consider closing this one as not a bug. |