January 2018 - Users - oVirt List Archives

Storage Hardware for Hyperconverged oVirt: Gluster best practice
by ovirt＠fateknollogee.com 26 Jan '18

26 Jan '18

oVirt + Gluster (hyperconverged) RAID question: I have 3 nodes of SuperMicro hardware, each node has 1x SATADOM (boot drive for o/s install) and 6x 1TB SSD (to be used for Gluster). For the SSDs, is hardware or software RAID preferred or do I use an HBA? The RedHat docs seem to suggest hardware RAID, others on the forum say HBA or software RAID. What are other folks using?

4 6

live migrating vm from 4.1.7 to 4.1.9 failed because of vmx flag
by Gianluca Cecchi 26 Jan '18

26 Jan '18

Hello, I'm trying to update an environment from 4.1.7 to 4.1.9. Already migrated the engine (separate) and one host. This host is now running a pair of VMs, that was powered off and then powered on it via "run once" feature. Now I'm trying to evacuate VMs from other hosts and get all to 4.1.9. But I have tried with couple of VMs and I'm always getting error events of type: Jan 26, 2018 12:40:00 PM Migration failed (VM: dbatest3, Source: ov301, Destination: ov200). In engine.log 2018-01-26 12:39:48,267+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (default task-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] Lock Acquired to object 'EngineLock:{exclusiveLocks='[4f6ecae2-7d71-47c9-af23-2b3e49bc08fc=VM]', sharedLocks=''}' 2018-01-26 12:39:48,350+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] Running command: MigrateVmToServerCommand internal: false. Entities affected : ID: 4f6ecae2-7d71-47c9-af23-2b3e49bc08fc Type: VMAction group MIGRATE_VM with role type USER 2018-01-26 12:39:48,424+01 INFO [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] START, MigrateVDSCommand( MigrateVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', srcHost='ov301.mydomain', dstVdsId='d16e723c-b44c-4c1c-be76-c67911e47ccd', dstHost='ov200.mydomain:54321', migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0', autoConverge='true', migrateCompressed='false', consoleAddress='null', maxBandwidth='500', enableGuestEvents='true', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDowntime, params=[100]}], stalling=[{limit=1, action={name=setDowntime, params=[150]}}, {limit=2, action={name=setDowntime, params=[200]}}, {limit=3, action={name=setDowntime, params=[300]}}, {limit=4, action={name=setDowntime, params=[400]}}, {limit=6, action={name=setDowntime, params=[500]}}, {limit=-1, action={name=abort, params=[]}}]]'}), log id: 7013a234 2018-01-26 12:39:48,425+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] START, MigrateBrokerVDSCommand(HostName = ov301, MigrateVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', srcHost='ov301.mydomain', dstVdsId='d16e723c-b44c-4c1c-be76-c67911e47ccd', dstHost='ov200.mydomain:54321', migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0', autoConverge='true', migrateCompressed='false', consoleAddress='null', maxBandwidth='500', enableGuestEvents='true', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDowntime, params=[100]}], stalling=[{limit=1, action={name=setDowntime, params=[150]}}, {limit=2, action={name=setDowntime, params=[200]}}, {limit=3, action={name=setDowntime, params=[300]}}, {limit=4, action={name=setDowntime, params=[400]}}, {limit=6, action={name=setDowntime, params=[500]}}, {limit=-1, action={name=abort, params=[]}}]]'}), log id: 25d9c017 2018-01-26 12:39:49,620+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] FINISH, MigrateBrokerVDSCommand, log id: 25d9c017 2018-01-26 12:39:49,622+01 INFO [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] FINISH, MigrateVDSCommand, return: MigratingFrom, log id: 7013a234 2018-01-26 12:39:49,627+01 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] EVENT_ID: VM_MIGRATION_START(62), Correlation ID: 72ccfbb1-735a-4411-a990-cdb2c081e391, Job ID: b2f39d2c-87f1-480c-b4c7-b8ab09d09318, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Migration started (VM: dbatest3, Source: ov301, Destination: ov200, User: admin@internal-authz). 2018-01-26 12:39:50,782+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmsStatisticsFetcher] (DefaultQuartzScheduler1) [f2fc61e] Fetched 3 VMs from VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd' 2018-01-26 12:39:50,783+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler1) [f2fc61e] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) was unexpectedly detected as 'MigratingTo' on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) (expected on '8ef1ce6f-4e38-486c-b3a4-58235f1f1d06') 2018-01-26 12:39:50,784+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler1) [f2fc61e] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' is migrating to VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) ignoring it in the refresh until migration is done 2018-01-26 12:39:51,968+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-15) [] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' was reported as Down on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) 2018-01-26 12:39:51,969+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] START, DestroyVDSCommand(HostName = ov200, DestroyVmVDSCommandParameters:{runAsync='true', hostId='d16e723c-b44c-4c1c-be76-c67911e47ccd', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', force='false', secondsToWait='0', gracefully='false', reason='', ignoreNoVm='true'}), log id: 3b49afe3 2018-01-26 12:39:52,236+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] Failed to destroy VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' because VM does not exist, ignoring 2018-01-26 12:39:52,237+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] FINISH, DestroyVDSCommand, log id: 3b49afe3 2018-01-26 12:39:52,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-15) [] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) was unexpectedly detected as 'Down' on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) (expected on '8ef1ce6f-4e38-486c-b3a4-58235f1f1d06') 2018-01-26 12:40:00,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler3) [5c4b079b] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) moved from 'MigratingFrom' --> 'Up' 2018-01-26 12:40:00,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler3) [5c4b079b] Adding VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) to re-run list 2018-01-26 12:40:00,245+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] (DefaultQuartzScheduler3) [5c4b079b] Rerun VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'. Called from VDS 'ov301' 2018-01-26 12:40:00,287+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] START, MigrateStatusVDSCommand(HostName = ov301, MigrateStatusVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'}), log id: 65677081 2018-01-26 12:40:00,818+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] FINISH, MigrateStatusVDSCommand, log id: 65677081 2018-01-26 12:40:00,823+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] EVENT_ID: VM_MIGRATION_TO_SERVER_FAILED(120), Correlation ID: 72ccfbb1-735a-4411-a990-cdb2c081e391, Job ID: b2f39d2c-87f1-480c-b4c7-b8ab09d09318, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Migration failed (VM: dbatest3, Source: ov301, Destination: ov200). 2018-01-26 12:40:00,825+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] Lock freed to object 'EngineLock:{exclusiveLocks='[4f6ecae2-7d71-47c9-af23-2b3e49bc08fc=VM]', sharedLocks=''}' 2018-01-26 12:40:05,796+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmsStatisticsFetcher] (DefaultQuartzScheduler1) [27a52eca] Fetched 2 VMs from VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd' I don't see errors in vdsm logs of target host, but I do see this in /var/log/messages of target host Jan 26 12:39:51 ov200 libvirtd: 2018-01-26 11:39:51.179+0000: 2588: error : virCPUx86UpdateLive:2726 : operation failed: guest CPU doesn't match specification: missing features: vmx Indeed dbatest3 VM has this "vmx=on" flag in qemu-kvm command line on source host, even if I never configured it explicitly...: [root@ov301 ~]# ps -ef|grep dbatest3 qemu 1455 1 1 2017 ? 08:41:29 /usr/libexec/qemu-kvm -name guest=dbatest3,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-dbatest3/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere,vmx=on -m 32768 ... A quite similar VM named dbatest4 running on the already upgraded host doesn't have indeed the flag: [root@ov200 vdsm]# ps -ef|grep dbatest4 qemu 15827 1 3 10:47 ? 00:04:37 /usr/libexec/qemu-kvm -name guest=dbatest4,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-dbatest4/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere -m 32768 The 2 VMs has been created from the same template and with the same options if I remember correctly and across the previous versions I could live migrate without problems.... What can have changed? This would be a possible great show stopper, because one has to power off all the VMs if he/she wants to upgrade..... Thanks in advance for any help, Gianluca

