Two tests opened the phony Fedora image in parallel without the
readonly flag. This occasionally resulted in strange errors
(especially observed in test-inspect.sh). Add the --readonly flag to
avoid this.
- add a flag to request chroot for the process, which is done only as
very last (before chdir) operation before exec'ing the process in the
child: this avoids using CHROOT_IN & CHROOT_OUT around command*
invocations, and reduces the code spent in chroot mode
- add failure checks for dup2, open, and chdir done in child, not
proceeding to executing the process if they fail
- open /dev/null without O_CLOEXEC, so it stays available for the
exec'ed process, and thus we don't need to provide an own fd for stdin
Followup of commit fd2f175ee7, thanks also
to the notes and hints provided by Mateusz Guzik.
Prior to this commit:
$ virt-builder --help
[...]
--sm-attach SELECTOR Attach to a subscription-manager pool
--sm-credentials SELECTOR credentials for subscription-manager
--sm-register Register using subscription-manager
Really the generator ought to check this.
'sfdisk --part-type' used to merely set the MBR ID byte in the
partition. However since sfdisk was rewritten, it now "helpfully"
corrupts the first sector of the partition if you change the type byte
from an ordinary partition to an extended partition.
So we need to change the order in which we sets the partition type
byte, to do it before copying the partition content.
This fixes a major regression in the way that virt-resize handles any
guest with logical partitions (specifically Ubuntu guests).
If uncompressing a template to a filesystem which is nearly full,
virt-builder displays an error which points to the wrong (source) file:
$ virt-builder fedora-22
[ 1.2] Downloading: http://libguestfs.org/download/builder/fedora-22.xz
[ 1.7] Planning how to build this image
[ 1.7] Uncompressing
/home/rjones/.cache/virt-builder/fedora-22.x86_64.1: No space left on device
/home/rjones/.cache/virt-builder/fedora-22.x86_64.1: No space left on device
/home/rjones/.cache/virt-builder/fedora-22.x86_64.1: No space left on device
/home/rjones/.cache/virt-builder/fedora-22.x86_64.1: No space left on device
(The error message is usually printed once by each thread, so it is
printed several times.)
Change the error message to point to the output file, which might be a
temporary or the final file depending on the build plan:
$ virt-builder fedora-22
[ 1.1] Downloading: http://libguestfs.org/download/builder/fedora-22.xz
[ 1.6] Planning how to build this image
[ 1.6] Uncompressing
fedora-22.img: No space left on device
fedora-22.img: No space left on device
fedora-22.img: No space left on device
fedora-22.img: No space left on device
On ARM machines with vGICv3, we need to use the extra -M
parameter gic-version=3 (or gic-version=2 for the old vGIC).
qemu can detect this feature for us if we pass gic-version=host,
so add that to the -M option. Unfortunately we cannot detect if
qemu itself supports this parameter, but this change only affects
aarch64.
Thanks: Wei Huang
Exit with 3 as return value when fusermount fails, because the specified
mount point is not considered mounted for the user. This is in line
with what the guestunmount documentation says.
Adapt the test-guestunmount-fd test to the updated return value.
Thanks to: Maxim Perevedentsev.
When running commands in the mounted guest (using the "command" API, and
APIs based on it), provide the /dev/null from the appliance as open fd
for stdin. Commands usually assume stdin is open if they didn't close
it explicitly, so this should avoid crashes or misbehavings due to that.
Older GCC versions (e.g. < 4.9) may complain about inline functions that
cannot be inlined (growing the generated code). It is not really a
problem for us, so just suppress again the warning.
Followup of commit c37c554fc5.
This allows certain guests which virt-v2v cannot access to be copied
off the remote hypervisor and converted. Essentially this just
automates the process of copying the guest's disks and adjusting the
libvirt XML.
This also adds a test of the new tool.
Split the map_source_to_uri function up so that we can get at just the
https://... URI.
This is almost refactoring. It doesn't quite handle the case where we
are passed a source path from the libvirt VMware driver that doesn't
match the expected "[datastore] path" format, but probably if we hit
that case it's a bug anyway.
If you try to convert a guest that has a zero-sized disk, it
will currently fail in a rather strange way. Usually you will
see errors in the debug output:
[ 0.562714] sd 2:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 0.563884] sd 2:0:0:0: [sda] Sense Key : Not Ready [current]
[ 0.564587] sd 2:0:0:0: [sda] Add. Sense: Logical unit not ready, manual intervention required
followed by virt-v2v failing with:
libguestfs: trace: v2v: inspect_os = []
virt-v2v: error: inspection could not detect the source guest (or physical
machine).
Additionally, because of a problem with the ssh driver in qemu (or
perhaps, with sftp-server on the remote side) it is not possible to
use the ssh driver to open a block device path on the remote server.
The drive will appear as zero-sized, triggering the above error.
Therefore detect this situation, and emit an error (see below). Also
add a section to the manual describing the workaround required for
converting RHEL 5 Xen guests which are located on block devices.
virt-v2v: error: guest disk sda appears to be zero bytes in size.
There could be several reasons for this:
Check that the guest doesn't really have a zero-sized disk. virt-v2v
cannot convert such a guest.
If you are converting a guest from an ssh source and the guest has a disk
on a block device (eg. on a host partition or host LVM LV), then
conversions of this type are not supported. See "XEN OR SSH CONVERSIONS
FROM BLOCK DEVICES" in the virt-v2v(1) manual for a workaround.
If the user tries to close the running dialog during a running
conversion, act as if the cancel button was pressed (cancelling the
conversion).
If the conversion has finished/been cancelled, then this closes the
dialog and exits virt-p2v, as now.
Cancelling the conversion in this way ensures that qemu-nbd and ssh
subprocesses are cleaned up.
If the virt-p2v ISO doesn't contain the correct drivers for the
hardware on the physical server, that can cause peculiar conversion
problems. This was hard to diagnose because we could not see the
'dmesg' output from the physical server.
Upload 'dmesg' output from the physical server (more precisely: from
the virt-p2v ISO's kernel running on the physical server) to the
virt-v2v conversion server debugging directory, so that this
information is available for debugging later.
Unfortunately this involves yet another copy of the 'read_whole_file'
function.
Instead of creating a special 'Exported by ...' string just for this
module, use the Common_utils.generated_by string. Since the string is
just descriptive, this should make no difference.
