On Sun, 2018-05-06 at 22:55 +0200, Jakob Bohm wrote:
> On 06/05/2018 21:12, Ben Hutchings wrote:
> > On Fri, 2018-05-04 at 03:08 +0200, Jakob Bohm wrote:
> > > Package: libvirt-daemon
> > > Version: 3.0.0-4+deb9u2~bpo8+1
> > > Severity: important
> > >
> > > NOTICE: This is for regular bridged networks, not the SR-IOV kind that
> > > had a similar looking issue on Redhat systems sometime before 3.9.0.?
> > >
> > > After upgrading from 3.0.0-4~bpo8+1 to 3.0.0-4+deb9u2~bpo8+1 starting
> > > most VMs fail to start with the following error (as reported in
> > > libvirtd.log):
> > >
> > > error : virNetDevSetMAC:248 : Cannot get interface MAC on 'vnet%d': No
> > > such device
> >
> > [...]
> >
> > I think this is kernel bug #897427.
> >
> > Ben.
> >
>
> Looks weirdly similar, except that multiple tap devices work fine
> when using qemu outside libvirt.
The regression is only for the case where the application specifies an
empty name or a name including %d. If you specify a full interface
name on the QEMU command line, this avoids the regression.
Ben.
> Also, libvirt outputs the same error message from the command
> "virsh domxml-to-native qemu-argv example.xml", which isn't
> supposed to affect the system in any way (such as telling the
> kernel to configure tap devices).
>
> But I will try with a kernel downgrade, although I would still
> like a way to try the old libvirt backport too.
>
> Enjoy
>
> Jakob
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John Lennon
Attachment:
signature.asc
Description: This is a digitally signed message part