similar to: Fedora 18 / Rawhide switch over to using libvirt as the back end

I'm just about to release libguestfs 1.20. This appendix covers issues specific to Fedora 18. Fedora 18 defaults to using the libvirt attach-method, meaning that libvirt is used to create and manage the libguestfs appliance. There are several benefits to this (see the full release notes). You can switch back to the ordinary method (directly running qemu) at any time by doing: export

All, Our testing seems to indicate that Qemu-1.4.0-2 and Qemu-1.4.0-1 is broken on virt-preview and rawhide. I'm getting undefined symbol: usbredirparser_send_start_bulk_receiving when running qemu-system-x86_64 -version.. Do others see this issue? Is there a known solution? Harald Failing cases:

https://bugs.freedesktop.org/show_bug.cgi?id=59474 Priority: medium Bug ID: 59474 Assignee: nouveau at lists.freedesktop.org Summary: fedora 18 X server crashes after boot QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Solaris Reporter: dax at enst.fr

I just want to bring everyone's attention this important bug in Fedora 18. It looks like people are now starting to upgrade to F18 and are hitting this bug. https://bugzilla.redhat.com/show_bug.cgi?id=912499 In brief, when virt-manager runs, it starts some libguestfs instances in the background to inspect guests. Starting with Fedora 18 these use libvirt and because of a bad interaction

Hi all. I''ve got a situation with Fedora 18 on a dual Xeon E5506 box, 16GB RAM, Tyan S7002 motherboard with the latest BIOS. Because of all the issues, I''m starting to think maybe there''s something wrong with the box itself, maybe something strange going on with the BIOS or mobo resources. Although this box was in service without incident for about 2 years prior. I

I am unable to convert a vm using virt-v2v. From the trace and debug logs I am unable to understand the cause of the problem. I assume it is a permission or configuration issue but I don't know where to start looking. The following command was issued: LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -ic qemu+ssh://xxx at 192.168.xxx.xxx/system -o rhev -os 192.168.xxx.xxx:/mnt/exports -of

On Thu, May 21, 2015 at 02:37:31PM +0100, Richard W.M. Jones wrote: > > Previous attempt: > https://www.redhat.com/archives/libguestfs/2015-April/msg00013.html > > supermin needs to download packages (eg. RPMs) when preparing the > appliance. > > After a lot of work, 'dnf download' can now be used as a replacement > for the (deprecated) 'yumdownloader'

supermin needs to download packages (eg. RPMs) when preparing the appliance. 'dnf download' finally appears to have made parallel downloads reliable[1]. Better late than never. So I have experimentally switched Rawhide's supermin to use 'dnf download' instead of the (deprecated) 'yumdownloader' program. This only affects the 'supermin --prepare' phase, which

On Tue, May 26, 2015 at 09:44:33AM +0100, Richard W.M. Jones wrote: > On Mon, May 25, 2015 at 10:22:35PM +0200, Kashyap Chamarthy wrote: > > I just built `supermin` from source on my Fedora 22 machine, and somehow > > it can't seem to detect RPM (but `supermin` from Rawhide detects it). > > Exact error: > > > > supermin: could not detect package manager

On Mon, May 25, 2015 at 10:22:35PM +0200, Kashyap Chamarthy wrote: > I just built `supermin` from source on my Fedora 22 machine, and somehow > it can't seem to detect RPM (but `supermin` from Rawhide detects it). > Exact error: > > supermin: could not detect package manager used by this system or > distro. > > which is coming from:

Previous attempt: https://www.redhat.com/archives/libguestfs/2015-April/msg00013.html supermin needs to download packages (eg. RPMs) when preparing the appliance. After a lot of work, 'dnf download' can now be used as a replacement for the (deprecated) 'yumdownloader' program. This only affects the 'supermin --prepare' phase, which means it only affects people building

On 04/03/2013 10:25 AM, yue wrote: > > hi,all > > i know svirt is merged into libvirt upstream, but how to use them? > You had better to ask this kind of question to libvirt-users at redhat.com in the future, it's a user mail listing, you may ask all kind of libvirt usage questions if you want, the following is some reference:

Btrfs has been broken for me for ages. I first reported it on this list 5 months ago[1]. Below is a very simple reproducer that anyone can run. *NB* before you run this, adjust /dev/sda & /dev/sda1 to point to an unused block device! ---------------------------------------------------------------------- #!/bin/sh - set -e while true; do parted -s -- /dev/sda mklabel msdos parted -s --

?Hi, ?I've installed libvirt-0.9.13 on RHEL6.2 from the source code. I cannot make sVirt working with LXC. (sVirt works well with KVM, though.) I can start an LXC instance, but the label of the process is not right. Can someone help me? I tried to change /etc/libvirtd/lxc.conf file to explicitly enable security_driver = "selinux". But it ends up with error saying "error :

I have an older quad-core AMD processor that supports hardware virtualization on a motherboard that does not support it in the bios. Eventually I'll swap the mobo out on this box for one that will support hardware virtualization and use qemu-kvm. I prefer kvm because of SELinux and sVirt that protects the host from VM breakout should a VM become hostile. In the meantime, I want to start work

Hello, I have a simple C program that uses libguestfs to extract info about disk usage from a libvirt domain. It works when ran manually as root, but fails when started as a systemd service. I'm attaching the service file, source code and verbose logs from both the successful manual run and from the service journal. SELinix is disabled. Error messages: libguestfs:

http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=0001-Workaround-for-usrmove-in-Fedora.patch;hb=HEAD I have added this patch (not upstream) ^^ This is a workaround for a rather misguided feature called 'usrmove' which was just dumped without notice into Rawhide, 3 days before the F17 branch, while everyone was away at FOSDEM. I still haven't got libguestfs to build

Creating a btrfs file system using btrfs-progs-0.20.rc1.20130308git704a08c-1.fc19, and either kernel 3.6.10-4.fc18 or 3.9.0-0.rc3.git0.3.fc19, makes a file system that cannot be mounted by kernel 3.6.10-4.fc18. It can be mounted by kernel 3.8.4. I haven''t tested any other 3.8, or any 3.7 kernels. Is this expected? dmesg reports: [ 300.014764] btrfs: disk space caching is enabled [

https://bugs.freedesktop.org/show_bug.cgi?id=36512 Summary: Xorg Beta 1.10.99.1 - Provided by Fedora - Rawhide Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

Fedora rawhide now builds on ARM as well as 32-bit and 64-bit x86, and while the x86 builds are successful, the ARM build is failing. I was able to fix the first problem, which was reported in a Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715424 However, there are further build errors for which I haven't found appropriate fixes. It looks like there might be a namespace