June 2015 - Users - oVirt List Archives

Just for info: ovirt-guest-agent on Debian 8 Jessie is buggy.
by Arman Khalatyan 16 Jun '15

16 Jun '15

The current debian has an bug the python script does not have exec flag so daemon shows as running but it does nothing. to fix it simply: chmod +x /usr/share/ovirt-guest-agent/ovirt-guest-agent.py systemctl restart ovirt-guest-agent *********************************************************** Dr. Arman Khalatyan eScience -SuperComputing Leibniz-Institut für Astrophysik Potsdam (AIP) An der Sternwarte 16, 14482 Potsdam, Germany ***********************************************************

2 1

Re: [ovirt-users] DWH remove
by Yedidyah Bar David 16 Jun '15

16 Jun '15

----- Original Message ----- > From: "Michael Wagenknecht" <wagenknecht(a)fuh-e.de> > To: "Yedidyah Bar David" <didi(a)redhat.com> > Sent: Tuesday, June 16, 2015 8:58:47 AM > Subject: Re: [ovirt-users] DWH remove > > Hi Didi, > thank you very much for the quick response. > A small report from my side: After doing your instructions I get some > error messages from engine-backup. > I have to remove the folders /var/lib/ovirt-engine-reports, > /var/lib/ovirt-engine-dwh, /etc/ovirt-engine-reports and > /etc/ovirt-engine-dwh manually. Then engine-backup works again. > Otherwise nothing has struck me. Thanks for the report! I'll update the wiki page about migration. Best, > > Best Regards, > Michael > > > Am 14.06.2015 um 07:40 schrieb Yedidyah Bar David: > > ----- Original Message ----- > >> From: "Michael Wagenknecht" <wagenknecht(a)fuh-e.de> > >> To: "Users" <users(a)ovirt.org> > >> Sent: Friday, June 12, 2015 2:15:23 PM > >> Subject: [ovirt-users] DWH remove > >> > >> Hi all, > >> how can I safely remove the DWH extension in ovirt 3.5.1? > > > > This depends on how "safely" you want this... > > > > Just stopping the services and removing the packages should be enough. > > > > I didn't verify what happens if you e.g. later try to run 'engine-cleanup' > > (How will it react when trying to remove them?) or re-install (will they > > behave as if already setup?) etc. > > > > You can/might then also remove the databases from postgres, e.g. > > > > # su - postgres > > psql > > drop database ovirt_engine_history; > > drop database ovirt_engine_reports; > > > >> Is there a howto? > > > > Not for this per-se, but [1] shows how to migrate them to another machine. > > > > We also have open bugs [2][3] to do this more cleanly, but they'll require > > some more work, and it currently does not seem they'll make it to 3.6. > > > > [1] http://www.ovirt.org/Features/Migration_of_local_DWH_Reports_to_remote > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060529 > > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1169695 > > > > Best, > > > -- Didi

1 0

Import Storage Domain 3.5 Error
by Tang Jackson 16 Jun '15

16 Jun '15

--_000_HK2PR03MB08200834250ECB842629B7DC9CBD0HK2PR03MB0820apcp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a SAN appliance with a large amount of data including VMs/Templates/= Disks mounted via NFS. When I tried to attach the storage domain to a fres= h ovirt cluster the following occurs 2015-06-10 18:35:58,739 INFO [org.ovirt.engine.core.bll.ImportVmFromConfig= urationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock Acquired to object = EngineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME , sharedLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM ] 2015-06-10 18:35:58,741 WARN [org.ovirt.engine.core.bll.ImportVmFromConfig= urationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] CanDoAction of action Im= portVmFromConfiguration failed for user admin@internal. Reasons: VAR__ACTIO= N__IMPORT,VAR__TYPE__VM,ACTION_TYPE_FAILED_STORAGE_DOMAIN_NOT_EXIST 2015-06-10 18:35:58,743 INFO [org.ovirt.engine.core.bll.ImportVmFromConfig= urationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock freed to object Eng= ineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME , sharedLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM ] The error appears on the GUI as Storage Domain does not exist. All templates are OK. Some VMs could be imported but most of them produce the error message above= . The procedure followed was http://www.ovirt.org/Features/ImportStorageDomai= n. --_000_HK2PR03MB08200834250ECB842629B7DC9CBD0HK2PR03MB0820apcp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"JA" link=3D"blue" vlink=3D"purple" style=3D"text-justify-trim= :punctuation"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">Hell= o,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">I ha= ve a SAN appliance with a large amount of data including VMs/Templates/Disk= s mounted via NFS.  When I tried to attach the storage domain to a fre= sh ovirt cluster the following occurs<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">2015= -06-10 18:35:58,739 INFO  [org.ovirt.engine.core.bll.ImportVmFromConfi= gurationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock Acquired to object= EngineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">, sh= aredLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">]<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">2015= -06-10 18:35:58,741 WARN  [org.ovirt.engine.core.bll.ImportVmFromConfi= gurationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] CanDoAction of action I= mportVmFromConfiguration failed for user admin@internal. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM,ACTION_TYPE_FAILED_STORAGE_DOMA= IN_NOT_EXIST<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">2015= -06-10 18:35:58,743 INFO  [org.ovirt.engine.core.bll.ImportVmFromConfi= gurationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock freed to object En= gineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">, sh= aredLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">]<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">The = error appears on the GUI as Storage Domain does not exist.<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">All = templates are OK.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">Some= VMs could be imported but most of them produce the error message above.<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">The = procedure followed was <a href=3D"http://www.ovirt.org/Features/ImportStorageDomain">http://www.ov= irt.org/Features/ImportStorageDomain</a>.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> </div> </body> </html> --_000_HK2PR03MB08200834250ECB842629B7DC9CBD0HK2PR03MB0820apcp_--

2 2

[ANN] oVirt 3.5.3 Second Release Candidate is now available for testing
by Sandro Bonazzola 16 Jun '15

