similar to: Bug#657745: xeutils-commonn-: /etc/xen/scripts/vif-bridge adds every tap interface to VM bridge which breaks openvpn connections.

Package: xen-utils-common Version: 4.1.2-1 Severity: important Dear Maintainer, I changed toolstack to xl in /etc/default/xen, rebooted machine, and xl started working, but creating domU (kfreebsd9 from package kfreebsd-image-9.0-1-xen) fails, because /var/lib/xen is missing. Just doing 'mkdir /var/lib/xen' solved my problem, and kfreebsd9 kernel now loads (still panics because of lack

Package: xen-utils-common Version: 4.1.2-1 Severity: important Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Witold Baryluk <baryluk at smp.if.uj.edu.pl> To: Debian Bug Tracking System <submit at bugs.debian.org> Subject: /usr/lib/xen-common/bin/xen-toolstack-wrapper: xl create fails because of missing /var/lib/xen

Hi everyone, A pair of network interface, vif and tap, will connect the bridge when a vm starts. What's their relationship? thanks for reply~ cheers bruce _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, I've been testing the Debian packages ahead of the Debian 7 release (which is very imminent) I believe this is a serious bug[1] in the package, as it appears that HVM networking is broken, or at the very least, requires some undocumented configuration step Specifically: - I can start the HVM domU without any vif - if I attach a vif, the domU will not start Looking at

On Thu, 2 Dec 2004 14:13:33 +0100 ncrfgs <ncrfgs@tin.it> wrote: > Hi, > > I'm using the great 802.1d Ethernet Bridging support via > brctl along with Universal TUN/TAP devices created with > openvpn on a GNU system with a vanilla 2.6.8.1 Linux > kernel. > > > To start it: > > /usr/sbin/brctl addbr br${X} > /sbin/ifconfig brX

Hi all. I have an OpenVPN server: 2.2.1-1 x86_64 Server config: port 11223 dev tap proto udp tls-server ca keys/ca.crt cert keys/server.crt key keys/server.key dh keys/dh1024.pem server 1.2.3.3 255.255.255.0 push "route 192.168.0.0 255.255.255.0 1.2.3.4" keepalive 10 60 client-to-client duplicate-cn inactive 600 log /var/log/openvpn.log syslog status /var/log/openvpn-status.log user

tags 671018 +patch thanks This issue has been fixed upstream for 4.2 by using the same hotplug scripts for tap devices as for vif devices rather than using a special qemu-ifup script. I don't think this is an appropriate thing to backport to 4.1 for wheezy so therefore I think the right fix is as Pierre suggests to set the MAC address in the qemu-ifup script. In terms of a patch to the

Hi, I''m now blocked for 2 days on getting the network to work in my domU. Here is the problem : The domU refuses to start when a vif is configured. It''s just staying paused for about 1m40s, then the xm create command line give back with an "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.", and the domU is destroyed. Nothing particular

Hi, I''m using the XEN 3.4.1-pre4 Hypervisor in Routet Mode and I''m facing some problems when I start the DomU. In detail, it means that the DomU IP-Adress will not be implemented in the Kernel routing table after starting the domU via "xm create /<path +configfle>" After making a "netstat -nr" it will not show the IPadress bound to the

I have a HP370 with 16 GB memory. If I build 7 Guests everything works fine. If I start the 8 guest I get this error: Error: Device 0 (vif) could not be connected. Hotplug scripts not working. I have xen 3.0.1 with PAE on Redhat 4.1 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Hi all, So i am starting a domu essentially with MiniOS and the configuration file is as follows: ################################ kernel = "path/to/mini-os.gz" #4MB is all i need memory = 4 cpus = "1" name = "Domain3" on_crash = ''destroy'' vif=[''mac=00:16:3E:00:00:01 , bridge=xenbr0, ip=10.0.0.1''] ################################

Hello, I was also hit by this problem. Perhaps it is related to the xen-netback module in the dom0 kernel? Have a look at: http://www.gossamer-threads.com/lists/xen/devel/275548 -- greetings eMHa -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL:

I have the following script, how can I implement to achieve that calculate the VIF. Thanks. U1.7km<-c(15:24) R<-c(1.2,0.2,3.6,2.5,4.8,6.3,2.3,4.1,7.2,6.1) Hm<-c(1:10) mod<-nls(R~a*(U1.7km^b)*(Hm^c), start=list(a=2.031, b=0.800, c=-0.255), trace=T) summary(mod) coef(mod) coef(summary(mod)) -- View this message in context:

I''ve just gotten xen-4.0.1-rc4-pre on top of Ubuntu 10.04 using the 2.6.32.15 kernel source installed and booting into Dom0 thanks to you guys! I was under the impression that xend would setup at least a basic bridge interface and some vif interfaces automaticlly.. I don''t get any of that. And when I try to start xend manually after reboot I get: ifdown: interface eth0 not

This is on a snapshot from 11/12/2005 of unstable. I wrote some quick debug code into vif-route to see what is going on during runtime, ex: echo "xenbus_path = $XENBUS_PATH" >>/root/route.log echo "command = $command" >>/root/route.log After starting/stopping a domain a few times it contains: xenbus_path = backend/vif/20/0 command = online xenbus_path =

I''m finding I cannot use the vif parameter with ''bridge'' only For example: vif=bridge=xen-br2 This errors out: [2005-09-30 14:23:55 xend] DEBUG (XendDomainInfo:1107) Creating vif dom=16 vif=0 mac=None [2005-09-30 14:23:55 xend] DEBUG (XendDomainInfo:665) Destroying vifs for domain 16 [2005-09-30 14:23:55 xend] DEBUG (XendDomainInfo:674) Destroying vbds for domain

Hello, I have a Sun X4140 running snv_134 as a Dom0 with a CentOS 4.8 (for Oracle 9i) and an Opensolaris DomU running on it with 4 NICs configured. I''m experiencing the virtual NICs dropping on the host. The Dom0 NICs are up and fine, and I am able to xm console into the DomU. The only metric that I have which seem useful is that memory scan rate spiked from near-0 to 507 under a

I am using nat for guest domU with dhcp running on dom0. on creating the domU xend-debug.log reports: Can''t open /etc/dhcp3/dhcpd.conf: Permission denied and dhcp fails. The vif0.X is created and the dhcp.conf is modified according to the randomly generated mac address and the address of vifx.0. I think the problem lies in the vif-nat script in synchronization during dhcpd.conf

When start a domU through xl create. The domU associated ip in the configuration file is not recorded in the xenstore. For this reason vif-common.sh antispoof scripts fails. *xl create * /usr/bin/xenstore-ls /local/domain/0/backend/vif/5/0 frontend = "/local/domain/5/device/vif/0" frontend-id = "5" online = "1" state = "4" script =

I had some problems getting Xen to work on my machine. I tracked down the problem to the function dom0_ip in vif-common.sh which shall retrieve the ip address of the main network device of dom0. This function, however, fails in some admittedly unusual configurations. The machine in question is a rented server. The LAN adapter is configured with a /32 netmask. I have debian, and this is an excerpt