Bug 1416846 - OVF of the hosted engine vm is not updated when there is a change in vm devices
Summary: OVF of the hosted engine vm is not updated when there is a change in vm devices
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.HostedEngine
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.1.1-1
Assignee: Jenny Tokar
QA Contact: Artyom
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-26 15:17 UTC by Jenny Tokar
Modified: 2017-05-11 09:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: When vm devices are imported to the engine the vm was not marked as changed in the db. Consequence: The vm ovf was never updated with the new devices. Fix: When importing devices mark the change in the vm in the db. Result: The ovf is generated with the new devices.
Clone Of:
Last Closed: 2017-04-21 09:44:41 UTC
oVirt Team: SLA
rule-engine: ovirt-4.1+
rule-engine: exception+
rule-engine: planning_ack+
dfediuck: devel_ack+
mavital: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 72709 0 'None' 'MERGED' 'core: Increment vm db generation when importing devices' 2019-12-05 17:54:39 UTC
oVirt gerrit 73343 0 'None' 'MERGED' 'core: Increment vm db generation when importing devices' 2019-12-05 17:54:39 UTC
oVirt gerrit 74245 0 'None' 'MERGED' 'core: Increment vm db generation when importing devices' 2019-12-05 17:54:39 UTC

Description Jenny Tokar 2017-01-26 15:17:09 UTC
Description of problem:
OVF of the hosted engine vm is not updated when there is a change in vm devices. 

How reproducible:

Steps to Reproduce:
1. Deploy hosted engine 
2. Wait for the vm to be imported and for the ovf to be created (set OvfUpdateIntervalInMinutes to 2 minutes to not wait too long)
3. Restart the engine to allow the monitoring to import the devices 

Actual results:
The ovf is not updated with the vm devices 

Expected results:
The ovf is updated and contains the same devices as in the db. 

Additional info:
1. The process to update ovfs runs but nothing gets written to the ovf. 
2. A workaround to this is to edit some other part of the vm via ui, this will trigger an ovf update.

Comment 1 Jenny Tokar 2017-01-31 14:11:13 UTC
The ovf update process decides which ovfs to update using GetVmsIdsForOvfUpdate query which checks if the db_generation column (vm) is bigger then the ovf_generation column (ovf_generation).
This column is not updated when importing devices and so the update process doesn't know that it should write a new ovf for the vm.
Usually the devices are imported to the engine before the first ovf generation and so are included in the generated ovf.

Comment 2 Yaniv Kaul 2017-03-19 08:49:09 UTC
Missed 4.1.1, moving to 4.1.2. Perhaps it can make it to 4.1.1-1?

Comment 3 Yaniv Lavi 2017-03-19 15:07:56 UTC
(In reply to Yaniv Kaul from comment #2)
> Missed 4.1.1, moving to 4.1.2. Perhaps it can make it to 4.1.1-1?

Ack from me, we want it in a async.

Comment 4 Artyom 2017-03-23 15:40:34 UTC
Verified on rhevm-

Devices in the database:
engine=# select device, address from vm_device_view where vm_id='6f5c58af-a9e6-426f-9a57-e5b160847b3f';
    device     |                           address                            
 vnc           | 
 cdrom         | 
 disk          | {slot=0x04, bus=0x00, domain=0x0000, type=pci, function=0x0}
 bridge        | {slot=0x02, bus=0x00, domain=0x0000, type=pci, function=0x0}
 console       | None
 virtio        | {slot=0x05, bus=0x00, domain=0x0000, type=pci, function=0x0}
 cdrom         | {bus=1, controller=0, type=drive, target=0, unit=0}
 usb           | {slot=0x01, bus=0x00, domain=0x0000, type=pci, function=0x2}
 ide           | {slot=0x01, bus=0x00, domain=0x0000, type=pci, function=0x1}
 virtio-serial | {slot=0x03, bus=0x00, domain=0x0000, type=pci, function=0x0}
 unix          | {bus=0, controller=0, type=virtio-serial, port=1}
 unix          | {bus=0, controller=0, type=virtio-serial, port=2}
 unix          | {bus=0, controller=0, type=virtio-serial, port=3}

Devices via virsh:
    <disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='raw' cache='none' error_policy='stop' io='threads'/>
      <source file='/var/run/vdsm/storage/8f10342b-42cd-4ee6-b895-d6bb66bdfca1/c2190f69-2610-430c-aab6-b576e81d79b9/225c8fc9-87dc-4f01-8297-6c02b60e12f8'>
        <seclabel model='selinux' labelskip='yes'/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source startupPolicy='optional'/>
      <target dev='hdc' bus='ide'/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    <controller type='usb' index='0'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    <controller type='ide' index='0'>
      <alias name='ide'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    <controller type='virtio-serial' index='0'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
      <target path='/rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Compute__NFS_alukiano_he__0/8f10342b-42cd-4ee6-b895-d6bb66bdfca1/images/c2190f69-2610-430c-aab6-b576e81d79b9/225c8fc9-87dc-4f01-8297-6c02b60e12f8.lease'/>
    <interface type='bridge'>
      <mac address='00:16:3e:7b:b8:56'/>
      <source bridge='ovirtmgmt'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <link state='up'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    <console type='pty' tty='/dev/pts/0'>
      <source path='/dev/pts/0'/>
      <target type='virtio' port='0'/>
      <alias name='console0'/>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channels/6f5c58af-a9e6-426f-9a57-e5b160847b3f.com.redhat.rhevm.vdsm'/>
      <target type='virtio' name='com.redhat.rhevm.vdsm' state='connected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channels/6f5c58af-a9e6-426f-9a57-e5b160847b3f.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channels/6f5c58af-a9e6-426f-9a57-e5b160847b3f.org.ovirt.hosted-engine-setup.0'/>
      <target type='virtio' name='org.ovirt.hosted-engine-setup.0' state='disconnected'/>
      <alias name='channel2'/>
      <address type='virtio-serial' controller='0' bus='0' port='3'/>
    <input type='mouse' bus='ps2'>
      <alias name='input0'/>
    <input type='keyboard' bus='ps2'>
      <alias name='input1'/>
    <memballoon model='none'>
      <alias name='balloon0'/>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <alias name='rng0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>

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