similar to: Bug#519064: xen-utils-common: /var/lib/xen/save gets created after reboot

Package: xen-utils-common Version: 3.2.0-2 Severity: normal When I was trying to migrate (xm migrate) a guest from one host to another, it simply fails. On the source host the virtual machine gets destroyed without any warning message - on the destination host I see the following error message in /var/log/xen/xend.log [2009-03-10 08:01:22 9846] ERROR (XendCheckpoint:52) read_exact: EOF trying

Package: xen-utils-3.4 Version: 3.4.0-0~ct Severity: important After installation of linux 2.6.26-2-xen-686 and xen-utils-3.4 the 2 onboard NICs 82574L (driver e1000e) are not working. ping results always in unreachable hostname ethtool seems fine for the eth's mii-tool has no transceiver for the eth's ip link show shows an UNKNOWN state for the eth's With linux 2.6.26-2-xen-686 and

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl isn't started by default. If blktapctrl isn't started then none of the tap: disks (eg tap:aio) work. This functionality has been removed in tools-misc-xend-startup.diff @@ -120,24 +86,14 @@ if not sys.argv[1:]: print 'usage: %s {start|stop|reload|restart}' % sys.argv[0] elif

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl doesn't start. This means that none of the tap: disks work (eg tap:aio). It produces this in the log BLKTAPCTRL[6569]: blktapctrl.c:788: blktapctrl: v1.0.0 BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (aio)] BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (sync)]

Package: xen-utils-3.4 Version: 3.4.0-1 Severity: grave Justification: renders package unusable This packages should depend on the 3.4 version of xenstore utils and library, because it the Lenny versions are installed, xend crashes instead of starting up. (Many users choose to run lenny/sid hybrid systems, with lenny as default, so it's completely plausible that the wrong package will be

Package: xen-utils-3.4 Version: 3.4.0-1 Severity: important The current version of the package does not contain the IOEMU tools. This makes HVM domains, and PV domains with emulated features like VFB impossible to run. There might be good reasons for this, but then at least the package description should contain a warning that makes this obvious, so that users know that they can not simply

Package: xen-utils-3.4 Version: 3.4.0-1 Severity: important pygrub uses the fsimage library to read contents of the filesystems to boot. This package install the plugins for different filesystems at /usr/lib/xen-3.4/lib/fs/, but searches for them under /usr//usr/lib/fs. (The debian patch tools-libfsimage-prefix.diff explicitly tinkers with this path, but it fails.) This breaks pygrub. --

Package: xen-utils-common Version: 4.0.0-1 Severity: normal Tags: squeeze The host runs (at the time of testing) a single linux-x86 domu (128MB, 1VCPU). When issuing a reboot, everything looks as expected: - domu is saved - xend is stopped - drbd stopped - lvms unmounted - md0..4 stopped and the message "rebooting now" appears, but nothing happens until "INFO: task xenwatch is

Package: xen-utils-common Version: 3.2.0-2 Followup-For: Bug #511579 My system is a Dell PowerEdge SC1435. As most of the servers of this category, it comes with 2 network interfaces. Both based on a Broadcom Corporation NetXtreme BCM5721 chip, set up via tg3 module. Does multiple NIC's triggers the bug? This link helped me a lot: https://systemausfall.org/wikis/howto/XenUpgrade3.2 --

Package: xen-utils-common Version: 3.4.2-3 Followup-For: Bug #571634 I can confirm that this bug not only exists in the current version but that it makes a DomU which forwards packets unusable. Other "simpler" DomUs which do not forward work perfectly. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (1000, 'stable'), (100, 'testing')

Package: xen-utils-common Version: 3.2.0-2 Severity: wishlist Hi, It would be very useful it /usr/bin/pygrub was available -- it should be a symlink (or wrapper) that points to the real version in the Xen hypervisor. That would mean that the domain configuration for xen domains could be (relatively) static when upgrades are occuring between hypervisor versions. Thanks, Anand -- System

Package: xen-utils-3.4 Version: 3.4.0-1 Severity: critical Justification: breaks unrelated software After installing xen-utils-3.4 besides my existing xen-3.2 system, I could not start xend-3.2 anymore. The message I was getting is this: "Failed to initialize dom0 state." As far as I know, xen 3.2 and 3.4 are supposed to be able to live peacefully on the same system. (The

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal xendomains saves the active domains when shutting down. it get the list of active domains from the following command[1]: xm list | grep -v '^Name' the output of "xm list" is like: lichen:~# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0

Package: xen-utils-common Version: 3.0.3-0-2 Severity: important patch I ran into this problem when using xen on Debian/Etch. I have several virtual xen instanses, and I name them using their fully qualified DNS domain name. These machines have failed to start automatically when I booted the host machine, and I just recently found out why. During shutdown, I was messages like this: Error:

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal gzip -3 compresses the Xen save files in a reasonably small amount of time and makes them take less than half the space that they might otherwise require. On systems with an encrypted root filesystem and on systems that have really fast CPUs if xm supported such compression then that would increase the speed of xm save and xm restore

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal On my systen, the script vif-common fails to retrieve the primary IP address of my ethernet device, preventing a domU from starting. I tracked this issue down to the file /etc/xen/script/vif-common. The function ip_of uses the following shell code to extract the address: ip addr show "$1" | awk "/^.*inet.*$1\$/{print

Package: xen-utils-common Version: 4.0.0-1 Severity: minor Tags: patch /etc/xen/scripts/block doesn't properly enclose $file in quotes for two out of three stat calls, which causes the script to fail on files which contain special characters (i.e. spaces) in their filename or pathname. See attached for patch. -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT

Package: xen-utils-common Version: 3.4.2-4 Severity: minor /usr/share/doc/xen-utils-common/examples contain samples with incorrect (for debian) and obsolete kernels names. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-xen-amd64 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8,

Package: xen-utils-common Version: 3.0.3-0-2 Severity: minor When I try to read the man page of xm, these warnings show up: Manual page xm(1) line 1/tmp/zmanA5668G:641: warning: can't find numbered character 160 /tmp/zmanA5668G:643: warning: can't find numbered character 160 /tmp/zmanA5668G:651: warning: can't find numbered character 160 /tmp/zmanA5668G:652: warning: can't find

Package: xen-utils-common Version: 3.0.3-0-2 Followup-For: Bug #401249 I don't mean to "me too", but I thought I might inform that this is not a one-off occurence. Please advise how I can assist with further debugging. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to