- Users - oVirt List Archives

Info on manual operations after removing FC storage domain
by Gianluca Cecchi 11 Oct '17

11 Oct '17

Hello, I'm relocating some disks from some storage domains to other ones. At the end I'm going to remove source storage domains. All the SD involved are FC and the hosts are CentOS 7.4 I see that after removing an SD from oVirt, the multipath part on host remains. What is the correct sequence of operations to do at hosts' side after completing the Webadmin Gui part? Some questions: - do the remove SD from gui imply vgchange -an of the VG and vgremove of the vg? Or are they delegated to post actions? - do it imply the pvremove on the LUN? After clearing what above I would imagine remaining steps would be, based on my previous similar experience with iSCSI removal on physical servers: - take note of the paths sdY, ... of mpathX - remove the multipath device with multipath -f mpathX - flush the single paths devices blockdev --flushbufs sdY for every path of the previous taken note ones - remove single path devices echo 1 > /sys/block/sdY/device/delete - remove LUN from storage array when previous steps done on all the hypervisors Any comment? Any further step at vdsm level files..? Thanks in advance, Gianluca

2 3

Maximum storage per VM?
by Dmitri Chebotarov 11 Oct '17

11 Oct '17

Hello I'm trying to find any info on how much storage I can attach to a VM. Is there a recommended/maximum for number of disks and maximum disk size? I'm using GlusterFS as backend storage for the cluster. The VM uses LVM (/w striped volumes) to manage attached disks. Thank you, -- Dmitri Chebotarov. George Mason University, 4400 University Drive, Fairfax, VA, 22030 GPG Public key# 5E19F14D: [https://goo.gl/SlE8tj]

3 5

VM Serial Port connection to network port
by Gagandeep Arora 11 Oct '17

11 Oct '17

Hi, Is it possible to configure a VM with a serial port connecting to network port in client mode? Can someone point me in the right direction on how to do this in ovirt. We are running ovirt-4.0.6.3-1.1. Regards, Gagan

1 0

Re: [ovirt-users] ovirt-engine-extension-aaa-ldap active directory
by Luca 'remix_tj' Lorenzetto 10 Oct '17

10 Oct '17

On Tue, Oct 10, 2017 at 4:41 PM, nicola gentile <nicola.gentile.to(a)gmail.com> wrote: > I run the command you suggest > ldapsearch -h domaincontroller.dom.it -b "dc=dom,dc=it" -D user(a)dom.it > -W -x sAMAccountName=user_to_search userPrincipalName | grep > userPrincipalName > > This is the result: > > Enter LDAP Password: > # requesting: userPrincipalName > Supposing you're using all the right parameters in ldapsearch command, it seems that the user you were looking up is not a valid user in that directory server. Please check with someone that can access to AD and verify the status of the user with ADSI Edit. Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenzetto.luca(a)gmail.com>

2 1

Re: [ovirt-users] ovirt-engine-extension-aaa-ldap active directory
by nicola gentile 10 Oct '17

10 Oct '17

yes is AD. Nick 2017-10-10 16:41 GMT+02:00 nicola gentile <nicola.gentile.to(a)gmail.com>: > I run the command you suggest > ldapsearch -h domaincontroller.dom.it -b "dc=dom,dc=it" -D user(a)dom.it > -W -x sAMAccountName=user_to_search userPrincipalName | grep > userPrincipalName > > This is the result: > > Enter LDAP Password: > # requesting: userPrincipalName > > Nick > > 2017-10-10 16:21 GMT+02:00 Luca 'remix_tj' Lorenzetto > <lorenzetto.luca(a)gmail.com>: >> On Tue, Oct 10, 2017 at 4:06 PM, nicola gentile >> <nicola.gentile.to(a)gmail.com> wrote: >>> include = <ad.properties> >>> >>> vars.domain = dom.it >>> vars.user = CN=myuser,OU=spuser,DC=dom,DC=it >>> vars.password = xxxxxxxxx >>> >>> pool.default.auth.simple.bindDN = ${global:vars.user} >>> pool.default.auth.simple.password = ${global:vars.password} >>> pool.default.serverset.type = srvrecord >>> pool.default.serverset.srvrecord.domain = ${global:vars.domain} >>> pool.default.ssl.startTLS = true >>> pool.default.ssl.truststore.file = ${local:_basedir}/polito.it.jks >>> pool.default.ssl.truststore.password = changeit >> >> It's an AD? >> >> Can you check if userPrincipalName of the user you're trying to use >> for connecting contains the login name in the format of >> user(a)domain.fqdn? >> >> I had issues with users that had userPrincipalName wrongly formatted. >> You should find nicola.gentile(a)polito.it on that field. >> >> You can check in this way: >> >> ldapsearch -h domaincontroller.dom.it -b "dc=dom,dc=it" -D user(a)dom.it >> -W -x sAMAccountName=user_to_search userPrincipalName | grep >> userPrincipalName >> >> >> Luca >> >> >> >> -- >> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare >> calcoli che potrebbero essere affidati a chiunque se si usassero delle >> macchine" >> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) >> >> "Internet è la più grande biblioteca del mondo. >> Ma il problema è che i libri sono tutti sparsi sul pavimento" >> John Allen Paulos, Matematico (1945-vivente) >> >> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenzetto.luca(a)gmail.com>

1 0

Re: [ovirt-users] ovirt-engine-extension-aaa-ldap active directory
by Luca 'remix_tj' Lorenzetto 10 Oct '17

10 Oct '17

On Tue, Oct 10, 2017 at 4:06 PM, nicola gentile <nicola.gentile.to(a)gmail.com> wrote: > include = <ad.properties> > > vars.domain = dom.it > vars.user = CN=myuser,OU=spuser,DC=dom,DC=it > vars.password = xxxxxxxxx > > pool.default.auth.simple.bindDN = ${global:vars.user} > pool.default.auth.simple.password = ${global:vars.password} > pool.default.serverset.type = srvrecord > pool.default.serverset.srvrecord.domain = ${global:vars.domain} > pool.default.ssl.startTLS = true > pool.default.ssl.truststore.file = ${local:_basedir}/polito.it.jks > pool.default.ssl.truststore.password = changeit It's an AD? Can you check if userPrincipalName of the user you're trying to use for connecting contains the login name in the format of user(a)domain.fqdn? I had issues with users that had userPrincipalName wrongly formatted. You should find nicola.gentile(a)polito.it on that field. You can check in this way: ldapsearch -h domaincontroller.dom.it -b "dc=dom,dc=it" -D user(a)dom.it -W -x sAMAccountName=user_to_search userPrincipalName | grep userPrincipalName Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenzetto.luca(a)gmail.com>

1 0

ovirt-engine-extension-aaa-ldap active directory
by nicola.gentile.to 10 Oct '17

10 Oct '17

Hi, I have a problem. Suddenly from the user portal the users of AD not login and displays the error: server_error: Unexpected comma or semicolon found at the end of the DN string. Also, from Admin Portal ->Users when I try to add a user of AD I don't see the sub domain Also, I try to run ovirt-engine-extension-aaa-ldap-setup but not works. I attach the log file. please help me Thanks Nick

3 4

multipath configuration for local disks?
by Matthias Leopold 10 Oct '17

10 Oct '17

hi, i'm using three different generations of hardware for my oVirt hypervisor hosts. they are not exactly the "same", but very "similar". - all were installed with oVirt Node 4.1.x installers - all have (2-4) local SSD disks for oVirt Node OS - all were configured with manual partitioning and SW RAID 1 with two SSD disks for oVirt Node OS after initializing the third generation of hosts (with 4 SSD disks) i noticed the difference in multipath configuration for the local disks. suddenly the two OS disks (for RAID 1) are not configured as multipath disks anymore, the unused other two are multipath disks. in the first two host generations the (only) two OS disks (for RAID 1) are configured as multipath disks. after looking at this for the first time and briefly looking into multipath documentation i think that local disks shouldn't be included in multipath configuration at all. i tried to remove the local disks from multipathing (delete from wwids file, explicit blacklisting), to no avail. i'm pasting two listings from the 4 SSD disk situation: # lsscsi --scsi_id -g [0:0:0:0] disk ATA SAMSUNG MZ7LM480 204Q /dev/sda - /dev/sg0 [0:0:1:0] disk ATA SAMSUNG MZ7LM480 204Q /dev/sdb - /dev/sg1 [0:0:2:0] disk ATA SAMSUNG MZ7LM480 204Q /dev/sdc SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102216 /dev/sg2 [0:0:3:0] disk ATA SAMSUNG MZ7LM480 204Q /dev/sdd SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102214 /dev/sg3 # ls -l /dev/disk/by-id/*SAMSUNG* lrwxrwxrwx. 1 root root 9 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102212 -> ../../sdb lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102212-part1 -> ../../sdb1 lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102212-part2 -> ../../sdb2 lrwxrwxrwx. 1 root root 9 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102214 -> ../../sdd lrwxrwxrwx. 1 root root 9 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102216 -> ../../sdc lrwxrwxrwx. 1 root root 9 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102222 -> ../../sda lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102222-part1 -> ../../sda1 lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102222-part2 -> ../../sda2 lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/dm-name-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102214 -> ../../dm-6 lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/dm-name-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102216 -> ../../dm-5 lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/dm-uuid-mpath-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102214 -> ../../dm-6 lrwxrwxrwx. 1 root root 10 9. Okt 12:07 /dev/disk/by-id/dm-uuid-mpath-SAMSUNG_MZ7LM480HMHQ-00005_S2UJNX0J102216 -> ../../dm-5 can someone explain this behaviour? what is the _intended_ configuration? thx matthias

2 2

problem installing/upgrading hosts after 3.6 to 4.0 update
by Jorick Astrego 10 Oct '17

10 Oct '17

This is a multi-part message in MIME format. --------------70C79498EE5B5DF90AEE38A5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi=2C It was time to upgrade our ancient ovirt 3=2E6 to 4=2E0 =28and then to 4=2E= 1=29=2C=20 but I=27m having some issues in our test environment=2E After upgrading the engine=2C I try to reinstall a fresh provisioned=20 Centos 7=2E4 node but it fails on the vdsm service=2E When debugging I see in the log that the step =22vdsm-tool configure=22 fai= ls=3A 2017-10-10 10=3A59=3A21 DEBUG otopi=2Econtext context=2E=5FexecuteMetho= d=3A128 Stage closeup METHOD otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages=2EPlugin=2E= =5Freconfigure 2017-10-10 10=3A59=3A21 DEBUG otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages plugin=2Eexec= uteRaw=3A813 execute=3A =28=27/bin/vdsm-tool=27=2C =27configure=27=2C =27--force=27= =29=2C executable=3D=27None=27=2C cwd=3D=27None=27=2C env=3DNone 2017-10-10 10=3A59=3A21 DEBUG otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages plugin=2Eexec= uteRaw=3A863 execute-result=3A =28=27/bin/vdsm-tool=27=2C =27configure=27=2C =27--fo= rce=27=29=2C rc=3D1 2017-10-10 10=3A59=3A21 DEBUG otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages plugin=2Eexec= ute=3A921 execute-output=3A =28=27/bin/vdsm-tool=27=2C =27configure=27=2C =27--fo= rce=27=29 stdout=3A Usage=3A /bin/vdsm-tool =5Boptions=5D =3Caction=3E =5Barguments=5D Valid options=3A -h=2C --help Show this help menu=2E -l=2C --logfile =3Cpath=3E Redirect logging to file=2E -v=2C --verbose When I run it by hand=2C there is no action =22configure=22 vdsm-tool -vvv configure Usage=3A /usr/bin/vdsm-tool =5Boptions=5D =3Caction=3E =5Barguments=5D= Valid options=3A -h=2C --help Show this help menu=2E -l=2C --logfile =3Cpath=3E Redirect logging to file=2E -v=2C --verbose Include warning =28and errors=29 messages in log=2E -vv=2C --vverbose Include information =28and above=29 messages in log=2E -vvv=2C --vvverbose Include debug =28and above=29 messages in log=2E -a=2C --append There is also no =22vdsm-tool validate-config=22 command rpm -qa=7Cgrep vdsm vdsm-jsonrpc-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch vdsm-cli-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch vdsm-4=2E18=2E21-1=2Eel7=2Ecentos=2Ex86=5F64 vdsm-api-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch vdsm-infra-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch vdsm-python-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch vdsm-hook-vmfex-dev-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch vdsm-xmlrpc-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch vdsm-yajsonrpc-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch What could be the problem=3F Met vriendelijke groet=2C With kind regards=2C Jorick Astrego Netbulae Virtualization Experts=20 ---------------- =09Tel=3A 053 20 30 270 =09info=40netbulae=2Eeu =09Staalsteden 4-3A =09KvK= 08198180 =09Fax=3A 053 20 30 271 =09www=2Enetbulae=2Eeu =097547 TA Enschede =09BTW= NL821234584B01 ---------------- --------------70C79498EE5B5DF90AEE38A5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =3Chtml=3E =3Chead=3E =3Cmeta http-equiv=3D=22content-type=22 content=3D=22text/html=3B chars= et=3Dutf-8=22=3E =3C/head=3E =3Cbody text=3D=22=23000000=22 bgcolor=3D=22=23FFFFFF=22=3E =3Cp=3EHi=2C=3C/p=3E =3Cp=3EIt was time to upgrade our ancient ovirt 3=2E6 to 4=2E0 =28and t= hen to 4=2E1=29=2C but I=27m having some issues in our test environment=2E= =3C/p=3E =3Cp=3EAfter upgrading the engine=2C I try to reinstall a fresh provisioned Centos 7=2E4 node but it fails on the vdsm service=2E=3C/= p=3E =3Cp=3EWhen debugging I see in the log that the step =22vdsm-tool configure=22 fails=3A=3C/p=3E =3Cblockquote=3E =3Cp=3E2017-10-10 10=3A59=3A21 DEBUG otopi=2Econtext context=2E=5FexecuteMethod=3A128 Stage closeup METHOD otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages=2EPlugin= =2E=5Freconfigure=3Cbr=3E 2017-10-10 10=3A59=3A21 DEBUG otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages plugin=2EexecuteRaw=3A813 execute=3A =28=27/bin/vdsm-tool=27=2C=20= =27configure=27=2C =27--force=27=29=2C executable=3D=27None=27=2C cwd=3D=27None=27=2C= env=3DNone=3Cbr=3E 2017-10-10 10=3A59=3A21 DEBUG otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages plugin=2EexecuteRaw=3A863 execute-result=3A =28=27/bin/vdsm-tool=27= =2C =27configure=27=2C =27--force=27=29=2C rc=3D1=3Cbr=3E 2017-10-10 10=3A59=3A21 DEBUG otopi=2Eplugins=2Eovirt=5Fhost=5Fdeploy=2Evdsm=2Epackages plugin=2E= execute=3A921 execute-output=3A =28=27/bin/vdsm-tool=27=2C =27configure=27=2C=20= =27--force=27=29 stdout=3A=3Cbr=3E Usage=3A /bin/vdsm-tool =5Boptions=5D =26lt=3Baction=26gt=3B =5Barg= uments=5D=3Cbr=3E Valid options=3A=3Cbr=3E =C2=A0 -h=2C --help=3Cbr=3E =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Show this help menu=2E=3Cbr=3E =C2=A0 -l=2C --logfile =26lt=3Bpath=26gt=3B=3Cbr=3E =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Redirect logging to file=2E=3Cbr=3E =C2=A0 -v=2C --verbose=3Cbr=3E =3Cbr=3E =3C/p=3E =3C/blockquote=3E =3Cp=3EWhen I run it by hand=2C there is no action =22configure=22=3C/p= =3E =3Cblockquote=3E =3Cp=3Evdsm-tool -vvv configure=3Cbr=3E Usage=3A /usr/bin/vdsm-tool =5Boptions=5D =26lt=3Baction=26gt=3B=20= =5Barguments=5D=3Cbr=3E Valid options=3A=3Cbr=3E =C2=A0 -h=2C --help=3Cbr=3E =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Show this help menu=2E=3Cbr= =3E =C2=A0 -l=2C --logfile =26lt=3Bpath=26gt=3B=3Cbr=3E =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Redirect logging to file=2E= =3Cbr=3E =C2=A0 -v=2C --verbose=3Cbr=3E =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Include warning =28and errors= =29 messages in log=2E=3Cbr=3E =C2=A0 -vv=2C --vverbose=3Cbr=3E =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Include information =28and ab= ove=29 messages in log=2E=3Cbr=3E =C2=A0 -vvv=2C --vvverbose=3Cbr=3E =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Include debug =28and above=29= messages in log=2E=3Cbr=3E =C2=A0 -a=2C --append=3Cbr=3E =3Cbr=3E =3C/p=3E =3C/blockquote=3E =3Cp=3EThere is also no =22vdsm-tool validate-config=22 command=3Cbr=3E= =3C/p=3E =3Cp=3E=3Cbr=3E =3C/p=3E =3Cblockquote=3E =3Cp=3Erpm -qa=7Cgrep vdsm=3C/p=3E =3Cp=3Evdsm-jsonrpc-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3Cbr=3E vdsm-cli-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3Cbr=3E vdsm-4=2E18=2E21-1=2Eel7=2Ecentos=2Ex86=5F64=3Cbr=3E vdsm-api-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3Cbr=3E vdsm-infra-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3Cbr=3E vdsm-python-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3C/p=3E =3Cp=3Evdsm-hook-vmfex-dev-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3C/p= =3E =3Cp=3Evdsm-xmlrpc-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3C/p=3E =3Cp=3Evdsm-yajsonrpc-4=2E18=2E21-1=2Eel7=2Ecentos=2Enoarch=3Cbr=3E= =3C/p=3E =3C/blockquote=3E =3Cp=3EWhat could be the problem=3F=3Cbr=3E =3C/p=3E =20= =3CBR /=3E =3CBR /=3E =3Cb style=3D=22color=3A=23604c78=22=3E=3C/b=3E=3Cbr=3E=3Cbr=3E=3Cspan styl= e=3D=22color=3A=23604c78=3B=22=3E=3Cfont color=3D=22000000=22=3E=3Cspan sty= le=3D=22mso-fareast-language=3Aen-gb=3B=22 lang=3D=22NL=22=3EMet vriendelij= ke groet=2C With kind regards=2C=3Cbr=3E=3Cbr=3EJorick Astrego=3Cbr=3E=3C/s= pan=3E=3C/font=3E=3C/span=3E=3Cb style=3D=22color=3A=23604c78=22=3E=3Cbr=3E= Netbulae Virtualization Experts =3C/b=3E=3Cbr=3E=3Chr style=3D=22border=3An= one=3Bborder-top=3A1px solid =23ccc=3B=22=3E=3Ctable style=3D=22width=3A 52= 2px=22=3E=3Ctbody=3E=3Ctr=3E=3Ctd style=3D=22width=3A 130px=3Bfont-size=3A= 10px=22=3ETel=3A 053 20 30 270=3C/td=3E =3Ctd style=3D=22width=3A 130p= x=3Bfont-size=3A 10px=22=3Einfo=40netbulae=2Eeu=3C/td=3E =3Ctd style=3D= =22width=3A 130px=3Bfont-size=3A 10px=22=3EStaalsteden 4-3A=3C/td=3E =20= =3Ctd style=3D=22width=3A 130px=3Bfont-size=3A 10px=22=3EKvK 08198180=3C/td= =3E=3C/tr=3E=3Ctr=3E =3Ctd style=3D=22width=3A 130px=3Bfont-size=3A 10px= =22=3EFax=3A 053 20 30 271=3C/td=3E =3Ctd style=3D=22width=3A 130px=3Bfo= nt-size=3A 10px=22=3Ewww=2Enetbulae=2Eeu=3C/td=3E =3Ctd style=3D=22width= =3A 130px=3Bfont-size=3A 10px=22=3E7547 TA Enschede=3C/td=3E =3Ctd style= =3D=22width=3A 130px=3Bfont-size=3A 10px=22=3EBTW NL821234584B01=3C/td=3E= =3C/tr=3E=3C/tbody=3E=3C/table=3E=3Cbr=3E=3Chr style=3D=22border=3Anone=3Bb= order-top=3A1px solid =23ccc=3B=22=3E=3CBR /=3E =3C/body=3E =3C/html=3E --------------70C79498EE5B5DF90AEE38A5--

