similar to: [PATCH] Enable new-style -chardev ... guestfwd command line

This patch is in preparation for allowing libguestfs to use alternate "vmchannel" implementations. Although it's not a functional change, I think it is worthwhile on its own because use of the term "vmchannel" in the names of constants is inappropriate since (a) the "-net channel" option is now properly known upstream as "guestfwd", and (b) no one can

This attempts to implement the idea proposed in https://www.redhat.com/archives/libguestfs/2010-April/msg00087.html The idea is that an externally managed QEMU (manual, or via libvirt) can boot the appliance kernel/initrd. libguestfs can then be just told of the UNIX domain socket associated with the guest daemon. An example based on guestfish. 1. Step one, find the appliance kernel/initrd

This set of 10 patches removes the need for any vmchannel implementation, although we can still choose to use vmchannel if we want. In this so-called "null vmchannel" configuration, the appliance connects directly to a port on the library. The exact method is described in patch 9/10. This method still requires SLIRP (user mode networking) so it is not a panacea, because recent

Couple of notes: (1) You may need to 'make clean' after applying this patch. There is some missing dep so it seems the appliance isn't fully rebuilt. (2) [Comment mainly directed to Matt] This is not a candidate to be automatically added to the stable 1.2 branch. It's far too large of a change for a stable release. Since this change may be required for V2V, please clone

The change to "null vmchannel" didn't get reflected in the configure script which still checks for vmchannel in qemu. This patch tidies up this part of the configure script so we don't fail, provided we have support for user mode networking (which is required for null vmchannel). This patch didn't make it into 1.0.71. Rich. -- Richard Jones, Emerging Technologies, Red

Hi all. Having trouble figuring out the magic to set up VMChannel comms between EL6.x host/guests. My end goal is to enable fence_virt in the guest to talk to fence_virtd on the host via VMChannel. I'd prefer to use that instead of multicast because it is supposed to work even if networking in the guest is down/borked. My analysis is that there is a mismatch between what libvirt is feeding

There is a need for communication channel between host and various agents that are running inside a VM guest. The channel will be used for statistic gathering, logging, cut & paste, host screen resolution changes notifications, guest configuration etc. It is undesirable to use TCP/IP for this purpose since network connectivity may not exist between host and guest and if it exists the traffic

There is a need for communication channel between host and various agents that are running inside a VM guest. The channel will be used for statistic gathering, logging, cut & paste, host screen resolution changes notifications, guest configuration etc. It is undesirable to use TCP/IP for this purpose since network connectivity may not exist between host and guest and if it exists the traffic

There's a new syntax check rule from gnulib. It requires that you write e.g., exit (EXIT_SUCCESS), not exit (0). And the same for 1/EXIT_FAILURE and any other constants. There were a lot of violations, including a few false positives, so I started with the exemptions (see the .x-sc file below). Then I converted the vast majority automatically, with this: maint: use EXIT_SUCCESS and

I'm pleased to announce the release of libguestfs 1.0.64, the library for accessing and modifying virtual machine disk images. Homepage: http://libguestfs.org/ Downloads: http://libguestfs.org/download/ Git repo: http://git.et.redhat.com/?p=libguestfs.git Fedora builds: http://koji.fedoraproject.org/koji/packageinfo?packageID=8391 NOTE at present there is a bug in qemu's

Hello, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

Hello, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

On Mon, Mar 22, 2010 at 02:56:47PM +0100, Ingo Molnar wrote: > Just curious: any plans to extend this to include live read/write access as > well? > > I.e. to have the 'agent' (guestfsd) running universally, so that > tools such as perf and by users could rely on the VFS integration as > well, not just disaster recovery tools? Totally. That's not to say there is a

v2 -> v3: - Rebase on top of the other patches. Rich.

NOTE: not for upstream, yet. v1 -> v2: - Remove the dependency on enabling ACPI, since ACPI is now enabled all the time. Rich.

Tested with 'make check-release'. tests/parallel (in check-slow) failed, although it does regularly and that seems to be because of libvirt. Rich.

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

On Sun, Sep 28, 2014 at 6:26 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Sun, Sep 28, 2014 at 04:30:37PM +0800, Zhi Yong Wu wrote: >> HI, >> >> On a RHEL5 box, i tried to directly run guest which was issued by >> libguestfs virt-xxx commands as below. But after some minutes, it >> exited exceptionally. >> >> Does anyone also hit the

virtio-scsi has been supported in qemu since 2012, and it is superior in every respect to virtio-blk. There's no reason to still be using virtio-blk. virtio-scsi support was initially added in 2012 (commit 0c0a7d0d868d153adf0600189f771459e1068b0a). You can still use virtio-blk using the (deprecated) iface parameter, but don't do that in new code. --- lib/guestfs-internal.h | 1 -

These assorted patches end up with adding virtio-scsi support to libguestfs. It passes libguestfs-test-tool, but I haven't yet tried to run the full set of tests. In theory > 26 devices can be added, but it's likely that certain parts of the daemon will break if you actually try this. This of course needs to be fixed. Thanks Paolo Bonzini for invaluable help. Rich.