XOCE - ISO upload is renamed after upload to ISO SR

[acebmxer]

@psafont @olivierlambert

I thought i tried this before last time this came up, but i just tried now and it did upload as uuid.img.

Possibly reverse proxy is doing this? I use Nginx Proxy manager as reverse proxy. In XO via proxy upload iso to iso sr and moments later uuid.img in iso sr.

While XO is still showing the correct .iso name the actuall iso sr have uuid.img on the share looking at it vs smb from windows client for me.

[olivierlambert]

There's something fishy somewhere, the hard thing is to pinpoint exactly what. If you upload with one XO, we'll save (in XO) the name label of the VDI (so you see the name, it's not the filename per se because XO doesn't have access to the storage, only XAPI does).

[ph7]

Didn't work a year or 2 ago but it seems to be working now

[olivierlambert]

Yes but if you connect via another XO, I think you don't have the right namelabel (IIRC)

[acebmxer]

@olivierlambert I dont think it was mentioned that XO is reporting the incorrect name of the ios, rather the sr itself when looking a from diffrent way. As my XO reports the correct name but when viewing the ios sr from my windows pc vis smb i see the uuid.img.

Edit- Fired up a copy of XOA and it sees iso in sr correct just like my ox-ce.

[ph7]

@acebmxer
Oh it doesn't work if I check with smb from nemo in debian 12

58581e20-ee5c-4f52-b989-b198cff42d59.img

[acebmxer]

Just tried again accessing xo-ce without reverse proxy and same thing.

Edit unless this is by design. If the ISO sr is expected to only be interacted with vis XO interface.

[ph7]

Gave my spare xoce a try:

and it's 8 commits behind 53c1a
The one in the earlier post is d3402 3 behind

[ph7]

XOA 5.112.1 and 5.111.1 is fine

If I import a new ISO in 53c1a it show the correct name in both 53c1a and d3402

[mx]

We'd recently got a relevant experience regarding this weird renaming to uuids.

We had one orchestra managing one pool. ISOs were in an ISO SR, with an nfs4 serving it underneath. All fine till then.

We added one second pool to the orchestra. Just a single host by itself. One of the very next days we discovered that all names in the ISO SR had been replaced by uuids. Removing/readding the sr to the new pool helped temporarily. Usual names appeared again. But after a few more days, again uuids. Where uuids were appearing, we could not select anything from the dropdown list in the console's cdrom. The list per pool was unpopulated.

We tried separate the shares by offering the new pool an nfs4 share from the NAS, actually sharing the same source dir. It did mount but now there was a uuid uniq constraint that was violated, so we could not see no files at all in this new SR.

It would not be an illogical thought to have an 'iso sr' attached once to the orchestra and be offered by the orchestra to all managed pools, without uuids, without uniqs etc. There seems to be an unnecessary complication here I think.