- Users - oVirt List Archives

High iowait and low throughput on NFS, oflag=direct fixes it?
by Frank Wall 29 Mar '19

29 Mar '19

Hi, I've been using oVirt for years and have just discovered a rather strange issue that causes EXTREME high iowait when using a NFSv3 storage. Here's a quick test on a CentOS 7.6 VM running on any oVirt 4.2.x node: (5 oVirt nodes, all showing the same results) # CentOS VM $ dd if=/dev/zero of=TEST02 bs=1M count=3000 3000+0 records in 3000+0 records out 3145728000 bytes (3.1 GB) copied, 141.649 s, 22.2 MB/s # iostat output Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vdb 0.00 0.00 1.00 50.00 0.00 23.02 924.39 121.62 2243.47 2301.00 2242.32 19.61 100.00 As you can see iowait is beyond bad both for read and write requests. During this test the underlying NFS storage server was idle, disks barely doing anything. iowait on the NFS storage server was very low. However, when using oflag=direct the test shows a completely different result: # CentOS VM $ dd if=/dev/zero of=TEST02 bs=1M count=3000 oflag=direct 3000+0 records in 3000+0 records out 3145728000 bytes (3.1 GB) copied, 21.0724 s, 149 MB/s # iostat output Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vdb 0.00 0.00 4.00 483.00 0.02 161.00 677.13 2.90 5.96 0.00 6.01 1.99 97.10 This test shows the *expected* performance in this small oVirt setup. Notice how iowait remains healthy, although the throughput is 7x higher now. I think this 2nd test may prove multiple things: the NFS storage is fast enough and there's no networking/switch issue either. Still, under normal conditions WRITE/READ operations are really slow and iowait goes through the roof. Do these results make sense to anyone? Any hints how to find what's wrong here? Any tests I should run or sysctls/tunables that would make sense? FWIW, iperf result looks good between the oVirt Node and the NFS storage: [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 10.9 GBytes 9.36 Gbits/sec Regards - Frank

1 1

Vagrant Plugin
by Jeremy Tourville 29 Mar '19

29 Mar '19

