Kola: add support for multipath devices#1296
Kola: add support for multipath devices#1296openshift-merge-robot merged 1 commit intocoreos:masterfrom darkmuggle:pr/multipath
Conversation
|
Example for an RHCOS instance: |
|
Okay, lifting the WIP/Draft tags. A couple of changes:
Once I get MPIO working in Dracut I plan on submitting a test for this. To play with this in COSA, you can use NOTE: Right now RHCOS and FCOS can't use root on Multipath since its in use by the time multipath tools come up. This is PR simply gives a way to test support later. |
|
/test sanity |
| id := fmt.Sprintf("d%d", builder.diskId) | ||
|
|
||
| if disk.MultiPathDisk { | ||
| builder.Append("-device", "virtio-scsi-pci,id=scsi") |
There was a problem hiding this comment.
If we try to add multiple multipath disks - will this fail since we're appending multiple with the same id=scsi? I think we either need to only append this once, or create a separate bus per disk?
There was a problem hiding this comment.
Ah, that is true. Testing a fix now.
|
I think the Prow jobs are doing some sort of bad merge with master that's not getting the updated |
|
Maybe this is useful, I just did a google search for "libvirt multipath" and found: |
|
@cgwalters I'm exploring using |
|
From the CI run: |
Oh yeah totally fine by me as is. The main reason I care is that I do want |
Add support for "faking" multipath devices. In order to do this, Kola converts QCOW2 to a raw device and adds the device twice with attributes sufficient to trick multipath tools into seeing the devices as two paths to the same device. This feature is needed in order to adequately test root on multipath devices for RHCOS.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, darkmuggle The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I ran out of space in `/tmp` today and it turned out I had a whole lot of `/tmp/mantle-qemu` files, including some really big disk images. This is a combination of changes from coreos#1338 and the multipath PR coreos#1296 Basically if we get interrupted by Ctrl-C which is a lot more likely now when qemu isn't owning the serial console from the start, we will leak our tmpfiles. We probably need to install a `SIGINT` handler but that's a whole mess that's avoided if we just let the kernel clean up our resources for us, which is what was happening before the multipath PR (well, at least for files and not the swtpm tmpdir, but that's small). And actually coreos#1380 does install a `SIGINT` handler so someone please review that and we can maybe fix this more after that lands.
I ran out of space in `/tmp` today and it turned out I had a whole lot of `/tmp/mantle-qemu` files, including some really big disk images. This is a combination of changes from coreos#1338 and the multipath PR coreos#1296 Basically if we get interrupted by Ctrl-C which is a lot more likely now when qemu isn't owning the serial console from the start, we will leak our tmpfiles. We probably need to install a `SIGINT` handler but that's a whole mess that's avoided if we just let the kernel clean up our resources for us, which is what was happening before the multipath PR (well, at least for files and not the swtpm tmpdir, but that's small). And actually coreos#1380 does install a `SIGINT` handler so someone please review that and we can maybe fix this more after that lands.
I ran out of space in `/tmp` today and it turned out I had a whole lot of `/tmp/mantle-qemu` files, including some really big disk images. This is a combination of changes from coreos#1338 and the multipath PR coreos#1296 Basically if we get interrupted by Ctrl-C which is a lot more likely now when qemu isn't owning the serial console from the start, we will leak our tmpfiles. We probably need to install a `SIGINT` handler but that's a whole mess that's avoided if we just let the kernel clean up our resources for us, which is what was happening before the multipath PR (well, at least for files and not the swtpm tmpdir, but that's small). And actually coreos#1380 does install a `SIGINT` handler so someone please review that and we can maybe fix this more after that lands.
I ran out of space in `/tmp` today and it turned out I had a whole lot of `/tmp/mantle-qemu` files, including some really big disk images. This is a combination of changes from #1338 and the multipath PR #1296 Basically if we get interrupted by Ctrl-C which is a lot more likely now when qemu isn't owning the serial console from the start, we will leak our tmpfiles. We probably need to install a `SIGINT` handler but that's a whole mess that's avoided if we just let the kernel clean up our resources for us, which is what was happening before the multipath PR (well, at least for files and not the swtpm tmpdir, but that's small). And actually #1380 does install a `SIGINT` handler so someone please review that and we can maybe fix this more after that lands.
4 participants
While looking at providing support for Multipath, I needed the ability to setup Multipathed disks.