1 2

bonding mode-alb
by Demeter Tibor 26 Jan '18

26 Jan '18

--=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear members, I would like to use two switches for make high-availability network connection for my nfs storge. Unfortunately, these switches does not support 802.3.ad lacp, (really I can't stack them) but I've read about mode-alb and mode-tlb bonding modes. I know,these modes are available in ovirt, but how is work that? Also how is safe? Are there for HA or for load balance? I've read some forums, where does not recommended these modes to use in ovirt. What is the truths? I would like to use only for storage-traffic, it will be separated from other network traffic. I have two 10Gbe switches and two 10Gbe ports in my nodes. Thanks in advance, R Tibor --=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>Dear members,</div><div><br data-mce-bogus= =3D"1"></div><div>I would like to use two switches for make high-availabili= ty network connection for my nfs storge.</div><div>Unfortunately, these swi= tches does not support 802.3.ad lacp, (really I can't stack them)  but= I've read about mode-alb and mode-tlb bonding modes.  <br>I know= ,these modes are available in ovirt, but how is work that? Also how is safe= ? Are there for HA or for load balance? </div><div><br data-mce-bogus= =3D"1"></div><div>I've read some forums, where does not recommended these m= odes to use in ovirt. What is the truths? </div><div>I would like to u= se only for storage-traffic, it will be separated from other network traffi= c. I have two 10Gbe switches and two 10Gbe ports in my nodes. </div><d= iv><br data-mce-bogus=3D"1"></div><div>Thanks in advance, </div><div><= br data-mce-bogus=3D"1"></div><div>R</div><div><br data-mce-bogus=3D"1"></d= iv><div>Tibor</div><div> </div><div><br></div><div data-marker=3D"__SI= G_PRE__"><p style=3D"font-family: 'Times New Roman'; font-size: medium; mar= gin: 0px;"><strong><span style=3D"font-size: medium;"><span style=3D"color:= rgb(45, 103, 176);"></span></span></strong></p><p></p></div></div></body><= /html> --=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2--

