4:32 a.m.
Only replaced in end-user messages and documentation, not in code,
comments, or anything else that's not end-user visible.
See: https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
---
appliance/init | 2 +-
builder/virt-builder.pod | 34 ++++++++++++------------
cat/virt-cat.pod | 2 +-
cat/virt-filesystems.pod | 2 +-
cat/virt-ls.pod | 2 +-
df/virt-df.pod | 2 +-
dib/virt-dib.pod | 4 +--
diff/virt-diff.pod | 2 +-
docs/guestfs-building.pod | 4 +--
docs/guestfs-faq.pod | 30 ++++++++++-----------
docs/guestfs-hacking.pod | 6 ++---
docs/guestfs-internals.pod | 4 +--
docs/guestfs-performance.pod | 4 +--
docs/guestfs-recipes.pod | 2 +-
docs/guestfs-security.pod | 6 ++---
edit/virt-edit.pod | 6 ++---
generator/actions_core.ml | 22 +++++++--------
generator/actions_inspection.ml | 4 +--
generator/customize.ml | 10 +++----
generator/java.ml | 2 +-
inspector/virt-inspector.pod | 2 +-
lib/guestfs.pod | 8 +++---
p2v/virt-p2v-make-disk.in | 2 +-
p2v/virt-p2v-make-kickstart.pod | 2 +-
p2v/virt-p2v-make-kiwi.pod | 2 +-
p2v/virt-p2v.pod | 6 ++---
rescue/virt-rescue.pod | 4 +--
resize/virt-resize.pod | 6 ++---
sysprep/sysprep_operation_script.ml | 10 +++----
sysprep/sysprep_operation_udev_persistent_net.ml | 2 +-
sysprep/sysprep_operation_utmp.ml | 2 +-
sysprep/virt-sysprep.pod | 2 +-
test-tool/libguestfs-test-tool.pod | 2 +-
tests/qemu/qemu-snapshot-isolation.sh | 2 +-
v2v/OVF.ml | 2 +-
v2v/test-harness/virt-v2v-test-harness.pod | 4 +--
v2v/virt-v2v.pod | 18 ++++++-------
37 files changed, 113 insertions(+), 113 deletions(-)
diff --git a/appliance/init b/appliance/init
index 968429c4b..2df5f92ce 100755
--- a/appliance/init
+++ b/appliance/init
@@ -213,7 +213,7 @@ else
echo
echo "Note: The contents of / (root) are the rescue appliance."
if ! test -d "/sysroot/dev"; then
- echo "You have to mount the guest's partitions under /sysroot"
+ echo "You have to mount the guest’s partitions under /sysroot"
echo "before you can examine them."
else
echo "Use 'cd /sysroot' or 'chroot /sysroot' to see guest
filesystems."
diff --git a/builder/virt-builder.pod b/builder/virt-builder.pod
index 76ad3b18e..a3e05728a 100644
--- a/builder/virt-builder.pod
+++ b/builder/virt-builder.pod
@@ -430,9 +430,9 @@ You don't have a host network (eg. in secure/restricted
environments).
Do not sync the output file on exit.
-Virt-builder fsync's the output file or disk image when it exits.
+Virt-builder C<fsync>s the output file or disk image when it exits.
-The reason is that qemu/KVM's default caching mode is C<none> or
+The reason is that qemu/KVM’s default caching mode is C<none> or
C<directsync>, both of which bypass the host page cache. Therefore
these would not work correctly if you immediately started the guest
after running virt-builder - they would not see the complete output
@@ -554,7 +554,7 @@ you can use I<--install> to install packages like this:
virt-builder fedora-20 --install inkscape
-This uses the guest's package manager and the host's network
+This uses the guest’s package manager and the host’s network
connection.
=head3 Updating packages at build time
@@ -575,11 +575,11 @@ Another option is to install the packages when the guest first
boots:
virt-builder fedora-20 --firstboot-install inkscape
-This uses the guest's package manager and the guest's network
+This uses the guest’s package manager and the guest’s network
connection.
The downsides are that it will take the guest a lot longer to boot
-first time, and there's nothing much you can do if package
+first time, and there’s nothing much you can do if package
installation fails (eg. if a network problem means the guest can't
reach the package repositories).
@@ -808,7 +808,7 @@ the guest, so they can login without supplying a password.
The C<SELECTOR> part of the option value is optional; in this case,
I<--ssh-inject> C<USER> means that we look in the I<current>
-user's F<~/.ssh> directory to find the default public ID file. That
+user’s F<~/.ssh> directory to find the default public ID file. That
key is uploaded. "default public ID" is the I<default_ID_file> file
described in L<ssh-copy-id(1)>.
@@ -982,7 +982,7 @@ Notes:
=item 1.
You I<must> specify the correct format. The format is C<raw> unless
-you used virt-builder's I<--format> option.
+you used virt-builder’s I<--format> option.
=item 2.
@@ -1013,8 +1013,8 @@ Import the image into Glance (the OpenStack image store) by doing:
--is-public True
The I<--file> parameter is the virt-builder-generated disk image. It
-should match virt-builder's I<--output> option. The I<--disk-format>
-parameter should match virt-builder's I<--format> option (or C<raw> if
+should match virt-builder’s I<--output> option. The I<--disk-format>
+parameter should match virt-builder’s I<--format> option (or C<raw> if
you didn't use that option). The I<--container-format> should always
be C<bare> since virt-builder doesn't put images into containers.
@@ -1425,9 +1425,9 @@ When expanding the image to its final size, instruct
L<virt-resize(1)>
to expand the named partition in the guest image to fill up all
available space. This works like the virt-resize I<--expand> option.
-You should usually put the device name of the guest's root filesystem here.
+You should usually put the device name of the guest’s root filesystem here.
-It's a good idea to use this, but not required. If the field is
+It’s a good idea to use this, but not required. If the field is
omitted then virt-resize will create an extra partition at the end of
the disk to cover the free space, which is much less user-friendly.
@@ -1437,7 +1437,7 @@ When expanding the image to its final size, instruct
L<virt-resize(1)>
to expand the named logical volume in the guest image to fill up all
available space. This works like the virt-resize I<--lv-expand> option.
-If the guest uses LVM2 you should usually put the LV of the guest's
+If the guest uses LVM2 you should usually put the LV of the guest’s
root filesystem here. If the guest does not use LVM2 or its root
filesystem is not on an LV, don't use this option.
@@ -1527,7 +1527,7 @@ The index is always encoded in UTF-8.
=head3 Caching templates
Since the templates are usually very large, downloaded templates are
-cached in the user's home directory.
+cached in the user’s home directory.
The location of the cache is F<$XDG_CACHE_HOME/virt-builder/> or
F<$HOME/.cache/virt-builder>.
@@ -1608,13 +1608,13 @@ index and templates have not been tampered with.
The source points to an index file, which is optionally signed.
Virt-builder downloads the index and checks that the signature is
-valid and the signer's fingerprint matches the specified fingerprint
+valid and the signer’s fingerprint matches the specified fingerprint
(ie. the one specified in I<gpgkey=..> in the I<.conf>, or with
I<--fingerprint>, in that order).
For checking against the built-in public key/fingerprint, this
-requires importing the public key into the user's local gpg keyring
-(that's just the way that gpg works).
+requires importing the public key into the user’s local gpg keyring
+(that’s just the way that gpg works).
When a template is downloaded, its signature is checked in the same
way.
@@ -1650,7 +1650,7 @@ commands do not run on the host. If you are using the libguestfs
libvirt backend and have SELinux enabled then the virtual machine is
additionally encapsulated in an SELinux container (sVirt).
-However these options will have access to the host's network and since
+However these options will have access to the host’s network and since
the template may contain untrusted code, the code might try to access
host network resources which it should not. You can use
I<--no-network> to prevent this.
diff --git a/cat/virt-cat.pod b/cat/virt-cat.pod
index a81f4f4d0..3c685440b 100644
--- a/cat/virt-cat.pod
+++ b/cat/virt-cat.pod
@@ -257,7 +257,7 @@ where C<domname> is the name of the libvirt guest, and
C<file> is the
full path to the file. Note the final C<-> (meaning "output to
stdout").
-The command above uses libguestfs's guest inspection feature and so
+The command above uses libguestfs’s guest inspection feature and so
does not work on guests that libguestfs cannot inspect, or on things
like arbitrary disk images that don't contain guests. To display a
file from a disk image directly, use:
diff --git a/cat/virt-filesystems.pod b/cat/virt-filesystems.pod
index cc3802592..84ad02fea 100644
--- a/cat/virt-filesystems.pod
+++ b/cat/virt-filesystems.pod
@@ -374,7 +374,7 @@ For shell scripts, use C<csvtool>
(L<https://github.com/Chris00/ocaml-csv>
also packaged in major Linux distributions).
For other languages, use a CSV processing library (eg. C<Text::CSV>
-for Perl or Python's built-in csv library).
+for Perl or Python’s built-in csv library).
Most spreadsheets and databases can import CSV directly.
diff --git a/cat/virt-ls.pod b/cat/virt-ls.pod
index f933c4192..d23e14baf 100644
--- a/cat/virt-ls.pod
+++ b/cat/virt-ls.pod
@@ -506,7 +506,7 @@ For shell scripts, use C<csvtool>
(L<https://github.com/Chris00/ocaml-csv>
also packaged in major Linux distributions).
For other languages, use a CSV processing library (eg. C<Text::CSV>
-for Perl or Python's built-in csv library).
+for Perl or Python’s built-in csv library).
Most spreadsheets and databases can import CSV directly.
diff --git a/df/virt-df.pod b/df/virt-df.pod
index 9e7744bad..55b0e27e3 100644
--- a/df/virt-df.pod
+++ b/df/virt-df.pod
@@ -244,7 +244,7 @@ For shell scripts, use C<csvtool>
(L<https://github.com/Chris00/ocaml-csv>
also packaged in major Linux distributions).
For other languages, use a CSV processing library (eg. C<Text::CSV>
-for Perl or Python's built-in csv library).
+for Perl or Python’s built-in csv library).
Most spreadsheets and databases can import CSV directly.
diff --git a/dib/virt-dib.pod b/dib/virt-dib.pod
index 5c1423ef5..d918097e4 100644
--- a/dib/virt-dib.pod
+++ b/dib/virt-dib.pod
@@ -69,7 +69,7 @@ Use the specified architecture for the output image. The default
value is the same as the host running virt-dib.
Right now this option does nothing more than setting the C<ARCH>
-environment variable for the elements, and it's up to them to
+environment variable for the elements, and it’s up to them to
produce an image for the requested architecture.
=item B<--checksum>
@@ -206,7 +206,7 @@ B<docker>.
=item C<qcow2> (enabled by default)
-QEMU's qcow2. This output format requires the C<qemu-img> tool.
+QEMU’s qcow2. This output format requires the C<qemu-img> tool.
=item C<raw>
diff --git a/diff/virt-diff.pod b/diff/virt-diff.pod
index 133e14276..a6f814984 100644
--- a/diff/virt-diff.pod
+++ b/diff/virt-diff.pod
@@ -236,7 +236,7 @@ For shell scripts, use C<csvtool>
(L<https://github.com/Chris00/ocaml-csv>
also packaged in major Linux distributions).
For other languages, use a CSV processing library (eg. C<Text::CSV>
-for Perl or Python's built-in csv library).
+for Perl or Python’s built-in csv library).
Most spreadsheets and databases can import CSV directly.
diff --git a/docs/guestfs-building.pod b/docs/guestfs-building.pod
index 11ffe5f0b..3cf86a0ae 100644
--- a/docs/guestfs-building.pod
+++ b/docs/guestfs-building.pod
@@ -198,7 +198,7 @@ Optional. Used only for tests.
=item libconfig
-Optional. Used to parse libguestfs's own config files,
+Optional. Used to parse libguestfs’s own config files,
eg. F</etc/libguestfs-tools.conf>.
=item libselinux
@@ -548,7 +548,7 @@ environment variables needed, eg. for skipping tests:
# Skip this test, it is broken.
export SKIP_TEST_BTRFS_FSCK=1
-Note that F<localenv> is included by the top Makefile (so it's a
+Note that F<localenv> is included by the top Makefile (so it’s a
Makefile fragment). But if it is also sourced by your
F<localconfigure> script then it is used as a shell script.
diff --git a/docs/guestfs-faq.pod b/docs/guestfs-faq.pod
index bab93ffcd..9da133098 100644
--- a/docs/guestfs-faq.pod
+++ b/docs/guestfs-faq.pod
@@ -8,7 +8,7 @@ guestfs-faq - libguestfs Frequently Asked Questions (FAQ)
libguestfs is a way to create, access and modify disk images. You can
look inside disk images, modify the files they contain, create them
-from scratch, resize them, and much more. It's especially useful from
+from scratch, resize them, and much more. It’s especially useful from
scripts and programs and from the command line.
libguestfs is a C library (hence "lib-"), and a set of tools built on
@@ -60,7 +60,7 @@ create images from scratch.
vdfuse is like kpartx but for VirtualBox images. See the kpartx
comparison above. You can use libguestfs on the partition files
-exposed by vdfuse, although it's not necessary since libguestfs can
+exposed by vdfuse, although it’s not necessary since libguestfs can
access VirtualBox images directly.
=item I<vs. qemu-nbd>
@@ -730,7 +730,7 @@ ssh. See L<guestfs(3)/REMOTE STORAGE>.
=item 2.
-Use VMware's proprietary vdiskmanager tool to convert the image to raw
+Use VMware’s proprietary vdiskmanager tool to convert the image to raw
format.
=item 3.
@@ -754,7 +754,7 @@ See
L<https://www.kernel.org/doc/Documentation/filesystems/ufs.txt>
=head2 Windows ReFS
-Windows ReFS is Microsoft's ZFS/Btrfs copy. This filesystem has not
+Windows ReFS is Microsoft’s ZFS/Btrfs copy. This filesystem has not
yet been reverse engineered and implemented in the Linux kernel, and
therefore libguestfs doesn't support it. At the moment it seems to be
very rare "in the wild".
@@ -783,8 +783,8 @@ This is a design flaw of the GNU/Linux system.
VFAT stores long filenames as UTF-16 characters. When opening or
returning filenames, the Linux kernel has to translate these to some
form of 8 bit string. UTF-8 would be the obvious choice, except for
-Linux users who persist in using non-UTF-8 locales (the user's locale
-is not known to the kernel because it's a function of libc).
+Linux users who persist in using non-UTF-8 locales (the user’s locale
+is not known to the kernel because it’s a function of libc).
Therefore you have to tell the kernel what translation you want done
when you mount the filesystem. The two methods are the C<iocharset>
@@ -911,7 +911,7 @@ standalone programs).
=head1 DEBUGGING LIBGUESTFS
-=head2 Help, it's not working!
+=head2 Help, it’s not working!
If no libguestfs program seems to work at all, run the program below
and paste the B<complete, unedited> output into an email to
@@ -1125,7 +1125,7 @@ store these writes, and then we discard it afterwards. This
ensures
that the underlying disk is always untouched.
Note also that there is a regression test for this when building
-libguestfs (in C<tests/qemu>). This is one reason why it's important
+libguestfs (in C<tests/qemu>). This is one reason why it’s important
for packagers to run the test suite.
=head2 Does C<--ro> make all disks read-only?
@@ -1158,7 +1158,7 @@ different times as the fsck operation progresses, with host writes
in
between. The result is that fsck sees massive corruption (imaginary,
not real!) and fails.
-What you have to do is to create a point-in-time snapshot. If it's a
+What you have to do is to create a point-in-time snapshot. If it’s a
logical volume, use an LVM2 snapshot. If the filesystem is located
inside something like a btrfs/ZFS file, use a btrfs/ZFS snapshot, and
then run the fsck on the snapshot. In practice you don't need to use
@@ -1168,7 +1168,7 @@ Creating point-in-time snapshots of host devices and files is
outside
the scope of libguestfs, although libguestfs can operate on them once
they are created.
-=head2 What's the difference between guestfish and virt-rescue?
+=head2 What’s the difference between guestfish and virt-rescue?
A lot of people are confused by the two superficially similar tools we
provide:
@@ -1192,12 +1192,12 @@ for shell. The key differentiating factor of guestfish (and the
libguestfs API in general) is the ability to automate changes.
L<virt-rescue(1)> is a free-for-all freeform way to boot the
-libguestfs appliance and make arbitrary changes to your VM. It's not
+libguestfs appliance and make arbitrary changes to your VM. It’s not
structured, you can't automate it, but for making quick ad-hoc fixes
to your guests, it can be quite useful.
But, libguestfs also has a "backdoor" into the appliance allowing you
-to send arbitrary shell commands. It's not as flexible as
+to send arbitrary shell commands. It’s not as flexible as
virt-rescue, because you can't interact with the shell commands, but
here it is anyway:
@@ -1207,7 +1207,7 @@ Note that you should B<not> rely on this. It could be removed
or
changed in future. If your program needs some operation, please add it
to the libguestfs API instead.
-=head2 What's the deal with C<guestfish -i>?
+=head2 What’s the deal with C<guestfish -i>?
=head2 Why does virt-cat only work on a real VM image, but virt-df
works on any disk image?
@@ -1322,7 +1322,7 @@
L<https://www.redhat.com/archives/libguestfs/2012-January/msg00023.htm...
=head2 Can I fork libguestfs?
Of course you can. Git makes it easy to fork libguestfs. Github
-makes it even easier. It's nice if you tell us on the mailing list
+makes it even easier. It’s nice if you tell us on the mailing list
about forks and the reasons for them.
=head1 MISCELLANEOUS QUESTIONS
@@ -1405,7 +1405,7 @@ deleting filesystems). For those kinds of things you must relaunch
the appliance.
(Note there is a third problem that you need to use consistent
-snapshots to really examine live disk images, but that's a general
+snapshots to really examine live disk images, but that’s a general
problem with using libguestfs against any live disk image.)
=head1 SEE ALSO
diff --git a/docs/guestfs-hacking.pod b/docs/guestfs-hacking.pod
index dd5a799e5..8778ebbf6 100644
--- a/docs/guestfs-hacking.pod
+++ b/docs/guestfs-hacking.pod
@@ -391,7 +391,7 @@ In either case, use another function as an example of what to do.
After making these changes, use C<make> to compile.
Note that you don't need to implement the RPC, language bindings,
-manual pages or anything else. It's all automatically generated from
+manual pages or anything else. It’s all automatically generated from
the OCaml description.
=head3 Adding tests for an API
@@ -945,7 +945,7 @@ in virt-v2v. They are converted in the same way as foreign VMs.
=head3 Running virt-p2v
You can run the F<p2v/virt-p2v> binary directly, but it will try to
-convert your machine's real F</dev/sda> which is unlikely to work
+convert your machine’s real F</dev/sda> which is unlikely to work
well. However virt-p2v also has a test mode in which you can supply a
test disk:
@@ -1002,7 +1002,7 @@ interactively to the remote virt-v2v conversion server.
(Note that miniexpect is a separate library with its own upstream, so
if you patch miniexpect.c, then please make sure the changes get
-reflected in miniexpect's upstream too:
+reflected in miniexpect’s upstream too:
F<http://git.annexia.org/?p=miniexpect.git;a=summary>)
=head1 MAINTAINER TASKS
diff --git a/docs/guestfs-internals.pod b/docs/guestfs-internals.pod
index a77b52226..16bab0618 100644
--- a/docs/guestfs-internals.pod
+++ b/docs/guestfs-internals.pod
@@ -42,13 +42,13 @@ controlling daemon called L</guestfsd>. The library talks to
L</guestfsd> using remote procedure calls (RPC). There is a mostly
one-to-one correspondence between libguestfs API calls and RPC calls
to the daemon. Lastly the disk image(s) are attached to the qemu
-process which translates device access by the appliance's Linux kernel
+process which translates device access by the appliance’s Linux kernel
into accesses to the image.
A common misunderstanding is that the appliance "is" the virtual
machine. Although the disk image you are attached to might also be
used by some virtual machine, libguestfs doesn't know or care about
-this. (But you will care if both libguestfs's qemu process and your
+this. (But you will care if both libguestfs’s qemu process and your
virtual machine are trying to update the disk image at the same time,
since these usually results in massive disk corruption).
diff --git a/docs/guestfs-performance.pod b/docs/guestfs-performance.pod
index cba9ce53c..620a82adf 100644
--- a/docs/guestfs-performance.pod
+++ b/docs/guestfs-performance.pod
@@ -77,7 +77,7 @@ so that you are measuring a typical "hot cache" case.
This command starts up the libguestfs appliance on the named disk
image or libvirt guest, performs libguestfs inspection on it (see
-L<guestfs(3)/INSPECTION>), mounts the guest's disks, then discards all
+L<guestfs(3)/INSPECTION>), mounts the guest’s disks, then discards all
these results and shuts down.
The first time you run the command, it will create an appliance and
@@ -395,7 +395,7 @@ hardware virt acceleration is not available).
Upload and download is as much as 10 times slower on UML than KVM.
Libguestfs sends this data over the UML emulated serial port, which is
-far less efficient than KVM's virtio-serial.
+far less efficient than KVM’s virtio-serial.
=item *
diff --git a/docs/guestfs-recipes.pod b/docs/guestfs-recipes.pod
index 0e6f6a95e..02739f6dc 100644
--- a/docs/guestfs-recipes.pod
+++ b/docs/guestfs-recipes.pod
@@ -697,7 +697,7 @@ RAID device:
guestfish --rw -d Guest run : upload lv.img /dev/vg_guest/lv_root
One common problem is that the filesystem isn't the right size for the
-target. If it is too large, there's not much you can do with
+target. If it is too large, there’s not much you can do with
libguestfs - you have to prepare the filesystem differently. But if
the filesystem needs to expand into the target, you can use guestfish
to resize it to the right size:
diff --git a/docs/guestfs-security.pod b/docs/guestfs-security.pod
index 5cbfb202c..093e7544c 100644
--- a/docs/guestfs-security.pod
+++ b/docs/guestfs-security.pod
@@ -188,7 +188,7 @@ L<guestfs(3)/RUNNING COMMANDS>).
The way to avoid this is to specify the expected disk format when
adding disks (the optional C<format> option to
L<guestfs(3)/guestfs_add_drive_opts>). You should always do this if
-the disk is raw format, and it's a good idea for other cases too.
+the disk is raw format, and it’s a good idea for other cases too.
(See also L<guestfs(3)/DISK IMAGE FORMATS>).
For disks added from libvirt using calls like
@@ -203,7 +203,7 @@ appropriate.
L<https://bugzilla.redhat.com/752375>
This is a bug in the kernel which allowed guests to overwrite
-parts of the host's drives which they should not normally
+parts of the host’s drives which they should not normally
have access to.
It is sufficient to update libguestfs to any version E<ge> 1.16 which
@@ -244,7 +244,7 @@ The location has to be a known one in order for both ends to
communicate. However no checking was done that the containing
directory (F</tmp/.guestfish-$UID>) is owned by the user. Thus
another user could create this directory and potentially hijack
-sockets owned by another user's guestfish client or server.
+sockets owned by another user’s guestfish client or server.
It is sufficient to update libguestfs to a version that is not
vulnerable: libguestfs E<ge> 1.20.12, E<ge> 1.22.7 or E<ge> 1.24.
diff --git a/edit/virt-edit.pod b/edit/virt-edit.pod
index da3d65665..a6b82a594 100644
--- a/edit/virt-edit.pod
+++ b/edit/virt-edit.pod
@@ -235,7 +235,7 @@ the system administrator can interactively edit the file.
There are two ways also to use C<virt-edit> from scripts in order to
make automated edits to files. (Note that although you I<can> use
-C<virt-edit> like this, it's less error-prone to write scripts
+C<virt-edit> like this, it’s less error-prone to write scripts
directly using the libguestfs API and Augeas for configuration file
editing.)
@@ -250,7 +250,7 @@ replace all instances of C<foo> with C<bar> in a file:
virt-edit -d domname filename -e 's/foo/bar/'
The full power of Perl regular expressions can be used (see
-L<perlre(1)>). For example to delete root's password you could do:
+L<perlre(1)>). For example to delete root’s password you could do:
virt-edit -d domname /etc/passwd -e 's/^root:.*?:/root::/'
@@ -342,7 +342,7 @@ Using C<virt-edit> is approximately equivalent to doing:
where C<domname> is the name of the libvirt guest, and F</file> is the
full path to the file.
-The command above uses libguestfs's guest inspection feature and so
+The command above uses libguestfs’s guest inspection feature and so
does not work on guests that libguestfs cannot inspect, or on things
like arbitrary disk images that don't contain guests. To edit a file
on a disk image directly, use:
diff --git a/generator/actions_core.ml b/generator/actions_core.ml
index 259ca9051..7e80ab821 100644
--- a/generator/actions_core.ml
+++ b/generator/actions_core.ml
@@ -58,7 +58,7 @@ automatically." };
shortdesc = "add hypervisor parameters";
longdesc = "\
This can be used to add arbitrary hypervisor parameters of the
-form I<-param value>. Actually it's not quite arbitrary - we
+form I<-param value>. Actually it’s not quite arbitrary - we
prevent you from setting some parameters which would interfere with
parameters that we use.
@@ -163,7 +163,7 @@ This call was added in version C<1.0.58>. In previous
versions of libguestfs there was no way to get the version
number. From C code you can use dynamic linker functions
to find out if this symbol exists (if it doesn't, then
-it's an earlier version).
+it’s an earlier version).
The call returns a structure with four elements. The first
three (C<major>, C<minor> and C<release>) are numbers and
@@ -1443,7 +1443,7 @@ See L<guestfs(3)/LIBVIRT AUTHENTICATION> for documentation and
example code." };
blocking = false;
shortdesc = "parse the environment and set handle flags accordingly";
longdesc = "\
-Parse the program's environment and set flags in the handle
+Parse the program’s environment and set flags in the handle
accordingly. For example if C<LIBGUESTFS_DEBUG=1> then the
'verbose' flag is set in the handle.
@@ -1490,7 +1490,7 @@ another error.
No cleanup is performed: for example, if a file was being uploaded
then after cancellation there may be a partially uploaded file. It is
-the caller's responsibility to clean up if necessary.
+the caller’s responsibility to clean up if necessary.
There are two common places that you might call C<guestfs_user_cancel>:
@@ -2451,7 +2451,7 @@ first parameter.
Shared libraries and data files required by the program
must be available on filesystems which are mounted in the
-correct places. It is the caller's responsibility to ensure
+correct places. It is the caller’s responsibility to ensure
all filesystems that are needed are mounted at the right
locations." };
@@ -3128,7 +3128,7 @@ This command is entirely equivalent to running C<fsck -a -t
fstype device>." };
longdesc = "\
This command writes zeroes over the first few blocks of C<device>.
-How many blocks are zeroed isn't specified (but it's I<not> enough
+How many blocks are zeroed isn't specified (but it’s I<not> enough
to securely wipe the device). It should be sufficient to remove
any partition tables, filesystem superblocks and so on.
@@ -3477,7 +3477,7 @@ volume to match the new size of the underlying device." };
style = RString "partitions", [Device "device"], [];
shortdesc = "display the kernel geometry";
longdesc = "\
-This displays the kernel's idea of the geometry of C<device>.
+This displays the kernel’s idea of the geometry of C<device>.
The result is in human-readable format, and not designed to
be parsed." };
@@ -3490,7 +3490,7 @@ be parsed." };
This displays the disk geometry of C<device> read from the
partition table. Especially in the case where the underlying
block device has been resized, this can be different from the
-kernel's idea of the geometry (see C<guestfs_sfdisk_kernel_geometry>).
+kernel’s idea of the geometry (see C<guestfs_sfdisk_kernel_geometry>).
The result is in human-readable format, and not designed to
be parsed." };
@@ -3610,13 +3610,13 @@ L<ntfs-3g.probe(8)> manual page." };
shortdesc = "run a command via the shell";
longdesc = "\
This call runs a command from the guest filesystem via the
-guest's F</bin/sh>.
+guest’s F</bin/sh>.
This is like C<guestfs_command>, but passes the command to:
/bin/sh -c \"command\"
-Depending on the guest's shell, this usually results in
+Depending on the guest’s shell, this usually results in
wildcards being expanded, shell expressions being interpolated
and so on.
@@ -5268,7 +5268,7 @@ Partition number, counting from 1.
=item B<part_start>
Start of the partition I<in bytes>. To get sectors you have to
-divide by the device's sector size, see C<guestfs_blockdev_getss>.
+divide by the device’s sector size, see C<guestfs_blockdev_getss>.
=item B<part_end>
diff --git a/generator/actions_inspection.ml b/generator/actions_inspection.ml
index 72fd4ecb3..9c0c19c28 100644
--- a/generator/actions_inspection.ml
+++ b/generator/actions_inspection.ml
@@ -558,7 +558,7 @@ Please read L<guestfs(3)/INSPECTION> for more details." };
shortdesc = "get hostname of the operating system";
longdesc = "\
This function returns the hostname of the operating system
-as found by inspection of the guest's configuration files.
+as found by inspection of the guest’s configuration files.
If the hostname could not be determined, then the
string C<unknown> is returned.
@@ -740,7 +740,7 @@ Notes:
=item *
-Unlike most other inspection API calls, the guest's disks must be
+Unlike most other inspection API calls, the guest’s disks must be
mounted up before you call this, since it needs to read information
from the guest filesystem during the call.
diff --git a/generator/customize.ml b/generator/customize.ml
index 96aa22d15..b158eb5d9 100644
--- a/generator/customize.ml
+++ b/generator/customize.ml
@@ -221,8 +221,8 @@ See also I<--run>.";
op_shortdesc = "Add package(s) to install at first boot";
op_pod_longdesc = "\
Install the named packages (a comma-separated list). These are
-installed when the guest first boots using the guest's package manager
-(eg. apt, yum, etc.) and the guest's network connection.
+installed when the guest first boots using the guest’s package manager
+(eg. apt, yum, etc.) and the guest’s network connection.
For an overview on the different ways to install packages, see
L<virt-builder(1)/INSTALLING PACKAGES>.";
@@ -243,8 +243,8 @@ dotted hostname.domainname (FQDN) if you want.";
op_shortdesc = "Add package(s) to install";
op_pod_longdesc = "\
Install the named packages (a comma-separated list). These are
-installed during the image build using the guest's package manager
-(eg. apt, yum, etc.) and the host's network connection.
+installed during the image build using the guest’s package manager
+(eg. apt, yum, etc.) and the host’s network connection.
For an overview on the different ways to install packages, see
L<virt-builder(1)/INSTALLING PACKAGES>.
@@ -465,7 +465,7 @@ This command performs a L<touch(1)>-like operation on
C<FILE>.";
op_shortdesc = "Uninstall package(s)";
op_pod_longdesc = "\
Uninstall the named packages (a comma-separated list). These are
-removed during the image build using the guest's package manager
+removed during the image build using the guest’s package manager
(eg. apt, yum, etc.). Dependent packages may also need to be
uninstalled to satisfy the request.
diff --git a/generator/java.ml b/generator/java.ml
index 0bbb55981..eec1ab116 100644
--- a/generator/java.ml
+++ b/generator/java.ml
@@ -189,7 +189,7 @@ public class GuestFS {
* <code>events</code> is one or more <code>EVENT_*</code>
constants,
* bitwise ORed together.
* </p><p>
- * When an event happens, the callback object's <code>event</code>
method
+ * When an event happens, the callback object’s <code>event</code> method
* is invoked like this:
* </p>
* <pre>
diff --git a/inspector/virt-inspector.pod b/inspector/virt-inspector.pod
index 102ba2eb8..8be9aed1a 100644
--- a/inspector/virt-inspector.pod
+++ b/inspector/virt-inspector.pod
@@ -29,7 +29,7 @@ You can also run virt-inspector directly on disk images from a single
virtual machine. Use C<virt-inspector -a disk.img>. In rare cases a
domain has several block devices, in which case you should list
several I<-a> options one after another, with the first corresponding
-to the guest's F</dev/sda>, the second to the guest's F</dev/sdb>
and
+to the guest’s F</dev/sda>, the second to the guest’s F</dev/sdb> and
so on.
You can also run virt-inspector on install disks, live CDs, bootable
diff --git a/lib/guestfs.pod b/lib/guestfs.pod
index e02cda6f8..bbc64892b 100644
--- a/lib/guestfs.pod
+++ b/lib/guestfs.pod
@@ -1651,7 +1651,7 @@ Make sure any filesystem drivers that you need are compiled into
the
kernel.
B<Currently, it needs a large amount of extra work to get modules
-working>. It's recommended that you disable module support in the
+working>. It’s recommended that you disable module support in the
kernel configuration, which will cause everything to be compiled into
the image.
@@ -1922,7 +1922,7 @@ There are at least two distinct variants of this format, although
qemu
=item I<vmdk>
-VMDK is VMware's native disk image format. There are many variations.
+VMDK is VMware’s native disk image format. There are many variations.
Modern qemu (hence libguestfs) supports most variations, but you
should be aware that older versions of qemu had some very bad
data-corrupting bugs in this area.
@@ -1933,7 +1933,7 @@ C<.vmdk> extension.
=item I<vdi>
-VDI is VirtualBox's native disk image format. Qemu (hence libguestfs)
+VDI is VirtualBox’s native disk image format. Qemu (hence libguestfs)
has generally good support for this.
=item I<vpc>
@@ -3005,7 +3005,7 @@ To retrieve the pointer, use:
void *guestfs_get_private (guestfs_h *g, const char *key);
This function returns C<NULL> if either no data is found associated
-with C<key>, or if the user previously set the C<key>'s C<data>
+with C<key>, or if the user previously set the C<key>’s C<data>
pointer to C<NULL>.
Libguestfs does not try to look at or interpret the C<data> pointer in
diff --git a/p2v/virt-p2v-make-disk.in b/p2v/virt-p2v-make-disk.in
index 026d18b51..61d3a85cd 100644
--- a/p2v/virt-p2v-make-disk.in
+++ b/p2v/virt-p2v-make-disk.in
@@ -147,7 +147,7 @@ fi
if [ ! -f "$virt_p2v_xz_binary" ]; then
echo "$program: cannot find $virt_p2v_xz_binary"
if [ -n "$arch" ]; then
- echo "You used the '--arch' option, so it's likely that you will
need to build"
+ echo "You used the '--arch' option, so it’s likely that you will
need to build"
echo "a virt-p2v.$arch binary yourself."
echo "See guestfs-building(1) section BUILDING i686 32 BIT VIRT-P2V for
help."
fi
diff --git a/p2v/virt-p2v-make-kickstart.pod b/p2v/virt-p2v-make-kickstart.pod
index adb15dd98..226f2f325 100644
--- a/p2v/virt-p2v-make-kickstart.pod
+++ b/p2v/virt-p2v-make-kickstart.pod
@@ -185,7 +185,7 @@ emulating a netboot:
-serial stdio
Note that this requires considerably more memory because the PXE image
-is loaded into memory. Also that qemu's TFTP server is very slow and
+is loaded into memory. Also that qemu’s TFTP server is very slow and
the virt-p2v PXE image is very large, so it can appear to "hang" after
pxelinux starts up.
diff --git a/p2v/virt-p2v-make-kiwi.pod b/p2v/virt-p2v-make-kiwi.pod
index 0b5c35c87..ac5e97dd6 100644
--- a/p2v/virt-p2v-make-kiwi.pod
+++ b/p2v/virt-p2v-make-kiwi.pod
@@ -28,7 +28,7 @@ Using virt-p2v-make-kiwi is very simple:
virt-p2v-make-kiwi
-will build a kiwi configuration based on the current machine's distribution.
+will build a kiwi configuration based on the current machine’s distribution.
To control the name of the output folder, use the I<-o> parameter.
diff --git a/p2v/virt-p2v.pod b/p2v/virt-p2v.pod
index 7fd637152..127fb891c 100644
--- a/p2v/virt-p2v.pod
+++ b/p2v/virt-p2v.pod
@@ -65,7 +65,7 @@ disk space to do the conversion, and as long as the physical machine
can connect directly to its SSH port. (See also
L<virt-v2v(1)/RESOURCE REQUIREMENTS>).
-Because all of the data on the physical server's hard drive(s) has to
+Because all of the data on the physical server’s hard drive(s) has to
be copied over the network, the speed of conversion is largely
determined by the speed of the network between the two machines.
@@ -348,7 +348,7 @@ user (default: do not use sudo).
=item B<p2v.name=GUESTNAME>
The name of the guest that is created. The default is to try to
-derive a name from the physical machine's hostname (if possible) else
+derive a name from the physical machine’s hostname (if possible) else
use a randomly generated name.
=item B<p2v.vcpus=NN>
@@ -715,7 +715,7 @@ randomly chosen and is displayed in the GUI. It has the form:
/tmp/virt-p2v-YYYYMMDD-XXXXXXXX
-where C<YYYYMMDD> is the current date, and the X's are random
+where C<YYYYMMDD> is the current date, and the ‘X’s are random
characters.
Into this directory are written various files which include:
diff --git a/rescue/virt-rescue.pod b/rescue/virt-rescue.pod
index 5cfbd6e1c..584df9dc2 100644
--- a/rescue/virt-rescue.pod
+++ b/rescue/virt-rescue.pod
@@ -35,11 +35,11 @@ For live VMs you I<must> use the I<--ro> option.
When you run virt-rescue on a virtual machine or disk image, you are
placed in an interactive bash shell where you can use many ordinary
Linux commands. What you see in F</> (F</bin>, F</lib> etc) is the
-rescue appliance. You must mount the virtual machine's filesystems.
+rescue appliance. You must mount the virtual machine’s filesystems.
There is an empty directory called F</sysroot> where you can mount
filesystems.
-To automatically mount the virtual machine's filesystems under
+To automatically mount the virtual machine’s filesystems under
F</sysroot> use the I<-i> option. This uses libguestfs inspection to
find the filesystems and mount them in the right place. You can also
mount filesystems individually using the I<-m> option.
diff --git a/resize/virt-resize.pod b/resize/virt-resize.pod
index 98c4b1017..14c682e7f 100644
--- a/resize/virt-resize.pod
+++ b/resize/virt-resize.pod
@@ -28,7 +28,7 @@ those manual pages first.
=item 1.
-Copy C<olddisk> to C<newdisk>, extending one of the guest's partitions
+Copy C<olddisk> to C<newdisk>, extending one of the guest’s partitions
to fill the extra 5GB of space.
virt-filesystems --long -h --all -a olddisk
@@ -77,7 +77,7 @@ of a raw disk:
=item 2. Locate input disk image
Locate the input disk image (ie. the file or device on the host
-containing the guest's disk). If the guest is managed by libvirt, you
+containing the guest’s disk). If the guest is managed by libvirt, you
can use C<virsh dumpxml> like this to find the disk image name:
# virsh dumpxml guestname | xpath /domain/devices/disk/source
@@ -792,7 +792,7 @@ derived from them, for supporting the C<xfs> filesystem.
Virt-resize has no support for expanding that type of filesystem.
-In this case, there's nothing that can be done to let virt-resize
+In this case, there’s nothing that can be done to let virt-resize
expand that type of filesystem.
=back
diff --git a/sysprep/sysprep_operation_script.ml b/sysprep/sysprep_operation_script.ml
index e3663eba5..aa656727e 100644
--- a/sysprep/sysprep_operation_script.ml
+++ b/sysprep/sysprep_operation_script.ml
@@ -119,10 +119,10 @@ Use one or more I<--script> parameters to specify scripts or
programs
that will be run against the guest.
The script or program is run with its current directory being the
-guest's root directory, so relative paths should be used. For
+guest’s root directory, so relative paths should be used. For
example: C<rm etc/resolv.conf> in the script would remove a Linux
-guest's DNS configuration file, but C<rm /etc/resolv.conf> would
-(try to) remove the host's file.
+guest’s DNS configuration file, but C<rm /etc/resolv.conf> would
+(try to) remove the host’s file.
Normally a temporary mount point for the guest is used, but you
can choose a specific one by using the I<--scriptdir> parameter.
@@ -148,8 +148,8 @@ will be created."
extra_pod_argval = Some "SCRIPT";
extra_pod_description = s_"\
Run the named C<SCRIPT> (a shell script or program) against the
-guest. The script can be any program on the host. The script's
-current directory will be the guest's root directory.
+guest. The script can be any program on the host. The script’s
+current directory will be the guest’s root directory.
B<Note:> If the script is not on the $PATH, then you must give
the full absolute path to the script.";
diff --git a/sysprep/sysprep_operation_udev_persistent_net.ml
b/sysprep/sysprep_operation_udev_persistent_net.ml
index d0ddd5328..b1a2ad0d0 100644
--- a/sysprep/sysprep_operation_udev_persistent_net.ml
+++ b/sysprep/sysprep_operation_udev_persistent_net.ml
@@ -34,7 +34,7 @@ let op = {
enabled_by_default = true;
heading = s_"Remove udev persistent net rules";
pod_description = Some (s_"\
-Remove udev persistent net rules which map the guest's existing MAC
+Remove udev persistent net rules which map the guest’s existing MAC
address to a fixed ethernet device (eg. eth0).
After a guest is cloned, the MAC address usually changes. Since the
diff --git a/sysprep/sysprep_operation_utmp.ml b/sysprep/sysprep_operation_utmp.ml
index 3c9c6deee..2c8860dd0 100644
--- a/sysprep/sysprep_operation_utmp.ml
+++ b/sysprep/sysprep_operation_utmp.ml
@@ -36,7 +36,7 @@ let op = {
pod_description = Some (s_"\
This file records who is currently logged in on a machine. In modern
Linux distros it is stored in a ramdisk and hence not part of the
-virtual machine's disk, but it was stored on disk in older distros.");
+virtual machine’s disk, but it was stored on disk in older distros.");
perform_on_filesystems = Some utmp_perform;
}
diff --git a/sysprep/virt-sysprep.pod b/sysprep/virt-sysprep.pod
index 3a50b255c..89ba49426 100644
--- a/sysprep/virt-sysprep.pod
+++ b/sysprep/virt-sysprep.pod
@@ -530,7 +530,7 @@ content in directory entries and inodes.
I<(This section applies to Linux guests only)>
For supported guests, virt-sysprep writes a few bytes of randomness
-from the host into the guest's random seed file.
+from the host into the guest’s random seed file.
If this is just done once and the guest is cloned from the same
template, then each guest will start with the same entropy, and things
diff --git a/test-tool/libguestfs-test-tool.pod b/test-tool/libguestfs-test-tool.pod
index 468399334..589b2aac9 100644
--- a/test-tool/libguestfs-test-tool.pod
+++ b/test-tool/libguestfs-test-tool.pod
@@ -101,7 +101,7 @@ different (eg. upstream) version of libvirt by running these commands
~/path/to/libvirt/run libguestfs-test-tool
The first command kills any session C<libvirtd> process(es) that may
-be running on the machine. The second command uses libvirt's C<run>
+be running on the machine. The second command uses libvirt’s C<run>
script (in the top-level libvirt build directory) to set some
environment variables so that the alternate version of libvirt is used
to run the program.
diff --git a/tests/qemu/qemu-snapshot-isolation.sh
b/tests/qemu/qemu-snapshot-isolation.sh
index 3406b2a14..a2542a7e4 100755
--- a/tests/qemu/qemu-snapshot-isolation.sh
+++ b/tests/qemu/qemu-snapshot-isolation.sh
@@ -87,7 +87,7 @@ function serious_error
echo
echo
echo "***** SERIOUS ERROR *****"
- echo "qemu's snapshot isolation does not appear to be working."
+ echo "qemu’s snapshot isolation does not appear to be working."
echo "Running libguestfs could cause disk corruption on live guests."
echo
echo "DO NOT USE libguestfs before you have resolved this problem."
diff --git a/v2v/OVF.ml b/v2v/OVF.ml
index 5c2ebc9a8..719158ec7 100644
--- a/v2v/OVF.ml
+++ b/v2v/OVF.ml
@@ -421,7 +421,7 @@ let rec create_ovf source targets guestcaps inspect
*)
(match source with
| { s_display = Some { s_password = Some _ } } ->
- warning (f_"This guest required a password for connection to its display, but
this is not supported by RHV. Therefore the converted guest's display will not
require a separate password to connect.");
+ warning (f_"This guest required a password for connection to its display, but
this is not supported by RHV. Therefore the converted guest’s display will not require a
separate password to connect.");
| _ -> ());
if verbose () then (
diff --git a/v2v/test-harness/virt-v2v-test-harness.pod
b/v2v/test-harness/virt-v2v-test-harness.pod
index 280aa02f6..0fb56353a 100644
--- a/v2v/test-harness/virt-v2v-test-harness.pod
+++ b/v2v/test-harness/virt-v2v-test-harness.pod
@@ -55,7 +55,7 @@ L<git-annex(1)> to distribute the test images.
=head2 REQUIREMENTS
-It's recommended to use an idle machine for testing. You will need
+It’s recommended to use an idle machine for testing. You will need
B<a lot of disk space> to run the tests, in excess of S<100 GB>. You
should also ensure the test machine has plenty of RAM, at least
S<16 GB>.
@@ -215,7 +215,7 @@ When you run each test, the following files can be created:
=item I<test>-I<yyyymmdd-hhmmss>.scrn
-Screenshot(s) of the guest's graphical console. These are helpful
+Screenshot(s) of the guest’s graphical console. These are helpful
when writing tests or debugging test failures.
The screenshot format is Portable Pixmap (PPM).
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
index 838b5986f..6d8a2017c 100644
--- a/v2v/virt-v2v.pod
+++ b/v2v/virt-v2v.pod
@@ -434,7 +434,7 @@ Set the output method to I<local>.
In this mode, the converted guest is written to a local directory
specified by I<-os /dir> (the directory must exist). The converted
-guest's disks are written as:
+guest’s disks are written as:
/dir/name-sda
/dir/name-sdb
@@ -952,7 +952,7 @@ I<--print-source> option which causes virt-v2v to print out the
information it has about the guest on the source and then exit.
In the I<--print-source> output you will see a section showing the
-guest's Network Interface Cards (NICs):
+guest’s Network Interface Cards (NICs):
$ virt-v2v [-i ...] --print-source name
[...]
@@ -1089,7 +1089,7 @@ like this:
If you get an error "Peer certificate cannot be authenticated with
given CA certificates" or similar, then you can either import the
-vCenter host's certificate, or bypass signature verification by adding
+vCenter host’s certificate, or bypass signature verification by adding
the C<?no_verify=1> flag:
$ virsh -c 'vpx://root@vcenter.example.com/Datacenter/esxi?no_verify=1' list
--all
@@ -1202,7 +1202,7 @@ B<ignored> when doing vCenter conversions.
=head1 INPUT FROM VMWARE OVA
-Virt-v2v is able to import guests from VMware's OVA (Open
+Virt-v2v is able to import guests from VMware’s OVA (Open
Virtualization Appliance) files. Only OVAs exported from VMware
vSphere will work.
@@ -1229,7 +1229,7 @@ contents.
=head3 Create OVA with ovftool
-You can also use VMware's proprietary C<ovftool>:
+You can also use VMware’s proprietary C<ovftool>:
ovftool --noSSLVerify \
vi://USER:PASSWORD@esxi.example.com/VM \
@@ -1395,7 +1395,7 @@ L<libvirt bug 1140166|https://bugzilla.redhat.com/1140166> is
fixed.
=head2 XEN OR SSH CONVERSIONS FROM BLOCK DEVICES
Currently virt-v2v cannot directly access a Xen guest (or any guest
-located remotely over ssh) if that guest's disks are located on host
+located remotely over ssh) if that guest’s disks are located on host
block devices.
To tell if a Xen guest uses host block devices, look at the guest XML.
@@ -1459,9 +1459,9 @@ metadata into a local temporary directory:
This creates two (or more) files in F</var/tmp> called:
/var/tmp/NAME.xml # the libvirt XML (metadata)
- /var/tmp/NAME-sda # the guest's first disk
+ /var/tmp/NAME-sda # the guest’s first disk
-(for C<NAME> substitute the guest's name).
+(for C<NAME> substitute the guest’s name).
=item 2.
@@ -1683,7 +1683,7 @@ faster.
=head2 Guest network configuration
-Virt-v2v cannot currently reconfigure a guest's network configuration.
+Virt-v2v cannot currently reconfigure a guest’s network configuration.
If the converted guest is not connected to the same subnet as the
source, its network configuration may have to be updated. See also
L<virt-customize(1)>.
--
2.12.0