The idea was discussed here before, so I'll keep this short.
We've set up a repository for people running Fedora 11 who would like
to test the rawhide/F12 virt packages. To use it, do e.g.
$> cat > /etc/yum.repos.d/fedora-virt-preview.repo << EOF
name=Virtualization Rawhide for Fedora 11
$> yum update
At the moment, it contains the F-12 versions of libvirt and qemu, but
as F-12 development continues, it will contain more. I'll send periodic
mails to the list detailing the latest updates.
Also, this is very much a work-in-progress. The TODO list includes:
- get createrepo installed on fedorapeople.org
- include debuginfo packages in the repo (need more quota)
- find a better location than markmc.fedorapeople.org
- enable package builders to upload directly to the repo
- automatically do preview build/upload for devel/ builds
- allow building against preview packages; e.g. for language bindings
Comments most welcome. Help with the TODO list is even more welcome :-)
 - https://www.redhat.com/archives/fedora-virt/2009-April/msg00154.html
I have built a new set of kernel packages based on fedora rawhide
kernels and the xen/dom0/hackery branch of Jeremy's git repository
( http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=summary ).
This batch (kernel-2.6.29-0.114.2.6.rc6.fc11) is available via the koji
build system at
These are really for development and debugging purposes only, as I am
still having problems getting them to boot, but others have reported more
success at getting kernels based on this git repository working, so you
might be lucky.
Note to install these packages on Fedora 10 you will need to have
rpm-4.6.0-1.fc10 installed (currently in updates-testing but it should be
available in updates soon) because of the change to SHA-256 file digest
hashing in recent Fedora 11 builds.
I've used a lot of time trying to get my custom Xen pv_ops dom0 kernel working with
virt-install and/or virt-manager on Fedora 10, and now it seems I got things
If you want to play with this you need:
1) New enough pv_ops dom0 kernel (2.6.29-rc8 or newer) so it has /sys/hypervisor support included
- Compile with CONFIG_HIGHPTE=n since it seems to be broken still
2) libvirt 0.6.1 and related packages from Fedora 10 updates-testing
In addition to those I'm using Xen 3.3.1-9 packages from rawhide/F11 rebuilt for F10.
With the older Fedora 10 libvirt packages libvirtd was crashing often for me, and
I had some other issues with virt-install console window not opening but stalling etc..
Today I was able to run the following on Fedora 10 32bit PAE pv_ops dom0:
- CentOS 5.3 32bit PAE PV domU
- Fedora 10 32bit PAE PV domU
- Use virt-install to install Fedora 10 32bit PAE PV domU (using custom kickstart
to force PAE kernel installation to avoid the anaconda BUG which installs
wrong non-PAE kernel as a default).
Fedora 11 (rawhide) installation most probably works too.
I'm using LVM volumes for domU disks (tap:aio is not yet supported by pv_ops
Network seems to work after running "ifdown eth0 && ifup eth0"
on the guest.. dunno why that's needed. That's something to figure out later:)
Graphical domU console works with virt-viewer and virt-install during installation.
- virt-manager complains about default network (virbr0) being inactive and
asks if I want to start it. If I click Yes, then I get error: "libvirtError: cannot create bridge 'virbr0': File exists"
virbr0 works just fine with virt-install. So dunno what's the problem with that..
have to look into that later.
Thanks to everyone involved for helping me with this!
I'm trying to upgrade kernel packages via libguestfs -- but grubby and
mkinitrd don't deal well at all with having a less-than-fully-populated
/dev, either failing to operate at all or producing an initrd with LVM
Before I spend too much more time on this one -- any hints or recipes?
This is virt-inspector-1.0.34-1.3 on CentOS 5:
$ virt-inspector --ro-fish --xml da.qcow2
qemu: loading initrd (0x33a576d bytes) at 0x0000000014c4a000
umount_all: guestfs_umount_all: call launch() before using this function
at /usr/bin/virt-inspector line 375.
I have a trouble when build virt-p2v-0.9.9.tar.gz to generate an iso file. Search for help
I have install all the packet that virt-p2v depend on, and i run the follow commands successfully
But when i enter "make build" command, wait minutes, i got the follow error:
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
Error creating Live CD : Unable to download from repo : Cannot retrieve repository metadata (repomd.xml) for repository: released. Please verify its path and try again
make: *** [build] error 1
Could anyone tell me where it want to get repository metadata , and which tools or command it use to get?
Research Department, CPD
Huawei Technologies Co., Ltd.
I have a rather large set of RPMs and such on my host I want to install
on my guest using libguestfs. The normal way to do this would be to
upload the package(s), install them, then (optionally) remove the RPMs.
However, I don't particularly want to bloat the qcow2 file with the
changes made via uploading files which are only going to be deleted when
no longer in use. Someday (*sigh*) we'll have 9p-over-virtio support
built into qemu; until then, a few ways to get around this present
- Add a temporary file as a disk to the guestfs session on startup;
within the guest, create a new filesystem there, transfer temporary
files to it, and delete when done.
Pro: No external dependencies.
Con: Not sure of a safe and correct way to find the name of the
temporary disk [to ensure that the mkfs operation being scripted refers
only to it], particularly when trying to script everything into a single
guestfish invocation with a variable number of other disks exposed (ie.
using a command line generated by virt-inspect). Upload needs to be
file-by-file (or have everything bundled in a tarball beforehand).
- Run a tmpfs mount on the guest; upload RPMs there.
Pro: Fast. No need to worry about device names.
Con: Potential for running out of memory. Upload needs to be
file-by-file (or have everything bundled in a tarball beforehand).
- Stuff the files to be added into a cramfs filesystem, running mkcramfs
on the host.
Pro: Relatively fast. Easy to transfer a full directory structure to the
guest at one stroke.
Con: Device names an issue. Requires cramfs.ko to be added to the
whitelist in appliance/update-initramfs.sh.in.
- Support a FUSE-based mechanism for exporting files, ie.
Pro: Potential to be the cleanest approach from an end-user perspective.
Con: Implementation difficulty; no Fedora or EPEL packages are available
What's the Right Way to do the below?
><fs> command "bash -c 'for D in avahi-daemon avahi-dnsconfd haldaemon;
do /sbin/chkconfig $D off; done; true'"
libguestfs: error: D: -c: line 0: unexpected EOF while looking for
D: -c: line 1: syntax error: unexpected end of file
Howdy. Is there any intention of supporting libguestfs on non-Fedora
targets (given a sufficiently new qemu or kvm)?
As background: I have a bunch of in-house QA infrastructure, which
happens to include my own, internally developed tools intended to
address the same problems as libguestfs. (One tool, for FUSE-mounting
from a guest, used serial ports rather than the vmchannel mechanism, a
buildroot/uClibc embedded userland rather than a stripped Fedora,
qemu-nbd+nbd-client proxied over serial for getting the block device
into the guest, UML rather than qemu or kvm, and a patched ccgfs+FUSE
for getting the guest's filesystem back out onto the host).
Libguestfs is clearly more mature and flexible than my personal hackery,
so I'm looking at migrating to it -- but right now, I'm having trouble
building it for my VM servers' platform, which is effectively RHEL5 with
kvm-85 and a modern host kernel. Specific issues follow:
futimens() isn't available on glibc 2.5, and do_touch() doesn't
presently degrade gracefully to a less-capable call without it:
guestfsd-file.o: In function `do_touch':
/home/cduffy/public_git/libguestfs/daemon/file.c:49: undefined reference
It was necessary to explicitly set OCAMLC=no OCAMLFIND=no (bypassing
build of the ocaml bits) to prevent the build from breaking early,
apparently due to C interface changes between the expected OCaml and the
ocaml-3.09.3-1.el5 which is present. [TODO: more detail]
make-initramfs had numerous complaints:
+ it expected /var/lib/yum to exist within the initramfs root, which it
+ library versions mismatched between host and guest: libtinfo.so.5
(from ncurses, needed by /bin/sh) isn't available on RHEL5 natively
(easily worked around), and the glibc versions don't match (not easily
+ unless my PATH included /usr/sbin, builds failed with
"/usr/bin/fakechroot: line 107: exec: chroot: not found"
+ rpm %pre scripts all failed due to the previously mentioned version
I haven't gotten beyond the last of these issues on account of the glibc
mismatch. Before I proceed -- is my goal reasonable, or am I better off
sticking with my in-house solution for the time being?