similar to: [PATCH] New APIs: set-network and get-network to enable network support.

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

Change 4963be85 re-introduced networking to the appliance, but didn't configure the custom network the appliance expects since we switched to link local addressing. This patch configures QEMU to use the custom network again. --- src/launch.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name:

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 also changes the name of the "vmchannel" buffer to just "buf", reflecting the fact that it's just used as a temporary buffer, and that the word vmchannel is overloaded. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages.

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.

More comprehensive support for virtio-scsi. Passes all the tests. Rich.

Hi All, I''ve got an interoffice IPSEC VPN in place that I''m trying to give priority to terminal service (tcp 3389) traffic. I''ve created rules at each end, but have hit a bit of a dillemma. As the data is encrypted I must also give highest priority to protocol 50 otherwise the priority is lost as the packet gets encrypted. When I do this however, I can''t

On Thu, 2003-01-02 at 10:48, David Wheeler wrote: > > > Unfortunately, an Ogg file can (and will) contain different codecs in > > the same file. Imagine a file that contains two chained groups of > > multiplexed bitstreams. The first group contains vorbis, vp3, speex, and > > subtitle streams. The second group contains FLAC, MNG, and MIDI streams. > > [The fact

On Thu, 2003-01-02 at 10:48, David Wheeler wrote: > > > Unfortunately, an Ogg file can (and will) contain different codecs in > > the same file. Imagine a file that contains two chained groups of > > multiplexed bitstreams. The first group contains vorbis, vp3, speex, and > > subtitle streams. The second group contains FLAC, MNG, and MIDI streams. > > [The fact

v1 was here: https://www.redhat.com/archives/libguestfs/2013-August/msg00005.html This now works, to some extent. The main problem now is that devices are named /dev/ubd[a-] which of course confuses everything. I'm thinking it may be easier to add a udev rule to rename them. Rich.

This is a User-Mode Linux backend for libguestfs. You can select it by doing: export LIBGUESTFS_BACKEND=uml export LIBGUESTFS_QEMU=/path/to/vmlinux Note we're reusing the 'qemu' variable in the handle for convenience. QEmu is not involved when using the UML backend. This almost works. UML itself crashes when the daemon tries to connect to the serial port. I suspect it's

Currently we have an OCaml library for generating the qemu command line (used only by ‘virt-v2v -o qemu’). However we also generate a qemu command line in ‘lib/launch-direct.c’, and we might in future need to generate a ‘-readconfig’-compatible configuration file if we want to go beyond 10,000 drives for scalability testing. Therefore this patch series reimplements the qemu command line code as

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.

This patch series lets you run the daemon under valgrind. Many errors were found and fixed. With the complete series applied, valgrind doesn't show any errors.

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 -

The latter is a better way to disable the qemu display output as we need to, without enabling extra devices (which are disabled already, anyway). Also, related to the change above, ban the -display parameter from the ones that can be supplied by the user. --- configure.ac | 8 ++++---- src/launch-direct.c | 12 ++++++++---- src/launch.c | 1 + 3 files changed, 13 insertions(+), 8

[Moving this thread over to the public mailing list] On Mon, Dec 02, 2013 at 01:17:09AM +0100, Pino Toscano wrote: > On Friday 29 November 2013 18:53:38 you wrote: > > > > I'm marking options with NONE (not used at all), or M (used in > > > > master) and/or RH7 (used in rhel-7.0). > > > > > > > > > * -nographic > > > > >

Hi All, I am running on CentOS Released 6.1 final. Been using and running Linux KVM quite well for quite some time, something goes wrong after I perform yum upgrade. I created new VM yesterday without any problem, same exact installation procedure, installed FreeBSD 8.2. I tried to create a new VM today after yum upgrade, it's able to detect the hard disk, when I start commit FreeBSD 8.2

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