5 9

Re: [ovirt-users] oVirt 4.1.9 and Spectre-Meltdown checks
by Arman Khalatyan 26 Jan '18

26 Jan '18

you should download microcode from the intel web page and overwrite the /lib/firmware/intel-ucode or so...please check the readme. Am 26.01.2018 10:50 vorm. schrieb "Gianluca Cecchi" < gianluca.cecchi(a)gmail.com>: Hello, nice to see integration of Spectre-Meltdown info in 4.1.9, both for guests and hosts, as detailed in release notes: I have upgraded my CentOS 7.4 engine VM (outside of oVirt cluster) and one oVirt host to 4.1.9. Now in General -> Software subtab of the host I see: OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: CentOS Linux 7 (Core) Kernel Version: 3.10.0 - 693.17.1.el7.x86_64 Kernel Features: IBRS: 0, PTI: 1, IBPB: 0 Am I supposed to manually set any particular value? If I run version 0.32 (updated yesterday) of spectre-meltdown-checker.sh I got this on my Dell M610 blade with Version: 6.4.0 Release Date: 07/18/2013 [root@ov200 ~]# /home/g.cecchi/spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 CPU is Intel(R) Xeon(R) CPU X5690 @ 3.47GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: YES > STATUS: NOT VULNERABLE (107 opcodes found, which is >= 70, heuristic to be improved when official patches become available) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: YES * Currently enabled features * IBRS enabled for Kernel space: NO (echo 1 > /sys/kernel/debug/x86/ibrs_enabled) * IBRS enabled for User space: NO (echo 2 > /sys/kernel/debug/x86/ibrs_enabled) * IBPB enabled: NO (echo 1 > /sys/kernel/debug/x86/ibpb_enabled) * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO * Retpoline enabled: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) A false sense of security is worse than no security at all, see --disclaimer [root@ov200 ~]# So it seems I'm still vulnerable only to Variant 2, but kernel seems ok: * Kernel is compiled with IBRS/IBPB support: YES while bios not, correct? Is RH EL / CentOS expected to follow the retpoline option too, to mitigate Variant 2, as done by Fedora for example? Eg on my just updated Fedora 27 laptop I get now: [g.cecchi@ope46 spectre_meltdown]$ sudo ./spectre-meltdown-checker.sh [sudo] password for g.cecchi: Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 x86_64 CPU is Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) > STATUS: VULNERABLE (Vulnerable) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: NO * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Retpoline enabled: YES > STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) A false sense of security is worse than no security at all, see --disclaimer [g.cecchi@ope46 spectre_meltdown]$ BTW: I updated some days ago this laptop from F26 to F27 and I remember Variant 1 was fixed in F26, while now I see it as vulnerable..... I'm going to check with Fedora mailing list about this... Another question: what should I see for a VM instead related to meltdown/spectre? Currently in "Guest CPU Type" in General subtab of the VM I only see "Westmere".. Should I also see anythin aout IBRS, etc...? Thanks, Gianluca _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

