search for: osdeps

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

Hi Bastian, I'd like to propose backporting the following changesets from upstream xen-unstable into the xen-3 package. With these it is possible to boot a default installation of Squeeze (using d-i) in a domU using pygrub. 20480:c2c2e67b8198 pygrub: if default entry is "saved" then use first entry. 20481:8f4e0adc2b3b pygrub: expands tabs before displaying menus. 20485:086a6a0c3f37

After install of update snv_101b the xend daemon dosn''t start any more. This is what I saw in the xend.log file [2008-11-22 10:58:59 572] INFO (SrvDaemon:334) Xend Daemon started [2008-11-22 10:58:59 572] INFO (SrvDaemon:338) Xend changeset: Mon Oct 13 22:14:51 2008 -0700 15904:94bd0a643efe. [2008-11-22 10:58:59 572] INFO (SrvDaemon:345) Xend version: Unknown. [2008-11-22 10:58:59 572]

The pvops dom0 kernel does not expose the balloon driver via /proc/xen, so use the sysfs interface. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r 1944c39d0007 tools/python/xen/xend/osdep.py --- a/tools/python/xen/xend/osdep.py Fri Nov 14 09:57:33 2008 -0800 +++ b/tools/python/xen/xend/osdep.py Fri Nov 14 12:26:51 2008 -0800 @@ -38,7 +38,10 @@

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

* Introduce new variants of the logging functions which include errno values (converted using strerror) in the messages passed to the application''s logging callback. * Use the new errno-including logging functions everywhere where appropriate. In general, xc_... functions return errno values or 0; xs_... functions return 0 or -1 (or some such) setting errno. * When

...e > -I../../tools/blktap2/control -I../../tools/blktap2/include -I../../tools/include > -Wl,-soname -Wl,libxenlight.so.1.0 -shared -o libxenlight.so.1.0.0 flexarray.o > libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o > libxl_internal.o xenguest.o libxl_utils.o osdeps.o libxl_paths.o > libxl_bootloader.o libxl_blktap2.o > /usr/bin/ld: libxl_dom.o: relocation R_X86_64_PC32 against > `hvm_build_set_params'' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: ld return...

On 04/27/2011 04:23 AM, Niccol? Belli wrote: > Hi, I backported xen-4.1-2 to Squeeze, but when I try to build > xen-qemu-dm-4.0 against it, it doesn't build. > Can you please help me? I attached log file. > > Niccol? Hi, To me, this looks like an issue with libxen-dev. The file /usr/include/xenctrl.h is the one to blame in your build log... Please write to the pkg-xen list

This is on top of Paolo and Nick's work. Current status: Works now (guest boots fine, no hang any more) with seabios's virtio-scsi disabled. Rebased to latest qemu.org/master Change details are in commit log. TODO: Make seabios happy. Paolo Bonzini (2): virtio-scsi: create VirtIOSCSICommon vhost-scsi: new device supporting the tcm_vhost Linux kernel module hw/Makefile.objs

This is on top of Paolo and Nick's work. Current status: Works now (guest boots fine, no hang any more) with seabios's virtio-scsi disabled. Rebased to latest qemu.org/master Change details are in commit log. TODO: Make seabios happy. Paolo Bonzini (2): virtio-scsi: create VirtIOSCSICommon vhost-scsi: new device supporting the tcm_vhost Linux kernel module hw/Makefile.objs

Hi, I am currently using the L2 tunnel feature of ssh between two Linux machines, and it works beautifully! As a result, I have come to prefer a workflow that uses an L2 tunnel, but I can't seem to find a long-term solution for this workflow on macOS. At the moment, tap devices on macOS can be generated using a kernel extension like tuntaposx <http://tuntaposx.sourceforge.net/>;

Hello all: > We operate in an environment where we might sometimes wish to do > certain tasks based solely upon the MAJOR version number of an OS > release, disregarding the minor portion of the version number. For > instance, CentOS 4.0 through 4.5 would all be ''CentOS 4'' to some > scripts, and CentOS 5.0 and greater would all be ''CentOS 5''.

Hi! Just in case somebody else needs this. Below is a patch which allows building qemu-kvm-0.15 unter CentOS 5.6 with vanilla kernel 2.6.35.14 and (optionally) vde2 [1]. FYI: qemu-kvm-0.15 compiles fine on CentOS 6 with distro-kernel, no patches needed. For CentOS 5.6, unpack 0.15 qemu-kvm tarball [2], apply the path below, configure and compile. Make sure to export the kernel include path

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi QEMU folks, The following is the patch series to support vhost-scsi-pci within the upstream QEMU tree. This includes the refactoring of existing virtio-scsi code from Paolo to allow a VirtIOSCSICommon structure that is shared amoungst existing virtio-scsi-pci device and new vhost-scsi-pci device code. Currently this code requires

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi QEMU folks, The following is the patch series to support vhost-scsi-pci within the upstream QEMU tree. This includes the refactoring of existing virtio-scsi code from Paolo to allow a VirtIOSCSICommon structure that is shared amoungst existing virtio-scsi-pci device and new vhost-scsi-pci device code. Currently this code requires

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi QEMU folks, The following is the patch-v2 series to support vhost-scsi-pci within the upstream QEMU tree. This includes the refactoring of existing virtio-scsi code from Paolo to allow a VirtIOSCSICommon structure that is shared amoungst existing virtio-scsi-pci device and new vhost-scsi-pci device code. Currently this code requires

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi QEMU folks, The following is the patch-v2 series to support vhost-scsi-pci within the upstream QEMU tree. This includes the refactoring of existing virtio-scsi code from Paolo to allow a VirtIOSCSICommon structure that is shared amoungst existing virtio-scsi-pci device and new vhost-scsi-pci device code. Currently this code requires

This is on top of Paolo and Nick's work. Current status: Basically, tcm_vhost + seabios works now. We still have one more issue, vhost_verify_ring_mappings fails. The hotplug also works with the latest tcm_vhost.ko hotplug patch. Asias He (1): disable vhost_verify_ring_mappings check Paolo Bonzini (2): virtio-scsi: create VirtIOSCSICommon vhost-scsi: new device supporting the

This is on top of Paolo and Nick's work. Current status: Basically, tcm_vhost + seabios works now. We still have one more issue, vhost_verify_ring_mappings fails. The hotplug also works with the latest tcm_vhost.ko hotplug patch. Asias He (1): disable vhost_verify_ring_mappings check Paolo Bonzini (2): virtio-scsi: create VirtIOSCSICommon vhost-scsi: new device supporting the

Signed-off-by: Yuval Shaia <yuval.shaia at oracle.com> --- hw/Kconfig | 1 + hw/rdma/Kconfig | 4 + hw/rdma/Makefile.objs | 2 + hw/rdma/virtio/virtio-rdma-ib.c | 287 ++++++++++++++++++++ hw/rdma/virtio/virtio-rdma-ib.h | 93 +++++++ hw/rdma/virtio/virtio-rdma-main.c