- Users - oVirt List Archives

Strange storage data center failure
by Fabrice Bacchella 02 Apr '19

02 Apr '19

I have a storage data center that I can't use. It's a local one. When I look on vdsm.log: 2019-04-02 10:55:48,336+0200 INFO (jsonrpc/2) [vdsm.api] FINISH connectStoragePool error=Cannot find master domain: u'spUUID=063d1217-6194-48a0-943e-3d873f2147de, msdUUID=49b1bd15-486a-4064-878e-8030c8108e09' from=::ffff:XXXXX,59590, task_id=a56a5869-a219-4659-baa3-04f673b2ad55 (api:50) 2019-04-02 10:55:48,336+0200 ERROR (jsonrpc/2) [storage.TaskManager.Task] (Task='a56a5869-a219-4659-baa3-04f673b2ad55') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in connectStoragePool File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 1035, in connectStoragePool spUUID, hostID, msdUUID, masterVersion, domainsMap) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 1097, in _connectStoragePool res = pool.connect(hostID, msdUUID, masterVersion) File "/usr/lib/python2.7/site-packages/vdsm/storage/sp.py", line 700, in connect self.__rebuild(msdUUID=msdUUID, masterVersion=masterVersion) File "/usr/lib/python2.7/site-packages/vdsm/storage/sp.py", line 1274, in __rebuild self.setMasterDomain(msdUUID, masterVersion) File "/usr/lib/python2.7/site-packages/vdsm/storage/sp.py", line 1495, in setMasterDomain raise se.StoragePoolMasterNotFound(self.spUUID, msdUUID) StoragePoolMasterNotFound: Cannot find master domain: u'spUUID=063d1217-6194-48a0-943e-3d873f2147de, msdUUID=49b1bd15-486a-4064-878e-8030c8108e09' 2019-04-02 10:55:48,336+0200 INFO (jsonrpc/2) [storage.TaskManager.Task] (Task='a56a5869-a219-4659-baa3-04f673b2ad55') aborting: Task is aborted: "Cannot find master domain: u'spUUID=063d1217-6194-48a0-943e-3d873f2147de, msdUUID=49b1bd15-486a-4064-878e-8030c8108e09'" - code 304 (task:1181) 2019-04-02 11:44:50,862+0200 INFO (jsonrpc/0) [vdsm.api] FINISH getSpmStatus error=Unknown pool id, pool not connected: (u'063d1217-6194-48a0-943e-3d873f2147de',) from=::ffff:10.83.16.34,46546, task_id=cfb1c871-b1d4-4b1a-b2a5-f91ddfaba 54b (api:50) 2019-04-02 11:44:50,862+0200 ERROR (jsonrpc/0) [storage.TaskManager.Task] (Task='cfb1c871-b1d4-4b1a-b2a5-f91ddfaba54b') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in getSpmStatus File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 634, in getSpmStatus pool = self.getPool(spUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 350, in getPool raise se.StoragePoolUnknown(spUUID) StoragePoolUnknown: Unknown pool id, pool not connected: (u'063d1217-6194-48a0-943e-3d873f2147de',) 063d1217-6194-48a0-943e-3d873f2147de is indeed the datacenter id and 49b1bd15-486a-4064-878e-8030c8108e09 the storage domain: <storage_domain href="/ovirt-engine/api/storagedomains/49b1bd15-486a-4064-878e-8030c8108e09" id="49b1bd15-486a-4064-878e-8030c8108e09"> <storage> <type>fcp</type> <volume_group id="cEOxNG-R4fv-EDo3-Y3lm-ZMAH-xOT4-Nn8QyP"> <logical_units> </logical_units> </volume_group> </storage> <storage_format>v4</storage_format> <data_centers> <data_center href="/ovirt-engine/api/datacenters/063d1217-6194-48a0-943e-3d873f2147de" id="063d1217-6194-48a0-943e-3d873f2147de"/> </data_centers> </storage_domain> On engine.log, I'm also getting: 2019-04-02 11:43:57,531+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-12) [] Command 'org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand' return value ' TaskStatusListReturn:{status='Status [code=654, message=Not SPM: ()]'} ' lsblk shows that the requested volumes are here: lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT cciss!c0d1 104:16 0 1.9T 0 disk |-49b1bd15--486a--4064--878e--8030c8108e09-metadata 253:0 0 512M 0 lvm |-49b1bd15--486a--4064--878e--8030c8108e09-outbox 253:1 0 128M 0 lvm |-49b1bd15--486a--4064--878e--8030c8108e09-xleases 253:2 0 1G 0 lvm |-49b1bd15--486a--4064--878e--8030c8108e09-leases 253:3 0 2G 0 lvm |-49b1bd15--486a--4064--878e--8030c8108e09-ids 253:4 0 128M 0 lvm |-49b1bd15--486a--4064--878e--8030c8108e09-inbox 253:5 0 128M 0 lvm |-49b1bd15--486a--4064--878e--8030c8108e09-master 253:6 0 1G 0 lvm |-49b1bd15--486a--4064--878e--8030c8108e09-6225ddc3--b600--49ef--8de4--6e53bf4cad1f 253:7 0 128M 0 lvm `-49b1bd15--486a--4064--878e--8030c8108e09-bdac3a3a--8633--41bf--921d--db2cf31f5d1c 253:8 0 128M 0 lvm There is no usefull data on them. So I don't mind destroying everything. But using the GUI I can't do any thing on that domain. I'm runing 4.2.7.5-1.el7 on rhel 7.6

1 0

oVirt Survey 2019 results
by Sandro Bonazzola 02 Apr '19

02 Apr '19

Thanks to the 143 participants to oVirt Survey 2019! The survey is now closed and results are publicly available at https://bit.ly/2JYlI7U We'll analyze collected data in order to improve oVirt thanks to your feedback. As a first step after reading the results I'd like to invite the 30 persons who replied they're willing to contribute code to send an email to devel(a)ovirt.org introducing themselves: we'll be more than happy to welcome them and helping them getting started. I would also like to invite the 17 people who replied they'd like to help organizing oVirt events in their area to either get in touch with me or introduce themselves to users(a)ovirt.org so we can discuss about events organization. Last but not least I'd like to invite the 38 people willing to contribute documentation and the one willing to contribute localization to introduce themselves to devel(a)ovirt.org. Thanks! -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

6 5

Not being able to create new partition with fdisk
by pawel.zajac＠mikrosimage.com 01 Apr '19

01 Apr '19

Hi, I am not able to add new or extend a partitions under CentOS 7 VM in oVirt 4.2.7.5 - 1.el7 Once I get to write to partition table the system pauses with error. "VM XXXX has been paused due to unknown storage error." Can't see much in the log, messages doesn't even signaled it. The VM just pauses. VM storage is on a NFS share, so not a block device, like most of the issues I found. Did search web for similar issue, bit no luck so far. Any ideas? Thank you. Best, Pawel

1 0

Multiple Active VM before the preview" snapshots
by Bruckner, Simone 31 Mar '19

31 Mar '19

Hi, we see some VMs that show an inconsistent view of snapshots. Checking die database for one example vm shows the following result: engine=# select snapshot_id, status, description from snapshots where vm_id = '40c0f334-dac5-42ad-8040-e2d2193c73c0'; snapshot_id | status | description --------------------------------------+------------+------------------------------ b77f5752-f1a4-454f-bcde-6afd6897e047 | OK | Active VM 059d262a-6cc4-4d35-b1d4-62ef7fe28d67 | OK | Active VM before the preview d22e4f74-6521-45d5-8e09-332c05194ec3 | OK | Active VM before the preview 87d39245-bedf-4cf1-a2a6-4228176091d3 | IN_PREVIEW | base (4 rows) We cannot perform any snapshot, clone, copy operations on those vms. Is there a way to get this cleared? All the best, Simone

1 1

Is iSCSI performance better for VMs on the selected Host?
by sebastian.freitag＠aptiv.com 30 Mar '19

30 Mar '19

Hi all, I am planning to add block storage (iSCSI) to my oVirt environment. I just stumbled across this point from the oVirt Documentation: "6. Select an active host in the Use Host field. If this is not the first data domain in a data center, you must select the data center's SPM host. Important: All communication to the storage domain is through the selected host and not directly from the oVirt Engine." (you find it here: https://www.ovirt.org/documentation/admin-guide/chap-Storage.html#adding-bl…) So my question is: Is there a significant performance advantage for VMs using the storage that are running on that "selected host"? Because if this is the case, I would connect all my host machines to the dedicated storage network, create multiple data domains and "split" my iSCSI storage server(s) among those domains. If it is not the case, I would only have my storage server(s) and one of my hosts in the storage network. This also has implications on the dimensions (and cost!) of the switch that I use for the storage network, so I would be grateful if someone has any insight. Thanks

3 4

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