Bug 2124538

Hi Vera, just because I'm not very clear what "soft iSCSI" means, is
the iSCSI a feature of the Broadcom BCM5720 card?  And what tool would
normally be used to enable & configure iSCSI in a RHEL guest?  (Presumably
not iscsiadm from the screenshot.)

(In reply to Richard W.M. Jones from comment #4)
> Hi Vera, just because I'm not very clear what "soft iSCSI" means, is
> the iSCSI a feature of the Broadcom BCM5720 card? 

Hi rjones,

"Soft iSCSI" means that iSCSI adapter is integrated NIC card, not HBA card (hard iSCSI). 

And our new server DELL poweredge 740 with the integrated Broadcom BCM5720 network card can support iSCSI boot.
So we didn't purchase HBA card from vendor.

> And what tool would
> normally be used to enable & configure iSCSI in a RHEL guest?  (Presumably
> not iscsiadm from the screenshot.)

After it is configured/enabled on the server, we can use it as normal one. 

That means during the RHEL installation, we can "Add disks" to discover/login iSCSI storage with initiator name/target IP
and choose this disk to install OS.

However, I don't know if the handling/connection methods for this type of iSCSI connection may differ from the hard one.

Apologies, I have to triage bugs, so assigning to Laszlo.

Hi Vera,

my understanding is the following, regarding the normal OS boot (or normal OS installation):

(1) You first enter the UEFI firmware setup on the machine.

(2) Using various dialogs there, you configure the iSCSI connection there (target name, IP address, username, password, etc).

(3) You boot Linux or Windows from the iSCSI target.

(4) The OS just booted can use the iSCSI disk.

Is this correct? Please confirm.

If the list of steps is correct, then I can describe a further piece of information. When your UEFI host firmware boots the OS (installer, or installed OS) from the iSCSI target, the host firmware also installs a new ACPI table that is called "iBFT". This ACPI table describes the iSCSI connection parameters for the OS, so that the OS can continue using the same iSCSI connection / target.

When you boot the P2V ISO on the physical machine, the host firmware does *not* create an iBFT ACPI table (because this is no "iscsi boot", so there is no "iscsi boot firmware table"). Therefore the OS will not know how to access the iSCSI target. Because iBFT is missing, at best the admin can supply the same set of information with iscsiadm. If that does not work, then I don't think this card can work well for P2V purposes.

Please provide the following information:

(a) How did you install RHEL-9.1 on the iSCSI storage, using this computer?

For example, did you boot a Live image from a USB stick, and Anaconda allowed you to specify the iSCSI connection parameters?

(b) Please install RHEL-9.1 to /dev/sda (a 1TB local disk, if I understand correctly), and then boot RHEL-9.1 from /dev/sda.

After having booted the system like this, can you access the iSCSI target at all, with iscsiadm commands?

Basically what I'm trying to figure out is whether *without P2V*, RHEL-9.1 is capable of accessing the iSCSI target, when booted off of a *local* disk. I'm trying to see if RHEL-9.1 has any means to connect to the iSCSI target *without* the iBFT ACPI table from the host firmware. Thanks.

(You can also give me the login details for the machine, so I could take a look myself. However, I will need a locally installed OS (/dev/sda) for investigating; or at least a USB live image inserted in a USB slot (and the ability to remotely reboot the computer). Thanks.)

Phew, this wasn't easy to crack open, but here goes.

There is a bug in Vera's configuration (I'll write a private comment about that first, due to the internal host names), and there is a bug (or limitation) in virt-p2v too. I'll write a public comment about that, second.

Assuming you launched XTerm from the Connection dialog of virt-p2v, set a proper initiator name, issued the proper iscsiadm commands, and confirmed with "lsblk" (e.g.) that the iSCSI disk has been attached as another /dev/sd* device node, you will *still* not see the iSCSI device in the Target dialog of virt-p2v.

That's due to a genuine bug in p2v. The list of hard disks is collected early, and the first dialog (where you can launch XTerm, and run iscsiadm commands) is shown afterwards:

