- Users - oVirt List Archives

Re: [ovirt-users] Can not connect to Storage domain data
by Yue, Cong 18 Dec '14

18 Dec '14

--_000_ED08B56256B38842A463A2A0804C5AC0326ACA46CAsvrcaexch1atg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the problems for my issue are related with the NFS version. >From the second, if I change the value of Defaultver /etc/nfsmount.conf fr= om "Defaultvres=3D4" to "Defaulvers=3D3", the mount can not be done. When I= changed it back to "Defaultvers=3D4", it will work. Also from /proc/mounts, it shows the nfs version is nfs4. But for my first = host, it is nfs3. Do somebody have the similar issue about thi? Thank in advance, Cong From: Yue, Cong Sent: Thursday, December 18, 2014 9:52 AM To: users(a)ovirt.org Subject: Can not connect to Storage domain data Hi I successfully deployed the first ovirt host with hosted-engine -deploy. En= gine VM works well. While, when I try to create the second host with the same way as the guide = of http://community.redhat.com/blog/2014/11/up-and-running-with-ovirt-3-5-part= -two/ I am not using GlusterFS, and just use one external storage(nfs) in my envi= ronment. The issue I have is in the engine administration menu, it says "can not con= nect to storage domain data" In the second host, I checked with nfs-check.py for both storage and data d= omain. It shows the status is ok. http://www.ovirt.org/Troubleshooting_NFS_Storage_Issues During deployment of the second host, how the data domain is trying to be m= ounted? Thanks, ________________________________ This e-mail message is for the sole use of the intended recipient(s) and ma= y contain confidential and privileged information. Any unauthorized review,= use, disclosure or distribution is prohibited. If you are not the intended= recipient, please contact the sender by reply e-mail and destroy all copie= s of the original message. If you are the intended recipient, please be adv= ised that the content of this message is subject to access, review and disc= losure by the sender's e-mail System Administrator. --_000_ED08B56256B38842A463A2A0804C5AC0326ACA46CAsvrcaexch1atg_ 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"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> I think the problems for my issue are related with the NFS version.<o:p><= /o:p> From the second, if I change the value of Defaultver  /etc/nfsmount.= conf from “Defaultvres=3D4” to “Defaulvers=3D3”, th= e mount can not be done. When I changed it back to “Defaultvers=3D4&#= 8221;, it will work.<o:p></o:p> Also from /proc/mounts, it shows the nfs version is nfs4. But for my firs= t host, it is nfs3.<o:p></o:p> <o:p> </o:p> Do somebody have the similar issue about thi?<o:p></o:p> <o:p> </o:p> Thank in advance,<o:p></o:p> Cong<o:p></o:p> <o:p> </o:p> <o:p> </o:p></spa= n> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> From: Yue, Con= g Sent: Thursday, December 18, 2014 9:52 AM To: users(a)ovirt.org Subject: Can not connect to Storage domain data <o:p></o:p></= p> </div> </div> <o:p> </o:p> Hi<o:p></o:p> <o:p> </o:p> I successfully deployed the first ovirt host with ho= sted-engine –deploy. Engine VM works well.<o:p></o:p> While, when I try to create the second host with the= same way as the guide of <o:p></o:p> <a href=3D"http://community.redhat.com/blog/2014/11/= up-and-running-with-ovirt-3-5-part-two/">http://community.redhat.com/blog/2= 014/11/up-and-running-with-ovirt-3-5-part-two/</a><o:p></o:p> <o:p> </o:p> I am not using GlusterFS, and just use one external = storage(nfs) in my environment.<o:p></o:p> <o:p> </o:p> The issue I have is in the engine administration men= u, it says “can not connect to storage domain data”<o:p></o:p><= /p> In the second host, I checked with nfs-check.py for = both storage and data domain. It shows the status is ok.<o:p></o:p> <a href=3D"http://www.ovirt.org/Troubleshooting_NFS_= Storage_Issues">http://www.ovirt.org/Troubleshooting_NFS_Storage_Issues</a>= <o:p></o:p> <o:p> </o:p> <o:p> </o:p> During deployment of the second host, how the data d= omain is trying to be mounted?<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> <hr> This e-mail message is for t= he sole use of the intended recipient(s) and may contain confidential and p= rivileged information. Any unauthorized review, use, disclosure or distribu= tion is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy = all copies of the original message. If you are the intended recipient, plea= se be advised that the content of this message is subject to access, review= and disclosure by the sender's e-mail System Administrator. </body> </html> --_000_ED08B56256B38842A463A2A0804C5AC0326ACA46CAsvrcaexch1atg_--

1 0

Can not connect to Storage domain data
by Yue, Cong 18 Dec '14

18 Dec '14

--_000_ED08B56256B38842A463A2A0804C5AC0326ACA4574svrcaexch1atg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I successfully deployed the first ovirt host with hosted-engine -deploy. En= gine VM works well. While, when I try to create the second host with the same way as the guide = of http://community.redhat.com/blog/2014/11/up-and-running-with-ovirt-3-5-part= -two/ I am not using GlusterFS, and just use one external storage(nfs) in my envi= ronment. The issue I have is in the engine administration menu, it says "can not con= nect to storage domain data" In the second host, I checked with nfs-check.py for both storage and data d= omain. It shows the status is ok. http://www.ovirt.org/Troubleshooting_NFS_Storage_Issues During deployment of the second host, how the data domain is trying to be m= ounted? Thanks, ________________________________ This e-mail message is for the sole use of the intended recipient(s) and ma= y contain confidential and privileged information. Any unauthorized review,= use, disclosure or distribution is prohibited. If you are not the intended= recipient, please contact the sender by reply e-mail and destroy all copie= s of the original message. If you are the intended recipient, please be adv= ised that the content of this message is subject to access, review and disc= losure by the sender's e-mail System Administrator. --_000_ED08B56256B38842A463A2A0804C5AC0326ACA4574svrcaexch1atg_ 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"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi<o:p></o:p> <o:p> </o:p> I successfully deployed the first ovirt host with ho= sted-engine –deploy. Engine VM works well.<o:p></o:p> While, when I try to create the second host with the= same way as the guide of <o:p></o:p> <a href=3D"http://community.redhat.com/blog/2014/11/= up-and-running-with-ovirt-3-5-part-two/">http://community.redhat.com/blog/2= 014/11/up-and-running-with-ovirt-3-5-part-two/</a><o:p></o:p> <o:p> </o:p> I am not using GlusterFS, and just use one external = storage(nfs) in my environment.<o:p></o:p> <o:p> </o:p> The issue I have is in the engine administration men= u, it says “can not connect to storage domain data”<o:p></o:p><= /p> In the second host, I checked with nfs-check.py for = both storage and data domain. It shows the status is ok.<o:p></o:p> <a href=3D"http://www.ovirt.org/Troubleshooting_NFS_= Storage_Issues">http://www.ovirt.org/Troubleshooting_NFS_Storage_Issues</a>= <o:p></o:p> <o:p> </o:p> <o:p> </o:p> During deployment of the second host, how the data d= omain is trying to be mounted?<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> <hr> This e-mail message is for t= he sole use of the intended recipient(s) and may contain confidential and p= rivileged information. Any unauthorized review, use, disclosure or distribu= tion is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy = all copies of the original message. If you are the intended recipient, plea= se be advised that the content of this message is subject to access, review= and disclosure by the sender's e-mail System Administrator. </body> </html> --_000_ED08B56256B38842A463A2A0804C5AC0326ACA4574svrcaexch1atg_--

1 0

architecture of ovirt in case of using hosted-engine
by Yue, Cong 18 Dec '14

18 Dec '14