Ovirt 4.2, failing to connect to VDSM.
by CRiMSON 25 Jan '18

25 Jan '18

I did a quick upgrade this afternoon on a dev machine. Jan 25 11:57:07 Updated: glusterfs-libs-3.12.5-2.el7.x86_64 Jan 25 11:57:08 Updated: glusterfs-client-xlators-3.12.5-2.el7.x86_64 Jan 25 11:57:08 Updated: glusterfs-3.12.5-2.el7.x86_64 Jan 25 11:57:09 Updated: kernel-ml-tools-libs-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:09 Updated: kernel-ml-tools-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:10 Updated: glusterfs-api-3.12.5-2.el7.x86_64 Jan 25 11:57:10 Updated: glusterfs-fuse-3.12.5-2.el7.x86_64 Jan 25 11:57:10 Updated: glusterfs-cli-3.12.5-2.el7.x86_64 Jan 25 11:57:11 Updated: python-perf-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:37 Installed: kernel-ml-devel-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:39 Updated: kernel-ml-headers-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:52 Installed: kernel-ml-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:52 Updated: rubygem-fluent-plugin-viaq_data_model-0.0.13-1.el7.noarch This is all that was upgraded. But now my storage domains are failing to come up and the host keeps saying it's getting a connection refused. It's all on 1 host. In mom.log I see. 2018-01-25 17:10:49,929 - mom - INFO - MOM starting 2018-01-25 17:10:49,955 - mom.HostMonitor - INFO - Host Monitor starting 2018-01-25 17:10:49,955 - mom - INFO - hypervisor interface vdsmjsonrpcbulk 2018-01-25 17:10:50,013 - mom.vdsmInterface - ERROR - Cannot connect to VDSM! [Errno 111] Connection refused 2018-01-25 17:10:50,013 - mom - ERROR - Failed to initialize MOM threads Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run hypervisor_iface = self.get_hypervisor_interface() File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, in get_hypervisor_interface return module.instance(self.config) File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", line 47, in instance return JsonRpcVdsmBulkInterface() File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", line 29, in __init__ super(JsonRpcVdsmBulkInterface, self).__init__() File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcInterface.py", line 43, in __init__ .orRaise(RuntimeError, 'No connection to VDSM.') File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in orRaise raise exception(*args, **kwargs) RuntimeError: No connection to VDSM. [root@lv426 vdsm]# My vdsm.log is 0 byes (nothing being logged?) In my engine.log I'm seeing: 2018-01-25 17:12:11,027-05 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to lv426.dasgeekhaus.org/127.0.0.1 2018-01-25 17:12:11,028-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-99) [] Command 'GetCapabilitiesVDSCommand(HostName = lv426, VdsIdAndVdsVDSCommandParametersBase:{hostId='a645af84-3da1-45ed-bab5-2af66b5924dd', vds='Host[lv426,a645af84-3da1-45ed-bab5-2af66b5924dd]'})' execution failed: java.net.ConnectException: Connection refused 2018-01-25 17:12:11,028-05 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-99) [] Failure to refresh host 'lv426' runtime info: java.net.ConnectException: Connection refused 2018-01-25 17:12:13,517-05 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to lv426.dasgeekhaus.org/127.0.0.1 2018-01-25 17:12:13,517-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] Command 'GetAllVmStatsVDSCommand(HostName = lv426, VdsIdVDSCommandParametersBase:{hostId='a645af84-3da1-45ed-bab5-2af66b5924dd'})' execution failed: java.net.ConnectException: Connection refused 2018-01-25 17:12:13,518-05 INFO [org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] Failed to fetch vms info for host 'lv426' - skipping VMs monitoring. All of my network interfaces do come up ok, iptables is turned off so it's not getting in the way. I'm at a complete loss right now as to what to look at.

