-
Notifications
You must be signed in to change notification settings - Fork 187
testiso: Do not add disk as primary disk for s390x pXE test #1336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
For s390x in pXE mode, the network device has the bootindex 1. Add a disk without specifying it as a primary disk with bootindex.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Prashanth684 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
s390x does not have the |
|
This will (textually) conflict with #1330 OK so this problem presumably came in with #1312 ...it feels to me like it'd be better if we tried to adddress this at the |
|
I don't understand though how s390x PXE works without this though...how does the firmware know to boot from the disk and not the network? |
right ..i was wondering whether to do it in qemu.go but this is very specific to the pXE scenario and netbooting which is why i thought it should go to testiso. |
Yes. I remember there was some quirks about the bootindex in s390x and zipl updating it. I will have to check with some of the s390x experts and find out. |
|
A different way to do this would be for us to use the QMP protocol to dynamically tell qemu to change the bootorder, triggered by a request from the guest. This closely matches how projects like Foreman do it for real bare metal PXE setups. We'd need to do some plumbing to add QMP support to |
I started to write that then discovered |
|
(I really wanted to use a |
I did try with the digital ocean library - one issue was - where do we call the connect to the socket and send commands? I see the qmp.sock created only after the VM gets started. The place above where you try to connect to the socket , I see that it has not been created yet. Also, just for my understanding - how do we want to use this? send qmp commands to control the device to boot from and leave the bootindex as is ? |
Ah..never mind..i missed the retries...After adding retries it works. Let me poke around the commands a little bit Not very familiar with QMP. |
Oh wow, I hadn't meant for you to take on using QMP in cosa but that's really awesome that you are! To be clear...I am not opposed to merging this PR as is either. But I do think we can do this in a cleaner way (QMP would be cleanest but failing that, it could work out OK to push some of the "here's a CDROM and disk, set things up to boot" into |
|
OK #1330 merged - feel free to rebase this one and we can do QMP as a followup if you prefer. |
|
@Prashanth684: PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
closed in favor of #1348 |
For s390x in pXE mode, the network device has the bootindex 1. Add a disk
without specifying it as a primary disk with bootindex.