November 2016 - Devel - oVirt List Archives

Re: [ovirt-devel] [ovirt-users] Recommended Ovirt Implementation on Active-Active Datacenters (Site 1 and Site2) - Same Cluster
by Roy Golan 24 Nov '16

24 Nov '16

On Nov 24, 2016 5:01 PM, "Roy Golan" <rgolan(a)redhat.com> wrote: Reposting to list > Affinity labels [1] will allow you to label the hosts and vms to site1 and site2 and that should be it. > > - create label per site > - add the redpective label to each vm and host > > Unfortunately there is no UI for that but with SDK or rest it's easy > > [1] https://www.ovirt.org/blog/2016/07/affinity-labels/ > > > On Nov 24, 2016 3:12 PM, "Rogério Ceni Coelho" < rogeriocenicoelho(a)gmail.com> wrote: >> >> Hi Ovirt Jedi´s !!! >> >> First of all, congrats about the product !!! I love Ovirt !!! >> >> I am using Ovirt 4.0.4 with 10 hosts and 58 virtual machines on two Active-Active Datacenters using two EMC Vplex + two EMC VNX5500 + eight Dell Blades + 8 Dell PowerEdge M610 and two M620 Servers. >> >> Half servers are on Site 1 and Half servers on Site 2. The same with VMs. All Sites work as one and have redundant network, storage, power, etc etc etc ... >> >> I want to know what is the best way to set that VM number 1 runs on Site 1 and VM number 2 runs on Site 2 ? >> >> On Vmware 5.1 we use DRS Group Manager and on Hyper-V we use Custom Properties on hosts and on VMs. What we use on oVirt without segregate on two different Datacenters or two different clusters ? >> >> Thanks in advance. >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >>

1 0

master deps broken for el7
by Sandro Bonazzola 24 Nov '16

24 Nov '16

Hi, FYI, jenkins detected broken dependencies issues withing vdsm package. It seems that some package are missing so I'm rebuilding the repository. Some failures may happen in the next 45 minutes. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

When you 'select *' you actually use ~10% of the data
by Michal Skrivanek 24 Nov '16

24 Nov '16

reposting > On 23 Nov 2016, at 10:22, Arik Hadas <ahadas(a)redhat.com> wrote: > > +1 > And this should come as no surprise to one that read [1] - it shows that querying 6000 VMs that run on a particular host in the monitoring took 765.774 ms on 3.6 by querying the 'vms' view while on master the same task (on the same database) took 2.703 ms by querying only the dynamic VM data (vm_dynamic). > Following this result, we (virt) already replaced calls to queries that are based on the heavy 'vms' view with ones that call lighter queries that are based on 'vm_static' and 'vm_dynamic' in most of the core virt flows. We also introduced lighter query named 'vms_monitoring_view' that is already used in several places (and can be used even further) instead of 'vms'. This principle is recommended in other places and for other entities (where appropriate) as well. > > [1] http://www.ovirt.org/blog/2016/08/monitoring-improvements-in-ovirt/ > > ---- Original Message — > On Wed, Nov 23, 2016 at 10:34 AM, Roy Golan <rgolan(a)redhat.com> wrote: >> It turns our that our busiest UI grids, 'Vms', 'Hosts', 'Disks' are using >> fraction of the data they really need. Every time we load the tab, or >> refresh it we invoke a 'SearchQuery' which effectively is translated to >> 'SELECT * from VIEW LIMIT 100'. Our views contains HUGH amount of joins >> just to feed the monster while we don't need it at all. >> >> See this table to understand how far we got: >> >> Grid name | Grid column count | # of columns in view | # of joins in view >> >> Vms tab | 14 | 161 | 9 >> Hosts tab | 11 | 137 | 8 >> Disks | 9 | 58 | 9 >> >> >> The numbers are not precise cause few more fields are needed for internal >> logic probably but this is very close the actual num. The numbers of views >> involved may even be higher because some of the view are using... more views >> >> >> This is not UI specific. Tons of bll code uses the views entities just >> because >> its easy while working with tailoring a query to your needs would perform way >> better. We obviously need to STOP doing that and create code that will >> encourage >> us to do get just enough data we need. This is a debate about or dal >> layer and its >> relationship with stored procedure AND our coding guidelines with db >> interaction. >> >> I didn't measure the effec tof moving to specific queries and using the >> result >> but I'm pretty sure it's going to be dramatic. >> >> So please, as a start, stop using the views cause it's easy, prefer the >> tables and create >> procedure to support your data needs. >> >> >> I opened a bug for that to track that and will work on POC to measure the >> effect >> >> *Bug 1397691* <https://bugzilla.redhat.com/show_bug.cgi?id=1397691> - >> [scale] UI grids queries all fields while ~10% is actually needed >> > >

1 0

[ ERROR ] schema.sh: Please fix numbering to interval 04010491 to 04010500 and run the upgrade script.
by Sandro Bonazzola 24 Nov '16

24 Nov '16

engine master CI is failing on $subject, please fix or revert as soon as possible, thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

7 13

snapshot merge failing on Experimental
by Evgheni Dereveanchin 24 Nov '16

24 Nov '16

Hi everyone, CI is failing on snapshot merge tests: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3618/testR… Not sure what is causing this but I see several patches that may be related that were recently merged: https://gerrit.ovirt.org/#/c/67064 https://gerrit.ovirt.org/#/c/67184 Could someone please check why it's happening as we need to fix/revert the problematic patch to make tests work again. Regards, Evgheni Dereveanchin

6 6

Restoring ovirt-release-master rpm
by Sandro Bonazzola 23 Nov '16

23 Nov '16

Looks like someone deleted ovirt-release-master rpm from http://resources.ovirt.org/pub/yum-repo/ breaking several stuff including website documentation. I'm restoring it, please avoid removing rpms without discussing it. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

Removal of xmlrpc
by Piotr Kliczewski 23 Nov '16

23 Nov '16

I am working on xmlrpc removal from the engine. I see bunch of references in [1] to xmlrpc client. Is there any reason why we need it? Do we plan to rewrite it to use other protocol? I am going to leave this code and xmlrpc dependency in the engine so we can improve it later. Thanks, Piotr [1] https://github.com/oVirt/ovirt-engine/blob/67880b549bada18aa3466d20a77da5c0…

2 1

Project ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64 is failing
by Sandro Bonazzola 23 Nov '16

23 Nov '16

http://jenkins.ovirt.org/job/ovirt-engine-api-model_4.0_build-artifacts-fc2… *00:04:35.993* + mv target/model.json exported-artifacts*00:04:35.993* mv: cannot stat 'target/model.json': No such file or directory*00:04:35.993* Took 93 seconds Can you please have a look? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 6

[VDSM] FAIL: test_intra_domain_copy('block', 'cow', 'cow') (storage_sdm_copy_data_test.TestCopyDataDIV)
by Nir Soffer 23 Nov '16

23 Nov '16