main()                       [main.c]
  set_config_defaults()      [main.c]
    find_all_disks()         [main.c]
  gui_conversion()           [gui.c]
    show_connection_dialog() [gui.c]

Therefore, the list of hard disks ("all_disks") is stale by the time we get to the Target dialog.

This is not a trivial problem. The XTerm window remains open even if we click Next and advance from Connection to Target, so we can't delay the fetching of all_disks until the XTerm window is closed. We also can't simply (re-)enumerate all_disks upon showing the Target dialog, because that would break the "--test-disk" option.

Basically virt-p2v has no built-in support for iSCSI block devices at the moment; that much is clear from both the UI and the data flow (= the fact that whatever we do in XTerm does not influence "all_disks" after startup). Currently we expect all disks to be available at virt-p2v launch.

So this is a feature request. We should think more on when it would be best to (re-)enumerate the hard disks.

Could we have a "refresh" (or reload or whatever) button on the second page?

Also I think we should document the correct way to use XTerm to set up
an iSCSI device, since it's clearly not obvious.  I don't think I would
have discovered by myself that just logging into the initiator with the
correct login is insufficient to find the filesystems.  But we can put all of
that knowledge into the manual.

(Also, this is why I prefer NBD over iSCSI.  Every time I have used or
interacted with iSCSI I have become more firm in my belief that it is insane.)

FWIW the RHEL9 manual

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_storage_devices/configuring-an-iscsi-initiator_managing-storage-devices

still only says

> Find the iSCSI disk name and create a file system on this iSCSI disk:
>
> # grep "Attached SCSI" /var/log/messages
>
> # mkfs.ext4 /dev/disk_name

This is of course unusable programmatically, and not too easy to identify for a human either.

One step closer to that could be the following device nodes symlinks, created upon successful iSCSI target scan:

lrwxrwxrwx. 1 root root  9 Sep 11 17:56 /dev/disk/by-path/ip-10.73.5.1:3260-iscsi-iqn.1986-03.com.ibm:2145.clusterv3700v2.node1-lun-0 -> ../../sdb
lrwxrwxrwx. 1 root root 10 Sep 11 17:56 /dev/disk/by-path/ip-10.73.5.1:3260-iscsi-iqn.1986-03.com.ibm:2145.clusterv3700v2.node1-lun-0-part1 -> ../../sdb1
lrwxrwxrwx. 1 root root 10 Sep 11 17:56 /dev/disk/by-path/ip-10.73.5.1:3260-iscsi-iqn.1986-03.com.ibm:2145.clusterv3700v2.node1-lun-0-part2 -> ../../sdb2
lrwxrwxrwx. 1 root root 10 Sep 11 17:56 /dev/disk/by-path/ip-10.73.5.1:3260-iscsi-iqn.1986-03.com.ibm:2145.clusterv3700v2.node1-lun-0-part3 -> ../../sdb3
lrwxrwxrwx. 1 root root 10 Sep 11 17:56 /dev/disk/by-path/ip-10.73.5.1:3260-iscsi-iqn.1986-03.com.ibm:2145.clusterv3700v2.node1-lun-0-part4 -> ../../sdb4

The symlink filenames contain the IP address and TCP port of the target, the IQN of the target. Furthermore, presumably for *each* LUN detected on the target, a whole-blockdev symlink, and one symlink per partition, exist.

I'll need to analyze the data flow around "all_disks"; in case we refresh it, I think some dependent data needs to be invalidated (or re-inited) too.

Hi Vera,

can you please check these out:

* virt-p2v ISO:

- URL: http://lacos.interhost.hu/rhbz-2124538/livecd-p2v-202209160911-git-39710202acb6.iso
- sha256sum: c428558323cba2f9948a4037b8a57db578f6bfd77a1e32848b9aca97efecc617

* documentation:

- view live: http://lacos.interhost.hu/rhbz-2124538/docs/virt-p2v.1.html

