mirrors/libguestfs
1
0
Fork 0
mirror of https://github.com/libguestfs/libguestfs.git synced 2026-03-21 22:53:37 +00:00
Code Issues Packages Projects Releases Wiki Activity

Replace possessive ASCII apostrophe ('s) with Unicode apostrophe (’s).

Browse Source 
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
This commit is contained in:
Richard W.M. Jones
2017-03-30 22:11:56 +01:00
parent 126ef5d082
commit 8c58b62f9d
37 changed files with 113 additions and 113 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
appliance/init
View File

@@ -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."

34
builder/virt-builder.pod
View File

@@ -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.

2
cat/virt-cat.pod
View File

@@ -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:

2
cat/virt-filesystems.pod
View File

@@ -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.

2
cat/virt-ls.pod
View File

@@ -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.

2
df/virt-df.pod
View File

@@ -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.

4
dib/virt-dib.pod
View File

@@ -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>

2
diff/virt-diff.pod
View File

@@ -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.

4
docs/guestfs-building.pod
View File

@@ -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.

30
docs/guestfs-faq.pod
View File

@@ -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.html>
=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

6
docs/guestfs-hacking.pod
View File

@@ -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

4
docs/guestfs-internals.pod
View File

@@ -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).

4
docs/guestfs-performance.pod
View File

@@ -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 *

2
docs/guestfs-recipes.pod
View File

@@ -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:

6
docs/guestfs-security.pod
View File

@@ -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.

6
edit/virt-edit.pod
View File

@@ -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:

22
generator/actions_core.ml
View File

@@ -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>

4
generator/actions_inspection.ml
View File

@@ -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.

10
generator/customize.ml
View File

@@ -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.

2
generator/java.ml
View File

@@ -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>

2
inspector/virt-inspector.pod
View File

@@ -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

8
lib/guestfs.pod
View File

@@ -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

2
p2v/virt-p2v-make-disk.in
View File

@@ -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

2
p2v/virt-p2v-make-kickstart.pod
View File

@@ -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.

2
p2v/virt-p2v-make-kiwi.pod
View File

@@ -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.

6
p2v/virt-p2v.pod
View File

@@ -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:

4
rescue/virt-rescue.pod
View File

@@ -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.

6
resize/virt-resize.pod
View File

@@ -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

10
sysprep/sysprep_operation_script.ml
View File

@@ -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.";

2
sysprep/sysprep_operation_udev_persistent_net.ml
View File

@@ -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

2
sysprep/sysprep_operation_utmp.ml
View File

@@ -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;
}

2
sysprep/virt-sysprep.pod
View File

@@ -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

2
test-tool/libguestfs-test-tool.pod
View File

@@ -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.

2
tests/qemu/qemu-snapshot-isolation.sh
View File

@@ -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."

2
v2v/OVF.ml
View File

@@ -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 (

4
v2v/test-harness/virt-v2v-test-harness.pod
View File

@@ -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).

18
v2v/virt-v2v.pod
View File

@@ -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)>.