This test pass usually, Adam, can you check this? 21:15:52 ====================================================================== 21:15:52 FAIL: test_intra_domain_copy('block', 'cow', 'cow') (storage_sdm_copy_data_test.TestCopyDataDIV) 21:15:52 ---------------------------------------------------------------------- 21:15:52 Traceback (most recent call last): 21:15:52 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 133, in wrapper 21:15:52 return f(self, *args) 21:15:52 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_sdm_copy_data_test.py", line 138, in test_intra_domain_copy 21:15:52 self.assertEqual(100.0, job.progress) 21:15:52 AssertionError: 100.0 != 0.0 21:15:52 -------------------- >> begin captured logging << -------------------- 21:15:52 2016-11-16 21:14:26,096 DEBUG (MainThread) [storage.PersistentDict] Created a persistent dict with VGTagMetadataRW backend (persistent:194) 21:15:52 2016-11-16 21:14:26,096 DEBUG (MainThread) [storage.PersistentDict] read lines (VGTagMetadataRW)=[] (persistent:236) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] Empty metadata (persistent:254) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] Starting transaction (persistent:169) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] Flushing changes (persistent:175) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] about to write lines (VGTagMetadataRW)=['CLASS=Data', 'POOL_UUID=fb6edad8-51ab-4aad-9090-a833efd6a1e2', 'SDUUID=beb999a9-a90b-4c49-9d4c-7b21b3adb164', 'VERSION=3', '_SHA_CKSUM=63ec9e7bc3d23a7da8ef5e318fdd65203ac7c3fe'] (persistent:307) 21:15:52 2016-11-16 21:14:26,098 DEBUG (MainThread) [storage.Metadata.VGTagMetadataRW] Updating metadata adding=MDT__SHA_CKSUM=63ec9e7bc3d23a7da8ef5e318fdd65203ac7c3fe, MDT_VERSION=3, MDT_POOL_UUID=fb6edad8-51ab-4aad-9090-a833efd6a1e2, MDT_CLASS=Data, MDT_SDUUID=beb999a9-a90b-4c49-9d4c-7b21b3adb164 removing= (blockSD:296) 21:15:52 2016-11-16 21:14:26,098 DEBUG (MainThread) [storage.PersistentDict] Finished transaction (persistent:177) 21:15:52 2016-11-16 21:14:26,101 WARNING (MainThread) [storage.StorageDomainManifest] Could not find mapping for lv beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 (blockSD:786) 21:15:52 2016-11-16 21:14:26,101 DEBUG (MainThread) [storage.StorageDomainManifest] Found freeSlot 4 in VG beb999a9-a90b-4c49-9d4c-7b21b3adb164 (blockSD:759) 21:15:52 2016-11-16 21:14:26,103 DEBUG (MainThread) [storage.VolumeManifest] Creating symlink from /var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 to /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 (blockVolume:147) 21:15:52 2016-11-16 21:14:26,103 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /usr/bin/qemu-img create -f qcow2 -o compat=0.10 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 1048576 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,144 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,148 WARNING (MainThread) [storage.StorageDomainManifest] Could not find mapping for lv beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (blockSD:786) 21:15:52 2016-11-16 21:14:26,148 DEBUG (MainThread) [storage.StorageDomainManifest] Found freeSlot 5 in VG beb999a9-a90b-4c49-9d4c-7b21b3adb164 (blockSD:759) 21:15:52 2016-11-16 21:14:26,149 DEBUG (MainThread) [storage.VolumeManifest] Creating symlink from /var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa to /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (blockVolume:147) 21:15:52 2016-11-16 21:14:26,150 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /usr/bin/qemu-img create -f qcow2 -o compat=0.10 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa 1048576 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,195 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,196 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,207 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000394548 s, 1.3 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,208 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000394548 s, 1.3 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,209 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 qemu-io -f qcow2 -c 'write -P 240 0 1024' /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,257 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,260 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,274 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000359356 s, 1.4 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,274 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000359356 s, 1.4 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,275 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 qemu-io -f qcow2 -c 'read -P 240 -s 0 -l 1024 0 1024' /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,316 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,318 INFO (MainThread) [root] Running job 'f8a60ab8-2ba9-473d-bf46-82080c283137'... (jobs:179) 21:15:52 2016-11-16 21:14:26,320 INFO (MainThread) [storage.VolumeManifest] Volume: preparing volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 (volume:462) 21:15:52 2016-11-16 21:14:26,321 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,335 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000302993 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,336 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000302993 s, 1.7 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,338 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,351 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000368094 s, 1.4 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,352 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000368094 s, 1.4 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,354 INFO (MainThread) [storage.VolumeManifest] Volume: preparing volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (volume:462) 21:15:52 2016-11-16 21:14:26,355 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,368 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000382558 s, 1.3 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,369 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000382558 s, 1.3 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,370 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,388 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000326875 s, 1.6 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,389 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000326875 s, 1.6 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,391 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,404 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000335536 s, 1.5 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,405 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000335536 s, 1.5 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,406 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,420 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000292733 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,421 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000292733 s, 1.7 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,422 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,436 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000359596 s, 1.4 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,437 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000359596 s, 1.4 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,438 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,451 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000322085 s, 1.6 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,452 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000322085 s, 1.6 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,454 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,467 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.00033405 s, 1.5 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,468 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.00033405 s, 1.5 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,469 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:16:08 2016-11-16 21:14:26,481 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.00030909 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:16:08 2016-11-16 21:14:26,482 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.00030909 s, 1.7 MB/s'], size: 512 (misc:138) 21:16:08 2016-11-16 21:14:26,483 INFO (MainThread) [storage.VolumeManifest] sdUUID=beb999a9-a90b-4c49-9d4c-7b21b3adb164 imgUUID=939d015f-e57e-4bf1-9013-b648fae347ae volUUID = 0e7c49ae-6c7c-4526-89c2-17b923c70dfa legality = ILLEGAL (volume:368) 21:16:08 2016-11-16 21:14:26,484 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:16:08 2016-11-16 21:14:26,497 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000307797 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:16:08 2016-11-16 21:14:26,498 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000307797 s, 1.7 MB/s'], size: 512 (misc:138) 21:16:08 2016-11-16 21:14:26,502 DEBUG (MainThread) [QemuImg] /usr/bin/taskset --cpu-list 0-3 /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /usr/bin/qemu-img convert -p -t none -T none -f qcow2 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 -O qcow2 -o compat=0.10 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (cwd None) (qemuimg:247) 21:16:08 2016-11-16 21:14:26,805 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:16:08 2016-11-16 21:14:26,820 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000380116 s, 1.3 MB/s\n'; <rc> = 0 (commands:93) 21:16:08 2016-11-16 21:14:26,821 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000380116 s, 1.3 MB/s'], size: 512 (misc:138) 21:16:08 2016-11-16 21:14:26,823 INFO (MainThread) [storage.VolumeManifest] Tearing down volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa justme True (blockVolume:386) 21:16:08 2016-11-16 21:14:26,824 INFO (MainThread) [storage.VolumeManifest] Tearing down volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 justme True (blockVolume:386) 21:16:08 2016-11-16 21:14:26,824 INFO (MainThread) [root] Job 'f8a60ab8-2ba9-473d-bf46-82080c283137' completed (jobs:203) 21:16:08 2016-11-16 21:14:26,825 INFO (MainThread) [root] Job 'f8a60ab8-2ba9-473d-bf46-82080c283137' will be deleted in 3600 seconds (jobs:245) 21:16:08 --------------------- >> end captured logging << ---------------------

2 4

engine-setup failed on master on Centos 7
by Martin Perina 22 Nov '16

22 Nov '16

Hi, if you have recently tried to install master engine on Centos 7, you may have encountered following error during engine-setup: Failed to execute stage 'Misc configuration': Command '/usr/bin/ovirt-aaa-jdbc-tool' failed to execute This is currently tracked by [1] and it's caused by faulty slfj4 1.7.10 package in virt7-ovirt-common-candidate repository. We have untagged faulty package from the repository, but to fix the error you need to downgrade package version to slf4j 1.7.4 provided by Centos [2]. Sorry for inconvenience Martin Perina [1] https://bugzilla.redhat.com/show_bug.cgi?id=1394656 [2] http://mirror.centos.org/centos/7/os/x86_64/Packages/slf4j-1.7.4-3.el7.noar…

1 0

blockcommit and gluster network disk path
by Sahina Bose 22 Nov '16

22 Nov '16

