Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1691562 - Cluster level changes are not increasing VMs generation numbers and so a new OVF_STORE content is not copied to the shared storage
Summary: Cluster level changes are not increasing VMs generation numbers and so a new ...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.2.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ovirt-4.3.4
: ---
Assignee: Shmuel Melamud
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks: 1585986
TreeView+ depends on / blocked
 
Reported: 2019-03-21 22:42 UTC by Simone Tiraboschi
Modified: 2019-04-16 11:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Virt
Target Upstream Version:


Attachments (Terms of Use)

Description Simone Tiraboschi 2019-03-21 22:42:39 UTC
Description of problem:
We got a report about an environment where the user tries to change the CPU type for the hosted-engine virtual machine with no actual results.

After investigations we understood that the issues comes from here:
 
MainThread::DEBUG::2019-03-21 10:02:00,865::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) {u'status': u'OK', u'lease': {u'path': u'/rhev/data-center/mnt/storage.internal.viada.de:_rhv4-volume/3ee26ff5-afb1-412a-89ef-a289ac109fed/images/0eba3025-70de-4adc-9857-05b77155bfc9/d301ed77-f3d8-4af2-9f1f-7dcb116d3c01.lease', u'owners': [], u'version': None, u'offset': 0}, u'domain': u'3ee26ff5-afb1-412a-89ef-a289ac109fed', u'capacity': u'134217728', u'voltype': u'LEAF', u'description': u'{"Updated":true,"Size":30720,"Last Updated":"Wed Mar 06 14:35:25 CET 2019","Storage Domains":[{"uuid":"3ee26ff5-afb1-412a-89ef-a289ac109fed"}],"Disk Description":"OVF_STORE"}', u'parent': u'00000000-0000-0000-0000-000000000000', u'format': u'RAW', u'generation': 0, u'image': u'0eba3025-70de-4adc-9857-05b77155bfc9', u'uuid': u'd301ed77-f3d8-4af2-9f1f-7dcb116d3c01', u'disktype': u'OVFS', u'legality': u'LEGAL', u'mtime': u'0', u'apparentsize': u'30720', u'truesize': u'30720', u'type': u'PREALLOCATED', u'children': [], u'pool': u'', u'ctime': u'1550073785'}
MainThread::DEBUG::2019-03-21 10:02:01,086::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) {u'status': u'OK', u'lease': {u'path': u'/rhev/data-center/mnt/storage.internal.viada.de:_rhv4-volume/3ee26ff5-afb1-412a-89ef-a289ac109fed/images/556be753-69bd-413c-87e2-e170d3fca9db/5cd0085a-094d-4806-a251-1af759241b4d.lease', u'owners': [], u'version': None, u'offset': 0}, u'domain': u'3ee26ff5-afb1-412a-89ef-a289ac109fed', u'capacity': u'134217728', u'voltype': u'LEAF', u'description': u'{"Updated":true,"Size":30720,"Last Updated":"Wed Mar 06 14:35:25 CET 2019","Storage Domains":[{"uuid":"3ee26ff5-afb1-412a-89ef-a289ac109fed"}],"Disk Description":"OVF_STORE"}', u'parent': u'00000000-0000-0000-0000-000000000000', u'format': u'RAW', u'generation': 0, u'image': u'556be753-69bd-413c-87e2-e170d3fca9db', u'uuid': u'5cd0085a-094d-4806-a251-1af759241b4d', u'disktype': u'OVFS', u'legality': u'LEGAL', u'mtime': u'0', u'apparentsize': u'30720', u'truesize': u'30720', u'type': u'PREALLOCATED', u'children': [], u'pool': u'', u'ctime': u'1550073786'}

look at

MainThread::DEBUG::2019-03-21 10:02:00,865 ... "Last Updated":"Wed Mar 06 14:35:25 CET 2019"
MainThread::DEBUG::2019-03-21 10:02:01,086 ... "Last Updated":"Wed Mar 06 14:35:25 CET 2019"

on 2019-03-21 ovirt-ha-agent is still continuously parsing the OVF_STORE but engine updated it last time only on 2019-03-06 (15 days before).

In the mean time the user is trying to edit the hosted-engine VM with no apparent results.



Version-Release number of selected component (if applicable):
4.2.8

How reproducible:
?

Steps to Reproduce:
1. check OVF_STORE updates periodicity on running engines
2.
3.

Actual results:
on an active storage domain, the engine updated the OVF_STORE 15 days ago

Expected results:
the engine updates the OVF_STORE files every time cycle that set in OvfUpdateIntervalInMinutes (default 60 minutes).

Additional info:

Comment 2 Simone Tiraboschi 2019-03-25 09:30:19 UTC
According to https://bugzilla.redhat.com/show_bug.cgi?id=1585986#c59 it seems that changes at cluster level are not increasing VMs generation numbers and so a new OVF_STORE content is not copied to the shared storage.

Comment 3 Michal Skrivanek 2019-03-27 12:20:01 UTC
(In reply to Simone Tiraboschi from comment #2)
> According to https://bugzilla.redhat.com/show_bug.cgi?id=1585986#c59 it
> seems that changes at cluster level are not increasing VMs generation
> numbers and so a new OVF_STORE content is not copied to the shared storage.

For HE it's true, because the cluster upgrade code is not touching HE VM. So IMHO works as designed. Does it need to change? I would strongly suggest to explore updating all VMs including HE, but there might be still some gaps I'm not aware of preventing this

Comment 4 Simone Tiraboschi 2019-03-27 13:26:37 UTC
(In reply to Michal Skrivanek from comment #3)
> For HE it's true, because the cluster upgrade code is not touching HE VM. So
> IMHO works as designed. Does it need to change? I would strongly suggest to
> explore updating all VMs including HE, but there might be still some gaps
> I'm not aware of preventing this

I tend to agree that's the best option: I don't see any reason why the hosted-engine VM should be different on this aspect.
For sure we don't have something like next run configuration but we can also discuss about that.


Note You need to log in before you can comment on or make changes to this bug.