<div dir="ltr"><div dir="ltr"><div>Thank you both for the quick response.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 31, 2022 at 4:49 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@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>
> Hi Igor and Laine,<br>
> <br>
> I would like to revive a 2 years old discussion [1] about consistent network<br>
> interfaces in the guest.<br>
> <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>
> 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>
> Are there any plans to add the acpi_index support?<br>
<br>
This was implemented a year & a half ago<br>
<br>
  <a href="https://libvirt.org/formatdomain.html#network-interfaces" rel="noreferrer" target="_blank">https://libvirt.org/formatdomain.html#network-interfaces</a><br>
<br>
though due to QEMU limitations this only works for the old<br>
i440fx chipset, not Q35 yet.<br></blockquote><br><div>I think most deployments today use Q35.<br></div><div>Are there plans to resolve it there?<br><br>BTW, should this limitation be added to the documentation?<br><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>
<br>
With regards,<br>
Daniel<br>
-- <br>
|: <a href="https://berrange.com" rel="noreferrer" target="_blank">https://berrange.com</a>      -o-    <a href="https://www.flickr.com/photos/dberrange" rel="noreferrer" target="_blank">https://www.flickr.com/photos/dberrange</a> :|<br>
|: <a href="https://libvirt.org" rel="noreferrer" target="_blank">https://libvirt.org</a>         -o-            <a href="https://fstop138.berrange.com" rel="noreferrer" target="_blank">https://fstop138.berrange.com</a> :|<br>
|: <a href="https://entangle-photo.org" rel="noreferrer" target="_blank">https://entangle-photo.org</a>    -o-    <a href="https://www.instagram.com/dberrange" rel="noreferrer" target="_blank">https://www.instagram.com/dberrange</a> :|<br>
<br>
</blockquote></div></div>