1 1

Imageio-Proxy: Failed to verify proxy ticket: Ticket life time expired
by Gabriel Stein 25 Jan '18

25 Jan '18

Hi, oVirt Version: 4.2 Imageio-Proxy: ovirt-imageio-proxy-1.0.0-0 vdsm: vdsm-4.20.9.3-1 I can't upload disks with more than 200GB to oVirt(using UI). Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1538814 I would appreciate any help. Thank you Best Regards Gabriel

1 0

Ovirt 4.2 - Help adding VM to numa node via python SDK
by Don Dupuis 25 Jan '18

25 Jan '18

I am able to create a vm using the sdk with nic and disks using the python sdk, but having trouble understanding how to assign it to virtual numanode onto the physical numanode via python sdk. Any help in this area would be greatly appreciated Thanks Don

2 2

[ANN] oVirt 4.2.1 Third Release Candidate is now available
by Lev Veyde 25 Jan '18

25 Jan '18

The oVirt Project is pleased to announce the availability of the oVirt 4.2.1 Third Release Candidate, as of January 25th, 2017 This update is a release candidate of the first in a series of stabilization updates to the 4.2 series. This is pre-release software. This pre-release should not to be used in production. This release is available now for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node will be available soon [2] Additional Resources: * Read more about the oVirt 4.2.1 release highlights: http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.1/>2 <http://www.ovirt.org/release/4.2.1/>. <http://www.ovirt.org/release/4.2.1/> 1 <http://www.ovirt.org/release/4.2.1/>/ <http://www.ovirt.org/release/4.2.1/> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.1/>2 <http://www.ovirt.org/release/4.2.1/>. <http://www.ovirt.org/release/4.2.1/> 1 <http://www.ovirt.org/release/4.2.1/>/ <http://www.ovirt.org/release/4.2.1/> [2] http://resources.ovirt.org/pub/ovirt-4. <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/>2-pre <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/>/iso/ <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/> -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

4.2 Cloud-init & VM Portal question
by Vrgotic, Marko 25 Jan '18

25 Jan '18

