Bug 465593

Summary: Using `virsh` does not properly parse vifname parameter from domU configuration!
Product: Red Hat Enterprise Linux 5 Reporter: Ahmed Medhat <ultimatetux>
Component: libvirtAssignee: Daniel Berrangé <berrange>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.4CC: brian, llim, nzhang, veillard, xen-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 09:21:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Handle vifname= parameter none

Description Ahmed Medhat 2008-10-04 08:29:45 UTC
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

Comment 1 Daniel Berrangé 2009-03-31 15:59:28 UTC
Created attachment 337328 [details]
Handle vifname= parameter

Patch posted upstream

http://www.redhat.com/archives/libvir-list/2009-March/msg00509.html

Comment 2 Daniel Veillard 2009-06-05 15:58:40 UTC
That patch was actually included as part of the 0.6.3 rebase, so the fix
is in the current build,

Daniel

Comment 5 Daniel Berrangé 2009-06-18 17:56:56 UTC
*** Bug 506797 has been marked as a duplicate of this bug. ***

Comment 6 Nan Zhang 2009-06-21 11:19:04 UTC
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)

Comment 7 Daniel Berrangé 2009-06-22 08:37:21 UTC
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'

Comment 8 Nan Zhang 2009-06-22 09:29:45 UTC
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)
(...)

Comment 9 Daniel Berrangé 2009-06-22 09:52:42 UTC
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'.

Comment 10 Nan Zhang 2009-06-22 10:07:13 UTC
OK, this bug is verified, set flag to VERIFIED.

Comment 11 Nan Zhang 2009-06-22 10:11:50 UTC
# 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)
(...)

Comment 13 errata-xmlrpc 2009-09-02 09:21:09 UTC
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