11:42 a.m.
I'm running libvirt with qemu-kvm underneath.
My network stack has the eth0 interface which is bridged to a br0 interface.
Usually, when a VM starts up, a new "vnet" interface is created as well by
libvirt. That vnet interface has a matching HWaddr to the VM that was spun up
with it, so I'm assuming they're associated somehow.
Sometimes, after using libvirt's "virt-install" to create a VM, I'm
unable to
"virsh start" it. Virsh will print this out to stderr that it couldn't start
that VM, since the connection was "Reset by peer".
I've yet to find a repro case for this issue. Eventually, I am able to "virsh
start" the instance, but only after several minutes.
Are there any known issues with libvirt/qemu-kvm failing to instantiate
network devices when it spins up VMs?
This is printed to the logs as well:
Mar 27 16:21:07 localhost kernel: device vnet42 entered promiscuous mode
Mar 27 16:21:07 localhost kernel: br0: port 44(vnet42) entering forwarding
state
Mar 27 16:21:07 localhost logger: KVM: 43 guests now active
Mar 27 16:21:08 localhost kernel: br0: port 44(vnet42) entering disabled
state
Mar 27 16:21:08 localhost kernel: device vnet42 left promiscuous mode
Mar 27 16:21:08 localhost kernel: br0: port 44(vnet42) entering disabled
state
Mar 27 16:21:08 localhost logger: KVM: 42 guests now active
1:29 p.m.
On 03/27/2015 12:42 PM, Dave Sayles wrote:
I'm running libvirt with qemu-kvm underneath.
My network stack has the eth0 interface which is bridged to a br0 interface.
Usually, when a VM starts up, a new "vnet" interface is created as well by
libvirt. That vnet interface has a matching HWaddr to the VM that was spun up
with it, so I'm assuming they're associated somehow.
The vnetX device is a tap device created by libvirt for use by qemu. One
end of the tap device is attached to the bridge, and the other end is a
file descriptor which the qemu process connects to the guest's emulated
network device.
The MAC address of the tap device actually isn't identical to the MAC
address used by the guest's emluated network device - the first byte is
0xFE, and all the other bytes match.
Sometimes, after using libvirt's "virt-install" to create a VM, I'm
unable to
"virsh start" it. Virsh will print this out to stderr that it couldn't
start
that VM, since the connection was "Reset by peer".
I've yet to find a repro case for this issue. Eventually, I am able to "virsh
start" the instance, but only after several minutes.
Are there any known issues with libvirt/qemu-kvm failing to instantiate
network devices when it spins up VMs?
What makes you think that is the problem?
This is printed to the logs as well:
Mar 27 16:21:07 localhost kernel: device vnet42 entered promiscuous mode
Mar 27 16:21:07 localhost kernel: br0: port 44(vnet42) entering forwarding
state
Mar 27 16:21:07 localhost logger: KVM: 43 guests now active
Mar 27 16:21:08 localhost kernel: br0: port 44(vnet42) entering disabled
state
Mar 27 16:21:08 localhost kernel: device vnet42 left promiscuous mode
Mar 27 16:21:08 localhost kernel: br0: port 44(vnet42) entering disabled
state
Mar 27 16:21:08 localhost logger: KVM: 42 guests now active
None of those are error messages. They are all indications of normal
operation.
It you don't see any error messages attributes to libvirtd in the logs,
try looking in /var/log/libvirt/$guestname.log
2:03 p.m.
libvirt/qemu-kvm failing to start interfaces wasn't the problem (though I
thought it was since those interfaces weren't around when the VM wouldn't
start). I eventually realized that the socket I was telling libvirt to
accept on was in the ephemeral port range, and a webserver I was running on
the same machine was accepting a bunch of connections at VM spin up time.
#mysterysolved
Thanks!
On 28 March 2015 at 14:29, Laine Stump <laine(a)laine.org> wrote:
On 03/27/2015 12:42 PM, Dave Sayles wrote:
> I'm running libvirt with qemu-kvm underneath.
>
> My network stack has the eth0 interface which is bridged to a br0
interface.
> Usually, when a VM starts up, a new "vnet" interface is created as well
by
> libvirt. That vnet interface has a matching HWaddr to the VM that was
spun up
> with it, so I'm assuming they're associated somehow.
The vnetX device is a tap device created by libvirt for use by qemu. One
end of the tap device is attached to the bridge, and the other end is a
file descriptor which the qemu process connects to the guest's emulated
network device.
The MAC address of the tap device actually isn't identical to the MAC
address used by the guest's emluated network device - the first byte is
0xFE, and all the other bytes match.
>
> Sometimes, after using libvirt's "virt-install" to create a VM,
I'm
unable to
> "virsh start" it. Virsh will print this out to stderr that it
couldn't
start
> that VM, since the connection was "Reset by peer".
>
> I've yet to find a repro case for this issue. Eventually, I am able to
"virsh
> start" the instance, but only after several minutes.
>
> Are there any known issues with libvirt/qemu-kvm failing to instantiate
> network devices when it spins up VMs?
What makes you think that is the problem?
>
> This is printed to the logs as well:
>
> Mar 27 16:21:07 localhost kernel: device vnet42 entered promiscuous mode
> Mar 27 16:21:07 localhost kernel: br0: port 44(vnet42) entering
forwarding
> state
> Mar 27 16:21:07 localhost logger: KVM: 43 guests now active
> Mar 27 16:21:08 localhost kernel: br0: port 44(vnet42) entering disabled
> state
> Mar 27 16:21:08 localhost kernel: device vnet42 left promiscuous mode
> Mar 27 16:21:08 localhost kernel: br0: port 44(vnet42) entering disabled
> state
> Mar 27 16:21:08 localhost logger: KVM: 42 guests now active
None of those are error messages. They are all indications of normal
operation.
It you don't see any error messages attributes to libvirtd in the logs,
try looking in /var/log/libvirt/$guestname.log
--
dgs3
3528
days inactive
3529
days old
2 comments
2 participants
participants (2)
-
Dave Sayles -
Laine Stump