From jeremy.clerc at celeste.fr Fri Aug 23 10:57:22 2013 Content-Type: multipart/mixed; boundary="===============0311003735960901232==" MIME-Version: 1.0 From: =?utf-8?q?J=C3=A9r=C3=A9my_Clerc_=3Cjeremy=2Eclerc_at_celeste=2Efr=3E?= To: users at ovirt.org Subject: [Users] iSCSI VM storage overlap Date: Fri, 23 Aug 2013 16:57:10 +0200 Message-ID: <1633448167.1535591377269830993.JavaMail.root@zm-store01> In-Reply-To: 1209265474.1535531377269771733.JavaMail.root@zm-store01 --===============0311003735960901232== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_80562_294231023.1377269830992 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable Hello,=3D20 We have a 3 node setup with one for ovirt-engine managing the 2 others node= =3D s.=3D20 OS on all nodes is CentOS release 6.4 (Final)=3D20 Ovirt version is 3.2.1-1.beta1.el6.noarch=3D20 It uses an iSCSI IBM Backend.=3D20 When importing 2 VMs from exports, it happens that after importing VM1, you= =3D import VM2 and it overwrites some parts of VM1's disk, and so you lose pre= =3D tty much all your data.=3D20 So it is like the SPM does not know where it wrote VM1. I have found any re= =3D levant logs.=3D20 Has anyone already experienced this ?=3D20 Thanks,=3D20 J=3DC3=3DA9r=3DC3=3DA9my=3D20 ------=3D_Part_80562_294231023.1377269830992 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable <=3D div style=3D3D'font-family: Arial; font-size: 12pt; color: #000099'>

Hello,

We have a 3 node setup with one for ovirt-engin= =3D e managing the 2 others nodes.

OS on all nodes is CentOS release 6.4= =3D (Final)

Ovirt version is 3.2.1-1.beta1.el6.noarch

It uses an= =3D iSCSI IBM Backend.

When importing 2 VMs from exports, it happen= =3D s that after importing VM1, you import VM2 and it overwrites some parts of = =3D VM1's disk, and so you lose pretty much all your data.

So it is like= =3D the SPM does not know where it wrote VM1. I have found any relevant = =3D logs.

Has anyone already experienced this ?

Thanks,

=3D20 J=3DC3=3DA9r=3DC3=3DA9my