1 1

Ovirt 4.2 Fencing problems
by Maton, Brett 10 Oct '17

10 Oct '17

Hi, I recently upgraded my testlab to oVirt 4.2-pre and have been having some issues. One of which is fencing with Dell Drac 8 remote access cards. The configuration I'm using works fine on my other (4.1.6) cluster... Error: Health check on Host host.example.com indicates that future attempts to Start this host using Power-Management are expected to fail. Fence agent setup for the host appears to be working though: Which logs would be helpful in debugging this issue ? Regards, Brett

2 7

VM-Clone issue
by Shamam Amir 09 Oct '17

09 Oct '17

Dear All, We are using oVirt release *Version 4.1.5.2. *I was trying to make a clone of a VM but I got the following message* "*Error while executing action CloneVm: Internal Engine Error", I found that when cloud-init is used in the vm's edit section, this error occurs, but when the vm is configured without cloud init, the clone was completed successfully. I wondered if this is a bug or something else? The log file is in this link https://paste.fedoraproject.org/paste/f~sHprL93BNZ-iJzoFDyww Best Regards

2 1

Dead hosts
by Maton, Brett 09 Oct '17

09 Oct '17

Hi, I've replaced some hardware, and didn't remote 'hosted engine deploy' before retireing the servers. (actually I failed to remove them properly...) How can I get rid of the 'old' hosts from the output of hosted-engine --vm-status ? oVirt 4.2 - pre centOS 7.4 Regards, Brett

2 2

Engine crash, storage won't activate, hosts won't shutdown, template locked, gpu passthrough failed
by M R 09 Oct '17

09 Oct '17

Hello! I have been using Ovirt for last four weeks, testing and trying to get things working. I have collected here the problems I have found and this might be a bit long but help to any of these or maybe to all of them from several people would be wonderful. My version is ovirt node 4.1.5 and 4.1.6 downloaded from website latest stable release at the time. Also tested with CentOS minimal +ovirt repo. In this case, 3. is solved, but other problems persist. 1. Power off host First day after installing ovirt node, it was able to reboot and shutdown clean. No problems at all. After few days of using ovir, I have noticed that hosts are unable to shutdown. I have tested this in several different ways and come to the following conclusion. IF engine has not been started after boot, all hosts are able to shutdown clean. But if engine is started even once, none of the hosts are able to shutdown anymore. The only way to get power off is to unplug or press power button for a longer time as hard reset. I have failed to find a way to have the engine running and then shutdown host. This effects to all hosts in the cluster. 2. Glusterfs failed Every time I have booted hosts, glusterfs has failed. For some reason, it turns inactive state even if I have setup systemctl enable glusterd. Before this command it was just inactive. After this command, it will say "failed (inactive). There is still a way to get glusterfs working. I have to give command systemctl start glusterd manually and everything starts working. Why do I have to give manual commands to start glusterfs? I have used this for CentOS before and never had this problem before. Node installer is that much different from the CentOS core? 3. Epel As I said that I have used CentOS before, I would like to able to install some packets from repo. But even if I install epel-release, it won't find packets such as nano or htop. I have read about how to add epel-release to ovirt node from here: https://www.ovirt.org/release/4.1.1/#epel I have tested even manually edit repolist, but it will fail to find normal epel packets. I have setup additional exclude=collectd* as guided in the link above. This doesn't make any difference. All being said I am able to install manually packets which are downloaded with other CentOS machine and transferred with scp to ovirt node. Still, this once again needs a lot of manual input and is just a workaround for the bug. 4. Engine startup When I try to start the engine when glusterfs is up, it will say vm doesn't exist, starting up. Still, it won't startup automatically. I have to give several times command hosted-engine --vm-start. I wait for about 5minutes until I give it next time. This will take usually about 30minutes and then randomly. Completely randomly after one of the times, I give this command engine shoots up and is up in 1minute. This has happened every time I boot up. And the times that I have to give a command to start the engine, has been changing. At best it's been 3rd time at worst it has been 7th time. Calculating from there it might take from 15minutes to 35minutes to get the engine up.Nevertheless, it will eventually come up every time. If there is a way to get it up on the first try or even better, automatically up, it would be great. 5. Activate storage Once the engine is up, there has been a problem with storage. When I go to storage tab, it will show all sources red. Even if I wait for 15~20minutes, it won't get storage green itself. I have to go and press active button from main data storage. Then it will get main storage up in 2~3munutes.Sometimes it fails it once, but will definitely get main data storage up on the seconds try. And then magically at the same time all other storages instantly go green. Main storage is glusterfs and I have 3 NFS storages as well. This is only a problem when starting up and once storages are on green they stay green. Still annoying that it cannot get it done by itself. 6.Template locked I try to create a template from existing VM and it resulted in original VM going into locked state and template being locked. I have read that some other people had a similar problem and they were suggested to restart engine to see if it solves it. For me it has been now a week and several restarts of engine and hosts, but there is still one VM locked and template locked as well. This is not a big problem, but still a problem. Everything is grey and cannot delete this bugged VM or template. 7. unable to use GPU I have been trying to do GPU passthrough with my VM. First, there was a problem with qemu cmd line, but once I figure out a way to get commands, it maybe is working(?). Log shows up fine, but it still doesn't give functionality I¨m looking for. As I mentioned in the other email that I have found this: https://www.mail-archive.com/users@ovirt.org/msg40422.html . It will give right syntax in log, but still, won't fix error 43 with nvidia drivers. If anybody got this working or has ideas how to do it, would really like to know how it's done properly. I have also tested with AMD graphics cards such as vega, but as soon as drivers have installed, I will get a black screen. Even if I restart VM or hosts or both. I will only see black screen and unable to use VM at all. I might be able to live with the other six things listed above, but this one is a bit of a problem for me. My use of VMs will eventually need graphical performance and therefore I will have to get this working or find an alternative to ovirt..I have found several things that I really like in ovirt and would prefer to use it. Best regards Mikko <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Ei viruksia. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2

Help - Host unresponsive!
by Wesley Stewart 09 Oct '17

09 Oct '17

I have a single server that is running ovirt as a host and a storage domain. I ran an update when the GUI told me that there was one. I shutdown all of the VM's, placed the host in maintenance mode and did the update. Upon rebooting the server, I was able to pull my VM's online without any issue, but then, all of a sudden, vm's stopped responding as well as the host. The host is showing as "Down" and I cannot "Activate" it. Also "Maintenance Mode" is greyed out. Storage pools are "down" but eventually come back online, but the host still will not come online. Every few minutes, the host goes to "UP" right before failing and going back "Down". To make it more confusing, like I mentioned before, this is all in one box, so it isn't like their is a network issue between the storage and the host boxes or anything. Currently trying to reinstall the host and see if that helps, but I would very much appreciate any sort of guidance, support or ideas! Fencing failed on Storage Pool Manager OVIRT-Host for Data Center OVIRT-Datacenter. Setting status to Non-Operational. Host OVIRT-Host failed to recover.

2 5

VM remote noVNC console
by Alex K 06 Oct '17

06 Oct '17

Hi all, I am trying to get the VM console of a VM through SSH socks proxy. This is a scenario I will frequently face, as the ovirt cluster will be available only though a remote SSH tunnel. I am trying several console options without success. With SPICE or VNC I get issue with virt-viewer saying "Unable to connect to libvirt with URI [none]' With noVNC I get a separate tab on browser where it is stuck showing "loading". Has anyone success with this kind of remote console access? Thanx, Alex

3 5

Debugging warning messages about bonding mode 4
by Gianluca Cecchi 06 Oct '17

06 Oct '17

Hello, on a 2 nodes cluster in 4.1.6 I have this situation. Every node has 3 bonds, each one composed by 2 network adapters and each one of type mode=4 (actually in setup networks I have configured custom and then the value: "mode=4 miimon=100" ) At this moment only one of the servers has access to FC storage, while the other is currently on maintenance. On 2 of the 3 bonds of the active server I get an exclamation point in "Network Interfaces" subtab with this mouseover popup Bond is in link aggregation mode (mode 4), but no partner mac has been reported for it What is the exact meaning of this message? Do I have to care about (I think so..)? What should I report to network guys? Eg, one of these two warning bonds status is: # cat /proc/net/bonding/bond2 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer2 (0) MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 802.3ad info LACP rate: slow Min links: 0 Aggregator selection policy (ad_select): stable System priority: 65535 System MAC address: 48:df:37:0c:7f:5a Active Aggregator Info: Aggregator ID: 5 Number of ports: 2 Actor Key: 9 Partner Key: 6 Partner Mac Address: b8:38:61:9c:75:80 Slave Interface: ens2f2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 2 Permanent HW addr: 48:df:37:0c:7f:5a Slave queue ID: 0 Aggregator ID: 5 Actor Churn State: none Partner Churn State: none Actor Churned Count: 2 Partner Churned Count: 3 details actor lacp pdu: system priority: 65535 system mac address: 48:df:37:0c:7f:5a port key: 9 port priority: 255 port number: 1 port state: 61 details partner lacp pdu: system priority: 32768 system mac address: b8:38:61:9c:75:80 oper key: 6 port priority: 32768 port number: 293 port state: 61 Slave Interface: ens2f3 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 2 Permanent HW addr: 48:df:37:0c:7f:5b Slave queue ID: 0 Aggregator ID: 5 Actor Churn State: none Partner Churn State: none Actor Churned Count: 0 Partner Churned Count: 3 details actor lacp pdu: system priority: 65535 system mac address: 48:df:37:0c:7f:5a port key: 9 port priority: 255 port number: 2 port state: 61 details partner lacp pdu: system priority: 32768 system mac address: b8:38:61:9c:75:80 oper key: 6 port priority: 32768 port number: 549 port state: 61 Also, the other node (that is currently in maintenance) shows one of the 2 interfaces of bond2 (ens2f2) as down (red arrow) but on the host # ip link show ens2f2 6: ens2f2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond2 state UP mode DEFAULT qlen 1000 link/ether 48:df:37:0c:85:4e brd ff:ff:ff:ff:ff:ff # Does this depend on the host being in maintenance? Perhaps when a host is in maintenance, the warnings on it are not checked/updated again from engine? Thanks in advance, Gianluca

2 1

Unable to grant permissions to AD users
by Michael Watters 06 Oct '17

06 Oct '17

I'm having some issues granting permissions to AD users in ovirt-engine 4.1. Users can log in but receive an error as below. The user user@example.com@example.com is not authorized to perform login I am also not able to grant this user any permissions through the admin console. Entering a user name in the search field for the System Permissions section results in a blank list. Attached is a screenshot for reference. Does anybody have an idea on what would cause this? The log files aren't very useful and don't show any errors.

2 3

VDI whit Ovirt Spice and NVIDIA passtrought
by codignotto . 06 Oct '17

06 Oct '17

Good night friends, I'm trying to make the passtrought GPU run using OVIRT with an NVIDIA M2000 / K2200 and a K4000, I made several configurations, the VM with windows recognizes the card, I install the NVIDIA drivers and after restarting the windows and access using the client SPICE remote viwer the mouse to work, everything works because the mouse does not work for anything, already tested with Win8, Win10 and the problem persists, the card is recognized but the mouse does not work. Has anyone used it this way? Passtrought from GPU to a VM using SPICE? I'm going to use these clients with 3d and adobe products. Thank you for your help Deny

1 0

IOPS stats/reports from all hosts to storage
by Neil 05 Oct '17

05 Oct '17

Hi guys, I'm running FC storage with 4 hosts on oVirt 3.6 and we've been having some IOPS issues recently and the SAN provider has asked me to provide them with the following info... Datastore Stripe Size Default VM Disk Stripe Size Average IO Size Average THROUGHPUT (MB/s) Average IOPS Maximum IOPS Read/Write Percentage of IO Datastore Average Latency VM Disk Average Latency All of this is from across all hosts and VM's to the storage domain. Is there any way to get this kind of info from oVirt? I've been looking at oVirt-reports but I don't see much as far as IO/throughput reporting goes. Apologies if I've missed something obvious. Thanks. Regards. Neil Wilson.

3 6

LVM structure
by Nicolas Ecarnot 05 Oct '17

05 Oct '17

Hello, I'm still coping with my qemu image corruption, and I'm following some Redhat guidelines that explains the way to go : - Start the VM - Identify the host - On this host, run the ps command to identify the disk image location : # ps ax|grep qemu-kvm|grep vm_name - Look for "-drive file=/rhev/data-center/00000001-0001-0001-0001-00000000033e/b72773dc-c99c-472a-9548-503c122baa0b/images/91bfb2b4-5194-4ab3-90c8-3c172959f712/e7174214-3c2b-4353-98fd-2e504de72c75" (YMMV) - Resolve this symbolic link # ls -la /rhev/data-center/00000001-0001-0001-0001-00000000033e/b72773dc-c99c-472a-9548-503c122baa0b/images/91bfb2b4-5194-4ab3-90c8-3c172959f712/e7174214-3c2b-4353-98fd-2e504de72c75 lrwxrwxrwx 1 vdsm kvm 78 3 oct. 2016 /rhev/data-center/00000001-0001-0001-0001-00000000033e/b72773dc-c99c-472a-9548-503c122baa0b/images/91bfb2b4-5194-4ab3-90c8-3c172959f712/e7174214-3c2b-4353-98fd-2e504de72c75 -> /dev/b72773dc-c99c-472a-9548-503c122baa0b/e7174214-3c2b-4353-98fd-2e504de72c75 - Shutdown the VM - On the SPM, activate the logical volume : # lvchange -ay /dev/b72773dc-c99c-472a-9548-503c122baa0b/e7174214-3c2b-4353-98fd-2e504de72c75 - Verify the state of the qemu image : # qemu-img check /dev/b72773dc-c99c-472a-9548-503c122baa0b/e7174214-3c2b-4353-98fd-2e504de72c75 - If needed, attempt a repair : # qemu-img check -r all /dev/... - In any case, deactivate the LV : # lvchange -an /dev/... I followed this steps tens of times, and finding the LV and activating it was obvious and successful. Since yesterday, I'm finding some VMs one which these steps are not working : I can identify the symbolic link, but the SPM neither the host are able to find the LV device, thus can not LV-activate it : # lvchange -ay /dev/de2fdaa0-6e09-4dd2-beeb-1812318eb893/ce13d349-151e-4631-b600-c42b82106a8d Failed to find logical volume "de2fdaa0-6e09-4dd2-beeb-1812318eb893/ce13d349-151e-4631-b600-c42b82106a8d" Either I need two more coffees, either I may be missing a step or something to check. Looking at the SPM /dev/disk/* structure, it looks like very sound (I can see my three storage domains dm-name-* series of links). As the VM can nicely be ran and stopped, does the host activates something more before being launched? -- Nicolas ECARNOT

3 7

ovirt-node iso installs non-bootable OS
by Guillaume 05 Oct '17

05 Oct '17

----=_RainLoop_127_572554114.1507153165 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello,=0A=0AI'm new to ovirt, I try it for the first time.=0AI downloaded= the iso ovirt-node-ng-installer-ovirt-4.1-2017100406.iso (http://jenkins= .ovirt.org/job/ovirt-node-ng_ovirt-4.1_build-artifacts-el7-x86_64/lastSuc= cessfulBuild/artifact/exported-artifacts/ovirt-node-ng-installer-ovirt-4.= 1-2017100406.iso)=0A=0AI installed it twice, but each time I have the sam= e problem.=0AWhen I reboot the PC after the install I can't start the OS,= I have the following error:=0A=0AFailed to open EFIcentosgrubx64.efi - N= ot Found=0AFailed to load image EFIcentosgrubx64.efi: Not Found=0Astart_i= mage() returned Not Found=0A=0AAm I the only one to have this error ?=0A= =0AIs there a way to solve this issue with the rescue iso choice ? or can= I download an older iso ?=0A=0AThanks,=0A=0AGuillaume ----=_RainLoop_127_572554114.1507153165 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><head><meta http-equiv=3D"Content-Type" content=3D"t= ext/html; charset=3Dutf-8" /></head><body><div data-html-editor-font-wrap= per=3D"true" style=3D"font-family: arial, sans-serif; font-size: 13px;"><= div><div><div style=3D"font-family: arial, sans-serif;font-size: 13px">He= llo,<br><br>I'm new to ovirt, I try it for the first time.<br>I downloade= d the iso <a href=3D"http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.1= _build-artifacts-el7-x86_64/lastSuccessfulBuild/artifact/exported-artifac= ts/ovirt-node-ng-installer-ovirt-4.1-2017100406.iso">ovirt-node-ng-instal= ler-ovirt-4.1-2017100406.iso</a><br><br>I installed it twice, but each ti= me I have the same problem.<br>When I reboot the PC after the install I c= an't start the OS, I have the following error:<br><br>Failed to open \EFI= \centos\grubx64.efi - Not Found<br>Failed to load image \EFI\centos\grubx= 64.efi: Not Found<br>start_image() returned Not Found<br><br>Am I the onl= y one to have this error ?<br><br>Is there a way to solve this issue with= the rescue iso choice ? or can I download an older iso ?<br><br>Thanks,<= br><br>Guillaume<br><signature></signature> </div></div></div></div></bod= y></html> ----=_RainLoop_127_572554114.1507153165--

3 2

Gluster Performance
by Bryan Sockel 05 Oct '17

05 Oct '17

Is there any performance loss from your if your gluster replica 3 servers are not all the same configuration? Server 1 - Primary 16 X 1.2 TB 10k Drives - Raid 10 - Stripe 256k (2.5 Drives) 1 CPU - Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz 64 GB Memory Server 2 - Replica 8 X 6 TB 7.5 RPM Drives - Raid 10 - Trip 512 (3.5) 1 CPU - Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz 16 GB Memory Server 3 - Arbiter (Also Virtual machine node) 2 X 1.2 TB 10k Drives Raid 10 2 CPU - Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 192 GB Memory Thanks

2 1

Organizing an event of oVirt in Myanmar
by Yan Naing Myint 05 Oct '17

05 Oct '17

Hello, We have planned an event named "The Tech Talk" on October 15, 2017. In the event we will mainly focus on - oVirt Virtualization - RAID & NFS - iSCSI In the event, we will use CentOS as main Linux distribution on which above mentioned services will be installed. The event is originally organized by Cyber Wings Co., Ltd here in Yangon, Myanmar. oVirt Myanmar Community is in association with them. Yet as a part of the event, I'm somehow promoting the oVirt alternatively. Here is the event page. https://www.facebook.com/events/120177198667868/? acontext=%7B%22ref%22%3A%2222%22%2C%22feed_story_type%22%3A% 2222%22%2C%22action_history%22%3A%22null%22%7D&pnref=story Agenda https://scontent.frgn1-1.fna.fbcdn.net/v/t1.0-9/22154155_1572685872788061_ 6765400324409071757_n.png?oh=83e2c9db6447296b6fde788b8634df57&oe=5A42295A Stickers printed here https://www.facebook.com/events/120177198667868/permalink/120228851996036/? ref=1&action_history=null Press Release in Myanmar Language describing about the event https://www.facebook.com/thevoicemyanmar.mm/posts/1635592309794355 We are hoping over 100 people will attend. Best, -- Yan Naing Myint CEO Server & Network Engineer Cyber Wings Co., Ltd http://cyberwings.asia 09799950510