- updates highlighted (openoffice document): http://lacos.interhost.hu/rhbz-2124538/docs/virt-p2v.1.html.odt

(I've noticed three typos in the documentation right now; I've corrected them locally, but I'm not regenerating / reuploading the above artifacts just for these.)

Thanks!

Tried with the comment18 build and the other versions:

virt-v2v-2.0.7-6.el9.x86_64
libnbd-1.12.6-1.el9.x86_64
libguestfs-1.48.4-2.el9.x86_64
nbdkit-1.30.8-1.el9.x86_64

OS: Windows2022-x86_64

Steps:
1. Boot host into virt-p2v client with 
2. Open Xterm and detect the iSCSI storage following the "ACCESSING ISCSI DEVICES" part in virt-p2v document
3. Input conversion server info and test connection
4. Check conversion info interface, No iSCSI storage shows on the interface now
5. Click "Refresh disks" button at the bottom of the dialogue. iSCSI storage show in the "Fixed hard disks"
6. Choose output to RHV and "Start conversion"
7. Check no errors msg shows during conversion
8. Go to RHV page, check the basic info of VM and import/start the VM 

Results:
With "Refresh disks" button, p2v can detect iSCSI LUN.


Thanks Laszlo.

Thanks for the test, Vera!

[p2v PATCH 00/15] recognize block device nodes (such as iSCSI /dev/sdX) added via XTerm
Message-Id: <20220919133511.18288-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-September/029891.html

Hi Lazsole,

I tried the comment18 build on RHEL9.1-x86_64 UEFI with the versions:

virt-v2v-2.0.7-6.el9.x86_64
libnbd-1.12.6-1.el9.x86_64
libguestfs-1.48.4-2.el9.x86_64
nbdkit-1.30.8-1.el9.x86_64


Steps:
Scenario 1: To RHEV (Pass)
1. conversion can be successful without errors
2. VM can be started into OS

Scenario 2: To Libvirt (Fail)
1. conversion can be successful without errors
2. start VM. Guest console turns into the black after inputting user/password. 
The issue is similar with bz2124193

Hi Vera,

yes, I think you have hit bz2124193 when outputting to libvirt. The conversion causes the guest kernel to use the bochsdrmfb driver, and the VGA initialization problem affects both the edk2 guest driver and the Linux guest driver. (Gerd has fixed both, see <https://issues.redhat.com/browse/RHELX-58> and bug 2124193, respectively.)

Now, bug 2124193 is still in POST status and not MODIFIED status, so there's no official development kernel that you could use. But, you could grab an RPM from <https://bugzilla.redhat.com/show_bug.cgi?id=2124193#c22>, install such a kernel in the original RHEL-9.1 guest, and perform the conversion afterwards. Thanks!

(In reply to Laszlo Ersek from comment #20)
> [p2v PATCH 00/15] recognize block device nodes (such as iSCSI /dev/sdX) added via XTerm
> Message-Id: <20220919133511.18288-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-September/029891.html

Merged upstream as commit range aa36551e515f..28d7ce8c9db9, with small updates to the "virt-p2v.pod" hunks in patch#14.

ISO built at upstream commit 28d7ce8c9db9, sha256sum ecbf20f6d1d45e92a67bef64801852f62aa519b91fb79c5ac68a9d5a239edbc5:

http://lacos.interhost.hu/livecd-p2v-202209231416.iso

Tested with comment24 iso and the versions:

virt-p2v-1.42.2
virt-v2v-2.0.7-6.el9.x86_64
libnbd-1.12.6-1.el9.x86_64
libguestfs-1.48.4-2.el9.x86_64
nbdkit-1.30.8-1.el9.x86_64

OS: RHEL9.1-x86_64 UEFI with comment22 rpms

Scenario: Convert to libvirt 
1. convert successfully 
2. VM after conversion can be started and the console can be open without black

Based on comment 25, the bug has been fixed and close the bug.