Bug 756434

Summary: forward mode: PASSTHROUGH error creating macvtap type of interface: Invalid argument
Product: [Community] Virtualization Tools Reporter: Shradha Shah <sshah>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: crobinso, dallan, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-02 15:25:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
config file for the domain
none
config file for network none

Description Shradha Shah 2011-11-23 15:07:18 UTC
Created attachment 535516 [details]
config file for the domain

Description of problem:
When using forward mode=passthrough, I cannot start a guest and the error given out is 
error: error creating macvtap type of interface: Invalid argument

Version-Release number of selected component (if applicable):
SHA1-ID is ea7182c29f185e7c1527b10fbe16dc4ba1f45a88

How reproducible:
Always


Steps to Reproduce:
1. virsh net-define network_direct.xml
2. virsh define guest_direct.xml
3. virsh start dibenchvm
  
Actual results:
error: Failed to start domain dibenchvm
error: error creating macvtap type of interface: Invalid argument

Expected results:
The Guest should start and create a macvtap interface on eth2.

Additional info:
The network_direct.xml and guest_direct.xml files are attached.

Comment 1 Shradha Shah 2011-11-23 15:08:08 UTC
Created attachment 535517 [details]
config file for network

Comment 2 Laine Stump 2011-11-23 18:16:05 UTC
You don't give the version/origin of the libvirt you're using, but I'm assuming you've built the latest sources from git.

You also don't give the platform or release of that platform, but based on the machine type in the domain XML I assume it is RHEL 6.1.

If those are correct, then the problem is that macvtap passthrough mode is not supported until at least kernel-2.6.32-175.el6 / RHEL6.2. Other macvtap modes should be supported, though - have you tried bridge or private?

If you really need macvtap passthrough mode, you should try to get hold of a RHEL6.2 beta.

Also, for a problem like this encountered while using a build from upstream, you can probably get quicker results by first sending mail to libvir-list. The developers pay much closer attention to this than to the upstream bug tracker (since most items in the upstream bug tracker are first brought up on the mailing list).

Please let me know if my assumptions about the origin of your libvirt and the release of OS you're using are correct. I would also like to hear if using a different macvtap mode works correctly.

Comment 4 Shradha Shah 2011-11-24 10:59:49 UTC
(In reply to comment #2)

> Please let me know if my assumptions about the origin of your libvirt and the
> release of OS you're using are correct. I would also like to hear if using a
> different macvtap mode works correctly.

Thankyou for your quick response
Your assumptions about the origin of my libvirt and about my OS are correct.
I will update my kernel version.

I tried using the mode vepa and I see the following error:
[root@c6100r sshah]# virsh start dibenchvm
error: Failed to start domain dibenchvm
error: Cannot set interface flags on 'macvtap0': Device or resource busy


I use /var/log/libvirt/libvirtd.log to get all the debug output (log_level is set to 1 in /etc/libvirt/libvirtd.conf)

libvirtd.log shows the following output:

2011-11-24 10:46:33.932: 2139: debug : networkAllocateActualDevice:2963 : Using physical device eth2, usageCount 1
2011-11-24 10:46:33.932: 2139: debug : openMacvtapTap:288 : openMacvtapTap: VM OPERATION: create
2011-11-24 10:46:33.934: 2139: debug : vpAssociatePortProfileId:1104 : Associating port profile '(nil)' on link device 'macvtap0'
2011-11-24 10:46:33.934: 2139: debug : vpAssociatePortProfileId:1106 : vpAssociatePortProfileId: VM OPERATION: create
2011-11-24 10:46:33.934: 2139: error : virNetDevSetOnline:454 : Cannot set interface flags on 'macvtap0': Device or resource busy
2011-11-24 10:46:33.934: 2139: debug : vpDisassociatePortProfileId:1163 : Disassociating port profile id '(nil)' on link device 'macvtap0' 
2011-11-24 10:46:33.934: 2139: debug : vpDisassociatePortProfileId:1165 : vpDisassociatePortProfileId: VM OPERATION: create
2011-11-24 10:46:33.959: 2138: debug : virEventPollRunOnce:629 : Poll got 1 event(s)
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchTimeouts:414 : Dispatch 5
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:459 : Dispatch 8
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:473 : i=0 w=1
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:473 : i=1 w=2
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:473 : i=2 w=3
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:473 : i=3 w=4
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:473 : i=4 w=5
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:473 : i=5 w=6
2011-11-24 10:46:33.959: 2138: debug : virEventPollDispatchHandles:487 : EVENT_POLL_DISPATCH_HANDLE: watch=6 events=1
2011-11-24 10:46:33.959: 2138: debug : udevEventHandleCallback:1467 : udev action: 'add'
2011-11-24 10:46:33.959: 2138: debug : udevGetDeviceProperty:120 : udev reports device 'macvtap0' does not have property 'DRIVER'
2011-11-24 10:46:33.959: 2138: debug : udevGetDeviceType:1095 : Found device type '(null)' for device 'macvtap0'
2011-11-24 10:46:33.959: 2138: debug : udevGetDeviceProperty:120 : udev reports device 'macvtap0' does not have property 'PCI_CLASS'
2011-11-24 10:46:33.959: 2138: debug : udevGetDeviceProperty:140 : Found property key 'INTERFACE' value 'macvtap0' for device with sysname 'macvtap0'
2011-11-24 10:46:33.959: 2138: debug : udevGetDeviceProperty:140 : Found property key 'INTERFACE' value 'macvtap0' for device with sysname 'macvtap0'
2011-11-24 10:46:33.959: 2138: debug : udevGetDeviceSysfsAttr:209 : udev reports device 'macvtap0' does not have sysfs attr 'address'
2011-11-24 10:46:33.959: 2138: debug : udevGetDeviceSysfsAttr:209 : udev reports device 'macvtap0' does not have sysfs attr 'addr_len'

The steps to reproduce are the same as in the Description.

Comment 5 Laine Stump 2011-12-02 10:34:27 UTC
Shradha,

I'm assuming from the patch you posted to libvir-list that updating your kernel solved the problem with passthrough mode. Is that correct?

As far as your problems with vepa, I'm unable to test vepa because it requires a vepa-capable switch. Your best bet for getting help with that would be to post a message to libvir-list, where the developers who did that work will see the problem and may be able to provide some help. Very few people see problem reports in the upstream bugzilla for libvirt, so it's not likely to get much response here, Upstream libvirt's bugzilla tends to mostly get used as a place to hold feature requests, while bug reports of this type are usually filed against a specific Linux distro, or handled completely on libvir-list.

Comment 6 Shradha Shah 2011-12-02 11:41:42 UTC
(In reply to comment #5)
> Shradha,
> 
> I'm assuming from the patch you posted to libvir-list that updating your kernel
> solved the problem with passthrough mode. Is that correct?

Laine,

Yes, updating the kernel solved my problem with the passthrough mode.

I will post my message regarding vepa mode to libvir-list.

Many Thanks for all your help.

Comment 7 Laine Stump 2011-12-02 15:25:15 UTC
Okay, I'm closing this bug then, since the originally reported problem is a kernel problem that's already fixed (both upstream and in the next RHEL release).