1 0

Ovirt causing strange network issues?
by Derek Atkins 05 Oct '17

05 Oct '17

Hi, I'm at my wits end so I'm tossing this here in the hopes that SOMEONE will be able to help me. tl;dr: Ovirt is doing something on my network that is causing my fiber modem to go from 3-5ms to 300-1000+ms round trip times. I know it's ovirt because when I unplug ovirt from my network the issue goes away; when I plug it back in, the issue recurs. Long version: I've been running Ovirt 4.0.6 happily on CentOS 7.3 for several months on a single host machine. Indeed, the host had an uptime of 200+ days and was working great until approximately midnight, September 21/22 (just over a week ago). I was on an airplane halfway across the Atlantic at that time, so it wasn't anything I did. My network is configured as: fiber modem <-> edgerouter <-> switch <-> everything else ovirt is living in the "everything else" area. When I sit with a laptop connected to either the everything else range or even directly connected to the fiber modem, I run 'mtr' and see network times (starting at the fiber modem) that bounce all over the place. When I unplug ovirt I see consistent 3-5ms times. Plug it back in, voom, back up to badness. I've spent several hours plugging and unplugging different devices trying to isolate the issue. The only "device" that has any effect is my ovirt box. I have tried to debug this in several ways, but really the only thing that seems to have helped at all is shutting down all the VMs and the hosted engine. Once nothing else is running (but the host itself), only then does the network seem to return to normal. I'm really at my wits end on this; I have no idea what is causing this or what might have changed to cause the issue right at that time. I also can't imagine what ovirt is doing over the network that could cause the modem, two physical hops away, to lose its mind in this way. But my experiementation is definitely showing a direct correlation. Help!! -derek -- Derek Atkins 617-623-3745 derek(a)ihtfp.com www.ihtfp.com Computer and Internet Security Consultant

3 9

Question about cold start
by Chris Adams 04 Oct '17

04 Oct '17

I have an oVirt cluster that was hard shutdown last night (fire is bad, and firemen killed the generators for their safety). When it came back up, it did not start any VMs other than the hosted engine. Is that expected? I know this is not a normal use case, but is there a way to set VMs to start on cluster boot? -- Chris Adams <cma(a)cmadams.net>

3 4

Re: [ovirt-users] Ovirt 4.0 and EL 7.4
by Sandro Bonazzola 04 Oct '17

04 Oct '17

Il 04 Ott 2017 15:51, "Alan Griffiths" <apgriffiths79(a)gmail.com> ha scritto: Hi, Is 4.0 supported/known to work on CentOS 7.4? I've just tried to upgrade one of the hosts in my lab from 7.3 to 7.4 and now vdsm-network fails to start with vdsm-tool: libvirt: XML-RPC error : authentication failed: authentication failed To even get this far I had to exclude gluster packages as 7.4 introduces 3.8 but ovirt 4.0 repo is still on 3.7. So, more generally. If I'm on ovirt 4.0, gluster 3.7 and EL 7.3. What is the best ordering for getting to ovirt 4.1 and EL 7.4? I would suggest to first upgrade to oVirt 4.1 and then complete the update to CentOS 7.4 Thanks, Alan _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

Re: [ovirt-users] How to import a qcow2 disk into ovirt
by Martín Follonier 04 Oct '17

04 Oct '17

Hi, I've done all the recommendations in this thread, and I'm still getting the "Paused by System" message just after the transfer starts. Honestly I don't know were else to look at, cause I don't find any log entry or packet capture that give me a hint about what is happening. I'll appreciate any help! Thank you in advance! Regards Martin On Thu, Sep 1, 2016 at 5:01 PM, Amit Aviram <aavi...(a)redhat.com> wrote: > You can do both, > Through the database, the table is "vdc_options". change "option_value" > where "option_name" = 'ImageProxyAddress' . > > On Thu, Sep 1, 2016 at 4:56 PM, Gianluca Cecchi <gianluca.cec...(a)gmail.com > > wrote: > >> On Thu, Sep 1, 2016 at 3:53 PM, Amit Aviram <aavi...(a)redhat.com> wrote: >> >>> You can just replace this value in the DB and change it to the right >>> FQDN, it is a config value named "ImageProxyAddress". replace "localhost" >>> with the right address (notice that the port is there too). >>> >>> If this will keep happen after users will have the latest version, we >>> will have to open a bug and fix whatever causes the URL to be "localhost". >>> >>> >> Do you mean through "engine-config" or directly into database? >> In this second case which is the table involved? >> >> Gianluca >> > > [root@ractorshe bin]# systemctl stop ovirt-imageio-proxy engine=# select * from vdc_options where option_name='ImageProxyAddress'; option_id | option_name | option_value | version -----------+-------------------+-----------------+--------- 950 | ImageProxyAddress | localhost:54323 | general (1 row) engine=# update vdc_options set option_value='ractorshe.mydomain:54323' where option_name='ImageProxyAddress'; UPDATE 1 engine=# select * from vdc_options where option_name='ImageProxyAddress'; option_id | option_name | option_value | version -----------+-------------------+--------------------------------------+--------- 950 | ImageProxyAddress | ractorshe.mydomain:54323 | general (1 row) engine=# engine=# select * from vdc_options where option_name='ImageProxyAddress'; option_id | option_name | option_value | version -----------+-------------------+--------------------------------------+--------- 950 | ImageProxyAddress | ractorshe.mydomain:54323 | general (1 row) systemctl stop ovirt-engine (otherwise it remained localhost) systemctl start ovirt-engine systemctl start ovirt-imageio-proxy Now transfer is ok. I tried a qcow2 disck configured as 40Gb but containing about 1.6Gb of data. I'm going to connect it to a VM and see if all is ok also from a contents point of view. Gianluca _______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users

5 6

oVirt blog screenshots: paging jmarks
by ovirt＠fateknollogee.com 04 Oct '17

04 Oct '17

https://www.ovirt.org/blog/2017/09/introducing-ovirt-4.2.0/ https://www.ovirt.org/blog/2017/10/introducing-high-performance-vms/ @jmarks : can you include the full resolution of your screenshots from those 2 blog posts? Those screenshots are hard to see any detail

2 1

oVirt Hosted Engine Backup and Restore guide
by Alexander Vrublevskiy 03 Oct '17

03 Oct '17

----ALT--yzweeHoec3G1pTHJaNdlhSvadlSkYjRQ1507035192 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CkhlbGxvIENvbW11bml0eSEKCkknbSBsb29raW5nIGZvciBpbmZvcm1hdGlvbiBhYm91dCBIb3N0 ZWQgRW5naW5lIGJhY2t1cCBhbmQgcmVzdG9yZSBwcm9jZWR1cmVzLiBUaGVyZSdzIEhFIGhvdy10 byB3aGljaCByZWZlcnMgdG8gb1ZpcnQgSG9zdGVkIEVuZ2luZSBCYWNrdXAgYW5kIFJlc3RvcmUg Z3VpZGU6Cmh0dHBzOi8vd3d3Lm92aXJ0Lm9yZy9kb2N1bWVudGF0aW9uL2hvdy10by9ob3N0ZWQt ZW5naW5lLyNob3N0ZWQtZW5naW5lLWJhY2t1cC1hbmQtcmVzdG9yZSDCoAoKYnV0IHRoZSBsaW5r IGxlYWRzIHRvIDQwNCBlcnJvci4KCkNvdWxkIGFueW9uZSBwcm92aWRlIHdvcmtpbmcgbGluayB0 byB0aGUgZG9jdW1lbnQsIHBsZWFzZT8KCkFuZCB0aGUgbWFpbiBwb2ludCB3aHkgSSdtIGxvb2tp bmcgZm9yIGl0IGlzIEhFIG1pZ3JhdGlvbjogd2UgbmVlZCB0byBtb3ZlIEhFIHRvIGFub3RoZXIg ZGF0YSBjZW50ZXIuIEl0J2QgYmUgYXdlc29tZSBpZiBzb21lb25lIGNvdWxkIHNoYXJlIGV4cGVy aWVuY2Ugb2Ygc3VjaCBtaWdyYXRpb24gb3IgYXQgbGVhc3QgcG9pbnQgdGhlIGRpcmVjdGlvbiB0 byBleHBsb3JlLgoKVGhhbmtzIGluIGFkdmFuY2UhClJlZ2FyZHMKQWxleAo= ----ALT--yzweeHoec3G1pTHJaNdlhSvadlSkYjRQ1507035192 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPjxwPkhlbGxvIENvbW11bml0eSE8YnI+PGJyPkknbSBsb29raW5nIGZvciBp bmZvcm1hdGlvbiBhYm91dCBIb3N0ZWQgRW5naW5lIGJhY2t1cCBhbmQgcmVzdG9yZSBwcm9jZWR1 cmVzLiBUaGVyZSdzIEhFIGhvdy10byB3aGljaCByZWZlcnMgdG8gb1ZpcnQgSG9zdGVkIEVuZ2lu ZSBCYWNrdXAgYW5kIFJlc3RvcmUgZ3VpZGU6PGJyIGRhdGEtbWNlLWJvZ3VzPSIxIj48L3A+PHA+ PGEgaHJlZj0iaHR0cHM6Ly93d3cub3ZpcnQub3JnL2RvY3VtZW50YXRpb24vaG93LXRvL2hvc3Rl ZC1lbmdpbmUvI2hvc3RlZC1lbmdpbmUtYmFja3VwLWFuZC1yZXN0b3JlIj5odHRwczovL3d3dy5v dmlydC5vcmcvZG9jdW1lbnRhdGlvbi9ob3ctdG8vaG9zdGVkLWVuZ2luZS8jaG9zdGVkLWVuZ2lu ZS1iYWNrdXAtYW5kLXJlc3RvcmU8L2E+Jm5ic3A7PGJyPjxicj5idXQgdGhlIGxpbmsgbGVhZHMg dG8gNDA0IGVycm9yLjxicj48YnI+Q291bGQgYW55b25lIHByb3ZpZGUgd29ya2luZyBsaW5rIHRv IHRoZSBkb2N1bWVudCwgcGxlYXNlPzxicj48YnI+QW5kIHRoZSBtYWluIHBvaW50IHdoeSBJJ20g bG9va2luZyBmb3IgaXQgaXMgSEUgbWlncmF0aW9uOiB3ZSBuZWVkIHRvIG1vdmUgSEUgdG8gYW5v dGhlciBkYXRhIGNlbnRlci4gSXQnZCBiZSBhd2Vzb21lIGlmIHNvbWVvbmUgY291bGQgc2hhcmUg ZXhwZXJpZW5jZSBvZiBzdWNoIG1pZ3JhdGlvbiBvciBhdCBsZWFzdCBwb2ludCB0aGUgZGlyZWN0 aW9uIHRvIGV4cGxvcmUuPGJyPjxicj5UaGFua3MgaW4gYWR2YW5jZSE8YnI+PC9wPjxwPlJlZ2Fy ZHM8YnI+QWxleDxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9wPjwvQk9EWT48L0hUTUw+Cg== ----ALT--yzweeHoec3G1pTHJaNdlhSvadlSkYjRQ1507035192--

2 2

Doubt about iptables host config
by Gianluca Cecchi 03 Oct '17

03 Oct '17

Hello, I have read this interesting blog post https://www.ovirt.org/blog/2016/12/extension-iptables-rules-oVirt-hosts/ In my case, to allow incoming connections from Nagios server to connect to Nagios nrpe daemon installed on hosts I have run [root@ovmgr1 ~]# engine-config --set IPTablesConfigSiteCustom=' > -A INPUT -p tcp --dport 5666 -s 10.4.5.99/32 -m comment --comment "Nagios NRPE daemon" -j ACCEPT > ' [root@ovmgr1 ~]# and systemctl restart ovirt-engine BTW: the link above misses the final ' apex at the end of the similar command in the given example On my oVirt running host (CentOS 7.4) in the mean time I have run [g.cecchi@ov300 ~]$ sudo iptables -I INPUT 16 -p tcp --dport 5666 -s 10.4.5.99/32 -m comment --comment "Nagios NRPE daemon" -j ACCEPT In fact the current "reject-with icmp-host-prohibited" was line 16 and I have inserted it right before. So far so good. I have a doubt if, in case of host put into maintenance and then reactivated, or rebooted, the rule will remain. Or do I have anyway to put any line in any file on host to set it persistently? I wouldn't like to go and reinstall it only to statically set a new iptables rule. Thanks, Gianluca

2 3

Proper Network Configuration
by ~Stack~ 03 Oct '17

03 Oct '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wEg6kdsJlbpnhkD0mpdWdqOEdlJP6oNc1 Content-Type: multipart/mixed; boundary="HkTRrIMlc5sthQGPoqAwgFo6PqOrG1D7i"; protected-headers="v1" From: ~Stack~ <i.am.stack(a)gmail.com> To: users <users(a)ovirt.org> Message-ID: <731fe359-8d20-949c-f0fa-50220389cbaf(a)gmail.com> Subject: Proper Network Configuration --HkTRrIMlc5sthQGPoqAwgFo6PqOrG1D7i Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Greetings, For various reasons I have multiple networks that I am required to work with. I just want to ensure that I've understood the documentation for setting up Ovirt correctly. - First is my BMC/ilo network. The security team wants as few entry points into this as possible and wants as much segregation as possible. - Second is my "management" access network. For my other machines on this network this means admin-SSH/rsyslog/SaltStack configuration management/ect. - Third is my high speed network where my NFS storage sits and applications that need the bandwidth do their thing. - Fourth is my "public" access. My Engine host has the "management" and "public" networks. My Hypervisor hosts have the "BMC/ilo", "management", and "storage" networks. Is there a reason why I should add "public" on the hypervisors? Is there a reason why I may need "BMC/ilo" or "storage" on the Engine hos= t? Thanks! ~Stack~ --HkTRrIMlc5sthQGPoqAwgFo6PqOrG1D7i-- --wEg6kdsJlbpnhkD0mpdWdqOEdlJP6oNc1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZ0rRVAAoJELkej+ysXJPm6PYP/3egWmQRTAWJvpGnEMuJtPcE IWxTyNhlWpF4nO+Euihj2f9zCtkgQJ1zt1chhfvgGnNcfX2PplqJDXPJ7oOeVEnS v3sddpgjNXMLHUvz2txsSqGfsQjCQiBQRBmcm3WY7MFH7y4ZZkyzJulA/E257Ogw BUHSefvpvi6DophHoGjyq4dNf4+1fHCorFRqruCK3mDvOAdXc3aCsUWIlELZIkDh zPw+++FFvGlTWtMJHoiTTTmjkQkLYjdBHHy7C1FJwj/DHWnZRHBl4+BXoxTk40GY 1zH9iXALuuBf/edNT7cFS0ScE3n1XCWrHBPcpLWR/mPWFW5Da5WyPPF0glnI1nN0 Qdwl8yreWz/oo8HS8beCYxSvqOro7yqzvdN5yjvQlxgYr9k/cJW81CMqnqMs+uMT iECxWQ5s1ICeBghF2sFvpVnED3yRlqOdxLr/gmBMgGi6fb+x1D6grnT8Hb4o+wDd mUOlx9wvDILtJUaJh/h9FNibrO/oFmxVQtJqsLACxZGcv9x0bz/wNGlswy+MPv8R O38ys9rvq7XQEpEtw/P4uLw2zb03Pnah6UFMredZpY2LdK4KyLNc5bwfoaafCjxW 2mj0WQMx9lAtLquznZaSkd1wouhjmmtBlhlACgTH/019TBzf7oy0pFJcHbXIoxac Je8z0wc4tveMHCK5oVpO =B3Ot -----END PGP SIGNATURE----- --wEg6kdsJlbpnhkD0mpdWdqOEdlJP6oNc1--

2 2

Hosted engine setup question
by Demeter Tibor 03 Oct '17

03 Oct '17

--=_d5a03c9f-d720-4690-b3f7-196f2e084694 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I just installed a hosted engine based four nodes cluster to glustered storage. It seems to working fine, but I have some question about it. - I would like to make an own cluster and datacenter. Is it possible to remove a host and re-add to an another cluster while it is running the hosted engine? - Is it possible to remove default datacenter without any problems? - I have a productive ovirt cluter that is based on 3.5 series. It is using a shared nfs storage. Is it possible to migrate VMs from 3.5 to 4.1 with detach shared storage from the old cluster and attach it to the new cluster? - If yes what will happend with the VM properies? For example mac addresses, limits, etc. Those will be migrated or not? Thanks in advance, Regard Tibor --=_d5a03c9f-d720-4690-b3f7-196f2e084694 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>Hi,</div><div><br data-mce-bogus=3D"1"></di= v><div>I just installed a hosted engine based four nodes cluster to gluster= ed storage.</div><div>It seems to working fine, but I have some question ab= out it.</div><div><br data-mce-bogus=3D"1"></div><div>- I would like to mak= e an own cluster and datacenter. Is it possible to remove a host and re-add= to an another cluster while it is running the hosted engine? </div><d= iv>- Is it possible to remove default datacenter without any problems?&nbsp= ;</div><div><br></div><div>- I have a productive ovirt cluter that is based= on 3.5 series. It is using a shared nfs storage.  Is it possible to m= igrate VMs from 3.5 to 4.1 with detach shared storage from the old cluster = and attach it to the new cluster? </div><div>- If yes what will happen= d with the VM properies? For example mac addresses, limits, etc. Those will= be migrated or not?</div><div><br data-mce-bogus=3D"1"></div><div>Thanks i= n advance,</div><div>Regard</div><div><br data-mce-bogus=3D"1"></div><div><= br data-mce-bogus=3D"1"></div><div>Tibor</div><div data-marker=3D"__SIG_PRE= __"><p style=3D"font-family: 'Times New Roman'; font-size: medium; margin: = 0px;" data-mce-style=3D"font-family: 'Times New Roman'; font-size: medium; = margin: 0px;"><strong><span style=3D"font-size: medium;" data-mce-style=3D"= font-size: medium;"><span style=3D"color: #2d67b0;" data-mce-style=3D"color= : #2d67b0;"><br></span></span></strong></p><p style=3D"font-family: 'Times = New Roman'; font-size: medium; margin: 0px;" data-mce-style=3D"font-family:= 'Times New Roman'; font-size: medium; margin: 0px;"><span style=3D"font-fa= mily: georgia, serif; color: #000080;" data-mce-style=3D"font-family: georg= ia, serif; color: #000080;"><strong><span style=3D"font-size: medium;" data= -mce-style=3D"font-size: medium;"><span></span></span></strong></span></p><= p></p></div></div></body></html> --=_d5a03c9f-d720-4690-b3f7-196f2e084694--

2 3

Help with Power Management network
by ~Stack~ 02 Oct '17

