similar to: Bug#503044: xen-utils-common: should make the loopback device default to supporting more nodes

On Wed, 22 Oct 2008, Russell Coker wrote: > It seems reasonable to create a file /etc/modprobe.d/xen that contains > the following line to alleviate this: > options loop max_loop=32 Since kernel 2.6.22, loop devices are allocated dynamically, so that you can `mknod /dev/loopN b 7 N` for any N and start using it immediately. The max_loop option causes more loop devices to be

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.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 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-3.2-1 Version: 3.2.1-2 Severity: normal When a DomU is defined as using a file: device the loopback driver will be used to make it appear to be a regular block device. The loopback driver will by default only support 8 nodes so this is a limited resource. http://etbe.coker.com.au/2008/10/22/kernel-issues-with-debian-xen-and-centos-kernels/ If there is a problem that prevents

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: 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.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.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-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

As a quick extra note, /usr/share/doc/xen-utils-4.1/README.Debian from xen-utils-4.1 version 4.1.2-2 still reads: | 1. Maximum number of loop devices | By default the loop driver supports a maximum of 8 loop devices. Of | course since every Xen domain uses at least two (one for the data and one | for the swap) this number is absolutely insufficient. You should increase | it by adding

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-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-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.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: 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

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

Subject: xen-utils-common: /etc/init.d/xen restart fails when using network-bridge if netdev does not match eth[0-9+] Package: xen-utils-common Version: 3.1.0-1 Severity: normal *** Please type your report below this line *** On a machine where the NICs are named something other than ethN, and using (network-script 'network-bridge netdev=XXX') (where XXX is the name of one of these

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