[PATCH] launch: add missing headers on Darwin
by Margaret Lewicka
Including sys/un.h for sockaddr_un and sys/fcntl.h for
O_CLOEXEC/O_NONBLOCK.
---
src/launch-libvirt.c | 1 +
src/launch-unix.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c
index 1649884..ad07210 100644
--- a/src/launch-libvirt.c
+++ b/src/launch-libvirt.c
@@ -52,6 +52,7 @@
/* Fixes for Mac OS X */
#if defined __APPLE__ && defined __MACH__
#include <sys/un.h>
+#include <sys/fcntl.h>
#endif
#ifndef SOCK_CLOEXEC
# define SOCK_CLOEXEC O_CLOEXEC
diff --git a/src/launch-unix.c b/src/launch-unix.c
index 5cce9c1..f57910d 100644
--- a/src/launch-unix.c
+++ b/src/launch-unix.c
@@ -25,6 +25,10 @@
#include <string.h>
#include <libintl.h>
+#if defined __APPLE__ && defined __MACH__
+#include <sys/un.h>
+#endif
+
#include "guestfs.h"
#include "guestfs-internal.h"
#include "guestfs_protocol.h"
--
2.6.2
9 years
Re: [Libguestfs] Fwd: [Bug 1277705] virt-sparsify --in-place should not sparsify a snapshot
by Richard W.M. Jones
[Let's discuss this upstream]
On Wed, Nov 04, 2015 at 12:18:48PM +0200, Yaniv Kaul wrote:
> I'm missing something here - what will happen to the tree structure?
> Will we lose it? So essentially it performs a merge?
In copying mode:
virt-sparsify disk1 disk2
creates an overlay on top of disk1, writes zeroes to the overlay in
the parts of disk1 which are not used (disk1 is not modified by this),
and then copies the result to disk2. It doesn't even consider any
snapshots or backing files of disk1.
- - -
This doesn't matter because you're proposing to use --in-place which
works completely differently -- literally: it's a different code path.
virt-sparsify --in-place disk
opens `disk', mounts each filesystem it finds in turn, and runs fstrim
on them.
The question for this bug is does that do anything useful if `disk'
has backing files?
Here is a non-sparse Fedora 22 disk image:
$ virt-builder fedora-22
$ mv fedora-22.img fedora-22.img.sparse
$ cp --sparse=never fedora-22.img.sparse fedora-22.img
$ du -sh fedora-22.img
6.1G fedora-22.img
Let's add a snapshot on top:
$ qemu-img create -f qcow2 -o compat=1.1 -b fedora-22.img overlay.qcow2
$ du -sh fedora-22.img overlay.qcow2
6.1G fedora-22.img
196K overlay.qcow2
and sparsify the overlay:
$ virt-sparsify --in-place overlay.qcow2
$ du -sh fedora-22.img overlay.qcow2
6.1G fedora-22.img
3.2M overlay.qcow2
All that happened was that the overlay got bigger (because it's now
storing a bunch of qcow2 zero clusters marking the places in the
backing file which are zero).
In *theory* it should be possible to commit the changes to the backing
file, making the backing file sparse. But in reality that doesn't
work:
$ qemu-img commit overlay.qcow2
Image committed.
$ du -sh fedora-22.img overlay.qcow2
6.1G fedora-22.img
260K overlay.qcow2
So really there's no use for virt-sparsify on a snapshot (although you
could also argue this is a bug or missing feature in qemu-img).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
9 years
[PATCH] sparsify: in-place: Refuse to run on overlay files (RHBZ#1277705).
by Richard W.M. Jones
$ qemu-img create -f qcow2 -b /tmp/centos-6.img overlay.qcow2
$ virt-sparsify --in-place overlay.qcow2
virt-sparsify: error: disk image 'overlay.qcow2' appears to have a backing
file. You should use copying mode sparsification for this file (see the
virt-sparsify(1) manual).
Thanks: Yaniv Kaul
---
sparsify/in_place.ml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/sparsify/in_place.ml b/sparsify/in_place.ml
index 3a2b32c..669c639 100644
--- a/sparsify/in_place.ml
+++ b/sparsify/in_place.ml
@@ -30,6 +30,11 @@ open Cmdline
module G = Guestfs
let rec run disk format ignores machine_readable zeroes =
+ (* If the disk has a backing file, refuse to run (RHBZ#1277705). *)
+ if (new G.guestfs ())#disk_has_backing_file disk then
+ error (f_"disk image '%s' appears to have a backing file. You should use copying mode sparsification for this file (see the virt-sparsify(1) manual).")
+ disk;
+
(* Connect to libguestfs. *)
let g = new G.guestfs () in
if trace () then g#set_trace true;
--
2.5.0
9 years
[PATCH] builder: Document using 'qemu-img amend' for RHEL 6 compat (RHBZ#1204131).
by Richard W.M. Jones
---
builder/virt-builder.pod | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/builder/virt-builder.pod b/builder/virt-builder.pod
index 67e017f..545b134 100644
--- a/builder/virt-builder.pod
+++ b/builder/virt-builder.pod
@@ -280,6 +280,12 @@ For ordinary builds, this selects the output format. The default is I<raw>.
With I<--get-kernel> this specifies the input format.
+To create an old-style qcow2 file (for compatibility with RHEL 6 or
+very old qemu E<lt> 1.1), after running virt-builder, use this
+command:
+
+ qemu-img amend -f qcow2 -o compat=0.10 output.qcow2
+
=item B<--get-kernel> IMAGE
This option extracts the kernel and initramfs from a previously built
--
2.5.0
9 years
P2V using 2 physical machines - Fedora OS installed on both
by Praveen Tiwari
Hi All,
We have installed Fedora 21 on two physical machines (HP SL hardware) and
generated the ISO using the "livecd-creator" on one of the machine (p2v
server)
We are unable to establish the connection between the two machines when we
try to boot the first machine (p2v machine) using the ISO created !
Can you please share the sequence of steps which we need to follow when
using two physical machines ? Screenshots might be helpful, if available.
Do we need to try the RHEL 7.1 free version for testing this, if Fedora 21
is not supported ?
Thanks.
Praveen.
9 years
Thoughts on virt-builder --output-alloc sparse|preallocated
by Richard W.M. Jones
I had a good go at implementing $subject, but it's not as easy as it
seems. There was a customer request for this, although I don't think
they ended up filing a BZ for it. Anyway, these are my random
thoughts in no particular order.
It would be nice to use `-oa sparse' etc for compatibility with
virt-v2v, but that possibly closes off future options for replacing
the horrible OCaml Arg module with GNU getopt_long (-oa == -o + -a).
I initially tried to implement `--output-alloc sparse|preallocated'
using the Planner. I added an extra planner flag
[`Alloc, ("sparse"|"preallocated")]. I added extra transitions
such as `Copy_sparse_never ("cp --sparse=never"). The problem is that
some output locations don't support sparse output, eg. writing to a
block device. If the user did:
virt-builder --output-alloc sparse --output /dev/sdX
then the planner stage would actually fail because it couldn't find a
satisfactory plan. (Even worse because `--output-alloc sparse' is the
default!)
So then I tried to add `--output-alloc prefer-sparse' as the default.
The problem with that is the planner could choose to use a
preallocating transition (eg. "cp --sparse=never" or
"qemu-img ... -o preallocation=full"), when ideally we'd always want
it to choose sparseness if possible. It may be possible to use the
planner weights to avoid this, but I'm not convinced the way we handle
weights is very robust (in particular, plans with lower total weight
but more steps are ignored).
Adding some kind of "best effort" goal to the planner might be
possible, but our planner is very naive and doesn't support that at
the moment. (All current goals must be "must" or "must not".)
Anyhow, there you go.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
9 years