02 Oct '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OnEhT75wdmSi56KelkEfSHNlc4EOmbWar Content-Type: multipart/mixed; boundary="QtNjKESroum0Gs4B16RTXPJnq400V1QDU"; protected-headers="v1" From: ~Stack~ <i.am.stack(a)gmail.com> To: users(a)ovirt.org Message-ID: <42d5325d-217f-5559-ec5a-11a10fbad2ed(a)gmail.com> Subject: Help with Power Management network --QtNjKESroum0Gs4B16RTXPJnq400V1QDU Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Greetings, I hit up the IRC earlier, but only crickets. Guess no one wants to stick around late on a Friday night. :-D I'm an ovirt newb here. I've been going through the docs setting up 4.1 on Scientific Linux 7.4. For the most part everything is going well once I learn how to do it. I'm, however, stuck on power management. I have multiple networks: 192.168.1.x is my BMC/ilo network. The security team wants as few entry points into this as possible and wants as much segregation as possible. 192.168.2.x is my "management" access network. For my other machines on this network this means admin-SSH/rsyslog/SaltStack configuration management/ect. 192.168.3.x is my high speed network where my NFS storage sits and applications that need the bandwidth do their thing. 10.10.86.x is my "public" access All networks are configured on the Host network settings. Mostly confident I got it right...at least each network/IP matches the right interface. ;-) Right now I only have the engine server and one hyper-visor. On either host I can ssh into the command line and run fence_ipmilan -a 192.168.1.x -l USER -p PASS -o status -v -P" it works, all is good. However, when I try to add it in the ovirt interface I get an error. :-/ Edit Host -> Power Management: Address: 192.168.1.14 User Name: root Password: SorryCantTellYou Type: ipmilan Options: <blank> Test Test failed: Failed to run fence status-check on host '192.168.2.14'. No other host was available to serve as proxy for the operation. Yes, same host because I only have one right now. :-) Any help or guidance would be much appreciated. In the meantime I'm going back to the docs to poke at a few other things I need to figure out. :-) Thanks! ~Stack~ --QtNjKESroum0Gs4B16RTXPJnq400V1QDU-- --OnEhT75wdmSi56KelkEfSHNlc4EOmbWar Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZzqxCAAoJELkej+ysXJPmkn8P/i7sx6DP5aSOejTEvOzq45jc uTYNnoAqniDK/do47z2ojjB0+Oa6czExR7IqyzAzz9+pFEMZlRttxVwQ0XyEj+4t Fw44htR1PhU+YnNQm4fgEo04P7X72qEzdgeMgA/vVVp6chpw0tSG5/bLosrX/yJC NsUF4X0yhnfsCtLZ9Tw78S392OqIQ1iyx12Brmxtip0c97JenMXxXXrxPoUHDFcR T+mqVf7jnC+VxpRj0x5qU+JAOr05oje9coAgbDE6MhWaL6sjClEwhsi5VOU47he9 JcBjKbye4bRHIlzkgpg01Ge0m5fQ4FclJl9wnV4V5vX1Rkuol61wiPQ6SXd/CPy2 PiVsbvX3WloealAupANhaaYG93QPpQsmrw/6Ew/Finlsz6CNfg2VZHbzBGc79QV6 trLMhu+fw7Hsi/lmiU9Rkkmi8OOSgtapMkA283ft1wnBr7gYTyPZwQsp2chO66X5 QZvrRC64nBv9QcVswawWruWSIsETWNNRg7NltEiy8CKBDUsaJ4vJftXzEuHe++ML 2tgOaVRK9nikf6C5OlGPf2TVTVuBRyXGQTVQhGmPVx40499B5sUaen3+dyDHy8QW qLWi6iPiN0YGZkzh/inl/jT4aowQlZEZTfT3KpnH5tyZQ018rcJBQnKFBiTwi5aM /KzRHvKBIvKpjiIREQ7V =kxQZ -----END PGP SIGNATURE----- --OnEhT75wdmSi56KelkEfSHNlc4EOmbWar--

3 6

Re: [ovirt-users] xfs fragmentation problem caused data domain to hang
by Jason Keltz 02 Oct '17

02 Oct '17

This is a multi-part message in MIME format. --------------8888294F2C8EF5B404842160 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/02/2017 11:00 AM, Yaniv Kaul wrote: > > > On Mon, Oct 2, 2017 at 5:57 PM, Jason Keltz <jas(a)cse.yorku.ca > <mailto:jas@cse.yorku.ca>> wrote: > > > On 10/02/2017 10:51 AM, Yaniv Kaul wrote: >> >> >> On Mon, Oct 2, 2017 at 5:14 PM, Jason Keltz <jas(a)cse.yorku.ca >> <mailto:jas@cse.yorku.ca>> wrote: >> >> >> On 10/02/2017 01:22 AM, Yaniv Kaul wrote: >>> >>> >>> On Mon, Oct 2, 2017 at 5:11 AM, Jason Keltz >>> <jas(a)cse.yorku.ca <mailto:jas@cse.yorku.ca>> wrote: >>> >>> Hi. >>> >>> For my data domain, I have one NFS server with a large >>> RAID filesystem (9 TB). >>> I'm only using 2 TB of that at the moment. Today, my NFS >>> server hung with >>> the following error: >>> >>> xfs: possible memory allocation deadlock in kmem_alloc >>> >>> >>> Can you share more of the log so we'll see what happened >>> before and after? >>> Y. >>> >>> >>> Here is engine-log from yesterday.. the problem started >>> around 14:29 PM. >>> http://www.eecs.yorku.ca/~jas/ovirt-debug/10012017/engine-log.txt >>> <http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/10012017/engine-log.txt> >>> >>> Here is the vdsm log on one of the virtualization hosts, >>> virt01: >>> http://www.eecs.yorku.ca/~jas/ovirt-debug/10012017/vdsm.log.2 >>> <http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/10012017/vdsm.log.2> >>> >>> Doing further investigation, I found that the XFS error >>> messages didn't start yesterday. You'll see they >>> started at the very end of the day on September 23. See: >>> >>> http://www.eecs.yorku.ca/~jas/ovirt-debug/messages-20170924 >>> <http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/messages-20170924> >>> >>> >>> >>> Our storage guys do NOT think it's an XFS fragmentation >>> issue, but we'll be looking at it. >> Hmmm... almost sorry to hear that because that would be easy >> to "fix"... >> >>> >>> They continued on the 24th, then on the 26th... I think >>> there were a few "hangs" on those times that people were >>> complaining about, but we didn't catch the problem. >>> However, the errors hit big time yesterday at 14:27 >>> PM... see here: >>> >>> http://www.eecs.yorku.ca/~jas/ovirt-debug/messages-20171001 >>> <http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/messages-20171001> >>> >>> If you want any other logs, I'm happy to provide them. I >>> just don't know exactly what to provide. >>> >>> Do you know if I can run the XFS defrag command live? >>> Rather than on a disk by disk, I'd rather just do it on >>> the whole filesystem. There really aren't that many >>> files since it's just ovirt disk images. However, I >>> don't understand the implications to running VMs. I >>> wouldn't want to do anything to create more downtime. >>> >>> >>> Should be enough to copy the disks to make them less fragmented. >> Yes, but this requires downtime.. but there's plenty of >> additional storage, so this would fix things well. >> > > Live storage migration could be used. > Y. > > > >> >> I had upgraded the engine server + 4 virtualization hosts >> from 4.1.1 to current on September 20 along with upgrading >> them from CentOS 7.3 to CentOS 7.4. virtfs, the NFS file >> server, was running CentOS 7.3 and kernel >> vmlinuz-3.10.0-514.16.1.el7.x86_64. Only yesterday, did I >> upgrade it to CentOS 7.4 and hence kernel >> vmlinuz-3.10.0-693.2.2.el7.x86_64. >> >> I believe the problem is fully XFS related, and not ovirt at >> all. Although, I must admit, ovirt didn't help either. When >> I rebooted the file server, the iso and export domains were >> immediately active, but the data domain took quite a long >> time. I kept trying to activate it, and it couldn't do it. >> I couldn't make a host an SPM. I found that the data domain >> directory on the virtualization host was a "stale NFS file >> handle". I rebooted one of the virtualization hosts (virt1), >> and tried to make it the SPM. Again, it wouldn't work. >> Finally, I ended up turning everything into maintenance mode, >> then activating just it, and I was able to make it the SPM. >> I was then able to bring everything up. I would have >> expected ovirt to handle the problem a little more >> gracefully, and give me more information because I was >> sweating thinking I had to restore all the VMs! >> >> >> Stale NFS is on our todo list to handle. Quite challenging. > Thanks.. > >> >> I didn't think when I chose XFS as the filesystem for my >> virtualization NFS server that I would have to defragment the >> filesystem manually. This is like the old days of running >> Norton SpeedDisk to defrag my 386... >> >> >> We are still not convinced it's an issue - but we'll look into it >> (and perhaps ask for more stats and data). > Thanks! > > >> Y. >> >> >> Thanks for any help you can provide... >> >> Jason. >> >> >>> >>> All 4 virtualization hosts of course had problems since >>> there was no >>> longer any storage. >>> >>> In the end, it seems like the problem is related to XFS >>> fragmentation... >>> >>> I read this great blog here: >>> >>> https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-deadl… >>> <https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-deadl…> >>> >>> In short, I tried this: >>> >>> # xfs_db -r -c "frag -f" /dev/sdb1 >>> actual 4314253, ideal 43107, fragmentation factor 99.00% >>> >>> Apparently the fragmentation factor doesn't mean much, >>> but the fact that >>> "actual" number of extents is considerably higher than >>> "ideal" extents seems that it >>> may be the problem. >>> >>> I saw that many of my virtual disks that are written to >>> a lot have, of course, >>> a lot of extents... >>> >>> For example, on our main web server disk image, there >>> were 247,597 >>> extents alone! I took the web server down, and ran the >>> XFS defrag >>> command on the disk... >>> >>> # xfs_fsr -v 9a634692-1302-471f-a92e-c978b2b67fd0 >>> 9a634692-1302-471f-a92e-c978b2b67fd0 >>> extents before:247597 after:429 DONE >>> 9a634692-1302-471f-a92e-c978b2b67fd0 >>> >>> 247,597 before and 429 after! WOW! >>> >>> Are virtual disks a problem with XFS? Why isn't this >>> memory allocation >>> deadlock issue more prevalent. I do see this article >>> mentioned on many >>> web posts. I don't specifically see any recommendation >>> to *not* use >>> XFS for the data domain though. >>> >>> I was running CentOS 7.3 on the file server, but before >>> rebooting the server, >>> I upgraded to the latest kernel and CentOS 7.4 in the >>> hopes that if there >>> was a kernel issue, that this would solve it. >>> >>> I took a few virtual systems down, and ran the defrag on >>> the disks. However, >>> with over 30 virtual systems, I don't really want to do >>> this individually. >>> I was wondering if I could run xfs_fsr on all the disks >>> LIVE? It says in the >>> manual that you can run it live, but I can't see how >>> this would be good when >>> a system is using that disk, and I don't want to deal >>> with major >>> corruption across the board. Any thoughts? >>> >>> Thanks, >>> >>> Jason. >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org <mailto:Users@ovirt.org> >>> http://lists.ovirt.org/mailman/listinfo/users >>> <http://lists.ovirt.org/mailman/listinfo/users> >>> >>> >> >> > > --------------8888294F2C8EF5B404842160 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 10/02/2017 11:00 AM, Yaniv Kaul wrote:<br> </div> <blockquote type="cite" cite="mid:CAJgorsb2ctuEaTpNkzvixsDSjF-_ABH6JDMgw5X03WUgZgbo2A@mail.gmail.com"> <div dir="ltr"><br> <div class="gmail_extra"><br> <div class="gmail_quote">On Mon, Oct 2, 2017 at 5:57 PM, Jason Keltz <span dir="ltr"><<a href="mailto:jas@cse.yorku.ca" target="_blank" moz-do-not-send="true">jas(a)cse.yorku.ca</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"><span class=""> <br> <div class="m_3456688468548054330moz-cite-prefix">On 10/02/2017 10:51 AM, Yaniv Kaul wrote:<br> </div> <blockquote type="cite"> <div dir="ltr"><br> <div class="gmail_extra"><br> <div class="gmail_quote">On Mon, Oct 2, 2017 at 5:14 PM, Jason Keltz <span dir="ltr"><<a href="mailto:jas@cse.yorku.ca" target="_blank" moz-do-not-send="true">jas(a)cse.yorku.ca</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"><span> <br> <div class="m_3456688468548054330m_-6564063642909371047moz-cite-prefix">On 10/02/2017 01:22 AM, Yaniv Kaul wrote:<br> </div> <blockquote type="cite"> <div dir="ltr"><br> <div class="gmail_extra"><br> <div class="gmail_quote">On Mon, Oct 2, 2017 at 5:11 AM, Jason Keltz <span dir="ltr"><<a href="mailto:jas@cse.yorku.ca" target="_blank" moz-do-not-send="true">jas(a)cse.yorku.ca</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br> <br> For my data domain, I have one NFS server with a large RAID filesystem (9 TB).<br> I'm only using 2 TB of that at the moment. Today, my NFS server hung with<br> the following error:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> xfs: possible memory allocation deadlock in kmem_alloc<br> </blockquote> </blockquote> <div><br> </div> <div>Can you share more of the log so we'll see what happened before and after?</div> <div>Y.</div> </div> </div> </div> </blockquote> </span><span class=""> <blockquote type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <br> Here is engine-log from yesterday.. the problem started around 14:29 PM.<br> <a class="m_3456688468548054330m_-6564063642909371047moz-txt-link-freetext" href="http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/10012017/engine-log.txt" target="_blank" moz-do-not-send="true">http://www.eecs.yorku.ca/~jas/<wbr>ovirt-debug/10012017/engine-lo<wbr>g.txt</a><br> <br> Here is the vdsm log on one of the virtualization hosts, virt01:<br> <a class="m_3456688468548054330m_-6564063642909371047moz-txt-link-freetext" href="http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/10012017/vdsm.log.2" target="_blank" moz-do-not-send="true">http://www.eecs.yorku.ca/~jas/<wbr>ovirt-debug/10012017/vdsm.log.<wbr>2</a><br> <br> Doing further investigation, I found that the XFS error messages didn't start yesterday. You'll see they started at the very end of the day on September 23. See:<br> <br> <a class="m_3456688468548054330m_-6564063642909371047moz-txt-link-freetext" href="http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/messages-20170924" target="_blank" moz-do-not-send="true">http://www.eecs.yorku.ca/~jas/<wbr>ovirt-debug/messages-20170924</a> <br> </div> </blockquote> <div><br> </div> <div>Our storage guys do NOT think it's an XFS fragmentation issue, but we'll be looking at it.</div> <div> </div> </div> </div> </div> </blockquote> </span> Hmmm... almost sorry to hear that because that would be easy to "fix"... <br> <span class=""> <br> <blockquote type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <br> They continued on the 24th, then on the 26th... I think there were a few "hangs" on those times that people were complaining about, but we didn't catch the problem. However, the errors hit big time yesterday at 14:27 PM... see here:<br> <br> <a class="m_3456688468548054330m_-6564063642909371047moz-txt-link-freetext" href="http://www.eecs.yorku.ca/%7Ejas/ovirt-debug/messages-20171001" target="_blank" moz-do-not-send="true">http://www.eecs.yorku.ca/~jas/<wbr>ovirt-debug/messages-20171001</a><br> <br> If you want any other logs, I'm happy to provide them. I just don't know exactly what to provide.<br> <br> Do you know if I can run the XFS defrag command live? Rather than on a disk by disk, I'd rather just do it on the whole filesystem. There really aren't that many files since it's just ovirt disk images. However, I don't understand the implications to running VMs. I wouldn't want to do anything to create more downtime.<br> </div> </blockquote> <div><br> </div> <div>Should be enough to copy the disks to make them less fragmented.</div> <div> </div> </div> </div> </div> </blockquote> </span> Yes, but this requires downtime.. but there's plenty of additional storage, so this would fix things well.</div> </blockquote> </div> </div> </div> </blockquote> </span></div> </blockquote> <div><br> </div> <div>Live storage migration could be used.</div> <div>Y.</div> <div> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"><span class=""><br> <br> <blockquote type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <br> I had upgraded the engine server + 4 virtualization hosts from 4.1.1 to current on September 20 along with upgrading them from CentOS 7.3 to CentOS 7.4. virtfs, the NFS file server, was running CentOS 7.3 and kernel vmlinuz-3.10.0-514.16.1.el7.x8<wbr>6_64. Only yesterday, did I upgrade it to CentOS 7.4 and hence kernel vmlinuz-3.10.0-693.2.2.el7.x86<wbr>_64.<br> <br> I believe the problem is fully XFS related, and not ovirt at all. Although, I must admit, ovirt didn't help either. When I rebooted the file server, the iso and export domains were immediately active, but the data domain took quite a long time. I kept trying to activate it, and it couldn't do it. I couldn't make a host an SPM. I found that the data domain directory on the virtualization host was a "stale NFS file handle". I rebooted one of the virtualization hosts (virt1), and tried to make it the SPM. Again, it wouldn't work. Finally, I ended up turning everything into maintenance mode, then activating just it, and I was able to make it the SPM. I was then able to bring everything up. I would have expected ovirt to handle the problem a little more gracefully, and give me more information because I was sweating thinking I had to restore all the VMs!<br> </div> </blockquote> <div><br> </div> <div>Stale NFS is on our todo list to handle. Quite challenging.</div> <div> </div> </div> </div> </div> </blockquote> </span> Thanks..<span class=""><br> <br> <blockquote type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <br> I didn't think when I chose XFS as the filesystem for my virtualization NFS server that I would have to defragment the filesystem manually. This is like the old days of running Norton SpeedDisk to defrag my 386...<br> </div> </blockquote> <div><br> </div> <div>We are still not convinced it's an issue - but we'll look into it (and perhaps ask for more stats and data).</div> </div> </div> </div> </blockquote> </span> Thanks! <div> <div class="h5"><br> <br> <blockquote type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>Y.</div> <div> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <br> Thanks for any help you can provide...<span class="m_3456688468548054330HOEnZb"><font color="#888888"><br> <br> Jason.</font></span> <div> <div class="m_3456688468548054330h5"><br> <br> <blockquote type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote> <br> All 4 virtualization hosts of course had problems since there was no<br> longer any storage.<br> <br> In the end, it seems like the problem is related to XFS fragmentation...<br> <br> I read this great blog here:<br> <br> <a href="https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-deadl…" rel="noreferrer" target="_blank" moz-do-not-send="true">https://blog.codecentric.de/en<wbr>/2017/04/xfs-possible-memory-a<wbr>llocation-deadlock-kmem_alloc/</a><br> <br> In short, I tried this:<br> <br> # xfs_db -r -c "frag -f" /dev/sdb1<br> actual 4314253, ideal 43107, fragmentation factor 99.00%<br> <br> Apparently the fragmentation factor doesn't mean much, but the fact that<br> "actual" number of extents is considerably higher than "ideal" extents seems that it<br> may be the problem.<br> <br> I saw that many of my virtual disks that are written to a lot have, of course,<br> a lot of extents...<br> <br> For example, on our main web server disk image, there were 247,597<br> extents alone! I took the web server down, and ran the XFS defrag<br> command on the disk...<br> <br> # xfs_fsr -v 9a634692-1302-471f-a92e-c978b2<wbr>b67fd0<br> 9a634692-1302-471f-a92e-c978b2<wbr>b67fd0<br> extents before:247597 after:429 DONE 9a634692-1302-471f-a92e-c978b2<wbr>b67fd0<br> <br> 247,597 before and 429 after! WOW!<br> <br> Are virtual disks a problem with XFS? Why isn't this memory allocation<br> deadlock issue more prevalent. I do see this article mentioned on many<br> web posts. I don't specifically see any recommendation to *not* use<br> XFS for the data domain though.<br> <br> I was running CentOS 7.3 on the file server, but before rebooting the server,<br> I upgraded to the latest kernel and CentOS 7.4 in the hopes that if there<br> was a kernel issue, that this would solve it.<br> <br> I took a few virtual systems down, and ran the defrag on the disks. However,<br> with over 30 virtual systems, I don't really want to do this individually.<br> I was wondering if I could run xfs_fsr on all the disks LIVE? It says in the<br> manual that you can run it live, but I can't see how this would be good when<br> a system is using that disk, and I don't want to deal with major<br> corruption across the board. Any thoughts?<br> <br> Thanks,<br> <br> Jason.<br> <br> ______________________________<wbr>_________________<br> Users mailing list<br> <a href="mailto:Users@ovirt.org" target="_blank" moz-do-not-send="true">Users(a)ovirt.org</a><br> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br> </blockquote> </div> <br> </div> </div> </blockquote> <br> </div> </div> </div> </blockquote> </div> <br> </div> </div> </blockquote> <br> </div> </div> </div> </blockquote> </div> <br> </div> </div> </blockquote> <br> </body> </html> --------------8888294F2C8EF5B404842160--