I am having some trouble getting the Ovirt Vagrant plugin working. I was able to get Vagrant installed and could even run the example scenario listed in the blog. https://www.ovirt.org/blog/2017/02/using-oVirt-vagrant.html My real issue is getting a vm generated by the SecGen project https://github.com/SecGen/SecGen to come up. If I use the VirtualBox provider everything works as expected and I can launch the vm with vagrant up. If I try to run using Ovirt provider it fails. I had originally posted this over in Google groups / Vagrant forums and it was suggested to take it to Ovirt. Hopefully, somebody here has some insights. The process fails quickly with the following output. Can anyone give some suggestions on how to fix the issue? I have also included a copy of my vagrantfile below. Thanks in advance for your assistance! ***Output*** Bringing machine 'escalation' up with 'ovirt4' provider... ==> escalation: Creating VM with the following settings... ==> escalation: -- Name: SecGen-default-scenario-escalation ==> escalation: -- Cluster: default ==> escalation: -- Template: debian_stretch_server_291118 ==> escalation: -- Console Type: spice ==> escalation: -- Memory: ==> escalation: ---- Memory: 512 MB ==> escalation: ---- Maximum: 512 MB ==> escalation: ---- Guaranteed: 512 MB ==> escalation: -- Cpu: ==> escalation: ---- Cores: 1 ==> escalation: ---- Sockets: 1 ==> escalation: ---- Threads: 1 ==> escalation: -- Cloud-Init: false ==> escalation: An error occured. Recovering.. ==> escalation: VM is not created. Please run `vagrant up` first. /home/secgenadmin/.vagrant.d/gems/2.4.4/gems/ovirt-engine-sdk-4.0.12/lib/ovirtsdk4/service.rb:52:in `raise_error': Fault reason is "Operation Failed". Fault detail is "Entity not found: Cluster: name=default". HTTP response code is 404. (OvirtSDK4::Error) from /home/secgenadmin/.vagrant.d/gems/2.4.4/gems/ovirt-engine-sdk-4.0.12/lib/ovirtsdk4/service.rb:67:in `check_fault' from /home/secgenadmin/.vagrant.d/gems/2.4.4/gems/ovirt-engine-sdk-4.0.12/lib/ovirtsdk4/services.rb:35570:in `add' from /home/secgenadmin/.vagrant.d/gems/2.4.4/gems/vagrant-ovirt4-1.2.2/lib/vagrant-ovirt4/action/create_vm.rb:67:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /home/secgenadmin/.vagrant.d/gems/2.4.4/gems/vagrant-ovirt4-1.2.2/lib/vagrant-ovirt4/action/set_name_of_domain.rb:17:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:121:in `block in finalize_action' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builder.rb:116:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `block in run' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/busy.rb:19:in `busy' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `run' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/call.rb:53:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /home/secgenadmin/.vagrant.d/gems/2.4.4/gems/vagrant-ovirt4-1.2.2/lib/vagrant-ovirt4/action/connect_ovirt.rb:31:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builder.rb:116:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `block in run' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/busy.rb:19:in `busy' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `run' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:238:in `action_raw' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:209:in `block in action' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/environment.rb:615:in `lock' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:195:in `call' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:195:in `action' from /opt/vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run' Non-zero exit status... Not going to destroy escalation, since it does not exist Failed. Not retrying. Please refer to the error above. **Vagrantfile*** VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.define "escalation" do |escalation| escalation.vm.provider :ovirt4 do |ovirt| ovirt.username = 'admin@internal' ovirt.password = 'my_password' ovirt.url = 'https://engine.cyber-range.lan/ovirt-engine/api' ovirt.cluster = 'default' ovirt.template = 'debian_stretch_server_291118' ovirt.memory_size = '512 MB' ovirt.console = 'spice' ovirt.insecure = true ovirt.debug = true end escalation.vm.provision 'shell', inline: "echo 'datasource_list: [ None ] '> /etc/cloud/cloud.cfg.d/90_dpkg.cfg" escalation.vm.hostname = 'SecGen-default-scenario-escalation' escalation.vm.box = 'ovirt4' escalation.vm.box_url = 'https://github.com/myoung34/vagrant-ovirt4/blob/master/example_box/dummy.bo…' escalation.vm.provision "puppet" do | modules_utilities_unix_update_unix_update | modules_utilities_unix_update_unix_update.module_path = "puppet/escalation/modules" modules_utilities_unix_update_unix_update.environment_path = "environments/" modules_utilities_unix_update_unix_update.environment = "production" modules_utilities_unix_update_unix_update.synced_folder_type = "rsync" modules_utilities_unix_update_unix_update.manifests_path = "puppet/escalation/modules/unix_update" modules_utilities_unix_update_unix_update.manifest_file = "unix_update.pp" end escalation.vm.provision "puppet" do | modules_vulnerabilities_unix_misc_distcc_exec | modules_vulnerabilities_unix_misc_distcc_exec.facter = { "base64_inputs_file" => '94bad9a7b0c9aa1462eb1d4d8277a712', } modules_vulnerabilities_unix_misc_distcc_exec.module_path = "puppet/escalation/modules" modules_vulnerabilities_unix_misc_distcc_exec.environment_path = "environments/" modules_vulnerabilities_unix_misc_distcc_exec.environment = "production" modules_vulnerabilities_unix_misc_distcc_exec.synced_folder_type = "rsync" modules_vulnerabilities_unix_misc_distcc_exec.manifests_path = "puppet/escalation/modules/distcc_exec" modules_vulnerabilities_unix_misc_distcc_exec.manifest_file = "distcc_exec.pp" end escalation.vm.provision "puppet" do | modules_vulnerabilities_unix_local_chkrootkit | modules_vulnerabilities_unix_local_chkrootkit.facter = { "base64_inputs_file" => '170197cbf03410f71d7d777e9d468382', } modules_vulnerabilities_unix_local_chkrootkit.module_path = "puppet/escalation/modules" modules_vulnerabilities_unix_local_chkrootkit.environment_path = "environments/" modules_vulnerabilities_unix_local_chkrootkit.environment = "production" modules_vulnerabilities_unix_local_chkrootkit.synced_folder_type = "rsync" modules_vulnerabilities_unix_local_chkrootkit.manifests_path = "puppet/escalation/modules/chkrootkit" modules_vulnerabilities_unix_local_chkrootkit.manifest_file = "chkrootkit.pp" end escalation.vm.provision "puppet" do | modules_services_unix_nfs_nfs_share | modules_services_unix_nfs_nfs_share.facter = { "base64_inputs_file" => '98ddf2a16a97f46fd4856a509df9b75a', } modules_services_unix_nfs_nfs_share.module_path = "puppet/escalation/modules" modules_services_unix_nfs_nfs_share.environment_path = "environments/" modules_services_unix_nfs_nfs_share.environment = "production" modules_services_unix_nfs_nfs_share.synced_folder_type = "rsync" modules_services_unix_nfs_nfs_share.manifests_path = "puppet/escalation/modules/nfs_share" modules_services_unix_nfs_nfs_share.manifest_file = "nfs_share.pp" end escalation.vm.network :private_network, type: "dhcp", :ovirt__network_name => 'ovirtmgmt' end end

