Bug 465593 - Using `virsh` does not properly parse vifname parameter from domU configuration!
Using `virsh` does not properly parse vifname parameter from domU configuration!
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
5.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Berrange
Virtualization Bugs
:
: 506797 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-04 04:29 EDT by Ahmed Medhat
Modified: 2009-12-14 16:09 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:21:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Handle vifname= parameter (4.32 KB, patch)
2009-03-31 11:59 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Ahmed Medhat 2008-10-04 04:29:45 EDT
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 Berrange 2009-03-31 11:59:28 EDT
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 11:58:40 EDT
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 Berrange 2009-06-18 13:56:56 EDT
*** Bug 506797 has been marked as a duplicate of this bug. ***
Comment 6 Nan Zhang 2009-06-21 07:19:04 EDT
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 Berrange 2009-06-22 04:37:21 EDT
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 05:29:45 EDT
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 Berrange 2009-06-22 05:52:42 EDT
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 06:07:13 EDT
OK, this bug is verified, set flag to VERIFIED.
Comment 11 Nan Zhang 2009-06-22 06:11:50 EDT
# 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 05:21:09 EDT
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

Note You need to log in before you can comment on or make changes to this bug.