similar to: on_xend_start: booting, shutting down and vm startup order

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

Hi, I''m having some issues with having my domUs shutdown gracefully when my dom0 reboots. Heres my config.sxp. --- snippet --- (actions_after_crash restart) (actions_after_shutdown preserve) (auto_power_on False) (actions_after_reboot restart) (on_crash restart) (on_poweroff destroy) (on_reboot restart) (on_xend_start start) (on_xend_stop shutdown) ___________ When I reboot my

Hi, I''ve just made changes on xend config xend-config.sxp file, but I''m not sure if restarting xend daemon also restart domUs? Thoughts? thanks in advance. -- Regards; Israel Garcia _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

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: 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: 4.0.0-1 Severity: normal Hi, On system shutdown the 'xendomains' script appears to detect wrong guests: | Stopping libvirt management daemon: libvirtd. | Clearing ebtables rulesets: filter nat broute done. | Shutting down Xen domains: bev-d6x02(save).Error: Domain '1024' does not exist. | !(shut).Error: Domain '1024' does not exist. |

Hi, A few people are having problems with the new console daemon and I''ve tracked the problem down to the order in which daemons are started. Here''s what currently happens: 1) xend (the script in tools/misc) start will launch xcs and consoled 2) xend (the python server) will launch xenstored whenever it needs it This creates a bit of a chicken and the egg problem since

I'm seeing an issue with xend not running a custom network script automatically, but works when I run it manually. In /etc/xen/xend-config.sxp I've changed: (network-script network-bridge) TO: (network-script network-custom) Here is /etc/xen/scripts/network-custom: # !/bin/bash # network-custom script=/etc/xen/scripts/network-bridge case $1 in start) $script start vifnum=0

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

Hello, I Created a VM, on Xen. Attached: - the config file of the VM : xmprova8 - the video output while creting the VM: output_epaer_hebe8 - the xend config.sxp file:xend config modificato - note, the system takes a lot of time while starting MTA. but the machine at the end is working. The bad point is that i can''t log in from ssh, just the console. And of course is not possible to

on_xend_stop can be set to ''suspend''. However, on_xend_start cannot be set to ''resume'' as far as I can see, and it''s not automatic. This seems like an easy way to create a config that ends up corrupting the domU filesystem. Are there further changes planned here? Presumably it will involve on_xend_start=''start'' just doing the right

I posted the message below on the libvir-list with no replies, so perhaps someone on this list has some experience with this issue. Alternatively, if anyone has gotten remote migration to work with Fedora and Xen, could you please send me the version numbers you are using for each tool? I''ve tried Xen API with this setup previously, but migration didn''t work at all.

Fix config file parsing for VMX domains. If we define "vif" in the config file, image.py will raise error "vmx: missing vbd configuration". The reason is "vif" is dealt with as a "vbd" device. This patch fixes this issue by dealing with "vbd" and "vif " separately, removing "macaddr" arg and parsing mac address from

Package: xen-utils-common Version: 4.4.1-5 Severity: important Dear Maintainer, I tried to upgrade xen-utils-4.4 depending on xen-utils-common. Here is aptitude answer: ... Param?trage de xen-utils-common (4.4.1-5) ... insserv: Service xenstored has to be enabled to start service xendomains insserv: Service xenconsoled has to be enabled to start service xendomains insserv: exiting now!

Comparing my last know working configuration with the current one, it appears to be gagging on the new localhost\.localdomain that is in the configuration file. I don''t know if this got added by my machine when compiling. diff -ur xen-3.0-testing.hg/install/etc/xen/xend-config.sxp xen-unstable.hg/install/etc/xen/xend-config.sxp --- xen-3.0-testing.hg/install/etc/xen/xend-config.sxp

Package: xen-utils-common Version: 3.3.1-2 Tags: patch xend_stop currently fails because the script defines $XEND rather than $DAEMON. --- xen-common/debian/xen-utils-common.xend.init +++ xen-common/debian/xen-utils-common.xend.init @@ -49,8 +49,8 @@ xend_start() xend_stop() { - $DAEMON status || return 0 - $DAEMON stop || return 1 + $XEND status || return 0 + $XEND stop || return 1 }

Package: xen-utils-common Version: 4.0.0-1 Severity: important Xen domains should be shutdown before iSCSI if that is installed. This can be accomplished by adding the following to /etc/init.d/xendomains: # Should-Start: iscsi # Should-Stop: iscsi -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64)

Package: xen-utils-common Version: 4.4.1-9 Severity: important This bug was already reported as #763102 and was brushed off because maintainer says it implicates xend which is not there in 4.4 anymore. However, this problem is present during upgrade from wheezy to jessie and means that reboots are not possible without physical interventions. As noted in #763102, during shutdown, we can see this

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, since pinning the cpu cores to Dom0 and the DomUs the shutdown of the VMs doesn''t work anymore. When shutting down or rebooting a DomU the DomU just freezes after the shutdown process but won''t reboot or stop the DomU. The shutdown itself seems to be complete though. We can reproduce this problem on 4 different servers.

Package: xen-utils-common Version: 4.0.0-1 Severity: important Xen domains should be shutdown before iSCSI if that is installed. This can be accomplished by adding the following to /etc/init.d/xendomains: # Should-Start: iscsi # Should-Stop: iscsi -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64)