I recently worked on a fix for LP: #144499 in Ubuntu’s cloud images where every instance (VM or LXD container) using a given cloud image would end up sharing the iSCSI initiator name. The iSCSI initiator name is intended to be unique, so that you can not only uniquely identify which system is using a given target on the iSCSI server, but also, if desired, restrict which initiators can use which targets.
This behavioral change was introduced by the fix for LP: #1057635; which was working around a different issue with initiator names by re-instituting an older behavior in Ubuntu. In effect, the open-iscsi package can either configure the iSCSI initiator name at install time or at boot time. This generation is controlled by a helper script seeing GenerateName=Yes in /etc/iscsi/initiatorname.iscsi; if it does see that string, then it generates a new unique initiator name using another helper. Ideally, this would be done at first-boot time (by the helper script), however if iSCSI is used for the root device, the initramfs will not contain a valid initiator name and will fail to find the root iSCSI disk. So, 1057635 re-instituted the prior Ubuntu behavior that the initiator name is created when the open-iscsi package is installed.
In order for iSCSI root to work, though, open-iscsi needs to be pre-installed in the installer environment (“seeded” in Ubuntu parlance), or if using images, needs to be installed by default so the image can use iSCSI. That results in processes like the CPC cloud image creation installing the open-iscsi package during the image creation. But that installation ends up creating an initiator name due to the prior bug. And thus every instance using that image has the same initiator name! To fix this, at least somewhat, I added a hook to the CPC image generation which, if it detects that /etc/iscsi/initiatorname.iscsi exists, overwrites it with GenerateName=yes. Thus, on the start of any instance using that cloud image, a new unique initiator name will be used.
Scott Moser (smoser), though, pointed out this “fix” is not quite complete. If you start with a cloud image and then make a snapshot, or a local image, from a running instance — all new instances using that local image will end up sharing an initiator name. This is actually relatively tricky to figure out — what we want is every unique instance to get a unique initiator name, not every image. I’m going to be trying to work out this issue on LP: #1677726. I probably will need to configure an iSCSI root and boot setup at home first 🙂
Nish's blog 
why not tie it to hostname?
LikeLike
A good question. Going off RFC 7143 for iSCSI: https://tools.ietf.org/html/rfc7143#section-4.2.7, iSCSI names are meant to be generated from data from one of three naming authorities:
a) iqn
b) eui
c) naa
with the logic that the uniqueness of the name (prefix) is guaranteed by the naming authority specified. The global uniqueness of a given iSCSI name is then a combination of that prefix and a suffix that guarantees uniqueness within the context of the that naming-authority-generated prefix.
Specifically, an iSCSI name is not tied to the hostname (as if you changed the hostname, that would imply the iSCSI name changes), and https://tools.ietf.org/html/rfc7143#section-4.2.7.1 specifies specifically that:
“iSCSI names are permanent. An iSCSI initiator node or target node has the same name for its lifetime.”
and
“iSCSI names do not imply a location or address. An iSCSI initiator or target can move or have multiple addresses. A change of address does not imply a change of name.”
Now, this isn’t really “enforced” by anything, but is good practice (it seems like).
Not sure if that makes sense to anyone else, though 🙂
LikeLike