1 1

libvirt: XML-RPC error : authentication failed: Failed to start SASL
by Ozan Uzun 02 Oct '17

02 Oct '17

Hello, Today I updated my ovirt engine v3.5 and all my hosts on one datacenter (centos 7.4 ones). and suddenly my vdsm and vdsm-network services stopped working. btw: My other DC is centos 6 based (managed from the same ovirt engine), everything works just fine there. vdsm fails dependent on vdsm-network service, with lots of RPC error. I tried to configure vdsm-tool configure --force, deleted everything (vdsm-libvirt), reinstalled. Could not make it work. My logs are filled with the follogin Sep 18 23:06:01 node6 python[5340]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available (default cache: KEYRING:persistent:0)) Sep 18 23:06:01 node6 vdsm-tool[5340]: libvirt: XML-RPC error : authentication failed: Failed to start SASL negotiation: -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credent Sep 18 23:06:01 node6 libvirtd[4312]: 2017-09-18 20:06:01.954+0000: 4312: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error ------- journalctl -xe output for vdsm-network Sep 18 23:06:02 node6 vdsm-tool[5340]: libvirt: XML-RPC error : authentication failed: Failed to start SASL negotiation: -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credent Sep 18 23:06:02 node6 vdsm-tool[5340]: Traceback (most recent call last): Sep 18 23:06:02 node6 vdsm-tool[5340]: File "/usr/bin/vdsm-tool", line 219, in main Sep 18 23:06:02 node6 libvirtd[4312]: 2017-09-18 20:06:02.558+0000: 4312: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error Sep 18 23:06:02 node6 vdsm-tool[5340]: return tool_command[cmd]["command"](*args) Sep 18 23:06:02 node6 vdsm-tool[5340]: File "/usr/lib/python2.7/site-packages/vdsm/tool/upgrade_300_networks.py", line 83, in upgrade_networks Sep 18 23:06:02 node6 vdsm-tool[5340]: networks = netinfo.networks() Sep 18 23:06:02 node6 vdsm-tool[5340]: File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 112, in networks Sep 18 23:06:02 node6 vdsm-tool[5340]: conn = libvirtconnection.get() Sep 18 23:06:02 node6 vdsm-tool[5340]: File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 159, in get Sep 18 23:06:02 node6 vdsm-tool[5340]: conn = _open_qemu_connection() Sep 18 23:06:02 node6 vdsm-tool[5340]: File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 95, in _open_qemu_connection Sep 18 23:06:02 node6 vdsm-tool[5340]: return utils.retry(libvirtOpen, timeout=10, sleep=0.2) Sep 18 23:06:02 node6 vdsm-tool[5340]: File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 1108, in retry Sep 18 23:06:02 node6 vdsm-tool[5340]: return func() Sep 18 23:06:02 node6 vdsm-tool[5340]: File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth Sep 18 23:06:02 node6 vdsm-tool[5340]: if ret is None:raise libvirtError('virConnectOpenAuth() failed') Sep 18 23:06:02 node6 vdsm-tool[5340]: libvirtError: authentication failed: Failed to start SASL negotiation: -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials availa Sep 18 23:06:02 node6 systemd[1]: vdsm-network.service: control process exited, code=exited status=1 Sep 18 23:06:02 node6 systemd[1]: Failed to start Virtual Desktop Server Manager network restoration. ----- libvirt is running but throws some errors. [root@node6 ~]# systemctl status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/libvirtd.service.d └─unlimited-core.conf Active: active (running) since Mon 2017-09-18 23:15:47 +03; 19min ago Docs: man:libvirtd(8) http://libvirt.org Main PID: 6125 (libvirtd) CGroup: /system.slice/libvirtd.service └─6125 /usr/sbin/libvirtd --listen Sep 18 23:15:56 node6 libvirtd[6125]: 2017-09-18 20:15:56.195+0000: 6125: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error Sep 18 23:15:56 node6 libvirtd[6125]: 2017-09-18 20:15:56.396+0000: 6125: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error Sep 18 23:15:56 node6 libvirtd[6125]: 2017-09-18 20:15:56.597+0000: 6125: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error ---------------- [root@node6 ~]# virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # list error: failed to connect to the hypervisor error: authentication failed: Failed to start SASL negotiation: -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available (default cache: KEYRING:persistent:0))) ================= I do not want to lose all my virtual servers, is there any way to recover them? Currenty everything is down. I am ok to install a new ovirt engine if somehow I can restore my virtual servers. I can also split centos 6 and centos 7 ovirt engine's.

3 6

SPM recovery after disaster
by Alexander Vrublevskiy 02 Oct '17

02 Oct '17

----ALT--hRuoHjf2JJIXx0JHEsfbvIkF0yxhgbcB1506953449 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CkhlbGxvIENvbW11bml0eSEKUmVjZW50bHkgd2UgaGFkIGEgZGlzYXN0ZXIgd2l0aCBvdXIgb1Zp cnQgNC4xIHRocmVlIG5vZGVzIGNsdXN0ZXIgCndpdGggSEUgYW5kIEdsdXN0ZXJGUyAoUkY9Mykg c3RvcmFnZSBkb21haW4uIFdlJ3ZlIG1vdmVkIG9uZSBub2RlIHRvIAptYWludGVuYW5jZSBhbmQg ZHVyaW5nIGFjdHVhbCBtYWludGVuYW5jZSBvbmUgb2Ygd29ya2luZyBub2RlcyB3aXRoIFNQTSAK cm9sZSB3ZW50IGRvd24uIEl0IHdhcyBoYXJkd2FyZSBmYWlsdXJlIHNvIHdlIGhhZCB0byByZW1v dmUgaXQgZnJvbSB0aGUgCmNsdXN0ZXIuCkFmdGVyIHRpbmtlcmluZyBhcm91bmQgbm93IHdlIGhh dmUgYWxtb3N0IHdvcmtpbmcgY2x1c3RlciB3aXRoIHR3byAKbm9kZXMgYW5kIHdpdGggR2x1c3Rl ckZTIFJGPTIuIEJ1dCB0aGUgcHJvYmxlbSBpcyBvVmlydCBjYW4ndCBmaW5kIFNQTSAKYW5kIHNw YW1pbmcgd2ViIGludGVyZmFjZSBsb2dzIHdpdGggIkhTTUdldEFsbFRhc2tzU3RhdHVzZXNWRFMg ZmFpbGVkOiAKTm90IFNQTSIgZXJyb3IuCkFmdGVyIHNvbWUgdGltZSBvZiBvcGVyYXRpbmcgd2l0 aCBzdGF0ZWQgY29uZmlndXJhdGlvbiB3ZSBsb3N0IGNvbnRlbnRzIG9mIGRvbV9tZCBzb21laG93 LgpMb29rcyBsaWtlIHRoZXNlIHR3byBwcm9ibGVtcyBhcmUgcmVsYXRlZCBhbmQgc2Vjb25kIG9u ZSBpcyBhIGNvbnNlcXVlbmNlIG9mIHRoZSBmaXJzdC4KUGxlYXNlIHN1Z2dlc3QgaG93IHRvIHJl Y292ZXIgU1BNIGFuZCBkb21fbWQuIElzIHRoZXJlIGEgd2F5IHRvIHJlY3JlYXRlIGJvdGg/ClRJ QQpSZWdhcmRzCkFsZXg= ----ALT--hRuoHjf2JJIXx0JHEsfbvIkF0yxhgbcB1506953449 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPjxkaXYgY2xhc3M9InBvc3QtdGV4dCIgaXRlbXByb3A9InRleHQiPgoKPHA+ SGVsbG8gQ29tbXVuaXR5ITxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9wPjxwPlJlY2VudGx5IHdl IGhhZCBhIGRpc2FzdGVyIHdpdGggb3VyIG9WaXJ0IDQuMSB0aHJlZSBub2RlcyBjbHVzdGVyIAp3 aXRoIEhFIGFuZCBHbHVzdGVyRlMgKFJGPTMpIHN0b3JhZ2UgZG9tYWluLiBXZSd2ZSBtb3ZlZCBv bmUgbm9kZSB0byAKbWFpbnRlbmFuY2UgYW5kIGR1cmluZyBhY3R1YWwgbWFpbnRlbmFuY2Ugb25l IG9mIHdvcmtpbmcgbm9kZXMgd2l0aCBTUE0gCnJvbGUgd2VudCBkb3duLiBJdCB3YXMgaGFyZHdh cmUgZmFpbHVyZSBzbyB3ZSBoYWQgdG8gcmVtb3ZlIGl0IGZyb20gdGhlIApjbHVzdGVyLjwvcD4K CjxwPkFmdGVyIHRpbmtlcmluZyBhcm91bmQgbm93IHdlIGhhdmUgYWxtb3N0IHdvcmtpbmcgY2x1 c3RlciB3aXRoIHR3byAKbm9kZXMgYW5kIHdpdGggR2x1c3RlckZTIFJGPTIuIEJ1dCB0aGUgcHJv YmxlbSBpcyBvVmlydCBjYW4ndCBmaW5kIFNQTSAKYW5kIHNwYW1pbmcgd2ViIGludGVyZmFjZSBs b2dzIHdpdGggIkhTTUdldEFsbFRhc2tzU3RhdHVzZXNWRFMgZmFpbGVkOiAKTm90IFNQTSIgZXJy b3IuPC9wPgoKPHA+QWZ0ZXIgc29tZSB0aW1lIG9mIG9wZXJhdGluZyB3aXRoIHN0YXRlZCBjb25m aWd1cmF0aW9uIHdlIGxvc3QgY29udGVudHMgb2YgZG9tX21kIHNvbWVob3cuPC9wPgoKPHA+TG9v a3MgbGlrZSB0aGVzZSB0d28gcHJvYmxlbXMgYXJlIHJlbGF0ZWQgYW5kIHNlY29uZCBvbmUgaXMg YSBjb25zZXF1ZW5jZSBvZiB0aGUgZmlyc3QuPC9wPgoKPHA+UGxlYXNlIHN1Z2dlc3QgaG93IHRv IHJlY292ZXIgU1BNIGFuZCBkb21fbWQuIElzIHRoZXJlIGEgd2F5IHRvIHJlY3JlYXRlIGJvdGg/ PC9wPgoKPHA+VElBPC9wPgoKPHA+UmVnYXJkczxicj5BbGV4PC9wPgogICAgPC9kaXY+PC9CT0RZ PjwvSFRNTD4K ----ALT--hRuoHjf2JJIXx0JHEsfbvIkF0yxhgbcB1506953449--

1 0

Having issue with external IPA
by Yan Naing Myint 02 Oct '17

02 Oct '17

Hello guys, I'm having problem with adding users from my FreeIPA server to oVirt. 1. Status of ovirt-engine-extension-aaa-ldap-setup is success with RHDS 2. I cannot add IPA users in oVirt webadmin panel 3. In oVirt web admin panel it says "Error while executing action AddUser: Internal Engine Error" What will be the problem or is it a bug? Is there any suggestion of how do it make it work? in the engine.log it says; 2017-10-01 17:30:52,436+06 ERROR [org.ovirt.engine.core.bll.aaa.AddUserCommand] (default task-113) [bf5822eb-39da-49e5-b2ab-9865f71346a3] Transaction rolled-back for command 'org.ovirt.engine.core.bll.aaa.AddUserCommand'. 2017-10-01 17:30:52,459+06 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-113) [bf5822eb-39da-49e5-b2ab-9865f71346a3] EVENT_ID: USER_FAILED_ADD_ADUSER(327), Correlation ID: bf5822eb-39da-49e5-b2ab-9865f71346a3, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Failed to add User 'mgorca' to the system. in cyberwings.local.properties ovirt.engine.extension.name = cyberwings.local ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = ../aaa/cyberwings.local.properties config.globals.baseDN.simple_baseDN = dc=cyberwings,dc=local in cyberwings.local-authn.properties ovirt.engine.extension.name = cyberwings.local-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = cyberwings.local ovirt.engine.aaa.authn.authz.plugin = cyberwings.local config.profile.file.1 = ../aaa/cyberwings.local.properties config.globals.baseDN.simple_baseDN = dc=cyberwings,dc=local -- Yan Naing Myint CEO Server & Network Engineer Cyber Wings Co., Ltd http://cyberwings.asia 09799950510

3 2

None
by Jason Keltz 02 Oct '17

02 Oct '17

Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Subject: [ovirt-users] xfs fragmentation problem caused data domain to hang X-BeenThere: users(a)ovirt.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Main users mailing list for oVirt <users.ovirt.org> List-Unsubscribe: <http://lists.ovirt.org/mailman/options/users>, <mailto:users-request@ovirt.org?subject=unsubscribe> List-Archive: <http://lists.ovirt.org/pipermail/users/> List-Post: <mailto:users@ovirt.org> List-Help: <mailto:users-request@ovirt.org?subject=help> List-Subscribe: <http://lists.ovirt.org/mailman/listinfo/users>, <mailto:users-request@ovirt.org?subject=subscribe> X-List-Received-Date: Mon, 02 Oct 2017 02:42:38 -0000 Hi. For my data domain, I have one NFS server with a large RAID filesystem (9 TB). I'm only using 2 TB of that at the moment. Today, my NFS server hung with the following error: > xfs: possible memory allocation deadlock in kmem_alloc All 4 virtualization hosts of course had problems since there was no longer any storage. In the end, it seems like the problem is related to XFS fragmentation... I read this great blog here: https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-deadl… In short, I tried this: # xfs_db -r -c "frag -f" /dev/sdb1 actual 4314253, ideal 43107, fragmentation factor 99.00% Apparently the fragmentation factor doesn't mean much, but the fact that "actual" number of extents is considerably higher than "ideal" extents seems that it may be the problem. I saw that many of my virtual disks that are written to a lot have, of course, a lot of extents... For example, on our main web server disk image, there were 247,597 extents alone! I took the web server down, and ran the XFS defrag command on the disk... # xfs_fsr -v 9a634692-1302-471f-a92e-c978b2b67fd0 9a634692-1302-471f-a92e-c978b2b67fd0 extents before:247597 after:429 DONE 9a634692-1302-471f-a92e-c978b2b67fd0 247,597 before and 429 after! WOW! Are virtual disks a problem with XFS? Why isn't this memory allocation deadlock issue more prevalent. I do see this article mentioned on many web posts. I don't specifically see any recommendation to *not* use XFS for the data domain though. I was running CentOS 7.3 on the file server, but before rebooting the server, I upgraded to the latest kernel and CentOS 7.4 in the hopes that if there was a kernel issue, that this would solve it. I took a few virtual systems down, and ran the defrag on the disks. However, with over 30 virtual systems, I don't really want to do this individually. I was wondering if I could run xfs_fsr on all the disks LIVE? It says in the manual that you can run it live, but I can't see how this would be good when a system is using that disk, and I don't want to deal with major corruption across the board. Any thoughts? Thanks, Jason.

1 0

iSCSI VLAN host connections - bond or multipath & IPv6
by Ben Bradley 01 Oct '17

01 Oct '17

Hi All I'm looking to add a new host to my oVirt lab installation. I'm going to share out some LVs from a separate box over iSCSI and will hook the new host up to that. I have 2 NICs on the storage host and 2 NICs on the new Ovirt host to dedicate to the iSCSI traffic. I also have 2 separate switches so I'm looking for redundancy here. Both iSCSI host and oVirt host plugged into both switches. If this was non-iSCSI traffic and without oVirt I would create bonded interfaces in active-backup mode and layer the VLANs on top of that. But for iSCSI traffic without oVirt involved I wouldn't bother with a bond and just use multipath. From scanning the oVirt docs it looks like there is an option to have oVirt configure iSCSI multipathing. So what's the best/most-supported option for oVirt? Manually create active-backup bonds so oVirt just sees a single storage link between host and storage? Or leave them as separate interfaces on each side and use oVirt's multipath/bonding? Also I quite like the idea of using IPv6 for the iSCSI VLAN, purely down to the fact I could use link-local addressing and not have to worry about setting up static IPv4 addresses or DHCP. Is IPv6 iSCSI supported by oVirt? Thanks, Ben

4 8

Re: [ovirt-users] 4.2 downgrade
by Yaniv Kaul 01 Oct '17

01 Oct '17

On Sep 30, 2017 8:09 AM, "Ryan Mahoney" <ryan(a)beaconhillentertainment.com> wrote: Accidentally upgraded a 4.0 environment to 4.2 (didn't realize the "master" repo was development repo). What's my chances/best way if possible to roll back to 4.0 (or 4.1 for that matter). There is no roll back to oVirt installation. That being said, I believe the Alpha quality is good. It is not feature complete and we of course have more polishing to do, but it's very usable and we will continue to ship updates to it. Let us know promptly what issues you encounter. Y. _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

3 3

DR with oVirt: no data on OVF_STORE
by Luca 'remix_tj' Lorenzetto 01 Oct '17

01 Oct '17

Hello, i'm experimenting a DR architecture that involves block storage replication from the storage side (EMC VNX 8000). Our idea is to import the replicated data storage domain on another datacenter, managed by another engine, with the option "Import Domain" and then import all the vms contained. The idea works, but we encountered an issue that we don't want to have again: we imported an SD and *no* vm were listed in the tab "VM Import". Disks were available, but no VM informations. What we did: - on storage side: split the replica between the main disk in Site A and the secondary disk Site B - on storage side: added the disk to the storage group of the "recovery" cluster - from engine UI: Imported storage domain, confirming that i want to activate even if seems to be attached to another DC - from engine UI: move out from maintenance the storage domain and click on the "VM Import" tab of the new SD. What happened: *no* vm were listed To identify better what's happening, I've found here some indications on how lvm for block storage works and I identified the command on how to find and read the OVF_STORE. Looking inside the OVF_STORE has shown why no vm were listed: it was empty (no .ovf file listed with tar tvf) So, without the possibility import vms, i did a rollback, detaching the storage domain and re-establishing the replication between the main site and the DR site. Then, after a day of replications (secondary volume is aligned every 30 minutes), i tried again and i've been able to import also vms (OVF_STORE was populated). So my question is: how to i force to have OVF_STORE to be aligned at least as frequent as the replication? I want to have the VM disks replicated to the remote site along with VM OVF informations. Is possible to have OVF_STORE informations aligned when a VM is created/edited or with a scheduled task? Is this so I/O expensive? Thank you, Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenzetto.luca(a)gmail.com>

2 1

oVirt 4.2 hosted-engine command damaged
by Julián Tete 01 Oct '17

01 Oct '17

I updated my lab environment from oVirt 4.1.x to oVirt 4.2 Alpha The hosted-engine command has been corrupted An example: hosted-engine --vm-status Traceback (most recent call last): File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/vm_status.py", line 213, in <module> if not status_checker.print_status (): File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/vm_status.py", line 110, in print_status all_host_stats = self._get_all_host_stats () File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/vm_status.py", line 75, in _get_all_host_stats all_host_stats = ha_cli.get_all_host_stats () File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 154, in get_all_host_stats return self.get_all_stats (self.StatModes.HOST) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 99, in get_all_stats stats = broker.get_stats_from_storage (service) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 147, in get_stats_from_storage for host_id, data in six.iteritems (result): File "/usr/lib/python2.7/site-packages/six.py", line 599, in iteritems return d.iteritems (** kw) AttributeError: 'NoneType' object has no attribute 'iteritems' hosted-engine --set-maintenance --mode = none Traceback (most recent call last): File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/set_maintenance.py", line 88, in <module> if not maintenance.set_mode (sys.argv [1]): File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/set_maintenance.py", line 76, in set_mode value = m_global, File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 240, in set_maintenance_mode str (value)) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 187, in set_global_md_flag all_stats = broker.get_stats_from_storage (service) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 147, in get_stats_from_storage for host_id, data in six.iteritems (result): File "/usr/lib/python2.7/site-packages/six.py", line 599, in iteritems return d.iteritems (** kw) AttributeError: 'NoneType' object has no attribute 'iteritems' hosted-engine --vm-start VM exists and its status is Up Hardware Manufacturer: HP Family: ProLiant Product Name: ProLiant BL460c Gen8 CPU Model Name: Intel (R) Xeon (R) CPU E5-2667 v2 @ 3.30GHz CPU Type: Intel SandyBridge Family CPU Sockets: 2 CPU Cores per Socket: 8 CPU Threads per Core: 2 (SMT Enabled) Software: OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: CentOS Linux 7 (Core) Kernel Version: 4.12.0 - 1.el7.elrepo.x86_64 KVM Version: 2.9.0 - 16.el7_4.5.1 LIBVIRT Version: libvirt-3.2.0-14.el7_4.3 VDSM Version: vdsm-4.20.3-95.git0813890.el7.centos SPICE Version: 0.12.8 - 2.el7.1 GlusterFS Version: glusterfs-3.12.1-2.el7 CEPH Version: librbd1-0.94.5-2.el7

2 1

Re: [ovirt-users] Engine crash, storage won't activate, hosts won't shutdown, template locked, gpu passthrough failed
by Yaniv Kaul 30 Sep '17

30 Sep '17

On Sep 30, 2017 7:50 PM, "M R" <gr8nextmail(a)gmail.com> wrote: Hello! I have been using Ovirt for last four weeks, testing and trying to get things working. I have collected here the problems I have found and this might be a bit long but help to any of these or maybe to all of them from several people would be wonderful. It's a bit difficult and inefficient to list all issues in a single post - unless you feel they are related ? Also, it'd be challenging to understand them without logs. Lastly, it's usually a good habit, when something doesn't work, solve it, rather than continue. I do suspect your issues are somehow related. Y. My version is ovirt node 4.1.5 and 4.1.6 downloaded from website latest stable release at the time. Also tested with CentOS minimal +ovirt repo. In this case, 3. is solved, but other problems persist. 1. Power off host First day after installing ovirt node, it was able to reboot and shutdown clean. No problems at all. After few days of using ovir, I have noticed that hosts are unable to shutdown. I have tested this in several different ways and come to the following conclusion. IF engine has not been started after boot, all hosts are able to shutdown clean. But if engine is started even once, none of the hosts are able to shutdown anymore. The only way to get power off is to unplug or press power button for a longer time as hard reset. I have failed to find a way to have the engine running and then shutdown host. This effects to all hosts in the cluster. 2. Glusterfs failed Every time I have booted hosts, glusterfs has failed. For some reason, it turns inactive state even if I have setup systemctl enable glusterd. Before this command it was just inactive. After this command, it will say "failed (inactive). There is still a way to get glusterfs working. I have to give command systemctl start glusterd manually and everything starts working. Why do I have to give manual commands to start glusterfs? I have used this for CentOS before and never had this problem before. Node installer is that much different from the CentOS core? 3. Epel As I said that I have used CentOS before, I would like to able to install some packets from repo. But even if I install epel-release, it won't find packets such as nano or htop. I have read about how to add epel-release to ovirt node from here: https://www.ovirt.org/release/4.1.1/#epel I have tested even manually edit repolist, but it will fail to find normal epel packets. I have setup additional exclude=collectd* as guided in the link above. This doesn't make any difference. All being said I am able to install manually packets which are downloaded with other CentOS machine and transferred with scp to ovirt node. Still, this once again needs a lot of manual input and is just a workaround for the bug. 4. Engine startup When I try to start the engine when glusterfs is up, it will say vm doesn't exist, starting up. Still, it won't startup automatically. I have to give several times command hosted-engine --vm-start. I wait for about 5minutes until I give it next time. This will take usually about 30minutes and then randomly. Completely randomly after one of the times, I give this command engine shoots up and is up in 1minute. This has happened every time I boot up. And the times that I have to give a command to start the engine, has been changing. At best it's been 3rd time at worst it has been 7th time. Calculating from there it might take from 15minutes to 35minutes to get the engine up.Nevertheless, it will eventually come up every time. If there is a way to get it up on the first try or even better, automatically up, it would be great. 5. Activate storage Once the engine is up, there has been a problem with storage. When I go to storage tab, it will show all sources red. Even if I wait for 15~20minutes, it won't get storage green itself. I have to go and press active button from main data storage. Then it will get main storage up in 2~3munutes.Sometimes it fails it once, but will definitely get main data storage up on the seconds try. And then magically at the same time all other storages instantly go green. Main storage is glusterfs and I have 3 NFS storages as well. This is only a problem when starting up and once storages are on green they stay green. Still annoying that it cannot get it done by itself. 6.Template locked I try to create a template from existing VM and it resulted in original VM going into locked state and template being locked. I have read that some other people had a similar problem and they were suggested to restart engine to see if it solves it. For me it has been now a week and several restarts of engine and hosts, but there is still one VM locked and template locked as well. This is not a big problem, but still a problem. Everything is grey and cannot delete this bugged VM or template. 7. unable to use GPU I have been trying to do GPU passthrough with my VM. First, there was a problem with qemu cmd line, but once I figure out a way to get commands, it maybe is working(?). Log shows up fine, but it still doesn't give functionality I¨m looking for. As I mentioned in the other email that I have found this: https://www.mail-archive.com/users@ovirt.org/msg40422.html . It will give right syntax in log, but still, won't fix error 43 with nvidia drivers. If anybody got this working or has ideas how to do it, would really like to know how it's done properly. I have also tested with AMD graphics cards such as vega, but as soon as drivers have installed, I will get a black screen. Even if I restart VM or hosts or both. I will only see black screen and unable to use VM at all. I might be able to live with the other six things listed above, but this one is a bit of a problem for me. My use of VMs will eventually need graphical performance and therefore I will have to get this working or find an alternative to ovirt..I have found several things that I really like in ovirt and would prefer to use it. Best regards Mikko <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Ei viruksia. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#m_1830658822099207723_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

Passing through a display port to a GUEST vm
by Alexander Witte 30 Sep '17

30 Sep '17

--_000_6DDEB273B96F45CC8FB776FCE14DD4FFbaicanadacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk91ciBzZXJ2ZXIgaGFzIDIgZGlzcGxheSBwb3J0cyBvbiBhbiBpbnRlZ3JhdGVkIGdy YXBoaWNzIGNhcmQuICBPbmUgcG9ydCBkaXNwbGF5cyB0aGUgaG9zdCBPUyAoQ2VudG9zNyB3aXRo IEtWTSBpbnN0YWxsZWQpIGFuZCB3ZSB3b3VsZCBsaWtlIHRoZSBzZWNvbmQgZGlzcGxheSBwb3J0 IHRvIGRpc3BsYXkgb25lIG9mIHRoZSBHVUVTVCBWTXMgKGEgV2luZG93cyAxMCBzZXJ2ZXIpLiAg SSB3YXMganVzdCBjdXJpb3VzIGlmIGFueW9uZSBoYWQgc2V0IHRoaXMga2luZCBvZiB0aGluZyB1 cCBiZWZvcmUgb3IgaWYgdGhpcyBpcyBldmVuIHBvc3NpYmxlIGFzIHRoZXJlIGlzIG5vdCBleHRl cm5hbCBWaWRlbyBjYXJkLiAgVGhpcyBpcyBhbGwgaW4gYW4gb1ZpcnQgZW52aXJvbm1lbnQuDQoN CklmIHRoZSBwYXNzdGhyb3VnaCBvbiB0aGUgZGlzcGxheSBwb3J0IGlzIG5vdCBwb3NzaWJsZSBJ IHdhcyB0aGlua2luZyBtYXliZSBvZiB1c2luZyBhIHVzYiB0byBoZG1pIGFkYXB0ZXIgYW5kIHBh c3NpbmcgdGhyb3VnaCB0aGUgVVNCIHBvcnQgdG8gdGhlIGd1ZXN0IFZNPw0KDQpIZXJl4oCZcyB0 aGUgc2VydmVyIHdl4oCZcmUgdXNpbmc6DQoNCmh0dHBzOi8vd3d3Lm1lbm1pY3JvLmNvbS9wcm9k dWN0cy9ib3gtcGNzL2JsNzB3Lw0KDQpJZiBhbnlvbmUgaGFzIGRvbmUgdGhpcyBvciBoYXMgYW55 IHRob3VnaHRzIGl0IHdvdWxkIGJlIGhlbHBmdWwhDQoNClRoYW5rcywNCg0KQWxleCBXaXR0ZQ0K --_000_6DDEB273B96F45CC8FB776FCE14DD4FFbaicanadacom_ Content-Type: text/html; charset="utf-8" Content-ID: <F67DA902C0572B4DBC4D4E4B308B3190(a)baicanada.local> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk91 ciBzZXJ2ZXIgaGFzIDIgZGlzcGxheSBwb3J0cyBvbiBhbiBpbnRlZ3JhdGVkIGdyYXBoaWNzIGNh cmQuICZuYnNwO09uZSBwb3J0IGRpc3BsYXlzIHRoZSBob3N0IE9TIChDZW50b3M3IHdpdGggS1ZN IGluc3RhbGxlZCkgYW5kIHdlIHdvdWxkIGxpa2UgdGhlIHNlY29uZCBkaXNwbGF5IHBvcnQgdG8g ZGlzcGxheSBvbmUgb2YgdGhlIEdVRVNUIFZNcyAoYSBXaW5kb3dzIDEwIHNlcnZlcikuICZuYnNw O0kgd2FzIGp1c3QgY3VyaW91cyBpZg0KIGFueW9uZSBoYWQgc2V0IHRoaXMga2luZCBvZiB0aGlu ZyB1cCBiZWZvcmUgb3IgaWYgdGhpcyBpcyBldmVuIHBvc3NpYmxlIGFzIHRoZXJlIGlzIG5vdCBl eHRlcm5hbCBWaWRlbyBjYXJkLiAmbmJzcDtUaGlzIGlzIGFsbCBpbiBhbiBvVmlydCBlbnZpcm9u bWVudC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPklmIHRoZSBwYXNzdGhyb3VnaCBvbiB0aGUgZGlzcGxheSBwb3J0IGlzIG5vdCBwb3Nz aWJsZSBJIHdhcyB0aGlua2luZyBtYXliZSBvZiB1c2luZyBhIHVzYiB0byBoZG1pIGFkYXB0ZXIg YW5kIHBhc3NpbmcgdGhyb3VnaCB0aGUgVVNCIHBvcnQgdG8gdGhlIGd1ZXN0IFZNPzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SGVyZeKA mXMgdGhlIHNlcnZlciB3ZeKAmXJlIHVzaW5nOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cubWVubWlj cm8uY29tL3Byb2R1Y3RzL2JveC1wY3MvYmw3MHcvIiBjbGFzcz0iIj5odHRwczovL3d3dy5tZW5t aWNyby5jb20vcHJvZHVjdHMvYm94LXBjcy9ibDcwdy88L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiBhbnlvbmUgaGFzIGRvbmUg dGhpcyBvciBoYXMgYW55IHRob3VnaHRzIGl0IHdvdWxkIGJlIGhlbHBmdWwhPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KVGhhbmtzLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQpBbGV4IFdpdHRl PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_6DDEB273B96F45CC8FB776FCE14DD4FFbaicanadacom_--

1 0

Re: [ovirt-users] Qemu prevents vm from starting up properly
by M R 30 Sep '17

30 Sep '17

Hello! I have maybe found a way to do this. I found this older email archive where similar problem was described: https://www.mail-archive.com/users@ovirt.org/msg40422.html With this -cpu arguments show up corretcly in log. But the it still won't fix nvidia problem 43, which is annoying "bug" implemented by nvidia. I have several gtx graphic cards collecting dust and would like to use them, but fail to do so... best regards Mikko On Thu, Sep 28, 2017 at 8:46 AM, Yedidyah Bar David <didi(a)redhat.com> wrote: > On Wed, Sep 27, 2017 at 8:32 PM, M R <gr8nextmail(a)gmail.com> wrote: > > Hello! > > > > Thank you very much! I had misunderstood how it was suppose to be > written in > > qemu_cmdline. There was a typo in syntax and error log revealed it. It is > > working IF I use ["-spice", "tls-ciphers=DES-CBC3-SHA"]. > > So I believe that installation is correctly done. > > > > Though, my problem still exists. > > This is what I have been trying to use for qemu_cmdline: > > ["-cpu", "kvm=off, hv_vendor_id=sometext"] > > It does not work and most likely is incorrectly written. > > You should first come up with something that works when you try it > manually, then try adapting that to the hook's syntax. > > > > > I understood that qemu commands are often exported into xml files and the > > command I'm trying to write is the following: > > > > <features> > > <hyperv> > > <vendor_id state='on' value='customvalue'/> > > </hyperv> > > <kvm> > > <hidden state='on'/> > > </kvm> > > </features> > > I guess you refer above to libvirt xml. This isn't strictly > related to qemu, although in practice most usage of libvirt > is with qemu. > > > > > How do I write this in custom properties for qemu_cmdline? > > If you have a working libvirt vm, with the options you need, > simply check how it translated your xml to qemu's command line. > You can see this either in its logs, or using ps. > > Best, > > > > > > > best regards > > > > Mikko > > > > > > > > On 27 Sep 2017 3:27 pm, "Yedidyah Bar David" <didi(a)redhat.com> wrote: > >> > >> On Wed, Sep 27, 2017 at 1:14 PM, M R <gr8nextmail(a)gmail.com> wrote: > >> > Hello! > >> > > >> > I did check logs from hosts, but didnt notice anything that would help > >> > me. I > >> > can copy paste logs later. > >> > > >> > I was not trying to get qemu crash vm. > >> > I'm trying to add new functionalities with qemu. > >> > > >> > I wasnt sure if my syntax was correct, so I copy pasted the example > >> > command > >> > for spice from that website. And it still behaves similarly. > >> > > >> > My conclusion is that qemu cmdline is setup wrong or it's not working > at > >> > all. But I dont know how to check that. > >> > >> Please check/share /var/log/libvirt/qemu/* and /var/log/vdsm/* . Thanks. > >> > >> > > >> > On 27 Sep 2017 12:32, "Yedidyah Bar David" <didi(a)redhat.com> wrote: > >> >> > >> >> On Wed, Sep 27, 2017 at 11:32 AM, M R <gr8nextmail(a)gmail.com> wrote: > >> >> > Hello! > >> >> > > >> >> > I have followed instructions in > >> >> > https://www.ovirt.org/develop/developer-guide/vdsm/hook/ > qemucmdline/ > >> >> > > >> >> > After adding any command for qemu cmdline, vm will try to start, > but > >> >> > will > >> >> > immediately shutdown. > >> >> > > >> >> > Is this a bug? > >> >> > >> >> If you intended, with the params you passed, to make qemu fail, for > >> >> whatever > >> >> reason (debugging qemu?), then it's not a bug :-) Otherwise, it is, > but > >> >> we > >> >> can't know where. > >> >> > >> >> > or is the information in the link insufficient? > >> >> > If it would be possible to confirm this and if there's a way to > fix, > >> >> > I > >> >> > would > >> >> > really like to have step by step guide of how to get this working. > >> >> > >> >> Did you check relevant logs? vdsm/libvirt? > >> >> > >> >> Best, > >> >> -- > >> >> Didi > >> > >> > >> > >> -- > >> Didi > > > > -- > Didi > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Ei viruksia. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Metrics store doc page link broken?
by Gianluca Cecchi 30 Sep '17

30 Sep '17

Hello, I was just giving an eye to what in subject here: https://www.ovirt.org/develop/release-management/features/metrics/metrics-s… But it seems that the main link to "Metrics store setup on top of openshift" Is broken... Any other point to begin to see the expected workflow for it? Thanks Gianluca

2 1

4.2 downgrade
by Ryan Mahoney 30 Sep '17

30 Sep '17

Accidentally upgraded a 4.0 environment to 4.2 (didn't realize the "master" repo was development repo). What's my chances/best way if possible to roll back to 4.0 (or 4.1 for that matter).

1 0

changing ip of host and its ovirtmgmt vlan
by Gianluca Cecchi 29 Sep '17

29 Sep '17

Hello, an host not maintained by me was modified so that its mgmt network had become ovirtmgmntZ2Z3. Originally the host had been added into engine with its hostname and not its ip and this simplifies things. So a dns entry change was done while the host was in maintenance (as far as I have understood...) The guy changed the /etc/sysconfig/netowrk-scripts/ files and apparently it was activated ok, but when host rebooted the config was reverted due to persistence of vdsm. As he had urgence for this host to become operational again, in the mean time I worked like this, having now a working host: - modified /etc/sysconfig/network/scripts files with the new required configuration - modified files under /var/lib/vdsm/persistence/netconf/nets/ eg the file ovirtmgmntZ2Z3 with its ip and vlan correct information sync then power off / power on host The host comes up good and as it had been peviously put into maintenance, it was able to be activated and power on some VMs. Can I consider this workflow ok or is there any ip/network information of the host stored into engine db or other parts on engine or hosts? I have then a question for the ovirtmgmt logical network itself, but I will open a new thread for it... Thanks in advance, Gianluca

3 5

Real Noob question- setting a static IP on host
by Alexander Witte 29 Sep '17

29 Sep '17

--_000_78BA09B27208464C8062331367F3EA13baicanadacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBpbmNyZWRpYmx5IHNvcnJ5IG92ZXIgdGhpcyBub29iIHF1ZXN0aW9uIGJ1dCBJIGFtIHJl YWxseSBiYXNoaW5nIG15IGhlYWQgdHJ5aW5nIHRvIHNpbXBseSBjaGFuZ2UgYW4gSVAgYWRkcmVz cyBvbiBhbiBPdmlydCBob3N0LiAgb1ZpcnQgd2FzIHB1c2hlZCB0byB0aGlzIGhvc3QgdGhyb3Vn aCB0aGUgc2VydmVyIHdlYiBpbnRlcmZhY2UuICBJdCBpcyBydW5uaW5nIG9uIHRvcCBvZiBDZW50 b3MgNy4NCg0KRnJvbSB0aGUgZG9jcyBpdCBzYXlzIHRvIGxvZyBpbnRvIHRoZSBob3N0IGFuZCBl ZGl0IHRoZSBpZmNmZy1vdmlydG1nbXQgZmlsZSBhbmQgSSBoYXZlIGRvbmUgYW5kIGhlcmUgYXJl IHRoZSBsYXRlc3Qgc2V0dGluZ3M6DQoNCiNHZW5lcmF0ZWQgYnkgVkRTTSB2ZXJzaW9uIDQuMTku MjgtMS5lMTcuY2VudG9zDQpERVZJQ0U6b3ZpcnRtZ210DQpUWVBFOkJyaWRnZQ0KREVMQVk9MA0K U1RQPW9mZg0KT05CT09UPXllcw0KQk9PVFBST1RPPW5vbmUNCk1UVT0xNTAwDQpERUZST1VURT15 ZXMNCk5NX0NPTlRST0xMRUQ9bm8NCklQVjZJTklUPXllcw0KSVBWNl9BVVRPQ09ORj15ZXMNCklQ QUREUj0xMC4wLjAuMjI2DQpHQVRFV0FZPTEwLjAuMC4xDQpQUkVGSVg9MTMNCkROUzE9MTAuMC4w LjkNCkROUzI9OC44LjguOA0KDQpUaGUgc2VydmVyIGNhbiByZWFjaCBldmVyeXRoaW5nIG9uIHRo ZSBuZXR3b3JrIGZpbmUuICBBbHRob3VnaCBpdCBjYW5ub3QgYmUgcmVhY2hlZCB0aHJvdWdoIHRo ZSBvVmlydCB3ZWIgaW50ZXJmYWNlIGFuZCB0aGUgaG9zdCBpcyBpbiBhIOKAnGNvbm5lY3Rpbmfi gJ0gc3RhdHVzLiAgSW4gdGhlIG9WaXJ0IHdlYiBpbnRlcmZhY2UgaWYgSSBhdHRlbXB0IHRvIGVk aXQgdGhlIE5JQyBzZXR0aW5ncyBmcm9tIERIQ1AgdG8gU3RhdGljIHRvIHJlZmxlY3QgdGhlIGNo YW5nZXMgSXZlIG1hZGUgYWJvdmUgSSBydW4gaW50byB0aGlzIGVycm9yOg0KDQoNCiAgKiAgIENh bm5vdCBzZXR1cCBOZXR3b3Jrcy4gQW5vdGhlciBTZXR1cCBOZXR3b3JrcyBvciBIb3N0IFJlZnJl c2ggcHJvY2VzcyBpbiBwcm9ncmVzcyBvbiB0aGUgaG9zdC4gUGxlYXNlIHRyeSBsYXRlci4NCg0K V2hhdCBpcyB0aGUgY29ycmVjdCBwcm9jZWR1cmUgdG8gY2hhbmdlIGEgaG9zdCBtYW5hZ2VtZW50 IElQIGZyb20gREhDUCB0byBTVEFUSUM/ICBTaG91bGQgSSBtYWtlIHRoZXNlIGNoYW5nZXMgbWFu dWFsbHkgb24gdGhlIGhvc3Qgb3IgdGhyb3VnaCB0aGUgTklDIHNldHRpbmdzIGluIHRoZSBvVmly dCB3ZWIgaW50ZXJmYWNlICh3aGVuIEkgdHJpZWQgdGhpcyBpdCBqdXN0IHNlZW1lZCB0byBoYW5n Li4pDQoNCkFueSBoZWxwIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcyEhDQoNCg0K QWxleA0KDQoNCg== --_000_78BA09B27208464C8062331367F3EA13baicanadacom_ Content-Type: text/html; charset="utf-8" Content-ID: <6FB4F688113E0C42AD7DBCD1BEC27217(a)baicanada.local> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIGFtIGlu Y3JlZGlibHkgc29ycnkgb3ZlciB0aGlzIG5vb2IgcXVlc3Rpb24gYnV0IEkgYW0gcmVhbGx5IGJh c2hpbmcgbXkgaGVhZCB0cnlpbmcgdG8gc2ltcGx5IGNoYW5nZSBhbiBJUCBhZGRyZXNzIG9uIGFu IE92aXJ0IGhvc3QuICZuYnNwO29WaXJ0IHdhcyBwdXNoZWQgdG8gdGhpcyBob3N0IHRocm91Z2gg dGhlIHNlcnZlciB3ZWIgaW50ZXJmYWNlLiAmbmJzcDtJdCBpcyBydW5uaW5nIG9uIHRvcCBvZiBD ZW50b3MgNy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkZyb20gdGhlIGRvY3MgaXQgc2F5cyB0byBsb2cgaW50byB0aGUgaG9zdCBhbmQg ZWRpdCB0aGUgaWZjZmctb3ZpcnRtZ210IGZpbGUgYW5kIEkgaGF2ZSBkb25lIGFuZCBoZXJlIGFy ZSB0aGUgbGF0ZXN0IHNldHRpbmdzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+I0dlbmVyYXRlZCBieSBWRFNNIHZlcnNpb24gNC4xOS4y OC0xLmUxNy5jZW50b3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+REVWSUNFOm92aXJ0bWdtdDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5UWVBFOkJyaWRnZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ERUxBWT0w PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNUUD1vZmY8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T05CT09U PXllczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iI2ZmMmEwZSIgY2xhc3M9IiI+ Qk9PVFBST1RPPW5vbmU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk1UVT0xNTAwPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkRFRlJPVVRFPXllczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5OTV9DT05U Uk9MTEVEPW5vPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklQVjZJTklUPXllczwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5JUFY2X0FVVE9DT05GPXllczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjb2xv cj0iI2ZmMjUxMyIgY2xhc3M9IiI+SVBBRERSPTEwLjAuMC4yMjY8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNvbG9yPSIjZmYyMDE1IiBjbGFzcz0iIj5HQVRFV0FZPTEwLjAuMC4x PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iI2ZmMWMwZCIgY2xhc3M9 IiI+UFJFRklYPTEzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ETlMxPTEwLjAuMC45PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkROUzI9OC44LjguODwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIHNlcnZlciBjYW4gcmVhY2ggZXZl cnl0aGluZyBvbiB0aGUgbmV0d29yayBmaW5lLiAmbmJzcDtBbHRob3VnaCBpdCBjYW5ub3QgYmUg cmVhY2hlZCB0aHJvdWdoIHRoZSBvVmlydCB3ZWIgaW50ZXJmYWNlIGFuZCB0aGUgaG9zdCBpcyBp biBhIOKAnGNvbm5lY3RpbmfigJ0gc3RhdHVzLiAmbmJzcDtJbiB0aGUgb1ZpcnQgd2ViIGludGVy ZmFjZSBpZiBJIGF0dGVtcHQgdG8gZWRpdCB0aGUgTklDIHNldHRpbmdzIGZyb20gREhDUCB0byBT dGF0aWMNCiB0byByZWZsZWN0IHRoZSBjaGFuZ2VzIEl2ZSBtYWRlIGFib3ZlIEkgcnVuIGludG8g dGhpcyBlcnJvcjo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHVsIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW4t dG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwcHg7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29k ZSBNUycsIEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bGkgc3R5bGU9ImJveC1zaXpp bmc6IGJvcmRlci1ib3g7IiBjbGFzcz0iIj5DYW5ub3Qgc2V0dXAgTmV0d29ya3MuIEFub3RoZXIg U2V0dXAgTmV0d29ya3Mgb3IgSG9zdCBSZWZyZXNoIHByb2Nlc3MgaW4gcHJvZ3Jlc3Mgb24gdGhl IGhvc3QuIFBsZWFzZSB0cnkgbGF0ZXIuPC9saT48L3VsPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGF0IGlzIHRoZSBjb3JyZWN0 IHByb2NlZHVyZSB0byBjaGFuZ2UgYSBob3N0IG1hbmFnZW1lbnQgSVAgZnJvbSBESENQIHRvIFNU QVRJQz8gJm5ic3A7U2hvdWxkIEkgbWFrZSB0aGVzZSBjaGFuZ2VzIG1hbnVhbGx5IG9uIHRoZSBo b3N0IG9yIHRocm91Z2ggdGhlIE5JQyBzZXR0aW5ncyBpbiB0aGUgb1ZpcnQgd2ViIGludGVyZmFj ZSAod2hlbiBJIHRyaWVkIHRoaXMgaXQganVzdCBzZWVtZWQgdG8gaGFuZy4uKTwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW55IGhlbHAg aXMgZ3JlYXRseSBhcHByZWNpYXRlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyEhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPg0KQWxleDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_78BA09B27208464C8062331367F3EA13baicanadacom_--

4 3

Host cannot connect to hosted storage domain
by Alexander Witte 29 Sep '17

29 Sep '17

--_000_99C25ABF4B9749298A9C9C8058D4162Ebaicanadacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNClF1ZXN0aW9uIGhvcGVmdWxseSBzb21lb25lIGNhbiBoZWxwIG1lIG91dCB3aXRoOg0K DQpJbiBteSBTZWxmIEhvc3RlZCBFbmdpbmUgZW52aXJvbm1lbnQsIHRoZSBsb2NhbCBzdG9yYWdl IGRvbWFpbiBEQVRBIChORlMpIHRoYXQgd2FzIGNyZWF0ZWQgd2l0aCB0aGUgc2VsZiBlbmdpbmUg aW5zdGFsbGF0aW9uIGhhcyBiZWVuIGNvbmZpZ3VyZWQgYXMgbG9jYWxob3N0Oi9zaGFyZXMNCg0K SSBzdXNwZWN0IHRoaXMgaXMgcHJldmVudGluZyBtZSBmcm9tIGFkZGluZyBhbnkgYWRkaXRpb25h bCBob3N0cyB0byB0aGUgb1ZpcnQgRGF0YWNlbnRlciBhcyBJIGFtIHJlY2VpdmluZyBhIFZEU00g ZXJyb3IgdGhhdCBJIGNhbm5vdCBtb3VudCB0aGF0IGRvbWFpbi4gIEkgdGhpbmsgc2luY2UgdGhl IGRvbWFpbiBpcyBzZXQgYXMgbG9jYWxob3N0IGl0IGNhbm5vdCBiZSByZXNvbHZlZCBjb3JyZWN0 IGJ5IGFueSBhZGRpdGlvbmFsIGhvc3RzLi4uPyAgVGhlIElTTywgRGF0YShNYXN0ZXIpIGFuZCBF WFBPUlQgZG9tYWlucyBhcmUgc2V0IGFzIEZRRE46L3NoYXJlcy9pc28gYW5kIEkgYW0gbm90IHNl ZWluZyBwcm9ibGVtcyBzcGVjaWZpYyB0byB0aGVtLg0KDQpJIGFtIGN1cmlvdXMgd2hhdCB0aGUg Y29ycmVjdCBwcm9jZWR1cmUgaXMgdG8gY2hhbmdlIHRoaXMgaG9zdGVkIGVuZ2luZSBzdG9yYWdl IGRvbWFpbiBwYXRoIGZyb20gbG9jYWxob3N0Oi9zaGFyZXMgdG8gRlFETjovc2hhcmVzID8gIEkg aGF2ZSBhdHRlbXB0ZWQgdGhpczoNCg0KMSkgUHV0IGhvc3RlZCBlbmdpbmUgaW4gR2xvYmFsIE1h aW50ZW5hbmNlIE1vZGUNCjIpIFNodXRkb3duIGhvc3RlZCBlbmdpbmUNCjMpIGVkaXQgdGhlIC9l dGMvb3ZpcnQtaG9zdGVkLWVuZ2luZS9ob3N0ZWQtZW5naW5lLmNvbmYgZmlsZSBmaWxlIGFuZCBj aGFuZ2U6DQpzdG9yYWdlPTEwLjAuMC4yMjM6L3NoYXJlcyAgIHRvDQpzdG9yYWdlPW1lbm1hc3Rl ci50cmFpbmRlbW8ubG9jYWw6L3NoYXJlcw0KNCkgUmVzdGFydCBob3N0ZWQgZW5naW5lDQoNCkFs dGhvdWdoIEnigJltIG5vdCBoYXZpbmcgYW55IGx1Y2sgcmVzdGFydGluZyB0aGUgaG9zdGVkIGVu Z2luZSBhZnRlciBhbmQgcnVubmluZyBhIGpvdXJuYWxjdGwgLXUgb24gdGhlIG92ZXJ0LWhhLWFn ZW50IHNlcnZpY2UgaXMgZ2l2aW5nIG1lIHRoaXM6DQoNClNlcCAyNyAyMDoxNzoxOSBtZW5tYXN0 ZXIudHJhaW5kZW1vLmxvY2FsIG92aXJ0LWhhLWFnZW50WzIwNTJdOiBvdmlydC1oYS1hZ2VudCBv dmlydF9ob3N0ZWRfZW5naW5lX2hhLmFnZW50LmFnZW50LkFnZW50IEVSUk9SIFRyYWNlYmFjayAo bW9zdCByZWNlbnQgY2FsbCBsYXN0KToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpbGUgIi91c3IvbGliL3B5dGhvbjIu Ny9zaXRlLXBhY2thZ2VzL292aXJ0X2hvc3RlZF9lbmdpbmVfaGEvYWdlbnQvYWdlbnQucHkiLCBs aW5lIDE5MSwgaW4gX3J1bl9hZ2VudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gYWN0aW9uKGhlKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMvb3ZpcnRfaG9zdGVk X2VuZ2luZV9oYS9hZ2VudC9hZ2VudC5weSIsIGxpbmUgNjQsIGluIGFjdGlvbl9wcm9wZXINCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcmV0dXJuIGhlLnN0YXJ0X21vbml0b3JpbmcoKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlsZSAiL3Vz ci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMvb3ZpcnRfaG9zdGVkX2VuZ2luZV9oYS9hZ2Vu dC9ob3N0ZWRfZW5naW5lLnB5IiwgbGluZSA0MDksIGluIHN0YXJ0X21vbml0b3JpbmcNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc2VsZi5faW5pdGlhbGl6ZV9zdG9yYWdlX2ltYWdlcyhmb3JjZT1UcnVlKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMvb3ZpcnRfaG9zdGVkX2Vu Z2luZV9oYS9hZ2VudC9ob3N0ZWRfZW5naW5lLnB5IiwgbGluZSA2NTEsIGluIF9pbml0aWFsaXpl X3N0b3JhZ2VfaW1hZ2VzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGltZy50ZWFyZG93bl9pbWFnZXMoKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMvb3ZpcnRfaG9zdGVkX2Vu Z2luZV9oYS9saWIvaW1hZ2UucHkiLCBsaW5lIDIxOCwgaW4gdGVhcmRvd25faW1hZ2VzDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHZvbHVtZUlEPXZvbFVVSUQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWxlICIvdXNyL2xpYi9weXRob24y Ljcvc2l0ZS1wYWNrYWdlcy92ZHNtL2pzb25ycGN2ZHNjbGkucHkiLCBsaW5lIDE1NSwgaW4gX2Nh bGxNZXRob2QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKG1ldGhvZE5hbWUsIGFyZ3MsIGUpKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV4Y2Vw dGlvbjogQXR0ZW1wdCB0byBjYWxsIGZ1bmN0aW9uOiB0ZWFyZG93bkltYWdlIHdpdGggYXJndW1l bnRzOiAoKSBlcnJvcjogJ3RlYXJkb3duSW1hZ2UnDQpTZXAgMjcgMjA6MTc6MTkgbWVubWFzdGVy LnRyYWluZGVtby5sb2NhbCBvdmlydC1oYS1hZ2VudFsyMDUyXTogb3ZpcnQtaGEtYWdlbnQgb3Zp cnRfaG9zdGVkX2VuZ2luZV9oYS5hZ2VudC5hZ2VudC5BZ2VudCBFUlJPUiBUcnlpbmcgdG8gcmVz dGFydCBhZ2VudA0KU2VwIDI3IDIwOjE3OjI0IG1lbm1hc3Rlci50cmFpbmRlbW8ubG9jYWwgb3Zp cnQtaGEtYWdlbnRbMjA1Ml06IG92aXJ0LWhhLWFnZW50IG92aXJ0X2hvc3RlZF9lbmdpbmVfaGEu YWdlbnQuYWdlbnQuQWdlbnQgRVJST1IgVG9vIG1hbnkgZXJyb3JzIG9jY3VycmVkLCBnaXZpbmcg dXAuIFBsZWFzZSByZXZpZXcgdGhlIGxvZyBhbmQgY29uc2lkZXIgZmlsaW5nDQpTZXAgMjcgMjA6 MTc6MjQgbWVubWFzdGVyLnRyYWluZGVtby5sb2NhbCBzeXN0ZW1kWzFdOiBvdmlydC1oYS1hZ2Vu dC5zZXJ2aWNlOiBtYWluIHByb2Nlc3MgZXhpdGVkLCBjb2RlPWV4aXRlZCwgc3RhdHVzPTE1Ny9u L2ENClNlcCAyNyAyMDoxNzoyNCBtZW5tYXN0ZXIudHJhaW5kZW1vLmxvY2FsIHN5c3RlbWRbMV06 IFVuaXQgb3ZpcnQtaGEtYWdlbnQuc2VydmljZSBlbnRlcmVkIGZhaWxlZCBzdGF0ZS4NClNlcCAy NyAyMDoxNzoyNCBtZW5tYXN0ZXIudHJhaW5kZW1vLmxvY2FsIHN5c3RlbWRbMV06IG92aXJ0LWhh LWFnZW50LnNlcnZpY2UgZmFpbGVkLg0KU2VwIDI3IDIwOjE3OjI1IG1lbm1hc3Rlci50cmFpbmRl bW8ubG9jYWwgc3lzdGVtZFsxXTogb3ZpcnQtaGEtYWdlbnQuc2VydmljZSBob2xkb2ZmIHRpbWUg b3Zlciwgc2NoZWR1bGluZyByZXN0YXJ0Lg0KU2VwIDI3IDIwOjE3OjI1IG1lbm1hc3Rlci50cmFp bmRlbW8ubG9jYWwgc3lzdGVtZFsxXTogU3RhcnRlZCBvVmlydCBIb3N0ZWQgRW5naW5lIEhpZ2gg QXZhaWxhYmlsaXR5IE1vbml0b3JpbmcgQWdlbnQuDQpTZXAgMjcgMjA6MTc6MjUgbWVubWFzdGVy LnRyYWluZGVtby5sb2NhbCBzeXN0ZW1kWzFdOiBTdGFydGluZyBvVmlydCBIb3N0ZWQgRW5naW5l IEhpZ2ggQXZhaWxhYmlsaXR5IE1vbml0b3JpbmcgQWdlbnQuLi4NClNlcCAyNyAyMDoxNzozNSBt ZW5tYXN0ZXIudHJhaW5kZW1vLmxvY2FsIG92aXJ0LWhhLWFnZW50WzI2MjZdOiBvdmlydC1oYS1h Z2VudCBvdmlydF9ob3N0ZWRfZW5naW5lX2hhLmxpYi5zdG9yYWdlX3NlcnZlci5TdG9yYWdlU2Vy dmVyIEVSUk9SIFRoZSBob3N0ZWQtZW5naW5lIHN0b3JhZ2UgZG9tYWluIGlzIGFscmVhZHkgbW91 bnRlZCBvbiAnL3JoZXYvZA0KU2VwIDI3IDIwOjE3OjQyIG1lbm1hc3Rlci50cmFpbmRlbW8ubG9j YWwgb3ZpcnQtaGEtYWdlbnRbMjYyNl06IG92aXJ0LWhhLWFnZW50IG92aXJ0X2hvc3RlZF9lbmdp bmVfaGEuYWdlbnQuYWdlbnQuQWdlbnQgRVJST1IgVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxs IGxhc3QpOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMv b3ZpcnRfaG9zdGVkX2VuZ2luZV9oYS9hZ2VudC9hZ2VudC5weSIsIGxpbmUgMTkxLCBpbiBfcnVu X2FnZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHJldHVybiBhY3Rpb24oaGUpDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWxlICIvdXNy L2xpYi9weXRob24yLjcvc2l0ZS1wYWNrYWdlcy9vdmlydF9ob3N0ZWRfZW5naW5lX2hhL2FnZW50 L2FnZW50LnB5IiwgbGluZSA2NCwgaW4gYWN0aW9uX3Byb3Blcg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4g aGUuc3RhcnRfbW9uaXRvcmluZygpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWxlICIvdXNyL2xpYi9weXRob24yLjcv c2l0ZS1wYWNrYWdlcy9vdmlydF9ob3N0ZWRfZW5naW5lX2hhL2FnZW50L2hvc3RlZF9lbmdpbmUu cHkiLCBsaW5lIDQwOSwgaW4gc3RhcnRfbW9uaXRvcmluZw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZWxmLl9pbml0 aWFsaXplX3N0b3JhZ2VfaW1hZ2VzKGZvcmNlPVRydWUpDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWxlICIvdXNyL2xp Yi9weXRob24yLjcvc2l0ZS1wYWNrYWdlcy9vdmlydF9ob3N0ZWRfZW5naW5lX2hhL2FnZW50L2hv c3RlZF9lbmdpbmUucHkiLCBsaW5lIDY1MSwgaW4gX2luaXRpYWxpemVfc3RvcmFnZV9pbWFnZXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW1nLnRlYXJkb3duX2ltYWdlcygpDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWxlICIvdXNyL2xp Yi9weXRob24yLjcvc2l0ZS1wYWNrYWdlcy9vdmlydF9ob3N0ZWRfZW5naW5lX2hhL2xpYi9pbWFn ZS5weSIsIGxpbmUgMjE4LCBpbiB0ZWFyZG93bl9pbWFnZXMNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm9sdW1lSUQ9 dm9sVVVJRCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEZpbGUgIi91c3IvbGliL3B5dGhvbjIuNy9zaXRlLXBhY2thZ2Vz L3Zkc20vanNvbnJwY3Zkc2NsaS5weSIsIGxpbmUgMTU1LCBpbiBfY2FsbE1ldGhvZA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAobWV0aG9kTmFtZSwgYXJncywgZSkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXhjZXB0aW9uOiBBdHRlbXB0IHRv IGNhbGwgZnVuY3Rpb246IHRlYXJkb3duSW1hZ2Ugd2l0aCBhcmd1bWVudHM6ICgpIGVycm9yOiAn dGVhcmRvd25JbWFnZScNClNlcCAyNyAyMDoxNzo0MiBtZW5tYXN0ZXIudHJhaW5kZW1vLmxvY2Fs IG92aXJ0LWhhLWFnZW50WzI2MjZdOiBvdmlydC1oYS1hZ2VudCBvdmlydF9ob3N0ZWRfZW5naW5l X2hhLmFnZW50LmFnZW50LkFnZW50IEVSUk9SIFRyeWluZyB0byByZXN0YXJ0IGFnZW50DQoNCg0K DQpBbnkgdGhvdWdodHM/ICBJIGNhbiBhdHRhY2ggbW9yZSBsb2dzIHRvbW9ycm93IG9yIHByb3Zp ZGUgZnVydGhlciBpbmZvcm1hdGlvbiBpZiBuZWVkZWQuDQoNClRoYW5rcyEhDQoNCg0KQWxleCBX aXR0ZQ0KDQoNCg0KDQo= --_000_99C25ABF4B9749298A9C9C8058D4162Ebaicanadacom_ Content-Type: text/html; charset="utf-8" Content-ID: <E38B5B8741CD7B4C8D310DCB50FCB58B(a)baicanada.local> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSE8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlF1 ZXN0aW9uIGhvcGVmdWxseSBzb21lb25lIGNhbiBoZWxwIG1lIG91dCB3aXRoOjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gbXkgU2Vs ZiBIb3N0ZWQgRW5naW5lIGVudmlyb25tZW50LCB0aGUgbG9jYWwgc3RvcmFnZSBkb21haW4gREFU QSAoTkZTKSB0aGF0IHdhcyBjcmVhdGVkIHdpdGggdGhlIHNlbGYgZW5naW5lIGluc3RhbGxhdGlv biBoYXMgYmVlbiBjb25maWd1cmVkIGFzIGxvY2FsaG9zdDovc2hhcmVzPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIDxiIGNsYXNzPSIi PnN1c3BlY3Q8L2I+IHRoaXMgaXMgcHJldmVudGluZyBtZSBmcm9tIGFkZGluZyBhbnkgYWRkaXRp b25hbCBob3N0cyB0byB0aGUgb1ZpcnQgRGF0YWNlbnRlciBhcyBJIGFtIHJlY2VpdmluZyBhIFZE U00gZXJyb3IgdGhhdCBJIGNhbm5vdCBtb3VudCB0aGF0IGRvbWFpbi4gJm5ic3A7SSB0aGluayBz aW5jZSB0aGUgZG9tYWluIGlzIHNldCBhcyBsb2NhbGhvc3QgaXQgY2Fubm90IGJlIHJlc29sdmVk IGNvcnJlY3QNCiBieSBhbnkgYWRkaXRpb25hbCBob3N0cy4uLj8gJm5ic3A7VGhlIElTTywgRGF0 YShNYXN0ZXIpIGFuZCBFWFBPUlQgZG9tYWlucyBhcmUgc2V0IGFzIEZRRE46L3NoYXJlcy9pc28g YW5kIEkgYW0gbm90IHNlZWluZyBwcm9ibGVtcyBzcGVjaWZpYyB0byB0aGVtLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBhbSBjdXJp b3VzIHdoYXQgdGhlIGNvcnJlY3QgcHJvY2VkdXJlIGlzIHRvIGNoYW5nZSB0aGlzIGhvc3RlZCBl bmdpbmUgc3RvcmFnZSBkb21haW4gcGF0aCBmcm9tDQo8aSBjbGFzcz0iIj5sb2NhbGhvc3Q6L3No YXJlczwvaT4gdG8gPGkgY2xhc3M9IiI+RlFETjovc2hhcmVzPC9pPiA/ICZuYnNwO0kgaGF2ZSBh dHRlbXB0ZWQgdGhpczo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjEpIFB1dCBob3N0ZWQgZW5naW5lIGluIEdsb2JhbCBNYWludGVuYW5j ZSBNb2RlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjIpIFNodXRkb3duIGhvc3RlZCBlbmdpbmU8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+MykgZWRpdCB0aGUgLzxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDY5 LCA2OSwgNjkpOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiIGNsYXNzPSIiPmV0Yy9v dmlydC1ob3N0ZWQtZW5naW5lL2hvc3RlZC1lbmdpbmUuY29uZiBmaWxlIGZpbGUgYW5kIGNoYW5n ZTo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDY5 LCA2OSwgNjkpOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiIGNsYXNzPSIiPjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgZm9udC1mYW1pbHk6ICdI ZWx2ZXRpY2EgTmV1ZSc7IiBjbGFzcz0iIj5zdG9yYWdlPTEwLjAuMC4yMjM6L3NoYXJlcw0KICZu YnNwOyB0bzwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoNjksIDY5LCA2OSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyIgY2xhc3M9IiI+ PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyBmb250LWZhbWls eTogJ0hlbHZldGljYSBOZXVlJzsiIGNsYXNzPSIiPnN0b3JhZ2U9bWVubWFzdGVyLnRyYWluZGVt by5sb2NhbDovc2hhcmVzPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjb2xvcj0i IzQ1NDU0NSIgZmFjZT0iSGVsdmV0aWNhIE5ldWUiIGNsYXNzPSIiPjQpIFJlc3RhcnQgaG9zdGVk IGVuZ2luZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY29sb3I9IiM0NTQ1NDUi IGZhY2U9IkhlbHZldGljYSBOZXVlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNvbG9yPSIjNDU0NTQ1IiBmYWNlPSJIZWx2ZXRpY2Eg TmV1ZSIgY2xhc3M9IiI+QWx0aG91Z2ggSeKAmW0gbm90IGhhdmluZyBhbnkgbHVjayByZXN0YXJ0 aW5nIHRoZSBob3N0ZWQgZW5naW5lIGFmdGVyIGFuZCBydW5uaW5nIGEgam91cm5hbGN0bCAtdSBv biB0aGUmbmJzcDtvdmVydC1oYS1hZ2VudCBzZXJ2aWNlIGlzIGdpdmluZyBtZSB0aGlzOjwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY29sb3I9IiM0NTQ1NDUiIGZhY2U9IkhlbHZl dGljYSBOZXVlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xh c3M9IiI+DQpTZXAgMjcgMjA6MTc6MTkgbWVubWFzdGVyLnRyYWluZGVtby5sb2NhbCBvdmlydC1o YS1hZ2VudFsyMDUyXTogb3ZpcnQtaGEtYWdlbnQgb3ZpcnRfaG9zdGVkX2VuZ2luZV9oYS5hZ2Vu dC5hZ2VudC5BZ2VudCBFUlJPUiBUcmFjZWJhY2sgKG1vc3QgcmVjZW50IGNhbGwgbGFzdCk6PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEZpbGUgJnF1b3Q7L3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMvb3ZpcnRf aG9zdGVkX2VuZ2luZV9oYS9hZ2VudC9hZ2VudC5weSZxdW90OywgbGluZSAxOTEsIGluIF9ydW5f YWdlbnQ8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsi IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJldHVybiBhY3Rpb24oaGUpPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRp Y2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGUgJnF1 b3Q7L3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMvb3ZpcnRfaG9zdGVkX2VuZ2luZV9o YS9hZ2VudC9hZ2VudC5weSZxdW90OywgbGluZSA2NCwgaW4gYWN0aW9uX3Byb3BlcjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgcmV0dXJuIGhlLnN0YXJ0X21vbml0b3JpbmcoKTwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNh IE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlICZxdW90 Oy91c3IvbGliL3B5dGhvbjIuNy9zaXRlLXBhY2thZ2VzL292aXJ0X2hvc3RlZF9lbmdpbmVfaGEv YWdlbnQvaG9zdGVkX2VuZ2luZS5weSZxdW90OywgbGluZSA0MDksIGluIHN0YXJ0X21vbml0b3Jp bmc8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHNlbGYuX2luaXRpYWxpemVfc3RvcmFnZV9pbWFnZXMoZm9yY2U9 VHJ1ZSk8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsi IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRmlsZSAmcXVvdDsvdXNyL2xpYi9weXRob24yLjcvc2l0ZS1wYWNrYWdl cy9vdmlydF9ob3N0ZWRfZW5naW5lX2hhL2FnZW50L2hvc3RlZF9lbmdpbmUucHkmcXVvdDssIGxp bmUgNjUxLCBpbiBfaW5pdGlhbGl6ZV9zdG9yYWdlX2ltYWdlczwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNh IE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW1n LnRlYXJkb3duX2ltYWdlcygpPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2Io NjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGUgJnF1b3Q7L3Vzci9saWIvcHl0aG9uMi43 L3NpdGUtcGFja2FnZXMvb3ZpcnRfaG9zdGVkX2VuZ2luZV9oYS9saWIvaW1hZ2UucHkmcXVvdDss IGxpbmUgMjE4LCBpbiB0ZWFyZG93bl9pbWFnZXM8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsg Y29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHZvbHVtZUlEPXZv bFVVSUQsPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7 IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEZpbGUgJnF1b3Q7L3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2Fn ZXMvdmRzbS9qc29ucnBjdmRzY2xpLnB5JnF1b3Q7LCBsaW5lIDE1NSwgaW4gX2NhbGxNZXRob2Q8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IChtZXRob2ROYW1lLCBhcmdzLCBlKSk8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGlj YSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBFeGNlcHRpb246IEF0dGVt cHQgdG8gY2FsbCBmdW5jdGlvbjogdGVhcmRvd25JbWFnZSB3aXRoIGFyZ3VtZW50czogKCkgZXJy b3I6ICd0ZWFyZG93bkltYWdlJzwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdi KDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQpTZXAgMjcgMjA6MTc6MTkgbWVubWFzdGVyLnRyYWlu ZGVtby5sb2NhbCBvdmlydC1oYS1hZ2VudFsyMDUyXTogb3ZpcnQtaGEtYWdlbnQgb3ZpcnRfaG9z dGVkX2VuZ2luZV9oYS5hZ2VudC5hZ2VudC5BZ2VudCBFUlJPUiBUcnlpbmcgdG8gcmVzdGFydCBh Z2VudDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIg Y2xhc3M9IiI+DQpTZXAgMjcgMjA6MTc6MjQgbWVubWFzdGVyLnRyYWluZGVtby5sb2NhbCBvdmly dC1oYS1hZ2VudFsyMDUyXTogb3ZpcnQtaGEtYWdlbnQgb3ZpcnRfaG9zdGVkX2VuZ2luZV9oYS5h Z2VudC5hZ2VudC5BZ2VudCBFUlJPUiBUb28gbWFueSBlcnJvcnMgb2NjdXJyZWQsIGdpdmluZyB1 cC4gUGxlYXNlIHJldmlldyB0aGUgbG9nIGFuZCBjb25zaWRlciBmaWxpbmc8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hl bHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KU2VwIDI3 IDIwOjE3OjI0IG1lbm1hc3Rlci50cmFpbmRlbW8ubG9jYWwgc3lzdGVtZFsxXTogb3ZpcnQtaGEt YWdlbnQuc2VydmljZTogbWFpbiBwcm9jZXNzIGV4aXRlZCwgY29kZT1leGl0ZWQsIHN0YXR1cz0x NTcvbi9hPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7 IiBjbGFzcz0iIj4NClNlcCAyNyAyMDoxNzoyNCBtZW5tYXN0ZXIudHJhaW5kZW1vLmxvY2FsIHN5 c3RlbWRbMV06IFVuaXQgb3ZpcnQtaGEtYWdlbnQuc2VydmljZSBlbnRlcmVkIGZhaWxlZCBzdGF0 ZS48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNs YXNzPSIiPg0KU2VwIDI3IDIwOjE3OjI0IG1lbm1hc3Rlci50cmFpbmRlbW8ubG9jYWwgc3lzdGVt ZFsxXTogb3ZpcnQtaGEtYWdlbnQuc2VydmljZSBmYWlsZWQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2Eg TmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NClNlcCAyNyAyMDoxNzoy NSBtZW5tYXN0ZXIudHJhaW5kZW1vLmxvY2FsIHN5c3RlbWRbMV06IG92aXJ0LWhhLWFnZW50LnNl cnZpY2UgaG9sZG9mZiB0aW1lIG92ZXIsIHNjaGVkdWxpbmcgcmVzdGFydC48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hl bHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KU2VwIDI3 IDIwOjE3OjI1IG1lbm1hc3Rlci50cmFpbmRlbW8ubG9jYWwgc3lzdGVtZFsxXTogU3RhcnRlZCBv VmlydCBIb3N0ZWQgRW5naW5lIEhpZ2ggQXZhaWxhYmlsaXR5IE1vbml0b3JpbmcgQWdlbnQuPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0i Ij4NClNlcCAyNyAyMDoxNzoyNSBtZW5tYXN0ZXIudHJhaW5kZW1vLmxvY2FsIHN5c3RlbWRbMV06 IFN0YXJ0aW5nIG9WaXJ0IEhvc3RlZCBFbmdpbmUgSGlnaCBBdmFpbGFiaWxpdHkgTW9uaXRvcmlu ZyBBZ2VudC4uLjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwg NjkpOyIgY2xhc3M9IiI+DQpTZXAgMjcgMjA6MTc6MzUgbWVubWFzdGVyLnRyYWluZGVtby5sb2Nh bCBvdmlydC1oYS1hZ2VudFsyNjI2XTogb3ZpcnQtaGEtYWdlbnQgb3ZpcnRfaG9zdGVkX2VuZ2lu ZV9oYS5saWIuc3RvcmFnZV9zZXJ2ZXIuU3RvcmFnZVNlcnZlciBFUlJPUiBUaGUgaG9zdGVkLWVu Z2luZSBzdG9yYWdlIGRvbWFpbiBpcyBhbHJlYWR5IG1vdW50ZWQgb24gJy9yaGV2L2Q8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0K U2VwIDI3IDIwOjE3OjQyIG1lbm1hc3Rlci50cmFpbmRlbW8ubG9jYWwgb3ZpcnQtaGEtYWdlbnRb MjYyNl06IG92aXJ0LWhhLWFnZW50IG92aXJ0X2hvc3RlZF9lbmdpbmVfaGEuYWdlbnQuYWdlbnQu QWdlbnQgRVJST1IgVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAn SGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBG aWxlICZxdW90Oy91c3IvbGliL3B5dGhvbjIuNy9zaXRlLXBhY2thZ2VzL292aXJ0X2hvc3RlZF9l bmdpbmVfaGEvYWdlbnQvYWdlbnQucHkmcXVvdDssIGxpbmUgMTkxLCBpbiBfcnVuX2FnZW50PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyByZXR1cm4gYWN0aW9uKGhlKTwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUn OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlICZxdW90Oy91c3Iv bGliL3B5dGhvbjIuNy9zaXRlLXBhY2thZ2VzL292aXJ0X2hvc3RlZF9lbmdpbmVfaGEvYWdlbnQv YWdlbnQucHkmcXVvdDssIGxpbmUgNjQsIGluIGFjdGlvbl9wcm9wZXI8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZl dGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHJldHVybiBoZS5zdGFydF9tb25pdG9yaW5nKCk8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsg Y29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZSAmcXVvdDsvdXNyL2xp Yi9weXRob24yLjcvc2l0ZS1wYWNrYWdlcy9vdmlydF9ob3N0ZWRfZW5naW5lX2hhL2FnZW50L2hv c3RlZF9lbmdpbmUucHkmcXVvdDssIGxpbmUgNDA5LCBpbiBzdGFydF9tb25pdG9yaW5nPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBzZWxmLl9pbml0aWFsaXplX3N0b3JhZ2VfaW1hZ2VzKGZvcmNlPVRydWUpPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEZpbGUgJnF1b3Q7L3Vzci9saWIvcHl0aG9uMi43L3NpdGUtcGFja2FnZXMvb3ZpcnRf aG9zdGVkX2VuZ2luZV9oYS9hZ2VudC9ob3N0ZWRfZW5naW5lLnB5JnF1b3Q7LCBsaW5lIDY1MSwg aW4gX2luaXRpYWxpemVfc3RvcmFnZV9pbWFnZXM8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsg Y29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGltZy50ZWFyZG93 bl9pbWFnZXMoKTwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwg NjkpOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlICZxdW90Oy91c3IvbGliL3B5dGhvbjIuNy9zaXRlLXBh Y2thZ2VzL292aXJ0X2hvc3RlZF9lbmdpbmVfaGEvbGliL2ltYWdlLnB5JnF1b3Q7LCBsaW5lIDIx OCwgaW4gdGVhcmRvd25faW1hZ2VzPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiBy Z2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2b2x1bWVJRD12b2xVVUlELDwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBGaWxlICZxdW90Oy91c3IvbGliL3B5dGhvbjIuNy9zaXRlLXBhY2thZ2VzL3Zkc20v anNvbnJwY3Zkc2NsaS5weSZxdW90OywgbGluZSAxNTUsIGluIF9jYWxsTWV0aG9kPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAobWV0aG9kTmFtZSwgYXJncywgZSkpPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7 IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRXhjZXB0aW9uOiBBdHRlbXB0IHRvIGNh bGwgZnVuY3Rpb246IHRlYXJkb3duSW1hZ2Ugd2l0aCBhcmd1bWVudHM6ICgpIGVycm9yOiAndGVh cmRvd25JbWFnZSc8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig2OSwgNjks IDY5KTsiIGNsYXNzPSIiPg0KU2VwIDI3IDIwOjE3OjQyIG1lbm1hc3Rlci50cmFpbmRlbW8ubG9j YWwgb3ZpcnQtaGEtYWdlbnRbMjYyNl06IG92aXJ0LWhhLWFnZW50IG92aXJ0X2hvc3RlZF9lbmdp bmVfaGEuYWdlbnQuYWdlbnQuQWdlbnQgRVJST1IgVHJ5aW5nIHRvIHJlc3RhcnQgYWdlbnQ8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbnkgdGhvdWdodHM/ICZuYnNwO0kgY2FuIGF0dGFjaCBt b3JlIGxvZ3MgdG9tb3Jyb3cgb3IgcHJvdmlkZSBmdXJ0aGVyIGluZm9ybWF0aW9uIGlmIG5lZWRl ZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoYW5rcyEhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KQWxleCBXaXR0 ZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_99C25ABF4B9749298A9C9C8058D4162Ebaicanadacom_--

2 4