Bug 593907 - libvirt rejects valid tap names containing periods, though the kernel accepts them
Summary: libvirt rejects valid tap names containing periods, though the kernel accepts...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Chris Lalancette
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-20 02:53 UTC by Charles Duffy
Modified: 2010-11-11 14:48 UTC (History)
6 users (show)

Fixed In Version: libvirt-0_8_1-11_el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-11 14:48:50 UTC
Target Upstream Version:

Attachments (Terms of Use)
one-line patch resolving this issue (432 bytes, patch)
2010-05-20 02:53 UTC, Charles Duffy
no flags Details | Diff
Updated patch removing isValidIfname entirely (1.55 KB, patch)
2010-05-20 21:32 UTC, Charles Duffy
no flags Details | Diff
Updated patch removing isValidIfname entirely (1.38 KB, patch)
2010-05-20 22:17 UTC, Charles Duffy
no flags Details | Diff

Description Charles Duffy 2010-05-20 02:53:43 UTC
Created attachment 415302 [details]
one-line patch resolving this issue

Description of problem:

  RHEL6's libvirt silently ignores interface name specifications containing periods, though the kernel allows such interface names to be created.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

  1. use "virsh define" to create a VM configured to attach to a precreated tap device named including a period, using an interface definition such as the following:

    <interface type="ethernet">
      <script path="/bin/true"/>
      <target dev="rtrtap-fvte.br67"/>
      <model type="virtio"/>

  2. Run "virsh dumpxml" to display the domain XML for the freshly defined interface.

Actual results:

  The domain XML will have the target element silently removed, as in the following example:

    <interface type="ethernet">
      <mac address='00:16:3e:0b:9c:93'/>
      <script path="/bin/true"/>
      <model type="virtio"/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>

Expected results:

  The designated target element should remain present.

Additional info:

  A patch I am using to successfully work around the issue is attached. This patch was also posted to the libvirt mailing list, as archived at http://permalink.gmane.org/gmane.comp.emulators.libvirt/25154

Comment 2 Charles Duffy 2010-05-20 21:32:17 UTC
Created attachment 415520 [details]
Updated patch removing isValidIfname entirely

After more discussion on the mailing list, consensus appears to be jelling that the appropriate course of action is to remove interface name validity checking from the parse process entirely. See for instance the post by Chris Lalancette at http://permalink.gmane.org/gmane.comp.emulators.libvirt/25191

Comment 3 Charles Duffy 2010-05-20 22:17:55 UTC
Created attachment 415533 [details]
Updated patch removing isValidIfname entirely

Updated version based on on-list feedback -- removes unnecessary header changes.

Comment 4 RHEL Program Management 2010-06-07 15:59:44 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 5 Daniel Berrangé 2010-06-08 13:51:45 UTC
Merged upstream

commit 8583b947b15775ebb3dba8790dfa4487448c3d9b
Author: Chris Lalancette <clalance@redhat.com>
Date:   Thu May 20 13:20:24 2010 -0400

    Remove isValidIfname.
    We shouldn't be checking validity in domain_conf, since
    it can be used by multiple different hosts and hypervisors.
    Remove the check completely.
    Signed-off-by: Chris Lalancette <clalance@redhat.com>

Comment 6 Dave Allan 2010-06-29 02:58:34 UTC
libvirt-0_8_1-11_el6 has been built in RHEL-6-candidate with the fix.


Comment 8 Osier Yang 2010-07-09 09:19:59 UTC
[root@dhcp-66-65-163 SOURCES]# rpm -q libvirt

1. [root@dhcp-66-65-163 SOURCES]# tunctl -t tap.test

2. insert following xml info domain toy'xml

    <interface type="ethernet">
      <script path="/bin/true"/>
      <target dev="tap.test"/>
      <model type="virtio"/>

3. destroy toy

4. start toy

5. virsh dumpxml toy

<domain type='kvm'>
    <type arch='x86_64' machine='rhel6.0.0'>hvm</type>
    <boot dev='hd'/>
  <clock offset='utc'/>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/migrate/bill2.img'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    <controller type='fdc' index='0'/>
    <interface type='network'>
      <mac address='52:54:00:f0:eb:5f'/>
      <source network='default'/>
      <target dev='vnet0'/>
      <filterref filter='disallow-dhcp'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    <interface type='ethernet'>
      <mac address='52:54:00:a3:ab:05'/>
      <script path='/bin/true'/>
      <target dev='tap.test'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    <serial type='pty'>
      <target port='0'/>
    <console type='pty'>
      <target port='0'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
    <sound model='ac97'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    <sound model='es1370'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>

the "target" node still stand there.


- Osier

Comment 9 releng-rhel@redhat.com 2010-11-11 14:48:50 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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