<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 31, 2022 at 6:55 PM Andrea Bolognani <<a href="mailto:abologna@redhat.com">abologna@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 31, 2022 at 04:32:27PM +0200, Edward Haas wrote:<br>
> That discussion mentioned that a guest PCI address may change in two cases:<br>
> - The PCI topology changes.<br>
> - The machine type changes.<br>
><br>
> Usually, the machine type is not expected to change, especially if one<br>
> wants to allow migrations between nodes.<br>
> I would hope to argue this should not be problematic in practice, because<br>
> guest images would be made per a specific machine type.<br>
<br>
The machine type might not change from q35 to i440fx and vice versa,<br>
but since the domain XML is constructed every time a KubeVirt VM is<br>
started, the machine type might be q35-6.0 on one boot and q35-7.0<br>
the next one if a KubeVirt upgrade that comes with a new version of<br>
QEMU has happened in between.<br>
<br>
This is unlikely to make a difference in terms of PCI addresses seen<br>
in the guest OS, but it's still not accurate to say that the machine<br>
type will not change.<br></blockquote><div><br></div><div>Thank you for the clarification.<br></div><div>It makes me wonder now what are the actual implications of<br></div><div>the machine type change.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Live migration is a separate matter, as the machine type will<br>
definitely not change while the VM is running.<br>
<br>
> Regarding the PCI topology, I am not sure I understand what changes<br>
> need to occur to the domxml for a defined guest PCI address to change.<br>
> The only think that I can think of is a scenario where hotplug/unplug is<br>
> used,<br>
> but even then I would expect existing devices to preserve their PCI address<br>
> and the plug/unplug device to have a reserved address managed by the one<br>
> acting on it (the management system).<br>
><br>
> Could you please help clarify in which scenarios the PCI topology can cause<br>
> a mess to the naming of interfaces in the guest?<br>
<br>
A change in libvirt (again, due to a KubeVirt upgrade in between two<br>
boots of the same VM) might result in different PCI addresses being<br>
assigned to devices despite the same input XML.<br>
<br>
We generally try fairly hard to avoid this kind of situation, but we<br>
can only really guarantee stable PCI addresses for the lifetime of a<br>
VM that has been defined and can't promise that the same input XML<br>
will result in the same guest ABI when using different versions of<br>
libvirt.<br></blockquote><div><br></div><div>I would expect the PCI addresses that have been explicitly set in the<br></div><div>domxml [2] to be honored. We cannot assume that?<br></div><div>I mainly referred to that input option, not to the expectation that the generated<br></div><div>configuration (of the domxml) to be identical between different versions.<br></div><div><br>[2] <a href="https://libvirt.org/formatdomain.html#device-addresses">https://libvirt.org/formatdomain.html#device-addresses</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Andrea Bolognani / Red Hat / Virtualization<br>
<br>
</blockquote></div></div>