xcp
xcp copied to clipboard
xcp-ng
Feature Request - network configuration prior to disk selection/probe for ISCSI boot from SAN
My situation, which I cannot be the only one. I use vlans, and my iscsi configuration for initiators requires a vlan id. Booting the installer with --use_ibft finds the drive, promps the question asking if I want to use the iscsi mount. After hitting yes, it starts to boot then fails and halts after trying to execute iscsid.
Disabling vlans on that port, (well changing the switch port to untagged) and setting the IP works just fine.
The ability to configure the network, including vlans, to mount an iscsi device before disk probing would resolve having to dump vlans for the storage network.
Hi,
I'm not sure about what you want to achieve: install the system on SAN, right? (diskless compute node)
Yes, diskless install. It installs fine when the network for iscsi storage does not use vlans, but fails to install and find the iscsi disk with vlans. The problem is the networking is not fully initialized on the installer before it probes for available disks to install to, so it finds no drives.
Correct. The request is that the network configuration be completed, including vlans prior to probing for local disks.
@Fohdeesha I don't remember, there's no option whatsoever to configure VLAN in the current ncurse installer, right?
@olivierlambert the installer definitely has a vlan configuration box alongside the main network configuration box, I think the issue @jvanbrecht is having is that this configuration comes up in the installer after disk selection. You're probably remembering the lack of LACP/bond config in the installer
@olivierlambert the installer definitely has a vlan configuration box alongside the main network configuration box, I think the issue @jvanbrecht is having is that this configuration comes up in the installer after disk selection. You're probably remembering the lack of LACP/bond config in the installer
Correct. The problem is simply (well this problem anyways), is that my storage network (iscsi) runs on vlan 200, there is no gateway, it is isolated to that vlan. I am unable to configure that aspect without going to the console first, and configuring the network manually and mounting the iscsi drive, then returning to the installer, and moving forward, then it sees the drive and I can continue normally with the install, select the disk, configure the network, and then do the network install.
There is a workaround of course, but it would be ideal if all network configuration could be done first. And in the drive selection, instead of giving only the option to reboot if a drive is not found, provide the option to mount an iscsi of fcoe mount.
The last issue, which I am trying to use the forums for (but the emails to reset my username does not appear to work, not getting them), is that even after installing to the drive, on the reboot after the install, it fails to mount the iscsi drive and the boot fails.
In a second scenario I tried, I installed to a sd card on the server (128GB) motherboard, and just tried to use the iscsi mount as vm/datapool storage. It does find this when I use --network_device=eth2 (the intel nic setup to mount the lun in hardware/bios), but again, after reboot, the drive disappears. I could use software iscsi, but that defeats the purpose of having hardware iscsi.
As a note with regards to this particular thread, I am only request the feature, not looking for support here (I will use the forums for that).
Simply, the feature I am requesting, configure network, and by extension, networked based storage (target, and associated fields), and to include Vlans first, then continue with the installation.
Have you tried the --network-config parameter of the installer? https://github.com/xcp-ng/host-installer/blob/master/doc/parameters.txt#L160
I have not, I was not aware of that parameter. I will test that. Either way, it is still a workaround and not intuitive.
Have you tried the
--network-configparameter of the installer? https://github.com/xcp-ng/host-installer/blob/master/doc/parameters.txt#L160
If if works, I won't consider this as a workaround, but a valid solution for an advanced use case (we can always document it). But first, let's see if it's the right answer :)