Ancient qemu 1.5 (in RHEL 7) does not understand the
file.file.filename= and file.driver= parameters. Go back to using the
old-style file= and format= parameters when we're not trying to set
the file.backing.file.locking=off parameter.
Fixes commit 9fe592808c.
Thanks: Yongkui Guo, Václav Kadlčík.
ocamlmklib will get confused if the -cclib parameter expands to
anything except a single -lxml2 argument. In any case it's not
necessary to specify the linker command here since every use of this
library links in a program to libxml2.
We routinely test the upstream code by running everything under
valgrind, and in any case _FORTIFY_SOURCE is usually defined by
downstream Linux distros and we can leave the optimization vs safety
decision to them.
See this bug: https://bugs.gentoo.org/640494
In some cases, the first stage bootloader needs the 'Legacy BIOS
bootable' flag to be set on the partition. This change copies all
flags (including this one) for each partition of the old disk to the
new one to avoid ending up with non-bootable disks.
Rename the sgdisk_info_extract_uuid_field to
sgdisk_info_extract_field in order to reuse it for other field types.
Just like its C ancestor, it now needs an extractor function to be
passed as parameter.
Test guestfish finds:
1. md device created from physical block device and LV,
2. md device created from LVs
3. LV created on md device
raid0 is used for md device because it is inoperable if one of its components is inaccessible so it is easy observable that md device is missing (raid1 in this case will be operable but in degraded state).
The issue:
- raid1 will be in degraded state if one of its components is logical volume (LV)
- raid0 will be inoperable at all (inacessible from within appliance) if one of its component is LV
- raidN: you can expect the same issue for any raid level depends on how many components are inaccessible at the time mdadm is running and raid redundency.
It happens because mdadm is launched prior to lvm AND it is instructed to run found arrays immediately (--run flag) regardless of completeness of their components.
Later (when lvm activates found LVs) md signature on LV might be recognized BUT newly found raid components could't be inserted into already running (in degraded state)
or marked as inoperable raid arrays.
The patch fixes the issue in the following way:
1. Found arrays won't be run immediately unless ALL expected drives (components) are present. Here '--no-degraded' flag comes into a play. See mdadm(8).
2. Second mdadm call (after LVM is scanned) will scan UNUSED yet devices and make an attempt to run all found arrays (even they will be in degraded state).
There is no performance penalty because second pass scans UNUSED yet devices. Here is 'boot-benchmark' before and after patch:
: libvirt backend : direct backend
------------------------------------------------
master : 835.2ms ±1.1ms : 670.4ms ±0.3ms
master+patch : 837.7ms ±2.4ms : 671.8ms ±0.2ms
According to 'guestfs_sync' API method documentation: "You should always call this if you have modified a disk image, before closing the handle."
So, 'guestfish --remote sync' is required because changes made on the disk (guestfish --remote rm /tail) should be visible to 'virt-tail' which works in different process and also accessing the same disk.
A you can see, other changes done via 'guestfish --remote' in this test are flushed via a 'sync' command.
The test is failing spontaneously beasue without 'sync' it very depends on outside factors like qemu caching policy, underlying host filesystem etc.
This allows us to easily see from trace output (‘virt-diff -x’) which
handle is being used for each call. Otherwise you get meaningless
output such as:
libguestfs: trace: download "/Windows/WindowsUpdate.log" "/tmp/virtdiffy9m5YW/a"
libguestfs: trace: download = 0
libguestfs: trace: download "/Windows/WindowsUpdate.log" "/tmp/virtdiffy9m5YW/b"
libguestfs: trace: download = 0
Thanks: Xiang Hua Chen
Someone following this example started by literally copying "olddisk"
to "newdisk", which doesn't work (the target must always be blank).
Clarify the wording.
This enhances the existing VMX input support allowing it to be
used over SSH to the ESXi server.
The original command (for local .vmx files) was:
$ virt-v2v -i vmx guest.vmx -o local -os /var/tmp
Adding ‘-it ssh’ and using an SSH remote path gives the new syntax:
$ virt-v2v \
-i vmx -it ssh \
"ssh://root@esxi.example.com/vmfs/volumes/datastore1/guest/guest.vmx" \
-o local -os /var/tmp
I anticipate that this input method will be widely used enough that it
deserves its own example at the top of the man page.
Previously the presence of the ‘--vddk <libdir>’ option magically
enabled VDDK mode. However we want to introduce other transports for
VMware conversions so this wasn't a very clean choice.
With this commit you must use ‘-it vddk’ to specify that you want VDDK
as a disk transport. The previous ‘--vddk <libdir>’ option has been
renamed to ‘--vddk-libdir <libdir>’ to be consistent with the other
passthrough options, and it is no longer required.
A new command line looks like:
$ export PATH=/path/to/nbdkit:$PATH
$ virt-v2v \
-ic 'vpx://root@vcenter.example.com/Datacenter/esxi?no_verify=1' \
| -it vddk \
| --vddk-libdir /path/to/vmware-vix-disklib-distrib \
--vddk-thumbprint xx:xx:xx:... \
"Windows 2003" \
-o local -os /var/tmp
where only the two lines marked with ‘|’ have changed.
This is an unexpected error, so fail hard instead of leaking
End_of_file exception.
Nothing that calls into the Urandom module expects or handles
End_of_file.
Certain transitions where the input and output filename are the same
are impossible, eg copying a file to itself. Don't add these.
Reported-by: David Kaylor.
This adds a ‘return’ statement as found in other programming
languages. You can use it like this:
with_return (fun {return} ->
some code ...
)
where ‘some code’ may either return implicitly (as usual), or may call
‘return x’ to immediately return ‘x’. All returned values must have
the same type.
The OCaml >= 4.04 implementation is by Petter A. Urkedal and octachron.
See this thread:
https://sympa.inria.fr/sympa/arc/caml-list/2017-11/msg00017.html
The version that works for any OCaml is by me. (Note that my version
cannot be nested).
However some existing functions had names which shadowed existing
functions in the List module, so I had to rename them:
assoc -> List.assoc_lbl
append -> List.push_back_list
prepend -> List.push_front_list
This is an extension of the previous commit.
We defined a number of functions on lists which are not provided by
the standard library. As with Char and String, let's extend List to
add these new functions to a List pseudo-module (really
Std_utils.List, but called List when you ‘open Std_utils’).
The initial exported functions are all List functions from OCaml 3.11
+ iteri + mapi. We can add other functions as needed.
When caching all the templates, use the architecture of each template,
instead of the architecture passed as --arch (or the host architecture,
as default). This way, the right destination filename will be used.
Fixes commit b1cf6246f3.
Thanks to: Erik Skultety.
It wasn't actually used for anything significant. Even worse
virt-v2v-copy-to-local made up a scheme out of thin air.
Just code refactoring, no functional change.
Commit aa9e0057b1 made the libvirt backend
use <shareable/> for the disk of the appliance, since at that time all
the instances were using the disk directly.
OTOH, commit 3ad44c8660 switched to
overlays for read-only disks, including the appliance, so effectively
protecting the appliance.
Because of this, the libvirt backend does not need <shareable/> anymore.
Thanks to: Daniel Berrange, Richard W.M. Jones, Peter Krempa.
When using grubby to get the default kernel of a guest, do not fail
with a bogus error like:
virt-v2v: error: libguestfs error: statns: statns_stub: path must start
with a / character
in case there is no default kernel that can be determined (e.g. because
of a bogus configuration).
