Otherwise the man page cannot contain any non-7-bit-ASCII characters. The test error seen was: Wide character in print at /usr/share/perl5/vendor_perl/Test2/Formatter/TAP.pm line 112. t/910-pod.t ................ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests --- generator/perl.ml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/generator/perl.ml b/generator/perl.ml index 3a87f1634..d1b4763b8 100644 --- a/generator/perl.ml +++ b/generator/perl.ml @@ -664,6 +664,8 @@ and generate_perl_pm () = generate_header HashStyle LGPLv2plus; pr "\ +=encoding utf8 + =pod =head1 NAME -- 2.12.0

On 03/31/2017 04:32 AM, Richard W.M. Jones wrote: The `' form of quoting is definitely out of style. But these days, it is debatable whether ASCII '' or Unicode ‘’ is better as the default; since it is still not guaranteed that everyone is using a UTF-8 console. Coreutils uses '', if that helps the decision any, but I'm fine with whatever you think looks best. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

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