kmt: fixes for local macOS VMs #1183
Conversation
| // We have to use QEMU network devices because libvirt does not support the macOS | ||
| // network devices. | ||
| netID := pulumi.Sprintf("net%s", set.ID) | ||
| netID := pulumi.Sprintf("net%s", e.Ctx().Stack()) |
There was a problem hiding this comment.
Will this not make VMs on the same set to get the same ID?
There was a problem hiding this comment.
Only for the network, which I think is what we should do. Previously all VMs had the same network ID (set.ID ended up being always distro_local or something to that effect) and I think that might have been confusing the macOS virtual networking, maybe it didn't properly restart a network that was previously used and was disabled.
There was a problem hiding this comment.
I am not sure about that. These values are local to a running QEMU instance. -netdev id= specifies an identifier for the network backend, which can be used to connect devices to it. This id should not be visible or have any meaning outside the current QEMU instance.
Atleast this is my understanding. Maybe mac is doing some weird stuff parsing these value...?
In any case, rather than using the pulumi generated stack name, maybe you can add an extra tag (like the KMT stack name) in the vmconfig generated by the python code, so the IDs get dedupped. We derive names and ids everywhere from the vmset itself. It would be better to keep that consistent here as well.
There was a problem hiding this comment.
I think macOS does some weird stuff, yes. Because I can't really reproduce the problem, I'm still at the stage of trying things a bit blindly.
maybe you can add an extra tag (like the KMT stack name) i
Maybe using the same schema we use for the domain name? like domainName := libvirtResourceName(e.Ctx().Stack(), domain.domainID), then netID := libvirtResourceName(domainName, 'net') ?
There was a problem hiding this comment.
I think macOS does some weird stuff, yes
Maybe try setting it to a static value to see if it event effects anything.
Maybe using the same schema we use for the domain name?
That would work
There was a problem hiding this comment.
Maybe try setting it to a static value to see if it event effects anything.
The main problem is that I don't have a way to reproduce the bug :D so I can't really know if it's changing things or not
There was a problem hiding this comment.
Should we make this change if there is no indication that it does anything?
There was a problem hiding this comment.
Unfortunately the only way to test this is to see if the same issue happens again in dev laptops...
There was a problem hiding this comment.
The only "clue" I have is a flare from @brycekahle where he had a VM that was turned on and another that was turned off, so a "network conflict" was a possible theory.
|
/merge |
|
🚂 MergeQueue: pull request added to the queue The median merge time in Use |
dd-devflow
bot
added
mergequeue-status: queued
mergequeue-status: in_progress
and removed
mergequeue-status: queued
labels
What does this PR do?
Two fixes for macOS local VMs:
dumpCoreto on. This is required by newer QEMU versions but libvirt isn't setting the defaults correctly yet. Will likely be needed in Linux too, in any case it just affects behavior of core dumps performed if the VM crashes.Which scenarios this will impact?
Motivation
Additional Notes
Validated in agent pipeline: https://gitlab.ddbuild.io/DataDog/datadog-agent/-/pipelines/46393212