------=3D_Part_80562_294231023.1377269830992-- --===============0311003735960901232== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzgwNTYyXzI5NDIzMTAyMy4xMzc3MjY5ODMwOTkyCkNvbnRlbnQtVHlwZTog dGV4dC9wbGFpbjsgY2hhcnNldD11dGYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90 ZWQtcHJpbnRhYmxlCgoKSGVsbG8sPTIwCgpXZSBoYXZlIGEgMyBub2RlIHNldHVwIHdpdGggb25l IGZvciBvdmlydC1lbmdpbmUgbWFuYWdpbmcgdGhlIDIgb3RoZXJzIG5vZGU9CnMuPTIwCgpPUyBv biBhbGwgbm9kZXMgaXMgQ2VudE9TIHJlbGVhc2UgNi40IChGaW5hbCk9MjAKCk92aXJ0IHZlcnNp b24gaXMgMy4yLjEtMS5iZXRhMS5lbDYubm9hcmNoPTIwCgpJdCB1c2VzIGFuIGlTQ1NJIElCTSBC YWNrZW5kLj0yMAoKCldoZW4gaW1wb3J0aW5nIDIgVk1zIGZyb20gZXhwb3J0cywgaXQgaGFwcGVu cyB0aGF0IGFmdGVyIGltcG9ydGluZyBWTTEsIHlvdT0KIGltcG9ydCBWTTIgYW5kIGl0IG92ZXJ3 cml0ZXMgc29tZSBwYXJ0cyBvZiBWTTEncyBkaXNrLCBhbmQgc28geW91IGxvc2UgcHJlPQp0dHkg bXVjaCBhbGwgeW91ciBkYXRhLj0yMAoKU28gaXQgaXMgbGlrZSB0aGUgU1BNIGRvZXMgbm90IGtu b3cgd2hlcmUgaXQgd3JvdGUgVk0xLiBJIGhhdmUgZm91bmQgYW55IHJlPQpsZXZhbnQgbG9ncy49 MjAKCkhhcyBhbnlvbmUgYWxyZWFkeSBleHBlcmllbmNlZCB0aGlzID89MjAKClRoYW5rcyw9MjAK Cko9QzM9QTlyPUMzPUE5bXk9MjAKCi0tLS0tLT1fUGFydF84MDU2Ml8yOTQyMzEwMjMuMTM3NzI2 OTgzMDk5MgpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD11dGYtOApDb250ZW50LVRy YW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgo8aHRtbD48aGVhZD48c3R5bGUgdHlw ZT0zRCd0ZXh0L2Nzcyc+cCB7IG1hcmdpbjogMDsgfTwvc3R5bGU+PC9oZWFkPjxib2R5Pjw9CmRp diBzdHlsZT0zRCdmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMw MDAwOTknPjxzdHlsZT5wID0KeyBtYXJnaW46IDA7IH08L3N0eWxlPjxkaXYgc3R5bGU9M0QiZm9u dC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHQ7IGNvPQpsb3I6ICMwMDAwOTkiPkhlbGxv LDxicj48YnI+V2UgaGF2ZSBhIDMgbm9kZSBzZXR1cCB3aXRoIG9uZSBmb3Igb3ZpcnQtZW5naW49 CmUgbWFuYWdpbmcgdGhlIDIgb3RoZXJzIG5vZGVzLjxicj48YnI+T1Mgb24gYWxsIG5vZGVzIGlz IENlbnRPUyByZWxlYXNlIDYuND0KIChGaW5hbCk8YnI+PGJyPk92aXJ0IHZlcnNpb24gaXMgMy4y LjEtMS5iZXRhMS5lbDYubm9hcmNoPGJyPjxicj5JdCB1c2VzIGFuPQogaVNDU0kgSUJNIEJhY2tl bmQuPGJyPjxicj48YnI+V2hlbiBpbXBvcnRpbmcgMiBWTXMgZnJvbSBleHBvcnRzLCBpdCBoYXBw ZW49CnMgdGhhdCBhZnRlciBpbXBvcnRpbmcgVk0xLCB5b3UgaW1wb3J0IFZNMiBhbmQgaXQgb3Zl cndyaXRlcyBzb21lIHBhcnRzIG9mID0KVk0xJ3MgZGlzaywgYW5kIHNvIHlvdSBsb3NlIHByZXR0 eSBtdWNoIGFsbCB5b3VyIGRhdGEuPGJyPjxicj5TbyBpdCBpcyBsaWtlPQogdGhlIFNQTSBkb2Vz IG5vdCZuYnNwOyBrbm93IHdoZXJlIGl0IHdyb3RlIFZNMS4gSSBoYXZlIGZvdW5kIGFueSByZWxl dmFudCA9CmxvZ3MuPGJyPjxicj5IYXMgYW55b25lIGFscmVhZHkgZXhwZXJpZW5jZWQgdGhpcyA/ PGJyPjxicj5UaGFua3MsPGJyPjxicj4KCiAgICAgICA9MjAKICAgICAgICAgICAgICAgIDxzcGFu IHN0eWxlPTNEImNvbG9yOiByZ2IoMCwgMCwgMTUzKTsgZm9udC1zaXplOiAxMjsgZm9udC13PQpl aWdodDogYm9sZDsiPko9QzM9QTlyPUMzPUE5bXk8YnI+PC9zcGFuPjwvZGl2PjwvZGl2PjwvYm9k eT48L2h0bWw+Ci0tLS0tLT1fUGFydF84MDU2Ml8yOTQyMzEwMjMuMTM3NzI2OTgzMDk5Mi0tCg== --===============0311003735960901232==--