- Users - oVirt List Archives

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

oVirt Weekly Sync Meeting: Dec. 17, 2014
by Brian Proffitt 18 Dec '14

18 Dec '14

========================= #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

2 2

Re: [ovirt-users] FQDN for vm creating with hosted-engine
by Yue, Cong 18 Dec '14

18 Dec '14

--- FQDN or fully qualified domain name means that you have to reserve in your DNS a name corresponding to IP received by HE VM from DHCP. IP address should be reserved for the VM at DHCP. I advise not to use manual IP to FQDN at your host, as this will lead to many confusions, especially when you'll have more than a single host machine, but you always can configure at your /etc/hosts file the FQDN corresponding to IP address given to HE VM. --- Thanks for the explanation. Now I understand what FQDN is for Ovirt. Is there any problem if I do not use the naming convention like aaa.bbb.ccc, but only aaa? Also I am some confused for the above explanation. Here it said the IP for VM is better to be got from DHCP rather than manual IP. If so, do this mean I need to change all /etc/hosts file of all virt nodes to update the IP for the FQDN for engine VM? What is the confusions if I use manual IP rather than DHCP for engine VM? Thanks, Cong -----Original Message----- From: users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of users-request(a)ovirt.org Sent: Wednesday, December 17, 2014 1:17 AM To: users(a)ovirt.org Subject: Users Digest, Vol 39, Issue 107 Send Users mailing list submissions to users(a)ovirt.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.ovirt.org/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request(a)ovirt.org You can reach the person managing the list at users-owner(a)ovirt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. 1. FQDN for vm creating with hosted-engine (Yue, Cong) (Nikolai Sednev) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Dec 2014 04:16:33 -0500 (EST) From: Nikolai Sednev <nsednev(a)redhat.com> To: users(a)ovirt.org Subject: [ovirt-users] 1. FQDN for vm creating with hosted-engine (Yue, Cong) Message-ID: <2080226028.11273252.1418807793775.JavaMail.zimbra(a)redhat.com> Content-Type: text/plain; charset="utf-8" FQDN or fully qualified domain name means that you have to reserve in your DNS a name corresponding to IP received by HE VM from DHCP. IP address should be reserved for the VM at DHCP. I advise not to use manual IP to FQDN at your host, as this will lead to many confusions, especially when you'll have more than a single host machine, but you always can configure at your /etc/hosts file the FQDN corresponding to IP address given to HE VM. Thanks in advance. Best regards, Nikolai ____________________ Nikolai Sednev Senior Quality Engineer at Compute team Red Hat Israel 34 Jerusalem Road, Ra'anana, Israel 43501 Tel: +972 9 7692043 Mobile: +972 52 7342734 Email: nsednev(a)redhat.com IRC: nsednev ----- Original Message ----- From: users-request(a)ovirt.org To: users(a)ovirt.org Sent: Wednesday, December 17, 2014 1:19:12 AM Subject: Users Digest, Vol 39, Issue 104 Send Users mailing list submissions to users(a)ovirt.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.ovirt.org/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request(a)ovirt.org You can reach the person managing the list at users-owner(a)ovirt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. FQDN for vm creating with hosted-engine (Yue, Cong) 2. Server 2012 R2 + Intel Conroe Cluster (Nathan Llaneza) 3. alternate method of fencing (Brent Hartzell) 4. Re: Don't start vm (Roman Nikolayevich Drovalev) ---------------------------------------------------------------------- Message: 1 Date: Tue, 16 Dec 2014 14:44:44 -0800 From: "Yue, Cong" <Cong_Yue(a)alliedtelesis.com> To: "users(a)ovirt.org" <users(a)ovirt.org> Subject: [ovirt-users] FQDN for vm creating with hosted-engine Message-ID: <ED08B56256B38842A463A2A0804C5AC0326ACA3F65(a)svr-ca-exch1.atg.lc> Content-Type: text/plain; charset="us-ascii" Hi Now I am trying to confirm KVM's HA with ovirt, and doing the walk through as the following guide. http://community.redhat.com/blog/2014/10/up-and-running-with-ovirt-3-5/ During the VM setting, FQDN is asked, what FQDN means about? Does it mean the hostname of VM host? In my case, it is compute2-2. The following is my hosts file, my VM host and storage is 10.0.0.92. And I am trying to assign 10.0.0.95 to the hosted VM. --- [root@compute2-2 ~]# cat /etc/hosts 10.0.0.93 compute2-2 nfs2-2 10.0.0.95 ovrit-test 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 ---- Also how I can remove the VM I installed, as for when I try to do hosted-engine --deploy, it shows --- [root@compute2-2 ~]# hosted-engine --deploy [ INFO ] Stage: Initializing Continuing will configure this host for serving as hypervisor and create a VM where you have to install oVirt Engine afterwards. Are you sure you want to continue? (Yes, No)[Yes]: Yes [ INFO ] Generating a temporary VNC password. [ INFO ] Stage: Environment setup Configuration files: [] Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20141216144036-30j0wk.log Version: otopi-1.3.0 (otopi-1.3.0-1.el7) [ INFO ] Hardware supports virtualization [ INFO ] Bridge ovirtmgmt already created [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup [ ERROR ] The following VMs has been found: ac4c8d35-ca47-4394-afa8-1180c768128c [ ERROR ] Failed to execute stage 'Environment setup': Cannot setup Hosted Engine with other VMs running [ INFO ] Stage: Clean up [ INFO ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf' [ INFO ] Answer file '/etc/ovirt-hosted-engine/answers.conf' has been updated [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination -- Thanks, Cong ________________________________ This e-mail message is for the sole use of the intended recipient(s) and may 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 copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.

2 1

Used Network resources of host XY [97%] exceeded
by Ml Ml 18 Dec '14

18 Dec '14

Hello List, one of my ovirt Guests seems to loose its Network connection. I can still see some traffic on the console tough. In the Logs i get: 2014-Dez-04, 13:09 Used Network resources of host <myhostname-here> [97%] exceeded defined threshold [95%]. Is this the reason? Where can i change or disable this feature? Thanks, Mario

3 2

Too much memory used in hosts
by Dinuwan 18 Dec '14

18 Dec '14

This is a multipart message in MIME format. ------=_NextPart_000_000C_01D01ABB.0EE8F8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Ovirt users, I am new to ovirt. I have installed the Ovirt hosted setup on two machines running glusterfs. It has been working ok. I now have about 6 virtual machines in my cluster. The problem that I am having is; when I shutdown all the machines on one host, the memory is not freed. I migrated all the VMs to one Host and left the with 0, but still the memory is displayed at 89%. When I do a top on the same Host, I only see the vdsmd using 16%. I do not see any particular errors in any of the log files either. Would appreciate it if anybody could share their knowledge on the matter. Has it happened to anyone? Thanking you all in advance, D1. ------=_NextPart_000_000C_01D01ABB.0EE8F8E0 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 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>Dear Ovirt users,<o:p></o:p><o:p> </o:p>I am new to = ovirt. I have installed the Ovirt hosted setup on two machines running = glusterfs. It has been working ok. I now have about 6 virtual machines = in my cluster. The problem that I am having is; when I shutdown all the = machines on one host, the memory is not freed. I migrated all the VMs to = one Host and left the with 0, but still the memory is displayed at 89%. = When I do a top on the same Host, I only see the vdsmd using 16%. I do = not see any particular errors in any of the log files = either.<o:p></o:p><o:p> </o:p>Would appreciate it if anybody could share their = knowledge on the matter. Has it happened to anyone? <o:p></o:p><o:p> </o:p>Thanking you = all in advance,<o:p></o:p><o:p> </o:p>D1. = <o:p></o:p></div></body></html> ------=_NextPart_000_000C_01D01ABB.0EE8F8E0--

2 5

after rebooting nodes cannot activate them
by Gabi C 18 Dec '14

18 Dec '14

Hello! 1 engine- not hosted FC 19 + ovirt 3.5 ; 3 nodes - F20 and ovirt 3.5 patternfly due to high vdsm memory usage. All theree nodes serves as glusterfs server - 3 replicated bricks. After putting DC in maintenance - all VM shutdown, storages in maintenance (ISO, Data, Export) , stop gluster volume and finally hosts in maintenance , runned "yum update" on all nodes, reboot them, "Confirm host has been rebooted" but trying to activate them raise "Gluster command [<UNKNOWN>] failed on server....." and hosts goes in non operational. vdsm log goes like: Thread-15::ERROR::2014-12-18 10:17:53,439::__init__::493::jsonrpc.JsonRpcServer::(_serveRequest) Internal server error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 488, in _serveRequest res = method(**params) File "/usr/share/vdsm/rpc/Bridge.py", line 264, in _dynamicMethod result = fn(*methodArgs) File "/usr/share/vdsm/gluster/apiwrapper.py", line 79, in list return self._gluster.hostsList() File "/usr/share/vdsm/gluster/api.py", line 54, in wrapper rv = func(*args, **kwargs) File "/usr/share/vdsm/gluster/api.py", line 251, in hostsList return {'hosts': self.svdsmProxy.glusterPeerStatus()} 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 glusterPeerStatus File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result) GlusterCmdExecFailedException: Command execution failed error: Connection failed. Please check if gluster daemon is operational. return code: 1 *NB* *Reinstalling all host after moving in Maintenance from Non-op avtivates them and I am able to start gluster volume, activate stoarage domains and so on.......* <https://bugzilla.redhat.com/show_bug.cgi?id=1142647>

