similar to: Bug#417243: xen-utils-common: Should display a usable error message when there is a config file error

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: 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.2.0-2 Severity: normal When file: sources are used for Xen block devices the Xen system will use a loopback device for each one. It's quite common for DomUs to be configured with two block devices (one for storage and one for swap) and not uncommon to have a block device for each filesystem (which makes it easier to grow filesystems). Therefore the

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: 4.4.1-9+deb8u1 Severity: normal With SE Linux it's desirable to give utilities and daemons the minimum privileges. That includes not permitting general utilities to create directories under /var/run. I think it would be best if /var/run/xen-hotplug was created by an init script such as /etc/init.d/xen (or by systemd-tmpfiles when using systemd units).

Package: xen-utils-common Version: 4.4.1-2 Severity: normal For correct operation under SE Linux the start script needs to assign correct security labels to firectories it creates. Note that restorcon doesn't cause any problems if run twice. If it's executable then you can safely run it. Below is a patch that demonstrates how to solve this problem. --- xen.old 2014-10-12

Package: xen-utils-common Version: 3.4.2-3 Severity: normal If one daemon is running but the others are not then the stop script will fail. It should use the pid file for each daemon and try to stop them independently. Note that the fact that Xen shouldn't get into this state is not relevant, daemons do periodically fail, relevant system control scripts should be able to stop them even

Package: xen-utils-common Version: 4.1.3~rc1+hg-20120614.a9c0a89c08f2-2 Severity: important Please modify the init scripts in a manner similar to the following to give the correct SE Linux labels. Failing to correctly label them may result in Xen not working correctly when SE Linux is enabled. --- /etc/init.d/xen.orig 2012-06-24 10:29:04.000000000 +1000 +++ /etc/init.d/xen 2012-06-24

Package: xen-hypervisor-4.0-i386 Version: 4.0.0-2

Package: xen-utils-4.4 Version: 4.4.1-9 Severity: normal # /usr/lib/xen-4.4/bin/xl create -c /etc/xen/katana Parsing config from /etc/xen/katana libxl: error: libxl_utils.c:217:logrename: failed to rotate logfile - could not rename /var/log/xen/qemu-dm-katana.log.6 to /var/log/xen/qemu-dm-katana.log.7: Permission denied Segmentation fault The above happens repeatably when I run xl on a system

Package: xen-utils-common Version: 3.4.2-2 Severity: important The network setup uses not longer supported iptables operations: | physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate

Package: xen-utils-4.0 Version: 4.0.0-1 Severity: normal xen-utils-4.0 needs to be built to work with the version of Python in Unstable. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal While reviewing the contents of /etc/init.d/xendomains, I noticed that the script sets a variable named WDOG_PID but later references an uninitialized variable named WDOG_PIG. I'm not sure how much this impairs the behavior of Xen, so I left the severity at "normal". See below for a simple patch: --- xendomains.orig

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: 4.1.0~rc6-1 Severity: important Currently xend fails to create a fully virtualized vm because it has a different path hardcoded to it. Unable to complete install: 'POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: device model '/usr/lib64/xen/bin/qemu-dm' not found")' The correct path to use

Hi all, I'm running OCFS2 on two system with OpenSUSE 10.2 connected on fibre channel with a shared storage (HP MSA1500 + HP PROLIANT MSA20). The cluster has two node (web-ha1 and web-ha2), sometimes (1 or 2 times on a month) the OCFS2 stop to work on both system. On the first node I'm getting no error in log files and after a forced shoutdown of the first node on the second I can see

Package: xen-utils-common Version: 4.1.3-6 Severity: minor Dear Maintainer, I am trying to run the following command on a dom0 Debian server in order to mount a vmware vmdk. I don't want to use kpartx or losetup as they have poor write performance and I'm hoping blktap will provide better performance. xm block-attach 0 tap:vmdk:/mnt/backup/3MSYDDP01/3MSYDDP01_2-flat.vmdk /dev/xvda1 w 0

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal Tags: patch When shutting down xen domains with '/etc/init.d/xendomains stop' most of the time not all domains are stopped when the script finishes. As it turns out the xendomains-script queries running domains by executing 'xm list', this command replies its usage info sometimes instead of giving proper output. I

Package: xen-utils-common Version: 4.0.0-1 Severity: normal A strange issue, when deploying Xen using Puppet, /etc/udev/rules.d/xend.rules and /etc/udev/rules.d/xen-backend.rules files are empty. Specifically, the symlinks point to ../xend.rules and ../xen-backend.rules respectively in /etc/udev, but neither of those files exist. Manually copying those files from another host that was not