--_000_ED08B56256B38842A463A2A0804C5AC0326ACA451Csvrcaexch1atg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand ovirt have ovirt engine and ovirt nodes. For ovirt engine, it = can be hosted on the top of ovirt nodes as one VM. I am using hosted-engine to try to do this. When I try to deploy the second ovirt node. I did Hosted-engine -deploy And is asks me when I want to create a VM where you have to install oVirt E= ngine afterwards. I am some confused whether this means another new engine = VM will be created into the second ovirt nodes? Also I met a problem for the second ovirt node deployment. In the event, it= saids "Failed to connect to Host hosted_engine_2 to Storage domain data". As for I met the same problem for /engine, and I just used nfs4 and it work= s. Is there some way I can redeploy it? Do I need do hosted-engine -destroy= -VM? Thanks, Cong ________________________________ This e-mail message is for the sole use of the intended recipient(s) and ma= y contain confidential and privileged information. Any unauthorized review,= use, disclosure or distribution is prohibited. If you are not the intended= recipient, please contact the sender by reply e-mail and destroy all copie= s of the original message. If you are the intended recipient, please be adv= ised that the content of this message is subject to access, review and disc= losure by the sender's e-mail System Administrator. --_000_ED08B56256B38842A463A2A0804C5AC0326ACA451Csvrcaexch1atg_ 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"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> I understand ovirt have ovirt engine and ovirt nodes= . For ovirt engine, it can be hosted on the top of ovirt nodes as one VM.<o= :p></o:p> <o:p> </o:p> I am using hosted-engine to try to do this.<o:p></o:= p> When I try to deploy the second ovirt node. <o:p></o= :p> I did <o:p></o:p> Hosted-engine –deploy<o:p></o:p> <o:p> </o:p> And is asks me when I want to create a VM where you = have to install oVirt Engine afterwards. I am some confused whether this me= ans another new engine VM will be created into the second ovirt nodes?<o:p>= </o:p> <o:p> </o:p> Also I met a problem for the second ovirt node deplo= yment. In the event, it saids “Failed to connect to Host hosted_engin= e_2 to Storage domain data”.<o:p></o:p> As for I met the same problem for /engine, and I jus= t used nfs4 and it works. Is there some way I can redeploy it? Do I need do= hosted-engine –destroy-VM?<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> Cong<o:p></o:p> <o:p></o:p> <o:p> </o:p> </div> <hr> This e-mail message is for t= he sole use of the intended recipient(s) and may contain confidential and p= rivileged information. Any unauthorized review, use, disclosure or distribu= tion is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy = all copies of the original message. If you are the intended recipient, plea= se be advised that the content of this message is subject to access, review= and disclosure by the sender's e-mail System Administrator. </body> </html> --_000_ED08B56256B38842A463A2A0804C5AC0326ACA451Csvrcaexch1atg_--

1 0

Problem with installing second host for hosted_engine (3.5)
by Otto Strassen 18 Dec '14

18 Dec '14

Hi I have set up oVirt 3.5 in a hosted engine configuration. Host running CentOS 7, guest CentOS 6.6. Now I'm trying to set up an additional host, also running CentOS 7. I'm doing this by running 'hosted-engine --deploy' on the second host, giving the NFS address of the hosted engine share and following the instructions (Do you want to copy over answers? etc.) It works up to the point where it asks for the admin@internal password. [ ERROR ] Failed to execute stage 'Setup validation': [Errno 2] No such file or directory: '/rhev/data-center/mnt/lima.sylon.net:_srv_hosted__engine/17f87a87-1144-4be6-a9b4-8b0520ccbe70/ha_agent/hosted-engine.metadata' -- Open Interactive GmbH Vogesenplatz 1 4056 Basel T +41 61 500 15 70 www.openinteractive.ch

2 4

IPv6 Functionality for WebSocket Proxy
by Donny Davis 18 Dec '14

18 Dec '14

