On Tue, Nov 10, 2015 at 4:52 PM, Stefano Danzi <s.danzi@hawai.it> wrote:

Il 10/11/2015 16.40, Simone Tiraboschi ha scritto:

On Tue, Nov 10, 2015 at 12:36 PM, Stefano Danzi <s.danzi@hawai.it> wrote:

Solved!

inside the image directory there was this link:

lrwxrwxrwx. 1 root root         54 02 nov 12.14 ovirt-tools-setup.iso -> /usr/share/ovirt-guest-tools-iso/ovirt-tools-setup.iso

removing the link all was solved.

Hi Stefano,

that link has been created installing oVirt guest tools rpm.

Was that ISO storage domain exposed via NFS?

Was it exported by the engine VM/host?

 

thanks,

Simone

Hi!

The link was a my attempt to have ovirt-tools-setup.iso always updated on oVirt CD list.
I made the link just before upgrading, so maybe that cause errors also in 3.5

OK, so it's not a bug of the upgrade process.

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.

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.

Then probably VDSM could be a bit more robust here. 

 

ISO storage domain was exposed via NFS. It was exported from engine host (self hosted engine).

Maybe nice to have a more detailed error instead of "VDSM command failed: Cannot get file stats: (u'8cccc37f-d2d4-4684-a389-ac1adb050fa8',)".

I think that engine stats all files. If one stat fail, for a link in this case, all process fail and list remain empty.