1 0

oVirt 4.2.8 - guest Windows 10 - oVirt tools - no mouse pointer
by Timmi 29 Mar '19

29 Mar '19

Hi guys, I have a problem with some of my Windows 10 VMs. There is no mouse pointer in case I'm connecting to the console through the virt-viewer. I have also other Windows 10 VMs which don't show the same issue. The mouse pointer is working as soon as I uninstall the oVirt tools. Any ideas? Best regards Timmi

1 0

ovirt "discard after delete" storage access request
by Simon Coter 29 Mar '19

29 Mar '19

Hi experts, how can I find a storage that supports “Discard” option for our oVirt storage domains ? I mean, I’ve tried more storage models and I always get: Discard is not supported by underlying storage. This is an example I’ve did on a very old storage (HP MSA): Thanks in advance for your help. Simon

2 1

cpu hotplug cannot be applied for windows 10
by zodaoko＠gmail.com 29 Mar '19

29 Mar '19

Hi there, I am running ovirt engine 4.2.8. I did cpu hotplug for windows 10 guest os, ovirt (from 1*2*1 to 2*2*1) successfully, and the output of virsh vcpuinfo also shows now there are total 4 vcpus: # virsh --readonly vcpuinfo 13 VCPU: 0 CPU: 51 State: running CPU time: 3911.8s CPU Affinity: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy VCPU: 1 CPU: 15 State: running CPU time: 907.7s CPU Affinity: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy VCPU: 2 CPU: 26 State: running CPU time: 1086.2s CPU Affinity: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy VCPU: 3 CPU: 2 State: running CPU time: 1085.7s CPU Affinity: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy Issue: But when I log into windows 10, from the task manager, there are only two vcpus listed. Then I opened device manager, and found that there are 4 processors listed. refer to https://bugzilla.redhat.com/show_bug.cgi?id=1377155, I have updated os to the latest version 1809. refer to the ovirt doc, cpu hot plug is explicitly supported for windows 10 (both x86 and x86_64) , but from my testing result, the cpu hotplug was not applied. So is this a windows 10 bug? or is there any workaround? Thank you! Thanks, -Zhen

1 2

HE Install cannot login to VM
by Callum Smith 29 Mar '19

29 Mar '19

Dear all, Giving up on running ansible playbook remotely we're hitting earlier issues running hosted-engine --deploy 2019-03-28 15:42:33,975+0000 INFO otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:109 TASK [ovirt.hosted_engine_setup : Wait for the local VM] 2019-03-28 15:45:40,739+0000 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:103 {u'msg': u"timed out waiting for ping module test success: Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this. Please add this host's fingerprint to your known_hosts file to manage this host.", u'elapsed': 186, u'changed': False, u'_ansible_no_log': False, u'_ansible_delegated_vars': {u'ansible_delegated_host': u'he.virt.in.bmrc.ox.ac.uk', u'ansibl e_host': u'he.virt.in.bmrc.ox.ac.uk'}} 2019-03-28 15:45:40,840+0000 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:107 fatal: [localhost -> he.virt.in.bmrc.ox.ac.uk]: FAILED! => {"changed": false, "elapsed": 186, "msg": "timed out waiting for ping module test success: Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this. Please add this host's fingerprint to your known_hosts file to manage this host."} At a bit of a loss, especially since the old no-ansible install is not available anymore? Regards, Callum -- Callum Smith Research Computing Core Wellcome Trust Centre for Human Genetics University of Oxford e. callum(a)well.ox.ac.uk<mailto:callum@well.ox.ac.uk>

2 2

CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES
by Arsène Gschwind 29 Mar '19

29 Mar '19

