From Bryan.Sockel at altn.com Sat Jun 3 03:20:21 2017 Content-Type: multipart/mixed; boundary="===============1655568999440711269==" MIME-Version: 1.0 From: Bryan Sockel To: users at ovirt.org Subject: Re: [ovirt-users] VM/Template copy issue Date: Fri, 02 Jun 2017 22:20:17 -0500 Message-ID: --===============1655568999440711269== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. ----_com.samsung.android.email_5990013383491030 Content-Type: text/plain; charset=3D"utf-8" Content-Transfer-Encoding: 7bit This happening to a number of vm's. All vm's are running and can be stopped and re started. We can read and write data within the vm. All vms are currently running on a single node gluster file system. I am attempting to migrate to a replica 3 gluster file system when i exprience these issues. The problem always seems to happen when finalizing the move or copy. If it makes a difference the gluster storage we are coping to and from are dedicated storage servers. -------- Original message -------- From: Maor Lipchuk = Date: 6/2/17 5:29 PM (GMT-06:00) = To: Bryan Sockel = Cc: users(a)ovirt.org = Subject: Re: [ovirt-users] VM/Template copy issue = _____ = >From : Maor Lipchuk [mlipchuk(a)redhat.com] To : Bryan Sockel [Bryan.Sockel(a)altn.com] Cc : users(a)ovirt.org [users(a)ovirt.org] Date : Friday, June 2 2017 17:27:32 Hi Bryan, It seems like there was an error from qemu-img while reading sector 143654878 . the Image copy (conversion) failed with low level qemu-img failure: CopyImageError: low level Image copy failed: ("cmd=3D['/usr/bin/taskset', '--cpu-list', '0-31', '/usr/bin/nice', '-n', '19', '/usr/bin/ionice', '-c', '3', '/usr/bin/qemu-img', 'convert', '-p', '-t', 'none', '-T', 'none', '-f', 'raw', u'/rhev/data-center/d776b537-16f2-4543-bd96-9b4cba69e247/e371d380-7194-4 950-b901-5f2aed5dfb35/images/9959c6e4-1fb7-455b-ad5e-8b9e2324a0ab/3f4e18 3b-7957-4bee-9153-9d967491f882', '-O', 'raw', u'/rhev/data-center/mnt/glusterSD/vs-host-colo-1-gluster.altn.int:_deskt op-vdi1/f927ceb8-91d2-41bd-ba42-dc795395b6d0/images/9959c6e4-1fb7-455b-a d5e-8b9e2324a0ab/3f4e183b-7957-4bee-9153-9d967491f882'], ecode=3D1, stdout=3D, stderr=3Dqemu-img: error while reading sector 143654878: No data available\n, message=3DNone",) Can you verify those disks are indeed valid? Can you IO to them while attaching them to a running VM? On Tue, May 30, 2017 at 9:10 PM, Bryan Sockel wrote: > > Hi, > > I am trying to rebuild my ovirt environment after having to juggle some > hardware around. I am moving from hosted engine environment into a engine > install on a dedicated server. I have two data centers in my setup and each > DC has a non-routable vlan dedicated to storage. > > As i rebuild my setup i am trying to clean up my storage configuration. I > am attempting to copy vm's and templates to a dedicated gluster setup. > However each time i attempt to copy a template or move a vm, the operation > fails. The failure always happens when it is finalizing the copy. > > The operation does not happen with all vm's, but seems to happen mostly with > vm's created from with in Ovirt, and not imported from vmware. > > > I have attached the logs from where i was trying to copy to templates to a > new Gluster Filesystem > > Thanks > Bryan > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ----_com.samsung.android.email_5990013383491030 Content-Type: text/html; charset=3D"utf-8" Content-Transfer-Encoding: quoted-printable
This happening to a number  of = =3D vm's. All vm's are running and can be stopped and re started.  We =3D can read and write data within the vm.

All vms =3D are currently running on a single node gluster file system.  I am =3D attempting to migrate to a replica 3 gluster file system when i =3D exprience these issues.  The problem always seems to happen when =3D finalizing the move or copy.

If it makes a =3D difference the gluster storage we are coping to and from are dedicated =3D storage servers.