Hi, I'm running into problems with blockcommit and gluster network disks - wanted to check how to pass path for network disks. How's the protocol and host parameters specified? For a backing volume chain as below, executing virsh blockcommit fioo5 vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c --base vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/d4c23ec6-20ce-4a2f-9b32-ca91e65a114a --top vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c --verbose --wait gives "error: invalid argument: No device found for specified path". <disk type='network' device='disk' snapshot='no'> <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='threads'/> <source protocol='gluster' name='vmstore/912d9062-3881-47 9b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6 d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c'> <host name='10.70.37.28' port='0'/> </source> <backingStore type='network' index='1'> <format type='qcow2'/> <source protocol='gluster' name='vmstore/912d9062-3881-47 9b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6 d8a4/d4c23ec6-20ce-4a2f-9b32-ca91e65a114a'> <host name='10.70.37.28' port='0'/> </source> <backingStore type='network' index='2'> <format type='raw'/> <source protocol='gluster' name='vmstore/912d9062-3881-47 9b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6 d8a4/f5098809-e719-404b-8d80-3f824f4333a2'> <host name='10.70.37.28' port='0'/> </source> <backingStore/> </backingStore> </backingStore> <target dev='vda' bus='virtio'/> <serial>27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4</serial> <boot order='2'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> thanks sahina

1 1

[Call for Vote] Proposal for new Incubator Project
by Brian Proffitt 22 Nov '16

22 Nov '16

All: This project was initially proposed for review on Oct. 9. It has been reviewed for major issues and having heard no objections, it's now time to formally vote on accepting this as an official oVirt incubator subproject. The last time we voted on one of these was during an IRC weekly meeting, so I believe it is appropriate to post a Call for Vote on the Devel and Board lists. Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5 votes should be received to formalize this project as an incubator subproject. Please use the following vote process: +1 Yes, agree, or the action should be performed. On some issues, this vote must only be given after the voter has tested the action on their own system(s). ±0 Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental affects if too many people abstain. -1 No, I veto this action. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void. Thank you! Brian Proffitt --- Project Proposal - Vagrant Provider A vagrant provider for oVirt v4 Abstract This will be a provider plugin for the Vagrant suite that allows command-line ease of virtual machine provisioning and lifecycle management. Proposal This Vagrant provider plugin will interface with the oVirt REST API (version 4 and higher) using the oVirt provided ruby SDK 'ovirt-engine-sdk-ruby'. This allows users to abstract the user interface and experience into a set of command line abilities to create, provision, destroy and manage the complete lifecycle of virtual machines. It also allows the use of external configuration management and configuration files themselves to be committed into code. Background I have previously forked and maintained the 'vagrant-ovirt' gem as 'vagrant-ovirt3' due to Gems requiring unique names. The original author has officially abandoned the project. For the last few years all code to maintain this project has been maintained by myself and a few ad-hoc github contributors. This provider interfaced directly with oVirt v3 using fog and rbovirt. The new project would be a fresh start using the oVirt provided ruby SDK to work directly with version 4. Rationale The trend in configuration management, operations, and devops has been to maintain as much of the development process as possible in terms of the virtual machines and hosts that they run on. With software like Terraform the tasks of creating the underlying infrastructure such as network rules, etc have had great success moving into 'Infrastructure as code'. The same company behind Terraform got their reputation from Vagrant which aims to utilize the same process for virtual machines themselves. The core software allows for standard commands such as 'up', 'provision', 'destroy' to be used across a provider framework. A provider for oVirt makes the process for managing VMs easier and able to be controlled through code and source control. Initial Goals The initial goal is to get the base steps of 'up', 'down' (halt), and 'destroy' to succeed using the oVirt provided ruby SDK for v4. Stretch/followup goals would be to ensure testability and alternate commands such as 'provision' and allow configuration management suites like puppet to work via 'userdata' (cloud-init). Current Status The version 3 of this software has been heavily utilized. The original fork known as 'vagrant-ovirt' has been abandoned with no plans to communicate or move forward. My upstream fork has had great success with nearly 4x the downloads from rubygems.org . Until my github fork has more 'stars' I cannot take over it completely so the gem was renamed 'vagrant-ovirt3'. This is also true for rubygems.org since gems are not namespaced, therefore could not be published without a unique name. The v4 provider is still pending my initial POC commit but there are no current barriers except initial oVirt hosting. The hosting of oVirt v3 for testing is a laptop on a UPS at my home, and v4 is also a different pc attached to a UPS. External Dependencies RHEVM/oVirt REST API - This provider must interact with the API itself to manage virtual machines. Initial Committers Marcus Young ( 3vilpenguin at gmail dot com ) -- Brian Proffitt Principal Community Analyst Open Source and Standards @TheTechScribe 574.383.9BKP

15 14

Fwd: New Defects reported by Coverity Scan for ovirt-engine
by Michal Skrivanek 21 Nov '16

21 Nov '16

--Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Not sure who touched that, but since it's a NPE - Tal, can you doublecheck p= lease? Begin forwarded message: > From: scan-admin(a)coverity.com > Date: 21 November 2016 at 21:13:22 GMT+1 > To: mskrivan(a)redhat.com > Subject: New Defects reported by Coverity Scan for ovirt-engine >=20 >=20 > Hi, >=20 > Please find the latest report on new defect(s) introduced to ovirt-engine f= ound with Coverity Scan. >=20 > 2 new defect(s) introduced to ovirt-engine found with Coverity Scan. > 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the r= ecent build analyzed by Coverity Scan. >=20 > New defect(s) Reported-by: Coverity Scan > Showing 2 of 2 defect(s) >=20 >=20 > ** CID 1366189: Null pointer dereferences (NULL_RETURNS) > /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vds= broker/vdsbroker/GetDeviceListVDSCommand.java: 112 in org.ovirt.engine.core.= vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map= , org.ovirt.engine.core.compat.Version)() >=20 >=20 > __________________________________________________________________________= ______________________________ > *** CID 1366189: Null pointer dereferences (NULL_RETURNS) > /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vds= broker/vdsbroker/GetDeviceListVDSCommand.java: 112 in org.ovirt.engine.core.= vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map= , org.ovirt.engine.core.compat.Version)() > 106 .put(xcon.get(PHYSICAL_DEVICE_FIEL= D).toString(), > 107 DEVICE_ACTIVE_VALUE.equals= (xcon.get(DEVICE_STATE_FIELD).toString())); > 108 } > 109 if (xcon.containsKey(PHYSICAL_DEVICE_FIELD) &&= xcon.containsKey(DEVICE_PATH_CAPACITY_FIELD)) { > 110 // set name and capacity > 111 Long size =3D IrsBrokerCommand.assignLongV= alue(xcon, DEVICE_PATH_CAPACITY_FIELD); >>>> CID 1366189: Null pointer dereferences (NULL_RETURNS) >>>> Unboxing null object "size". > 112 lun.getPathsCapacity() > 113 .put(xcon.get(PHYSICAL_DEVICE_FIEL= D).toString(), > 114 SizeConverter.convert(size= , > 115 SizeConverter.Size= Unit.BYTES, SizeConverter.SizeUnit.GiB).intValue()); > 116 } > 117 } >=20 > ** CID 1366190: Resource leaks (RESOURCE_LEAK) > /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/stora= ge/CommandsWeightsUtilsTest.java: 37 in org.ovirt.engine.core.bll.storage.Co= mmandsWeightsUtilsTest.adjustWeights(java.util.List, java.util.List, int)() >=20 >=20 > __________________________________________________________________________= ______________________________ > *** CID 1366190: Resource leaks (RESOURCE_LEAK) > /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/stora= ge/CommandsWeightsUtilsTest.java: 37 in org.ovirt.engine.core.bll.storage.Co= mmandsWeightsUtilsTest.adjustWeights(java.util.List, java.util.List, int)() > 31 adjustWeights(Arrays.<Double> asList(0.33, 0.37, 0.3), Arra= ys.<Integer> asList(3, 3, 4), 10); > 32 } > 33 =20 > 34 public void adjustWeights(List<Double> weightParts, List<Intege= r> expectedWeightsSorted, int totalWeight) { > 35 assertFalse(weightsUtils =3D=3D null); > 36 Map<String, Double> map =3D new HashMap<>(); >>>> CID 1366190: Resource leaks (RESOURCE_LEAK) >>>> Failing to save or close resource created by "java.util.stream.IntSt= ream.range(0, weightParts.size())" leaks it. > 37 IntStream.range(0, weightParts.size()).forEach(i -> map.put= (String.valueOf(i), weightParts.get(i))); > 38 Map<String, Integer> res =3D weightsUtils.adjust(map, total= Weight); > 39 assertEquals("adjusted weights sum should be equal to the t= otal weight", > 40 totalWeight, > 41 res.values().stream().mapToInt(x -> x).sum()); > 42 =20 >=20 >=20 > __________________________________________________________________________= ______________________________ > To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.n= et/wf/click?upn=3D08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRY9v3SZ-2= BLqhn66fucWz5NChdV2QNZzLQCPY1fjqQGlAKjFKQ4pnDnQ8dtAwvCE2G0E-3D_xDvy9aTtFVlNg= NTFLiCVD0cicL2K6Y3d-2BJIBr-2FpAeMq2Gor5C1ZEiQuot3av2-2FBnTXIjnZdjb0Cw-2FiZV5= z3DRotm2ow-2BiwdoVplKeuk7nRFrRXzS4jJb3IZXBSxeZC0bc8KPnuElHCtQryUJ5u-2FY6QjMU= nZuFDu-2BC21coRtHfPr1uF9ZCvkTQAT-2Bg5drHSbNPaszp0YnZzvaUGArGUlXQkPt48dc-2FNZ= aixgGomwsPPQ-3D >=20 > To manage Coverity Scan email notifications for "mskrivan(a)redhat.com", cli= ck https://u2389337.ct.sendgrid.net/wf/click?upn=3D08onrYu34A-2BWcWUl-2F-2Bf= V0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4QYNJdvz3-2Bo6D7kzKGM4BieGXc= FZeVj8bblbpPZS135zo-2F9pagiHHlVMtL1t-2BQNkdMMpi2fcAFj8yWlY6sxZhzNUWHvSkeP6Ld= DHUGDSs8PI-3D_xDvy9aTtFVlNgNTFLiCVD0cicL2K6Y3d-2BJIBr-2FpAeMq2Gor5C1ZEiQuot3= av2-2FBnYwmACJZZa-2BkRa13JTRgm4K6JnogNoqDZTzNvLRxP6Val1P03EDtJ3QxTG8urJ-2FCT= uXNzEDZ24au9cRqVgy9YVPOiVSvw7tAY4dzssRc8ERmy1mCzlCbU6-2B9s01kYf0EYko6e7QKj2V= pVxVJD8bRNr-2FNXcUSv-2Bu1fA612id1LcCM-3D >=20 --Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj5Ob3Qgc3VyZSB3aG8gdG91Y2hlZCB0aGF0LCBidXQgc2luY2UgaXQncyBhIE5QRSAtIFRh bCwgY2FuIHlvdSBkb3VibGVjaGVjayBwbGVhc2U/PGJyPjxicj48YnI+QmVnaW4gZm9yd2FyZGVk IG1lc3NhZ2U6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxiPkZy b206PC9iPiA8YSBocmVmPSJtYWlsdG86c2Nhbi1hZG1pbkBjb3Zlcml0eS5jb20iPnNjYW4tYWRt aW5AY292ZXJpdHkuY29tPC9hPjxicj48Yj5EYXRlOjwvYj4gMjEgTm92ZW1iZXIgMjAxNiBhdCAy MToxMzoyMiBHTVQrMTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptc2tyaXZhbkByZWRo YXQuY29tIj5tc2tyaXZhbkByZWRoYXQuY29tPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gPGI+TmV3 IERlZmVjdHMgcmVwb3J0ZWQgYnkgQ292ZXJpdHkgU2NhbiBmb3Igb3ZpcnQtZW5naW5lPC9iPjxi cj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNw YW4+PC9zcGFuPjxicj48c3Bhbj5IaSw8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+ UGxlYXNlIGZpbmQgdGhlIGxhdGVzdCByZXBvcnQgb24gbmV3IGRlZmVjdChzKSBpbnRyb2R1Y2Vk IHRvIG92aXJ0LWVuZ2luZSBmb3VuZCB3aXRoIENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48c3Bh bj48L3NwYW4+PGJyPjxzcGFuPjIgbmV3IGRlZmVjdChzKSBpbnRyb2R1Y2VkIHRvIG92aXJ0LWVu Z2luZSBmb3VuZCB3aXRoIENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48c3Bhbj4xIGRlZmVjdChz KSwgcmVwb3J0ZWQgYnkgQ292ZXJpdHkgU2NhbiBlYXJsaWVyLCB3ZXJlIG1hcmtlZCBmaXhlZCBp biB0aGUgcmVjZW50IGJ1aWxkIGFuYWx5emVkIGJ5IENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48 c3Bhbj48L3NwYW4+PGJyPjxzcGFuPk5ldyBkZWZlY3QocykgUmVwb3J0ZWQtYnk6IENvdmVyaXR5 IFNjYW48L3NwYW4+PGJyPjxzcGFuPlNob3dpbmcgMiBvZiAyIGRlZmVjdChzKTwvc3Bhbj48YnI+ PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPioqIENJRCAxMzY2MTg5OiAm bmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2VzICZuYnNwOyhOVUxMX1JFVFVSTlMpPC9zcGFu Pjxicj48c3Bhbj4vYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvdmRzYnJva2VyL3NyYy9tYWluL2ph dmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3Zkc2Jyb2tlci92ZHNicm9rZXIvR2V0RGV2aWNlTGlz dFZEU0NvbW1hbmQuamF2YTogMTEyIGluIG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIu dmRzYnJva2VyLkdldERldmljZUxpc3RWRFNDb21tYW5kLnBhcnNlTHVuRnJvbVhtbFJwYyhqYXZh LnV0aWwuTWFwLCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuY29tcGF0LlZlcnNpb24pKCk8L3NwYW4+ PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+KioqIENJ RCAxMzY2MTg5OiAmbmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2VzICZuYnNwOyhOVUxMX1JF VFVSTlMpPC9zcGFuPjxicj48c3Bhbj4vYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvdmRzYnJva2Vy L3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3Zkc2Jyb2tlci92ZHNicm9rZXIv R2V0RGV2aWNlTGlzdFZEU0NvbW1hbmQuamF2YTogMTEyIGluIG9yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIudmRzYnJva2VyLkdldERldmljZUxpc3RWRFNDb21tYW5kLnBhcnNlTHVuRnJv bVhtbFJwYyhqYXZhLnV0aWwuTWFwLCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuY29tcGF0LlZlcnNp b24pKCk8L3NwYW4+PGJyPjxzcGFuPjEwNiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsucHV0KHhjb24uZ2V0KFBIWVNJQ0FMX0RFVklDRV9GSUVMRCkudG9TdHJp bmcoKSw8L3NwYW4+PGJyPjxzcGFuPjEwNyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtERVZJQ0VfQUNUSVZFX1ZBTFVFLmVxdWFscyh4Y29uLmdldChERVZJQ0VfU1RBVEVfRklF TEQpLnRvU3RyaW5nKCkpKTs8L3NwYW4+PGJyPjxzcGFuPjEwOCAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt9PC9zcGFuPjxicj48c3Bhbj4xMDkgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7aWYgKHhjb24uY29udGFpbnNLZXkoUEhZU0lDQUxfREVWSUNFX0ZJRUxEKSAmYW1wOyZh bXA7IHhjb24uY29udGFpbnNLZXkoREVWSUNFX1BBVEhfQ0FQQUNJVFlfRklFTEQpKSB7PC9zcGFu Pjxicj48c3Bhbj4xMTAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Ly8gc2V0IG5hbWUgYW5kIGNhcGFjaXR5PC9zcGFuPjxicj48c3Bhbj4xMTEg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TG9u ZyBzaXplID0gSXJzQnJva2VyQ29tbWFuZC5hc3NpZ25Mb25nVmFsdWUoeGNvbiwgREVWSUNFX1BB VEhfQ0FQQUNJVFlfRklFTEQpOzwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNw OyZuYnNwOyZuYnNwO0NJRCAxMzY2MTg5OiAmbmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2Vz ICZuYnNwOyhOVUxMX1JFVFVSTlMpPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7VW5i b3hpbmcgbnVsbCBvYmplY3QgInNpemUiLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PHNwYW4+MTEyICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2x1bi5nZXRQYXRoc0NhcGFjaXR5KCk8L3NwYW4+PGJy PjxzcGFuPjExMyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsu cHV0KHhjb24uZ2V0KFBIWVNJQ0FMX0RFVklDRV9GSUVMRCkudG9TdHJpbmcoKSw8L3NwYW4+PGJy PjxzcGFuPjExNCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTaXplQ29udmVy dGVyLmNvbnZlcnQoc2l6ZSw8L3NwYW4+PGJyPjxzcGFuPjExNSAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtTaXplQ29udmVydGVyLlNpemVVbml0LkJZVEVTLCBTaXplQ29udmVydGVyLlNpemVV bml0LkdpQikuaW50VmFsdWUoKSk7PC9zcGFuPjxicj48c3Bhbj4xMTYgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48YnI+PHNwYW4+MTE3ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PGJyPjxz cGFuPjwvc3Bhbj48YnI+PHNwYW4+KiogQ0lEIDEzNjYxOTA6ICZuYnNwO1Jlc291cmNlIGxlYWtz ICZuYnNwOyhSRVNPVVJDRV9MRUFLKTwvc3Bhbj48YnI+PHNwYW4+L2JhY2tlbmQvbWFuYWdlci9t b2R1bGVzL2JsbC9zcmMvdGVzdC9qYXZhL29yZy9vdmlydC9lbmdpbmUvY29yZS9ibGwvc3RvcmFn ZS9Db21tYW5kc1dlaWdodHNVdGlsc1Rlc3QuamF2YTogMzcgaW4gb3JnLm92aXJ0LmVuZ2luZS5j b3JlLmJsbC5zdG9yYWdlLkNvbW1hbmRzV2VpZ2h0c1V0aWxzVGVzdC5hZGp1c3RXZWlnaHRzKGph dmEudXRpbC5MaXN0LCBqYXZhLnV0aWwuTGlzdCwgaW50KSgpPC9zcGFuPjxicj48c3Bhbj48L3Nw YW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPioqKiBDSUQgMTM2NjE5MDogJm5i c3A7UmVzb3VyY2UgbGVha3MgJm5ic3A7KFJFU09VUkNFX0xFQUspPC9zcGFuPjxicj48c3Bhbj4v YmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvYmxsL3NyYy90ZXN0L2phdmEvb3JnL292aXJ0L2VuZ2lu ZS9jb3JlL2JsbC9zdG9yYWdlL0NvbW1hbmRzV2VpZ2h0c1V0aWxzVGVzdC5qYXZhOiAzNyBpbiBv cmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnN0b3JhZ2UuQ29tbWFuZHNXZWlnaHRzVXRpbHNUZXN0 LmFkanVzdFdlaWdodHMoamF2YS51dGlsLkxpc3QsIGphdmEudXRpbC5MaXN0LCBpbnQpKCk8L3Nw YW4+PGJyPjxzcGFuPjMxICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FkanVzdFdlaWdodHMoQXJyYXlzLiZsdDtE b3VibGUmZ3Q7IGFzTGlzdCgwLjMzLCAwLjM3LCAwLjMpLCBBcnJheXMuJmx0O0ludGVnZXImZ3Q7 IGFzTGlzdCgzLCAzLCA0KSwgMTApOzwvc3Bhbj48YnI+PHNwYW4+MzIgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48YnI+PHNwYW4+MzMgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxicj48c3Bhbj4zNCAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwdWJsaWMgdm9pZCBhZGp1c3RXZWlnaHRz KExpc3QmbHQ7RG91YmxlJmd0OyB3ZWlnaHRQYXJ0cywgTGlzdCZsdDtJbnRlZ2VyJmd0OyBleHBl Y3RlZFdlaWdodHNTb3J0ZWQsIGludCB0b3RhbFdlaWdodCkgezwvc3Bhbj48YnI+PHNwYW4+MzUg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7YXNzZXJ0RmFsc2Uod2VpZ2h0c1V0aWxzID09IG51bGwpOzwvc3Bhbj48 YnI+PHNwYW4+MzYgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWFwJmx0O1N0cmluZywgRG91YmxlJmd0OyBtYXAg PSBuZXcgSGFzaE1hcCZsdDsmZ3Q7KCk7PC9zcGFuPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4g Jm5ic3A7Jm5ic3A7Jm5ic3A7Q0lEIDEzNjYxOTA6ICZuYnNwO1Jlc291cmNlIGxlYWtzICZuYnNw OyhSRVNPVVJDRV9MRUFLKTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwO0ZhaWxpbmcg dG8gc2F2ZSBvciBjbG9zZSByZXNvdXJjZSBjcmVhdGVkIGJ5ICJqYXZhLnV0aWwuc3RyZWFtLklu dFN0cmVhbS5yYW5nZSgwLCB3ZWlnaHRQYXJ0cy5zaXplKCkpIiBsZWFrcyBpdC48L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxzcGFuPjM3ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO0ludFN0cmVhbS5yYW5nZSgwLCB3ZWlnaHRQYXJ0cy5zaXplKCkpLmZvckVhY2goaSAt Jmd0OyBtYXAucHV0KFN0cmluZy52YWx1ZU9mKGkpLCB3ZWlnaHRQYXJ0cy5nZXQoaSkpKTs8L3Nw YW4+PGJyPjxzcGFuPjM4ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO01hcCZsdDtTdHJpbmcsIEludGVnZXImZ3Q7 IHJlcyA9IHdlaWdodHNVdGlscy5hZGp1c3QobWFwLCB0b3RhbFdlaWdodCk7PC9zcGFuPjxicj48 c3Bhbj4zOSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthc3NlcnRFcXVhbHMoImFkanVzdGVkIHdlaWdodHMgc3Vt IHNob3VsZCBiZSBlcXVhbCB0byB0aGUgdG90YWwgd2VpZ2h0Iiw8L3NwYW4+PGJyPjxzcGFuPjQw ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3RvdGFsV2VpZ2h0LDwvc3Bhbj48YnI+PHNwYW4+NDEgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVzLnZhbHVlcygp LnN0cmVhbSgpLm1hcFRvSW50KHggLSZndDsgeCkuc3VtKCkpOzwvc3Bhbj48YnI+PHNwYW4+NDIg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFu Pjwvc3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PGJyPjxzcGFuPlRvIHZpZXcgdGhlIGRlZmVjdHMgaW4gQ292ZXJpdHkg U2NhbiB2aXNpdCwgPGEgaHJlZj0iaHR0cHM6Ly91MjM4OTMzNy5jdC5zZW5kZ3JpZC5uZXQvd2Yv Y2xpY2s/dXBuPTA4b25yWXUzNEEtMkJXY1dVbC0yRi0yQmZWMFYwNVVQeHZWaldjaC0yQmQyTUdj a2NSWTl2M1NaLTJCTHFobjY2ZnVjV3o1TkNoZFYyUU5aekxRQ1BZMWZqcVFHbEFLakZLUTRwbkRu UThkdEF3dkNFMkcwRS0zRF94RHZ5OWFUdEZWbE5nTlRGTGlDVkQwY2ljTDJLNlkzZC0yQkpJQnIt MkZwQWVNcTJHb3I1QzFaRWlRdW90M2F2Mi0yRkJuVFhJam5aZGpiMEN3LTJGaVpWNXozRFJvdG0y b3ctMkJpd2RvVnBsS2V1azduUkZyUlh6UzRqSmIzSVpYQlN4ZVpDMGJjOEtQbnVFbEhDdFFyeVVK NXUtMkZZNlFqTVVuWnVGRHUtMkJDMjFjb1J0SGZQcjF1RjlaQ3ZrVFFBVC0yQmc1ZHJIU2JOUGFz enAwWW5aenZhVUdBckdVbFhRa1B0NDhkYy0yRk5aYWl4Z0dvbXdzUFBRLTNEIj5odHRwczovL3Uy Mzg5MzM3LmN0LnNlbmRncmlkLm5ldC93Zi9jbGljaz91cG49MDhvbnJZdTM0QS0yQldjV1VsLTJG LTJCZlYwVjA1VVB4dlZqV2NoLTJCZDJNR2NrY1JZOXYzU1otMkJMcWhuNjZmdWNXejVOQ2hkVjJR Tlp6TFFDUFkxZmpxUUdsQUtqRktRNHBuRG5ROGR0QXd2Q0UyRzBFLTNEX3hEdnk5YVR0RlZsTmdO VEZMaUNWRDBjaWNMMks2WTNkLTJCSklCci0yRnBBZU1xMkdvcjVDMVpFaVF1b3QzYXYyLTJGQm5U WElqblpkamIwQ3ctMkZpWlY1ejNEUm90bTJvdy0yQml3ZG9WcGxLZXVrN25SRnJSWHpTNGpKYjNJ WlhCU3hlWkMwYmM4S1BudUVsSEN0UXJ5VUo1dS0yRlk2UWpNVW5adUZEdS0yQkMyMWNvUnRIZlBy MXVGOVpDdmtUUUFULTJCZzVkckhTYk5QYXN6cDBZblp6dmFVR0FyR1VsWFFrUHQ0OGRjLTJGTlph aXhnR29td3NQUFEtM0Q8L2E+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlRvIG1h bmFnZSBDb3Zlcml0eSBTY2FuIGVtYWlsIG5vdGlmaWNhdGlvbnMgZm9yICI8YSBocmVmPSJtYWls dG86bXNrcml2YW5AcmVkaGF0LmNvbSI+bXNrcml2YW5AcmVkaGF0LmNvbTwvYT4iLCBjbGljayA8 YSBocmVmPSJodHRwczovL3UyMzg5MzM3LmN0LnNlbmRncmlkLm5ldC93Zi9jbGljaz91cG49MDhv bnJZdTM0QS0yQldjV1VsLTJGLTJCZlYwVjA1VVB4dlZqV2NoLTJCZDJNR2NrY1JiVkRiaXM3MTJx WkRQLTJGQTh5MDZOcTRRWU5KZHZ6My0yQm82RDdrektHTTRCaWVHWGNGWmVWajhiYmxicFBaUzEz NXpvLTJGOXBhZ2lISGxWTXRMMXQtMkJRTmtkTU1waTJmY0FGajh5V2xZNnN4Wmh6TlVXSHZTa2VQ NkxkREhVR0RTczhQSS0zRF94RHZ5OWFUdEZWbE5nTlRGTGlDVkQwY2ljTDJLNlkzZC0yQkpJQnIt MkZwQWVNcTJHb3I1QzFaRWlRdW90M2F2Mi0yRkJuWXdtQUNKWlphLTJCa1JhMTNKVFJnbTRLNkpu b2dOb3FEWlR6TnZMUnhQNlZhbDFQMDNFRHRKM1F4VEc4dXJKLTJGQ1R1WE56RURaMjRhdTljUnFW Z3k5WVZQT2lWU3Z3N3RBWTRkenNzUmM4RVJteTFtQ3psQ2JVNi0yQjlzMDFrWWYwRVlrbzZlN1FL ajJWcFZ4VkpEOGJSTnItMkZOWGNVU3YtMkJ1MWZBNjEyaWQxTGNDTS0zRCI+aHR0cHM6Ly91MjM4 OTMzNy5jdC5zZW5kZ3JpZC5uZXQvd2YvY2xpY2s/dXBuPTA4b25yWXUzNEEtMkJXY1dVbC0yRi0y QmZWMFYwNVVQeHZWaldjaC0yQmQyTUdja2NSYlZEYmlzNzEycVpEUC0yRkE4eTA2TnE0UVlOSmR2 ejMtMkJvNkQ3a3pLR000QmllR1hjRlplVmo4YmJsYnBQWlMxMzV6by0yRjlwYWdpSEhsVk10TDF0 LTJCUU5rZE1NcGkyZmNBRmo4eVdsWTZzeFpoek5VV0h2U2tlUDZMZERIVUdEU3M4UEktM0RfeER2 eTlhVHRGVmxOZ05URkxpQ1ZEMGNpY0wySzZZM2QtMkJKSUJyLTJGcEFlTXEyR29yNUMxWkVpUXVv dDNhdjItMkZCbll3bUFDSlpaYS0yQmtSYTEzSlRSZ200SzZKbm9nTm9xRFpUek52TFJ4UDZWYWwx UDAzRUR0SjNReFRHOHVySi0yRkNUdVhOekVEWjI0YXU5Y1JxVmd5OVlWUE9pVlN2dzd0QVk0ZHpz c1JjOEVSbXkxbUN6bENiVTYtMkI5czAxa1lmMEVZa282ZTdRS2oyVnBWeFZKRDhiUk5yLTJGTlhj VVN2LTJCdTFmQTYxMmlkMUxjQ00tM0Q8L2E+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjwv ZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24--