This is a multipart message in MIME format. ------=_NextPart_000_02AD_01D01AA1.DD69F530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I just realized this morning that my noVNC connections were not working for IPv6 only on cloudspin.me For those who want to deploy dual stack functionality for ovirt-websocket-proxy here is a very simple and elegant fix. NGINX is a useful tool :) You will need nginx to proxy the connection between your IPv6 customers, and the IPv4 listening only websocket proxy(however that can be changed in /usr/share/ovirt-engine/services/ovirt-websocket-proxy/ovirt-websocket-proxy .conf but you can't have your cake and eat it too. one or the other ipv4 or ipv6) Anyways, here is the fix Install nginx on your websocket proxy server - Why Nginx, because I like it better than apache. The default config for Ovirt could be setup to do this with the web server that is already running :) just sayin For my configuration I am running the websocket proxy on a different host, but I imagine you could use this config in a full deployment and use websocket proxy on the engine host server { server_name web.cloudspin.me; # this is the hostname that you told the engine that the websocket proxy would be listening on #listen 6100; #Commented because I am using this for ipv6 only, but you could use nginx to proxy both and only open one port in the firewall listen [::]:6100 ssl; #NOTE this needs to listen on the same port you told the engine the websocket proxy would be listening on ssl_certificate /physical/path/to/ssl/cert; #I used the same cert that my websocket proxy is using ssl_certificate_key /physical/path/to/ssl/key; ssl on; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; access_log /var/log/nginx/websocket.cloudspin.me-access.log; error_log /var/log/nginx/websocket.cloudspin.me-error.log; location / { proxy_pass https://ip_address_of_websocket_proxy:6100; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } Too easy to fix the many problems I have had getting websocket proxy to work. If you have a commerical cert and key, this would be a great place to put it, so your users don't have to bother with trusting your CA, it will just work Cheers and I hope this helps If anyone needs any help getting this to work give me a shout Donny D cloudspin.me ------=_NextPart_000_02AD_01D01AA1.DD69F530 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-microsoft-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=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DEN-US link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>I just = realized this morning that my noVNC connections were not working for = IPv6 only on cloudspin.me<o:p></o:p>For those = who want to deploy dual stack functionality for ovirt-websocket-proxy = here is a very simple and elegant fix. <o:p></o:p><o:p> </o:p>NGINX is a = useful tool :)<o:p></o:p><o:p> </o:p>You will = need nginx to proxy the connection between your IPv6 customers, and the = IPv4 listening only websocket proxy(however that can be changed in = /usr/share/ovirt-engine/services/ovirt-websocket-proxy/ovirt-websocket-pr= oxy.conf but you can't have your cake and eat it too… one or the = other ipv4 or ipv6)<o:p></o:p>Anyways, here is = the fix<o:p></o:p><o:p> </o:p>Install nginx on your websocket proxy server - Why = Nginx, because I like it better than apache. The default config for = Ovirt could be setup to do this with the web server that is already = running :) just sayin<o:p></o:p>For my = configuration I am running the websocket proxy on a different host, but = I imagine you could use this config in a full deployment and use = websocket proxy on the engine host<o:p></o:p><o:p> </o:p>server = {<o:p></o:p>        server_name = web.cloudspin.me; # this is the hostname that you told the engine that = the websocket proxy would be listening on<o:p></o:p>        #listen = 6100;           &n= bsp; #Commented because I am using this for ipv6 only, but you could use = nginx to proxy both and only open one port in the = firewall<o:p></o:p>        listen [::]:6100 = ssl;     #NOTE this needs to listen on the same port = you told the engine the websocket proxy would be listening = on   <o:p></o:p>        ssl_certificate=            = /physical/path/to/ssl/cert; #I used the same cert that my websocket = proxy is using<o:p></o:p>        = ssl_certificate_key       = /physical/path/to/ssl/key;<o:p></o:p><o:p> </o:p>        ssl = on;<o:p></o:p>        = ssl_session_cache  builtin:1000  = shared:SSL:10m;<o:p></o:p>        ssl_protocols  = TLSv1 TLSv1.1 TLSv1.2;<o:p></o:p>        ssl_ciphers = HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;<o:p></o:p></spa= n>   =      ssl_prefer_server_ciphers = on;<o:p></o:p><o:p> </o:p>        access_log = /var/log/nginx/websocket.cloudspin.me-access.log;<o:p></o:p><p= class=3DMsoNormal style=3D'text-autospace:none'>        error_log = /var/log/nginx/websocket.cloudspin.me-error.log;<o:p></o:p><o:p> </o:p>        location / = {<o:p></o:p>          &nb= sp; proxy_pass = https://ip_address_of_websocket_proxy:6100;<o:p></o:p>          = proxy_http_version 1.1;<o:p></o:p>          = proxy_set_header Upgrade $http_upgrade;<o:p></o:p>          = proxy_set_header Connection "upgrade";<o:p></o:p>          &nb= sp;    <o:p></o:p>        }<o:p></o:p></s= pan>    }<o:p></o:p><o:p> </o:p><o:p> </o:p>Too easy to fix = the many problems I have had getting websocket proxy to work. If you = have a commerical cert and key, this would be a great place to put it, = so your users don't have to bother with trusting your CA, it will just = work <o:p></o:p><o:p> </o:p>Cheers and I = hope this helps<o:p></o:p><o:p> </o:p>If anyone needs = any help getting this to work give me a shout<o:p></o:p><o:p> </o:p>Donny = D<o:p></o:p>cloudspin.me<o:p></o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------=_NextPart_000_02AD_01D01AA1.DD69F530--

1 1

Get involved in oVirt project! Xmas edition
by Sandro Bonazzola 18 Dec '14

18 Dec '14

Hi, have you got some free time in upcoming holidays and do you want to get involved in oVirt project? Here are some bugs you can hopefully fix in less that one day or you can just try to reproduce providing info: Bug 1080823 - [RFE] make override of iptables configurable when using hosted-engine Bug 1065350 - hosted-engine should prompt a question at the user when the host was already a host in the engine Bug 1059952 - hosted-engine --deploy (additional host) will fail if the engine is not using the default self-signed CA Bug 1073421 - [RFE] allow additional parameter for engine-backup to omit audit_log data Bug 1083104 - engine-setup --offline does not update versionlock Do you want something easier? Bug ID Status Summary 1174285 NEW [de-DE] "Live Snapshot Support" reads "Live Snapsnot Support" 734120 NEW [RFE] VDSM: use virt-sparsify/zerofree to reduce image size 1065989 NEW AddStorageDomainCommand CDA allows export storage on block devices 1115059 NEW Incomplete error message when adding VNIC profile to running VM 1156060 NEW [text] engine admin password prompt consistency 1143817 NEW [TEXT ONLY] - Hosted Engine - Instructions for FQDN are not clear enough 772931 NEW [RFE] Reports should include the name of the oVirt engine You don't have programming skills but you want to contribute? Here are some bugs you can take care of, also without writing a line of code: Bug ID Status Summary 1099998 NEW Hosted Engine documentation has several errors 1099995 NEW Migrate to Hosted Engine How-To does not state all pre-reqs 1159784 NEW [RFE] Document when and where new features are available when upgrading cluster / datacenters 1074545 NEW Error in API documentation: Create API object in python sdk 1120585 NEW update image uploader documentation 1120586 NEW update iso uploader documentation 1120588 NEW update log collector documentation 1074301 NEW [RFE] ovirt-shell has no man page Do you prefer to test things? We have some test cases[5] you can try using nightly snapshots[6] Do you want to contribute test cases? Most of the features[7] included in oVirtare missing a test case, you're welcome to contribute one! Is this the first time you try to contribute to oVirt project? You can start from here [1][2]! Don't know gerrit very well? You can find some more docs here [3]. Any other question about development? Feel free to ask on devel(a)ovirt.org or on irc channel[4]. [1] http://www.ovirt.org/Develop [2] http://www.ovirt.org/Working_with_oVirt_Gerrit [3] https://gerrit-review.googlesource.com/Documentation [4] http://www.ovirt.org/Community [5] http://www.ovirt.org/Category:TestCase [6] http://www.ovirt.org/Install_nightly_snapshot [7] http://www.ovirt.org/Category:Feature -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

NUMA and non-NUMA nodes and migration
by Chris Adams 18 Dec '14

18 Dec '14

So, new problem (I'm good at breaking things I guess?). Same setup, CentOS 7 + oVirt 3.5.0. Some of my nodes have 2 four-core CPUs, and some have 1 eight-core CPU (same number of available cores); all Intel Xeons of Nehalem or newer type. The systems with 2 CPUs apparently have NUMA support, although I haven't configured anything related to it. The problem: I am unable to live migrate a VM from a node with NUMA to a node without NUMA (haven't tried the other direction). I get messages like: Dec 16 15:36:05 node8 journal: internal error: Process exited prior to exec: libvirt: error : internal error: NUMA node 1 is out of range I see this mentioned in RHBZ 1147644, but it doesn't have a clear resolution to this issue there (multiple issues came up in the same ticket). Is this something that is supposed to be fixed already, will be fixed in 3.5.1 (or later release), or has fallen through the cracks? -- Chris Adams <cma(a)cmadams.net>

2 2

Re: [ovirt-users] vm has paused due to unknown storage error
by Martijn Grendelman 18 Dec '14

18 Dec '14

Oh I just found this: https://bugzilla.redhat.com/show_bug.cgi?id=1162640 Cheers, M. Martijn Grendelman schreef op 18-12-2014 om 15:03: > Hi, > > On a new host, I am running into exactly the same scenario. > > I have a host with an oVirt-managed GlusterFS volume (single brick on > local disk in distribute mode) on an XFS file system. > > I think I have found the root cause, but I doubt I can fix it. > > Around the time of the VMs going paused, there seemed to be a glusterfsd > restart: > >> [2014-12-18 01:43:27.272235] W [glusterfsd.c:1194:cleanup_and_exit] (--> 0-: received signum (15), shutting down >> [2014-12-18 01:43:27.272279] I [fuse-bridge.c:5599:fini] 0-fuse: Unmounting '/rhev/data-center/mnt/glusterSD/onode3.isaac.local:data02'. >> [2014-12-18 01:49:36.854339] I [MSGID: 100030] [glusterfsd.c:2018:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.6.1 (args: /usr/sbin/glusterfs - >> -volfile-server=onode3.isaac.local --volfile-id=data02 /rhev/data-center/mnt/glusterSD/onode3.isaac.local:data02) >> [2014-12-18 01:49:36.862887] I [dht-shared.c:337:dht_init_regex] 0-data02-dht: using regex rsync-hash-regex = ^\.(.+)\.[^.]+$ >> [2014-12-18 01:49:36.863749] I [client.c:2280:notify] 0-data02-client-0: parent translators are ready, attempting connect on transport > > So I thought I'd check /var/log/messages for potential sources of the > SIGTERM, and I found this: > >> Dec 18 02:43:26 onode3 kernel: supervdsmServer[1960]: segfault at 18 ip 00007faa89951bca sp 00007fa355b80f40 error 4 in libgfapi.so.0.0.0[7faa8994c000+18000] >> Dec 18 02:43:27 onode3 systemd: supervdsmd.service: main process exited, code=killed, status=11/SEGV >> Dec 18 02:43:27 onode3 systemd: Unit supervdsmd.service entered failed state. >> Dec 18 02:43:27 onode3 journal: vdsm jsonrpc.JsonRpcServer ERROR Internal server error >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 486, in _serveRequest >> res = method(**params) >> File "/usr/share/vdsm/rpc/Bridge.py", line 266, in _dynamicMethod >> result = fn(*methodArgs) >> File "/usr/share/vdsm/gluster/apiwrapper.py", line 106, in status >> return self._gluster.volumeStatus(volumeName, brick, statusOption) >> File "/usr/share/vdsm/gluster/api.py", line 54, in wrapper >> rv = func(*args, **kwargs) >> File "/usr/share/vdsm/gluster/api.py", line 221, in volumeStatus >> data = self.svdsmProxy.glusterVolumeStatvfs(volumeName) >> File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ >> return callMethod() >> File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> >> **kwargs) >> File "<string>", line 2, in glusterVolumeStatvfs >> File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in _callmethod >> kind, result = conn.recv() >> EOFError >> Dec 18 02:43:27 onode3 systemd: supervdsmd.service holdoff time over, scheduling restart. >> Dec 18 02:43:27 onode3 systemd: Stopping Virtual Desktop Server Manager... >> Dec 18 02:43:27 onode3 systemd: Stopping "Auxiliary vdsm service for running helper functions as root"... >> Dec 18 02:43:27 onode3 systemd: Starting "Auxiliary vdsm service for running helper functions as root"... >> Dec 18 02:43:27 onode3 systemd: Started "Auxiliary vdsm service for running helper functions as root". >> Dec 18 02:43:27 onode3 journal: vdsm IOProcessClient ERROR IOProcess failure >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 107, in _communicate >> raise Exception("FD closed") >> Exception: FD closed > > > I guess I'll file a bug report. > > Best regards, > Martijn Grendelman > > > > > > > Punit Dambiwal schreef op 12-12-2014 om 3:44: >> Hi Dan, >> >> Yes..it's glusterfs.... >> >> glusterfs logs :- http://ur1.ca/j3b5f >> >> OS Version: RHEL - 7 - 0.1406.el7.centos.2.3 >> Kernel Version: 3.10.0 - 123.el7.x86_64 >> KVM Version: 1.5.3 - 60.el7_0.2 >> LIBVIRT Version: libvirt-1.1.1-29.el7_0.3 >> VDSM Version: vdsm-4.16.7-1.gitdb83943.el7 >> GlusterFS Version: glusterfs-3.6.1-1.el7 >> Qemu Version : QEMU emulator version 1.5.3 (qemu-kvm-1.5.3-60.el7_0.2) >> >> Thanks, >> punit >> >> >> >> >> On Thu, Dec 11, 2014 at 5:47 PM, Dan Kenigsberg <danken(a)redhat.com >> <mailto:danken@redhat.com>> wrote: >> >> On Thu, Dec 11, 2014 at 03:41:01PM +0800, Punit Dambiwal wrote: >> > Hi, >> > >> > Suddenly all of my VM on one host paused with the following error :- >> > >> > vm has paused due to unknown storage error >> > >> > I am using glusterfs storage with distributed replicate >> replica=2....my >> > storage and compute both running on the same node... >> > >> > engine logs :- http://ur1.ca/j31iu >> > Host logs :- http://ur1.ca/j31kk (I grep it for one Failed VM) >> >> libvirtEventLoop::INFO::2014-12-11 >> 15:00:48,627::vm::4780::vm.Vm::(_onIOError) >> vmId=`e84bb987-a817-436a-9417-8eab9148e57e`::abnormal vm stop device >> virtio-disk0 error eother >> >> Which type of storage is it? gluster? Do you have anything in particular >> on glusterfs logs? >> >> Which glusterfs/qemu/libvirt/vdsm versions do you have installed? >> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >

1 0

rhevm engine Compilation failure
by QuantumCloud 18 Dec '14

18 Dec '14

This is a multi-part message in MIME format. ------=_NextPart_5492E389_096D8538_62357C89 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgZ3V5czoNCiAgICBJIHRlc3RlZCB0byBjb21wbGlsZSByaGV2bSBlbmdpbmUgZnJvbSBz b3VyY2UgcGtnLCBidXQgZ2V0IHNvbWUgZXJyb3IuDQogICBJIGhhdmUgdGVzdGVkIHdpdGgg c2FtZSB3YXkgaW4gb3ZpcnQgMy40LjQgYW5kIHJoZXZtIDMuNC4zLCB0aGVyZSB3YXMgbm8g ZXJyb3IsIGJ1dCBqdXN0IGluIHJoZXZtIDMuNC40IHdpdGggc29tZSBlcnJvcnM6DQogIA0K IFtJTkZPXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCltJTkZPXSAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CltJTkZPXSBCdWlsZGluZyBDb21tb24gdXRpbGl0aWVzIDMuNC40DQpbSU5GT10gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpbSU5GT10gDQpbSU5GT10gLS0tIG1hdmVuLWNsZWFuLXBsdWdpbjoy LjU6Y2xlYW4gKGRlZmF1bHQtY2xlYW4pIEAgdXRpbHMgLS0tDQpbSU5GT10gRGVsZXRpbmcg L3Jvb3QvcnBtYnVpbGQvU09VUkNFUy9vdmlydC1lbmdpbmUvYmFja2VuZC9tYW5hZ2VyL21v ZHVsZXMvdXRpbHMvdGFyZ2V0DQpbSU5GT10gDQpbSU5GT10gLS0tIG1hdmVuLXJlc291cmNl cy1wbHVnaW46Mi40LjM6cmVzb3VyY2VzIChkZWZhdWx0LXJlc291cmNlcykgQCB1dGlscyAt LS0NCltJTkZPXSBVc2luZyAnVVRGLTgnIGVuY29kaW5nIHRvIGNvcHkgZmlsdGVyZWQgcmVz b3VyY2VzLg0KW0lORk9dIENvcHlpbmcgMiByZXNvdXJjZXMNCltJTkZPXSANCltJTkZPXSAt LS0gbWF2ZW4tY29tcGlsZXItcGx1Z2luOjIuMy4yOmNvbXBpbGUgKGRlZmF1bHQtY29tcGls ZSkgQCB1dGlscyAtLS0NCltJTkZPXSBDb21waWxpbmcgMTYzIHNvdXJjZSBmaWxlcyB0byAv cm9vdC9ycG1idWlsZC9TT1VSQ0VTL292aXJ0LWVuZ2luZS9iYWNrZW5kL21hbmFnZXIvbW9k dWxlcy91dGlscy90YXJnZXQvY2xhc3Nlcw0KW0lORk9dIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCltFUlJPUl0gQ09N UElMQVRJT04gRVJST1IgOiANCltJTkZPXSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbRVJST1JdIC9yb290L3JwbWJ1 aWxkL1NPVVJDRVMvb3ZpcnQtZW5naW5lL2JhY2tlbmQvbWFuYWdlci9tb2R1bGVzL3V0aWxz L3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3V0aWxzL3BtL1Zkc0ZlbmNl T3B0aW9ucy5qYXZhOlszMjksNDRdIGVycm9yOiBjYW5ub3QgZmluZCBzeW1ib2wNCltJTkZP XSAxIGVycm9yDQpbSU5GT10gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0lORk9dIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K W0lORk9dIFJlYWN0b3IgU3VtbWFyeToNCltJTkZPXSANCltJTkZPXSBvdmlydC1yb290IC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMC4z MTEgc10NCltJTkZPXSBvVmlydCBCdWlsZCBUb29scyByb290IC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMC4wMTYgc10NCltJTkZPXSBvVmlydCBjaGVja3N0 eWxlIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMS4x NzYgc10NCltJTkZPXSBvVmlydCBKQm9zcyBNb2R1bGVzIE1hdmVuIFBsdWdpbiAuLi4uLi4u Li4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMy4xNDggc10NCltJTkZPXSBvVmlydCBDaGVja3N0 eWxlIENoZWNrcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMC44 NDkgc10NCltJTkZPXSBvVmlydCBNb2R1bGVzIC0gYmFja2VuZCAuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMC4wMTAgc10NCltJTkZPXSBvVmlydCBNYW5hZ2Vy IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMC4w MDkgc10NCltJTkZPXSBvVmlydCBFbmdpbmUgZGVwZW5kZW5jaWVzIC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMS4xMTMgc10NCltJTkZPXSBvVmlydCBNb2R1bGVz IC0gbWFuYWdlciAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMC43 NDEgc10NCltJTkZPXSBDU2hhcnAgQ29tcGF0aWJpbGl0eSAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIFNVQ0NFU1MgWyAgMi43ODkgc10NCltJTkZPXSBDb21tb24gdXRpbGl0 aWVzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIEZBSUxVUkUgWyAgMi45 NTYgc10NCltJTkZPXSBDb21tb24gQ29kZSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIFNLSVBQRUQNCltJTkZPXSBEYXRhIEFjY2VzcyBMYXllciAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQNCltJTkZPXSBWZHMgYnJva2Vy IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQNCltJ TkZPXSBlbmdpbmUgc2NoZWR1bGVyIGJlYW4gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uIFNLSVBQRUQNCltJTkZPXSBTZWFyY2ggQmFja2VuZCAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQNCltJTkZPXSBCYWNrZW5kIExvZ2ljIEBTZXJ2 aWNlIGJlYW4gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQNCltJTkZPXSBvVmly dCBSRVNUZnVsIEFQSSBCYWNrZW5kIEludGVncmF0aW9uIC4uLi4uLi4uLi4uLi4uIFNLSVBQ RUQNCltJTkZPXSBvVmlydCBSRVNUZnVsIEFQSSBCYWNrZW5kIEludGVncmF0aW9uIFR5cGUg TWFwcGVycyAuIFNLSVBQRUQNCltJTkZPXSBvVmlydCBSRVNUZnVsIEFQSSBCYWNrZW5kIElu dGVncmF0aW9uIEpBWC1SUyBSZXNvdXJjZXMgU0tJUFBFRA0KW0lORk9dIG9WaXJ0IFJFU1Rm dWwgQVBJIEJhY2tlbmQgSW50ZWdyYXRpb24gV2ViYXBwIC4uLi4uLi4gU0tJUFBFRA0KW0lO Rk9dIG9WaXJ0IFJFU1RmdWwgQVBJIGludGVyZmFjZSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4gU0tJUFBFRA0KW0lORk9dIG9WaXJ0IEVuZ2luZSBBUEkgRGVmaW5pdGlvbiAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIG9WaXJ0IEVuZ2luZSBBUEkgQ29t bW9tIFBhcmVudCBQT00gLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIG9WaXJ0 IEVuZ2luZSBBUEkgQ29tbW9uIEpBWC1SUyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBF RA0KW0lORk9dIG9WaXJ0IEVuZ2luZSBXZWIgUm9vdCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIEJyYW5kaW5nIHBhY2thZ2UgLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIG92aXJ0LWVuZ2luZSBz ZXJ2aWNlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9d IG9WaXJ0IEVuZ2luZSBXZWIgRG9jcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4g U0tJUFBFRA0KW0lORk9dIG92aXJ0LWVuZ2luZSB3ZWxjb21lIC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIEJhY2tlbmQgQXV0aGVudGljYXRpb24g Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIG9WaXJ0IEVu Z2luZSBUb29scyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0K W0lORk9dIG9WaXJ0IE1vZHVsZXMgOjogRnJvbnRlbmQgLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gU0tJUFBFRA0KW0lORk9dIG9WaXJ0IE1vZHVsZXMgOjogV2ViYWRtaW4gLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIG9WaXJ0IE1vZHVsZXMgLSB1 aSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIEV4 dGVuc2lvbnMgZm9yIEdXVCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJ UFBFRA0KW0lORk9dIFVJIFV0aWxzIENvbXBhdGliaWxpdHkgKGZvciBVSUNvbW1vbikgLi4u Li4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIEZyb250ZW5kIGZvciBHV1QgVUkgUHJvamVj dHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIFVJQ29tbW9uV2Vi IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lO Rk9dIG9WaXJ0IEdXVCBVSSBjb21tb24gaW5mcmFzdHJ1Y3R1cmUgLi4uLi4uLi4uLi4uLi4u Li4gU0tJUFBFRA0KW0lORk9dIFdlYkFkbWluIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIFVzZXJQb3J0YWwgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRA0KW0lORk9dIG9WaXJ0 IFNlcnZlciBFQVIgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBF RA0KW0lORk9dIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0lORk9dIEJVSUxEIEZBSUxVUkUNCltJ TkZPXSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCltJTkZPXSBUb3RhbCB0aW1lOiAxNC4zNDAgcw0K W0lORk9dIEZpbmlzaGVkIGF0OiAyMDE0LTEyLTE3VDIzOjExOjM1KzA4OjAwDQpbSU5GT10g RmluYWwgTWVtb3J5OiA1MU0vMjQ3TQ0KW0lORk9dIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0VS Uk9SXSBGYWlsZWQgdG8gZXhlY3V0ZSBnb2FsIG9yZy5hcGFjaGUubWF2ZW4ucGx1Z2luczpt YXZlbi1jb21waWxlci1wbHVnaW46Mi4zLjI6Y29tcGlsZSAoZGVmYXVsdC1jb21waWxlKSBv biBwcm9qZWN0IHV0aWxzOiBDb21waWxhdGlvbiBmYWlsdXJlDQpbRVJST1JdIC9yb290L3Jw bWJ1aWxkL1NPVVJDRVMvb3ZpcnQtZW5naW5lL2JhY2tlbmQvbWFuYWdlci9tb2R1bGVzL3V0 aWxzL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3V0aWxzL3BtL1Zkc0Zl bmNlT3B0aW9ucy5qYXZhOlszMjksNDRdIGVycm9yOiBjYW5ub3QgZmluZCBzeW1ib2wNCltF UlJPUl0gLT4gW0hlbHAgMV0NCltFUlJPUl0gDQpbRVJST1JdIFRvIHNlZSB0aGUgZnVsbCBz dGFjayB0cmFjZSBvZiB0aGUgZXJyb3JzLCByZS1ydW4gTWF2ZW4gd2l0aCB0aGUgLWUgc3dp dGNoLg0KW0VSUk9SXSBSZS1ydW4gTWF2ZW4gdXNpbmcgdGhlIC1YIHN3aXRjaCB0byBlbmFi bGUgZnVsbCBkZWJ1ZyBsb2dnaW5nLg0KW0VSUk9SXSANCltFUlJPUl0gRm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGVycm9ycyBhbmQgcG9zc2libGUgc29sdXRpb25zLCBwbGVh c2UgcmVhZCB0aGUgZm9sbG93aW5nIGFydGljbGVzOg0KW0VSUk9SXSBbSGVscCAxXSBodHRw Oi8vY3dpa2kuYXBhY2hlLm9yZy9jb25mbHVlbmNlL2Rpc3BsYXkvTUFWRU4vTW9qb0ZhaWx1 cmVFeGNlcHRpb24NCltFUlJPUl0gDQpbRVJST1JdIEFmdGVyIGNvcnJlY3RpbmcgdGhlIHBy b2JsZW1zLCB5b3UgY2FuIHJlc3VtZSB0aGUgYnVpbGQgd2l0aCB0aGUgY29tbWFuZA0KW0VS Uk9SXSAgIG12biA8Z29hbHM+IC1yZiA6dXRpbHMNCiAgDQogc29tZSBjb2RlIG9mIGVycm9y IGZpbGUgVmRzRmVuY2VPcHRpb25zLmphdmE6IChJIGhhdmUgbm90IGNoYW5nZWQgYW55IGNv ZGVzKQ0KIC4uLg0KIDMxOSAgICAgLyoqDQozMjAgICAgICAqIGhhbmRsZXMgYWdlbnQgZGVm YXVsdCBvcHRpb25zDQozMjEgICAgICAqDQozMjIgICAgICAqIEBwYXJhbSBhZ2VudA0KMzIz ICAgICAgKiBAcGFyYW0gZmVuY2VPcHRpb25zDQozMjQgICAgICAqIEByZXR1cm4gU3RyaW5n IHRoZSBvcHRpb25zIGFmdGVyIGFkZGluZyBkZWZhdWx0IGFnZW50IHBhcmFtZXRlcnMNCjMy NSAgICAgICovDQozMjYgICAgIHB1YmxpYyBzdGF0aWMgU3RyaW5nIGdldERlZmF1bHRBZ2Vu dE9wdGlvbnMoU3RyaW5nIGFnZW50LCBTdHJpbmcgZmVuY2VPcHRpb25zLCAgQXJjaGl0ZWN0 dXJlVHlwZSBhcmNoaXRlY3R1cmVUeXBlKSB7DQozMjcgICAgICAgICBTdHJpbmcgYWdlbnRE ZWZhdWx0UGFyYW1zID0gIChhcmNoaXRlY3R1cmVUeXBlICE9IG51bGwgJiYgYXJjaGl0ZWN0 dXJlVHlwZSA9PSBBcmNoaXRlY3R1cmVUeXBlLnBwYzY0KQ0KMzI4ICAgICAgICAgICAgICAg ICA/DQozMjkgICAgICAgICAgICAgICAgIENvbmZpZy5nZXRWYWx1ZShDb25maWdWYWx1ZXMu RmVuY2VBZ2VudERlZmF1bHRQYXJhbXNGb3JQUEMsIENvbmZpZ0NvbW1vbi5kZWZhdWx0Q29u ZmlndXJhdGlvblZlcnNpb24pLnRvU3RyaW5nKCkNCjMzMCAgICAgICAgICAgICAgICAgOg0K MzMxICAgICAgICAgICAgICAgICBDb25maWcuZ2V0VmFsdWUoQ29uZmlnVmFsdWVzLkZlbmNl QWdlbnREZWZhdWx0UGFyYW1zLCBDb25maWdDb21tb24uZGVmYXVsdENvbmZpZ3VyYXRpb25W ZXJzaW9uKS50b1N0cmluZygpOw0KMzMyIC4uLg0KICANCiBNeSBjb21waWxhdGlvbiB0b29s cyBlbnY6DQogW3Jvb3RAbG9jYWxob3N0IH5dIyBtdm4gLXYNCkFwYWNoZSBNYXZlbiAzLjIu MyAoMzNmOGMzZTEwMjdjM2RkZGU5OWQzY2RlYmFkMjY1NmEzMWU4ZmRmNDsgMjAxNC0wOC0x MlQwNDo1ODoxMCswODowMCkNCk1hdmVuIGhvbWU6IC9hcGFjaGUtbWF2ZW4NCkphdmEgdmVy c2lvbjogMS43LjBfNzEsIHZlbmRvcjogT3JhY2xlIENvcnBvcmF0aW9uDQpKYXZhIGhvbWU6 IC91c3IvbGliL2p2bS9qYXZhLTEuNy4wLW9wZW5qZGstMS43LjAuNzEueDg2XzY0L2pyZQ0K RGVmYXVsdCBsb2NhbGU6IGVuX1VTLCBwbGF0Zm9ybSBlbmNvZGluZzogVVRGLTgNCk9TIG5h bWU6ICJsaW51eCIsIHZlcnNpb246ICIyLjYuMzItNTA0LjEuMy5lbDYueDg2XzY0IiwgYXJj aDogImFtZDY0IiwgZmFtaWx5OiAidW5peCINCiAgDQogYWxzbyBJIGhhdmUgdGVzdCBkaWZm ZXJlbnQgdG9vbHM6DQogbWF2ZW4gMy4wLjUgKyBqYXZhIDEuNy4wLjQ1DQogIG1hdmVuIDMu MC41ICsgamF2YSAxLjcuMC43MSANCiAgbWF2ZW4gMy4xLjEgKyBqYXZhIDEuNy4wLjQ1IA0K ICBtYXZlbiAzLjEuMSArIGphdmEgMS43LjAuNzEgDQogIG1hdmVuIDMuMi4zICsgamF2YSAx LjcuMC40NQ0KICBtYXZlbiAzLjIuMyArIGphdmEgMS43LjAuNzENCiAgDQogYWxsIGFib3Zl IGhhZCB0aGUgc2FtZSBlcnJvci4NCiAgDQogV2hvIGNhbiBnaXZlIHNvbWUgaWRlYSB0byBm aXggaXQ/ ------=_NextPart_5492E389_096D8538_62357C89 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PERJVj48QlI+Jm5ic3A7PC9ESVY+DQo8RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMzMzMzMz PkhpIGd1eXM6PC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgY29sb3I9IzMzMzMz Mz4mbmJzcDsgSSB0ZXN0ZWQgdG8gY29tcGxpbGUgcmhldm0gPFNUUk9ORz5lbmdpbmU8L1NU Uk9ORz4gZnJvbSBzb3VyY2UgcGtnLCBidXQgZ2V0IHNvbWUgZXJyb3IuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMzMzMzMzPiZuYnNwOyBJIGhhdmUgdGVzdGVkIHdpdGgg c2FtZSB3YXkgaW4gb3ZpcnQgMy40LjQgYW5kIHJoZXZtIDMuNC4zLCB0aGVyZSB3YXMgbm8g ZXJyb3IsIGJ1dCBqdXN0IGluIHJoZXZtIDMuNC40IHdpdGggc29tZSBlcnJvcnM6PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMzMzMzMzPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+W0lORk9dJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgPEJSPltJTkZPXSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+W0lORk9dIEJ1aWxkaW5nIENv bW1vbiB1dGlsaXRpZXMgMy40LjQ8QlI+W0lORk9dIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5b SU5GT10gPEJSPltJTkZPXSAtLS0gbWF2ZW4tY2xlYW4tcGx1Z2luOjIuNTpjbGVhbiAoZGVm YXVsdC1jbGVhbikgQCB1dGlscyAtLS08QlI+W0lORk9dIERlbGV0aW5nIC9yb290L3JwbWJ1 aWxkL1NPVVJDRVMvb3ZpcnQtZW5naW5lL2JhY2tlbmQvbWFuYWdlci9tb2R1bGVzL3V0aWxz L3RhcmdldDxCUj5bSU5GT10gPEJSPltJTkZPXSAtLS0gbWF2ZW4tcmVzb3VyY2VzLXBsdWdp bjoyLjQuMzpyZXNvdXJjZXMgKGRlZmF1bHQtcmVzb3VyY2VzKSBAIHV0aWxzIC0tLTxCUj5b SU5GT10gVXNpbmcgJ1VURi04JyBlbmNvZGluZyB0byBjb3B5IGZpbHRlcmVkIHJlc291cmNl cy48QlI+W0lORk9dIENvcHlpbmcgMiByZXNvdXJjZXM8QlI+W0lORk9dIDxCUj5bSU5GT10g LS0tIG1hdmVuLWNvbXBpbGVyLXBsdWdpbjoyLjMuMjpjb21waWxlIChkZWZhdWx0LWNvbXBp bGUpIEAgdXRpbHMgLS0tPEJSPltJTkZPXSBDb21waWxpbmcgMTYzIHNvdXJjZSBmaWxlcyB0 byAvcm9vdC9ycG1idWlsZC9TT1VSQ0VTL292aXJ0LWVuZ2luZS9iYWNrZW5kL21hbmFnZXIv bW9kdWxlcy91dGlscy90YXJnZXQvY2xhc3NlczxCUj5bSU5GT10gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5bRVJS T1JdIENPTVBJTEFUSU9OIEVSUk9SIDogPEJSPltJTkZPXSAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPltFUlJPUl0g L3Jvb3QvcnBtYnVpbGQvU09VUkNFUy9vdmlydC1lbmdpbmUvYmFja2VuZC9tYW5hZ2VyL21v ZHVsZXMvdXRpbHMvc3JjL21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL2NvcmUvdXRpbHMv cG0vVmRzRmVuY2VPcHRpb25zLmphdmE6WzMyOSw0NF0gZXJyb3I6IGNhbm5vdCBmaW5kIHN5 bWJvbDxCUj5bSU5GT10gMSBlcnJvcjxCUj5bSU5GT10gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5bSU5GT10gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPEJSPltJTkZPXSBSZWFjdG9yIFN1bW1hcnk6PEJSPltJTkZPXSA8 QlI+W0lORk9dIG92aXJ0LXJvb3QgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4gU1VDQ0VTUyBbJm5ic3A7IDAuMzExIHNdPEJSPltJTkZPXSBvVmlydCBCdWls ZCBUb29scyByb290IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyZu YnNwOyAwLjAxNiBzXTxCUj5bSU5GT10gb1ZpcnQgY2hlY2tzdHlsZSAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiBTVUNDRVNTIFsmbmJzcDsgMS4xNzYgc108QlI+W0lO Rk9dIG9WaXJ0IEpCb3NzIE1vZHVsZXMgTWF2ZW4gUGx1Z2luIC4uLi4uLi4uLi4uLi4uLi4u Li4gU1VDQ0VTUyBbJm5ic3A7IDMuMTQ4IHNdPEJSPltJTkZPXSBvVmlydCBDaGVja3N0eWxl IENoZWNrcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyZuYnNwOyAw Ljg0OSBzXTxCUj5bSU5GT10gb1ZpcnQgTW9kdWxlcyAtIGJhY2tlbmQgLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiBTVUNDRVNTIFsmbmJzcDsgMC4wMTAgc108QlI+W0lORk9dIG9W aXJ0IE1hbmFnZXIgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU1VD Q0VTUyBbJm5ic3A7IDAuMDA5IHNdPEJSPltJTkZPXSBvVmlydCBFbmdpbmUgZGVwZW5kZW5j aWVzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNVQ0NFU1MgWyZuYnNwOyAxLjExMyBz XTxCUj5bSU5GT10gb1ZpcnQgTW9kdWxlcyAtIG1hbmFnZXIgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLiBTVUNDRVNTIFsmbmJzcDsgMC43NDEgc108QlI+W0lORk9dIENTaGFycCBD b21wYXRpYmlsaXR5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU1VDQ0VTUyBb Jm5ic3A7IDIuNzg5IHNdPEJSPltJTkZPXSBDb21tb24gdXRpbGl0aWVzIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIEZBSUxVUkUgWyZuYnNwOyAyLjk1NiBzXTxCUj5b SU5GT10gQ29tbW9uIENvZGUgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLiBTS0lQUEVEPEJSPltJTkZPXSBEYXRhIEFjY2VzcyBMYXllciAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8QlI+W0lORk9dIFZkcyBicm9rZXIgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRDxCUj5bSU5G T10gZW5naW5lIHNjaGVkdWxlciBiZWFuIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LiBTS0lQUEVEPEJSPltJTkZPXSBTZWFyY2ggQmFja2VuZCAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8QlI+W0lORk9dIEJhY2tlbmQgTG9naWMgQFNl cnZpY2UgYmVhbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBFRDxCUj5bSU5GT10g b1ZpcnQgUkVTVGZ1bCBBUEkgQmFja2VuZCBJbnRlZ3JhdGlvbiAuLi4uLi4uLi4uLi4uLiBT S0lQUEVEPEJSPltJTkZPXSBvVmlydCBSRVNUZnVsIEFQSSBCYWNrZW5kIEludGVncmF0aW9u IFR5cGUgTWFwcGVycyAuIFNLSVBQRUQ8QlI+W0lORk9dIG9WaXJ0IFJFU1RmdWwgQVBJIEJh Y2tlbmQgSW50ZWdyYXRpb24gSkFYLVJTIFJlc291cmNlcyBTS0lQUEVEPEJSPltJTkZPXSBv VmlydCBSRVNUZnVsIEFQSSBCYWNrZW5kIEludGVncmF0aW9uIFdlYmFwcCAuLi4uLi4uIFNL SVBQRUQ8QlI+W0lORk9dIG9WaXJ0IFJFU1RmdWwgQVBJIGludGVyZmFjZSAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4gU0tJUFBFRDxCUj5bSU5GT10gb1ZpcnQgRW5naW5lIEFQSSBEZWZp bml0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBTS0lQUEVEPEJSPltJTkZPXSBvVmly dCBFbmdpbmUgQVBJIENvbW1vbSBQYXJlbnQgUE9NIC4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQ RUQ8QlI+W0lORk9dIG9WaXJ0IEVuZ2luZSBBUEkgQ29tbW9uIEpBWC1SUyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4gU0tJUFBFRDxCUj5bSU5GT10gb1ZpcnQgRW5naW5lIFdlYiBSb290IC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBTS0lQUEVEPEJSPltJTkZPXSBCcmFuZGlu ZyBwYWNrYWdlIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8 QlI+W0lORk9dIG92aXJ0LWVuZ2luZSBzZXJ2aWNlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4gU0tJUFBFRDxCUj5bSU5GT10gb1ZpcnQgRW5naW5lIFdlYiBEb2NzIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBTS0lQUEVEPEJSPltJTkZPXSBvdmlydC1lbmdp bmUgd2VsY29tZSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8QlI+ W0lORk9dIEJhY2tlbmQgQXV0aGVudGljYXRpb24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gU0tJUFBFRDxCUj5bSU5GT10gb1ZpcnQgRW5naW5lIFRvb2xzIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiBTS0lQUEVEPEJSPltJTkZPXSBvVmlydCBNb2R1bGVz IDo6IEZyb250ZW5kIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8QlI+W0lO Rk9dIG9WaXJ0IE1vZHVsZXMgOjogV2ViYWRtaW4gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4gU0tJUFBFRDxCUj5bSU5GT10gb1ZpcnQgTW9kdWxlcyAtIHVpIC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLiBTS0lQUEVEPEJSPltJTkZPXSBFeHRlbnNpb25zIGZvciBH V1QgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8QlI+W0lORk9d IFVJIFV0aWxzIENvbXBhdGliaWxpdHkgKGZvciBVSUNvbW1vbikgLi4uLi4uLi4uLi4uLi4g U0tJUFBFRDxCUj5bSU5GT10gRnJvbnRlbmQgZm9yIEdXVCBVSSBQcm9qZWN0cyAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiBTS0lQUEVEPEJSPltJTkZPXSBVSUNvbW1vbldlYiAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8QlI+W0lORk9dIG9W aXJ0IEdXVCBVSSBjb21tb24gaW5mcmFzdHJ1Y3R1cmUgLi4uLi4uLi4uLi4uLi4uLi4gU0tJ UFBFRDxCUj5bSU5GT10gV2ViQWRtaW4gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiBTS0lQUEVEPEJSPltJTkZPXSBVc2VyUG9ydGFsIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFNLSVBQRUQ8QlI+W0lORk9dIG9WaXJ0 IFNlcnZlciBFQVIgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gU0tJUFBF RDxCUj5bSU5GT10gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPltJTkZPXSBCVUlMRCBGQUlMVVJF PEJSPltJTkZPXSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+W0lORk9dIFRvdGFsIHRpbWU6IDE0 LjM0MCBzPEJSPltJTkZPXSBGaW5pc2hlZCBhdDogMjAxNC0xMi0xN1QyMzoxMTozNSswODow MDxCUj5bSU5GT10gRmluYWwgTWVtb3J5OiA1MU0vMjQ3TTxCUj5bSU5GT10gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPEJSPltFUlJPUl0gRmFpbGVkIHRvIGV4ZWN1dGUgZ29hbCBvcmcuYXBhY2hl Lm1hdmVuLnBsdWdpbnM6bWF2ZW4tY29tcGlsZXItcGx1Z2luOjIuMy4yOmNvbXBpbGUgKGRl ZmF1bHQtY29tcGlsZSkgb24gcHJvamVjdCB1dGlsczogQ29tcGlsYXRpb24gZmFpbHVyZTxC Uj5bRVJST1JdIC9yb290L3JwbWJ1aWxkL1NPVVJDRVMvb3ZpcnQtZW5naW5lL2JhY2tlbmQv bWFuYWdlci9tb2R1bGVzL3V0aWxzL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS9j b3JlL3V0aWxzL3BtL1Zkc0ZlbmNlT3B0aW9ucy5qYXZhOlszMjksNDRdIGVycm9yOiBjYW5u b3QgZmluZCBzeW1ib2w8QlI+W0VSUk9SXSAtJmd0OyBbSGVscCAxXTxCUj5bRVJST1JdIDxC Uj5bRVJST1JdIFRvIHNlZSB0aGUgZnVsbCBzdGFjayB0cmFjZSBvZiB0aGUgZXJyb3JzLCBy ZS1ydW4gTWF2ZW4gd2l0aCB0aGUgLWUgc3dpdGNoLjxCUj5bRVJST1JdIFJlLXJ1biBNYXZl biB1c2luZyB0aGUgLVggc3dpdGNoIHRvIGVuYWJsZSBmdWxsIGRlYnVnIGxvZ2dpbmcuPEJS PltFUlJPUl0gPEJSPltFUlJPUl0gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGVy cm9ycyBhbmQgcG9zc2libGUgc29sdXRpb25zLCBwbGVhc2UgcmVhZCB0aGUgZm9sbG93aW5n IGFydGljbGVzOjxCUj5bRVJST1JdIFtIZWxwIDFdIDxBIGhyZWY9Imh0dHA6Ly9jd2lraS5h cGFjaGUub3JnL2NvbmZsdWVuY2UvZGlzcGxheS9NQVZFTi9Nb2pvRmFpbHVyZUV4Y2VwdGlv biI+aHR0cDovL2N3aWtpLmFwYWNoZS5vcmcvY29uZmx1ZW5jZS9kaXNwbGF5L01BVkVOL01v am9GYWlsdXJlRXhjZXB0aW9uPC9BPjxCUj5bRVJST1JdIDxCUj5bRVJST1JdIEFmdGVyIGNv cnJlY3RpbmcgdGhlIHByb2JsZW1zLCB5b3UgY2FuIHJlc3VtZSB0aGUgYnVpbGQgd2l0aCB0 aGUgY29tbWFuZDxCUj5bRVJST1JdICZuYnNwOyBtdm4gJmx0O2dvYWxzJmd0OyAtcmYgOnV0 aWxzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5zb21lIGNvZGUgb2YgZXJyb3Ig ZmlsZSA8U1RST05HPlZkc0ZlbmNlT3B0aW9ucy5qYXZhPC9TVFJPTkc+OiAoSSBoYXZlIG5v dCBjaGFuZ2VkIGFueSBjb2Rlcyk8L0RJVj4NCjxESVY+Li4uPC9ESVY+DQo8RElWPjMxOSAm bmJzcDsgJm5ic3A7IC8qKjxCUj4zMjAmbmJzcDsgJm5ic3A7ICZuYnNwOyAqIGhhbmRsZXMg YWdlbnQgZGVmYXVsdCBvcHRpb25zPEJSPjMyMSZuYnNwOyAmbmJzcDsgJm5ic3A7ICo8QlI+ MzIyJm5ic3A7ICZuYnNwOyAmbmJzcDsgKiBAcGFyYW0gYWdlbnQ8QlI+MzIzJm5ic3A7ICZu YnNwOyAmbmJzcDsgKiBAcGFyYW0gZmVuY2VPcHRpb25zPEJSPjMyNCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICogQHJldHVybiBTdHJpbmcgdGhlIG9wdGlvbnMgYWZ0ZXIgYWRkaW5nIGRlZmF1 bHQgYWdlbnQgcGFyYW1ldGVyczxCUj4zMjUmbmJzcDsgJm5ic3A7ICZuYnNwOyAqLzxCUj4z MjYgJm5ic3A7ICZuYnNwOyBwdWJsaWMgc3RhdGljIFN0cmluZyBnZXREZWZhdWx0QWdlbnRP cHRpb25zKFN0cmluZyBhZ2VudCwgU3RyaW5nIGZlbmNlT3B0aW9ucywmbmJzcDsgQXJjaGl0 ZWN0dXJlVHlwZSBhcmNoaXRlY3R1cmVUeXBlKSB7PEJSPjMyNyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFN0cmluZyBhZ2VudERlZmF1bHRQYXJhbXMgPSZuYnNw OyAoYXJjaGl0ZWN0dXJlVHlwZSAhPSBudWxsICZhbXA7JmFtcDsgYXJjaGl0ZWN0dXJlVHlw ZSA9PSBBcmNoaXRlY3R1cmVUeXBlLnBwYzY0KTxCUj4zMjgmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyA/PEJSPjMyOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7 IENvbmZpZy5nZXRWYWx1ZShDb25maWdWYWx1ZXMuRmVuY2VBZ2VudERlZmF1bHRQYXJhbXNG b3JQUEMsIENvbmZpZ0NvbW1vbi5kZWZhdWx0Q29uZmlndXJhdGlvblZlcnNpb24pLnRvU3Ry aW5nKCk8QlI+MzMwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgOjxCUj4zMzEm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb25maWcuZ2V0VmFsdWUoQ29uZmln VmFsdWVzLkZlbmNlQWdlbnREZWZhdWx0UGFyYW1zLCBDb25maWdDb21tb24uZGVmYXVsdENv bmZpZ3VyYXRpb25WZXJzaW9uKS50b1N0cmluZygpOzxCUj4zMzIgLi4uPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5NeSBjb21waWxhdGlvbiB0b29scyBlbnY6PC9ESVY+DQo8 RElWPltyb290QGxvY2FsaG9zdCB+XSMgbXZuIC12PEJSPkFwYWNoZSBNYXZlbiAzLjIuMyAo MzNmOGMzZTEwMjdjM2RkZGU5OWQzY2RlYmFkMjY1NmEzMWU4ZmRmNDsgMjAxNC0wOC0xMlQw NDo1ODoxMCswODowMCk8QlI+TWF2ZW4gaG9tZTogL2FwYWNoZS1tYXZlbjxCUj5KYXZhIHZl cnNpb246IDEuNy4wXzcxLCB2ZW5kb3I6IE9yYWNsZSBDb3Jwb3JhdGlvbjxCUj5KYXZhIGhv bWU6IC91c3IvbGliL2p2bS9qYXZhLTEuNy4wLW9wZW5qZGstMS43LjAuNzEueDg2XzY0L2py ZTxCUj5EZWZhdWx0IGxvY2FsZTogZW5fVVMsIHBsYXRmb3JtIGVuY29kaW5nOiBVVEYtODxC Uj5PUyBuYW1lOiAibGludXgiLCB2ZXJzaW9uOiAiMi42LjMyLTUwNC4xLjMuZWw2Lng4Nl82 NCIsIGFyY2g6ICJhbWQ2NCIsIGZhbWlseTogInVuaXgiPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5hbHNvIEkgaGF2ZSB0ZXN0IGRpZmZlcmVudCB0b29sczo8L0RJVj4NCjxE SVY+bWF2ZW4gMy4wLjUgKyBqYXZhIDEuNy4wLjQ1PC9ESVY+DQo8RElWPg0KPERJVj5tYXZl biAzLjAuNSArIGphdmEgMS43LjAuNzEgPC9ESVY+DQo8RElWPg0KPERJVj5tYXZlbiAzLjEu MSArIGphdmEgMS43LjAuNDUgPC9ESVY+DQo8RElWPg0KPERJVj5tYXZlbiAzLjEuMSArIGph dmEgMS43LjAuNzEgPC9ESVY+DQo8RElWPg0KPERJVj5tYXZlbiAzLjIuMyArIGphdmEgMS43 LjAuNDU8L0RJVj4NCjxESVY+DQo8RElWPm1hdmVuIDMuMi4zICsgamF2YSAxLjcuMC43MTwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+YWxsIGFib3ZlIGhhZCB0aGUgc2FtZSBl cnJvci48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPldobyBjYW4gZ2l2ZSBzb21l IGlkZWEgdG8gZml4IGl0PzwvRElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj48 L0RJVj48L0RJVj48L0RJVj4NCjxESVY+PC9ESVY+PC9ESVY+DQo8RElWPjwvRElWPjwvRElW Pg== ------=_NextPart_5492E389_096D8538_62357C89--

1 0

Re: [ovirt-users] vm has paused due to unknown storage error
by Martijn Grendelman 18 Dec '14

18 Dec '14

Hi, On a new host, I am running into exactly the same scenario. I have a host with an oVirt-managed GlusterFS volume (single brick on local disk in distribute mode) on an XFS file system. I think I have found the root cause, but I doubt I can fix it. Around the time of the VMs going paused, there seemed to be a glusterfsd restart: > [2014-12-18 01:43:27.272235] W [glusterfsd.c:1194:cleanup_and_exit] (--> 0-: received signum (15), shutting down > [2014-12-18 01:43:27.272279] I [fuse-bridge.c:5599:fini] 0-fuse: Unmounting '/rhev/data-center/mnt/glusterSD/onode3.isaac.local:data02'. > [2014-12-18 01:49:36.854339] I [MSGID: 100030] [glusterfsd.c:2018:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.6.1 (args: /usr/sbin/glusterfs - > -volfile-server=onode3.isaac.local --volfile-id=data02 /rhev/data-center/mnt/glusterSD/onode3.isaac.local:data02) > [2014-12-18 01:49:36.862887] I [dht-shared.c:337:dht_init_regex] 0-data02-dht: using regex rsync-hash-regex = ^\.(.+)\.[^.]+$ > [2014-12-18 01:49:36.863749] I [client.c:2280:notify] 0-data02-client-0: parent translators are ready, attempting connect on transport So I thought I'd check /var/log/messages for potential sources of the SIGTERM, and I found this: > Dec 18 02:43:26 onode3 kernel: supervdsmServer[1960]: segfault at 18 ip 00007faa89951bca sp 00007fa355b80f40 error 4 in libgfapi.so.0.0.0[7faa8994c000+18000] > Dec 18 02:43:27 onode3 systemd: supervdsmd.service: main process exited, code=killed, status=11/SEGV > Dec 18 02:43:27 onode3 systemd: Unit supervdsmd.service entered failed state. > Dec 18 02:43:27 onode3 journal: vdsm jsonrpc.JsonRpcServer ERROR Internal server error > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 486, in _serveRequest > res = method(**params) > File "/usr/share/vdsm/rpc/Bridge.py", line 266, in _dynamicMethod > result = fn(*methodArgs) > File "/usr/share/vdsm/gluster/apiwrapper.py", line 106, in status > return self._gluster.volumeStatus(volumeName, brick, statusOption) > File "/usr/share/vdsm/gluster/api.py", line 54, in wrapper > rv = func(*args, **kwargs) > File "/usr/share/vdsm/gluster/api.py", line 221, in volumeStatus > data = self.svdsmProxy.glusterVolumeStatvfs(volumeName) > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > return callMethod() > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > **kwargs) > File "<string>", line 2, in glusterVolumeStatvfs > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in _callmethod > kind, result = conn.recv() > EOFError > Dec 18 02:43:27 onode3 systemd: supervdsmd.service holdoff time over, scheduling restart. > Dec 18 02:43:27 onode3 systemd: Stopping Virtual Desktop Server Manager... > Dec 18 02:43:27 onode3 systemd: Stopping "Auxiliary vdsm service for running helper functions as root"... > Dec 18 02:43:27 onode3 systemd: Starting "Auxiliary vdsm service for running helper functions as root"... > Dec 18 02:43:27 onode3 systemd: Started "Auxiliary vdsm service for running helper functions as root". > Dec 18 02:43:27 onode3 journal: vdsm IOProcessClient ERROR IOProcess failure > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 107, in _communicate > raise Exception("FD closed") > Exception: FD closed I guess I'll file a bug report. Best regards, Martijn Grendelman Punit Dambiwal schreef op 12-12-2014 om 3:44: > Hi Dan, > > Yes..it's glusterfs.... > > glusterfs logs :- http://ur1.ca/j3b5f > > OS Version: RHEL - 7 - 0.1406.el7.centos.2.3 > Kernel Version: 3.10.0 - 123.el7.x86_64 > KVM Version: 1.5.3 - 60.el7_0.2 > LIBVIRT Version: libvirt-1.1.1-29.el7_0.3 > VDSM Version: vdsm-4.16.7-1.gitdb83943.el7 > GlusterFS Version: glusterfs-3.6.1-1.el7 > Qemu Version : QEMU emulator version 1.5.3 (qemu-kvm-1.5.3-60.el7_0.2) > > Thanks, > punit > > > > > On Thu, Dec 11, 2014 at 5:47 PM, Dan Kenigsberg <danken(a)redhat.com > <mailto:danken@redhat.com>> wrote: > > On Thu, Dec 11, 2014 at 03:41:01PM +0800, Punit Dambiwal wrote: > > Hi, > > > > Suddenly all of my VM on one host paused with the following error :- > > > > vm has paused due to unknown storage error > > > > I am using glusterfs storage with distributed replicate > replica=2....my > > storage and compute both running on the same node... > > > > engine logs :- http://ur1.ca/j31iu > > Host logs :- http://ur1.ca/j31kk (I grep it for one Failed VM) > > libvirtEventLoop::INFO::2014-12-11 > 15:00:48,627::vm::4780::vm.Vm::(_onIOError) > vmId=`e84bb987-a817-436a-9417-8eab9148e57e`::abnormal vm stop device > virtio-disk0 error eother > > Which type of storage is it? gluster? Do you have anything in particular > on glusterfs logs? > > Which glusterfs/qemu/libvirt/vdsm versions do you have installed? > >

1 0