ISO Importing Results in .img Files

planedrop

@olivierlambert So far I haven't seen anyone else running across this, but maybe people aren't using the feature a ton? Normally I just move my ISOs to the SMB share manually but decided to use this feature for it instead and then noticed it created all the .img files.

It may be worth noting that whatever host that manages the SR I select, can indeed use the .img files to boot, but other hosts using the same ISO SR won't see them until I rename the files to .iso of some sort.

Gheppy

I will try to use this option as well, although I don't like that the files are stored as UUID.iso, I prefer to have them as names.
I prefer to have RockyLinux.9.2.iso than to have 89c425b6-42b7-11ee-be56-0242ac120002.iso.
If I can no longer recover the metadata, these UUIDs are of no use. You must identify them first.

planedrop

@Gheppy Yeah I agree, and I think what @olivierlambert is saying is that they should import as raw so in theory the name shouldn't change right?

Thanks for helping test this out!

Gheppy

I can confirm that the file *.iso importing is converted to *.img
Importing

File on share is

File on XOCE, commit 3baa37846e6dbe775a8891f51f7eaebbbb28bea6

planedrop

@Gheppy This is good to know, thank you!

So at least I know I'm not just super unlucky haha.

So far I haven't been able to get it to do a .iso properly, but I will keep trying various things.

planedrop

Looks like this is still happening on the latest XO version, any ideas/updates @olivierlambert ?

@Gheppy you still seeing this as well?

Fix is easy enough for me for now, just rename to .iso and everything is good, just a bit odd.

olivierlambert

Can you check if there's a diff between a local ISO SR and a shared NFS ISO SR?

Gheppy

The problem is the same with all form of ISO SR: local, cifs (smb), nfs. On all I have *.img

planedrop

I've only tested local and SMB so far but both did the same thing.

olivierlambert

@florent can you reproduce this?

florent

@olivierlambert yep

upload are renamed as uuid.img , I will check if it is on XO or XCP side

olivierlambert

And what is displayed in the SR VDI names? It might be the right name but if you are connecting the same ISO SR via another pool, it won't (since it's only local metadata I assume).

florent

@olivierlambert
the displayed size is ok on XO :

the file created is /run/sr-mount/acf947c6-5204-a149-ad41-a5981cc6a3db/0144fd11-d5e6-4915-a153-40548c9d0a60.img in our lab and the extension choice seems to be made on the host size

this iso is available on VM creation

olivierlambert

Yeah but I can assume the name is correct here, but not from another pool connected to this SR, since the VDI name is only used from the original filename that is unknown outside the pool.

florent

@olivierlambert Oh yes, that's right the file does not appear in the iso list

only the file really named *.iso of the SR are listed
I am checking where do we filter it

florent

@olivierlambert I don't think we do any filtering, the iso uploaded to another pool doesn't appear in the xapi calls result

olivierlambert

Even after a rescan?

florent

@olivierlambert this where it gets fun

after a rescan, the iso is listed in the SR > disks tabs, but since its vdi uuid is the same the link vdi to SR only show one SR.
The fix won't be trivial, I created a task in the backlog for this

Is it possible for non iso SR to be connected to multiple pool ?

olivierlambert

No, because only ISO SRs are in read only mode (ie when using a CD, you will never write on it). That's why it can be shared between pools, unlike a VM VDI SR, where you need a lock/write access. You can't coordinate locks outside a pool.

planedrop

Just wanted to chime in to say thanks for looking into this and "glad" you can reproduce it. If there's anything I can do to help/test let me know, would be happy to.