16 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The oVirt team is pleased to announce that the 3.5.3 Second Release Candidate is now available for testing as of May 28th 2015. The release candidate is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar). This release of oVirt includes numerous bug fixes and one CVE fix for the VENOM Vulnerability. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO is already available as well[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.3_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVZrrzAAoJEHw3u57E4QAOnX4QAMFi+d4Vq5jnZ0e+LaD1vB9R GmT+k21q6vybjIvovPh7q6StCtPS0sg15BoH5JTmTfl5IWL01qMsFvw/G32PIjZI u3mm2Z3evbxPg9qsqJPyJm/jAlRHv/L6ntLJaJBDPDSO6Y0iqiHTVUQG16easW3L ZnUC2IM5TpHuU3PcgVp8zY9gqFqQWnnsA8deJXBvif9J8RdSf7DnkFha9/Ei3v0E 1btkzt0XVS3Cate8pEaTT8zSoE/tOBBS/D65HsnnZdD13RAxYkolzuPvT+7BlmUO QMhyIE7msWex048HrcDVTEDLrkYF2SpAmYix3sA2O9+AIujenpICHJ8JyxAc+BmJ scsvv99iDLU3wkpMwKiIABj7nE8gIiUbyZBNaxsxQJ0jurLZGHGIhQGLAJ2q/rd7 MTkcDXOBOZHEadqs87mSEzHt1pQCmZ40KSJCvyWbqa7vFv6kyOgOs3PldoizsOyV Z1DlDmfMM8hs/6LOP/Mr/4p/l3JgS3gbOy34L2q9J/B+BX/XU7H2bOk6GTEMVPOn av7m2kDs8DlQJzSqZAURZNt6XTnGGw05THOBWD8NmHuvlVZsSF1mxKb0BC+LpRcs QmLGAtT12Y2Wnq1xwzcRav9+wiIeEYTVJCbyohMLyqTHqPgRstpeF3JulpqILo5I rHhGapreYDlzy06Ki7X7 =pUqF -----END PGP SIGNATURE-----

2 1

Re: [ovirt-users] Adding users through LDAP fails on "external_id"
by Zach La Celle 16 Jun '15

16 Jun '15

I have tried the following combinations of certificates added to the keystore: * PositiveSSL CA bundle (SHA-1 and SHA256) -- This is the source of our SSL certificates * All CA certificates from the LDAP machine * All CA certificates from the LDAP machine plus the machine's own certificate * The machine's own certificate only None fix the issue. As I understand it, adding just the CA bundle from PositiveSSL should work. Or, adding the CA bundles offered by Ubuntu should also work. Previously (when using port 636 and TLS/SSL), to fix SSLPeerUnverifiedException, I added all of the CA certificates from the LDAP machine, plus its own certificate (this last part fixed it). In the mean time, to try and fix the original issue of "external_id", is there any way to disable certificate verification for STARTTLS? On 06/15/2015 03:57 PM, Alon Bar-Lev wrote: > You should add *ONLY* the ca certificate top level to the keystore. > > ----- Original Message ----- >> From: "Zach La Celle" <lacelle(a)roboticresearch.com> >> To: "Alon Bar-Lev" <alonbl(a)redhat.com> >> Sent: Monday, June 15, 2015 10:54:02 PM >> Subject: Re: [ovirt-users] Adding users through LDAP fails on "external_id" >> >> OK, started using the STARTTLS protocol. Tested working using >> ldapsearch, but now ovirt-engine's engine.log complains: >> >> java.io.IOException: Unable to verify an attempt to to establish a >> secure connection to 'directory.roboticresearch.com:389' becau\ >> se an unexpected error was encountered during validation processing: >> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated >> >> Not sure what is wrong. We fixed this before by adding the >> ca-certificates from the LDAP server as well as the LDAP server >> certificate into the .jks keystore. >> >> On 06/15/2015 03:21 PM, Alon Bar-Lev wrote: >>> ----- Original Message ----- >>>> From: "Zach La Celle" <lacelle(a)roboticresearch.com> >>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com> >>>> Sent: Monday, June 15, 2015 10:14:34 PM >>>> Subject: Re: [ovirt-users] Adding users through LDAP fails on >>>> "external_id" >>>> >>>> My mistake. We're using OpenLDAP 2.4.28-1.1ubuntu4.4 on Ubuntu 12.04. >>>> >>>> The full configuration files are as follows (I removed commented-out >>>> lines for brevity). Communications with the LDAP server seem to work >>>> correctly now. >>>> >>>> __profile1.properties__ >>>> >>>> # >>>> >>>> # Select >>>> one >>>> >>>> # >>>> >>>> include = <openldap.properties> >>> reading bellow, you may want to try rfc2307-openldap as your schema seems >>> to be rfc2307 compatible. >>> >>> <snip> >>> >>>> pool.default.serverset.type = single >>>> pool.default.serverset.single.server = ${global:vars.server} >>>> pool.default.serverset.single.port = 636 >>> why do you modify port? please use startTLS on default port. >>> >>>> #pool.default.auth.simple.bindDN = ${global:vars.user} >>>> #pool.default.auth.simple.password = ${global:vars.password} >>> why did you comment this, do you allow anonymous access? >>> >>>> # Create keystore, import certificate chain and uncomment >>>> # if using ssl/tls. >>>> #pool.default.ssl.startTLS = true >>> please uncomment this^ >>> >>>> pool.default.ssl.truststore.file = >>>> ${local:_basedir}/${global:vars.server}.jks >>>> pool.default.ssl.truststore.password = sdfnliwneponalsdinosaivnewal >>>> >>>> # TLS settings and authentication >>>> pool.default.ssl.enable = true >>> please do not use ssl unless startTLS is not supported, and it is in >>> openldap. >>> >>>> pool.default.ssl.startTLS = false >>> please set this to true. >>> >>>> pool.default.ssl.host-name-verify.enable = true >>>> pool.default.ssl.host-name-verify.wildcards = false >>>> pool.default.ssl.insecure = false >>>> pool.default.ssl.protocol = TLSv1 >>>> #pool.default.ssl.startTLSProtocol = TLSv1 >>> these are the default, you do not need to add these. >>> >>>> pool.default.auth.type = none >>> why have you set this explicitly? >>> >>>> # Mapping >>>> attrmap.map-principal-record.attr.PrincipalRecord_DISPLAY_NAME.map = cn >>>> attrmap.map-principal-record.attr.PrincipalRecord_EMAIL.map = Email >>>> attrmap.map-group-record.attr.GroupRecord_DISPLAY_NAME.map = cn >>> please remove mapping, it should work without. >>> >>>> # Variables >>>> sequence.openldap-init-vars.030.var-set.value = entryUUID, uid, cn, >>>> givenName, sn, Email >>>> sequence.openldap-init-vars.040.var-set.value = >>>> (objectClass=posixAccount)(uid=*) >>>> sequence.openldap-init-vars.050.var-set.value = entryUUID, cn >>>> sequence.openldap-init-vars.060.var-set.value = (objectClass=posixGroup) >>>> sequence.openldap-init-vars.070.var-set.value = memberUid >>> why have you added these? maybe you have rfc2307 compatible schema? >>> >>>> On 06/15/2015 03:07 PM, Alon Bar-Lev wrote: >>>>> This probably state that you do not use the correct driver. >>>>> >>>>> You did not mention what LDAP server do you use, and you pasted only >>>>> partial profile. >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Zach La Celle" <lacelle(a)roboticresearch.com> >>>>>> To: users(a)ovirt.org >>>>>> Sent: Monday, June 15, 2015 10:04:47 PM >>>>>> Subject: [ovirt-users] Adding users through LDAP fails on "external_id" >>>>>> >>>>>> Hello, >>>>>> >>>>>> We have a small oVirt cluster set up, and are trying to get it >>>>>> integrated with our LDAP server. >>>>>> >>>>>> I've changed some configuration values in order to try and make it >>>>>> function, and it seems to communicate correctly with the LDAP server. >>>>>> However, when trying to add the user, I get the following error upon SQL >>>>>> entry add: >>>>>> >>>>>> 2015-06-15 14:44:49,439 ERROR >>>>>> [org.ovirt.engine.core.bll.aaa.AddUserCommand] (ajp--127.0.0.1-8702-6) >>>>>> [3b15cbfe] Command org.ovirt.engine.core.bll.aaa.AddUserCommand throw >>>>>> exception: org.springframework.da\ >>>>>> o.DataIntegrityViolationException: CallableStatementCallback; SQL [{call >>>>>> insertuser(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: null >>>>>> value in column "external_id" violates not-null constraint >>>>>> Where: SQL statement "INSERT INTO users(department, domain, email, >>>>>> groups, name, note, role, active, surname, user_id, username, group_ids, >>>>>> external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ >>>>>> 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" >>>>>> PL/pgSQL function "insertuser" line 2 at SQL statement; nested exception >>>>>> is org.postgresql.util.PSQLException: ERROR: null value in column >>>>>> "external_id" violates not-null constraint >>>>>> Where: SQL statement "INSERT INTO users(department, domain, email, >>>>>> groups, name, note, role, active, surname, user_id, username, group_ids, >>>>>> external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ >>>>>> 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" >>>>>> >>>>>> I can't figure out what maps from the LDAP user to "external_id" for the >>>>>> SQL table entry. >>>>>> >>>>>> Here are the changes I made to profile1.properties: >>>>>> >>>>>> #Mapping changes >>>>>> attrmap.map-principal-record.attr.PrincipalRecord_DISPLAY_NAME.map = cn >>>>>> attrmap.map-principal-record.attr.PrincipalRecord_EMAIL.map = Email >>>>>> attrmap.map-group-record.attr.GroupRecord_DISPLAY_NAME.map = cn >>>>>> >>>>>> #LDAP value changes >>>>>> sequence.openldap-init-vars.030.var-set.value = entryUUID, uid, cn, >>>>>> givenName, sn, Email >>>>>> sequence.openldap-init-vars.040.var-set.value = >>>>>> (objectClass=posixAccount)(uid=*) >>>>>> sequence.openldap-init-vars.050.var-set.value = entryUUID, cn >>>>>> sequence.openldap-init-vars.060.var-set.value = (objectClass=posixGroup) >>>>>> sequence.openldap-init-vars.070.var-set.value = memberUid >>>>>> >>>>>> Any help is appreciated! >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>

2 3

Adding users through LDAP fails on "external_id"
by Zach La Celle 15 Jun '15

15 Jun '15

Hello, We have a small oVirt cluster set up, and are trying to get it integrated with our LDAP server. I've changed some configuration values in order to try and make it function, and it seems to communicate correctly with the LDAP server. However, when trying to add the user, I get the following error upon SQL entry add: 2015-06-15 14:44:49,439 ERROR [org.ovirt.engine.core.bll.aaa.AddUserCommand] (ajp--127.0.0.1-8702-6) [3b15cbfe] Command org.ovirt.engine.core.bll.aaa.AddUserCommand throw exception: org.springframework.da\ o.DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertuser(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: null value in column "external_id" violates not-null constraint Where: SQL statement "INSERT INTO users(department, domain, email, groups, name, note, role, active, surname, user_id, username, group_ids, external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" PL/pgSQL function "insertuser" line 2 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: null value in column "external_id" violates not-null constraint Where: SQL statement "INSERT INTO users(department, domain, email, groups, name, note, role, active, surname, user_id, username, group_ids, external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" I can't figure out what maps from the LDAP user to "external_id" for the SQL table entry. Here are the changes I made to profile1.properties: #Mapping changes attrmap.map-principal-record.attr.PrincipalRecord_DISPLAY_NAME.map = cn attrmap.map-principal-record.attr.PrincipalRecord_EMAIL.map = Email attrmap.map-group-record.attr.GroupRecord_DISPLAY_NAME.map = cn #LDAP value changes sequence.openldap-init-vars.030.var-set.value = entryUUID, uid, cn, givenName, sn, Email sequence.openldap-init-vars.040.var-set.value = (objectClass=posixAccount)(uid=*) sequence.openldap-init-vars.050.var-set.value = entryUUID, cn sequence.openldap-init-vars.060.var-set.value = (objectClass=posixGroup) sequence.openldap-init-vars.070.var-set.value = memberUid Any help is appreciated!

2 1

changelogs for upgrades in ovirt yum repo
by Tiemen Ruiten 15 Jun '15

15 Jun '15

Hello, Is there a changelog available for upgrades in the ovirt repositories? There are some upgrades available for qemu and vdsm and I have no idea whether they're urgent, security related or both. -- Tiemen Ruiten Systems Engineer R&D Media

3 3

oVirt 3.5.3 VDSM on CentOS Virt SIG
by Sandro Bonazzola 15 Jun '15

15 Jun '15

Hi, today oVirt 3.5.3 has been released[1]. VDSM 4.16.20 and its dependencies has been tagged as release as well within the Virt SIG build repositories for CentOS Linux 7. In order to enable the needed repositories you need to create /etc/yum.repos.d/centos-virt-sig.repo with the following content: [virt7-kvm-common-release] name=virt7-kvm-common-release baseurl=http://cbs.centos.org/repos/virt7-kvm-common-release/x86_64/os enabled=1 gpgcheck=0 [virt7-ovirt-common-release] name=virt7-ovirt-common-release baseurl=http://cbs.centos.org/repos/virt7-ovirt-common-release/x86_64/os enabled=1 gpgcheck=0 [virt7-ovirt-35-release] name=virt7-ovirt-35-release baseurl=http://cbs.centos.org/repos/virt7-ovirt-35-release/x86_64/os enabled=1 gpgcheck=0 An initial submission for the repository rpm has been pushed[2] and is waiting for public GPG keys to be added. [1] http://lists.ovirt.org/pipermail/announce/2015-June/000175.html [2] https://gerrit.ovirt.org/41403 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

[ANN] oVirt 3.5.3 Final Release is now available
by Sandro Bonazzola 15 Jun '15

15 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The oVirt team is pleased to announce that the oVirt 3.5.3 Final Release is now available as of June 15th 2015. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. oVirt is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS Linux 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). This release of oVirt includes numerous bug fixes and two CVE fixes. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO is already available[2] and oVirt Node ISO will be soon available as well[3]. Please note that mirrors[4] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.3_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-live/el6-3.5.3/ovirt-liv… [3] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-node/ [4] http://www.ovirt.org/Repository_mirrors#Current_mirrors - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVfoI3AAoJEHw3u57E4QAOZtcP/167LZUjWapo8ujNgW9JilAW Cmz9mWoQWzUopaFFhLkpPJV9+ngCIqiny4bgdeStNQCJ3VsbWS6gz1mFgm9M7ZGl 1y6Q5dbUrt+xRtdec+w8BbTb/UEdFPUeQ2Gxa+Z/YCJ4+ovsAX2Sgv2ZVNe6S6zR WBVy79X1oKwJDsTbXjSotl2FxWbHW/+S3+3qI5YLVkwHDhwn6uoHdaNC0xo47fUj Kw9G0VjLhQH3UHtna0QX/rw39elLf9/eVsiIiimSo8YbnQ7aqvkZw3tcOVYs/hGe s+fW+xDnU5IcD90K6JToZYfHc8xsN7KAyfAbJecgS3HVDef1jyjcfxG08cTlG73C Q+XqAZQXlAPHbjMQe8EYHYRAZcpk0EGVOaR+BXmL4x4p9sGCppTavq6W/9FlxkmK tLVz5hFC+H6pjU00T/gCQC1+N8aZSfy8kO5nbbLWdFW9/ixvkIB4SCEVDkbB0keb KphiOJZuxX5U1ZdwK0HvYcA6Z6bevCp9+wZEyi6UdNu/SjJx785USiFjBi/rmXVY h/W0u0bqkjqu6Fc/IlDA8irNhxjwDiNp7qLWba72mlqKif0UKeqBgXmFk9A34BWi bJmToIpnWyrZ5vjYyvHY+fwcnvu7EFFQb/OOnuFspoXc8aOkm6GcGZP+pgm9biN2 aPdWpfSKRDeX6nOg5LZN =5bEX -----END PGP SIGNATURE-----

1 0

DWH remove
by Michael Wagenknecht 14 Jun '15

14 Jun '15

Hi all, how can I safely remove the DWH extension in ovirt 3.5.1? Is there a howto? Best Regards, Michael

2 1

Help with a vdsm hook script script?
by Paul Jansen 12 Jun '15

12 Jun '15

