search for: tapx

...ach a vif, the domU will not start Looking at /var/log/daemon.log, I notice: xcp-fe: qemu-dm-10[9169]: can't add tap10.0 to bridge xapi1: Operation not supported while the output from dmesg suggests that the interface vif10.0 was created. It appears there is confusion between the vifX.Y and tapX.Y naming schemes. Can anybody comment on this? Is this hardcoded into some config that I should inspect? Is it hard coded in the qemu-dm scripts? It would be very desirable to fix this before the wheezy release so that people don't have a bad impression of XCP with HVM. Regards, Daniel...

Hi Everyone, In my HVM guest''s config file, I have given my guest 3 interface. I have called them fw1, fw2 and fw3. I have joined each interface to a bridge on the Dom0. This does appear when I do a "brctl show". However, there are 3 other interfaces also added called tapx.0,tapx.1 and tapx.2 (Where x is the domain ID for the guest). Furthermore, I am only able to run tcpdump on the tap interfaces; if I run tcpdump on the fw1,fw2 or fw3 interfaces, no packets are detected. This is a major issue when creating my firewall rules, as I wish to filter by interface, a...

If I understand correctly, a HVM domain''s network adapter gets a tapX device created for it in Dom0 for qemu to talk to, and a vifY.Z device for the PV drivers (which probably aren''t there) to talk to. How can I stop the qemu code creating the virtual Realtek driver? What will happen if I try and use PV and Realtek drivers at the same time? Will the Realtek...

THis is the modified script that came with tinc 1.0pre2, and it now uses ifconfig in stead of ip-route. I changed the syntax to be correct (may already have been fixedin a newer version), it now checks whether or not there is a '/dev/tapX' or a '/dev/netlink/tapX' and it checks if there is a module or not. I also added the force_connect and the reload options. Force_connect send an SIGALRM to tincd and reload sends a SIGHUP to tincd. Baard -------------- next part -------------- #!/bin/sh # # tinc tincd VPN setup scr...

I have set up both Windows XP and Windows 2000 Server clients on Xen under Centos 5.1 and am unable to install an application firewall. I have tried the latest: 1) Agnitum Outpost Commercial Version 2) Comodo Firewall (ver 2 on Windows 2000) 3) Sunbelt Commercial Version With all of these when the firewall starts up it results in a BSOD. With Windows XP and Agnitum I can go back to a previous

...$(echo $DEV | wc -l) -gt 1 ] && \ - { MSG="multiple TapDevice entries not allowed!"; return 1 } + { MSG="multiple TapDevice entries not allowed!"; return 1; } echo $DEV | grep -q -x -E '/dev/tap[[:digit:]]+' || - { MSG="TapDevice should be in form /dev/tapX!"; return 1 } + { MSG="TapDevice should be in form /dev/tapX!"; return 1; } # MyOwnVPNIP/MyVirtualIP syntax validation [ -z "$VPN" ] && \ - { MSG="MyOwnVPNIP/MyVirtualIP required!"; return 1 } + { MSG="MyOwnVPNIP/MyVirtualIP required!&quo...

Hello, While testing Fedora 16 Xen PVHVM guests I noticed the following problem: When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear on dom0, but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the vif/tap interfaces disappear from dom0.. so the bridge in dom0 doesn''t have any vifs/taps connected to it anymore. Has anyone seen that behaviour? I bet that''s also the r...

...VM", what I mean, is, these virtual machines are not paravirtualized. The are fully emulated x86 hosts. This is achieved using the vif-bridge script that accompanies the xen-tools (I have emerged the xen-tools-3.4.2-r1.ebuild ebuild provided by gentoo portage). Each HVM client increments a new tapx.x interface, and also a corresponding vifx.x interface. I am not using the standard xenbr0 configuration that everybody else is talking about and using. My bridge looks something like the following: (cloud) | [wired-eth0]-----| |---------[br0 on XEN DOM0 HOST] [wired-eth1]--...

...after the 1m40s timeout, I get a perfectly working domU with Network. Strangely, the vif network interfaces are now named tap[domUid].[interface#] (ie tap2.0). So, my questions : - Why is there no clear log about vif-bridge script, and how can I debug this script. - Why are the interfaces named tapX.X instead of vifX.X ? - Is there a default name for the bridge interface ? I''m currently using xenbr0, but I see that some documentations are talking about eth0, should I use eth0 as default bridge name ? Thanks, François. My config : root@UbuntuTST-Blade:~# xm info host...

...show xapi1 bridge name bridge id STP enabled interfaces xapi1 0000.de699bd4dc4d no vif1.2 vif3.1 It is only the HVM domU that has this error. Why is it talking about tap10.0 and not vif10.0 in the qemu-dm log message? Do HVM vifs use the tapX naming convention? Or is this the cause of the problem? dmesg output shows that a vif10.0 did exist briefly

I totally agree with Luc Boudreau about this problem. On modern branded server they ALL use Broadcom chipset... I must admit that: a) lot of people are experiencing the problem but can tolerate it or b) someone already experienced this problem and solved it Lets'' approach the problem pragmatically... just start with a survey on the list. ... hope we solve this issue soon. Ivan

Hey all, I''m trying to setup roadwarrior connection to my internal network. So I''ve setup openvpn to create a tap0 connection and also have bridged the eth1 (leads to my internal computers 192.168.2.10-30 and tap0 which is the VPN connection. On my shorewall setup I have br0 maped to zone loc and eth0 to be my internet and I have masqing on my br0 to get my internal computers