Can not connect to Storage domain data
by Yue, Cong
--_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><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">I successfully deployed the first ovirt host with ho=
sted-engine –deploy. Engine VM works well.<o:p></o:p></p>
<p class=3D"MsoNormal">While, when I try to create the second host with the=
same way as the guide of
<o:p></o:p></p>
<p class=3D"MsoNormal"><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></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">I am not using GlusterFS, and just use one external =
storage(nfs) in my environment.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">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>
<p class=3D"MsoNormal">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></p>
<p class=3D"MsoNormal"><a href=3D"http://www.ovirt.org/Troubleshooting_NFS_=
Storage_Issues">http://www.ovirt.org/Troubleshooting_NFS_Storage_Issues</a>=
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">During deployment of the second host, how the data d=
omain is trying to be mounted?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<br>
<hr>
<font face=3D"Arial" color=3D"Gray" size=3D"1">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.<br>
</font>
</body>
</html>
--_000_ED08B56256B38842A463A2A0804C5AC0326ACA4574svrcaexch1atg_--
10 years
architecture of ovirt in case of using hosted-engine
by Yue, Cong
--_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><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">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></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">I am using hosted-engine to try to do this.<o:p></o:=
p></p>
<p class=3D"MsoNormal">When I try to deploy the second ovirt node. <o:p></o=
:p></p>
<p class=3D"MsoNormal">I did <o:p></o:p></p>
<p class=3D"MsoNormal">Hosted-engine –deploy<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">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></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">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></p>
<p class=3D"MsoNormal">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></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">Cong<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<br>
<hr>
<font face=3D"Arial" color=3D"Gray" size=3D"1">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.<br>
</font>
</body>
</html>
--_000_ED08B56256B38842A463A2A0804C5AC0326ACA451Csvrcaexch1atg_--
10 years
Problem with installing second host for hosted_engine (3.5)
by Otto Strassen
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
10 years
IPv6 Functionality for WebSocket Proxy
by Donny Davis
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><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Lucida Console";
panose-1:2 11 6 9 4 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>I just =
realized this morning that my noVNC connections were not working for =
IPv6 only on cloudspin.me<o:p></o:p></p><p class=3DMsoNormal>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></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>NGINX is a =
useful tool :)<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>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></p><p class=3DMsoNormal>Anyways, here is =
the fix<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>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></p><p class=3DMsoNormal>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></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida Console"'>server =
{<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> 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></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> #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></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> 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></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> ssl_certificate=
=
/physical/path/to/ssl/cert; #I used the same cert that my websocket =
proxy is using<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> =
ssl_certificate_key =
/physical/path/to/ssl/key;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> ssl =
on;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> =
ssl_session_cache builtin:1000 =
shared:SSL:10m;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> ssl_protocols =
TLSv1 TLSv1.1 TLSv1.2;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> ssl_ciphers =
HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;<o:p></o:p></spa=
n></p><p class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida Console"'> =
ssl_prefer_server_ciphers =
on;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> access_log =
/var/log/nginx/websocket.cloudspin.me-access.log;<o:p></o:p></span></p><p=
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> error_log =
/var/log/nginx/websocket.cloudspin.me-error.log;<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> location / =
{<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> &nb=
sp; proxy_pass =
https://ip_address_of_websocket_proxy:6100;<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> =
proxy_http_version 1.1;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> =
proxy_set_header Upgrade $http_upgrade;<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> =
proxy_set_header Connection "upgrade";<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> &nb=
sp; <o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> }<o:p></o:p></s=
pan></p><p class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'> }<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida Console"'>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></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida Console"'>Cheers and I =
hope this helps<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida Console"'>If anyone needs =
any help getting this to work give me a shout<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'><o:p> </o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida Console"'>Donny =
D<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Lucida =
Console"'>cloudspin.me<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p></div></body></html>
------=_NextPart_000_02AD_01D01AA1.DD69F530--
10 years
Get involved in oVirt project! Xmas edition
by Sandro Bonazzola
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
10 years
NUMA and non-NUMA nodes and migration
by Chris Adams
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>
10 years
Re: [ovirt-users] vm has paused due to unknown storage error
by Martijn Grendelman
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
>
10 years
rhevm engine Compilation failure
by QuantumCloud
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--
10 years
Re: [ovirt-users] vm has paused due to unknown storage error
by Martijn Grendelman
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?
>
>
10 years
oVirt Weekly Sync Meeting: Dec. 17, 2014
by Brian Proffitt
=========================
#ovirt: oVirt Weekly Sync
=========================
Meeting started by bkp at 15:06:03 UTC. The full logs are available at
http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-17-15.06.log.html .
Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-17-15.06.html
Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-17-15.06.txt
Meeting summary
---------------
* Agenda and Roll Call (bkp, 15:06:23)
* infra update (bkp, 15:06:23)
* 3.5.z updates (bkp, 15:06:23)
* 3.6.0 status (bkp, 15:06:23)
* conferences and workshops (bkp, 15:06:23)
* other topics (bkp, 15:06:26)
* infra update (bkp, 15:07:42)
* LINK:
http://lists.centos.org/pipermail/centos-virt/2014-December/004187.html
(sbonazzo, 15:22:07)
* infra update Console access gained to the PHX hosts, and they are
now back up. (bkp, 15:23:09)
* infra update First nested job is working (thanks fabiand) (bkp,
15:23:12)
* infra update First ovirt-node image has been built (thanks tlitovsk)
(bkp, 15:23:14)
* infra update dcaro should be given a huge round of thanks for his
efforts on this project. Good work! (bkp, 15:23:17)
* infra update There is currently strong emphasis on getting zuul for
gating (testing the patches and merging them after only if it passes
the tests) (bkp, 15:23:20)
* infra update zuul requirements must be understood (gearmand, some
jenkins plugins, some gate jobs, etc. are needed) and then plan on
getting all the services going_ (bkp, 15:23:23)
* infra update Moving to zuul will also require help from devs to
create the gate jobs--jobs that must pass in order to get the patch
merged--they should be very reliable (bkp, 15:23:26)
* infra update oVirt has formally joined the CentOS Virt sig, and
progress is being made to have CentOS host all of the packages we
want them to host (Re:
http://lists.centos.org/pipermail/centos-virt/2014-December/004187.html).
sbonazzo and dcaro will be co-maintainers. (bkp, 15:23:29)
* 3.5.z updates (bkp, 15:23:35)
* 3.5.z updates Full status at:
http://lists.ovirt.org/pipermail/users/2014-December/030048.html
(bkp, 15:29:49)
* 3.5.z updates One open blocker (1160846) in NEW state; ETA/status of
fix: unknown (bkp, 15:29:52)
* 3.5.z updates oVirt 3.5.1 RC compose date/time 2015-01-07 0800 UTC
(bkp, 15:29:55)
* 3.5.z updates oVirt 3.5.1 GA date now 2015-01-14 (bkp, 15:29:58)
* 3.5.z updates danken asked to update vdsm in current stable repo,
ybronhei had issues with koji. Not sure if we'll have it before
holidays (bkp, 15:30:00)
* 3.5.z updates There are still 62 bugs targeted to 3.5.1
(http://goo.gl/7G0PDV). Excluding Node and doc bugs, there are 41
bugs. (bkp, 15:30:03)
* 3.6 status (bkp, 15:30:26)
* LINK: http://www.ovirt.org/Features/UCS_Integration (dr_gogeta86,
15:31:51)
* 3.6.0 status Full status at:
http://lists.ovirt.org/pipermail/users/2014-December/030049.html
(bkp, 15:41:35)
* 3.6.0 status Following the review process, the remaining key
milestones for this release will be scheduled. (bkp, 15:41:38)
* 3.6.0 status There are 461 bugs targeted to 3.6.0 (438 without Node
and doc bugs); no known blockers. (bkp, 15:41:41)
* ACTION: 3.6.0 status Features proposed for 3.6.0 are now collected
in the 3.6 Google doc (http://goo.gl/9X3G49) and must be reviewed by
maintainers. (bkp, 15:41:44)
* 3.6.0 status Storage: for the better part of the last 2-3 weeks
storage has been chasing down EL issues for RHEV, which will also be
fixed in oVirt 3.5.1 - amureini still haven't got his head around
3.6.0 to update the doc, which amureini will do soon. Or else.
(bkp, 15:41:47)
* conferences and workshops (bkp, 15:41:59)
* conferences and workshops bkp has *just* learned that oVirt has
received a stand of its own for FOSDEM! (bkp, 15:42:14)
* conferences and workshops FOSDEM planning was delayed this week, due
to FOSDEM notifications not going out. Some lightning talk
notifications went out, so ideally information on talks, and
devrooms is forthcoming. (bkp, 15:42:32)
* conferences and workshops Registration for CfgMgmtCamp 2015 has
just(!) opened. There are no plans for a formal oVirt presence, but
it is right after FOSDEM in Ghent and if anyone wants to attend,
registration is here: http://cfgmgmtcamp.eu/ (bkp, 15:42:54)
* conferences and workshops bkp has also just learned that there
*will* be an Infrastructure.Next event in Ghent on Feb. 5, contrary
to earlier reports. Details to follow. (bkp, 15:43:07)
* conferences and workshops bkp is still working with hpillay on
possibly running an oVirt workshop around FOSSAsia
(http://fossasia.org/) in Singapore Mar 12-16. (bkp, 15:43:23)
* conferences and workshops fabiand will be submitting a talk to CeBit
(http://www.cebit.de/home) in Hannover Mar 16-20. (bkp, 15:43:56)
* conferences and workshops rkoch is planning a booth and presentation
for oVirt at Chemnitzer Linux-Tage
(https://chemnitzer.linux-tage.de/2015/en/info) Mar 21-22. Depending
on outcome of FOSSasia, bkp may join him (bkp, 15:44:07)
* conferences and workshops rkoch is planning a booth and presentation
for oVirt at Chemnitzer Linux-Tage
(https://chemnitzer.linux-tage.de/2015/en/info) Mar 21-22. Depending
on outcome of FOSSasia, bkp may join him (bkp, 15:44:27)
* conferences and workshops Beginning in 2015, events that oVirt is
and can be involved in will be posted on the oVirt Schedule Google
Calendar, which is open to public. If you have information on *any*
event, please send it to bkp as early as possible spo it can be
posted on the calendar. (bkp, 15:44:43)
* conferences and workshops Discussions are underway for an oVirt
presence at http://www.oss2015.org 11th Intl. Conf. on Open Source
Systems (May 16-17, Florence, Italy) (bkp, 15:48:44)
* other topics (bkp, 15:49:08)
* other topics shaunm has begun preliminary conversion of MediaWiki
content to XML-based formats that should be easy for community
members to work with and be compatible with downstream documentation
systems. (bkp, 15:49:20)
* other topics bkp has spoken with UDSEnterprise, and has a case study
in the works. (bkp, 15:49:24)
* other topics There is a known problem with gmail subscribers to the
oVirt Users mailing list getting excessive bounces. Still trying to
puzzle this one out. Anyone with Mailman mojo is more than welcome
to lend a hand. (bkp, 15:49:27)
* other topics A reminder: due to holiday celebrations, there will be
no oVirt Weekly Sync meeting until Jan. 7, 2015 (bkp, 15:49:48)
Meeting ended at 15:51:59 UTC.
Action Items
------------
* 3.6.0 status Features proposed for 3.6.0 are now collected in the 3.6
Google doc (http://goo.gl/9X3G49) and must be reviewed by maintainers.
Action Items, by person
-----------------------
* **UNASSIGNED**
* 3.6.0 status Features proposed for 3.6.0 are now collected in the
3.6 Google doc (http://goo.gl/9X3G49) and must be reviewed by
maintainers.
People Present (lines said)
---------------------------
* bkp (86)
* sbonazzo (20)
* dcaro (13)
* dr_gogeta86 (8)
* awels (5)
* tlitovsk (5)
* lvernia (3)
* amureini (3)
* ovirtbot (2)
* Dw_Sn (1)
* fabiand (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Brian Proffitt
Community Liaison
oVirt
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC
10 years