Predictable and consistent net interface naming in guests

[Edward Haas]

Thank you both for the quick response.

On Mon, Oct 31, 2022 at 4:49 PM Daniel P. Berrangé <berrange at redhat.com>
wrote:

> On Mon, Oct 31, 2022 at 04:32:27PM +0200, Edward Haas wrote:
> > Hi Igor and Laine,
> >
> > I would like to revive a 2 years old discussion [1] about consistent
> network
> > interfaces in the guest.
> >
> > That discussion mentioned that a guest PCI address may change in two
> cases:
> > - The PCI topology changes.
> > - The machine type changes.
> >
> > Usually, the machine type is not expected to change, especially if one
> > wants to allow migrations between nodes.
> > I would hope to argue this should not be problematic in practice, because
> > guest images would be made per a specific machine type.
> >
> > Regarding the PCI topology, I am not sure I understand what changes
> > need to occur to the domxml for a defined guest PCI address to change.
> > The only think that I can think of is a scenario where hotplug/unplug is
> > used,
> > but even then I would expect existing devices to preserve their PCI
> address
> > and the plug/unplug device to have a reserved address managed by the one
> > acting on it (the management system).
> >
> > Could you please help clarify in which scenarios the PCI topology can
> cause
> > a mess to the naming of interfaces in the guest?
> >
> > Are there any plans to add the acpi_index support?
>
> This was implemented a year & a half ago
>
>   https://libvirt.org/formatdomain.html#network-interfaces
>
> though due to QEMU limitations this only works for the old
> i440fx chipset, not Q35 yet.
>

I think most deployments today use Q35.
Are there plans to resolve it there?

BTW, should this limitation be added to the documentation?


>
> With regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20221031/f4ceb118/attachment.htm>