ISO Importing Results in .img Files
-
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.
-
Can you check if there's a diff between a local ISO SR and a shared NFS ISO SR?
-
The problem is the same with all form of ISO SR: local, cifs (smb), nfs. On all I have *.img
-
I've only tested local and SMB so far but both did the same thing.
-
@florent can you reproduce this?
-
@olivierlambert yep
upload are renamed as uuid.img , I will check if it is on XO or XCP side
-
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).
-
@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.imgin our lab and the extension choice seems to be made on the host sizethis iso is available on VM creation
-
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.
-
@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 -
@olivierlambert I don't think we do any filtering, the iso uploaded to another pool doesn't appear in the xapi calls result
-
Even after a rescan?
-
@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 thisIs it possible for non iso SR to be connected to multiple pool ?
-
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.
-
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.
-
D Danp referenced this topic on
-
Im experiencing this behavior up loading iso, one post mentions we can safely rename the iso after import.
Is this the recommended workaround?
Also i notice the same thing is happening with my vms. Can. I simply rename the vm as well?
-
@Octive For now that is the right solution in terms of ISOs, it's what I've been doing in a production environment without any issues at all.
What do you mean same thing with VMs though? Importing from where? They aren't ISOs so that is a different story entirely, don't just go renaming VMs that's for sure.
For clarity, you can rename the ISO files in your ISO SR's just fine and then do a rescan of the SR and they will be found.
-
@planedrop Good morning,
Thanks for the input I have renamed my ISO's directly, and now I can easily track each iso on my NAS.
Here is what I mean when checking my VMs.
Example:
For my test lab, the display name for XO-CE is XO-CE_urene when creating the VM. However, when viewing the VM on my NAS, the Guid appears:
I was expecting to see (XO-CE_urene) as the .vhd and thought this might be the same thing going on with the ISO files.
I'm still learning the system and don't know what the expected behavior is.
-
I think the issue is that when we upload a raw file to the SR, SMAPIv1 won't take the name but create an UUID directly
-
@olivierlambert said in ISO Importing Results in .img Files:
take the name but create an UUID directl
I can try a different connection method I'm currently using.
NFS v4 and DNS names to connect to backend storage.
I can test with a lower NFS version or switch over to ISCSI targets to see if I can replicate it.