1 0

oVirt 4.0.6 RC2 build planned
by Sandro Bonazzola 21 Nov '16

21 Nov '16

Fyi oVirt developers, An oVirt build is planned for this Tuesday 10:00 AM TLV time (9:00 AM CET). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Monday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Tuesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

oVirt 4.0.6 RC2 merge / branch / tag / bugzilla reminder
by Sandro Bonazzola 21 Nov '16

21 Nov '16

All stable branch maintainers, please make sure to merge all relevant open bugs until Wednesday morning 10:00 AM TLV time (9:00 AM CET). For each package that need to be built (i.e oVirt product) please make sure every bug in MODIFIED has the right Target Release and Target Milestone. A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.6, tr: 4.0.6) A list of bugs that require attention is here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Merge gating in Gerrit
by Barak Korren 21 Nov '16

21 Nov '16

Hi all, Perhaps the main purpose of CI, is to prevent braking code from getting merged into the stable/master branches. Unfortunately our CI is not there yet, and one of the reasons for that is that we do large amount of our CI tests only _after_ the code is merged. The reason for that is that when balancing through, but time consuming, tests (e.g. enging build with all permutations) v.s. faster but more basic ones (e.g. "findbugs" and single permutation build), we typically choose the faster tests to be run per-patch-set and leave the through testing to only be run post-merge. We'd like to change that and have the through tests also run before merge. Ideally we would like to just hook stuff to the "submit" button, but Gerrit doesn't allow one to do that easily. So instead we'll need to adopt some kind of flag to indicate we want to submit and have Jenkins "click" the submit button on our behalf if tests pass. I see two options here: 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge. 2. Add an "approve" flag that maintainers can set to +1 (This is what OpenStack is doing). What would you prefer? -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

