<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 4:52 PM, Stefano Danzi <span dir="ltr"><<a href="mailto:s.danzi@hawai.it" target="_blank">s.danzi@hawai.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>Il 10/11/2015 16.40, Simone Tiraboschi
ha scritto:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 10, 2015 at 12:36 PM,
Stefano Danzi <span dir="ltr"><<a href="mailto:s.danzi@hawai.it" target="_blank">s.danzi@hawai.it</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Solved!<br>
<br>
inside the image directory there was this link:<br>
<br>
lrwxrwxrwx. 1 root root 54 02 nov 12.14
ovirt-tools-setup.iso ->
/usr/share/ovirt-guest-tools-iso/ovirt-tools-setup.iso<br>
<br>
removing the link all was solved.</div>
</blockquote>
<div><br>
</div>
<div>Hi Stefano,</div>
<div>that link has been created installing oVirt guest tools
rpm.</div>
<div>Was that ISO storage domain exposed via NFS?</div>
<div>Was it exported by the engine VM/host?</div>
<div> </div>
<div>thanks,</div>
<div>Simone</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div><br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br></span>
Hi!<br>
<br>
The link was a my attempt to have ovirt-tools-setup.iso always
updated on oVirt CD list.<br>
I made the link just before upgrading, so maybe that cause errors
also in 3.5<br></div></blockquote><div><br></div><div>OK, so it's not a bug of the upgrade process.</div><div><br></div><div>The issue is that basically the symbolic link on NFS got resolved on the NFS client and not on the NFS server where the file was.</div><div>So you have to manually position that iso file exactly in the same path on each of your hosts or, much better, directly that file into your ISO storage domain instead of creating a broken symlink.</div><div>Then probably VDSM could be a bit more robust here. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
ISO storage domain was exposed via NFS. It was exported from engine
host (self hosted engine).<br>
<br>
Maybe nice to have a more detailed error instead of "VDSM command
failed: Cannot get file stats:
(u'8cccc37f-d2d4-4684-a389-ac1adb050fa8',)".<br>
<br>
I think that engine stats all files. If one stat fail, for a link in
this case, all process fail and list remain empty. <br>
<br>
<br>
</div>
</blockquote></div><br></div></div>