similar to: problem about changing state to XenbusStateClosed resulting in vbd entry removed from xenstore

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

tail /var/log/xen/xen-hotplug.log xenstore-read: couldn't read path backend/vbd/6/768/node /etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=: unary operator expected /etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=: unary operator expected xenstore-read: couldn't read path backend/vbd/6/5632/node xenstore-read: couldn't read path backend/vbd/6/768/node

$ git checkout RELEASE-4.2.2 $ git clean -ffdx [do a build, install, reboot] $ xl create a0 $ xl cd-eject a0 hdc [However, the guest OS still sees the CD inserted] $ xl block-list a0 Segmentation fault $ xl cd-insert a0 hdc file:/images/xs-tools-6.0.0.iso Segmentation fault The problem seems to be that xl cd-eject is writing corrupt values to xenstore. Note that vbd/1/5632 is still there

Package: xcp-xapi Version: 1.3.2-6 Severity: normal Tags: upstream vbd plug to PV domain cause following error: The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: the device disappeared from xenstore (frontend (domid=4 | kind=vbd | devid=51760); backend (domid=0 | kind=vbd | devid=51760)) (same error

After a few times of building xen by source, I can''t start domU anyway. I tried "yum erase xen kernel-xen" and "yum install xen kernel-xen" again, but the problem is still exist. There are xenstore-write errors in /var/log/xen/xen-hotplug.log: xenstore-write: could not write path backend/vbd/1/2050/hotplug-error xenstore-write: could not write path

Hi! Please help me. # xm create win7.hvm Using config file "./win7.hvm". Error: Device 768 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/9/768 state: 1 grep -v ^# /etc/xen/win7.hvm | grep -vx '''' kernel = "/usr/lib/xen/boot/hvmloader" builder=''hvm'' memory = 2048 name = "win7" vif = [

I''m trying to add vbd resize to GPLPV, but it doesn''t seem to work: xm block-attach w2k3test32 phy:/dev/vg-xen/virt-test-0 hdb w xenstore-read /local/domain/0/backend/vbd/377/832/sectors =44056576 lvextend --size=+1M /dev/vg-xen/virt-test-0 xenstore-read /local/domain/0/backend/vbd/377/832/sectors =44056576 The xenstore backend isn''t updated to reflect the new size

Hi, xm destroy CRASHED_DOMAIN does not cleanup the vbd nor the vif. The loopback backend is busy, so losetup -d fails. This is inconvenient, as it results in an unclean shutdown of your physical machine. Best, -- Kurt Garloff, Director SUSE Labs, Novell Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Ewan Mellor wrote: >> >> Ian Pratt wrote: >>> >>> >>>> I have been trying for days now to get a working nat setup with >> my >>>> domU''s using the default nat scripts. >>> Just look at what the demo CD does for a nice example of how to set up >>> NAT. >>> >>> Ian >>> >>

From: Ruslan Pisarev <ruslan at rpisarev.org.ua> This is a patch to the xenbus_client.c file that fixed up whitespaces, tabs errors found by the checkpatch.pl tools. Signed-off-by: Ruslan Pisarev <ruslan at rpisarev.org.ua> --- drivers/xen/xenbus/xenbus_client.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git

From: Ruslan Pisarev <ruslan at rpisarev.org.ua> This is a patch to the xenbus_client.c file that fixed up whitespaces, tabs errors found by the checkpatch.pl tools. Signed-off-by: Ruslan Pisarev <ruslan at rpisarev.org.ua> --- drivers/xen/xenbus/xenbus_client.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git

From: Ruslan Pisarev <ruslan at rpisarev.org.ua> This is a patch to the xenbus_client.c file that fixed up whitespaces, tabs errors found by the checkpatch.pl tools. Signed-off-by: Ruslan Pisarev <ruslan at rpisarev.org.ua> --- drivers/xen/xenbus/xenbus_client.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git

From: Ben Cressey <bcressey@amazon.com> The commit "minios: refactor xenbus state machine" caused "/state" to be appended to the local value of nodename. Previously the nodename variable pointed to dev->nodename. The xenbus_rm() calls were not updated to reflect this change, and refer to paths that do not exist. For example, shutdown_blkfront() for vbd 2049 would

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

This patch series introduces the tapback daemon, the user space daemon that acts as a device''s back-end, essentially most of blkback in user space. The daemon is responsible for coordinating the front-end and tapdisk. It creates tapdisk process as needed, instructs them to connect to/disconnect from the shared ring, and manages the state of the back-end. The shared ring between the

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-4 Severity: normal Rebooting from inside domU hangs in initrd: Begin: Waiting for root file system... ... Root file system is not available because underlying DRBD device got deactivated during reboot: $ cat /proc/drbd version: 8.0.13 (api:86/proto:86) GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by phil at fat-tyre, 2008-08-04

Hi all, Now I use xentop to get disk statistical information. NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 96233 0.7 3902464 23.3 no limit n/a 12 0 0 0 0 0 0 0 0 0 0 slave3

APIs such as sh_invlpg and sh_update_cr3 take a pointer to the virtual cpu on which it needs to operate as an argument. However, it appears that the call can only operate on the currently executing vcpu. Regards, K. Y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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()