7 10

system tests failing on template export
by Evgheni Dereveanchin 20 Nov '16

20 Nov '16

Hello, We've got several cases today where system tests failed when attempting to export templates: http://jenkins.ovirt.org/job/ovirt_master_system-tests/655/testReport/junit… Related engine.log looks something like this: https://paste.fedoraproject.org/449936/47643643/raw/ I could not find any obvious issues in SPM logs, could someone please take a look to confirm what may be causing this issue? Full logs from the test are available here: http://jenkins.ovirt.org/job/ovirt_master_system-tests/655/artifact/ Regards, Evgheni Dereveanchin

6 7

Failures in OST (4.0/master) ( was error msg from Jenkins )
by Eyal Edri 20 Nov '16

20 Nov '16

Renaming title and adding devel. On Sun, Nov 20, 2016 at 2:36 PM, Piotr Kliczewski <pkliczew(a)redhat.com> wrote: > The last failure seems to be storage related. > > @Nir please take a look. > > Here is engine side error: > > 2016-11-20 05:54:59,605 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] > (default task-5) [59fc0074] Exception: org.ovirt.engine.core. > vdsbroker.irsbroker.IRSNoMasterDomainException: IRSGenericException: > IRSErrorException: IRSNoMasterDomainException: Cannot find master domain: > u'spUUID=1ca141f1-b64d-4a52-8861-05c7de2a72b2, msdUUID=7d4bf750-4fb8-463f- > bbb0-92156c47306e' > > and here is vdsm: > > jsonrpc.Executor/5::ERROR::2016-11-20 05:54:56,331::multipath::95:: > Storage.Multipath::(resize_devices) Could not resize device > 360014052749733c7b8248628637b990f > Traceback (most recent call last): > File "/usr/share/vdsm/storage/multipath.py", line 93, in resize_devices > _resize_if_needed(guid) > File "/usr/share/vdsm/storage/multipath.py", line 101, in > _resize_if_needed > for slave in devicemapper.getSlaves(name)] > File "/usr/share/vdsm/storage/multipath.py", line 158, in getDeviceSize > bs, phyBs = getDeviceBlockSizes(devName) > File "/usr/share/vdsm/storage/multipath.py", line 150, in > getDeviceBlockSizes > "queue", "logical_block_size")).read()) > IOError: [Errno 2] No such file or directory: > '/sys/block/sdb/queue/logical_block_size' > We now see a different error in master [1], which also indicates the hosts are in a problematic state: ( failing 'assign_hosts_network_label' test ) status: 409 reason: Conflict detail: Cannot add Label. Operation can be performed only when Host status is Maintenance, Up, NonOperational. -------------------- >> begin captured logging << -------------------- [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3506/testR… > > > On Sun, Nov 20, 2016 at 12:50 PM, Eyal Edri <eedri(a)redhat.com> wrote: > >> >> >> On Sun, Nov 20, 2016 at 1:42 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote: >> >>> >>> >>> On Sun, Nov 20, 2016 at 1:30 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote: >>> >>>> >>>> >>>> On Sun, Nov 20, 2016 at 1:18 PM, Eyal Edri <eedri(a)redhat.com> wrote: >>>> >>>>> the test fails to run VM because no hosts are in UP state(?) [1], not >>>>> sure it is related to the triggering patch[2] >>>>> >>>>> status: 400 >>>>> reason: Bad Request >>>>> detail: There are no hosts to use. Check that the cluster contains at >>>>> least one host in Up state. >>>>> >>>>> Thoughts? Shouldn't we fail the test earlier we hosts are not UP? >>>>> >>>> >>>> Yes. It's more likely that we are picking the wrong host or so, but who >>>> knows - where are the engine and VDSM logs? >>>> >>> >>> A simple grep on the engine.log[1] finds serveral unrelated issues I'm >>> not sure are reported, it's despairing to even begin... >>> That being said, I don't see the issue there. We may need better logging >>> on the API level, to see what is being sent. Is it consistent? >>> >> >> Just failed now the first time, I didn't see it before. >> >> >>> Y. >>> >>> >>> [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4. >>> 0/3015/artifact/exported-artifacts/basic_suite_4.0.sh-el7/ex >>> ported-artifacts/test_logs/basic-suite-4.0/post-004_basic_ >>> sanity.py/lago-basic-suite-4-0-engine/_var_log_ovirt-engine/engine.log >>> >>>> Y. >>>> >>>> >>>>> >>>>> >>>>> [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimenta >>>>> l_4.0/3015/testReport/junit/(root)/004_basic_sanity/vm_run/ >>>>> [2] http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-arti >>>>> facts-el7-x86_64/1535/changes#detail >>>>> >>>>> >>>>> >>>>> On Sun, Nov 20, 2016 at 1:00 PM, <jenkins(a)jenkins.phx.ovirt.org> >>>>> wrote: >>>>> >>>>>> Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4. >>>>>> 0/3015/, >>>>>> Build Number: 3015, >>>>>> Build Status: FAILURE >>>>>> _______________________________________________ >>>>>> Infra mailing list >>>>>> Infra(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Eyal Edri >>>>> Associate Manager >>>>> RHV DevOps >>>>> EMEA ENG Virtualization R&D >>>>> Red Hat Israel >>>>> >>>>> phone: +972-9-7692018 >>>>> irc: eedri (on #tlv #rhev-dev #rhev-integ) >>>>> >>>> >>>> >>> >> >> >> -- >> Eyal Edri >> Associate Manager >> RHV DevOps >> EMEA ENG Virtualization R&D >> Red Hat Israel >> >> phone: +972-9-7692018 >> irc: eedri (on #tlv #rhev-dev #rhev-integ) >> > > -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

3 2

Re: [ovirt-devel] Where's MOM (on latest master)
by Michal Skrivanek 18 Nov '16

18 Nov '16

> On 18 Nov 2016, at 12:35, Martin Sivak <msivak(a)redhat.com> wrote: > >> I don't think it is related to version X or Y. It is a race, so might be >> related to other factors. > > It never (seriously: NEVER) happened with xml-rpc before 4.0.5. that is surprising but we also didn’t have lago before;-) > >> likely because json-rpc is initialized after xml-rpc….or indeed whatever >> else;-) > > But this is not about jsonrpc. The socket itself is shared according > to what Piotr said. it is > >> btw you likely still want to have a retry in mom once it >> starts responding due to delayed vdsm async recovery taking potentially >> minutes > > We handle this already. The only issue is the connection refused state. then why don’t you handle the connection state as well? isn’t that a simple fix? > > > Martin > > > On Fri, Nov 18, 2016 at 12:19 PM, Michal Skrivanek > <michal.skrivanek(a)redhat.com> wrote: >> >> On 18 Nov 2016, at 12:12, Oved Ourfali <oourfali(a)redhat.com> wrote: >> >> I don't think it is related to version X or Y. It is a race, so might be >> related to other factors. >> >> >> likely because json-rpc is initialized after xml-rpc….or indeed whatever >> else;-) >> >> either way it needs to be solved. Either by improving the systemd service >> file or mom retry (btw you likely still want to have a retry in mom once it >> starts responding due to delayed vdsm async recovery taking potentially >> minutes) >> >> >> On Nov 18, 2016 12:59 PM, "Martin Sivak" <msivak(a)redhat.com> wrote: >>> >>>> Are we / can we use systemd socket activation there? >>> >>> That actually requires systemd specific code iirc (to take over the >>> standing by socket). I am actually wondering why the xml-rpc in 4.0.4 >>> was fine and json-rpc in 4.0.6 is too slow. >>> >>> Martin >>> >>> On Fri, Nov 18, 2016 at 11:53 AM, Anton Marchukov <amarchuk(a)redhat.com> >>> wrote: >>>> Hello All. >>>> >>>> Are we / can we use systemd socket activation there? >>>> >>>> Anton. >>>> >>>> On Fri, Nov 18, 2016 at 11:21 AM, Martin Sivak <msivak(a)redhat.com> >>>> wrote: >>>>> >>>>> What about making vdsm ready to answer connections when it returns to >>>>> systemd instead? I hate workarounds and this always worked fine. >>>>> >>>>> Martin >>>>> >>>>> On Fri, Nov 18, 2016 at 11:13 AM, Oved Ourfali <oourfali(a)redhat.com> >>>>> wrote: >>>>>> Seems like a race regardless of the protocol. >>>>>> Should you add a retry? >>>>>> >>>>>> >>>>>> On Nov 18, 2016 11:52 AM, "Martin Sivak" <msivak(a)redhat.com> wrote: >>>>>>> >>>>>>> Yes, because VDSM is supposed to be up (there is systemd >>>>>>> dependency). >>>>>>> This always worked fine with xml-rpc. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On Fri, Nov 18, 2016 at 10:14 AM, Nir Soffer <nsoffer(a)redhat.com> >>>>>>> wrote: >>>>>>>> On Fri, Nov 18, 2016 at 10:45 AM, Martin Sivak <msivak(a)redhat.com> >>>>>>>> wrote: >>>>>>>>> This happens because MOM can't connect to VDSM and so it quits. >>>>>>>> >>>>>>>> So mom try once to connect and if the connection fails it quits? >>>>>>>> >>>>>>>>> We >>>>>>>>> discussed it on the mailinglist >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://lists.fedoraproject.org/archives/list/vdsm-devel@lists.fedorahosted… >>>>>>>>> http://lists.ovirt.org/pipermail/devel/2016-November/014101.html >>>>>>>>> >>>>>>>>> This issue never happened with XML-RPC. >>>>>>>>> >>>>>>>>> Shira reported it as >>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1393012 >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> On Thu, Nov 17, 2016 at 7:42 PM, Yaniv Kaul <ykaul(a)redhat.com> >>>>>>>>> wrote: >>>>>>>>>> I've recently seen, including now on Master, the following >>>>>>>>>> warnings: >>>>>>>>>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: >>>>>>>>>> Started >>>>>>>>>> MOM >>>>>>>>>> instance configured for VDSM purposes. >>>>>>>>>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: >>>>>>>>>> Starting >>>>>>>>>> MOM >>>>>>>>>> instance configured for VDSM purposes... >>>>>>>>>> Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, Policy could not be set. >>>>>>>>>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Any ideas what this is and why? >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Devel mailing list >>>>>>>>>> Devel(a)ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>>>> _______________________________________________ >>>>>>>>> Devel mailing list >>>>>>>>> Devel(a)ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> Devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Devel mailing list >>>>> Devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>>> >>>> >>>> >>>> -- >>>> Anton Marchukov >>>> Senior Software Engineer - RHEV CI - Red Hat >>>> >> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> >>

2 1

Where's MOM (on latest master)
by Yaniv Kaul 18 Nov '16

18 Nov '16

I've recently seen, including now on Master, the following warnings: Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Started MOM instance configured for VDSM purposes. Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Starting MOM instance configured for VDSM purposes... Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, Policy could not be set. Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Any ideas what this is and why?

7 15

Introduce new package decencies in vdsm
by Yaniv Bronheim 17 Nov '16

17 Nov '16

Hi After merging https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:c… we need now for any new requirement to add a line in: check-patch.packages.el7 check-patch.packages.fc24 check-merged.packages.el7 check-merged.packages.fc24 vdsm.spec.in Dockerfile.centos Dockerfile.fedora seems like we can add it once to the spec with section for fedora and centos and the rest of the places will use yum-builddep. sounds more reasonable to me and probably the right way to work with rpms dependencies. no? *Yaniv Bronhaim.*

4 4

oVirt Neutron External Provider
by Than Maung 17 Nov '16

17 Nov '16

All, Is there a guide for getting oVirt 4.0.4 going with networks created in Neutron? We are having problems with VMs not getting DHCP at all but they are showing up in the OpenStack Dashboard interface under Ports with the correct MAC IDs and the IP that the DHCP agent had assigned them. I'm using OpenStack Newton version and the controller is working all properly. We are trying to follow these two guides in trying to get virtual networks to work but experiencing problems. http://docs.openstack.org/newton/install-guide-rdo/neutron.html http://captainkvm.com/2016/09/integrating-rhv-openstack-neutron/ Sincerely, -- Than H. Maung, CISSP tmaung(a)techintsolutions.com (571) 295-8462

3 2

Vdsm build failure
by Piotr Kliczewski 17 Nov '16

17 Nov '16

All, I see a build failure [1] due to: 13:34:32 FAIL: test_from_invalid_to_valid_domain('selftest', <type 'exceptions.OSError'>) (storage_monitor_test.TestMonitorThreadMonitoring) 13:34:32 ---------------------------------------------------------------------- 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 133, in wrapper 13:34:32 return f(self, *args) 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_monitor_test.py", line 470, in test_from_invalid_to_valid_domain 13:34:32 self.assertTrue(status.valid) 13:34:32 AssertionError: False is not true 13:34:32 -------------------- >> begin captured logging << -------------------- 13:34:32 2016-11-14 13:33:04,968 DEBUG (monitor/uuid) [storage.Monitor] Domain monitor for uuid started (monitor:304) 13:34:32 2016-11-14 13:33:04,968 DEBUG (monitor/uuid) [storage.Monitor] Producing domain uuid (monitor:366) 13:34:32 2016-11-14 13:33:04,969 INFO (monitor/uuid) [test] Start checking '/path/to/metadata' (storage_monitor_test:73) 13:34:32 2016-11-14 13:33:04,969 DEBUG (monitor/uuid) [test] Checking if iso domain (storage_monitor_test:156) 13:34:32 2016-11-14 13:33:04,969 ERROR (monitor/uuid) [storage.Monitor] Error checking domain uuid (monitor:426) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 407, in _checkDomainStatus 13:34:32 self.domain.selftest() 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 616, in wrapper 13:34:32 raise exception 13:34:32 OSError 13:34:32 2016-11-14 13:33:04,969 INFO (monitor/uuid) [storage.Monitor] Domain uuid became INVALID (monitor:456) 13:34:32 2016-11-14 13:33:04,969 DEBUG (monitor/uuid) [test] Emitting event (args=('uuid', False), kwrags={}) (storage_monitor_test:57) 13:34:32 2016-11-14 13:33:05,170 ERROR (monitor/uuid) [storage.Monitor] Error checking domain uuid (monitor:426) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 407, in _checkDomainStatus 13:34:32 self.domain.selftest() 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 616, in wrapper 13:34:32 raise exception 13:34:32 OSError 13:34:32 2016-11-14 13:33:05,371 ERROR (monitor/uuid) [storage.Monitor] Error checking domain uuid (monitor:426) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 407, in _checkDomainStatus 13:34:32 self.domain.selftest() 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 616, in wrapper 13:34:32 raise exception 13:34:32 OSError 13:34:32 2016-11-14 13:33:05,461 DEBUG (monitor/uuid) [storage.Monitor] Domain monitor for uuid canceled (monitor:309) 13:34:32 2016-11-14 13:33:05,461 DEBUG (monitor/uuid) [storage.Monitor] Domain monitor for uuid stopped (shutdown=False) (monitor:312) 13:34:32 2016-11-14 13:33:05,461 INFO (monitor/uuid) [test] Stop checking '/path/to/metadata' (storage_monitor_test:79) 13:34:32 2016-11-14 13:33:05,461 DEBUG (monitor/uuid) [test] Releasing host id (hostId=host_id, unused=True) (storage_monitor_test:143) 13:34:32 2016-11-14 13:33:05,461 ERROR (monitor/uuid) [storage.Monitor] Error releasing host id host_id for domain uuid (monitor:568) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 565, in _releaseHostId 13:34:32 self.domain.releaseHostId(self.hostId, unused=True) 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_monitor_test.py", line 146, in releaseHostId 13:34:32 assert self.acquired, "Attempt to release unacquired host id" 13:34:32 AssertionError: Attempt to release unacquired host id Can someone please take a look? Thanks, Piotr [1] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/4123/conso…

1 1

oVirt 4.0.6 RC1 build planned
by Rafael Martins 16 Nov '16

16 Nov '16

Fyi oVirt developers, An oVirt build is planned for this Wednesday 10:00 AM TLV time (9:00 AM CET). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Tuesday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Wednesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… Rafael

3 2

[VDSM] Failing make check
by Adam Litke 16 Nov '16

16 Nov '16

Hi Piotr, I am now seeing consistent Jenkins failures during make check (when producing the schema html doc) and I suspect this[1] change. Can you take a look please? [1] https://gerrit.ovirt.org/#/c/56387/ -- Adam Litke

2 1