similar to: [PATCH] network-script: use default network device

This seems exceptionally evil and is definitely a PITA. What was the original problem that led us to do this? I''d like to take a stab at correcting it so we can have a more sane installation. Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Attached patch fixes a problem in marshaling large integers. It seems to only occur on systems with very large memory. However, on those systems, it''s a show-stopper. I see this as a temporary solution until we can sanitize the XML-RPC functions and get rid of all the S-Expression stuff. I''ll run xm-test tomorrow against it. Right now I''ve only done basic

I have problem to start domU with errors: # xm create -c x335-hien1-vm4.cfg Using config file "x335-hien1-vm4.cfg". Error: Device 0 (vif) could not be connected. Hotplug scripts not working in changeset: changeset: 7700:98bcd8fbd5e36662c10becdcd0222a22161bb2b6 tag: tip user: kaf24@firebug.cl.cam.ac.uk date: Tue Nov 8 09:48:42 2005 summary: Fix alloc_skb()

> -----Original Message----- > From: Ewan Mellor [mailto:ewan@xensource.com] > Sent: Tuesday, December 06, 2005 5:25 AM > To: Dave Thompson (davetho) > Cc: Xen Mailing List > Subject: Re: [Xen-devel] Hotplug scripts not working... > xen/ia64 domU stoppedworking > > On Mon, Dec 05, 2005 at 03:03:54PM -0500, Dave Thompson > (davetho) wrote: > > > >

The network-bridge script is fragile because of how grep is used. As one example, if I already have "xenbridge", I can''t create "xenbr". (It''s actually worse than that, because it''s even grepping the header output by brctl show.) Assuming dom0 is on Linux with /sys mounted (is that a safe assumption?) we can check for the existence of a bridge, and

Yes, I saw that problem and removing the vif line or changing it to vif0 fixed it for me. Aravindh > -----Original Message----- > From: wei huang [mailto:huanwei@cse.ohio-state.edu] > Sent: Friday, November 04, 2005 12:14 PM > To: Puthiyaparambil, Aravindh > Cc: Mark Williamson; xen-users@lists.xensource.com; ewan@xensource.com > Subject: RE: [Xen-users] Error "Device 0

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

http://bugs.freedesktop.org/show_bug.cgi?id=21023 Summary: NV34GL: fails to properly set up DVI Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1306311631 -3600 # Node ID 6b1fe0cba8a2f0bcc1274c8e777da5b6c198b45d # Parent 8258c5a0ba35de937597e2c516bc88f8ebe1be35 libxl: use preferred syntax for network device creation with upstream qemu Markus Armbruster points out in <m3r582pzc1.fsf@blackfin.pond.sub.org> on qemu-devel that this is the prefered syntax

We have test latest xen (ChangeSet 7608) on VT platform with Intel 915 chipset and Here is the test summary: IA32: Build&Boot SMP xen0 without problem Can startup XenU with different configuration IA32 issues contain: VMX can not be created IA32E: Build&Boot SMP xen0 without problem Can startup XenU with different configuration IA32E issues

After upgrading to 3.0.2 I tried rebooting a domU (a problem sometimes in 3.0.1 related to bug 514) it failed to come back up. This was in my xend.log. ("Refusing to restart to avoid loops." .... ) [2006-04-11 20:53:39 xend.XendDomainInfo] DEBUG (__init__:988) Storing domain details: {''console/ring-ref'': ''223144'', ''console/port'':

Some time in the last few dozen changesets (I''m at 13662:5bb084098493 now) I''ve started getting this error on xm create: [2007-01-29 12:23:41 7373] ERROR (__init__:1072) (13, ''Permission denied'') Traceback (most recent call last): File "/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/Xen dDomain.py", line 1364, in

I noticed that the changesets around 7378:bd3268de4145 introduced the xen_domain_handle_t param to xc_create_domain(), the struct domain, etc. and call it a "tool UUID". Can someone explain how this is envisioned being used (xend sets it to some magic values but I don''t see it get used anywhere)? Joe _______________________________________________ Xen-devel mailing list

This patch -Displays[1] current parameters for running domains ala xm list -Allow users to set[2] one or more parameters[3] without having to provide values for parameters they do not wish to change -Adds additional testing of sched-sedf via new xm-test testcases. With this patch applied, test 02_sedf_period_lower_neg.py exposes a bug[4]. I''ll follow up this email with a patch for

This patch causes "xm mem-set" to be lower bound on domX-min-mem option in xend-config. Another configuration option called domU-min-mem has been introduced, which works similarly to dom0-min-mem. This is prevents users from freezing the system when doing "xm mem-set" on very low values like 32M. Signed-off-by: Aravindh Puthiyaparambil

Hi, Xm list and xm vcpu-list show wrong DomID(name). Under this situation, # xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 512 1 r----- 1064.6 test1 13 64 1 r----- 83879.7 # xm list 1 13 Error: Domain ''1'' not found when running ''xm list'' # xm list

If I understand correctly, a HVM domain''s network adapter gets a tapX device created for it in Dom0 for qemu to talk to, and a vifY.Z device for the PV drivers (which probably aren''t there) to talk to. How can I stop the qemu code creating the virtual Realtek driver? What will happen if I try and use PV and Realtek drivers at the same time? Will the Realtek driver just talk to

With sles 10, ''make tools'' produces the following: CFLAGS="-O2 -fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_INTERFACE_VERSION__=0x00030101" python setup.py install --home="/root/xen/xen-unstable.hg/dist/install/usr" --force running install error: must supply either home or prefix/exec-prefix --

Since CPP is being used with CFLAGS, it should be in lock-step with CC, to avoid having to specify both CC and CPP for the build. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-03-19/config/StdGNU.mk =================================================================== --- 2007-03-19.orig/config/StdGNU.mk 2007-03-08 09:37:32.000000000 +0100 +++ 2007-03-19/config/StdGNU.mk