-------- Original message --------
From: Maor Lipchuk =3D <mlipchuk(a)redhat.com>
Date: 6/2/17 5:29 PM =3D (GMT-06:00)
To: Bryan Sockel <Bryan.Sockel(a)altn.com> =3D
Cc: users(a)ovirt.org
Subject: Re: [ovirt-users] =3D VM/Template copy issue

From : Maor Lipchuk =3D [mlipchuk(a)redhat.com]
To : Bryan Sockel [Bryan.Sockel(a)altn.com]
Cc : users(a)ovirt.org =3D [users(a)ovirt.org]
Date =3D : Friday, June 2 2017 17:27:32
=3D0A=3D 
Hi Bryan,

It seems like there was an error from qemu-img while reading sector =3D
143654878 .
 the Image copy (conversion) failed with low level qemu-img failure:

CopyImageError: low level Image copy failed:
("cmd=3D3D['/usr/bin/taskset', '--cpu-list', '0-31', '/usr/bin/nice',
'-n', '19', '/usr/bin/ionice', '-c', '3', '/usr/bin/qemu-img',
'convert', '-p', '-t', 'none', '-T', 'none', '-f', 'raw',
u'/rhev/data-center/d776b537-16f2-4543-bd96-9b4cba69e247/e371d380-7194-49=
=3D
50-b901-5f2aed5dfb35/images/9959c6e4-1fb7-455b-ad5e-8b9e2324a0ab/3f4e183b=
=3D
-7957-4bee-9153-9d967491f882',
'-O', 'raw', =3D
u'/rhev/data-center/mnt/glusterSD/vs-host-colo-1-gluster.altn.int:_deskto=
=3D
p-vdi1/f927ceb8-91d2-41bd-ba42-dc795395b6d0/images/9959c6e4-1fb7-455b-ad5=
=3D
e-8b9e2324a0ab/3f4e183b-7957-4bee-9153-9d967491f882'],
ecode=3D3D1, stdout=3D3D, stderr=3D3Dqemu-img: error while reading sector
143654878: No data available\n, message=3D3DNone",)

Can you verify those disks are indeed valid? Can you IO to them while
attaching them to a running VM?

On Tue, May 30, 2017 at 9:10 PM, Bryan Sockel  =3D
wrote:
>
> Hi,
>
> I am trying to rebuild my ovirt environment after having to juggle =3D
some
> hardware around.  I am moving from hosted engine environment into a =3D
engine
> install on a dedicated server.  I have two data centers in my setup =3D
and each
> DC has a non-routable vlan dedicated to storage.
>
> As i rebuild my setup i am trying to clean up my storage =3D
configuration.  I
> am attempting to copy vm's and templates to a dedicated gluster setup.
> However  each time i attempt to copy a template or move a vm, the =3D
operation
> fails.  The failure always happens when it is finalizing the copy.
>
> The operation does not happen with all vm's, but seems to happen =3D
mostly with
> vm's created from with in Ovirt, and not imported from vmware.
>
>
> I have attached the logs from where i was trying to copy to templates =3D
to a
> new Gluster Filesystem
>
> Thanks
> Bryan
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
----_com.samsung.android.email_5990013383491030-- --===============1655568999440711269== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KCi0tLS1fY29tLnNh bXN1bmcuYW5kcm9pZC5lbWFpbF81OTkwMDEzMzgzNDkxMDMwCkNvbnRlbnQtVHlwZTogdGV4dC9w bGFpbjsKCWNoYXJzZXQ9InV0Zi04IgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0CgpU aGlzIGhhcHBlbmluZyB0byBhIG51bWJlciAgb2Ygdm0ncy4gQWxsIHZtJ3MgYXJlIHJ1bm5pbmcg YW5kIGNhbiBiZQpzdG9wcGVkIGFuZCByZSBzdGFydGVkLiAgV2UgY2FuIHJlYWQgYW5kIHdyaXRl IGRhdGEgd2l0aGluIHRoZSB2bS4KCkFsbCB2bXMgYXJlIGN1cnJlbnRseSBydW5uaW5nIG9uIGEg c2luZ2xlIG5vZGUgZ2x1c3RlciBmaWxlIHN5c3RlbS4gIEkKYW0gYXR0ZW1wdGluZyB0byBtaWdy YXRlIHRvIGEgcmVwbGljYSAzIGdsdXN0ZXIgZmlsZSBzeXN0ZW0gd2hlbiBpCmV4cHJpZW5jZSB0 aGVzZSBpc3N1ZXMuICBUaGUgcHJvYmxlbSBhbHdheXMgc2VlbXMgdG8gaGFwcGVuIHdoZW4KZmlu YWxpemluZyB0aGUgbW92ZSBvciBjb3B5LgoKSWYgaXQgbWFrZXMgYSBkaWZmZXJlbmNlIHRoZSBn bHVzdGVyIHN0b3JhZ2Ugd2UgYXJlIGNvcGluZyB0byBhbmQgZnJvbQphcmUgZGVkaWNhdGVkIHN0 b3JhZ2Ugc2VydmVycy4KCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206 IE1hb3IgTGlwY2h1ayA8bWxpcGNodWtAcmVkaGF0LmNvbT4gCkRhdGU6IDYvMi8xNyA1OjI5IFBN IChHTVQtMDY6MDApIApUbzogQnJ5YW4gU29ja2VsIDxCcnlhbi5Tb2NrZWxAYWx0bi5jb20+IApD YzogdXNlcnNAb3ZpcnQub3JnIApTdWJqZWN0OiBSZTogW292aXJ0LXVzZXJzXSBWTS9UZW1wbGF0 ZSBjb3B5IGlzc3VlIAoKICBfX19fXyAgCgo+RnJvbSA6IE1hb3IgTGlwY2h1ayBbbWxpcGNodWtA cmVkaGF0LmNvbV0KVG8gOiBCcnlhbiBTb2NrZWwgW0JyeWFuLlNvY2tlbEBhbHRuLmNvbV0KQ2Mg OiB1c2Vyc0BvdmlydC5vcmcgW3VzZXJzQG92aXJ0Lm9yZ10KRGF0ZSA6IEZyaWRheSwgSnVuZSAy IDIwMTcgMTc6Mjc6MzIKSGkgQnJ5YW4sCgpJdCBzZWVtcyBsaWtlIHRoZXJlIHdhcyBhbiBlcnJv ciBmcm9tIHFlbXUtaW1nIHdoaWxlIHJlYWRpbmcgc2VjdG9yCjE0MzY1NDg3OCAuCiB0aGUgSW1h Z2UgY29weSAoY29udmVyc2lvbikgZmFpbGVkIHdpdGggbG93IGxldmVsIHFlbXUtaW1nIGZhaWx1 cmU6CgpDb3B5SW1hZ2VFcnJvcjogbG93IGxldmVsIEltYWdlIGNvcHkgZmFpbGVkOgooImNtZD1b Jy91c3IvYmluL3Rhc2tzZXQnLCAnLS1jcHUtbGlzdCcsICcwLTMxJywgJy91c3IvYmluL25pY2Un LAonLW4nLCAnMTknLCAnL3Vzci9iaW4vaW9uaWNlJywgJy1jJywgJzMnLCAnL3Vzci9iaW4vcWVt dS1pbWcnLAonY29udmVydCcsICctcCcsICctdCcsICdub25lJywgJy1UJywgJ25vbmUnLCAnLWYn LCAncmF3JywKdScvcmhldi9kYXRhLWNlbnRlci9kNzc2YjUzNy0xNmYyLTQ1NDMtYmQ5Ni05YjRj YmE2OWUyNDcvZTM3MWQzODAtNzE5NC00Cjk1MC1iOTAxLTVmMmFlZDVkZmIzNS9pbWFnZXMvOTk1 OWM2ZTQtMWZiNy00NTViLWFkNWUtOGI5ZTIzMjRhMGFiLzNmNGUxOAozYi03OTU3LTRiZWUtOTE1 My05ZDk2NzQ5MWY4ODInLAonLU8nLCAncmF3JywKdScvcmhldi9kYXRhLWNlbnRlci9tbnQvZ2x1 c3RlclNEL3ZzLWhvc3QtY29sby0xLWdsdXN0ZXIuYWx0bi5pbnQ6X2Rlc2t0Cm9wLXZkaTEvZjky N2NlYjgtOTFkMi00MWJkLWJhNDItZGM3OTUzOTViNmQwL2ltYWdlcy85OTU5YzZlNC0xZmI3LTQ1 NWItYQpkNWUtOGI5ZTIzMjRhMGFiLzNmNGUxODNiLTc5NTctNGJlZS05MTUzLTlkOTY3NDkxZjg4 MiddLAplY29kZT0xLCBzdGRvdXQ9LCBzdGRlcnI9cWVtdS1pbWc6IGVycm9yIHdoaWxlIHJlYWRp bmcgc2VjdG9yCjE0MzY1NDg3ODogTm8gZGF0YSBhdmFpbGFibGVcbiwgbWVzc2FnZT1Ob25lIiwp CgpDYW4geW91IHZlcmlmeSB0aG9zZSBkaXNrcyBhcmUgaW5kZWVkIHZhbGlkPyBDYW4geW91IElP IHRvIHRoZW0gd2hpbGUKYXR0YWNoaW5nIHRoZW0gdG8gYSBydW5uaW5nIFZNPwoKT24gVHVlLCBN YXkgMzAsIDIwMTcgYXQgOToxMCBQTSwgQnJ5YW4gU29ja2VsICB3cm90ZToKPgo+IEhpLAo+Cj4g SSBhbSB0cnlpbmcgdG8gcmVidWlsZCBteSBvdmlydCBlbnZpcm9ubWVudCBhZnRlciBoYXZpbmcg dG8ganVnZ2xlCnNvbWUKPiBoYXJkd2FyZSBhcm91bmQuICBJIGFtIG1vdmluZyBmcm9tIGhvc3Rl ZCBlbmdpbmUgZW52aXJvbm1lbnQgaW50byBhCmVuZ2luZQo+IGluc3RhbGwgb24gYSBkZWRpY2F0 ZWQgc2VydmVyLiAgSSBoYXZlIHR3byBkYXRhIGNlbnRlcnMgaW4gbXkgc2V0dXAKYW5kIGVhY2gK PiBEQyBoYXMgYSBub24tcm91dGFibGUgdmxhbiBkZWRpY2F0ZWQgdG8gc3RvcmFnZS4KPgo+IEFz IGkgcmVidWlsZCBteSBzZXR1cCBpIGFtIHRyeWluZyB0byBjbGVhbiB1cCBteSBzdG9yYWdlCmNv bmZpZ3VyYXRpb24uICBJCj4gYW0gYXR0ZW1wdGluZyB0byBjb3B5IHZtJ3MgYW5kIHRlbXBsYXRl cyB0byBhIGRlZGljYXRlZCBnbHVzdGVyIHNldHVwLgo+IEhvd2V2ZXIgIGVhY2ggdGltZSBpIGF0 dGVtcHQgdG8gY29weSBhIHRlbXBsYXRlIG9yIG1vdmUgYSB2bSwgdGhlCm9wZXJhdGlvbgo+IGZh aWxzLiAgVGhlIGZhaWx1cmUgYWx3YXlzIGhhcHBlbnMgd2hlbiBpdCBpcyBmaW5hbGl6aW5nIHRo ZSBjb3B5Lgo+Cj4gVGhlIG9wZXJhdGlvbiBkb2VzIG5vdCBoYXBwZW4gd2l0aCBhbGwgdm0ncywg YnV0IHNlZW1zIHRvIGhhcHBlbgptb3N0bHkgd2l0aAo+IHZtJ3MgY3JlYXRlZCBmcm9tIHdpdGgg aW4gT3ZpcnQsIGFuZCBub3QgaW1wb3J0ZWQgZnJvbSB2bXdhcmUuCj4KPgo+IEkgaGF2ZSBhdHRh Y2hlZCB0aGUgbG9ncyBmcm9tIHdoZXJlIGkgd2FzIHRyeWluZyB0byBjb3B5IHRvIHRlbXBsYXRl cwp0byBhCj4gbmV3IEdsdXN0ZXIgRmlsZXN5c3RlbQo+Cj4gVGhhbmtzCj4gQnJ5YW4KPgo+Cj4K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFVzZXJz IG1haWxpbmcgbGlzdAo+IFVzZXJzQG92aXJ0Lm9yZwo+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcv bWFpbG1hbi9saXN0aW5mby91c2Vycwo+CgotLS0tX2NvbS5zYW1zdW5nLmFuZHJvaWQuZW1haWxf NTk5MDAxMzM4MzQ5MTAzMApDb250ZW50LVR5cGU6IHRleHQvaHRtbDsKCWNoYXJzZXQ9InV0Zi04 IgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgo8aHRtbD48aGVh ZD48bWV0YSBodHRwLWVxdWl2PTNEIkNvbnRlbnQtVHlwZSIgY29udGVudD0zRCJ0ZXh0L2h0bWw7 ID0KY2hhcnNldD0zRFVURi04Ij48L2hlYWQ+PGJvZHk+PGRpdj5UaGlzIGhhcHBlbmluZyB0byBh IG51bWJlciAmbmJzcDtvZiA9CnZtJ3MuIEFsbCB2bSdzIGFyZSBydW5uaW5nIGFuZCBjYW4gYmUg c3RvcHBlZCBhbmQgcmUgc3RhcnRlZC4gJm5ic3A7V2UgPQpjYW4gcmVhZCBhbmQgd3JpdGUgZGF0 YSB3aXRoaW4gdGhlIHZtLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWxsIHZtcyA9CmFyZSBj dXJyZW50bHkgcnVubmluZyBvbiBhIHNpbmdsZSBub2RlIGdsdXN0ZXIgZmlsZSBzeXN0ZW0uICZu YnNwO0kgYW0gPQphdHRlbXB0aW5nIHRvIG1pZ3JhdGUgdG8gYSByZXBsaWNhIDMgZ2x1c3RlciBm aWxlIHN5c3RlbSB3aGVuIGkgPQpleHByaWVuY2UgdGhlc2UgaXNzdWVzLiAmbmJzcDtUaGUgcHJv YmxlbSBhbHdheXMgc2VlbXMgdG8gaGFwcGVuIHdoZW4gPQpmaW5hbGl6aW5nIHRoZSBtb3ZlIG9y IGNvcHkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JZiBpdCBtYWtlcyBhID0KZGlmZmVyZW5j ZSB0aGUgZ2x1c3RlciBzdG9yYWdlIHdlIGFyZSBjb3BpbmcgdG8gYW5kIGZyb20gYXJlIGRlZGlj YXRlZCA9CnN0b3JhZ2Ugc2VydmVycy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp dj48IS0tIG9yaWdpbmFsTWVzc2FnZSA9Ci0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogTWFvciBMaXBjaHVrID0KJmx0O21saXBjaHVrQHJl ZGhhdC5jb20mZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogNi8yLzE3ICA1OjI5IFBNICA9CihHTVQtMDY6 MDApIDwvZGl2PjxkaXY+VG86IEJyeWFuIFNvY2tlbCAmbHQ7QnJ5YW4uU29ja2VsQGFsdG4uY29t Jmd0OyA9CjwvZGl2PjxkaXY+Q2M6IHVzZXJzQG92aXJ0Lm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6 IFJlOiBbb3ZpcnQtdXNlcnNdID0KVk0vVGVtcGxhdGUgY29weSBpc3N1ZSA8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2ID0Kc3R5bGU9M0QibWFyZ2luLWxlZnQ6MnB4O3BhZGRpbmctbGVmdDoycHg7 Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkID0KIzIwMjAyMDsiPjxkaXYgc3R5bGU9M0QiZm9udC1zaXpl OiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOyA9CmNvbG9yOiAjMDAwMDAwOyBmb250 LXdlaWdodDogNDAwOyBmb250LWZhbWlseTogPQpUYWhvbWEsQXJpYWwsVmVyZGFuYSxzYW5zLXNl cmlmOyIgPjxociAvPjxkaXY+PHNwYW4gPQpzdHlsZT0zRCJmb250LXdlaWdodDogNzAwIj5Gcm9t PC9zcGFuPiA6IE1hb3IgTGlwY2h1ayA9ClttbGlwY2h1a0ByZWRoYXQuY29tXTwvZGl2PjxkaXY+ PHNwYW4gc3R5bGU9M0QiZm9udC13ZWlnaHQ6ID0KNzAwIj5Ubzwvc3Bhbj4gOiBCcnlhbiBTb2Nr ZWwgW0JyeWFuLlNvY2tlbEBhbHRuLmNvbV08L2Rpdj48ZGl2PjxzcGFuID0Kc3R5bGU9M0QiZm9u dC13ZWlnaHQ6IDcwMCI+Q2M8L3NwYW4+IDogdXNlcnNAb3ZpcnQub3JnID0KW3VzZXJzQG92aXJ0 Lm9yZ108L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPTNEImZvbnQtd2VpZ2h0OiA3MDAiPkRhdGU8L3Nw YW4+ID0KOiBGcmlkYXksIEp1bmUgMiAyMDE3IDE3OjI3OjMyPC9kaXY+PC9kaXY+PTBBPQo8cHJl PkhpIEJyeWFuLAoKSXQgc2VlbXMgbGlrZSB0aGVyZSB3YXMgYW4gZXJyb3IgZnJvbSBxZW11LWlt ZyB3aGlsZSByZWFkaW5nIHNlY3RvciA9CjE0MzY1NDg3OCAuCiB0aGUgSW1hZ2UgY29weSAoY29u dmVyc2lvbikgZmFpbGVkIHdpdGggbG93IGxldmVsIHFlbXUtaW1nIGZhaWx1cmU6CgpDb3B5SW1h Z2VFcnJvcjogbG93IGxldmVsIEltYWdlIGNvcHkgZmFpbGVkOgooImNtZD0zRFsnL3Vzci9iaW4v dGFza3NldCcsICctLWNwdS1saXN0JywgJzAtMzEnLCAnL3Vzci9iaW4vbmljZScsCictbicsICcx OScsICcvdXNyL2Jpbi9pb25pY2UnLCAnLWMnLCAnMycsICcvdXNyL2Jpbi9xZW11LWltZycsCidj b252ZXJ0JywgJy1wJywgJy10JywgJ25vbmUnLCAnLVQnLCAnbm9uZScsICctZicsICdyYXcnLAp1 Jy9yaGV2L2RhdGEtY2VudGVyL2Q3NzZiNTM3LTE2ZjItNDU0My1iZDk2LTliNGNiYTY5ZTI0Ny9l MzcxZDM4MC03MTk0LTQ5PQo1MC1iOTAxLTVmMmFlZDVkZmIzNS9pbWFnZXMvOTk1OWM2ZTQtMWZi Ny00NTViLWFkNWUtOGI5ZTIzMjRhMGFiLzNmNGUxODNiPQotNzk1Ny00YmVlLTkxNTMtOWQ5Njc0 OTFmODgyJywKJy1PJywgJ3JhdycsID0KdScvcmhldi9kYXRhLWNlbnRlci9tbnQvZ2x1c3RlclNE L3ZzLWhvc3QtY29sby0xLWdsdXN0ZXIuYWx0bi5pbnQ6X2Rlc2t0bz0KcC12ZGkxL2Y5MjdjZWI4 LTkxZDItNDFiZC1iYTQyLWRjNzk1Mzk1YjZkMC9pbWFnZXMvOTk1OWM2ZTQtMWZiNy00NTViLWFk NT0KZS04YjllMjMyNGEwYWIvM2Y0ZTE4M2ItNzk1Ny00YmVlLTkxNTMtOWQ5Njc0OTFmODgyJ10s CmVjb2RlPTNEMSwgc3Rkb3V0PTNELCBzdGRlcnI9M0RxZW11LWltZzogZXJyb3Igd2hpbGUgcmVh ZGluZyBzZWN0b3IKMTQzNjU0ODc4OiBObyBkYXRhIGF2YWlsYWJsZVxuLCBtZXNzYWdlPTNETm9u ZSIsKQoKQ2FuIHlvdSB2ZXJpZnkgdGhvc2UgZGlza3MgYXJlIGluZGVlZCB2YWxpZD8gQ2FuIHlv dSBJTyB0byB0aGVtIHdoaWxlCmF0dGFjaGluZyB0aGVtIHRvIGEgcnVubmluZyBWTT8KCk9uIFR1 ZSwgTWF5IDMwLCAyMDE3IGF0IDk6MTAgUE0sIEJyeWFuIFNvY2tlbCA8QnJ5YW4uU29ja2VsQGFs dG4uY29tPiA9Cndyb3RlOgo+Cj4gSGksCj4KPiBJIGFtIHRyeWluZyB0byByZWJ1aWxkIG15IG92 aXJ0IGVudmlyb25tZW50IGFmdGVyIGhhdmluZyB0byBqdWdnbGUgPQpzb21lCj4gaGFyZHdhcmUg YXJvdW5kLiAgSSBhbSBtb3ZpbmcgZnJvbSBob3N0ZWQgZW5naW5lIGVudmlyb25tZW50IGludG8g YSA9CmVuZ2luZQo+IGluc3RhbGwgb24gYSBkZWRpY2F0ZWQgc2VydmVyLiAgSSBoYXZlIHR3byBk YXRhIGNlbnRlcnMgaW4gbXkgc2V0dXAgPQphbmQgZWFjaAo+IERDIGhhcyBhIG5vbi1yb3V0YWJs ZSB2bGFuIGRlZGljYXRlZCB0byBzdG9yYWdlLgo+Cj4gQXMgaSByZWJ1aWxkIG15IHNldHVwIGkg YW0gdHJ5aW5nIHRvIGNsZWFuIHVwIG15IHN0b3JhZ2UgPQpjb25maWd1cmF0aW9uLiAgSQo+IGFt IGF0dGVtcHRpbmcgdG8gY29weSB2bSdzIGFuZCB0ZW1wbGF0ZXMgdG8gYSBkZWRpY2F0ZWQgZ2x1 c3RlciBzZXR1cC4KPiBIb3dldmVyICBlYWNoIHRpbWUgaSBhdHRlbXB0IHRvIGNvcHkgYSB0ZW1w bGF0ZSBvciBtb3ZlIGEgdm0sIHRoZSA9Cm9wZXJhdGlvbgo+IGZhaWxzLiAgVGhlIGZhaWx1cmUg YWx3YXlzIGhhcHBlbnMgd2hlbiBpdCBpcyBmaW5hbGl6aW5nIHRoZSBjb3B5Lgo+Cj4gVGhlIG9w ZXJhdGlvbiBkb2VzIG5vdCBoYXBwZW4gd2l0aCBhbGwgdm0ncywgYnV0IHNlZW1zIHRvIGhhcHBl biA9Cm1vc3RseSB3aXRoCj4gdm0ncyBjcmVhdGVkIGZyb20gd2l0aCBpbiBPdmlydCwgYW5kIG5v dCBpbXBvcnRlZCBmcm9tIHZtd2FyZS4KPgo+Cj4gSSBoYXZlIGF0dGFjaGVkIHRoZSBsb2dzIGZy b20gd2hlcmUgaSB3YXMgdHJ5aW5nIHRvIGNvcHkgdG8gdGVtcGxhdGVzID0KdG8gYQo+IG5ldyBH bHVzdGVyIEZpbGVzeXN0ZW0KPgo+IFRoYW5rcwo+IEJyeWFuCj4KPgo+Cj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBVc2VycyBtYWlsaW5nIGxpc3QK PiBVc2Vyc0BvdmlydC5vcmcKPiBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGlu Zm8vdXNlcnMKPgo8L3ByZT48L2Rpdj48L2JvZHk+PC9odG1sPgoKLS0tLV9jb20uc2Ftc3VuZy5h bmRyb2lkLmVtYWlsXzU5OTAwMTMzODM0OTEwMzAtLQoK --===============1655568999440711269==-- From mlipchuk at redhat.com Sun Jun 4 12:09:01 2017 Content-Type: multipart/mixed; boundary="===============4042720903114574421==" MIME-Version: 1.0 From: Maor Lipchuk To: users at ovirt.org Subject: Re: [ovirt-users] VM/Template copy issue Date: Sun, 04 Jun 2017 15:09:00 +0300 Message-ID: In-Reply-To: MDAS20170603032018.2010002@altn.com --===============4042720903114574421== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sat, Jun 3, 2017 at 6:20 AM, Bryan Sockel wrot= e: > This happening to a number of vm's. All vm's are running and can be stop= ped > and re started. We can read and write data within the vm. > > All vms are currently running on a single node gluster file system. I am > attempting to migrate to a replica 3 gluster file system when i exprience > these issues. The problem always seems to happen when finalizing the move > or copy. > > If it makes a difference the gluster storage we are coping to and from are > dedicated storage servers. > > > -------- Original message -------- > From: Maor Lipchuk > Date: 6/2/17 5:29 PM (GMT-06:00) > To: Bryan Sockel > Cc: users(a)ovirt.org > Subject: Re: [ovirt-users] VM/Template copy issue > > ________________________________ > From : Maor Lipchuk [mlipchuk(a)redhat.com] > To : Bryan Sockel [Bryan.Sockel(a)altn.com] > Cc : users(a)ovirt.org [users(a)ovirt.org] > Date : Friday, June 2 2017 17:27:32 > > Hi Bryan, > > It seems like there was an error from qemu-img while reading sector > 143654878 . > the Image copy (conversion) failed with low level qemu-img failure: > > CopyImageError: low level Image copy failed: > ("cmd=3D['/usr/bin/taskset', '--cpu-list', '0-31', '/usr/bin/nice', > '-n', '19', '/usr/bin/ionice', '-c', '3', '/usr/bin/qemu-img', > 'convert', '-p', '-t', 'none', '-T', 'none', '-f', 'raw', > u'/rhev/data-center/d776b537-16f2-4543-bd96-9b4cba69e247/e371d380-7194-49= 50-b901-5f2aed5dfb35/images/9959c6e4-1fb7-455b-ad5e-8b9e2324a0ab/3f4e183b-7= 957-4bee-9153-9d967491f882', > '-O', 'raw', > u'/rhev/data-center/mnt/glusterSD/vs-host-colo-1-gluster.altn.int:_deskto= p-vdi1/f927ceb8-91d2-41bd-ba42-dc795395b6d0/images/9959c6e4-1fb7-455b-ad5e-= 8b9e2324a0ab/3f4e183b-7957-4bee-9153-9d967491f882'], > ecode=3D1, stdout=3D, stderr=3Dqemu-img: error while reading sector > 143654878: No data available\n, message=3DNone",) > > Can you verify those disks are indeed valid? Can you IO to them while > attaching them to a running VM? > > On Tue, May 30, 2017 at 9:10 PM, Bryan Sockel wrote: >> >> Hi, >> >> I am trying to rebuild my ovirt environment after having to juggle some >> hardware around. I am moving from hosted engine environment into a engi= ne >> install on a dedicated server. I have two data centers in my setup and >> each >> DC has a non-routable vlan dedicated to storage. >> >> As i rebuild my setup i am trying to clean up my storage configuration. = I >> am attempting to copy vm's and templates to a dedicated gluster setup. >> However each time i attempt to copy a template or move a vm, the >> operation >> fails. The failure always happens when it is finalizing the copy. >> >> The operation does not happen with all vm's, but seems to happen mostly >> with >> vm's created from with in Ovirt, and not imported from vmware. >> >> >> I have attached the logs from where i was trying to copy to templates to= a >> new Gluster Filesystem >> >> Thanks >> Bryan >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> I'm not sure if this is related to the hardware that was juggled, but it seems like the volume has a bad sector and qemu-img reports it. Do you have this volume in another storage domain maybe before the hardware change, so we can eliminate the issue of hardware change. You can also open a bug so it will be easier to track and investigate it: https://bugzilla.redhat.com/enter_bug.cgi?product=3Dvdsm please also attach the engine and vdsm logs. Regards, Maor --===============4042720903114574421==--