similar to: Send data from hypervisor to Dom0?

Package: xen-hypervisor-4.3-amd64 Version: 4.3.0-3+b1 Severity: critical File: xen-hypervisor-4.3-amd Justification: breaks the whole system Dear Maintainer, Installation is a minimal system designed only to get dom0 working. The following are the uncommented GRUB commands GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

I am running a 64 bit dom0 with a stock Debian Squeeze xen hypervisor and kernel. On top of this I am running a PV 32 bit domU that is passed two PCI network cards. This set-up had been working well for over a year, however there was a recent hypervisor update so I rebooted the dom0. Unfortunately now the domU that is being passed the two NICs is no longer able to create a PPPoe connection to

Package: xen-hypervisor-3.4-i386 Version: 3.4.3~rc3-2 Severity: important Tags: sid After booting into the xen kernel, xm cannot run because xend is not running (the sysfs hypervisor is not populated) # dpkg -l | grep xen ii libc6-xen 2.10.2-6 GNU C Library: Shared libraries [Xen version] ii libxenstore3.0

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-5.2 Hi, We're seeing weird behaviour regarding network traffic between a Xen dom0 and domU. I reported this issue yesterday to the openvswitch-discuss mailing list, but it seems this could also be a (regression?) bug in the xen hypervisor or the linux kernel... (we've upgraded xen-hypervisor-4.0-amd64 4.0.1-4 -> 4.0.1-5.2 and

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: normal Because my networking was getting rather complex I cloned my firewall/net server as domU/dom0 to offload some services to the domU. I use bridged networking with the domU virtual adaptor connected to the internal ethernet interface used to provide services (which is normally the single port of the bridge). When I attempt to

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-4 Severity: normal Xen Networking[1] works by creating a new pair of virtual ethernet interfaces (vifN.M in dom0 and ethM in domU with id N) and connecting then by an internal "crossover ethernet cable". My understanding of the "internal crossover" thing is that networking statistics should be the same no matter if you measure

Hi, I have a question about the memory layout of the Xen hypervisor, dom0 and domU. *The goal I want to achieve is: I want to show which RAM area is used by hypervisor, which RAM area is used by dom0, which RAM area is used by each domU (PV guest domain). I hope to know the above information when xen is booted as well as when xen is running some domUs. I already know that we can dedicate a fix

Package: src:xen Severity: important Version: 4.1.3~rc1+hg-20120614.a9c0a89c08f2-2 I recently upgrade from Squeeze to Wheezy on a system which had the xen-linux-system-686-pae metapackage (one of two which Provides: xen-linux-system). After dist-upgrade I had the new xen-utils-common and xenstore-utils (and a few others) but not the xen-utils-4.1 or xen-hypervisor-4.1-i386 or xen-hypervisor-amd64

Package: xen Version: 4.0.1-5.5 Severity: critical --- Please enter the report below this line. --- Hi! Since the update last weekind in stable/squeeze I'm experiencing problems with running Xen on amd64 and multiple domUs losing their network connection/VIFs. From http://blog.windfluechter.net/content/blog/2013/02/26/1597-xen-problems-vms-2632-5-xen-amd64 Unfortunately this update

retitle Traffic forwarding issue between Xen domU/dom0 thanks This week again this bug occurred again so we are trying to create some kind of reproduce algorithm. First we've created two virtual machines named koekiemonster.bofh.hq.mendix.net and netappsim.bofh.hq.mendix.net. We've added 29 vifs to koekiemonster.bofh.hq.mendix.net. During this tests we've always had a ping

Package: xen-hypervisor-4.1-amd64 Version: 4.1.3-7 Severity: important Tags: patch Dear Maintainer, The PMU may be enabled on the Dom0 although the needed MSRs are not accessible, causing at least major noise on the xen messages ring buffer. I suspect there might also be a performance decrease, because the MSR write is trapped by Xen. Once the PC is in that state, a reboot won't help. This

Processing commands for control at bugs.debian.org: > retitle 773561 /etc/init.d/xen fails when run in a nested L1 hypervisor dom0 (Xen on Xen) Bug #773561 [xen-utils-common] /etc/init.d/xen fails when run in a guest, causing postinst to fail. Changed Bug title to '/etc/init.d/xen fails when run in a nested L1 hypervisor dom0 (Xen on Xen)' from '/etc/init.d/xen fails when run in a

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-5.2 Severity: important Tags: patch I have a system based on a Supermicro X8DTH-i motherboard and a Xeon E5506 CPU. It was previously running Debian lenny with xen-hypervisor-3.2-1-amd64 / linux-image-2.6.26-2-xen-amd64 without incident. I upgraded it to Debian squeeze, with xen-hypervisor-4.0-amd64 / linux-image-2.6.32-5-xen-amd64 and now it does

Package: xen-hypervisor-4.3-amd64 Version: 4.3.0-3+b1 Severity: normal Dear Maintainer, After booting into kernel 3.13 dom0, the keyboard no longer works. All other aspects work, ssh is needed to login to the system to start working with the domU's. They keyboard works at the grub menu just fine, and works normal when booting into the non xen kernel. -- System Information: Debian Release:

Package: xen-hypervisor-3.0.3-1-i386 Version: 3.0.3-0-1 Severity: normal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, When you have a HVM domain running, if you try to boot a regular paravirtualized domain, dom0 (or maybe the hypervisor) crashes immediately (reboot). The opposite (trying to boot a HVM domain while a regular paravirtualized domain is running) crashes the system as well. I

Package: xen-hypervisor-3.0-unstable-1-i386 Version: 3.0-unstable+hg11561-1 Severity: important I've installed xen-linux-system-2.6.17-2-xen-k7 (version 2.6.17-9) on a server, and planned to run 3 Xen domUs on it. Creating the domUs was no problem, and running two of them works well. Starting the third one however will crash the dom0 and forces it to reboot. The machine is a Athlon64 3800+

Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.0-5 Severity: important The hypervisor loads OK but then fails to load my dom0 kernel. I get an erorr message "not an ELF binary" followed after 5s by a hypervisor reboot. /boot/grub/grub.cfg contains: menuentry "Debian GNU/Linux, Xen 3.2-1-amd64, Linux 2.6.22-3-vserver-amd64 (single-user mode)" { set root=(hd0,1)

Package: xen-hypervisor-3.0.3-1-i386 Version: 3.0.3-0-2 Severity: important When I try to start a domU with more than 6 vdb it crash. The first time the vm does not launch and aparently wait for the loop device creation (some scripts/block add, udev --daemon and sleep 1 process running). And nothing happen until I Ctrl+C the xm create. My loop module is loaded with 64 loops. After this first

On Thu, 2005-06-16 at 06:17 +0100, Keir Fraser wrote: > > I suggested that we simply mmap /dev/kmem for the xenstored to access > > the domain0 page for the moment. That doesn''t work: we''ll do something > > else. > > Just use xc_map_foreign_range(), as you would for mapping any other > domain''s xenstore page. So here''s my patch

Package: xen-utils-4.1 Version: 4.1.3-4 Severity: important Tags: patch Bug presented in sid, with patch attached. Similar bug is also present in stable and testing versions. How to reproduce: Install xen-utils-4.1 in a domU, and run: /etc/init.d/xen start Expected result: xenstored running (or to have any other easy way to get it running within a domU) xenstored is not just something