Description of problem: Trying to statically set the virtual interface for a domU by using 'vifname=blabla' added to the vif list inside the domU specific configuration file, Starting the domU with `virsh start domU` would still attach the domU to an auto-incremented virtual interface like vif(domid).0 However starting the the domU with `xm create /etc/xen/domU` parsed the configuration well and did set the virtual interface to the value I set in vifname. A quick look at the code I was lead to code from the 'xen' package /usr/lib64/python2.4/site-packages/xen/xm/create.py and /usr/lib64/python2.4/site-packages/xen/xend/server/netif.py which after comparing the vifname inside them to another properly parsed variables like 'mac' or 'bridge' I found nothing buggy (from my quick look) appearing. It might be a Xen bug (or something I missed from the manuals) but as it only happens through virsh I thought posting it as libvirt related would be rational. Version-Release number of selected component (if applicable): $rpm -qa|grep 'kernel\|xen\|virt'|sort kernel-2.6.18-92.1.10.el5 kernel-devel-2.6.18-92.1.10.el5 kernel-headers-2.6.18-92.1.10.el5 kernel-xen-2.6.18-92.1.13.el5 kernel-xen-devel-2.6.18-92.1.13.el5 libvirt-0.3.3-7.el5 libvirt-python-0.3.3-7.el5 python-virtinst-0.300.2-8.el5 virt-viewer-0.0.2-2.el5 xen-3.0.3-64.el5_2.1 xen-libs-3.0.3-64.el5_2.1 How reproducible: In Description! Steps to Reproduce: In Description! Actual results: vifname isn't used. Expected results: set virtual network interface name for the specific domU to the value of vifname
Created attachment 337328 [details] Handle vifname= parameter Patch posted upstream http://www.redhat.com/archives/libvir-list/2009-March/msg00509.html
That patch was actually included as part of the 0.6.3 rebase, so the fix is in the current build, Daniel
*** Bug 506797 has been marked as a duplicate of this bug. ***
Not fixed, still attach the domU to an auto-incremented virtual interface. # rpm -qa|grep 'kernel\|xen\|virt'|sort kernel-2.6.18-154.el5 kernel-xen-2.6.18-154.el5 libvirt-0.6.3-11.el5 libvirt-cim-0.5.5-2.el5 libvirt-debuginfo-0.6.3-11.el5 libvirt-devel-0.6.3-11.el5 libvirt-python-0.6.3-11.el5 python-virtinst-0.400.3-3.el5 virt-manager-0.6.1-3.el5 virt-viewer-0.0.2-3.el5 xen-3.0.3-88.el5 xen-devel-3.0.3-88.el5 xen-libs-3.0.3-88.el5 # cat /etc/xen/xentest name = "xentest" uuid = "38f80d8a-585c-4c55-ba98-94c6ea573117" maxmem = 512 memory = 512 vcpus = 1 bootloader = "/usr/bin/pygrub" on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" vfb = [ "type=vnc,vncunused=1,keymap=en-us" ] disk = [ "tap:aio:/var/lib/xen/images/xentest.img,xvda,w" ] vif = [ "mac=00:16:36:7e:cf:f0,vifname=vif-foo,bridge=xenbr0,script=vif-bridge" ] # virsh start xentest Domain xentest started # virsh list Id Name State ---------------------------------- 0 Domain-0 running 3 xentest idle [root@dhcp-66-70-85 ~]# ifconfig (...) vif0.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:425650 errors:0 dropped:0 overruns:0 frame:0 TX packets:427009 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4232040099 (3.9 GiB) TX bytes:34045066 (32.4 MiB) vif3.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:66 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:15099 (14.7 KiB) xenbr0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:107785 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6096863 (5.8 MiB) TX bytes:0 (0.0 b)
Any vifname= parameters whose name starts with 'vif' is dropped, since that is the name prefix used for auto-assigned interface names. If this were allowed you could get naming clashes. Use a vifname= parameter value which doesn't start with 'vif'
But using xm can works well, I don't know if it's a design problem that the prefix name is not allowed to start with 'vif'. Starting the domU with `xm create /etc/xen/xentest` would attach the domU with the vifname 'vif-foo'. # xm create /etc/xen/xentest Using config file "/etc/xen/xentest". Started domain xentest # ifconfig (...) vif-foo Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:52 errors:0 dropped:0 overruns:0 frame:0 TX packets:641 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:8670 (8.4 KiB) TX bytes:135315 (132.1 KiB) (...)
This is one of the few delibrate policy decisions enforced in libvirt, because previously we would pass through the auto-generated name and this lead to worse errors with clashing vifnames between VMs. So we now drop all vifnames starting in 'vif'.
OK, this bug is verified, set flag to VERIFIED.
# cat /etc/xen/xentest (...) vif = [ "mac=00:16:36:7e:cf:f0,vifname=vnet-foo,bridge=xenbr0,script=vif-bridge" ] # virsh start xentest Domain xentest started # virsh list Id Name State ---------------------------------- 0 Domain-0 running 15 xentest idle [root@dhcp-66-70-85 ~]# ifconfig (...) vnet-foo Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) (...)
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1269.html