------=_Part_1839633_221010509.1434090878897 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have not coded much python, but I'm having a go at trying to get a vdsm h= ook script working. What it is supposed to do is look for a controller of model 'virtio-scsi' i= n the domxml and change the model to 'ich9-ahci'.I've named the script '50_= change_scsi_controller' and have placed it in '/usr/libexec/vdsm/hooks/befo= re_vm_start' on the one (and only) host in the cluster where I'm doing this= testing.=C2=A0 I've set the perms to 755.I've also added the custom proper= ty to my engine like so: engine-config -s UserDefinedVMProperties=3D'change= _scsi_controller=3D.*' --cver=3D3.5I've restarted the ovirt-engine like so = 'service ovirt-engine restart' , and can now see the custom property in the= GUI config for a powered off VM that is set to boot up into my cluster.=C2= =A0 I've put a string into the 'change_scsi_controller' property and booted= up the VM.The scsi controller model is not changed from 'virtio-scsi' to '= ich9-ahci' =C2=A0On the host when I look at '/var/log/vdsm/vdsm.log' I can see tha tth= e hook is getting called, but I'm not sure what I need to look at here spec= ifically?=C2=A0 Can anyone assist and possibly tell me what is wrong here? = Is it an issue with my python hook script? I'm wanting to test an EL5 based install with a scsi disk, and EL5 does not= support virtio-scsi. I should also mention that I know there are issues with migrating VMs that = use the ich9-ahci sata controller and I don't plan to use this long term.= =C2=A0 If I do need this functionality I'll likely set up some Fedora hosts= in another cluster and use one of the other scsi controller types instead = - ie: 'lsi53c810"', 'lsi53c895a', 'megasas', 'pvscsi'. Here's the hook script code: #!/usr/bin/python =C2=A0 import os import hooking =C2=A0 def main(): =C2=A0 =C2=A0=C2=A0=C2=A0 if hooking.tobool(os.environ.get('change_scsi_controller= ')): =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 newscsiadapter =3D hooking.read_= json() =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domxml =3D hooking.read_domxml() =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for controller in domxml.getElem= entsByTagName('controller'): =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 filterVa= lue =3D controller.getAttribute('model') =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if filte= rValue =3D=3D 'virtio-scsi': =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 filterValue.setAttribute('model','ich9-ahci') =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hooking.write_domxml(domxml) if __name__ =3D=3D '__main__': =C2=A0=C2=A0=C2=A0 main() ------=_Part_1839633_221010509.1434090878897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial,= Lucida Grande, Sans-Serif;font-size:16px"><div dir=3D"ltr" id=3D"yui_3_16_= 0_1_1434089995415_2277"><span id=3D"yui_3_16_0_1_1434089995415_2464">I have= not coded much python, but I'm having a go at trying to get a vdsm hook sc= ript working.</span></div><div id=3D"yui_3_16_0_1_1434089995415_2366" dir= =3D"ltr"><br><span></span></div><div id=3D"yui_3_16_0_1_1434089995415_2289"= dir=3D"ltr"><span id=3D"yui_3_16_0_1_1434089995415_2310">What it is suppos= ed to do is look for a controller of model 'virtio-scsi' in the domxml and = change the model to 'ich9-ahci'.</span></div><div id=3D"yui_3_16_0_1_143408= 9995415_2311" dir=3D"ltr"><span id=3D"yui_3_16_0_1_1434089995415_2310"></sp= an></div><div id=3D"yui_3_16_0_1_1434089995415_2338" dir=3D"ltr">I've named= the script '50_change_scsi_controller' and have placed it in '/usr/libexec= /vdsm/hooks/before_vm_start' on the one (and only) host in the cluster wher= e I'm doing this testing.  I've set the perms to 755.</div><div id=3D"= yui_3_16_0_1_1434089995415_2389" dir=3D"ltr">I've also added the custom pro= perty to my engine like so: engine-config -s UserDefinedVMProperties=3D'cha= nge_scsi_controller=3D.*' --cver=3D3.5</div><div id=3D"yui_3_16_0_1_1434089= 995415_2423" dir=3D"ltr">I've restarted the ovirt-engine like so 'service o= virt-engine restart' , and can now see the custom property in the GUI confi= g for a powered off VM that is set to boot up into my cluster.  I've p= ut a string into the 'change_scsi_controller' property and booted up the VM= .</div><div id=3D"yui_3_16_0_1_1434089995415_2453" dir=3D"ltr">The scsi con= troller model is not changed from 'virtio-scsi' to 'ich9-ahci'<br></div><di= v style=3D"" class=3D"" id=3D"yui_3_16_0_1_1434089995415_2338" dir=3D"ltr">=  </div><div id=3D"yui_3_16_0_1_1434089995415_2535" style=3D"" class=3D= "" dir=3D"ltr">On the host when I look at '/var/log/vdsm/vdsm.log' I can se= e tha tthe hook is getting called, but I'm not sure what I need to look at = here specifically?  Can anyone assist and possibly tell me what is wro= ng here? Is it an issue with my python hook script?</div><div id=3D"yui_3_1= 6_0_1_1434089995415_2562" style=3D"" class=3D"" dir=3D"ltr"><br></div><div = id=3D"yui_3_16_0_1_1434089995415_2593" style=3D"" class=3D"" dir=3D"ltr">I'= m wanting to test an EL5 based install with a scsi disk, and EL5 does not s= upport virtio-scsi.<br></div><div id=3D"yui_3_16_0_1_1434089995415_2701" st= yle=3D"" class=3D"" dir=3D"ltr">I should also mention that I know there are= issues with migrating VMs that use the ich9-ahci sata controller and I don= 't plan to use this long term.  If I do need this functionality I'll l= ikely set up some Fedora hosts in another cluster and use one of the other = scsi controller types instead - ie: 'lsi53c810"', 'lsi53c895a', 'megasas', = 'pvscsi'.</div><div id=3D"yui_3_16_0_1_1434089995415_2702" style=3D"" class= =3D"" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1434089995415_2703" sty= le=3D"" class=3D"" dir=3D"ltr">Here's the hook script code:</div><div id=3D= "yui_3_16_0_1_1434089995415_2635" style=3D"" class=3D"" dir=3D"ltr"><br></d= iv><div id=3D"yui_3_16_0_1_1434089995415_2636" style=3D"" class=3D"" dir=3D= "ltr"><br></div><div id=3D"yui_3_16_0_1_1434089995415_2637" style=3D"" clas= s=3D"" dir=3D"ltr">#!/usr/bin/python<br style=3D"" class=3D""> <br sty= le=3D"" class=3D"">import os<br style=3D"" class=3D"">import hooking<br sty= le=3D"" class=3D""> <br style=3D"" class=3D"">def main():<br style=3D"= " class=3D""> <br style=3D"" class=3D"">    if hooking.= tobool(os.environ.get('change_scsi_controller')):<br style=3D"" class=3D"">=         newscsiadapter =3D hooking.read_= json()<br style=3D"" class=3D"">        = domxml =3D hooking.read_domxml()<br style=3D"" class=3D""><br style=3D"" cl= ass=3D"">        for controller in domxm= l.getElementsByTagName('controller'):<br style=3D"" class=3D"">  =           filterValue =3D cont= roller.getAttribute('model')<br style=3D"" class=3D"">   &nb= sp;        if filterValue =3D=3D 'virtio= -scsi':<br style=3D"" class=3D"">       =          filterValue.setAttribute('= model','ich9-ahci')<br style=3D"" class=3D""><br style=3D"" class=3D"">&nbs= p;       hooking.write_domxml(domxml)<br styl= e=3D"" class=3D""><br style=3D"" class=3D""><br style=3D"" class=3D"">if __= name__ =3D=3D '__main__':<br style=3D"" class=3D"">    main(= )<br style=3D"" class=3D""><br></div></div></body></html> ------=_Part_1839633_221010509.1434090878897--

3 2

Re: [ovirt-users] Bug in Snapshot Removing
by Soeren Malchow 11 Jun '15

11 Jun '15

--_000_D1916735D978soerenmalchowmconnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Small addition again: This error shows up in the log while removing snapshots WITHOUT rendering t= he Vms unresponsive =97 Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: Timed= out during operation: cannot acquire state change lock Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm vm.V= m ERROR vmId=3D`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting block = job info Traceback= (most recent call last): File "/= usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs=85 =97 From: Soeren Malchow <soeren.malchow(a)mcon.net<mailto:soeren.malchow@mcon.ne= t>> Date: Monday 1 June 2015 00:56 To: "libvirt-users(a)redhat.com<mailto:libvirt-users@redhat.com>" <libvirt-us= ers(a)redhat.com<mailto:libvirt-users@redhat.com>>, users <users(a)ovirt.org<ma= ilto:users@ovirt.org>> Subject: [ovirt-users] Bug in Snapshot Removing Dear all I am not sure if the mail just did not get any attention between all the ma= ils and this time it is also going to the libvirt mailing list. I am experiencing a problem with VM becoming unresponsive when removing Sna= pshots (Live Merge) and i think there is a serious problem. Here are the previous mails, http://lists.ovirt.org/pipermail/users/2015-May/033083.html The problem is on a system with everything on the latest version, CentOS 7.= 1 and ovirt 3.5.2.1 all upgrades applied. This Problem did NOT exist before upgrading to CentOS 7.1 with an environme= nt running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-preview rep= o activated. I think this is a bug in libvirt, not ovirt itself, but i am not sure. The = actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm.py, = line 697). We are very willing to help, test and supply log files in anyway we can. Regards Soeren --_000_D1916735D978soerenmalchowmconnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9FBCF9D40986EE4C94B0FC8E1FE85212(a)liquidcampaign.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Small addition again:</div> <div><br> </div> <div>This error shows up in the log while removing snapshots WITHOUT render= ing the Vms unresponsive</div> <div><br> </div> <div>=97</div> <div> <div>Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: = Timed out during operation: cannot acquire state change lock</div> <div>Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm= vm.Vm ERROR vmId=3D`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting b= lock job info</div> <div>                    =                     &nbsp= ;                     &nb= sp;   Traceback (most recent call last):</div> <div>                    =                     &nbsp= ;                     &nb= sp;     File "/usr/share/vdsm/virt/vm.py", line 5759, i= n queryBlockJobs=85</div> </div> <div><br> </div> <div>=97</div> <div><br> </div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>Soeren Malchow <<a href=3D= "mailto:soeren.malchow@mcon.net">soeren.malchow(a)mcon.net</a>><br> <span style=3D"font-weight:bold">Date: </span>Monday 1 June 2015 00:56<br> <span style=3D"font-weight:bold">To: </span>"<a href=3D"mailto:libvirt= -users(a)redhat.com">libvirt-users(a)redhat.com</a>" <<a href=3D"mailto= :libvirt-users@redhat.com">libvirt-users(a)redhat.com</a>>, users <<a h= ref=3D"mailto:users@ovirt.org">users(a)ovirt.org</a>><br> <span style=3D"font-weight:bold">Subject: </span>[ovirt-users] Bug in Snaps= hot Removing<br> </div> <div><br> </div> <div> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil= y: Calibri, sans-serif;"> <div>Dear all</div> <div><br> </div> <div>I am not sure if the mail just did not get any attention between all t= he mails and this time it is also going to the libvirt mailing list.</div> <div><br> </div> <div>I am experiencing a problem with VM becoming unresponsive when removin= g Snapshots (Live Merge) and i think there is a serious problem.</div> <div><br> </div> <div>Here are the previous mails,</div> <div><br> </div> <div><a href=3D"http://lists.ovirt.org/pipermail/users/2015-May/033083.html= ">http://lists.ovirt.org/pipermail/users/2015-May/033083.html</a></div> <div><br> </div> <div>The problem is on a system with everything on the latest version, Cent= OS 7.1 and ovirt 3.5.2.1 all upgrades applied.</div> <div><br> </div> <div>This Problem did NOT exist before upgrading to CentOS 7.1 with an envi= ronment running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-previe= w repo activated.</div> <div><br> </div> <div>I think this is a bug in libvirt, not ovirt itself, but i am not sure.= The actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm= .py, line 697).</div> <div><br> </div> <div>We are very willing to help, test and supply log files in anyway we ca= n. </div> <div><br> </div> <div>Regards</div> <div>Soeren </div> <div><br> </div> </div> </div> </span> </body> </html> --_000_D1916735D978soerenmalchowmconnet_--

3 11

How do I get discard working?
by Chris Jones - BookIt.com Systems Administrator 11 Jun '15

11 Jun '15

oVirt Node - 3.5 - 0.999.201504280931.el7.centos Using our shared storage via baremetal (stock CentOS 7) -> iscsi, I can successfully issue fstrim commands. With oVirt at the VM level, even with direct LUNS, trim commands are not supported despite having the LVM config in the VMs set up to allow it. Thanks -- This email was Virus checked by the PHX UTM 9. For issues please contact the Windows Systems Admin.

4 4

Re: [ovirt-users] [Users] Compiling ovirt-guest-agent on FreeBSD
by Karli Sjöberg 11 Jun '15

11 Jun '15

