similar to: libxl: error when destroying domain on NetBSD

docs/man/xl.pod.1 | 6 +++++- tools/libxl/xl_cmdimpl.c | 39 ++++++++++++++++++++++++++++++++++++--- tools/libxl/xl_cmdtable.c | 3 ++- 3 files changed, 43 insertions(+), 5 deletions(-) xl: Introduce shutdown xm compatibility option -a to shutdown all domains Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it> diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1 ---

# HG changeset patch # User yamahata@valinux.co.jp # Date 1188274001 -32400 # Node ID 2c9db26f1d0e0fdd4757d76a67f4b37ba0e40351 # Parent 58d131f1fb35977ff2d8682f553391c8a866d52c Make XEN_DOMCTL_destroydomain hypercall continuable. XEN_DOMCTL_destroydomain hypercall frees domain resources, especially it frees all pages of the domain. When domain memory is very large, it takes too long resulting in

Libvirt has a fixed 15 second timeout for qemu to exit. If qemu is writing to a slow USB key, it can hang (in D state) for much longer than this - many minutes usually. The solution is to check specifically for the libvirt EBUSY error when this happens, and retry the virDomainDestroyFlags operation (indefinitely). See also the description here:

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1345046301 -3600 # Node ID 7cec0543f67cefe3755bbad0c2262fa2e820d746 # Parent 30bf79cc14d932fbe6ff572d0438e5a432f69b0a libxl: make domain resume API asynchronous Although the current implementation has no asynchromous parts I can envisage it needing to do bits of create/destroy like functionality which may need async

Hi, All Intel QA conducted a full validation for xen 4.1 rc1, it includes VT-x, VT-d, SRIOV, RAS, TXT and xl tools testing. 24 issues were exposed. Refer the bug list, please. We already assigned 14 bugs to Intel developers (which has an ''Intel'' tag in the bug title), most of the rest 10 bugs are related xl command. For the these bugs, need community''s help to fix

On 31.10.13 04:34, Miguel Clara wrote: > I was trying to get a core-dump for a domU with xl and got this error: > > # xl dump-core 20 test.core > Memory fault > > GDB shows this: > > a# gdb xl xl.core > GNU gdb (GDB) 7.3.1 > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later<http://gnu.org/licenses/gpl.html> >

Moved the node administration elements to a separate submenu. Created a new network administration menu. * users can define a network * users can create a network * users can destroy a network * users can undefine a network * users can list existing networks, including details Each new command is also available as a separate command line executable as well. Signed-off-by: Darryl L. Pierce

Prevent xl from doing any operation if xend daemon is running. That prevents bugs that happened when xl and xend raced to close a domain. Changes since v1: * Add documentation to xl man page. * Permit the execution of commands that don''t modify anything. * Indent error message. Cc: george.dunlap@eu.citrix.com Cc: ian.jackson@eu.citrix.com Signed-off-by: Roger Pau Monne

This version of the patch includes feedback from jboggs at redhat.com, including fixes to the BuildRequires and Requires in the spec file.

This patch obsoletes any previous ones. This is an upstream candidate, so I'm looking for feedback so we can push this and start using it.

This version fixes a few bugs found by jboggs. It also includes some logging facilities that need to be fleshed out more.

This patch is ready for pushing upstream.

Hello, I''m trying to compile Xen unstable on NetBSD, I''ve aplied the patches from http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/xentools41/patches/?only_with_tag=MAIN and copied the blk files from http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/xentools41/files/?only_with_tag=MAIN (I don''t know which of these patches have been applied to xen unstable, so

The previous patch was missing this file. Resending.

Hi All, I''ve been looking through the code and list archives but haven''t found this yet... From dom0, how do you cause a virtual domain to gracefully shutdown? It seems like the machinery is there somewhere, because the hypervisor can do it to dom0... For reference, in UML you do this by putting this in /etc/inittab: ca:12345:ctrlaltdel:/sbin/shutdown -h now ...and then

Hi, can someone explain the states shown by the ''xm list'' command? ''r'' (running) - The domain is currently running. - This flag is always shown for the Domain 0, but never for unprivileged domains, why? ''b'' (blocked) - The domain is blocked. - What does that mean? Why should a domain be blocked? ''p'' (paused) - The domain

The series introduces auto-generation of the type definitions used in the libxl interface followed by auto-generation of a destructor function for each type. In the future it may be possible to use the related data structures for other purposes, for example auto-generation of the functions to marshal between C and language binding data types. tools/_libxl_types.h should be identical both before

On Tue, Jan 19, 2016 at 04:18:46PM +0000, Richard W.M. Jones wrote: > Libvirt has a fixed 15 second timeout for qemu to exit. If qemu is > writing to a slow USB key, it can hang (in D state) for much longer > than this - many minutes usually. > > The solution is to check specifically for the libvirt EBUSY error when > this happens, and retry the virDomainDestroyFlags operation

Hi all, this is the tenth version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v9: - rename QEMU_UPSTREAM_TAG to QEMU_UPSTREAM_REVISION: we are going to use it with a branch name by default; - set QEMU_UPSTREAM_REVISION to "master" by default; - set SEABIOS_UPSTREAM_URL to git://xenbits.xen.org/seabios.git by default; - add

# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1324385575 -3600 # Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa # Parent f72b99fccfca694674259cc1c03c526a827b67ec libxl: add support for yajl 2.x This patch adds support for yajl versions 2.x, while retaining 1.x compatibility. This patch adds quite a lot of #ifdefs all over the json code, so I''m open