On Jul 13, 2017, at 9:33 AM, Fred Rolland <frolland@redhat.com> wrote: =20 Yes. But the image should be uncompressed before you upload it. =20
On Jul 13, 2017 6:34 PM, "aduckers" <alex.duckers@gmail.com> wrote: Ok. I should be able to select QCOW2 for a SAN storage target? If true,=
--Apple-Mail-DC678AB0-DD73-4F3B-890A-054DFC1D92D3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok thanks. I'll try that today and report back if it made a difference or no= t.=20 then I=E2=80=99ll need to figure out why that doesn=E2=80=99t work.
=20
On Jul 13, 2017, at 8:32 AM, Fred Rolland <frolland@redhat.com> wrote: =20 When you select RAW, the Vdsm will allocated the whole size of the image= (virtual size), this is why you will not encounter this issue in Block Stor= age. =20
On Thu, Jul 13, 2017 at 6:17 PM, aduckers <alex.duckers@gmail.com> wrot= e: Thanks Fred. I haven=E2=80=99t run into the upload issue again, but if= we do I=E2=80=99ll try that. Regarding the template creation issue - could that just be user error o= n my part? I=E2=80=99ve found that if I select RAW format for the disk, whe= n target is SAN, it works fine. QCOW2 format works for a target of NFS. =20=
Is that the way it=E2=80=99s supposed to behave? =20 =20
On Jul 13, 2017, at 7:59 AM, Fred Rolland <frolland@redhat.com> wrote:=
On Wed, Jul 5, 2017 at 10:44 AM, Fred Rolland <frolland@redhat.com> w= rote: Can you please open bugs for the two issues for future tracking ? These needs further investigations. =20 > On Mon, Jul 3, 2017 at 2:17 AM, aduckers <alex.duckers@gmail.com> wr= ote: > Thanks for the assistance. Versions are: >=20 > vdsm.x86_64 4.19.15-1.el7.centos > ovirt-engine.noarch 4.1.2.2-1.el7.centos >=20 > Logs are attached. The GUI shows a creation date of 2017-06-23 11:3= 0:13 for the disk image that is stuck finalizing, so that might be a good pl= ace to start in the logs. >=20 >=20 >=20 >=20 >=20 > > On Jul 2, 2017, at 3:52 AM, Fred Rolland <frolland@redhat.com> wro= te: > > > > Hi, > > > > Thanks for the logs. > > > > What exact version are you using ? (VDSM,engine) > > > > Regarding the upload issue, can you please provide imageio-proxy a= nd imageio-daemon logs ? > > Issue in [1] looks with the same symptoms, but we need more info. > > > > Regarding the template issue, it looks like [2]. > > There were some issues when calculating the estimated size target v=
> > Please provide the exact versions, so I can check if it includes t= he fixes. > > > > Thanks, > > > > Fred > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=3D1357269 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=3D1448606 > > > > > > On Fri, Jun 30, 2017 at 5:11 AM, aduckers <alex.duckers@gmail.com>= wrote: > > > > > > Attached. I=E2=80=99ve also got an image upload to the ISO domain= stuck in =E2=80=9CFinalizing=E2=80=9D, and can=E2=80=99t cancel or clear it= . Not sure if related or not, but it might show in the logs and if that can= be cleared that=E2=80=99d be great too. > > > > Thanks > > > > > >> On Jun 29, 2017, at 9:20 AM, Fred Rolland <frolland@redhat.com> w= rote: > >> > >> Can you please attach engine and Vdsm logs ? > >> > >> On Thu, Jun 29, 2017 at 6:21 PM, aduckers <alex.duckers@gmail.com= wrote: > >> I=E2=80=99m running 4.1 with a hosted engine, using FC SAN storag= e. I=E2=80=99ve uploaded a qcow2 image, then created a VM and attached that= image. > >> When trying to create a template from that VM, we get failures wi=
=20 It seems you hit [1] If the image is compressed, the Vdsm will not compute the size as need= ed. In file storage, it will work OK as the file system is sparse. =20 As a workaround you can decompress before uploading: qemu-img convert -f qcow2 rhel-guest-image-7.3-35.x86_64.qcow2 -O qcow= 2 -o compat=3D1.1 uncompressed.qcow2 =20 [1] https://bugzilla.redhat.com/show_bug.cgi?id=3D1470435 =20 olume, that should be already fixed. th:
> >> > >> failed: low level image copy failed > >> VDSM command DeleteImageGroupVDS failed: Image does not exist in d= omain > >> failed to create template > >> > >> What should I be looking at to resolve this? Anyone recognize th= is issue? > >> > >> Thanks > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > > > > > > >=20 >=20 =20 =20 =20 =20 =20
On Jul 13, 2017 6:34 PM, "aduckers" <<a href=3D"mailto:alex.duckers@gmai= l.com">alex.duckers@gmail.com</a>> wrote:<br type=3D"attribution"><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
<<a href=3D"mailto:alex.duckers@gmail.com" target=3D"_blank">alex.ducker= s@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div styl= e=3D"word-wrap:break-word">Thanks Fred. I haven=E2=80=99t run into the= upload issue again, but if we do I=E2=80=99ll try that.<div>Regarding the t= emplate creation issue - could that just be user error on my part? I=E2= =80=99ve found that if I select RAW format for the disk, when target is SAN,= it works fine. QCOW2 format works for a target of NFS. </div><d= iv>Is that the way it=E2=80=99s supposed to behave?</div><div><div class=3D"= m_-1628404680015422047h5"><div><br></div><div><br><div><blockquote type=3D"c= ite"><div>On Jul 13, 2017, at 7:59 AM, Fred Rolland <<a href=3D"mailto:fr=
<br class=3D"m_-1628404680015422047m_-2535657724139672755Apple-interchange-= newline"><div><div dir=3D"ltr"><div><div><div>It seems you hit [1]<br></div>= If the image is compressed, the Vdsm will not compute the size as needed.<br= </div>In file storage, it will work OK as the file system is sparse.<br><br= </div>As a workaround you can decompress before uploading:<br><pre class=3D= "m_-1628404680015422047m_-2535657724139672755gmail-bz_comment_text m_-162840= 4680015422047m_-2535657724139672755gmail-bz_wrap_comment_text" id=3D"m_-1628= 404680015422047m_-2535657724139672755gmail-comment_text_3">qemu-img convert -= f qcow2 rhel-guest-image-7.3-35.x86_64<wbr>.qcow2 -O qcow2 -o compat=3D1.1 u= ncompressed.qcow2</pre><div><div><div><br>[1] <a href=3D"https://bugzilla.re= dhat.com/show_bug.cgi?id=3D1470435" target=3D"_blank">https://bugzilla.redha= t.com/sh<wbr>ow_bug.cgi?id=3D1470435</a><br></div></div></div></div><div cla= ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jul 5, 2017 at 10:= 44 AM, Fred Rolland <span dir=3D"ltr"><<a href=3D"mailto:frolland@redhat.= com" target=3D"_blank">frolland@redhat.com</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
--Apple-Mail-DC678AB0-DD73-4F3B-890A-054DFC1D92D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div></div><div>Ok thanks. I'll try that to= day and report back if it made a difference or not. </div><div><br>On J= ul 13, 2017, at 9:33 AM, Fred Rolland <<a href=3D"mailto:frolland@redhat.= com">frolland@redhat.com</a>> wrote:<br><br></div><blockquote type=3D"cit= e"><div><div dir=3D"auto">Yes. But the image should be uncompressed before y= ou upload it.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"= olid;padding-left:1ex"><div style=3D"word-wrap:break-word">Ok. I shoul= d be able to select QCOW2 for a SAN storage target? If true, then I=E2= =80=99ll need to figure out why that doesn=E2=80=99t work.<div><br><div><blo= ckquote type=3D"cite"><div>On Jul 13, 2017, at 8:32 AM, Fred Rolland <<a h= ref=3D"mailto:frolland@redhat.com" target=3D"_blank">frolland@redhat.com</a>= > wrote:</div><br class=3D"m_-1628404680015422047Apple-interchange-newlin= e"><div><div dir=3D"ltr">When you select RAW, the Vdsm will allocated the wh= ole size of the image (virtual size), this is why you will not encounter thi= s issue in Block Storage.<br></div><div class=3D"gmail_extra"><br><div class= =3D"gmail_quote">On Thu, Jul 13, 2017 at 6:17 PM, aduckers <span dir=3D"ltr"= olland@redhat.com" target=3D"_blank">frolland@redhat.com</a>> wrote:</div= lid;padding-left:1ex"><div dir=3D"ltr"><div>Can you please open bugs for the= two issues for future tracking ?<br></div>These needs further investigation= s.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><= div class=3D"m_-1628404680015422047m_-2535657724139672755h5">On Mon, Jul 3, 2= 017 at 2:17 AM, aduckers <span dir=3D"ltr"><<a href=3D"mailto:alex.ducker= s@gmail.com" target=3D"_blank">alex.duckers@gmail.com</a>></span> wrote:<= br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"m_-162840468= 0015422047m_-2535657724139672755h5">Thanks for the assistance. Version= s are:<br> <br> vdsm.x86_64 4.19.15-1.el7.cen= tos<br> ovirt-engine.noarch 4.1.2.2-1.el7.centos<br> <br> Logs are attached. The GUI shows a creation date of 2017-06-23 11:30:1= 3 for the disk image that is stuck finalizing, so that might be a good place= to start in the logs.<br> <br> <br> <br><br> <br></div></div><div><div class=3D"m_-1628404680015422047m_-2535657724139672= 755h5"> > On Jul 2, 2017, at 3:52 AM, Fred Rolland <<a href=3D"mailto:frolland= @redhat.com" target=3D"_blank">frolland@redhat.com</a>> wrote:<br> ><br> > Hi,<br> ><br> > Thanks for the logs.<br> ><br> > What exact version are you using ? (VDSM,engine)<br> ><br> > Regarding the upload issue, can you please provide imageio-proxy and im= ageio-daemon logs ?<br> > Issue in [1] looks with the same symptoms, but we need more info.<br> ><br> > Regarding the template issue, it looks like [2].<br> > There were some issues when calculating the estimated size target volum= e, that should be already fixed.<br> > Please provide the exact versions, so I can check if it includes the fi= xes.<br> ><br> > Thanks,<br> ><br> > Fred<br> ><br> > [1] <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1357269" r= el=3D"noreferrer" target=3D"_blank">https://bugzilla.redhat.com/sh<wbr>ow_bu= g.cgi?id=3D1357269</a><br> > [2] <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1448606" r= el=3D"noreferrer" target=3D"_blank">https://bugzilla.redhat.com/sh<wbr>ow_bu= g.cgi?id=3D1448606</a><br> ><br> ><br> > On Fri, Jun 30, 2017 at 5:11 AM, aduckers <<a href=3D"mailto:alex.du= ckers@gmail.com" target=3D"_blank">alex.duckers@gmail.com</a>> wrote:<br>= ><br> ><br> > Attached. I=E2=80=99ve also got an image upload to the ISO domain= stuck in =E2=80=9CFinalizing=E2=80=9D, and can=E2=80=99t cancel or clear it= . Not sure if related or not, but it might show in the logs and if tha= t can be cleared that=E2=80=99d be great too.<br> ><br> > Thanks<br> ><br> ><br> >> On Jun 29, 2017, at 9:20 AM, Fred Rolland <<a href=3D"mailto:fro= lland@redhat.com" target=3D"_blank">frolland@redhat.com</a>> wrote:<br> >><br> >> Can you please attach engine and Vdsm logs ?<br> >><br> >> On Thu, Jun 29, 2017 at 6:21 PM, aduckers <<a href=3D"mailto:ale= x.duckers@gmail.com" target=3D"_blank">alex.duckers@gmail.com</a>> wrote:= <br> >> I=E2=80=99m running 4.1 with a hosted engine, using FC SAN storage.= I=E2=80=99ve uploaded a qcow2 image, then created a VM and attached t= hat image.<br> >> When trying to create a template from that VM, we get failures with= :<br> >><br> >> failed: low level image copy failed<br> >> VDSM command DeleteImageGroupVDS failed: Image does not exist in do= main<br> >> failed to create template<br> >><br> >> What should I be looking at to resolve this? Anyone recognize= this issue?<br> >><br> >> Thanks<br> >><br> >><br> >> ______________________________<wbr>_________________<br> >> Users mailing list<br> >> <a href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users@ovirt.or= g</a><br> >> <a href=3D"http://lists.ovirt.org/mailman/listinfo/users" rel=3D"no= referrer" target=3D"_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/use= rs</a><br> >><br> ><br> ><br> ><br> <br> <br></div></div></blockquote></div><br></div> </blockquote></div><br></div> </div></blockquote></div><br></div></div></div></div></blockquote></div><br>= </div> </div></blockquote></div><br></div></div></blockquote></div></div> </div></blockquote></body></html>= --Apple-Mail-DC678AB0-DD73-4F3B-890A-054DFC1D92D3--