[1] seems reasonable, I'll give it a try with and without the PPA of Andres. It needs a slight modification, to not conflict with the default portal.
Install libvirt with all else it usually brings (for the bridge and dhcp on the bridge): $ sudo install libvirt-daemon-system So use these commands: $ curl -O http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img $ qemu-img convert -O raw cirros-0.3.4-x86_64-disk.img cirros.raw $ sudo targetcli /backstores/fileio/ create cirros $PWD/cirros.raw 100M false $ sudo targetcli /iscsi create iqn.2016-01.com.example:cirros $ sudo targetcli /iscsi/iqn.2016-01.com.example:cirros/tpg1/luns create /backstores/fileio/cirros $ sudo targetcli /iscsi/iqn.2016-01.com.example:cirros/tpg1/portals delete 0.0.0.0 ip_port=3260 $ sudo targetcli /iscsi/iqn.2016-01.com.example:cirros/tpg1/portals create 192.168.122.1 If you do that you'll end up with a targetcli config like this: $ sudo targetcli targetcli shell version 2.1.fb43 Copyright 2011-2013 by Datera, Inc and others. For help on commands, type 'help'. /> ls o- / ......................................................................................................................... [...] o- backstores .............................................................................................................. [...] | o- block .................................................................................................. [Storage Objects: 0] | o- fileio ................................................................................................. [Storage Objects: 1] | | o- cirros ........................................................... [/home/ubuntu/cirros.raw (39.2MiB) write-thru activated] | o- pscsi .................................................................................................. [Storage Objects: 0] | o- ramdisk ................................................................................................ [Storage Objects: 0] o- iscsi ............................................................................................................ [Targets: 1] | o- iqn.2016-01.com.example:cirros .................................................................................... [TPGs: 1] | o- tpg1 .................................................................................................. [gen-acls, no-auth] | o- acls .......................................................................................................... [ACLs: 0] | o- luns .......................................................................................................... [LUNs: 1] | | o- lun0 ........................................................................ [fileio/cirros (/home/ubuntu/cirros.raw)] | o- portals .................................................................................................... [Portals: 1] | o- 192.168.122.1:3260 ............................................................................................... [OK] o- loopback ......................................................................................................... [Targets: 0] o- srpt ............................................................................................................. [Targets: 0] o- vhost ............................................................................................................ [Targets: 0] Do that and then on qemu start attach to the console early. To get that easier, instead of VNC use a local curses console with: $ sudo qemu-system-x86_64 -smp cpus=2 -curses -boot order=n -netdev bridge,br=virbr0,id=virtio0 -device virtio-net-pci,netdev=virtio Hit CTRL+B early on boot for ipxe commands With out virtbr0 default setup having the host on 192.168.122.1 that would be iPXE> ifopen net0 iPXE> dhcp iPXE> sanboot iscsi:192.168.122.1::::iqn.2016-01.com.example:cirros Retested with 1.0.0+git-20180124.fbe8c52d-0ubuntu2.2~18.04.1 from the PPA. Boot just as much - so while no perfect test (what if that would be in a VLAN tagged network?) it is better than nothing. That said - together with all that was discussed before - I think Andres could go on uploading it to Disco. For the SRUs we will need some extra for [2], but one thing at a time. Or is the assumption that I drive it from here and you only do verifications on the case? [1]: https://medium.com/oracledevs/kvm-iscsi-part-i-iscsi-boot-with-ipxe-f533f2666075 [2]: https://packages.ubuntu.com/bionic/ipxe-qemu-256k-compat-efi-roms -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1805920 Title: iPXE ignores vlan 0 traffic Status in MAAS: Invalid Status in ipxe package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: I have three MAAS rack/region nodes which are blades in a Cisco UCS chassis. This is an FCE deployment where MAAS has two DHCP servers, infra1 is the primary and infra3 is the secondary. The pod VMs on infra1 and infra3 PXE boot fine but the pod VMs on infra2 fail to PXE boot. If I reconfigure the subnet to provide DHCP on infra2 (either as primary or secondary) then the pod VMs on infra2 will PXE boot but the pod VMs on the demoted infra node (that no longer serves DHCP) now fail to PXE boot. While commissioning a pod VM on infra2 I captured network traffic with tcpdump on the vnet interface. Here is the dump when the PXE boot fails (no dhcp server on infra2): https://pastebin.canonical.com/p/THW2gTSv4S/ Here is the dump when PXE boot succeeds (when infra2 is serving dhcp): https://pastebin.canonical.com/p/HH3XvZtTGG/ The only difference I can see is that in the unsuccessful scenario, the reply is an 802.1q packet -- it's got a vlan tag for vlan 0. Normally vlan 0 traffic is passed as if it is not tagged and indeed, I can ping between the blades with no problem. Outgoing packets are untagged but incoming packets are tagged vlan 0 -- but the ping works. It seems vlan 0 is used as a part of 802.1p to set priority of packets. This is separate from vlan, it just happens to use that ethertype to do the priority tagging. Someone confirmed to me that, in the iPXE source, it drops all packets if they are vlan tagged. The customer is unable to figure out why the packets between blades is getting vlan tagged so we either need to figure out how to allow iPXE to accept vlan 0 or the customer will need to use different equipment for the MAAS nodes. I found a conversation on the ipxe-devel mailing list that suggested a commit was submitted and signed off but that was from 2016 so I'm not sure what became of it. Notable messages in the thread: http://lists.ipxe.org/pipermail/ipxe-devel/2016-April/004916.html http://lists.ipxe.org/pipermail/ipxe-devel/2016-July/005099.html Would it be possible to install a local patch as part of the FCE deployment? I suspect the patch(es) mentioned in the above thread would require some modification to apply properly. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1805920/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
