similar to: Bug#554805: Bug in patch

tag 554805 + patch thanks The problem to solve is that qemu-ifup assumes the world is always bridged, and vif-routed does not know of the concept of TAP devices, and even if it did, it has at this point no way to get at qemu's TAP device anyway. The following set of patches help run in the ioemu-HVM situation: * xend-image.py.diff : modifies the HVM loader so that when running in

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: normal Under this Xen setup, (Linux) HVM guests fail to have network active when running with *routed* networking, as some hosting providers require (in my case, OVH). In this scenario: * the host is a described below * the guest runs as HVM. * the guest runs exclusively with ioemu; virtual network drivers are not available (vanilla lenny

Package: xen-utils-common Version: 4.0.0-1 Severity: normal After upgrading xen-utils-common from 3.4.2-4 to 4.0.0-1, I could not create a guest domain defined with a DRBD file type. The xm create command would fail with "Error: Device 51713 (vbd) could not be connected. Hotplug scripts not working.". After some research I realized the /etc/xen/scripts/block-drbd helper script was

I am using Debian 6.0 "Squeeze", I applied that patch (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591456) to xen-common because of lack of hotplugpath.sh. network-route netdev=eth1 now does work, but vif-route gives me this error: root at xen-dom0:~# xm create /srv/xen/profiles/ca.cfg Using config file "/srv/xen/profiles/ca.cfg". Error: Device 0 (vif) could not be

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1341941699 -3600 # Node ID efb7fee3573b68e895de0341dd67df83cb68acc6 # Parent ca5c306052791edf6d96da3f80aecd750b86a5e4 hotplug: vif: fail if a duplicate vifname is used. This is based on a patch from Hans van Kranenburg in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658305. Quoting that bug report: When

Xen developers, After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed NIC stopped working. This bug was probably introduced in Debian Jessie sometime between 2015-12-30 and 2016-01-08 as 2015-12-30 as 2015-12-30 was the last time I upgraded without any problems according to my dpkg.log. This bug has also been reported to Debian Bug (https://bugs.debian.org/810379), where I got

On Wed, 2015-09-16 at 01:52 +0200, Arne Klein wrote: > [...] > At the moment when the network in the domU completely stops working, > there is the error message > [2178752.854380] vif vif-33-0 vif33.0: Guest Rx stalled > visible in dmesg in the dom0. This will therefore be a kernel issue not a hypervisor one. It sounds like a backend one given the issue is with both new and

Package: src:xen Version: 4.17.3+10-g091466ba55-1~deb12u1 Severity: wishlist I wasn't sure if this script comes from Debian or Xen or somewhere else, so I thought it safest to report it here. /etc/xen/scripts/vif-bridge handles MTU settings in the vif, but the otherwise similar /etc/xen/scripts/vif-openvswitch does not. I added it in, here's the diff-c and the full fixed file is also

Source: xen Severity: normal Dear Maintainer, After an upgrade, my passthroughed NIC stopped working. I created a new jessie domU and tried to passthrough some PCI devices and found that both USB3 host controller and tg3 NIC generated these lines in domU dmesg: xen:events: Failed to obtain physical IRQ 31 xen:events: Failed to obtain physical IRQ 32 xen:events: Failed to obtain physical IRQ 33

Package: xen-utils-common Version: 4.1.4-3 Severity: important Dear Maintainer, While updating my xen package today, I was prompted with a config file conflict. --- /etc/xen/scripts/hotplugpath.sh 2013-04-28 01:51:20.899778510 +0800 +++ /etc/xen/scripts/hotplugpath.sh.dpkg-new 2013-04-19 19:39:55.000000000 +0800 @@ -1,12 +1,10 @@ SBINDIR="/usr/sbin" BINDIR="/usr/bin"

Control: reassign -1 src:xen Hi Stephen, You filed this bug against xen-utils-3.0.3-1, but such a package does not exist in Debian. My guess is that it was once built from xen and I have (tried to) reassign it accordingly. That said, at first glance if your problem is related to a package from Debian etch. Unless this problem can be reproduced in a newer version of the package, the

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u1 Severity: important A few minutes after starting a domU, network access is no longer possible from and to it. This does not always happen and is not easily reproducible, but seems to occur in all newly started domUs from some point in time on. However, also restarting the dom0 does not necessarily prevent the problem. At the moment when

Package: xcp-xapi Version: 1.3.2-14 Severity: important I chose the Open vSwitch (ovs) networking mode when I installed XCP # cat /etc/xcp/network.conf openvswitch Whenever I boot a VM, I notice that the vif interface is created (e.g. vif1.0) on dom0, and the vif is added to the ovs bridge (I can see it in the output of ovs-vsctl show) However, there is no connectivity, I can't ping the

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1341875694 -3600 # Node ID 1d33f934dd675a1b91d2d4e0fa2d2a873a8debf5 # Parent 54384951de02e2db909116d64aa6a65d06ffa708 hotplug: fix ip_of for systems using a peer-to-peer link This is from an old Debian bug at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437127 I'm slightly inferring what the configuration

Package: xen-utils-4.3 Version: 4.3.0-3+b1 Using the xl toolstack there's no information about the networks of the domUs in xentop. I have a PV and a HVM domU and both are shown as having 0 network interfaces, while in fact they have functioning interfaces. Here's one of the interfaces that should be shown, from xenstore: 29 = "" 0 = "" frontend =

Package: xen-utils-common Version: 4.3.0-3 Severity: normal Dear Maintainer, * What led up to the situation? I upgraded my server from squeeze to wheezy and then to jessie. Server is Intel S3200SHV m/b with Intel(R) Core(TM)2 Quad CPU. I'm pretty sure that before that it was running whatever came before squeeze, I forget the name. I was trying to get xen_pciback to work, so I

Package: xen-utils-common Version: 4.0.0-1 Severity: important When Xen is configured in routed mode, restarting xend fails because the script hotplugpath.sh is missing. Please see below for more information. *** root at eliott:~# /etc/init.d/xend restart Restarting Xen daemons: xend/etc/xen/scripts/network-route: line 20: /etc/xen/scripts/hotplugpath.sh: No such file or directory

Package: xen-hypervisor-4.1-i386 Version: 4.1.1-1 Severity: important Tags: wheezy I cannot boot a domU with networking after installing the package. root at topsail:~# xm create /etc/xen/udevtest.cfg -c root at topsail:~# Error: Device 0 (vif) could not be connected. Hotplug scripts not working. [2011-08-03 15:56:53 4411] DEBUG (DevController:139) Waiting for devices tap2. [2011-08-03

On Thu, 2015-07-30 at 09:41 +0000, Andy Smith wrote: > Package: xen-utils-common > Version: 4.4.1-9+deb8u1 > Severity: normal > > Dear Maintainer, > > When booting a PV guest (xl create -c /etc/xen/foo.conf), immediately > after pygrub has determined which kernel/initramfs it will use, the > following error messages are logged: > > xenconsole: Could not open tty

Package: xen-utils-3.0 Version: 3.0.2+hg9656-1 Severity: normal My setup is a basic one. No changes to the /etc/xen/* files. Network in a domU works perfectly fine. But, after shutdowning a domU, I can see the following lines in /var/log/debug: May 6 10:31:45 vaio logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/18/0 May 6 10:31:46 vaio logger: /etc/xen/scripts/vif-bridge: