Creating local ISO SR failed -> Feature request
-
That's precisely something we want to avoid: having to connect outside XAPI. Also we have no way to know if:
- root password is still enabled on SSH
- we have SSH access to the host (only 443 can be used for XAPI)
Last option is to use a XAPI plugin we build ourselves to do that. But it must be secure enough to avoid folder creation anywhere.
-
How hard is it to SSH in and manually create the folder? It's 10 seconds worth of work tops. And you probably will never have to ever touch it again.
-
@Biggen said in Creating local ISO SR failed -> Feature request:
How hard is it to SSH in and manually create the folder? It's 10 seconds worth of work tops. And you probably will never have to ever touch it again.
It's about optimizing things and taking away extra/manual steps that disturbs workflow with rather low effort to implement
.
I'm not feeding your negative vibes on that, so discussion is over for me. Oliver said they don't want to do things beside what XAPI can do and thereby it's done. -
We are just talking, indeed
I'm always open to suggestions, and as I said, there's still one possibility (XAPI plugin) but it might be done carefully to avoid security breaches.Maybe having the folder created by default is another option. In the end, we could create that folder "by convention".
-
@cg said in Creating local ISO SR failed -> Feature request:
@Biggen said in Creating local ISO SR failed -> Feature request:
How hard is it to SSH in and manually create the folder? It's 10 seconds worth of work tops. And you probably will never have to ever touch it again.
It's about optimizing things and taking away extra/manual steps that disturbs workflow with rather low effort to implement
There may be something I didn't get, but if you don't want manual steps that disturb the workflow, I suppose you've got many hosts to install. If you've got several hosts to install, I hope you have a file server with an NFS or SMB share where you could put ISOs on?
-
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.