--_000_17440597BD9049178A1771E526A26F32activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydCwNCg0KSSBoYXZlIGNyZWF0ZWQgYSB0ZW1wbGF0ZSB3aGljaCBpbmNsdWRlcyAg Y2xvdWQtaW5pdCB3aXRoIHVzZXIgLyB0aW1lem9uZSAvIHNzaCBrZXkgLyBuZXR3b3JrIGRlZmlu ZWQuIEludGVudGlvbiBpcyB0byBhbGxvdyByZWd1bGFyIHVzZXJzICYgVk0gUG9ydGFsIHRvIGNy ZWF0ZSBWTXMgdXNpbmcgdGhpcyB0ZW1wbGF0ZS4NCg0KUXVlc3Rpb24gdGhhdCBJIGhhdmUgaXM7 IGlmIHBvc3NpYmxlLCBob3cgY2FuIEkgYXJyYW5nZSB0aGF0IHZtIG5hbWUgSSBmaWxsIGluLCBp cyBwYXNzZWQgdG8gY2xvdWQtaW5pdCBhcyB2bSBob3N0bmFtZSAoYXMgaXQgaXMgZGVmYXVsdCB3 aGVuIGNyZWF0aW5nIFZNIGZyb20gQWRtaW4gUG9ydGFsKT8gSXMgaXQgZXZlbiBwb3NzaWJsZSBh bmQgcGxlYXNlIGlmIHNvLCBwcm92aWRlIHNvbWUgZ3VpZGFuY2UuDQoNCi0tDQpNZXQgdnJpZW5k ZWxpamtlIGdyb2V0IC8gQmVzdCByZWdhcmRzLA0KTWFya28gVnJnb3RpYw0KU3lzdGVtIEVuZ2lu ZWVyL0N1c3RvbWVyIENhcmUNCkFjdGl2ZVZpZGVvDQoNCg== --_000_17440597BD9049178A1771E526A26F32activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2B53B85BE18C0E4DB54AB4EAF1D1E03D(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgb1Zp cnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgY3Jl YXRlZCBhIHRlbXBsYXRlIHdoaWNoIGluY2x1ZGVzICZuYnNwO2Nsb3VkLWluaXQgd2l0aCB1c2Vy IC8gdGltZXpvbmUgLyBzc2gga2V5IC8gbmV0d29yayBkZWZpbmVkLiBJbnRlbnRpb24gaXMgdG8g YWxsb3cgcmVndWxhciB1c2VycyAmYW1wOyBWTSBQb3J0YWwgdG8gY3JlYXRlIFZNcyB1c2luZyB0 aGlzIHRlbXBsYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ UXVlc3Rpb24gdGhhdCBJIGhhdmUgaXM7IGlmIHBvc3NpYmxlLCBob3cgY2FuIEkgYXJyYW5nZSB0 aGF0IHZtIG5hbWUgSSBmaWxsIGluLCBpcyBwYXNzZWQgdG8gY2xvdWQtaW5pdCBhcyB2bSBob3N0 bmFtZSAoYXMgaXQgaXMgZGVmYXVsdCB3aGVuIGNyZWF0aW5nIFZNIGZyb20gQWRtaW4gUG9ydGFs KT8gSXMgaXQgZXZlbiBwb3NzaWJsZSBhbmQgcGxlYXNlDQogaWYgc28sIHByb3ZpZGUgc29tZSBn dWlkYW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tR0IiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0Ii Pk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPk1hcmtvIFZyZ290aWM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+U3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENhcmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+QWN0aXZlVmlkZW88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_17440597BD9049178A1771E526A26F32activevideocom_--

3 3

what does the metadata param "LEGALITY", "VOLTYPE" and "GEN" means?
by pengyixiang 24 Jan '18

24 Jan '18

------=_Part_119963_1780357530.1516780114893 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGVsbG8sIGV2ZXJ5b25lIQogICAgVGhlcmUncyBhIGxpc3Qgc3RvcmFnZSBtZXRhZGF0YSBmb3Jt YXQgaW4gWzFdLCAgd2hhdCBkb2VzIHRoZSAiRkFLRSIgLCAiSU5URVJOQUx8U0hBUkVEfExFQUYi LCAiR0VOIiBtZWFucyBpbiBvdmlydD8gSG93IGRpZCB0aGVzZSB1c2VkPwoKCgoKCgpbMV0KIyBI ZXJlIGlzIHRoZSB3b3JzdCBjYXNlIG1ldGFkYXRhIGZvcm1hdDoKIwojIENUSU1FPTE0NDA5MzUw MzggICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBpbnQodGltZS50aW1lKCkpCiMgREVTQ1JJ UFRJT049ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHRleHR8SlNPTgojIERJU0tU WVBFPTIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBlbnVtCiMgRE9NQUlOPTc1 ZjhhMWJiLTQ1MDQtNDMxNC05MWNhLWQ5MzY1YTMwNjkyYiAjIHV1aWQKIyBGT1JNQVQ9Q09XICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgUkFXfENPVwojIElNQUdFPTc1ZjhhMWJi LTQ1MDQtNDMxNC05MWNhLWQ5MzY1YTMwNjkyYiAgIyB1dWlkCiMgTEVHQUxJVFk9SUxMRUdBTCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAjIElMTEVHQUx8TEVHQUx8RkFLRQojIE1USU1FPTAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBhbHdheXMgMAojIFBPT0xfVVVJ RD0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBhbHdheXMgZW1wdHkKIyBQVVVJ RD03NWY4YTFiYi00NTA0LTQzMTQtOTFjYS1kOTM2NWEzMDY5MmIgICMgdXVpZAojIFNJWkU9MjE0 NzQ4MzY0OCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBzaXplIGluIGJsb2NrcwojIFRZ UEU9UFJFQUxMT0NBVEVEICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBQUkVBTExPQ0FURUR8 VU5LTk9XTnxTUEFSU0UKIyBWT0xUWVBFPUlOVEVSTkFMICAgICAgICAgICAgICAgICAgICAgICAg ICAgICMgSU5URVJOQUx8U0hBUkVEfExFQUYKIyBHRU49OTk5ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICMgaW50CiMgRU9G ------=_Part_119963_1780357530.1516780114893 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+aGVsbG8sIGV2ZXJ5b25lITwvZGl2PjxkaXY+Jm5ic3A7 ICZuYnNwOyBUaGVyZSdzIGEgbGlzdCBzdG9yYWdlIG1ldGFkYXRhIGZvcm1hdCBpbiBbMV0sJm5i c3A7IHdoYXQgZG9lcyB0aGUgIjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgp OyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiAmcXVvdDtEZWphVnUgU2FucyBNb25v JnF1b3Q7OyBmb250LXNpemU6IDExLjNwdDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+RkFLRTwv c3Bhbj4iICwgIjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgpOyBmb250LXN0 eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiAmcXVvdDtEZWphVnUgU2FucyBNb25vJnF1b3Q7OyBm b250LXNpemU6IDExLjNwdDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+SU5URVJOQUx8U0hBUkVE fExFQUY8L3NwYW4+IiwgIjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgpOyBm b250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiAmcXVvdDtEZWphVnUgU2FucyBNb25vJnF1 b3Q7OyBmb250LXNpemU6IDExLjNwdDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+R0VOPC9zcGFu PiIgbWVhbnMgaW4gb3ZpcnQ/IEhvdyBkaWQgdGhlc2UgdXNlZD88L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlsxXTwvZGl2PjxkaXY+PHByZSBz dHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0RlamFWdSBTYW5zIE1vbm8mcXVvdDs7IGZvbnQtc2l6 ZTogMTEuM3B0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7 Ij4jIEhlcmUgaXMgdGhlIHdvcnN0IGNhc2UgbWV0YWRhdGEgZm9ybWF0Ojxicj48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4jPGJyPjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgQ1RJTUU9MTQ0 MDkzNTAzOCAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGludCh0aW1lLnRpbWUoKSk8YnI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBE RVNDUklQVElPTj0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgdGV4dHxKU09OPGJy Pjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMg RElTS1RZUEU9MiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGVudW08YnI+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBET01B SU49NzVmOGExYmItNDUwNC00MzE0LTkxY2EtZDkzNjVhMzA2OTJiICMgdXVpZDxicj48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4jIEZPUk1BVD1D T1cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBSQVd8Q09XPGJyPjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgSU1BR0U9NzVm OGExYmItNDUwNC00MzE0LTkxY2EtZDkzNjVhMzA2OTJiICAjIHV1aWQ8YnI+PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBMRUdBTElUWT1JTExF R0FMICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgSUxMRUdBTHxMRUdBTHxGQUtFPGJyPjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgTVRJ TUU9MCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGFsd2F5cyAwPGJyPjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgUE9P TF9VVUlEPSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGFsd2F5cyBlbXB0eTxi cj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4j IFBVVUlEPTc1ZjhhMWJiLTQ1MDQtNDMxNC05MWNhLWQ5MzY1YTMwNjkyYiAgIyB1dWlkPGJyPjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgU0la RT0yMTQ3NDgzNjQ4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHNpemUgaW4gYmxvY2tz PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsi PiMgVFlQRT1QUkVBTExPQ0FURUQgICAgICAgICAgICAgICAgICAgICAgICAgICAjIFBSRUFMTE9D QVRFRHxVTktOT1dOfFNQQVJTRTxicj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7 Zm9udC1zdHlsZTppdGFsaWM7Ij4jIFZPTFRZUEU9SU5URVJOQUwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIyBJTlRFUk5BTHxTSEFSRUR8TEVBRjxicj48L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4jIEdFTj05OTkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIyBpbnQ8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBFT0Y8L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+ PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_119963_1780357530.1516780114893--

1 0