- Users - oVirt List Archives

[ANN] oVirt 3.6.0 First Alpha Release is now available for testing
by Sandro Bonazzola 21 May '15

21 May '15

The oVirt Project is pleased to announce the availability of the first Alpha release of oVirt 3.6 for testing, as of May 20, 2015. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. The Alpha release is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar). The Alpha release can also be deployed on Hypervisor Hosts running Fedora 21 and Fedora 22. This Alpha release of oVirt includes numerous bug fixes. See the release notes [1] for an initial list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO and Node ISO will be available soon[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.6_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

disk format hang
by paf1＠email.cz 20 May '15

20 May '15

This is a multi-part message in MIME format. --------------010600070900060906080603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, during VM instalation I needed add 300GB new disk and format as EXT3. Easy task, but .... Used striped mirror volume for that - created by: # gluster volume create 12KVM12SC4 replica 2 stripe 2 1kvm1-SAN:/p4/GFS1 1kvm2-SAN:/p4/GFS1 2kvm1-SAN /p4/GFS1 2kvm2-SAN:/p4/GFS1 force - added disk throught oVisrt GUI - VM# partprobe - VM# fdisk - make one partition, type linux - VM# mkfs.ext3 /dev/vdb1 it hangs after cca 30% of format oVirt alert: *VM has been paused due to a storage I/O error* so I tried to copy some data directly from hypervizor ( cca 80GB ) to default gluster-ovirt mountpoint ( /rhev/data-center/mnt/glusterSD/localhost:_12KVM12SC4 ) with no hangs. The same whole operation on volume distribute replica type succesfully done. Can anybody help me with it ?? Maybe continual error on /var/log/messages occure will get right view on it : May 20 15:47:00 1kvm2 virsh: All-whitespace username. May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:47:00 1kvm2 virsh: All-whitespace username. May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:48:00 1kvm2 virsh: All-whitespace username. May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:48:00 1kvm2 virsh: All-whitespace username. May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error regs to ALL !! URGENT !! Pavel --------------010600070900060906080603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hello, <br> <br> during VM instalation I needed add 300GB new disk and format as EXT3. Easy task, but ....<br> Used striped mirror volume for that - created by:<br> <meta http-equiv="content-type" content="text/html; charset=utf-8"> # gluster volume create 12KVM12SC4 replica 2 stripe 2 1kvm1-SAN:/p4/GFS1 1kvm2-SAN:/p4/GFS1 2kvm1-SAN /p4/GFS1 2kvm2-SAN:/p4/GFS1 force<br> - added disk throught oVisrt GUI<br> - VM# partprobe<br> - VM# fdisk - make one partition, type linux<br> - VM# mkfs.ext3 /dev/vdb1<br> it hangs after cca 30% of format<br> <br> oVirt alert: <div> <div> <div style="display: inline;" class="gwt-Label"><b>VM has been paused due to a storage I/O error</b></div> </div> </div> <br> so I tried to copy some data directly from hypervizor ( cca 80GB ) to default gluster-ovirt mountpoint ( /rhev/data-center/mnt/glusterSD/localhost:_12KVM12SC4 ) with no hangs.<br> The same whole operation on volume distribute replica type succesfully done.<br> <br> Can anybody help me with it ??<br> <br> Maybe continual error on /var/log/messages occure will get right view on it :<br> <br> May 20 15:47:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:47:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:48:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:48:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error<br> <br> regs to ALL<br> <br> !! URGENT !!<br> <br> Pavel<br> </body> </html> --------------010600070900060906080603--

1 0

Re: [ovirt-users] Linux VMs get stuck after Live Migration
by Soeren Malchow 20 May '15

20 May '15

--_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCnNvbWUgYWRkaXRpb25zOg0KDQogICogICBzd2l0Y2hpbmcgb2YgbWVtb3J5 IGJhbGxvb25pZyBkb2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbQ0KICAqICAgT25jZSB3ZSBtaWdy YXRlZCB0aGUgbWFjaGluZXMgd2UgY2FuIGJhc2ljYWxseSBub3QgdXNlIGFueXRoaW5nIGFueW1v cmUgdGhhdCBuZWVkcyBzb21lIGtpbmQgb2YgdGltaW5nIOKAkyBlLmcuIOKAnHBpbmcgMS4xLjEu MSDigJNpIDLigJ0gb3Ig4oCcd2hpbGUgdHJ1ZTsgZG8gZWNobyDigJxsYWxh4oCdOyBzbGVlcOKA nTsgZG9uZeKAnSBib3RoIGRvIHRoZSBmcmlzdCB0aGluZyAoMSBwaW5nIGFuZCBvbmUg4oCcbGFs YeKAnSBvdXRwdXQpIGJ1dCB0aGVuIHN0YWxsDQoNCkNoZWVycw0KU29lcmVuDQoNCkZyb206IDx1 c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZzxtYWlsdG86dXNlcnMtYm91bmNlc0BvdmlydC5vcmc+PiBv biBiZWhhbGYgb2YgU29lcmVuIE1hbGNob3cNCkRhdGU6IFdlZG5lc2RheSAyMCBNYXkgMjAxNSAx Mzo0Mg0KVG86ICJ1c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZz4iDQpTdWJq ZWN0OiBbb3ZpcnQtdXNlcnNdIExpbnV4IFZNcyBnZXQgc3R1Y2sgYWZ0ZXIgTGl2ZSBNaWdyYXRp b24NCg0KRGVhciBhbGwsDQoNCldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9ibGVtIHdpdGggTGlu dXggVm1zIHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2VudE9TIDcuMSAoc28g ZmFyIGl0IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9ibGVtKSwgYWZ0ZXIg dGhlIGxpdmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0aGUgSVAgYW5kIGhv c3RuYW1lIGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vlc3QgdG9vbHMgYXJl IG5vdCBpbnN0YWxsZWQsIGJ1dCB0aGUgbWFjaGluZXMgYXJlIHN0aWxsIHJ1bm5pbmcuDQoNClRo ZW4gd2UgaGF2ZSAyIGRpZmZlcmVudCBzY2VuYXJpb3MNCg0KUmVib290L3NodXRkb3duOg0KV2hl biBpIHJlYm9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2UgVk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0 aGUgT1Mgc2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIsIHRoZSBxZW11IHByb2Nlc3MgaXMgc3Rp bGwgcnVubmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNoaW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNo dXRkb3du4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5vdCBkbyBhbnl0aGluZywgYSDigJxwb3dl ciBvZmbigJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZQ0KDQpKdXN0IHdhaXQ6DQpBZnRlciBhIHdo aWxlIHRoZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFzaWNhbGx5 IHRoZW4gc2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duDQoNClRoZSBlbnZpcm9u bWVudCBpczoNCg0KSG9zdGVkIEVuZ2luZSBvbiBDZW50T1MgNi42IHdpdGggb3ZpcnQgMy41LjIu MQ0KQ29tcHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNtIDQuMTYuMTQgYW5kIGxpYnZp cnQgMS4yLjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVwbyAoZm9yIGxpdmUgbWVyZ2Up DQpTdG9yYWdlIC0+IENlbnRPUyA3LjEgd2l0aCBnbHVzdGVyIDMuNi4zDQoNCkNhbiBhbnlvbmUg cG9pbnQgdXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uDQoNClJlZ2FyZHMNClNvZXJlbg0K --_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <E72DBA6120393545B26397A309AE61D7(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkRlYXIgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+c29tZSBhZGRpdGlv bnM6Jm5ic3A7PC9kaXY+DQo8dWw+DQo8bGk+c3dpdGNoaW5nIG9mIG1lbW9yeSBiYWxsb29uaWcg ZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW08L2xpPjxsaT5PbmNlIHdlIG1pZ3JhdGVkIHRoZSBt YWNoaW5lcyB3ZSBjYW4gYmFzaWNhbGx5IG5vdCB1c2UgYW55dGhpbmcgYW55bW9yZSB0aGF0IG5l ZWRzIHNvbWUga2luZCBvZiB0aW1pbmcg4oCTIGUuZy4g4oCccGluZyAxLjEuMS4xIOKAk2kgMuKA nSBvciDigJx3aGlsZSB0cnVlOyBkbyBlY2hvIOKAnGxhbGHigJ07IHNsZWVw4oCdOyBkb25l4oCd IGJvdGggZG8gdGhlIGZyaXN0IHRoaW5nICgxIHBpbmcgYW5kIG9uZSDigJxsYWxh4oCdIG91dHB1 dCkgYnV0IHRoZW4gc3RhbGw8L2xpPjwvdWw+DQo8ZGl2PkNoZWVyczwvZGl2Pg0KPGRpdj5Tb2Vy ZW4mbmJzcDs8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp OyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJP VFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4m bHQ7PGEgaHJlZj0ibWFpbHRvOnVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnIj51c2Vycy1ib3VuY2Vz QG92aXJ0Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBTb2VyZW4gTWFsY2hvdzxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5IDIwIE1heSAy MDE1IDEzOjQyPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnVzZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9h PiZxdW90Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw YW4+W292aXJ0LXVzZXJzXSBMaW51eCBWTXMgZ2V0IHN0dWNrIGFmdGVyIExpdmUgTWlncmF0aW9u PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkRlYXIgYWxs LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgYXJlIGV4cGVyaWVuY2luZyBhIHBy b2JsZW0gd2l0aCBMaW51eCBWbXMgc3BlY2lmaWNhbGx5IHRoZSBWbXMgd2UgdGVzdGVkIGFyZSBD ZW50T1MgNy4xIChzbyBmYXIgaXQgbG9va3MgYXMgaWYgV2luZG93cyBWbXMgYXJlIG5vdCBhIHBy b2JsZW0pLCBhZnRlciB0aGUgbGl2ZSBtaWdyYXRpb24gdGhlIG1hY2hpbmVzIGRvIG5vdCBzaG93 IHRoZSBJUCBhbmQgaG9zdG5hbWUgaW4gdGhlIEdVSSwgdGhlIHNhbWUgd2F5IGFzIGlmIHRoZSBn dWVzdA0KIHRvb2xzIGFyZSBub3QgaW5zdGFsbGVkLCBidXQgdGhlIG1hY2hpbmVzIGFyZSBzdGls bCBydW5uaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlbiB3ZSBoYXZlIDIg ZGlmZmVyZW50IHNjZW5hcmlvczwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVib290 L3NodXRkb3duOjwvZGl2Pg0KPGRpdj5XaGVuIGkgcmVib290L3NodXRkb3duIG9uZSBvZiB0aGVz ZSBWTVMgZnJvbSBpbnNpZGUgdGhlIFZNIHRoZSBPUyBzZWVtcyB0byBzaHV0ZG93biwgaG93ZXZl ciwgdGhlIHFlbXUgcHJvY2VzcyBpcyBzdGlsbCBydW5uaW5nIGFuZCBmb3Igb3ZpcnQgdGhlIG1h Y2hpbmUgaXMgc3RpbGwgdXAsIGEg4oCcc2h1dGRvd27igJ0gaW4gdGhlIGZyb250ZW5kIGRvZXMg bm90IGRvIGFueXRoaW5nLCBhIOKAnHBvd2VyIG9mZuKAnSBzaHV0cyBkb3duIHRoZSBtYWNoaW5l PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5KdXN0IHdhaXQ6PC9kaXY+DQo8ZGl2PkFm dGVyIGEgd2hpbGUgdGhlIG1hY2hpbmVzIGp1c3Qgc2VlbSB0byBzaHV0ZG93biBhbmQgdGhlbiBi YXNpY2FsbHkgdGhlbiBzYW1lIGhhcHBlc24gYXMgd2l0aCByZWJvb3Qvc2h1dGRvd248L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBlbnZpcm9ubWVudCBpczo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pkhvc3RlZCBFbmdpbmUgb24gQ2VudE9TIDYuNiB3aXRoIG92aXJ0 IDMuNS4yLjE8L2Rpdj4NCjxkaXY+Q29tcHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNt IDQuMTYuMTQgYW5kIGxpYnZpcnQgMS4yLjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVw byAoZm9yIGxpdmUgbWVyZ2UpPC9kaXY+DQo8ZGl2PlN0b3JhZ2UgLSZndDsgQ2VudE9TIDcuMSB3 aXRoIGdsdXN0ZXIgMy42LjM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNhbiBhbnlv bmUgcG9pbnQgdXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNvZXJlbiZuYnNwOzwvZGl2Pg0KPGRp dj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_--

1 0

NFS export domain still remain in "Preparing for maintenance"
by NUNIN Roberto 20 May '15

20 May '15

--_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all We are using oVirt engine 3.5.1-0.0 on Centos 6.6 We have two DC. One with hosts using vdsm-4.16.10-8.gitc937927.el7.x86_64, = the other vdsm-4.16.12-7.gita30da75.el6.x86_64 on Centos6.6 No hosted-engine, it run on a dedicates VM, outside oVirt. Behavior: When try to put the NFS export currently active and attached to t= he 6.6 cluster, used to move VM from one DC to the other, this remain indef= initely in "Preparing for maintenance phase". No DNS resolution issue in place. All parties involved are solved directly = and via reverse resolution. I've read about the issue on el7 and IPv6 bug, but here we have the problem= on Centos 6.6 hosts. Any idea/suggestion/further investigation ? Can we reinitialize the NFS export in some way ? Only erasing content ? Thanks in advance for any suggestion. Roberto Nunin Italy ________________________________ Questo messaggio e' indirizzato esclusivamente al destinatario indicato e p= otrebbe contenere informazioni confidenziali, riservate o proprietarie. Qua= lora la presente venisse ricevuta per errore, si prega di segnalarlo immedi= atamente al mittente, cancellando l'originale e ogni sua copia e distruggen= do eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potr= ebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibit= ed and may be unlawful. --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"IT" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi all<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">We are using oVirt engine 3.5.1= -0.0 on Centos 6.6<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">We have two DC. One with hosts = using vdsm-4.16.10-8.gitc937927.el7.x86_64, the other vdsm-4.16.12-7.gita30= da75.el6.x86_64 on Centos6.6<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">No hosted-engine, it run on a d= edicates VM, outside oVirt.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Behavior: When try to put the N= FS export currently active and attached to the 6.6 cluster, used to move VM= from one DC to the other, this remain indefinitely in “Preparing for= maintenance phase”.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">No DNS resolution issue in plac= e. All parties involved are solved directly and via reverse resolution.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I’ve read about the issue= on el7 and IPv6 bug, but here we have the problem on Centos 6.6 hosts.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Any idea/suggestion/further inv= estigation ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Can we reinitialize the NFS exp= ort in some way ? Only erasing content ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks in advance for any sugge= stion.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">Roberto Nunin<o:p><= /o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">Italy<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <br> <hr> <font face=3D"Courier New" color=3D"Black" size=3D"2">Questo messaggio e' i= ndirizzato esclusivamente al destinatario indicato e potrebbe contenere inf= ormazioni confidenziali, riservate o proprietarie. Qualora la presente veni= sse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e dis= truggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito= e potrebbe essere fonte di violazione di legge.<br> <br> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful.<br> </font> </body> </html> --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_--

2 5

Linux VMs get stuck after Live Migration
by Soeren Malchow 20 May '15

20 May '15

--_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9ibGVtIHdpdGggTGludXggVm1z IHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2VudE9TIDcuMSAoc28gZmFyIGl0 IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9ibGVtKSwgYWZ0ZXIgdGhlIGxp dmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0aGUgSVAgYW5kIGhvc3RuYW1l IGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vlc3QgdG9vbHMgYXJlIG5vdCBp bnN0YWxsZWQsIGJ1dCB0aGUgbWFjaGluZXMgYXJlIHN0aWxsIHJ1bm5pbmcuDQoNClRoZW4gd2Ug aGF2ZSAyIGRpZmZlcmVudCBzY2VuYXJpb3MNCg0KUmVib290L3NodXRkb3duOg0KV2hlbiBpIHJl Ym9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2UgVk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0aGUgT1Mg c2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIsIHRoZSBxZW11IHByb2Nlc3MgaXMgc3RpbGwgcnVu bmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNoaW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNodXRkb3du 4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5vdCBkbyBhbnl0aGluZywgYSDigJxwb3dlciBvZmbi gJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZQ0KDQpKdXN0IHdhaXQ6DQpBZnRlciBhIHdoaWxlIHRo ZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFzaWNhbGx5IHRoZW4g c2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duDQoNClRoZSBlbnZpcm9ubWVudCBp czoNCg0KSG9zdGVkIEVuZ2luZSBvbiBDZW50T1MgNi42IHdpdGggb3ZpcnQgMy41LjIuMQ0KQ29t cHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNtIDQuMTYuMTQgYW5kIGxpYnZpcnQgMS4y LjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVwbyAoZm9yIGxpdmUgbWVyZ2UpDQpTdG9y YWdlIC0+IENlbnRPUyA3LjEgd2l0aCBnbHVzdGVyIDMuNi4zDQoNCkNhbiBhbnlvbmUgcG9pbnQg dXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uDQoNClJlZ2FyZHMNClNvZXJlbg0K --_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <FCD76AD0F70A3F428467305A213B2D3F(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9i bGVtIHdpdGggTGludXggVm1zIHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2Vu dE9TIDcuMSAoc28gZmFyIGl0IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9i bGVtKSwgYWZ0ZXIgdGhlIGxpdmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0 aGUgSVAgYW5kIGhvc3RuYW1lIGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vl c3QNCiB0b29scyBhcmUgbm90IGluc3RhbGxlZCwgYnV0IHRoZSBtYWNoaW5lcyBhcmUgc3RpbGwg cnVubmluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZW4gd2UgaGF2ZSAyIGRp ZmZlcmVudCBzY2VuYXJpb3M8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlYm9vdC9z aHV0ZG93bjo8L2Rpdj4NCjxkaXY+V2hlbiBpIHJlYm9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2Ug Vk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0aGUgT1Mgc2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIs IHRoZSBxZW11IHByb2Nlc3MgaXMgc3RpbGwgcnVubmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNo aW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNodXRkb3du4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5v dCBkbyBhbnl0aGluZywgYSDigJxwb3dlciBvZmbigJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZTwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SnVzdCB3YWl0OjwvZGl2Pg0KPGRpdj5BZnRl ciBhIHdoaWxlIHRoZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFz aWNhbGx5IHRoZW4gc2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZW52aXJvbm1lbnQgaXM6PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5Ib3N0ZWQgRW5naW5lIG9uIENlbnRPUyA2LjYgd2l0aCBvdmlydCAz LjUuMi4xPC9kaXY+DQo8ZGl2PkNvbXB1dGUgaG9zdHMgb24gRmVkb3JhIDIwIHdpdGggdmRzbSA0 LjE2LjE0IGFuZCBsaWJ2aXJ0IDEuMi45LjEgZnJvbSB0aGUgbGlidmlydC1wcmV2aWV3IHJlcG8g KGZvciBsaXZlIG1lcmdlKTwvZGl2Pg0KPGRpdj5TdG9yYWdlIC0mZ3Q7IENlbnRPUyA3LjEgd2l0 aCBnbHVzdGVyIDMuNi4zPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DYW4gYW55b25l IHBvaW50IHVzIHRvd2FyZHMgdGhlIHJpZ2h0IGRpcmVjdGlvbjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tb2VyZW4mbmJzcDs8L2Rpdj4NCjxkaXY+ DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_--

1 0

Missing CPU features
by Bloemen, Jurriën 20 May '15

20 May '15

--_000_D180F3484A93jurrienbloemendmcamcnetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I try to add a new host to a new cluster but I get this message: Host <hostname> moved to Non-Operational state as host does not meet the cl= uster's minimum CPU level. Missing CPU features : model_Haswell The engine.log shows: 2015-05-19 13:54:09,843 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock [exc= lusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS , sharedLocks=3D ] 2015-05-19 13:54:09,868 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: ActivateVd= sCommand internal: false. Entities affected : ID: 1ac98a04-41ed-40b7-8f02-= e1b9cbbc5480 Type: VDSAction group MANIPULATE_HOST with role type ADMIN 2015-05-19 13:54:09,869 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock in or= der to prevent monitoring for host <hostname> from data-center DMC 2015-05-19 13:54:09,870 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from now a m= onitoring of host will be skipped for host <hostname> from data-center DMC 2015-05-19 13:54:09,885 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVdsStat= usVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-40b7-8f02-e1= b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE, stopSpmFailur= eLogged=3Dfalse), log id: 3ec2e03a 2015-05-19 13:54:09,890 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetVdsSta= tusVDSCommand, log id: 3ec2e03a 2015-05-19 13:54:09,920 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Lock rel= eased. Monitoring can run now for host <hostname> from data-center DMC 2015-05-19 13:54:09,923 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Cor= relation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Call St= ack: null, Custom Event ID: -1, Message: Host <hostname> was activated by a= dmin@internal. 2015-05-19 13:54:09,926 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object Engine= Lock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VD= S , sharedLocks=3D ] 2015-05-19 13:54:11,706 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge= tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] STAR= T, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-4= 1ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac98a04-41ed-40b7-8f02-e= 1b9cbbc5480]), log id: 32ca13a8 2015-05-19 13:54:11,712 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge= tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] FINI= SH, GetHardwareInfoVDSCommand, log id: 32ca13a8 2015-05-19 13:54:11,726 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] = (DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is running wi= th disabled SELinux. 2015-05-19 13:54:11,748 INFO [org.ovirt.engine.core.bll.HandleVdsCpuFlagsO= rClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] Runni= ng command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entiti= es affected : ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,772 INFO [org.ovirt.engine.core.bll.SetNonOperationalV= dsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running command: S= etNonOperationalVdsCommand internal: true. Entities affected : ID: 1ac98a0= 4-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,786 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVdsStat= usVDSCommand(HostName =3D <hostname> HostId =3D 1ac98a04-41ed-40b7-8f02-e1= b9cbbc5480, status=3DNonOperational, nonOperationalReason=3DCPU_TYPE_INCOMP= ATIBLE_WITH_CLUSTER, stopSpmFailureLogged=3Dfalse), log id: 24054dd4 2015-05-19 13:54:11,789 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetVdsSta= tusVDSCommand, log id: 24054dd4 2015-05-19 13:54:11,796 WARN [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor= relation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message: Host= <hostname> moved to Non-Operational state as host does not meet the cluste= r's minimum CPU level. Missing CPU features : model_Haswell 2015-05-19 13:54:11,813 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor= relation ID: null, Call Stack: null, Custom Event ID: -1, Message: Status o= f host <hostname> was set to NonOperational. 2015-05-19 13:54:11,839 INFO [org.ovirt.engine.core.bll.HandleVdsVersionCo= mmand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: Handle= VdsVersionCommand internal: true. Entities affected : ID: 1ac98a04-41ed-40= b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,841 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-41ed-4= 0b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOperational status for = reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is = skipped. It says that the host has not meet the minimum CPU level. =93lscpu" has the= following output: # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 56 On-line CPU(s) list: 0-55 Thread(s) per core: 2 Core(s) per socket: 14 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 63 Model name: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz Stepping: 2 CPU MHz: 1957.007 BogoMIPS: 5206.30 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 35840K NUMA node0 CPU(s): 0-13,28-41 NUMA node1 CPU(s): 14-27,42-55 This model is a haswell: http://ark.intel.com/products/81059/Intel-Xeon-Pro= cessor-E5-2697-v3-35M-Cache-2_60-Ghz<http://ark.intel.com/products/81059/In= tel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz> and http://ark.intel.com/= products/codename/42174/Haswell#@All Is this a bug? Should I make a bug report at bugzilla for this? Or am I mis= sing something? Kind regards, Jurri=EBn Bloemen This message (including any attachments) may contain information that is pr= ivileged or confidential. If you are not the intended recipient, please not= ify the sender and delete this email immediately from your systems and dest= roy all copies of it. You may not, directly or indirectly, use, disclose, d= istribute, print or copy this email or any part of it if you are not the in= tended recipient --_000_D180F3484A93jurrienbloemendmcamcnetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <42B749253886BC48BF746A5ED0F34094(a)chellomedia.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Hi all,</div> <div><br> </div> <div>I try to add a new host to a new cluster but I get this message:</div> <div><br> </div> <div>Host <hostname> moved to Non-Operational state as host does not = meet the cluster's minimum CPU level. Missing CPU features : model_Haswell<= /div> <div><br> </div> <div>The engine.log shows:</div> <div><br> </div> <div> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,843 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock= [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS</p= > <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> , sharedLocks=3D ]</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,868 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: Activ= ateVdsCommand internal: false. Entities affected :  ID: 1ac98a04-41ed-= 40b7-8f02-e1b9cbbc5480 Type: VDSAction group MANIPULATE_HOST with role type ADMIN</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,869 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock = in order to prevent monitoring for host <hostname> from data-center D= MC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,870 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from no= w a monitoring of host will be skipped for host <hostname> = from data-center DMC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,885 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVd= sStatusVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-4= 0b7-8f02-e1b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE, stopSpmFailureLogged=3Dfalse), log id: 3ec2e03a</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,890 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetV= dsStatusVDSCommand, log id: 3ec2e03a</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,920 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Loc= k released. Monitoring can run now for host <hostname> from data-cent= er DMC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,923 INFO  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90= ] Correlation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Ca= ll Stack: null, Custom Event ID: -1, Message: Host <hostname> was activated by admin@internal.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,926 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object E= ngineLock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 valu= e: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> , sharedLocks=3D ]</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,706 INFO  [org.ovirt.engine.core.vdsbroker.vdsbrok= er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]= START, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostI= d =3D 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac= 98a04-41ed-40b7-8f02-e1b9cbbc5480]), log id: 32ca13a8</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,712 INFO  [org.ovirt.engine.core.vdsbroker.vdsbrok= er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]= FINISH, GetHardwareInfoVDSCommand, log id: 32ca13a8</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,726 WARN  [org.ovirt.engine.core.vdsbroker.VdsMana= ger] (DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is= running with disabled SELinux.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,748 INFO  [org.ovirt.engine.core.bll.HandleVdsCpuF= lagsOrClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] = Running command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. E= ntities affected :  ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,772 INFO  [org.ovirt.engine.core.bll.SetNonOperati= onalVdsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running comma= nd: SetNonOperationalVdsCommand internal: true. Entities affected :  I= D: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,786 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVd= sStatusVDSCommand(HostName =3D <hostname>  HostId =3D 1ac98= a04-41ed-40b7-8f02-e1b9cbbc5480, status=3DNonOperational, nonOperationalRea= son=3DCPU_TYPE_INCOMPATIBLE_WITH_CLUSTER, stopSpmFailureLogged=3Dfalse), log id: 24054dd4</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,789 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetV= dsStatusVDSCommand, log id: 24054dd4</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,796 WARN  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219= ] Correlation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message:= Host <hostname> moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU f= eatures : model_Haswell</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,813 INFO  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219= ] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Sta= tus of host <hostname> was set to NonOperational.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,839 INFO  [org.ovirt.engine.core.bll.HandleVdsVers= ionCommand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: H= andleVdsVersionCommand internal: true. Entities affected :  ID: 1ac98a= 04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,841 INFO  [org.ovirt.engine.core.vdsbroker.VdsUpda= teRunTimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-4= 1ed-40b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOp= erational status for reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is skipped.</p> </div> <div><br> </div> <div>It says that the host has not meet the minimum CPU level. =93lscpu&quo= t; has the following output:</div> <div><br> </div> <div> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> # lscpu</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Architecture:          x86_64</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU op-mode(s):        32-bit, 64-bit</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Byte Order:            Little Endian</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU(s):                56</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> On-line CPU(s) list:   0-55</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Thread(s) per core:    2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Core(s) per socket:    14</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Socket(s):             2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node(s):          2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Vendor ID:             GenuineIntel</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU family:            6</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Model:                 63</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Model name:            Intel(R) Xeon(R) CPU E= 5-2697 v3 @ 2.60GHz</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Stepping:              2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU MHz:               1957.007</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> BogoMIPS:              5206.30</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Virtualization:        VT-x</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L1d cache:             32K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L1i cache:             32K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L2 cache:              256K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L3 cache:              35840K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node0 CPU(s):     0-13,28-41</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node1 CPU(s):     14-27,42-55</p> </div> <div><br> </div> <div>This model is a haswell: <a href=3D"http://ark.intel.com/products= /81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz">http://ark.intel= .com/products/81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-Ghz</a>&= nbsp;and <a href=3D"http://ark.intel.com/products/codename/42174/Haswe= ll#@All">http://ark.intel.com/products/codename/42174/Haswell#@All</a></div= > <div><br> </div> <div>Is this a bug? Should I make a bug report at bugzilla for this? Or am = I missing something?</div> <div><br> </div> <div>Kind regards,</div> <div><br> </div> <div>Jurri=EBn Bloemen</div> This message (including any attachments) may contain information that is pr= ivileged or confidential. If you are not the intended recipient, please not= ify the sender and delete this email immediately from your systems and dest= roy all copies of it. You may not, directly or indirectly, use, disclose, distribute, print or copy this emai= l or any part of it if you are not the intended recipient </body> </html> --_000_D180F3484A93jurrienbloemendmcamcnetworkscom_--

2 2

Re: [ovirt-users] missing disk after storage domain expansion [SOLVED]
by Andrea Ghelardi 20 May '15

20 May '15

Thanks for all your information. I created a linux script as per details below. Attached to this email (some info purged) Gentlemen, we have a disk now! I'm marking the post as solved ... even though we do not know where the disk gone in these weeks yet. Probably unexpected vacation @Cuba? This disk won't reclaim expenses though I will create a test VM and perform some tests in the future with the expansion feature Thank you for all your support More cats: https://www.youtube.com/watch?v=cWKmorjUzF0 AG -----Original Message----- From: Juan Hernández [mailto:jhernand@redhat.com] Sent: Wednesday, May 20, 2015 10:37 AM To: Maor Lipchuk; Andrea Ghelardi Cc: users(a)ovirt.org Subject: Re: [ovirt-users] missing disk after storage domain expansion On 05/19/2015 06:23 PM, Maor Lipchuk wrote: > Hi Andrea, > > I'm using "postman" chrome-extension to execute my REST requests. > > For firefox the rest-client add-on you can use is > https://addons.mozilla.org/de/firefox/addon/restclient/ > > Juan, do we have a wiki for step by step instructions of REST > > Regards, > Maor > I'd suggest to try a command line client, as it is easier to share the results and check what is going wrong. You can use the "curl" command, for example. Assuming that you already know the identifiers of the storage domain and of the disk to register it should be something like this: ---8<--- #!/bin/sh -ex url="https://yourengine/ovirt-engine/api" user="your user" password="your password" storage_domain_id="the storage domain id" disk_id="the disk id" curl \ --verbose \ --insecure \ --user "${user}:${password}" \ --request POST \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data " <disk id=\"${disk_id}\"/> " \ "${url}/storagedomains/${storage_domain_id}/disks;unregistered" --->8--- > > ----- Original Message ----- >> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >> Cc: users(a)ovirt.org >> Sent: Tuesday, May 19, 2015 4:46:09 PM >> Subject: RE: [ovirt-users] missing disk after storage domain >> expansion >> >> I got an error but I'm not 100% sure I did everything correctly Error >> below: >> <html><head><title>JBoss Web/7.0.13.Final - Error >> report</title><style></style> </head><body><h1>HTTP Status 415 - Cannot >> consume content type</h1><HR size="1" >> noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> >> <u>Cannot consume content type</u></p><p><b>description</b> <u>The >> server refused this request because the request entity is in a format >> not supported by the requested resource for the requested method >> (Cannot consume content type).</u></p><HR size="1" >> noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></html> >> >> Actions: >> Used RESTclient 2.3.0 for Firefox to POST this body <disk >> id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk> >> >> I think I need a step by step guide about how to use the REST client >> to POST commands to ovirt service remotely >> >> Cheers >> AG >> >> -----Original Message----- >> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >> Sent: Monday, May 18, 2015 4:50 PM >> To: Andrea Ghelardi >> Subject: Re: [ovirt-users] missing disk after storage domain >> expansion >> >> I've went through the logs, though I didn't noticed any special >> information. >> Please let me know how the registration of the disk went. >> >> Regards, >> Maor >> >> >> >> ----- Original Message ----- >>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>> Sent: Monday, May 18, 2015 4:35:30 PM >>> Subject: RE: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Here the full set of logs as promised. >>> >>> Unfortunately, I do not think I have vdsm logs pointing to that date >>> (logs rotated already). >>> I tried to search for >>> xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but >>> nothing found >>> >>> cheers >>> AG >>> >>> -----Original Message----- >>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] >>> Sent: Monday, May 18, 2015 3:30 PM >>> To: 'Maor Lipchuk' >>> Cc: 'users(a)ovirt.org' >>> Subject: RE: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Hi Maor, >>> >>> 1) disk creation: ok >>> 2) no free space at the moment of creation: this is very strange! >>> Are you sure? I assure you the disk was working, exported to VM >>> which formatted and wrote data on it >>> 3) no disk removal mention: this is the very issue I'm facing. In >>> fact disk disappeared with no notification, no logs, nothing. I'm >>> forwarding you full set of engine.log separately. If you need >>> vdsm.logs just tell me from which server you need it as I have >>> several cluster. >>> 4) I have not yet tried to register using the procedure you provided >>> me earlier. I'll try tomorrow. >>> >>> Thanks >>> AG >>> >>> >>> -----Original Message----- >>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>> Sent: Monday, May 18, 2015 1:15 PM >>> To: Andrea Ghelardi >>> Cc: users(a)ovirt.org >>> Subject: Re: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Hi Andrea, >>> >>> I guessed I missed those logs, I found it now, thanks. >>> >>> I do see the disk creation in the log from 20150501, I can also see >>> that the Storage Domain hertz-dstore2 has 0 GB of free space at the >>> moment of >>> creation: >>> 2015-05-01 03:30:05,801 ERROR >>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirecto >>> r] >>> (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack: >>> null, Custom Event ID: -1, Message: Critical, Low disk space. >>> hertz-dstore2 domain has 0 GB of free space >>> >>> though, I don't see any indication of the removed disks from the engine. >>> I have also noticed a gap from the first log which finished at >>> 2015-05-01 >>> 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879. >>> >>> Did you try to register the disk as described in the wiki? >>> >>> Regards, >>> Maor >>> >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>>> Cc: users(a)ovirt.org >>>> Sent: Monday, May 18, 2015 12:10:55 PM >>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>> expansion >>>> >>>> Hi Maor, >>>> I already added logs in my previous email, did you received them? >>>> I'm sending them again, but only privately to you not to burden the >>>> mailing list (or let me know if you prefer otherwise). >>>> >>>> Cheers >>>> AG >>>> >>>> >>>> -----Original Message----- >>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>>> Sent: Saturday, May 16, 2015 10:03 AM >>>> To: Andrea Ghelardi >>>> Cc: users(a)ovirt.org >>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>> expansion >>>> >>>> Hi Andrea, >>>> >>>> The OVF_STORE disks are disks which mainly being used internally in >>>> the engine to store VMs' and Templates' OVFs, you can disregard >>>> them for now. >>>> >>>> The behavior you mentioned, that suddenly the disk has disappeared >>>> from the setup, sounds very weird and I would like to investigate >>>> this a bit more. >>>> if you can please add the engine and vdsm logs, I can know what >>>> made the disk get removed from the setup, at the first place. >>>> Could it be that some one accessed the data base by any chance? >>>> >>>> Regarding the disk registration, basically it should not create any >>>> problems unless, if your disk was deleted manually form the DB, and >>>> there are still leftovers related to the disk in some of the tables. >>>> Once the disk is registered to the setup, you can try to attach it >>>> to the VM, and try to run it. >>>> >>>> >>>> Regards, >>>> Maor >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>>>> Cc: users(a)ovirt.org >>>>> Sent: Friday, May 15, 2015 4:54:25 PM >>>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> After querying the hosted engine with the suggested command >>>>> https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4 >>>>> 6- >>>>> 21 12-40a4-814f-24d74c760b2d/disks;unregistered >>>>> >>>>> Indeed shows a (unregistered?) disk >>>>> >>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks> >>>>> <disk >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41" >>>>> id="16736ce0-a9df-410f-9f29-3a28364cdd41"> >>>>> <actions> >>>>> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export" >>>>> rel="export"/> >>>>> </actions> >>>>> <name>hertz_disk5</name> >>>>> <description>disk for SYBASE installation, on SAN shared >>>>> storage</description> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions" >>>>> rel="permissions"/> >>>>> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics" >>>>> rel="statistics"/> >>>>> <alias>hertz_disk5</alias> >>>>> <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id> >>>>> <storage_domain >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d" >>>>> id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> >>>>> <storage_domains> >>>>> <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> >>>>> </storage_domains> >>>>> <size>225485783040</size> >>>>> <provisioned_size>225485783040</provisioned_size> >>>>> <actual_size>225485783040</actual_size> >>>>> <status> >>>>> <state>ok</state> >>>>> </status> >>>>> <interface>ide</interface> >>>>> <format>raw</format> >>>>> <sparse>false</sparse> >>>>> <bootable>false</bootable> >>>>> <shareable>false</shareable> >>>>> <wipe_after_delete>false</wipe_after_delete> >>>>> <propagate_errors>false</propagate_errors> >>>>> </disk> >>>>> </disks> >>>>> >>>>> I'm waiting for any comments on the two OVF disk or any advice >>>>> before proceeding with the registering command (test in production >>>>> environment hmmmmm) >>>>> >>>>> Cheers >>>>> AG >>>>> >>>>> -----Original Message----- >>>>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] >>>>> Sent: Friday, May 15, 2015 12:30 PM >>>>> To: Maor Lipchuk >>>>> Cc: users(a)ovirt.org >>>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> Thank you for your reply! >>>>> I'm unsure if the disk contained any snapshots. I do not think so. >>>>> Is the register action a safe one to do in production system? I >>>>> wouldn't mess any of my existing running servers. >>>>> >>>>> Here the relevant logs from the date >>>>> ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation >>>>> ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3) >>>>> ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last >>>>> occurrence of the imageid >>>>> >>>>> Please note from >>>>> ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of >>>>> two disk OVF store (??) on the same storage domain >>>>> 7a48fe46-2112-40a4-814f-24d74c760b2d >>>>> right after the volume expansion >>>>> >>>>> In the instructions.txt what I did to enlarge the volume (and >>>>> lose the >>>>> disk) (the guides is informational only, I followed the steps on a >>>>> different >>>>> server) >>>>> >>>>> Here some cats to thank you in advance >>>>> https://www.youtube.com/watch?v=nfTY41-zC7Y >>>> >>>> >>>> lol :) >>>> Nice cats >>>> >>>>> AG >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>>>> Sent: Wednesday, May 13, 2015 11:02 PM >>>>> To: Andrea Ghelardi >>>>> Cc: users(a)ovirt.org >>>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> Hi Andrea, >>>>> >>>>> First of all, the issue sounds quite severe, can u please attach >>>>> the engine logs so we can try to figure out how that happened. >>>>> second, does this disk contained any snapshots? >>>>> If not, can you try to register it back (see >>>>> http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre >>>>> gi >>>>> st >>>>> ered_disk) >>>>> >>>>> >>>>> Regards, >>>>> Maor >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>>>> To: users(a)ovirt.org >>>>>> Sent: Monday, May 11, 2015 12:01:17 AM >>>>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>>>> expansion >>>>>> >>>>>> >>>>>> >>>>>> Ok, so, >>>>>> >>>>>> After _ a lot _ of unsuccessful approach, I finally connected to >>>>>> postegre DB directly. >>>>>> >>>>>> Browsing the tables I found “unregistered_ovf_of_entities” where >>>>>> there is a reference of the missing disk >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3 >>>>>> >>>>>> @ovf:size:210 >>>>>> >>>>>> @ovf:actual_size:210 >>>>>> >>>>>> @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882 >>>>>> >>>>>> @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16- >>>>>> 45 >>>>>> 2d >>>>>> -8 >>>>>> 521-4ff0b004aef3 >>>>>> >>>>>> @ovf:format: >>>>>> http://www.vmware.com/specifications/vmdk.html#sparse >>>>>> >>>>>> @ovf:volume-format:RAW >>>>>> >>>>>> @ovf:volume-type:Preallocated >>>>>> >>>>>> @ovf:disk-interface:VirtIO >>>>>> >>>>>> @ovf:boot:false >>>>>> >>>>>> @ovf:disk-alias:hertz_disk5 >>>>>> >>>>>> @ovf:disk-description:disk for SYBASE installation, on SAN shared >>>>>> storage >>>>>> >>>>>> @ovf:wipe-after-delete:false >>>>>> >>>>>> >>>>>> >>>>>> However, I’ve been unable to find any other helpful details. >>>>>> >>>>>> I guess the disk is not recoverable at this point? >>>>>> >>>>>> Any guru who has a good ovirt DB kwnoledge willing to give me >>>>>> some advice? >>>>>> >>>>>> >>>>>> >>>>>> Thanks as usual >>>>>> >>>>>> AG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ] >>>>>> Sent: Thursday, May 07, 2015 6:08 PM >>>>>> To: ' users(a)ovirt.org ' >>>>>> Subject: missing disk after storage domain expansion >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi gentlemen, >>>>>> >>>>>> >>>>>> >>>>>> I recently found an error on 1 of my storages: it was complaining >>>>>> about no free space but the VM was running and disk operational. >>>>>> >>>>>> Since I needed to perform some maintenance on the VM, I shut it >>>>>> down and at restart VM couldn’t boot up properly. >>>>>> >>>>>> Checked VM via console and a disk was missing. Edited fstab >>>>>> (luckily this disk was not root but heck! It had a Sybase DB on >>>>>> it!) and restarted VM this time ok. >>>>>> >>>>>> >>>>>> >>>>>> Since the disk resides on the dstore with no space, I expanded >>>>>> the iSCSI LUN, then refreshed multipath on hosts, then resized >>>>>> PVs and now ovirt is showing the correct size (logs do not >>>>>> complain anymore on no free space). >>>>>> >>>>>> >>>>>> >>>>>> BUUUT >>>>>> >>>>>> >>>>>> >>>>>> Now disk is missing. It is not shown anymore on Disks tab nor >>>>>> anywhere else. >>>>>> >>>>>> Problem is that storage shows 214GB occupancy (size of the >>>>>> missing >>>>>> disk) so data is there but cannot find it anymore. >>>>>> >>>>>> >>>>>> >>>>>> Logs show original disk creation, errors from the lack of space, >>>>>> refresh of the storage size and then.... no more references on >>>>>> the disk. >>>>>> >>>>>> >>>>>> >>>>>> What can I do to find those missing ~210GBs? >>>>>> >>>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> Andrea Ghelardi >>>>>> -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

1 0

Huge, unrotated /var/log/glusterfs/cli.log
by Ernest Beinrohr 20 May '15

20 May '15

This is a multi-part message in MIME format. --------------050503090908010601040603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Does anyone else has these on their HVs? I just dropped a new logrotate config, but I think ovirt need to lower the loglevel for gluster. -- Ernest Beinrohr, AXON PRO Ing <http://www.beinrohr.sk/ing.php>, RHCE <http://www.beinrohr.sk/rhce.php>, RHCVA <http://www.beinrohr.sk/rhce.php>, LPIC <http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>, +421-2-62410360 +421-903-482603 --------------050503090908010601040603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Does anyone else has these on their HVs?<br> <br> I just dropped a new logrotate config, but I think ovirt need to lower the loglevel for gluster.<br> <br> <br> <div class="moz-signature">-- <br> <div id="oernii_footer" style="color: gray;"> <span style="font-family: Lucida Console, Luxi Mono, Courier, monospace; font-size: 90%;"> Ernest Beinrohr, AXON PRO<br> <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/ing.php">Ing</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/vca.php">VCA</a>, <br> +421-2-62410360 +421-903-482603 <br> </span> </div> <img src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk" moz-do-not-send="true" border="0" width="1" height="1"> </div> </body> </html> --------------050503090908010601040603--

2 1

Re: [ovirt-users] missing disk after storage domain expansion
by Andrea Ghelardi 20 May '15

20 May '15

I got an error but I'm not 100% sure I did everything correctly Error below: <html><head><title>JBoss Web/7.0.13.Final - Error report</title><style></style> </head><body><h1>HTTP Status 415 - Cannot consume content type</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>Cannot consume content type</u></p><p><b>description</b> <u>The server refused this request because the request entity is in a format not supported by the requested resource for the requested method (Cannot consume content type).</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></html> Actions: Used RESTclient 2.3.0 for Firefox to POST this body <disk id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk> I think I need a step by step guide about how to use the REST client to POST commands to ovirt service remotely Cheers AG -----Original Message----- From: Maor Lipchuk [mailto:mlipchuk@redhat.com] Sent: Monday, May 18, 2015 4:50 PM To: Andrea Ghelardi Subject: Re: [ovirt-users] missing disk after storage domain expansion I've went through the logs, though I didn't noticed any special information. Please let me know how the registration of the disk went. Regards, Maor ----- Original Message ----- > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > Sent: Monday, May 18, 2015 4:35:30 PM > Subject: RE: [ovirt-users] missing disk after storage domain expansion > > Here the full set of logs as promised. > > Unfortunately, I do not think I have vdsm logs pointing to that date > (logs rotated already). > I tried to search for > xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but > nothing found > > cheers > AG > > -----Original Message----- > From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] > Sent: Monday, May 18, 2015 3:30 PM > To: 'Maor Lipchuk' > Cc: 'users(a)ovirt.org' > Subject: RE: [ovirt-users] missing disk after storage domain expansion > > Hi Maor, > > 1) disk creation: ok > 2) no free space at the moment of creation: this is very strange! Are > you sure? I assure you the disk was working, exported to VM which > formatted and wrote data on it > 3) no disk removal mention: this is the very issue I'm facing. In fact > disk disappeared with no notification, no logs, nothing. I'm > forwarding you full set of engine.log separately. If you need > vdsm.logs just tell me from which server you need it as I have several > cluster. > 4) I have not yet tried to register using the procedure you provided > me earlier. I'll try tomorrow. > > Thanks > AG > > > -----Original Message----- > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > Sent: Monday, May 18, 2015 1:15 PM > To: Andrea Ghelardi > Cc: users(a)ovirt.org > Subject: Re: [ovirt-users] missing disk after storage domain expansion > > Hi Andrea, > > I guessed I missed those logs, I found it now, thanks. > > I do see the disk creation in the log from 20150501, I can also see > that the Storage Domain hertz-dstore2 has 0 GB of free space at the > moment of > creation: > 2015-05-01 03:30:05,801 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack: > null, Custom Event ID: -1, Message: Critical, Low disk space. > hertz-dstore2 domain has 0 GB of free space > > though, I don't see any indication of the removed disks from the engine. > I have also noticed a gap from the first log which finished at > 2015-05-01 > 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879. > > Did you try to register the disk as described in the wiki? > > Regards, > Maor > > > > > ----- Original Message ----- > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > Cc: users(a)ovirt.org > > Sent: Monday, May 18, 2015 12:10:55 PM > > Subject: RE: [ovirt-users] missing disk after storage domain > > expansion > > > > Hi Maor, > > I already added logs in my previous email, did you received them? > > I'm sending them again, but only privately to you not to burden the > > mailing list (or let me know if you prefer otherwise). > > > > Cheers > > AG > > > > > > -----Original Message----- > > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > > Sent: Saturday, May 16, 2015 10:03 AM > > To: Andrea Ghelardi > > Cc: users(a)ovirt.org > > Subject: Re: [ovirt-users] missing disk after storage domain > > expansion > > > > Hi Andrea, > > > > The OVF_STORE disks are disks which mainly being used internally in > > the engine to store VMs' and Templates' OVFs, you can disregard them > > for now. > > > > The behavior you mentioned, that suddenly the disk has disappeared > > from the setup, sounds very weird and I would like to investigate > > this a bit more. > > if you can please add the engine and vdsm logs, I can know what made > > the disk get removed from the setup, at the first place. > > Could it be that some one accessed the data base by any chance? > > > > Regarding the disk registration, basically it should not create any > > problems unless, if your disk was deleted manually form the DB, and > > there are still leftovers related to the disk in some of the tables. > > Once the disk is registered to the setup, you can try to attach it > > to the VM, and try to run it. > > > > > > Regards, > > Maor > > > > > > > > ----- Original Message ----- > > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > Cc: users(a)ovirt.org > > > Sent: Friday, May 15, 2015 4:54:25 PM > > > Subject: RE: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > After querying the hosted engine with the suggested command > > > https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4 > > > 6- > > > 21 12-40a4-814f-24d74c760b2d/disks;unregistered > > > > > > Indeed shows a (unregistered?) disk > > > > > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks> > > > <disk > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41" > > > id="16736ce0-a9df-410f-9f29-3a28364cdd41"> > > > <actions> > > > <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export" > > > rel="export"/> > > > </actions> > > > <name>hertz_disk5</name> > > > <description>disk for SYBASE installation, on SAN shared > > > storage</description> <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions" > > > rel="permissions"/> > > > <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics" > > > rel="statistics"/> > > > <alias>hertz_disk5</alias> > > > <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id> > > > <storage_domain > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d" > > > id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> > > > <storage_domains> > > > <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> > > > </storage_domains> > > > <size>225485783040</size> > > > <provisioned_size>225485783040</provisioned_size> > > > <actual_size>225485783040</actual_size> > > > <status> > > > <state>ok</state> > > > </status> > > > <interface>ide</interface> > > > <format>raw</format> > > > <sparse>false</sparse> > > > <bootable>false</bootable> > > > <shareable>false</shareable> > > > <wipe_after_delete>false</wipe_after_delete> > > > <propagate_errors>false</propagate_errors> > > > </disk> > > > </disks> > > > > > > I'm waiting for any comments on the two OVF disk or any advice > > > before proceeding with the registering command (test in production > > > environment hmmmmm) > > > > > > Cheers > > > AG > > > > > > -----Original Message----- > > > From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] > > > Sent: Friday, May 15, 2015 12:30 PM > > > To: Maor Lipchuk > > > Cc: users(a)ovirt.org > > > Subject: RE: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > Thank you for your reply! > > > I'm unsure if the disk contained any snapshots. I do not think so. > > > Is the register action a safe one to do in production system? I > > > wouldn't mess any of my existing running servers. > > > > > > Here the relevant logs from the date > > > ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation > > > ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3) > > > ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last > > > occurrence of the imageid > > > > > > Please note from > > > ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of > > > two disk OVF store (??) on the same storage domain > > > 7a48fe46-2112-40a4-814f-24d74c760b2d > > > right after the volume expansion > > > > > > In the instructions.txt what I did to enlarge the volume (and > > > lose the > > > disk) (the guides is informational only, I followed the steps on a > > > different > > > server) > > > > > > Here some cats to thank you in advance > > > https://www.youtube.com/watch?v=nfTY41-zC7Y > > > > > > lol :) > > Nice cats > > > > > AG > > > > > > > > > -----Original Message----- > > > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > > > Sent: Wednesday, May 13, 2015 11:02 PM > > > To: Andrea Ghelardi > > > Cc: users(a)ovirt.org > > > Subject: Re: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > Hi Andrea, > > > > > > First of all, the issue sounds quite severe, can u please attach > > > the engine logs so we can try to figure out how that happened. > > > second, does this disk contained any snapshots? > > > If not, can you try to register it back (see > > > http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre > > > gi > > > st > > > ered_disk) > > > > > > > > > Regards, > > > Maor > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > > > To: users(a)ovirt.org > > > > Sent: Monday, May 11, 2015 12:01:17 AM > > > > Subject: Re: [ovirt-users] missing disk after storage domain > > > > expansion > > > > > > > > > > > > > > > > Ok, so, > > > > > > > > After _ a lot _ of unsuccessful approach, I finally connected to > > > > postegre DB directly. > > > > > > > > Browsing the tables I found “unregistered_ovf_of_entities” where > > > > there is a reference of the missing disk > > > > > > > > > > > > > > > > > > > > > > > > @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3 > > > > > > > > @ovf:size:210 > > > > > > > > @ovf:actual_size:210 > > > > > > > > @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882 > > > > > > > > @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16- > > > > 45 > > > > 2d > > > > -8 > > > > 521-4ff0b004aef3 > > > > > > > > @ovf:format: > > > > http://www.vmware.com/specifications/vmdk.html#sparse > > > > > > > > @ovf:volume-format:RAW > > > > > > > > @ovf:volume-type:Preallocated > > > > > > > > @ovf:disk-interface:VirtIO > > > > > > > > @ovf:boot:false > > > > > > > > @ovf:disk-alias:hertz_disk5 > > > > > > > > @ovf:disk-description:disk for SYBASE installation, on SAN > > > > shared storage > > > > > > > > @ovf:wipe-after-delete:false > > > > > > > > > > > > > > > > However, I’ve been unable to find any other helpful details. > > > > > > > > I guess the disk is not recoverable at this point? > > > > > > > > Any guru who has a good ovirt DB kwnoledge willing to give me > > > > some advice? > > > > > > > > > > > > > > > > Thanks as usual > > > > > > > > AG > > > > > > > > > > > > > > > > > > > > From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ] > > > > Sent: Thursday, May 07, 2015 6:08 PM > > > > To: ' users(a)ovirt.org ' > > > > Subject: missing disk after storage domain expansion > > > > > > > > > > > > > > > > > > > > Hi gentlemen, > > > > > > > > > > > > > > > > I recently found an error on 1 of my storages: it was > > > > complaining about no free space but the VM was running and disk > > > > operational. > > > > > > > > Since I needed to perform some maintenance on the VM, I shut it > > > > down and at restart VM couldn’t boot up properly. > > > > > > > > Checked VM via console and a disk was missing. Edited fstab > > > > (luckily this disk was not root but heck! It had a Sybase DB on > > > > it!) and restarted VM this time ok. > > > > > > > > > > > > > > > > Since the disk resides on the dstore with no space, I expanded > > > > the iSCSI LUN, then refreshed multipath on hosts, then resized > > > > PVs and now ovirt is showing the correct size (logs do not > > > > complain anymore on no free space). > > > > > > > > > > > > > > > > BUUUT > > > > > > > > > > > > > > > > Now disk is missing. It is not shown anymore on Disks tab nor > > > > anywhere else. > > > > > > > > Problem is that storage shows 214GB occupancy (size of the > > > > missing > > > > disk) so data is there but cannot find it anymore. > > > > > > > > > > > > > > > > Logs show original disk creation, errors from the lack of space, > > > > refresh of the storage size and then.... no more references on > > > > the disk. > > > > > > > > > > > > > > > > What can I do to find those missing ~210GBs? > > > > > > > > > > > > > > > > Cheers > > > > > > > > Andrea Ghelardi > > > > > > > > > > > > > > > > _______________________________________________ > > > > Users mailing list > > > > Users(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > > > > >

3 2

Gluster and Export Storage
by ml＠ohnewald.net 20 May '15

20 May '15

Hello List, i have a GlusterFS Data (Master) Storage and a NFS Export Storage. Now my NFS Export Storage is broken. Does this also put my GlusterFS Data Storage into Unknown status? I think my GlusterFS Storage is totally fine, but it wont come up. :-( ° No Split Brain ° Peers are there ° everything is online Its related to this: http://lists.ovirt.org/pipermail/users/2015-May/032889.html It would be cool to get my GlusterFS Up and Running again in order to migrate the vms onto one host and then reboot my empty one. Here is some more gluster info: http://fpaste.org/223283/03230114/ Any ideas? Does the NFS Export Problem really block my GlusterData Domain?! Thanks, Mario

2 1