Hi, I updated ou oVirt cluster to 4.3.2 and when i try to update the cluster version to 4.3 i get the following error: CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES So far I remember I could update the cluster version to 4.2 without having to stop everything. I've searched around about this error but couldn't find anything. The engine log says: 2019-03-20 14:33:28,125+01 INFO [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Lock Acquired to object 'EngineLock:{exclusiveLocks='[25682477-0bd2-4303-a5fd-0ae9adfd276c=TEMPLATE]', sharedLocks='[119fad69-b4a2-441f-9056-354cd1b8a7aa=VM, 1f696eca-c0a0-48ff-8aa9-b977345b5618=VM, 95ee485d-7992-45b8-b1be-256223b5a89f=VM, 432ed647-c150-425e-aac7-3cb5410f4bc8=VM, 7c2646b1-8a4c-4618-b3c9-dfe563f29e00=VM, 629e40c0-e83b-47e0-82bc-df42ec310ca4=VM, 2e0741bd-33e2-4a8e-9624-a9b7bb70b664=VM, 136d0ca0-478c-48d9-9af4-530f98ac30fd=VM, dafaa8d2-c60c-44c8-b9a3-2b5f80f5aee3=VM, 2112902c-ed42-4fbb-a187-167a5f5a446c=VM, 5330b948-f0cd-4b2f-b722-28918f59c5ca=VM, 3f06be8c-8af9-45e2-91bc-9946315192bf=VM, 8cf338bf-8c94-4db4-b271-a85dbc5d6996=VM, c0be6ae6-3d25-4a99-b93d-81b4ecd7c9d7=VM, 8f4acfc6-3bb1-4863-bf97-d7924641b394=VM]'}' 2019-03-20 14:33:28,214+01 WARN [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Validation of action 'UpdateCluster' failed for user xxxx@yyy. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES 2019-03-20 14:33:28,215+01 INFO [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Lock freed to object 'EngineLock:{exclusiveLocks='[25682477-0bd2-4303-a5fd-0ae9adfd276c=TEMPLATE]', sharedLocks='[119fad69-b4a2-441f-9056-354cd1b8a7aa=VM, 1f696eca-c0a0-48ff-8aa9-b977345b5618=VM, 95ee485d-7992-45b8-b1be-256223b5a89f=VM, 432ed647-c150-425e-aac7-3cb5410f4bc8=VM, 7c2646b1-8a4c-4618-b3c9-dfe563f29e00=VM, 629e40c0-e83b-47e0-82bc-df42ec310ca4=VM, 2e0741bd-33e2-4a8e-9624-a9b7bb70b664=VM, 136d0ca0-478c-48d9-9af4-530f98ac30fd=VM, dafaa8d2-c60c-44c8-b9a3-2b5f80f5aee3=VM, 2112902c-ed42-4fbb-a187-167a5f5a446c=VM, 5330b948-f0cd-4b2f-b722-28918f59c5ca=VM, 3f06be8c-8af9-45e2-91bc-9946315192bf=VM, 8cf338bf-8c94-4db4-b271-a85dbc5d6996=VM, c0be6ae6-3d25-4a99-b93d-81b4ecd7c9d7=VM, 8f4acfc6-3bb1-4863-bf97-d7924641b394=VM]'}' Any Idea for the reason of this error? Thanks

3 13

Migrate HE beetwen hosts failed.
by kiv＠intercom.pro 29 Mar '19

29 Mar '19

Hi all. I have oVirt 4.3.1 and 3 node hosts. All VM migrate beetwen all hosts successfully. VM with HE - does not migrate. vdsm.log: libvirtError: operation failed: guest CPU doesn't match specification: missing features: xsave,avx,xsaveopt Nodes: 1. Intel Westmere IBRS SSBD Family 2. Intel Westmere IBRS SSBD Family 3. Intel SandyBridge IBRS SSBD Family <----- HE now here Cluster CPU Type: Intel Westmere Family Info from VM with HE: Guest CPU Type: Intel Westmere Family Does anyone know what needs to be done to make migration work?

3 6

virsh edit vm not saving after reboot
by Dev Ops 28 Mar '19

28 Mar '19

I am trying to get Cisco ISE installed into Ovirt. I was told I needed to do a virsh edit on the vm and change a line in the smbios settings. This is all simple enough. After a reboot or shutdown/restart the settings revert back to what they were before. A dump of the XML in fact shows the original settings that I had changed. Since I can't edit the file while the VM is off I am not sure how to save this config change. My issue is similar to this: https://access.redhat.com/discussions/2720821 I have been reading and digging around with no luck. I just can't seem to make this change static. Thanks!

2 2

[ANN] oVirt 4.3.3 First Release Candidate is now available
by Sandro Bonazzola 28 Mar '19

28 Mar '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.3 First Release Candidate, as of March 28th, 2019. This update is a release candidate of the third in a series of stabilization updates to the 4.3 series. This is pre-release software. This pre-release should not to be used in production. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node is already available[2] Additional Resources: * Read more about the oVirt 4.3.3 release highlights: http://www.ovirt.org/release/4.3.3/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.3.3/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0