[01:44] <znf> JanC, nah, just got a 100Gbit broadcomm adapter with RDMA/SRV-IO enabled
=== shokohsc51087 is now known as shokohsc5108
=== cpaelzer_ is now known as cpaelzer
=== ravage_ is now known as ravage
[08:04] <nibbon_> cpaelzer: I cracked the Windows issue
[08:05] <nibbon_> the problem is due to this change: https://github.com/qemu/qemu/commit/af1b80ae56c9495999e8ccf7b70ef894378de642
[08:05] -ubottu:#ubuntu-server- Commit af1b80a in qemu/qemu "i386/acpi: fix inconsistent QEMU/OVMF device paths"
[08:07] <nibbon_> upstream proposed a workaround to make it work up to 5.1 https://github.com/qemu/qemu/commit/0a343a5add75f9f90c65e932863d57ddbcb28f5c
[08:07] -ubottu:#ubuntu-server- Commit 0a343a5 in qemu/qemu "i386/acpi: restore device paths for pre-5.1 vms"
[08:08] <nibbon_> tl;dr if you migrate a Windows instance from Focal (4.2) to Jammy (6.2), as long as the instance is restarted with machine type = "xxx-6.2", creates new network interfaces. If they rely on DHCP, no problem, but any static configuration is lost in the void
[08:11] <cpaelzer> nibbon_: so a migration without changing the type works, but the upgrade of the type switches the pci-id and due to that it is lost - is that the right summary?
[08:12] <nibbon_> cpaelzer: yeah, live migrating a workload persist the machine type; when the workload is stopped and started back, may take the new machine type which leads Windows to create new interfaces - screwing up those with static configuration
[08:13] <nibbon_> solution are: either persist the machine type when the instance is restarted or introduce this patch https://paste.debian.net/hidden/964a45eb/ 
[08:13] <nibbon_> I'm currently testing the latter in my env, and it's working fine
[08:14] <cpaelzer> nibbon_: even stop/start should keep the machine type as it is in the guest XML definition of libvirt. Or are you running qemu directly (sorry if you told me before I forgot that detail)
[08:15] <nibbon_> cpaelzer: our custom orchestrator uses the greatest machine type available and it's out of my reach changing that :/
[08:16] <cpaelzer> nibbon_: ah I see, well bumping the machine type will imply changing virtual hardware
[08:16] <cpaelzer> which is just what you see
[08:16] <cpaelzer> I mean, it is great to change to later types as a well controlled update (like when you qualify and switch to a new generation of silicon)
[08:16] <cpaelzer> But switching the type => give me the new things
[08:18] <nibbon_> cpaelzer: I'm aware of that; however, we have been doing that for ages and it's the first time we hit such an issue
[08:18] <cpaelzer> And that patch is very specific (just 6.2 is changed) and would likely break live migrations as they would have 0 on the source and 1 on the target node. So we would change that underneath their feet even if they kept the machine type.
[08:18] <cpaelzer> That sounds like something that can't be applied to Ubuntu that tries to work for everyone and every use-case
[08:19] <cpaelzer> I've seen issues like this a few times, maybe once every year. But that very much depends on whic huse case and (virtual) HW you are using.
[08:19] <cpaelzer> essentially each change to a type in the file you patched there is such a change - and they have a lot more via the compat entries.
[08:20] <cpaelzer> TL;DR I'd love to help you but a) your suggested change will likely break others and b) you are switching type so you can not really insist on virtual HW being the same as before
[08:22] <nibbon_> hmm, you have a point wrt live migration; nevertheless, I haven't spotted any issue while performing tests in my env (being linux or windows workloads involved). I'll perform more tests
[08:23] <nibbon_> can you articulate more about the compat entries?
[08:24] <nibbon_> (asking for a friend who's likely left alone in this endeavor :P)
[08:25] <cpaelzer> hehe
[08:28] <cpaelzer> what I mean is people often look at e.g. hw/i386/pc_q35.c (or piix) and think that is all that changed. But you also have the entries in hw/i386/pc.c representing "changes in virtual HW when changing machine type"
[08:31] <nibbon_> right
=== shokohsc51080 is now known as shokohsc5108
[21:17] <oramirez> Hi all,  I got a question to anyone. I have install pro and attached the token to the computer. I was able to add the machine to the landscape server, however when I look in the Ubuntu Pro Tab, I get the message that This computer is not attached to an Ubuntu Pro entitlement. I might be misunderstanding this. Does Landscape is unable to see that I
[21:17] <oramirez> do have a Pro subscription?
[21:20] <JanC> you probably better ask Landscape/Canonical support about that