similar to: [PATCH] [XM] Enable a bootloader when using XM via Xen-API

Fix for pygrub path on Solaris. Signed-off-by: John Levon <john.levon@sun.com> diff --git a/tools/python/xen/xend/XendDomainInfo.py b/tools/python/xen/xend/XendDomainInfo.py --- a/tools/python/xen/xend/XendDomainInfo.py +++ b/tools/python/xen/xend/XendDomainInfo.py @@ -37,7 +37,7 @@ from xen.util.blkif import blkdev_uname_ from xen.util.blkif import blkdev_uname_to_file from xen.util

This is a proposal for modifying the interface for domU bootloaders (i.e. something that provides us with a kernel and ramdisk file with which the domain can be booted). The current interface, as is, has a number of problems, including: 1) the first disk specified is assumed to be the disk containing the files 2) ''bootentry'' is highly pygrub-specific. There is no easy facility

Hi all, I am unable to start the virtual machine. Its configuration file is # Automtically generated by ConVirt name=''virtual1'' ramdisk=''/home/devi/Desktop/initrd.img'' kernel=''/home/devi/Desktop/vmlinuz'' bootloader='''' vif=[''mac=00:16:3e:0c:e1:16, bridge=xenbr0''] #extra = ''ks=

xend has a timeout such that if an ''xm shutdown'' request does not result in the domain shutting down within a certain time period, the domain is violently destroyed. This seems like a strange choice - if the domain isn''t responding properly to such requests, then it must be in a buggy state, and should surely be preserved for administrator action (dumping core,

This cset: changeset: 11473:0008fca70351 date: Thu Sep 14 08:19:38 2006 +0100 description: xm dump command add on xm dump-core [-L|--live][-C| --crash] <domID> [output path] Didn''t actually implement anything. Worse, it looks like we don''t even pause the domain, so it''s always live (not good). What''s going on? regards john

The following test case does local migration 3 times in a loop. I currently see the following error output on x86-64 (only!) inside the guest (change debugMe in line 68 of xm-test/lib/XmTestLib/Console.py to True): @%@%> XENBUS error -12 while reading message XENBUS error -12 while reading message XENBUS unexpected type [1325400064], expected [4] XENBUS error -12 while reading message XENBUS

I''ve got a CentOS 5.3 dom0 with Xen 3.4.1-rc5 (or so). I''ve tried the same stuff below with 3.4.0, no difference. I''m trying to install 2009.06 PV domU based on instructions from [1] and [2]. I can run the install fine, I can also get the kernel and boot archive (from [2]) after the install. But for the life of me I can''t get the installed domU to boot. If I

I attempted to install Ubuntu 10.04 as a domU on my CentOS dom0. The process I used was: wget http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/xm-debian.cfg Edited the config file to use the proper logical volume for its install, and stepped through the install, installed GRUB to the MBR, and all seemed well. However, upon xm create -c NAME

16396:055d98aa2dd0 almost works but not quite. LDFLAGS_DIRECT means we end up with: gld -melf_i386 -nostdlib -N -Ttext 0x100000 -o hvmloader.tmp hvmloader.o mp_tables.o util.o smbios.o 32bitbios_support.o acpi/acpi.a Specifying a linker script and asking for -nostdlib is obviously contradictory. Removing $(LDFLAGS_DIRECT) fixes the problem. regards john

Hi, Is there any tool out there that can help me analyze a coredump? Thanks, David. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Package: xen-utils-4.4 Version: 4.4.1-9+deb8u8 Severity: normal Under Xen 4.1 in Debian 7 (wheezy), the following works when included in a DomU configuration in "/etc/xen/cfg/" -- bootloader = '/usr/lib/xen-default/bin/pygrub' After upgrading to Xen 4.4 as part of an upgrade to Debian 8 (jessie), the DomU silently fails to start. Examination of the log files shows that the

I've just done a fresh lenny amd64 install, and taken the xm-debian.cfg example: http://people.debian.org/~joeyh/d-i/images/daily/netboot/xen/xm-debian.cfg and built a 32 bit lenny inside a 64 bit lenny dom0 # xm create -c xm-th2.cfg install=true install-installer=http://people.debian.org/~joeyh/d-i/images/daily/ When I try to boot the domU: # xm create -c xm-debian.cfg it

All, Is is possible for xm create foo.cfg to traverse a symlink to access the foo.img. Here''s an example config and the resulting error.. --- name = "jim" memory = "512" disk = [ ''phy:/dev/VolGroup00/foo,xvda,r'', ''tap:aio:/home/fred/local/jim/build/foo_swap.img,xvdd,w'',

# HG changeset patch # User john.levon@sun.com # Date 1161090606 25200 # Node ID c6bfe43048f3becda6966deceb7b70baea833b7c # Parent 03d4223c846b14fc415cfd05d970c7b4d688fddb Many of the tools use C99 features such as bool, or expect certain functions. Fix the CFLAGS to enable these on Solaris. Signed-off-by: John Levon <john.levon@sun.com> diff --git a/config/SunOS.mk b/config/SunOS.mk ---

I am running Xen 3.0 (64bit) on CentOS 5.3, and I want to install Ubuntu 10.04 using the steps below: 1. Create a new disk with LVM 2. Downlaod vmlinuz & initrd.gz from http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/ 3. /usr/sbin/xm create -c /etc/xen/ubuntu.cfg install=true 4. Format the whole disk as EXT3, mount as / 5. The installer show some

This patch moves some dom0 variables and backend device configuration from frontend directories to /local/domain/<backdomid>/backend or /vm. Also, - the first console is created as a xend device and moves from console/0 to device/console/0 - /vm_path/<domid> is introduced, referencing the /vm path - /vm_path/device/backend holds the backend device location, rather than storing it

Hi All, Debian squeeze, Xen 4.0, 2.6.32-5 I successfully installed opensolaris, but when trying to convert to pygrub it just hangs. root@vhost2:/var/log/xen# xm create /etc/xen/opensolaris.cfg -c Using config file "/etc/xen/opensolaris.cfg". root@vhost2:/etc/xen# xm list Name ID Mem VCPUs State Time(s) Domain-0

I just tripped over this issue with pygrub. The code is written such that saying bootloader="pygrub" should cause the correct path to be used, the attached patch simply fixes this path to be correct. I don't have an HVM capable test machine handy (so I can't actually confirm this works) but I think changing the default "kernel" for an HVM guest to point to the correct

This changeset: changeset: 15606:17820aa1b2c0 user: Keir Fraser <keir.fraser@citrix.com> date: Fri Dec 14 11:58:37 2007 +0000 summary: hvm: Remove duplicate assignment of __HYPERVISOR_grant_table_op in Has broken our HVM PV drivers. Previously we were using: 520 if ((HYPERVISOR_grant_table_op(GNTTABOP_setup_table, pset, 1) != 0) || 521

Hello, I must be missing something very very basic. Because I am having trouble launching some vm''s that I recently built whereas I don''t have any problem at all launching some older images I made in very much the same way! First there is vm01 which works just fine: [root@lcent5-1:/etc/xen]$:xm create vm01 Using config file "./vm01". Started domain vm01