Appliance device names are not reliable since the kernel no longer
enumerates virtio-scsi devices serially. Instead get the UUID of the
appliance and pass this as the parameter.
Note this requires supermin >= 5.1.18 (from around July 2017).
Linux from around 5.6 now enumerates individual disks in any order
(whereas previously it enumerated only drivers in parallel). This
means that /dev/sdX ordering is no longer stable - in particular we
cannot be sure that /dev/sda inside the guest is the first disk that
was attached to the appliance, /dev/sdb the second disk and so on.
However we can still use SCSI PCI device numbering as found in
/dev/disk/by-path. Use this to translate device names in and out of
the appliance.
Thanks: Vitaly Kuznetsov, Paolo Bonzini, Dan Berrangé.
In the guestfs_disk_create API we have traditionally allowed you to
set backingfile without setting backingformat. The meaning of this is
to let qemu autodetect the backing format when opening the overlay
disk.
However libvirt >= 6.0 refuses to even pass such disks to qemu (see
https://bugzilla.redhat.com/show_bug.cgi?id=1798148).
For this reason, move the autodetection earlier and make it explicit.
We now autodetect the format of the backing disk at the time of
creation of the overlay, and set that as the backing format in the
overlay disk itself, allowing libvirt to open the disk later.
This symbol is not present in Python 2.7 or 3.6. It's not really
necessary to call this, it just avoids a crash in certain corner cases
when the interpreter is shutting down. So make the call conditional
on the function existing.
Fixes commit e6f9e0b0f6.
This function doesn't work reliably with the proposed change to device
name translation. The reason is that strings returned by
Devsparts.list_devices contained translated names, so their indexes
did not correspond to the untranslated names used outside the
appliance..
We can avoid this and make the function much simpler and faster by
implementing it on the library side instead.
Although it's highly unlikely in normal use, while testing device name
translation patches it did happen and caused the test to segfault
instead of exiting with an error.
Already outdated, but rounded ;)
I literally just opened the 5yrs logo, changed the text and then done:
inkscape -z -o logo/fish-10yrs.{png,svg}
cp {logo,website}/fish-10yrs.svg
and then updated the rest of the files.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The current way to get the size of a filesystem is to query the size in
bytes of the device. However, this gives the whole size of the device
where a filesystem is stored, and it does not consider the actual size
for which the filesystem is configured (e.g. in case it was shrunk).
A simple reproducer for this is:
$ guestfish -N test.img=fs:ext4:2G resize2fs-size /dev/sda1 1073741824
As result, try to mount the filesystem, and get its actual statistics to
determine its full size. In case mounting fails, fall back to the
previous method, which is still a good value in the majority of the
cases.
Thanks to: Erik Skultety.
This patch adds '--blocksize' command line option for virt-make-fs
tool. This option allows specifying disk sector size as described in
'guestfs_add_drive_opts' libguestfs API.
On current Fedora releases the ocaml modules will fail to
link unless CFLAGS contains -fPIC.
The autogen.sh script only updates the 'gnulib' submodule,
and so the build will fail due to the missing 'common'
submodule. This needs to be manually initialized at checkout.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The first split does not care about the whole string, it is just trying to get
the command name in front, so triml is just right.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Seeing `g.add_drive_opt :readonly => 1` allows one to imply
that ensuring writable access to drive should happen via
`g.add_drive_opt :readonly => 0`. However, the passed option
value gets passed down to C according to Ruby Boolean semantics,
that is, any value apart from `false` and `nil` will be true
(see RTEST in Ruby C API).
So its more idiomatic and provides a better hint if we use
`g.add_drive_opt :readonly => true` in Ruby samples.
Go API functions returned (<val>, *GuestfsError) that made
code like this fail to build:
n, err := os.Stdin.Read(buf)
if err != nil {
log.Fatal(err)
}
n, err = g.Pwrite_device(dev, buf[:n], off)
...
As err should be of error (interface) type as of the stdlib call,
and should be of *GuestfsError type as of the libguestfs call.
The concrete error value that libguestfs functions return can be
a *GuestfsError, but the function signature should have (<val>, error)
as return value.
This patch adds '--blocksize' command line option for virt-get-kernel
tool. This option allows specifying disk sector size as described in
'guestfs_add_drive_opts' libguestfs API.
This package in Fedora enables optional support for Windows 10
"CompactOS" (file-level compression), read-only, which is sufficient
for inspecting Windows guests and doing certain types of modifications
to them. Virt-v2v appears to work, but it may be that anything that
involves modifying a compressed file might not work.
I couldn't find the equivalent package in Debian or SUSE. It's
available in Arch AUR although I didn't verify that part of the change
actually works there (but should be safe because supermin ignores
packages that are not known about on the target system).
Nowadays there are hard drives and operating systems which support
"4K native" sector size. In this mode physical and logical block size
exposed to the operating system is equal to 4096 bytes.
GPT partition table (as a known example) being created in this mode will
place GPT header at LBA1 which is 4096 bytes. libguetfs is unable to
recognize partition table on such physical block devices or disk images.
The reason is that libguestfs appliance will look for a GPT header at
LBA1 which is seen at 512 byte offset.
In order to fix the issue we need a way to provide correct logical block
size for attached disks. Fortunately QEMU and libvirt already provides
a way to specify physical/logical block size per disk basis.
After discussion in a mailing list we agreed that physical block size is
rarely used and is not so important. Thus both physical and logical
block size will be set to the same value.
In this patch one more optional parameter 'blocksize' is added
to add_drive_opts API method. Valid values are 512 and 4096.
add_drive_scratch has the same optional parameter for a consistency and
testing purpose.
add-domain and add_libvirt_dom will pass logical_block_size value from
libvirt XML to add_drive_opts method.
Libvirt 6.0 now requires that every disk in the backing chain has an
explicit backing format. For example this will be rejected by
libvirt:
qemu-img create -f qcow2 -b backing-disk disk.qcow2
with the error:
Original error from libvirt: Requested operation is not valid:
format of backing image 'backing-disk' of image 'disk.qcow2' was not
specified in the image metadata (See
https://libvirt.org/kbase/backing_chains.html for troubleshooting)
[code=55 int1=-1]
Instead you have to use the -F option to specify the format, eg:
qemu-img create -f qcow2 -b backing-disk -F raw disk.qcow2
I believe this warning is bogus, but simply initializing the local
variable is enough to avoid it.
log.c: In function 'do_log':
log.c:390:7: error: 'comm_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
390 | printf (" %.*s", (int) comm_len, comm);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The current code was broken, as the field 1 of the exception value is
the error code (int), not an error string, and thus it would have
crashed. This did not happen in practice, as all the usage of
ocaml-augeas were only in the inspection code with ad-hoc exception
catching blocks.
Other than fixing the aforementioned issue, enhance the error reporting
to be as close as possible to what the current AUGEAS_ERROR() macro
does: error message, error minor message (if available), error details
(if available).
Enhance the UEFI firmware lookup function with the information on the
libvirt firmware autoselection, allowing it to return a value to use for
the appliance.
At the moment no firmware is selected this way, so there is no behaviour
change.
