Re: [libvirt] Instances
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 la...@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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Instances
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Instances
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
