XOCE - ISO upload is renamed after upload to ISO SR
-
Hi
Is there a way to prevent XOCE to rename an ISO file upload via XOCE ?
for example : if i upload the iso file : linux-mint.iso, after upload to the nfs storage, it is renamed a04e750f-ba9a-4e58-b3f7-35e04ce3c979.img
thing is, it's pretty anoying, because the same iso source is used for other virtual environement, and having iso file with a UUID is not usable elswhere, because if i'm not on XOCE, i can't know what iso is
-
@Chico008
Use a file manager outside of XO, it will keep the name of the iso -
@ph7 that's what i'm doing for now, but i'm still wondering why the renaming, and maby a way to disable this renaming.
But maybe we can't
-
@Chico008 I think it's not a bug, it's a feature.
-
@Pilow Like BSOD from Microsoft Win95 show
-
I think we discussed it internally, IIRC it's not XO doing any renaming, but the toolstack. Adding @andriy.sultanov or @psafont in the loop
-
@olivierlambert said in XOCE - ISO upload is renamed after upload to ISO SR:
I think we discussed it internally, IIRC it's not XO doing any renaming, but the toolstack. Adding @andriy.sultanov or @psafont in the loop
I'm not sure about that, xapi is quite conscious it cannot rename these ISOs, in the few places I've seen it mentioned. I did not see any place in xapi that could have renamed these, nor reproduce it in my system.
-
How does XAPI name the .img file in the first place? IIRC, when we upload via XO, we set the name label but we have 0 control on the file naming on the ISO SR itself.
-
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.
-
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).
-
Didn't work a year or 2 ago but it seems to be working now
-
Yes but if you connect via another XO, I think you don't have the right namelabel (IIRC)
-
@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.
-
@acebmxer
Oh it doesn't work if I check with smb from nemo in debian 1258581e20-ee5c-4f52-b989-b198cff42d59.img -
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.
-
Gave my spare xoce a try:
and it's 8 commits behind
53c1a
The one in the earlier post isd34023 behind -
XOA 5.112.1 and 5.111.1 is fine
If I import a new ISO in
53c1ait show the correct name in both53c1aandd3402
-
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.
