Creating local ISO SR failed -> Feature request
-
I'm just installing it on a smaller number of independent servers. I can't use an ISO share for that.
But I'm not limiting that to me: Other people have to do the same stepts manualls.
It's one change, that - in the long run - can save thousands of manual steps in the community.
The feature is pretty nice for smaller environments, especially as new servers often don't have optical drives anymore and using iLO for that requires an advanced license, which is not super cheap (relative to the price of smaller servers).Edit: And yes, of course the 2nd thing would be an "upload" button, to use XOA to drop the ISOs there. (Or did I just miss that?)
-
@olivierlambert said in Creating local ISO SR failed -> Feature request:
Maybe having the folder created by default is another option. In the end, we could create that folder "by convention".
That would be quite easy to do for future releases indeed.
-
One option, considering a single server, you would have a local SR. Create there a "ISO folder" and mount it, like ESXi do, using the XO interface to manage the files.
-
@Carlos-Raasch said in Creating local ISO SR failed -> Feature request:
One option, considering a single server, you would have a local SR. Create there a "ISO folder" and mount it, like ESXi do, using the XO interface to manage the files.
It's what the whole topic is about.
-
@cg Not create a folder inside the host, create it inside a Local SR. Unless I completely misunderstood the problem.
-
@Carlos-Raasch it doesn't work like that. You should keep the "VM" SR untouched, because you have no control on what XAPI/storage need or will do inside it.
-
@olivierlambert I thought of this possibility because looking at the host file system the local SR appears as a simple mount point.
Surely it must be a lot more complicated than that.
dev/mapper/XSLocalEXT--53661c67--1a41--fc58--eccd--ca48db6033fa-53661c67--1a41--fc58--eccd--ca48db6033fa 785G 25G 721G 4% /run/sr-mount/53661c67-1a41-fc58-eccd-ca48db6033fa cd /run/sr-mount/53661c67-1a41-fc58-eccd-ca48db6033fa [root@server 53661c67-1a41-fc58-eccd-ca48db6033fa]# ll -h total 24G -rw-r--r-- 1 root root 267K Aug 8 2018 25b3b4be-e8f1-45a7-a37b-35c8b0ee3191.vhd -rw-r--r-- 1 root root 268K Aug 8 2018 359a4aca-738d-4ad7-bd2f-6fae9e5f1ce7.vhd -rw-r--r-- 1 root root 24G Oct 24 10:06 ab1280a3-841a-44b6-903c-eeec136817be.vhd -rw-r--r-- 1 root root 268K Aug 8 2018 da35ec61-a723-4138-ada4-340548777a47.vhd -rw-r--r-- 1 root root 8.1M Aug 11 2018 daa80630-f813-404e-9986-3afde0deb1ef.vhd -rw-r--r-- 1 root root 267K Aug 8 2018 ec98cb69-4be6-46f4-a13b-9de4be085c00.vhd -rw-r--r-- 1 root root 46K Jul 26 15:09 filelog.txt drwx------ 2 root root 16K Jul 30 2018 lost+found -
It's a mount point, but a SR rescan can fail if it doesn't have what's expected inside. That why we tend to avoid doing any manual step inside a SR.
-
Maybe ... is it possible to convert the ISO to VHD, to be properly stored in the SR? I did a quick search but only got Azure related stuff.
-
No it's not how it works in XAPI. You need a dedicated ISO SR using only *.iso file name/extension.
