Hide Forgot
This is related to bug #217495, which was closed as duplicate of 207166, but I am not authorized to see 207166 nor reopen 217495. Please read bug #217495 before proceeding. On /var/log/xen/xen-hotplug.log I found several "bridge xenbr0 does not exists". In fact, I have a xenbr1 bridge. By defining a xenbr0 bridge via brctl the installation of the guest starts. This could be related to the unconfiguration of eth0 at operating system installation time, when only eth1 was configured. In every case, it seems to me that virt-install should setup the guest so they can work with xenbr(n+1) if xenbx(n) is not defined.
Bug 217495 is not related - that is merely describing a misleading error message thrown by libvirt which is now fixed. The root problem here is that the virt-install / virt-manager programs both assume a 'default' network configuration. In XenD terms 'default' means xenbr0, even if the network-bridge script deciding to create xenbr1 instead. The latest version of python-virtinst 0.97.0-1 has a workaround for this problem, which checks the default network route to decide whether to use xenbr0 or any other xenbrX device: $ rpm -q --changelog python-virtinst * Mon Nov 20 2006 Jeremy Katz <katzj@redhat.com> - 0.97.0-1 - handle multiple nics with virt-install (#215726) Can you confirm what version of python-virtinst is installed ?
I am using python-virtinst-0.96.0-2.el5
Opps, I didn't mean 0.97.0 - the neccessary fix is actually in version 0.96.0-3.el5 * Thu Nov 16 2006 Daniel P. Berrange <berrange@redhat.com> - 0.96.0-3 - Autodetect primary bridge device when creating guests (bz 207210, 201626) Since you only have version 0.96.0-2.el5 I'm going to close this bug since it looks like the same core issue. The updated RPMs will be available in GA (and possibly even before). *** This bug has been marked as a duplicate of 201626 ***