Red Hat Bugzilla – Bug 1281732
Updating a template in a vm pool causes removal of soundcard and memory ballon device
Last modified: 2016-04-21 10:39:54 EDT
Description of problem: When I change template version in a vmpool the souncard and balloon device get cleared, even if the new template has sound and ballon enabled. After that the checkbox are greyed out and cannot be enabled without destroying and recreating the pool... Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create a template with soundcard and memory ballon device 2.Create a pool from the above template 3.VMs and the pool itself have sound and balloon device 4.Create a new Template as version 2 of the original one 5.Check that sound and balloon are enabled in the template 6.Reconfigure the pool to use version 2 of the template 7.VMs and the pool itself have sound and balloon *unchecked* and cannot be enabled anymore Actual results: Pool looses balloon and soundcard settings Expected results: Pool should retain settings from the new version of the template Additional info:
It reminds me a lot about this: https://bugzilla.redhat.com/show_bug.cgi?id=1282853 Can you please share the exact version of the ovirt-engine this happens on?
[root@ovengine ~]# rpm -qa|grep ovirt ovirt-engine-wildfly-overlay-001-2.el7.noarch ovirt-host-deploy-java-1.4.0-1.el7.centos.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.6.0.3-1.el7.centos.noarch ovirt-engine-setup-3.6.0.3-1.el7.centos.noarch ovirt-engine-extensions-api-impl-3.6.0.3-1.el7.centos.noarch ovirt-engine-restapi-3.6.0.3-1.el7.centos.noarch ovirt-guest-agent-windows-1.0.11-2.noarch ovirt-iso-uploader-3.6.0-1.el7.centos.noarch ovirt-engine-dbscripts-3.6.0.3-1.el7.centos.noarch ovirt-engine-backend-3.6.0.3-1.el7.centos.noarch ovirt-engine-userportal-3.6.0.3-1.el7.centos.noarch ovirt-engine-webadmin-portal-3.6.0.3-1.el7.centos.noarch ovirt-engine-wildfly-8.2.0-1.el7.x86_64 ovirt-vmconsole-proxy-1.0.0-1.el7.centos.noarch ovirt-engine-cli-3.6.0.1-1.el7.centos.noarch ovirt-guest-agent-common-1.0.11-1.el7.noarch ovirt-engine-extension-aaa-ldap-setup-1.1.0-1.el7.centos.noarch ovirt-engine-setup-base-3.6.0.3-1.el7.centos.noarch ovirt-engine-setup-plugin-ovirt-engine-3.6.0.3-1.el7.centos.noarch ovirt-engine-setup-plugin-websocket-proxy-3.6.0.3-1.el7.centos.noarch ovirt-engine-vmconsole-proxy-helper-3.6.0.3-1.el7.centos.noarch ovirt-guest-tools-iso-3.6.0-0.2_master.fc22.noarch ovirt-release36-002-2.noarch ovirt-engine-sdk-python-3.6.0.3-1.el7.centos.noarch ovirt-image-uploader-3.6.0-1.el7.centos.noarch ovirt-engine-extension-aaa-jdbc-1.0.1-1.el7.noarch ovirt-host-deploy-1.4.0-1.el7.centos.noarch ovirt-vmconsole-1.0.0-1.el7.centos.noarch ebay-cors-filter-1.0.1-0.1.ovirt.el7.noarch ovirt-engine-extension-aaa-ldap-1.1.0-1.el7.centos.noarch ovirt-engine-lib-3.6.0.3-1.el7.centos.noarch ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.0.3-1.el7.centos.noarch ovirt-engine-websocket-proxy-3.6.0.3-1.el7.centos.noarch ovirt-engine-tools-3.6.0.3-1.el7.centos.noarch ovirt-engine-3.6.0.3-1.el7.centos.noarch [root@ovengine ~]#
The problem was different than the https://bugzilla.redhat.com/show_bug.cgi?id=1282853 even the symptoms were similar. Here the problem was that the way how the the fact if the template has the devices or not was incorrectly implemented on backend.
Verified with rhevm-3.6.5.1-0.1.el6 according to description.