1 0

Cannot activate storage domain
by Brent Hartzell 18 Dec '14

18 Dec '14

------=_NextPart_000_0353_01D01A39.5FE62240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Have the following: 6 hosts - virt + Gluster shared Gluster volume is distributed-replicate - replica 2 Shutting down servers one at a time all work except for 1 brick. If we shut down one specific brick (1 brick per host) - we're unable to activate the storage domain. VM's that were actively running from other bricks continue to run. Whatever was running form that specific brick fails to run, gets paused etc. Error log shows the entry below. I'm not certain what it's saying is read only.nothing is read only that I can find. 2014-12-17 19:57:13,362 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStatusVDSCommand] (DefaultQuartzScheduler_Worker-47) [4e9290a2] Command SpmStatusVDSCommand(HostName = U23.domainame.net, HostId = 0db58e46-68a3-4ba0-a8aa-094893c045a1, storagePoolId = 7ccd6ea9-7d80-4170-afa1-64c10c185aa6) execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to SpmStatusVDS, error = [Errno 30] Read-only file system, code = 100 2014-12-17 19:57:13,363 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxyData] (DefaultQuartzScheduler_Worker-47) [4e9290a2] hostFromVds::selectedVds - U23.domainname.net, spmStatus returned null! According to Ovirt/Gluster, if a brick goes down, the VM should be able to be restarted from another brick without issue. This does not appear to be the case. If we take other bricks offline, it appears to work as expected. Something with this specific brick cases everything to break which then makes any VM's that were running from the brick unable to start. ------=_NextPart_000_0353_01D01A39.5FE62240 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 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>Have the following:<o:p></o:p><o:p> </o:p>6 hosts = – virt + Gluster shared<o:p></o:p><o:p> </o:p>Gluster = volume is distributed-replicate – replica 2<o:p></o:p><o:p> </o:p>Shutting = down servers one at a time all work except for 1 brick. If we shut down = one specific brick (1 brick per host) – we’re unable to = activate the storage domain. VM’s that were actively running from = other bricks continue to run. Whatever was running form that specific = brick fails to run, gets paused etc. <o:p></o:p><o:p> </o:p>Error log = shows the entry below. I’m not certain what it’s saying is = read only…nothing is read only that I can find. =  <o:p></o:p><o:p> </o:p><o:p> </o:p>2014-12-17 = 19:57:13,362 ERROR = [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStatusVDSCommand] = (DefaultQuartzScheduler_Worker-47) [4e9290a2] Command = SpmStatusVDSCommand(HostName =3D U23.domainame.net, HostId =3D = 0db58e46-68a3-4ba0-a8aa-094893c045a1, storagePoolId =3D = 7ccd6ea9-7d80-4170-afa1-64c10c185aa6) execution failed. Exception: = VDSErrorException: VDSGenericException: VDSErrorException: Failed to = SpmStatusVDS, error =3D [Errno 30] Read-only file system, code =3D = 100<o:p></o:p>2014-12-17 19:57:13,363 = INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxyData] = (DefaultQuartzScheduler_Worker-47) [4e9290a2] hostFromVds::selectedVds - = U23.domainname.net, spmStatus returned null!<o:p></o:p><o:p> </o:p><o:p> </o:p>According to = Ovirt/Gluster, if a brick goes down, the VM should be able to be = restarted from another brick without issue. This does not appear to be = the case… If we take other bricks offline, it appears to work as = expected. Something with this specific brick cases everything to break = which then makes any VM’s that were running from the brick unable = to start.<o:p></o:p></div></body></html> ------=_NextPart_000_0353_01D01A39.5FE62240--

3 2