similar to: Bug#435406: xen-utils-common: xm save does not use compression

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal After running "halt" in a couple of domains I ran "xm list" repeatedly to see when the halt command was complete. Below is some of the output. The "Device 0 not connected" should not occur. yoyoxen:~# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal There should be a clean and clearly defined way to restart all the Xen daemons in the case of error. If the file /var/lib/xenstored/tdb is corrupt then you must stop xenstored, rm the file, and then restart it. Currently there is no defined way of doing this so the solution is to kill -9 the process, rm the file, and then reboot. --

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal When a block device name is wrong (the device does not exist) it should say "block device /dev/foo/bar does not exist" instead of waiting for ages and giving the following error: Using config file "/etc/xen/ha2". Error: Device 768 (vbd) could not be connected. Hotplug scripts not working. Also the following parsing

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: 4.0.0-1 Severity: important After running modules_setup you need to have the following line: [ -x /sbin/restorecon ] && /sbin/restorecon -R /dev/xen The reason is that the module load causes the kernel to create device nodes in the devtmpfs. This bypasses the udev code for labelling the device node and results in xenstored being unable to access

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.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-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 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: 3.0.3-0-2 Severity: minor Tags: patch Hi ! /etc/init.d/xendomains and /etc/init.d/xend complain about xen-utils-version not existing any more instead of failing silently. The following patch fix this problem. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1,

Package: xen-utils-common Followup-For: Bug #430778 Here's a patch I made to have working rules here... feel free to comment/adapt. Hope this helps -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-xen-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8,

Package: xen-utils-common Version: 4.0.0-1 Severity: normal Hi, I think would be good to have a note in manpage about this issue. Will save time to many people which will search about xmlproc in squeeze. --- xm.1.orig 2010-08-31 11:02:15.393343178 +0200 +++ xm.1 2010-08-31 11:05:25.978339569 +0200 @@ -466,7 +466,9 @@ .RE .IP "\fBnew\fR \fIconfigfile\fR [\fI\s-1OPTIONS\s0\fR]

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal I cannot find a use the network-nat and vif-nat provided in the general case, where I'd like to NAT between vifx.0 and ethx interfaces. I have setup the following in /etc/xen/xend-config.sxp : ## Use the following if network traffic is routed with NAT, as an alternative # to the settings for bridged networking given above.

Package: xen-utils-common Version: 4.1.2-1 Severity: grave Justification: renders package unusable (Grave because dash is the default /bin/sh) With dash 0.5.5.1-7.4 as /bin/sh, /usr/sbin/xm enters an infinite loop of reexcuting itself. When run with bash, it works correctly. I traced that to /usr/lib/xen-common/bin/xen-toolstack; here's the diff between "/bin/sh -x /usr/sbin/xm"

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-common Version: 4.0.0-1 Severity: important The xm utility requires python-xml but the package does not depend on it. # xm new --help_vars Unexpected error: <type 'exceptions.ImportError'> Please report to xen-devel at lists.xensource.com Traceback (most recent call last): File "/usr/lib/xen-4.0/bin/xm", line 8, in <module>

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal I'm not an expert in networking but I think that the current setup when using network-nat for domains is insecure. I've configured : (network-script 'network-nat netdev=eth1') (vif-script vif-nat) So when only domain 0 is started, I get the following : # iptables -L -n Chain INPUT (policy ACCEPT) target prot

Package: xen-utils-common Version: 4.0.0-1 Severity: important When xen domUs are saved by running /etc/init.d/xendomains stop the memory images are saved world readable, so that every user on the system can read the memory dumps. The default mode of /var/lib/xen/save is 755, vm images are saved with mode 755. At least the save directory shoudn't be world readable. -- System Information:

Package: xen-utils-common Version: 3.2.0-2 Followup-For: Bug #519064 I've experienced the same problem (missing /var/lib/xen/save) on one host, but had no problem on another. Some investigation showed that /var/lib/xen/save gets created on some actions like a reboot whith a suspend/resume cycle. This problem will thus not be reproducable on quite some hosts, but is a real bug. The simplest

Package: xen-utils-common Version: 3.2.0-1~bpo4+1 Severity: minor I use the version from backports, but it's still present in sid. In /etc/xen/xend-config-sxp : #(xen-tcp-xmlrpc-server-address 'localhost') #(xen-tcp-xmlrpc-server-port 8006) should be #(xend-tcp-xmlrpc-server-address 'localhost') #(xend-tcp-xmlrpc-server-port 8006) Small typo in a commented line, but