--_000_88d6743d06ba4ab8bfea500a71da1165emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTEganVuIDIwMTUgNDo0MiBlbSBza3JldiBWaW56ZW56IEZlZW5zdHJhIDx2ZmVlbnN0 ckByZWRoYXQuY29tPjoNCj4NCj4gT24gMDUvMjcvMjAxNSAxMDozOSBBTSwgQWxleGFuZHIgS3Jp dnVseWEgd3JvdGU6DQo+ID4gMDIuMDIuMjAxNSAxMjo1NywgS2FybGkgU2rDtmJlcmcg0L/QuNGI 0LXRgjoNCj4gPj4gT24gU2F0LCAyMDE1LTAxLTMxIGF0IDIzOjU0ICswMjAwLCBBbGV4YW5kciBL cml2dWx5YSB3cm90ZToNCj4gPj4+IDE5LjA4LjIwMTMgMTM6MjEsIEthcmxpIFNqw7ZiZXJnINC/ 0LjRiNC10YI6DQo+ID4+Pg0KPiA+Pj4+IG3DpW4gMjAxMy0wOC0xOSBrbG9ja2FuIDEyOjExICsw MjAwIHNrcmV2IFZpbnplbnogRmVlbnN0cmE6DQo+ID4+Pj4+IE9uIDA4LzE5LzIwMTMgMTA6MDEg QU0sIEthcmxpIFNqw7ZiZXJnIHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gbcOlbiAyMDEzLTA4 LTE5IGtsb2NrYW4gMDk6NTMgKzAyMDAgc2tyZXYgTWljaGFsIFNrcml2YW5lazoNCj4gPj4+Pj4+ PiBPbiBBdWcgMTksIDIwMTMsIGF0IDA5OjQxICwgS2FybGkgU2rDtmJlcmcgPEthcmxpLlNqb2Jl cmdAc2x1LnNlPiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBIaSENCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gQXMgcGFydCBvZiBhIHRlbXBsYXRlIEnCtG0gcHJlcGFyaW5nLCBJwrRtIHdv bmRlcmluZyBob3cgdG8gY29tcGlsZSB0aGUgYWdlbnQgd2l0aCBqdXN0IHRoZSBiYXNpY3MgaW5j bHVkZWQuIEnCtHZlIHRyaWVkIHJ1bm5pbmcgbGlrZToNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4g T1BUSU9OUz0nDQo+ID4+Pj4+Pj4+IC0td2l0aG91dC1nZG0tcGx1Z2luIC0td2l0aG91dC1nZG0y LXBsdWdpbiAgLS13aXRob3V0LWtkbS1wbHVnaW4gLS13aXRob3V0LXBhbS1vdmlydC1jcmVkDQo+ ID4+Pj4+Pj4+IC0td2l0aC1nZG0tcGx1Z2luPW5vIC0td2l0aC1nZG0yLXBsdWdpbj1ubyAtLXdp dGgta2RtLXBsdWdpbj1ubyAtLXdpdGgtcGFtLW92aXJ0LWNyZWQ9bm8NCj4gPj4+Pj4+Pj4gLS1k aXNhYmxlLWdkbS1wbHVnaW4gLS1kaXNhYmxlLWdkbTItcGx1Z2luIC0tZGlzYWJsZS1rZG0tcGx1 Z2luIC0tZGlzYWJsZS1wYW0tb3ZpcnQtY3JlZA0KPiA+Pj4+Pj4+PiAtLWVuYWJsZS1nZG0tcGx1 Z2luPW5vIC0tZW5hYmxlLWdkbTItcGx1Z2luPW5vIC0tZW5hYmxlLWtkbS1wbHVnaW49bm8gLS1l bmFibGVwYW0tb3ZpcnQtY3JlZC09bm8nDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICMgLi9jb25m aWd1cmUgJHtPUFRJT05TfQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBSZWdhcmRsZXNzIG9mIGhv dyBJIHRyeSwgaXQganVzdCByZXNwb25kczoNCj4gPj4+Pj4+Pj4gY29uZmlndXJlOiBXQVJOSU5H OiB1bnJlY29nbml6ZWQgb3B0aW9uczogJHtPUFRJT05TfQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ PiBJIHRvb2sgdGhlIHBhY2thZ2UgZnJvbSB0aGUgIm9mZmljaWFsIiBvVmlydC5vcmcgcmVwbywg c3JjIGZpbGU6DQo+ID4+Pj4+Pj4+IG92aXJ0LWd1ZXN0LWFnZW50LTEuMC42LnRhci5iejINCj4g Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gV2hhdCBhbSBJIGRvaW5nIHdyb25nPw0KPiA+Pj4+Pj4+IEhp DQo+ID4+Pj4+Pj4gdGhlIHBhcmFtZXRlcnMgYXJlIGdkbSwga2RtIGFuZCBzc28sIHNldCB0aGVt IHRvIG5vDQo+ID4+Pj4+PiBJIGRvbsK0dCBnZXQgaXQsIGl0IGRvZXNuwrR0IHNlZW0gdG8gY2Fy ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAjIC4vY29uZmlndXJlIC0td2l0aG91dC1nZG0NCj4gPj4+ Pj4+ICMgLi9jb25maWd1cmUgLS13aXRoLWdkbT1ubw0KPiA+Pj4+Pj4gIyAuL2NvbmZpZ3VyZSAt LWVuYWJsZS1nZG09bm8NCj4gPj4+Pj4+ICMgLi9jb25maWd1cmUgLS1kaXNhYmxlLWdkbQ0KPiA+ Pj4+Pj4gIyAuL2NvbmZpZ3VyZSAtLXdpdGhvdXQtZ2RtIC0td2l0aC1nZG09bm8gLS1lbmFibGUt Z2RtPW5vDQo+ID4+Pj4+PiAtLWRpc2FibGUtZ2RtDQo+ID4+Pj4+PiBjb25maWd1cmU6IFdBUk5J Tkc6IHVucmVjb2duaXplZCBvcHRpb25zOiAtLXdpdGhvdXQtZ2RtLA0KPiA+Pj4+Pj4gLS13aXRo LWdkbSwgLS1lbmFibGUtZ2RtLCAtLWRpc2FibGUtZ2RtDQo+ID4+Pj4+IHRoaXMgZmVhdHVyZSBv ZiBkaXNhYmxpbmcgaXQgd2FzIGludHJvZHVjZWQgdG8gb3ZpcnQtZ3Vlc3QtYWdlbnQNCj4gPj4+ Pj4gaW4gMS4wLjgNCj4gPj4+Pj4NCj4gPj4+Pj4gVHJ5IHRoaXMgb25lOg0KPiA+Pj4+PiBodHRw Oi8vZXZpbGlzc2ltby5mZWRvcmFwZW9wbGUub3JnL3JlbGVhc2VzL292aXJ0LWd1ZXN0LWFnZW50 LzEuMC44L292aXJ0LWd1ZXN0LWFnZW50LTEuMC44LjEudGFyLmJ6Mg0KPiA+Pj4+Pg0KPiA+Pj4+ PiAuL2NvbmZpZ3VyZSAtLXdpdGhvdXQtc3NvIC0tcHJlZml4PS91c3INCj4gPj4+PiBZb3Uga25v dyB3aGF0LCBzb3JyeSBhYm91dCB0aGUgbm9pc2UsIGJlY2F1c2UgaXQgc2VlbXMgYXMgaWYNCj4g Pj4+PiB2aXJ0aW8tc2VyaWFsIGlzbsK0dCBldmVuIGF2YWlsYWJsZSBvbiBGcmVlQlNELCBzbyBp dMK0cyBtb290DQo+ID4+Pj4gYW55d2F5Li4uIFNob3VsZCBwcm9iYWJseSBoYXZlIGxvb2tlZCB0 aGF0IHVwIGJlZm9yZSBldmVuIGdldHRpbmcNCj4gPj4+PiBzdGFydGVkOykNCj4gPj4+Pg0KPiA+ Pj4+IEJ1dCBiZXNpZGVzIHRoZSBmYWN0IHRoYXQgaXQgd29uwrR0IHdvcmsgdW50aWwgdGhhdMK0 cyBzb3J0ZWQsIEkgY2FuDQo+ID4+Pj4gYXQgbGVhc3Qgc2F5IHRoYXQgaXQgY29uZmlndXJlZCwg Y29tcGlsZWQgYW5kIGluc3RhbGxlZCBPSyB1c2luZw0KPiA+Pj4+IFJlbsOpwrRzIHN1Z2dlc3Rp b24sIGNsb25pbmcgZnJvbSBnaXQgYW5kIGJ1aWxkaW5nIGZyb20gdGhlcmUuDQo+ID4+PiBIZWxs byENCj4gPj4+IE5vdyB3aGVuIHZpcnRpb19jb25zb2xlKDQpIGRyaXZlciBhdmFpbGFibGUgaW4g Q1VSUkVOVCBkb2VzIGFueW9uZQ0KPiA+Pj4gd29ya3Mgb24gcG9ydGluZyBvdmlydC1ndWVzdC1h Z2VudCB0byBGcmVlQlNEPw0KPiA+Pj4gcGxhaW4gdGV4dCBkb2N1bWVudCBhdHRhY2htZW50IChB VFQwMDAwMSkNCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+PiBVc2VycyBtYWlsaW5nIGxpc3QNCj4gPj4+IFVzZXJzQG92aXJ0Lm9yZw0K PiA+Pj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4+ IEkgaGF2ZW7CtHQgdGVzdGVkIGFueXRoaW5nIHNpbmNlIGxhc3QgdGltZSBidXQgZ29vZCB0byBr bm93IHNvbWVvbmUgZG9pbmcNCj4gPj4gc29tZXRoaW5nOikgSSBjYW4gaW1hZ2luZSB0aGUgZ3Vl c3QgYWdlbnQgd291bGQgbmVlZCBzb21lIHR3ZWVraW5nIHRvDQo+ID4+IGdldCBpdCBydW5uaW5n IGFzIHdlbGw6DQo+ID4+DQo+ID4+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwv ZnJlZWJzZC1lbXVsYXRpb24vMjAxMy1BcHJpbC8wMTA1NjkuaHRtbA0KPiA+PiAiVGhlIFZpcnRJ TyBzcGVjIGlzIHdyaXR0ZW4gd2l0aCBtb3N0bHkgTGludXggaW4gbWluZCBhbmQgdXN1YWxseSB0 YWtlcw0KPiA+PiB2YXJ5aW5nIGFtb3VudHMgb2YgZXh0cmEgZWZmb3J0IHRvIGFkYXB0IHRvIEZy ZWVCU0QuIg0KPiA+Pg0KPiA+Pg0KPiA+IEkgaGF2ZSBzdWNjZXNzZnVsbHkgYnVpbGQgYW5kIHJ1 biBndWVzdCBhZ2VudCBvbiBGcmVlQlNELUN1cnJlbnQuIEl0DQo+ID4gcHJvdmlkZXMgYSBmZXcg aW5mb3JtYXRpb24gKGZvciBleGFtcGxlIGZxZG4gYW5kIGxvZ2dlZCB1c2VycykgaW50bw0KPiA+ IGFkbWluIHBvcnRhbCwgYnV0IGFsbCBvdGhlciByZXF1aXJlcyByZXdyaXRpbmcgR3Vlc3RBZ2Vu dExpbnV4Mi5weSBvcg0KPiA+IGltcGxlbWVudGluZyBpdCBhcyBzZXBhcmF0ZSBtb2R1bGUuIEkg aGF2ZSBubyBleHBlcmllbmNlIGluIHB5dGhvbiBhbmQNCj4gPiBwcm9ncmFtbWluZyBpdHNlbGYs IGJ1dCBpbXBsZW1lbnRpbmcgc29tZSBzaW1wbGUgZmVhdHVyZXMgbWF5IGJlIHF1aWV0DQo+ID4g ZWFzeS4gQ2FuIGFueW9uZSBoZWxwIHdpdGggaXQ/DQo+IFNvcnJ5IGZvciB0aGUgbGF0ZSByZXBs eSwgbm93IEkgZGlkbid0IG5vdGljZSB0aGF0IHRoZSBkcml2ZXJzIGFyZSBub3cNCj4gYXZhaWxh YmxlLCBJIHdpbGwgYmUgbG9va2luZyBpbnRvIHN1cHBvcnRpbmcgRnJlZUJTRCBmb3IgdGhlIGd1 ZXN0IGFnZW50DQo+IHRoZW4uDQoNCkhlcmUncyBhbiBleGNlbGxlbnQgcGxhY2UgdG8gc3RhcnQ6 KQ0KaHR0cHM6Ly93d3cuZnJlZWJzZC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9wb3J0 ZXJzLWhhbmRib29rLw0KDQovSw0KDQo+DQo+IFRoYW5rcyBmb3IgdGhlIGhlYWRzIHVwIDotKQ0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g VXNlcnMgbWFpbGluZyBsaXN0DQo+ID4gVXNlcnNAb3ZpcnQub3JnDQo+ID4gaHR0cDovL2xpc3Rz Lm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+DQo+DQo+IC0tDQo+IFJlZ2FyZHMs DQo+DQo+IFZpbnplbnogRmVlbnN0cmEgfCBTZW5pb3IgU29mdHdhcmUgRW5naW5lZXINCj4gUmVk SGF0IEVuZ2luZWVyaW5nIFZpcnR1YWxpemF0aW9uIFIgJiBEDQo+IFBob25lOiArNDIwIDUzMiAy OTQgNjI1DQo+IElSQzogdmZlZW5zdHIgb3IgZXZpbGlzc2ltbw0KPg0KPiBCZXR0ZXIgdGVjaG5v bG9neS4gRmFzdGVyIGlubm92YXRpb24uIFBvd2VyZWQgYnkgY29tbXVuaXR5IGNvbGxhYm9yYXRp b24uDQo+IFNlZSBob3cgaXQgd29ya3MgYXQgcmVkaGF0LmNvbQ0KPg0K --_000_88d6743d06ba4ab8bfea500a71da1165emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <B2651542710001428FAF322F6A8F4A69(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxMSBqdW4gMjAxNSA0OjQyIGVtIHNrcmV2IFZpbnplbnogRmVlbnN0cmEgJmx0 O3ZmZWVuc3RyQHJlZGhhdC5jb20mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDA1LzI3LzIw MTUgMTA6MzkgQU0sIEFsZXhhbmRyIEtyaXZ1bHlhIHdyb3RlOjxicj4NCiZndDsgJmd0OyAwMi4w Mi4yMDE1IDEyOjU3LCBLYXJsaSBTasO2YmVyZyDQv9C40YjQtdGCOjxicj4NCiZndDsgJmd0OyZn dDsgT24gU2F0LCAyMDE1LTAxLTMxIGF0IDIzOjU0ICYjNDM7MDIwMCwgQWxleGFuZHIgS3JpdnVs eWEgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgMTkuMDguMjAxMyAxMzoyMSwgS2FybGkg U2rDtmJlcmcg0L/QuNGI0LXRgjo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBtw6VuIDIwMTMtMDgtMTkga2xvY2thbiAxMjoxMSAmIzQzOzAyMDAgc2ty ZXYgVmluemVueiBGZWVuc3RyYTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDA4 LzE5LzIwMTMgMTA6MDEgQU0sIEthcmxpIFNqw7ZiZXJnIHdyb3RlOjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtw6VuIDIw MTMtMDgtMTkga2xvY2thbiAwOTo1MyAmIzQzOzAyMDAgc2tyZXYgTWljaGFsIFNrcml2YW5lazo8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gQXVnIDE5LCAyMDEzLCBh dCAwOTo0MSAsIEthcmxpIFNqw7ZiZXJnICZsdDtLYXJsaS5Tam9iZXJnQHNsdS5zZSZndDsgd3Jv dGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBBcyBwYXJ0IG9mIGEgdGVtcGxhdGUgScK0bSBwcmVwYXJpbmcsIEnCtG0gd29uZGVyaW5n IGhvdyB0byBjb21waWxlIHRoZSBhZ2VudCB3aXRoIGp1c3QgdGhlIGJhc2ljcyBpbmNsdWRlZC4g ScK0dmUgdHJpZWQgcnVubmluZyBsaWtlOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9Q VElPTlM9Jzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS13aXRo b3V0LWdkbS1wbHVnaW4gLS13aXRob3V0LWdkbTItcGx1Z2luJm5ic3A7IC0td2l0aG91dC1rZG0t cGx1Z2luIC0td2l0aG91dC1wYW0tb3ZpcnQtY3JlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS13aXRoLWdkbS1wbHVnaW49bm8gLS13aXRoLWdkbTItcGx1Z2lu PW5vIC0td2l0aC1rZG0tcGx1Z2luPW5vIC0td2l0aC1wYW0tb3ZpcnQtY3JlZD1ubzxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS1kaXNhYmxlLWdkbS1wbHVnaW4g LS1kaXNhYmxlLWdkbTItcGx1Z2luIC0tZGlzYWJsZS1rZG0tcGx1Z2luIC0tZGlzYWJsZS1wYW0t b3ZpcnQtY3JlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS1l bmFibGUtZ2RtLXBsdWdpbj1ubyAtLWVuYWJsZS1nZG0yLXBsdWdpbj1ubyAtLWVuYWJsZS1rZG0t cGx1Z2luPW5vIC0tZW5hYmxlcGFtLW92aXJ0LWNyZWQtPW5vJzxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUgJHtPUFRJT05TfTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFJlZ2FyZGxlc3Mgb2YgaG93IEkgdHJ5LCBpdCBqdXN0IHJlc3BvbmRzOjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uZmlndXJlOiBXQVJOSU5HOiB1 bnJlY29nbml6ZWQgb3B0aW9uczogJHtPUFRJT05TfTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEkgdG9vayB0aGUgcGFja2FnZSBmcm9tIHRoZSAmcXVvdDtvZmZpY2lhbCZxdW90OyBvVmly dC5vcmcgcmVwbywgc3JjIGZpbGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBvdmlydC1ndWVzdC1hZ2VudC0xLjAuNi50YXIuYnoyPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgV2hhdCBhbSBJIGRvaW5nIHdyb25nPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBIaTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0aGUgcGFyYW1ldGVycyBhcmUgZ2RtLCBrZG0gYW5kIHNzbywgc2V0IHRoZW0gdG8gbm88YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbsK0dCBnZXQgaXQsIGl0IGRvZXNu wrR0IHNlZW0gdG8gY2FyZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUgLS13aXRob3V0LWdk bTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUgLS13aXRo LWdkbT1ubzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUg LS1lbmFibGUtZ2RtPW5vPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgIyAuL2Nv bmZpZ3VyZSAtLWRpc2FibGUtZ2RtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg IyAuL2NvbmZpZ3VyZSAtLXdpdGhvdXQtZ2RtIC0td2l0aC1nZG09bm8gLS1lbmFibGUtZ2RtPW5v PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS1kaXNhYmxlLWdkbTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbmZpZ3VyZTogV0FSTklORzogdW5yZWNvZ25p emVkIG9wdGlvbnM6IC0td2l0aG91dC1nZG0sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgLS13aXRoLWdkbSwgLS1lbmFibGUtZ2RtLCAtLWRpc2FibGUtZ2RtPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIGZlYXR1cmUgb2YgZGlzYWJsaW5nIGl0IHdhcyBpbnRy b2R1Y2VkIHRvIG92aXJ0LWd1ZXN0LWFnZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBpbiAxLjAuODxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFRyeSB0aGlzIG9uZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGh0dHA6Ly9ldmlsaXNzaW1vLmZlZG9yYXBlb3BsZS5vcmcvcmVsZWFzZXMvb3ZpcnQtZ3Vl c3QtYWdlbnQvMS4wLjgvb3ZpcnQtZ3Vlc3QtYWdlbnQtMS4wLjguMS50YXIuYnoyPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLi9j b25maWd1cmUgLS13aXRob3V0LXNzbyAtLXByZWZpeD0vdXNyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFlvdSBrbm93IHdoYXQsIHNvcnJ5IGFib3V0IHRoZSBub2lzZSwgYmVjYXVzZSBpdCBz ZWVtcyBhcyBpZjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB2aXJ0aW8tc2VyaWFsIGlzbsK0 dCBldmVuIGF2YWlsYWJsZSBvbiBGcmVlQlNELCBzbyBpdMK0cyBtb290PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGFueXdheS4uLiBTaG91bGQgcHJvYmFibHkgaGF2ZSBsb29rZWQgdGhhdCB1 cCBiZWZvcmUgZXZlbiBnZXR0aW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHN0YXJ0ZWQ7 KTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBC dXQgYmVzaWRlcyB0aGUgZmFjdCB0aGF0IGl0IHdvbsK0dCB3b3JrIHVudGlsIHRoYXTCtHMgc29y dGVkLCBJIGNhbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhdCBsZWFzdCBzYXkgdGhhdCBp dCBjb25maWd1cmVkLCBjb21waWxlZCBhbmQgaW5zdGFsbGVkIE9LIHVzaW5nPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IFJlbsOpwrRzIHN1Z2dlc3Rpb24sIGNsb25pbmcgZnJvbSBnaXQgYW5k IGJ1aWxkaW5nIGZyb20gdGhlcmUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSGVsbG8hPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgTm93IHdoZW4gdmlydGlvX2NvbnNvbGUoNCkgZHJpdmVyIGF2YWls YWJsZSBpbiBDVVJSRU5UIGRvZXMgYW55b25lPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgd29ya3Mg b24gcG9ydGluZyBvdmlydC1ndWVzdC1hZ2VudCB0byBGcmVlQlNEPzxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IHBsYWluIHRleHQgZG9jdW1lbnQgYXR0YWNobWVudCAoQVRUMDAwMDEpPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBVc2Vyc0BvdmlydC5vcmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBodHRw Oi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQomZ3Q7ICZndDsm Z3Q7IEkgaGF2ZW7CtHQgdGVzdGVkIGFueXRoaW5nIHNpbmNlIGxhc3QgdGltZSBidXQgZ29vZCB0 byBrbm93IHNvbWVvbmUgZG9pbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNvbWV0aGluZzopIEkgY2Fu IGltYWdpbmUgdGhlIGd1ZXN0IGFnZW50IHdvdWxkIG5lZWQgc29tZSB0d2Vla2luZyB0bzxicj4N CiZndDsgJmd0OyZndDsgZ2V0IGl0IHJ1bm5pbmcgYXMgd2VsbDo8YnI+DQomZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvcGlwZXJtYWlsL2Zy ZWVic2QtZW11bGF0aW9uLzIwMTMtQXByaWwvMDEwNTY5Lmh0bWw8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZxdW90O1RoZSBWaXJ0SU8gc3BlYyBpcyB3cml0dGVuIHdpdGggbW9zdGx5IExpbnV4IGluIG1p bmQgYW5kIHVzdWFsbHkgdGFrZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHZhcnlpbmcgYW1vdW50cyBv ZiBleHRyYSBlZmZvcnQgdG8gYWRhcHQgdG8gRnJlZUJTRC4mcXVvdDs8YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyBJIGhhdmUgc3VjY2Vzc2Z1bGx5 IGJ1aWxkIGFuZCBydW4gZ3Vlc3QgYWdlbnQgb24gRnJlZUJTRC1DdXJyZW50LiBJdDxicj4NCiZn dDsgJmd0OyBwcm92aWRlcyBhIGZldyBpbmZvcm1hdGlvbiAoZm9yIGV4YW1wbGUgZnFkbiBhbmQg bG9nZ2VkIHVzZXJzKSBpbnRvPGJyPg0KJmd0OyAmZ3Q7IGFkbWluIHBvcnRhbCwgYnV0IGFsbCBv dGhlciByZXF1aXJlcyByZXdyaXRpbmcgR3Vlc3RBZ2VudExpbnV4Mi5weSBvcjxicj4NCiZndDsg Jmd0OyBpbXBsZW1lbnRpbmcgaXQgYXMgc2VwYXJhdGUgbW9kdWxlLiBJIGhhdmUgbm8gZXhwZXJp ZW5jZSBpbiBweXRob24gYW5kPGJyPg0KJmd0OyAmZ3Q7IHByb2dyYW1taW5nIGl0c2VsZiwgYnV0 IGltcGxlbWVudGluZyBzb21lIHNpbXBsZSBmZWF0dXJlcyBtYXkgYmUgcXVpZXQ8YnI+DQomZ3Q7 ICZndDsgZWFzeS4gQ2FuIGFueW9uZSBoZWxwIHdpdGggaXQ/PGJyPg0KJmd0OyBTb3JyeSBmb3Ig dGhlIGxhdGUgcmVwbHksIG5vdyBJIGRpZG4ndCBub3RpY2UgdGhhdCB0aGUgZHJpdmVycyBhcmUg bm93IDxicj4NCiZndDsgYXZhaWxhYmxlLCBJIHdpbGwgYmUgbG9va2luZyBpbnRvIHN1cHBvcnRp bmcgRnJlZUJTRCBmb3IgdGhlIGd1ZXN0IGFnZW50IDxicj4NCiZndDsgdGhlbi48L3A+DQo8cCBk aXI9Imx0ciI+SGVyZSdzIGFuIGV4Y2VsbGVudCBwbGFjZSB0byBzdGFydDopPGJyPg0KaHR0cHM6 Ly93d3cuZnJlZWJzZC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9wb3J0ZXJzLWhhbmRi b29rLzwvcD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0 OyBUaGFua3MgZm9yIHRoZSBoZWFkcyB1cCA6LSk8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgVXNlcnMg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IFVzZXJzQG92aXJ0Lm9yZzxicj4NCiZndDsgJmd0 OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDs8YnI+ DQomZ3Q7IFZpbnplbnogRmVlbnN0cmEgfCBTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI8YnI+DQom Z3Q7IFJlZEhhdCBFbmdpbmVlcmluZyBWaXJ0dWFsaXphdGlvbiBSICZhbXA7IEQ8YnI+DQomZ3Q7 IFBob25lOiAmIzQzOzQyMCA1MzIgMjk0IDYyNTxicj4NCiZndDsgSVJDOiB2ZmVlbnN0ciBvciBl dmlsaXNzaW1vPGJyPg0KJmd0Ozxicj4NCiZndDsgQmV0dGVyIHRlY2hub2xvZ3kuIEZhc3RlciBp bm5vdmF0aW9uLiBQb3dlcmVkIGJ5IGNvbW11bml0eSBjb2xsYWJvcmF0aW9uLjxicj4NCiZndDsg U2VlIGhvdyBpdCB3b3JrcyBhdCByZWRoYXQuY29tPGJyPg0KJmd0Ozxicj4NCjwvcD4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_88d6743d06ba4ab8bfea500a71da1165emailandroidcom_--

1 0

[Users] Compiling ovirt-guest-agent on FreeBSD
by Karli Sjöberg 11 Jun '15

11 Jun '15

--_000_5F9E965F5A80BC468BE5F40576769F092E70EBE0exchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkFzIHBhcnQgb2YgYSB0ZW1wbGF0ZSBJwrRtIHByZXBhcmluZywgScK0bSB3b25kZXJp bmcgaG93IHRvIGNvbXBpbGUgdGhlIGFnZW50IHdpdGgganVzdCB0aGUgYmFzaWNzIGluY2x1ZGVk LiBJwrR2ZSB0cmllZCBydW5uaW5nIGxpa2U6DQoNCk9QVElPTlM9Jw0KLS13aXRob3V0LWdkbS1w bHVnaW4gLS13aXRob3V0LWdkbTItcGx1Z2luICAtLXdpdGhvdXQta2RtLXBsdWdpbiAtLXdpdGhv dXQtcGFtLW92aXJ0LWNyZWQNCi0td2l0aC1nZG0tcGx1Z2luPW5vIC0td2l0aC1nZG0yLXBsdWdp bj1ubyAtLXdpdGgta2RtLXBsdWdpbj1ubyAtLXdpdGgtcGFtLW92aXJ0LWNyZWQ9bm8NCi0tZGlz YWJsZS1nZG0tcGx1Z2luIC0tZGlzYWJsZS1nZG0yLXBsdWdpbiAtLWRpc2FibGUta2RtLXBsdWdp biAtLWRpc2FibGUtcGFtLW92aXJ0LWNyZWQNCi0tZW5hYmxlLWdkbS1wbHVnaW49bm8gLS1lbmFi bGUtZ2RtMi1wbHVnaW49bm8gLS1lbmFibGUta2RtLXBsdWdpbj1ubyAtLWVuYWJsZXBhbS1vdmly dC1jcmVkLT1ubycNCg0KIyAuL2NvbmZpZ3VyZSAke09QVElPTlN9DQoNClJlZ2FyZGxlc3Mgb2Yg aG93IEkgdHJ5LCBpdCBqdXN0IHJlc3BvbmRzOg0KY29uZmlndXJlOiBXQVJOSU5HOiB1bnJlY29n bml6ZWQgb3B0aW9uczogJHtPUFRJT05TfQ0KDQpJIHRvb2sgdGhlIHBhY2thZ2UgZnJvbSB0aGUg Im9mZmljaWFsIiBvVmlydC5vcmcgcmVwbywgc3JjIGZpbGU6DQpvdmlydC1ndWVzdC1hZ2VudC0x LjAuNi50YXIuYnoyDQoNCldoYXQgYW0gSSBkb2luZyB3cm9uZz8NCg0KLS0NCg0KTWVkIFbDpG5s aWdhIEjDpGxzbmluZ2FyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpLYXJsaSBTasO2YmVyZw0K U3dlZGlzaCBVbml2ZXJzaXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlcw0KQm94IDcwNzkgKFZp c2l0aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KQ0KUy03NTAgMDcgVXBwc2FsYSwgU3dlZGVu DQpQaG9uZTogICs0Ni0oMCkxOC02NyAxNSA2Ng0Ka2FybGkuc2pvYmVyZ0BzbHUuc2U8bWFpbHRv OmthcmxpLnNqb2JlcmdAYWRtLnNsdS5zZT4NCg== --_000_5F9E965F5A80BC468BE5F40576769F092E70EBE0exchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC42LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpIaSE8YnI+DQo8YnI+ DQpBcyBwYXJ0IG9mIGEgdGVtcGxhdGUgScK0bSBwcmVwYXJpbmcsIEnCtG0gd29uZGVyaW5nIGhv dyB0byBjb21waWxlIHRoZSBhZ2VudCB3aXRoIGp1c3QgdGhlIGJhc2ljcyBpbmNsdWRlZC4gScK0 dmUgdHJpZWQgcnVubmluZyBsaWtlOjxicj4NCjxicj4NCk9QVElPTlM9Jzxicj4NCi0td2l0aG91 dC1nZG0tcGx1Z2luIC0td2l0aG91dC1nZG0yLXBsdWdpbiZuYnNwOyAtLXdpdGhvdXQta2RtLXBs dWdpbiAtLXdpdGhvdXQtcGFtLW92aXJ0LWNyZWQ8YnI+DQotLXdpdGgtZ2RtLXBsdWdpbj1ubyAt LXdpdGgtZ2RtMi1wbHVnaW49bm8gLS13aXRoLWtkbS1wbHVnaW49bm8gLS13aXRoLXBhbS1vdmly dC1jcmVkPW5vPGJyPg0KLS1kaXNhYmxlLWdkbS1wbHVnaW4gLS1kaXNhYmxlLWdkbTItcGx1Z2lu IC0tZGlzYWJsZS1rZG0tcGx1Z2luIC0tZGlzYWJsZS1wYW0tb3ZpcnQtY3JlZDxicj4NCi0tZW5h YmxlLWdkbS1wbHVnaW49bm8gLS1lbmFibGUtZ2RtMi1wbHVnaW49bm8gLS1lbmFibGUta2RtLXBs dWdpbj1ubyAtLWVuYWJsZXBhbS1vdmlydC1jcmVkLT1ubyc8YnI+DQo8YnI+DQojIC4vY29uZmln dXJlICR7T1BUSU9OU308YnI+DQo8YnI+DQpSZWdhcmRsZXNzIG9mIGhvdyBJIHRyeSwgaXQganVz dCByZXNwb25kczo8YnI+DQpjb25maWd1cmU6IFdBUk5JTkc6IHVucmVjb2duaXplZCBvcHRpb25z OiAke09QVElPTlN9PGJyPg0KPGJyPg0KSSB0b29rIHRoZSBwYWNrYWdlIGZyb20gdGhlICZxdW90 O29mZmljaWFsJnF1b3Q7IG9WaXJ0Lm9yZyByZXBvLCBzcmMgZmlsZTo8YnI+DQpvdmlydC1ndWVz dC1hZ2VudC0xLjAuNi50YXIuYnoyPGJyPg0KPGJyPg0KV2hhdCBhbSBJIGRvaW5nIHdyb25nPzxi cj4NCjxicj4NCjx0YWJsZSBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIx MDAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZD4tLSA8YnI+DQo8YnI+DQpNZWQgVsOkbmxpZ2EgSMOk bHNuaW5nYXI8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KS2FybGkgU2rDtmJlcmc8 YnI+DQpTd2VkaXNoIFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFsIFNjaWVuY2VzPGJyPg0KQm94 IDcwNzkgKFZpc2l0aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KTxicj4NClMtNzUwIDA3IFVw cHNhbGEsIFN3ZWRlbjxicj4NClBob25lOiAmbmJzcDsmIzQzOzQ2LSgwKTE4LTY3IDE1IDY2PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOmthcmxpLnNqb2JlcmdAYWRtLnNsdS5zZSI+a2FybGkuc2pvYmVy Z0BzbHUuc2U8L2E+IDwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_5F9E965F5A80BC468BE5F40576769F092E70EBE0exchange21_--

6 10

[Centos7.1x64] [Ovirt 3.5.2] Test fence : Power management test failed for Host hosted_engine1 Done
by wodel youchi 11 Jun '15

11 Jun '15

Hi, I have a weird problem with fencing I have a cluster of two HP DL380p G8 (ILO4) *Centos7.1x64 and oVirt 3.5.2 ALL UPDATED* I configured fencing first with *ilo4* then *ipmilan* When testing fence from the engine I get : Succeeded, Unknown And in alerts tab I get : Power management test failed for Host hosted_engine1 Done (the same for host2) I tested with fence_ilo4 and fence_ipmilan and they report the result correctly # fence_ipmilan -P -a 192.168.2.2 -o status -l Administrator -p ertyuiop -vExecuting: /usr/bin/ipmitool -I lanplus -H 192.168.2.2 -U Administrator -P ertyuiop -p 623 -L ADMINISTRATOR chassis power status 0 Chassis Power is on Status: ON # fence_ilo4 -l Administrator -p ertyuiop -a 192.168.2.2 -o status -v Executing: /usr/bin/ipmitool -I lanplus -H 192.168.2.2 -U Administrator -P ertyuiop -p 623 -L ADMINISTRATOR chassis power status 0 Chassis Power is on Status: ON ---------------------------------- These are the options passed to fence_ipmilan (I tested with the options and without them) lanplus="1", power_wait="60" This is the engine log: 2015-06-09 13:35:29,287 INFO [org.ovirt.engine.core.bll.FenceExecutor] (ajp--127.0.0.1-8702-7) Using Host hosted_engine_2 from cluster Default as proxy to execute Status command on Host 2015-06-09 13:35:29,289 INFO [org.ovirt.engine.core.bll.FenceExecutor] (ajp--127.0.0.1-8702-7) Executing <Status> Power Management command, Proxy Host:hosted_engine_2, Agent:ipmilan, Target Host:, Management IP:192.168.2.2, User:Administrator, Options: power_wait="60",lanplus="1", Fencing policy:null 2015-06-09 13:35:29,306 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (ajp--127.0.0.1-8702-7) START, FenceVdsVDSCommand( HostName = hosted_engine_2, HostId = 0192d1ac-b905-4660-b149-4bef578985dd, targetVdsId = cf2d1260-7bb3-451a-9cd7-80e6a0ede52a, action = Status, ip = 192.168.2.2, port = , type = ipmilan, user = Administrator, password = ******, options = ' power_wait="60",lanplus="1"', policy = 'null'), log id: 24ce6206 2015-06-09 13:35:29,516 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-7) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Power Management test failed for Host hosted_engine_1.Done 2015-06-09 13:35:29,516 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (ajp--127.0.0.1-8702-7) FINISH, FenceVdsVDSCommand, return: *Test Succeeded, unknown*, log id: 24ce6206 and here the vdsm log from the proxy JsonRpcServer::DEBUG::2015-06-09 13:37:52,461::__init__::506::jsonrpc.JsonRpcServer::(serve_requests) Waiting for request Thread-131907::DEBUG::2015-06-09 13:37:52,463::API::1209::vds::(fenceNode) fenceNode(addr=192.168.2.2,port=,agent=ipmilan,user=Administrator,passwd=XXXX,action=status,secure=False,options= power_wait="60" lanplus="1",policy=None) Thread-131907::DEBUG::2015-06-09 13:37:52,463::utils::739::root::(execCmd) /usr/sbin/fence_ipmilan (cwd None) Thread-131907::DEBUG::2015-06-09 13:37:52,533::utils::759::root::(execCmd) FAILED: <err> = 'Failed: Unable to obtain correct plug status or plug is not available\n\n\n'; <rc> = 1 Thread-131907::DEBUG::2015-06-09 13:37:52,533::API::1164::vds::(fence) rc 1 inp agent=fence_ipmilan ipaddr=192.168.2.2 login=Administrator action=status passwd=XXXX power_wait="60" lanplus="1" out [] err ['Failed: Unable to obtain correct plug status or plug is not available', '', ''] Thread-131907::DEBUG::2015-06-09 13:37:52,533::API::1235::vds::(fenceNode) rc 1 in agent=fence_ipmilan ipaddr=192.168.2.2 login=Administrator action=status passwd=XXXX power_wait="60" lanplus="1" out [] err ['*Failed: Unable to obtain correct plug status or plug is not available*', '', ''] Thread-131907::DEBUG::2015-06-09 13:37:52,534::stompReactor::163::yajsonrpc.StompServer::(send) Sending response Detector thread::DEBUG::2015-06-09 13:37:53,670::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection) Adding connection from 127.0.0.1:55761 VDSM rpms # rpm -qa | grep vdsm vdsm-cli-4.16.14-0.el7.noarch vdsm-python-zombiereaper-4.16.14-0.el7.noarch vdsm-xmlrpc-4.16.14-0.el7.noarch vdsm-yajsonrpc-4.16.14-0.el7.noarch vdsm-4.16.14-0.el7.x86_64 vdsm-python-4.16.14-0.el7.noarch vdsm-jsonrpc-4.16.14-0.el7.noarch any idea? Thanks in advance.

3 9

Unable to use the SPICE HTML5 tool
by Nicolás 11 Jun '15

11 Jun '15

This is a multi-part message in MIME format. --------------040801010109090109090703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm using oVirt 3.5.2 on a CentOS box. As far as the engine goes everything is working fine, except that I can't start the SPICE HTML5 tool for any of the installed machines I have. I've installed the oVirt guest agent on the VM side, websocket-proxy is running and port 6100 is listening on the engine box: # systemctl status ovirt-websocket-proxy ovirt-websocket-proxy.service - oVirt Engine websockets proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-websocket-proxy.service; enabled) Active: active (running) # netstat -atpn | grep 6100 tcp 0 0 0.0.0.0:6100 0.0.0.0:* LISTEN 7227/python Also, I imported the CA cert (https://fqdn/ca.crt) on the browser. However, once I run the SPICE HTML5 client from the userportal, all I get is an empty grey square with the two "Send ctrl+alt+delete" and "Toggle messages output" buttons at the bottom. Nothing in the logs about this issue. I tried to run it both with Chromium and Firefox on a linux box. Is there anything that I am missing? I've run out of ideas... Thanks. Nicolás --------------040801010109090109090703 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 bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> I'm using oVirt 3.5.2 on a CentOS box. As far as the engine goes everything is working fine, except that I can't start the SPICE HTML5 tool for any of the installed machines I have.<br> <br> I've installed the oVirt guest agent on the VM side, websocket-proxy is running and port 6100 is listening on the engine box:<br> <blockquote># systemctl status ovirt-websocket-proxy<br> ovirt-websocket-proxy.service - oVirt Engine websockets proxy<br> Loaded: loaded (/usr/lib/systemd/system/ovirt-websocket-proxy.service; enabled)<br> Active: active (running)<br> <br> # netstat -atpn | grep 6100<br> tcp 0 0 0.0.0.0:6100 0.0.0.0:* LISTEN 7227/python<br> </blockquote> Also, I imported the CA cert (<a class="moz-txt-link-freetext" href="https://fqdn/ca.crt">https://fqdn/ca.crt</a>) on the browser. However, once I run the SPICE HTML5 client from the userportal, all I get is an empty grey square with the two "Send ctrl+alt+delete" and "Toggle messages output" buttons at the bottom. Nothing in the logs about this issue. I tried to run it both with Chromium and Firefox on a linux box.<br> <br> Is there anything that I am missing? I've run out of ideas...<br> <br> Thanks.<br> <br> Nicolás<br> <br> <br> </body> </html> --------------040801010109090109090703--

5 7

Re: [ovirt-users] Comma Seperated Value doesn't accept by custom properties
by Punit Dambiwal 11 Jun '15

11 Jun '15

Hi Dan, Seems the problem is here :- ----------------------------- Thread-779::INFO::2015-06-09 09:04:05,204::hooks::100::root::(_runHooksDir) Thread-779::DEBUG::2015-06-09 09:04:05,205::utils::739::root::(execCmd) /usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof (cwd None) Thread-779::DEBUG::2015-06-09 09:04:05,301::utils::759::root::(execCmd) FAILED: <err> = 'Traceback (most recent call last):\n File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 85, in <module>\n main()\n File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 52, in main\n interface, = domxml.getElementsByTagName(\'interface\')\nValueError: too many values to unpack\n'; <rc> = 1 Thread-779::INFO::2015-06-09 09:04:05,301::hooks::100::root::(_runHooksDir) Traceback (most recent call last): File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 85, in <module> main() File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 52, in main interface, = domxml.getElementsByTagName('interface') ValueError: too many values to unpack Thread-779::DEBUG::2015-06-09 09:04:05,301::vm::2294::vm.Vm::(_startUnderlyingVm) vmId=`600f6fa9-0c08-42ec-bbbd-939a07beb61c`::_ongoingCreations released Thread-779::ERROR::2015-06-09 09:04:05,302::vm::2331::vm.Vm::(_startUnderlyingVm) vmId=`600f6fa9-0c08-42ec-bbbd-939a07beb61c`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 2271, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 3299, in _run domxml = hooks.before_vm_start(self._buildCmdLine(), self.conf) File "/usr/share/vdsm/hooks.py", line 142, in before_vm_start return _runHooksDir(domxml, 'before_vm_start', vmconf=vmconf) File "/usr/share/vdsm/hooks.py", line 110, in _runHooksDir raise HookError() HookError Thread-779::DEBUG::2015-06-09 09:04:05,303::vm::2786::vm.Vm::(setDownStatus) vmId=`600f6fa9-0c08-42ec-bbbd-939a07beb61c`::Changed state to Down: VM terminated with error (code=1) --------------------- On Tue, Jun 9, 2015 at 9:13 AM, Punit Dambiwal <hypunit(a)gmail.com> wrote: > Hi Dan, > > Please find the Vdsm logs here :- > > 1. With 2 NIC (VM failed to bootup) :- http://paste.ubuntu.com/11660142/ > 2. Removed the secondary NIC and run the VM again....VM can bootup :- > http://paste.ubuntu.com/11660197/ > > Thanks, > Punit > > > > > On Mon, Jun 8, 2015 at 8:35 PM, Dan Kenigsberg <danken(a)redhat.com> wrote: > >> On Mon, Jun 08, 2015 at 05:43:40PM +0800, Punit Dambiwal wrote: >> > Hi Dan, >> > >> > Can save now the comma separate ip address...but still the problem >> > persists.... >> > >> > 1. If one Network interface...i can add multiple ip addresses with comma >> > separated... >> > 2. But if i add another network interface to this VM....VM cannot boot >> up... >> > 3. What need to do if i want to assign multiple ip address on multiple >> > network interface ?? >> >> Can you share your vdsm.log of this boot failure? >> >> Regards, >> Dan. >> > >

2 2

[Centos7x64] [Ovirt 3.5.2 hosted engine] hypervisor hang when rebooted
by wodel youchi 10 Jun '15

10 Jun '15

Hi, Centos7x64, Ovirt 3.5.2 hosted engine : all updated. Two hypervisors HP DL380p I have a strange behaviour on my hypervisors, whenever I reboot one of them it hangs. It hangs in this line : hpwdt unexpected close not stopping watchdog watchdog multiplexing stopped on the ILO4 GUI I have this error An Unrecoverable System Error (NMI) has occurred (System error code 0x0000002B, 0x00000000) Thanks.

1 1

ovirt webadmin errors
by jazzman＠go2.pl 10 Jun '15

10 Jun '15

--==o2.pl-WebMail-33769c4e.b80adab.aa4c2== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi=20guys,=C2=A0 I=20need=20to=20build=20a=20ovirt=20based=C2=A0environment=20using=20coup= le=20old=20servers=20-=20for=20now=20only=20for=20testing.=C2=A0 For=20controler=20I=20choose=20machine=20with=203GB=20of=20ram=20and=20In= tel=20Xeon=202.8=20Ghz.=C2=A0 I=20know=20this=20is=C2=A0below=20requirements=20but=20in=20this=C2=A0env= ironment=20I=20have=20smal=20amount=20of=20physical=20servers=20eg: 1x=20controller=C2=A0 2x=20hypervisors=C2=A0 2x=20glusters After=20instaling,=20everything=20looks=20okay=C2=A0until=20the=20first=20= logon=20to=20webadmin.=C2=A0 When=20I=20try=20to=20define=20first=20virtual=20datacenter=20webui=20wor= ks=20realy=C2=A0slow.=C2=A0It=20is=20not=20possible=20to=20switch=20beetw= en=20any=20tabs.=20At=20the=20end=C2=A0I=20received=20a=20503=20error.=C2= =A0 I=20thought=20that=20was=20a=20my=20browser=20issue.=C2=A0I=20check=20thi= s=20using=20Ubuntu=20+=20Chromium=20+=20Firefox=20from=20repo,=20also=20I= =20try=20a=20older=20version=20of=20Firefox.=C2=A0 Windows=207=20+=20Firefox=20-=20=C2=A0was=20this=20same=20problems.=C2=A0= Does=20anybody=20know=20how=20to=20resolve=20the=20problem=20?=C2=A0 Thanks=C2=A0 Greg=20K=C2=A0 --==o2.pl-WebMail-33769c4e.b80adab.aa4c2== Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi=20guys,=C2=A0<br=20/>I=20need=20to=20build=20a=20ovirt=20based=C2=A0en= vironment=20using=20couple=20old=20servers=20-=20for=20now=20only=20for=20= testing.=C2=A0<br=20/>For=20controler=20I=20choose=20machine=20with=203GB= =20of=20ram=20and=20Intel=20Xeon=202.8=20Ghz.=C2=A0<br=20/>I=20know=20thi= s=20is=C2=A0below=20requirements=20but=20in=20this=C2=A0environment=20I=20= have=20smal=20amount=20of=20physical=20servers=20eg:<br=20/>1x=20controll= er=C2=A0<br=20/>2x=20hypervisors=C2=A0<br=20/>2x=20glusters<br=20/><br=20= />After=20instaling,=20everything=20looks=20okay=C2=A0until=20the=20first= =20logon=20to=20webadmin.=C2=A0<br=20/>When=20I=20try=20to=20define=20fir= st=20virtual=20datacenter=20webui=20works=20realy=C2=A0slow.=C2=A0It=20is= =20not=20possible=20to=20switch=20beetwen=20any=20tabs.=20At=20the=20end=C2= =A0I=20received=20a=20503=20error.=C2=A0<br=20/>I=20thought=20that=20was=20= a=20my=20browser=20issue.=C2=A0I=20check=20this=20using=20Ubuntu=20+=20Ch= romium=20+=20Firefox=20from=20repo,=20also=20I=20try=20a=20older=20versio= n=20of=20Firefox.=C2=A0<br=20/>Windows=207=20+=20Firefox=20-=20=C2=A0was=20= this=20same=20problems.=C2=A0<br=20/><br=20/>Does=20anybody=20know=20how=20= to=20resolve=20the=20problem=20?=C2=A0<br=20/><br=20/>Thanks=C2=A0<br=20/= >Greg=20K=C2=A0<br=20/><br=20/> --==o2.pl-WebMail-33769c4e.b80adab.aa4c2==--

3 3

Questions about Spice Proxy
by Kevin COUSIN 08 Jun '15

08 Jun '15

Hi list, Hi try to setup a SPICE Proxy with HAproxy. It works fine for the WebUI. I define the proxy with engine-config -s SpiceProxyDefault="http://mygreatproxy.tld:8080". The connections are going on the nodes with the same port (here 8080 or 3128 line in documentation) or on the engine ? Need I to install a squid proxy instead of HAproxy ? Regards ---- Kevin C.

2 1

Comma Seperated Value doesn't accept by custom properties
by Punit Dambiwal 08 Jun '15

08 Jun '15

Hi, I have installed noipspoof VDSM hooks...in the vdsm hooks it specify that you can use multiple ip address by comma separate list....but it's not working... single ip can work without any issue...but can not add multiple ip address in this filed... [image: Inline image 1] Thanks, Punit

3 6

Move VirtIO disk to External LUN disk
by Juan Carlos YJ. Lin 08 Jun '15

08 Jun '15

--=_29ee8d9f-0144-4834-b7ed-9ac528cd762c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I have performance issue with the VirtIO disks and like to move it to External LUN on the ISCI storage to use the ISCSI pathtrought How I can do that? Juan Carlos Lin Unisoft S.A. +595-993-288330 --------------------------------------------------- "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente" "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias." --=_29ee8d9f-0144-4834-b7ed-9ac528cd762c Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 10pt; color: #000000'><span>I have performance issue with the VirtIO disks and like to move it to External LUN on the ISCI storage to use the ISCSI pathtrought<br>How I can do that?<br><br><span name="x"></span>Juan Carlos Lin<br>Unisoft S.A.<br>+595-993-288330<span name="x"></span><br></span><br></div> <br> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML lang="es"> <HEAD> <TITLE>System-wide Disclaimer</TITLE> </HEAD> <BODY>---------------------------------------------------<br>"Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente"<br>"Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias." </BODY> </HTML><br> </body></html> --=_29ee8d9f-0144-4834-b7ed-9ac528cd762c--

2 1

Katello integration
by Nathanaël Blanchet 08 Jun '15

08 Jun '15

Hello i read your wiki page about katello but i can't see thé projection as a target on the Google sheet https://docs.google.com/spreadsheets/d/1vUwi0y54SV7nYZC1DXo_hLPyG7hvtWDHfa6… Is this always targeted tout 3.6? Screenshot tell me that web is already ready.

3 2

Re: [ovirt-users] HA storage based on two nodes with one point of failure
by Юрий Полторацкий 08 Jun '15

08 Jun '15

This is a multi-part message in MIME format. --------------070106010204050704030701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I have made a lab with a config listed below and have got unexpected result. Someone, tell me, please, where did I go wrong? I am testing oVirt. Data Center has two clusters: the first as a computing with three nodes (node1, node2, node3); the second as a storage (node5, node6) based on glusterfs (replica 2). I want the storage to be HA. I have read here <https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/Admini…> next: For a replicated volume with two nodes and one brick on each machine, if the server-side quorum is enabled and one of the nodes goes offline, the other node will also be taken offline because of the quorum configuration. As a result, the high availability provided by the replication is ineffective. To prevent this situation, a dummy node can be added to the trusted storage pool which does not contain any bricks. This ensures that even if one of the nodes which contains data goes offline, the other node will remain online. Note that if the dummy node and one of the data nodes goes offline, the brick on other node will be also be taken offline, and will result in data unavailability. So, I have added my "Engine" (not self-hosted) as a dummy node without a brick and have configured quorum as listed below: cluster.quorum-type: fixed cluster.quorum-count: 1 cluster.server-quorum-type: server cluster.server-quorum-ratio: 51% Then, I've run a VM and have dropped the network link from node6, after one a hour have switched back the link and after a while have got a split-brain. But why? No one could write to the brick on node6: the VM was running on node3 and node1 was SPM. Gluster's log from node6: Июн 07 15:35:06 node6.virt.local etc-glusterfs-glusterd.vol[28491]: [2015-06-07 12:35:06.106270] C [MSGID: 106002] [glusterd-server-quorum.c:356:glusterd_do_volume_quorum_action] 0-management: Server quorum lost for volume vol3. Stopping local bricks. Июн 07 16:30:06 node6.virt.local etc-glusterfs-glusterd.vol[28491]: [2015-06-07 13:30:06.261505] C [MSGID: 106003] [glusterd-server-quorum.c:351:glusterd_do_volume_quorum_action] 0-management: Server quorum regained for volume vol3. Starting local bricks. gluster> volume heal vol3 info Brick node5.virt.local:/storage/brick12/ /5d0bb2f3-f903-4349-b6a5-25b549affe5f/dom_md/ids - Is in split-brain Number of entries: 1 Brick node6.virt.local:/storage/brick13/ /5d0bb2f3-f903-4349-b6a5-25b549affe5f/dom_md/ids - Is in split-brain Number of entries: 1 gluster> volume info vol3 Volume Name: vol3 Type: Replicate Volume ID: 69ba8c68-6593-41ca-b1d9-40b3be50ac80 Status: Started Number of Bricks: 1 x 2 = 2 Transport-type: tcp Bricks: Brick1: node5.virt.local:/storage/brick12 Brick2: node6.virt.local:/storage/brick13 Options Reconfigured: storage.owner-gid: 36 storage.owner-uid: 36 cluster.server-quorum-type: server cluster.quorum-type: fixed network.remote-dio: enable cluster.eager-lock: enable performance.stat-prefetch: off performance.io-cache: off performance.read-ahead: off performance.quick-read: off auth.allow: * user.cifs: disable nfs.disable: on performance.readdir-ahead: on cluster.quorum-count: 1 cluster.server-quorum-ratio: 51% 06.06.2015 12:09, Юрий Полторацкий пишет: > Hi, > > I want to build a HA storage based on two servers. I want that if one > goes down, my storage will be available in RW mode. > > If I will use replica 2, then split-brain can occur. To avoid this I > would use a quorum. As I understand correctly, I can use quorum on a > client side, on a server side, or on both. I want to add a dummy node > without a brick and make such config: > > cluster.quorum-type: fixed > cluster.quorum-count: 1 > cluster.server-quorum-type: server > cluster.server-quorum-ratio: 51% > > I expect that client will have access in RW mode until one brick > alive. On the other side if server's quorum will not meet, then bricks > will be RO. > > Say, HOST1 with a brick BRICK1, HOST2 with a brick BRICK2, and HOST3 > without a brick. > > Once HOST1 lose a network connection, than on this node server quorum > will not meet and the brick BRICK1 will not be able for writing. But > on HOST2 there is no problem with server quorum (HOST2 + HOST3 > 51%) > and that's why BRICK2 still accessible for writing. With client's > quorum there is no problem also - one brick is alive, so client can > write on it. > > I have made a lab using KVM on my desktop and it seems to be worked > well and as expected. > > The main question is: > Can I use such a storage for production? > > Thanks. > --------------070106010204050704030701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi,<br> <br> I have made a lab with a config listed below and have got unexpected result. Someone, tell me, please, where did I go wrong?<br> <br> I am testing oVirt. Data Center has two clusters: the first as a computing with three nodes (node1, node2, node3); the second as a storage (node5, node6) based on glusterfs (replica 2).<br> <br> I want the storage to be HA. I have read <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/Admini…">here</a> next:<br> <tt>For a replicated volume with two nodes and one brick on each machine, if the server-side quorum is enabled and one of the nodes goes offline, the other node will also be taken offline because of the quorum configuration. As a result, the high availability provided by the replication is ineffective. To prevent this situation, a dummy node can be added to the trusted storage pool which does not contain any bricks. This ensures that even if one of the nodes which contains data goes offline, the other node will remain online. Note that if the dummy node and one of the data nodes goes offline, the brick on other node will be also be taken offline, and will result in data unavailability. </tt><br> <br> So, I have added my "Engine" (not self-hosted) as a dummy node without a brick and have configured quorum as listed below:<br> <tt>cluster.quorum-type: fixed</tt><tt><br> </tt><tt>cluster.quorum-count: 1</tt><tt><br> </tt><tt>cluster.server-quorum-type: server</tt><tt><br> </tt><tt>cluster.server-quorum-ratio: 51%</tt><br> <br> <br> Then, I've run a VM and have dropped the network link from node6, after one a hour have switched back the link and after a while have got a split-brain. But why? No one could write to the brick on node6: the VM was running on node3 and node1 was SPM.<br> <br> Gluster's log from node6:<br> <tt>Июн 07 15:35:06 node6.virt.local etc-glusterfs-glusterd.vol[28491]: [2015-06-07 12:35:06.106270] C [MSGID: 106002] [glusterd-server-quorum.c:356:glusterd_do_volume_quorum_action] 0-management: Server quorum lost for volume vol3. Stopping local bricks.</tt><tt><br> </tt><tt>Июн 07 16:30:06 node6.virt.local etc-glusterfs-glusterd.vol[28491]: [2015-06-07 13:30:06.261505] C [MSGID: 106003] [glusterd-server-quorum.c:351:glusterd_do_volume_quorum_action] 0-management: Server quorum regained for volume vol3. Starting local bricks.</tt><br> <tt><br> <br> </tt><tt>gluster> volume heal vol3 info </tt><tt><br> </tt><tt>Brick node5.virt.local:/storage/brick12/</tt><tt><br> </tt><tt>/5d0bb2f3-f903-4349-b6a5-25b549affe5f/dom_md/ids - Is in split-brain</tt><tt><br> </tt><tt><br> </tt><tt>Number of entries: 1</tt><tt><br> </tt><tt><br> </tt><tt>Brick node6.virt.local:/storage/brick13/</tt><tt><br> </tt><tt>/5d0bb2f3-f903-4349-b6a5-25b549affe5f/dom_md/ids - Is in split-brain</tt><tt><br> </tt><tt><br> </tt><tt>Number of entries: 1</tt><br> <br> <br> <tt>gluster> volume info vol3</tt><tt><br> </tt><tt> </tt><tt><br> </tt><tt>Volume Name: vol3</tt><tt><br> </tt><tt>Type: Replicate</tt><tt><br> </tt><tt>Volume ID: 69ba8c68-6593-41ca-b1d9-40b3be50ac80</tt><tt><br> </tt><tt>Status: Started</tt><tt><br> </tt><tt>Number of Bricks: 1 x 2 = 2</tt><tt><br> </tt><tt>Transport-type: tcp</tt><tt><br> </tt><tt>Bricks:</tt><tt><br> </tt><tt>Brick1: node5.virt.local:/storage/brick12</tt><tt><br> </tt><tt>Brick2: node6.virt.local:/storage/brick13</tt><tt><br> </tt><tt>Options Reconfigured:</tt><tt><br> </tt><tt>storage.owner-gid: 36</tt><tt><br> </tt><tt>storage.owner-uid: 36</tt><tt><br> </tt><tt>cluster.server-quorum-type: server</tt><tt><br> </tt><tt>cluster.quorum-type: fixed</tt><tt><br> </tt><tt>network.remote-dio: enable</tt><tt><br> </tt><tt>cluster.eager-lock: enable</tt><tt><br> </tt><tt>performance.stat-prefetch: off</tt><tt><br> </tt><tt>performance.io-cache: off</tt><tt><br> </tt><tt>performance.read-ahead: off</tt><tt><br> </tt><tt>performance.quick-read: off</tt><tt><br> </tt><tt>auth.allow: *</tt><tt><br> </tt><tt>user.cifs: disable</tt><tt><br> </tt><tt>nfs.disable: on</tt><tt><br> </tt><tt>performance.readdir-ahead: on</tt><tt><br> </tt><tt>cluster.quorum-count: 1</tt><tt><br> </tt><tt>cluster.server-quorum-ratio: 51%</tt><br> <br> <br> <br> <div class="moz-cite-prefix">06.06.2015 12:09, Юрий Полторацкий пишет:<br> </div> <blockquote cite="mid:CANgBB_sWBZwDh3yaAJV=ETLqrJyYxT9_EfRjnjMHF-1NVbevqw@mail.gmail.com" type="cite"> <div dir="ltr"> <div> <div> <div> <div> <div> <div> <div> <div>Hi,<br> <br> </div> I want to build a HA storage based on two servers. I want that if one goes down, my storage will be available in RW mode.<br> <br> </div> If I will use replica 2, then split-brain can occur. To avoid this I would use a quorum. As I understand correctly, I can use quorum on a client side, on a server side, or on both. I want to add a dummy node without a brick and make such config:<br> </div> <br> cluster.quorum-type: fixed<br> cluster.quorum-count: 1<br> cluster.server-quorum-type: server<br> cluster.server-quorum-ratio: 51%<br> <br> </div> I expect that client will have access in RW mode until one brick alive. On the other side if server's quorum will not meet, then bricks will be RO. <br> <br> Say, HOST1 with a brick BRICK1, HOST2 with a brick BRICK2, and HOST3 without a brick.<br> <br> Once HOST1 lose a network connection, than on this node server quorum will not meet and the brick BRICK1 will not be able for writing. But on HOST2 there is no problem with server quorum (HOST2 + HOST3 > 51%) and that's why BRICK2 still accessible for writing. With client's quorum there is no problem also - one brick is alive, so client can write on it.<br> <br> </div> I have made a lab using KVM on my desktop and it seems to be worked well and as expected.<br> <br> </div> The main question is:<br> </div> Can I use such a storage for production?<br> <br> </div> Thanks. <br> <div> <div> <div> <div> <div><br> </div> </div> </div> </div> </div> </div> </blockquote> <br> </body> </html> --------------070106010204050704030701--

2 2