Re: [Libguestfs] [libguestfs/libguestfs] resize with ubuntu-20.04 (#63)
by Peter Willis
> I wonder if there's a way to make Ubuntu templates that don't use
> logical partitions?
The ubuntu 18.04 template was made without logical partitions. They are both in the default set of libguestfs templates.
# virt-filesystems --all --long -h -a ubuntu-18.04.img
Name Type VFS Label MBR Size Parent
/dev/sda1 filesystem ext4 - - 10G -
/dev/sda1 partition - - 83 10G /dev/sda
/dev/sda device - - - 10G -
P.S Sorry I couldn’t figure out how to reply to the existing thread.
5 years
Re: [Libguestfs] [libguestfs/libguestfs] resize with ubuntu-20.04 (#63)
by Richard W.M. Jones
On Mon, Feb 08, 2021 at 04:28:24AM -0800, Peter Willis wrote:
> Is there something I am missing to resize the disk in the ubuntu-20.04
> template?
>
> # virt-builder ubuntu-20.04 --size 30G
> [ 0.8] Downloading: http://builder.libguestfs.org/ubuntu-20.04.xz
> [ 1.8] Planning how to build this image
> [ 1.8] Uncompressing
> [ 10.9] Resizing (using virt-resize) to expand the disk to 30.0G
> virt-resize: error: /dev/sda5: partition not found in the source disk image
> (this error came from ‘--expand’ option on the command line). Try
> running this command: virt-filesystems --partitions --long -a
> /var/tmp/vb7ee275.img
>
> If reporting bugs, run virt-resize with debugging enabled and include the
> complete output:
>
> virt-resize -v -x [...]
>
> Or:
>
> # virt-list-partitions -lh ubuntu-20.04.img
> /dev/sda1 vfat 512.0M
> /dev/sda2 unknown 1K
> /dev/sda5 ext4 5.5G
> # truncate -r ubuntu-20.04.img ubuntu-20.04-resized.img
> # truncate -s +5G ubuntu-20.04-resized.img
> # virt-resize --expand /dev/sda5 ubuntu-20.04.img ubuntu-20.04-resized.img
> [ 0.0] Examining ubuntu-20.04.img
> virt-resize: error: /dev/sda5: partition not found in the source disk image
> (this error came from ‘--expand’ option on the command line). Try
> running this command: virt-filesystems --partitions --long -a
> ubuntu-20.04.img
>
> If reporting bugs, run virt-resize with debugging enabled and include the
> complete output:
>
> virt-resize -v -x [...]
The problem is that this image is incompatible with virt-resize:
$ virt-builder ubuntu-20.04
$ virt-filesystems -a ubuntu-20.04.img --all -l -h
Name Type VFS Label MBR Size Parent
/dev/sda1 filesystem vfat - - 511M -
/dev/sda5 filesystem ext4 - - 5.3G -
/dev/sda1 partition - - 0b 512M /dev/sda
/dev/sda2 partition - - 05 1.0K /dev/sda
/dev/sda5 partition - - 83 5.5G /dev/sda
/dev/sda device - - - 6.0G -
Note the root filesystem is on a logical partition (/dev/sda5) which
virt-resize cannot handle:
https://libguestfs.org/virt-resize.1.html#logical-partitions
I wonder if there's a way to make Ubuntu templates that don't use
logical partitions?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
5 years
(no subject)
by ChromaCat248
1. mount a disk from a windows virtual machine that broke
2. guestmount --add ./win10.vhd --inspector --ro ./mount/
3. libguestfs: error: /usr/bin/supermin exited with error status 1.
4. libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: create: flags = 0, handle = 0x560ec787ee10, program =
guestmount
libguestfs: trace: set_recovery_proc false
libguestfs: trace: set_recovery_proc = 0
libguestfs: trace: add_drive "./win10.vhd" "readonly:true"
libguestfs: creating COW overlay to protect original drive content
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: disk_create
"/tmp/libguestfsZ5RkIL/overlay1.qcow2" "qcow2" -1
"backingfile:/home/chromacat248/Virtualbox VMs/win10/win10.vhd"
libguestfs: command: run: qemu-img
libguestfs: command: run: \ create
libguestfs: command: run: \ -f qcow2
libguestfs: command: run: \ -o
backing_file=/home/chromacat248/Virtualbox VMs/win10/win10.vhd
libguestfs: command: run: \ /tmp/libguestfsZ5RkIL/overlay1.qcow2
qemu-img: warning: Deprecated use of backing file without explicit
backing format (detected format of vpc)
Formatting '/tmp/libguestfsZ5RkIL/overlay1.qcow2', fmt=qcow2
cluster_size=65536 extended_l2=off compression_type=zlib
size=53686272000 backing_file=/home/chromacat248/Virtualbox
VMs/win10/win10.vhd backing_fmt=vpc lazy_refcounts=off refcount_bits=16
libguestfs: trace: disk_create = 0
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: max_disks
libguestfs: trace: max_disks = 255
libguestfs: trace: version
libguestfs: trace: version = <struct guestfs_version = major: 1,
minor: 42, release: 0, extra: , >
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
libguestfs: launch: program=guestmount
libguestfs: launch: version=1.42.0
libguestfs: launch: backend registered: unix
libguestfs: launch: backend registered: uml
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfsZ5RkIL
libguestfs: launch: umask=0022
libguestfs: launch: euid=1000
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: begin building supermin appliance
libguestfs: run supermin
libguestfs: command: run: /usr/bin/supermin
libguestfs: command: run: \ --build
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --if-newer
libguestfs: command: run: \ --lock /var/tmp/.guestfs-1000/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/lib/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-1000/appliance.d
supermin: version: 5.2.0
supermin: package handler: arch/pacman
supermin: acquiring lock on /var/tmp/.guestfs-1000/lock
supermin: build: /usr/lib/guestfs/supermin.d
supermin: reading the supermin appliance
supermin: build: visiting /usr/lib/guestfs/supermin.d/base.tar.gz
type gzip base image (tar)
supermin: build: visiting /usr/lib/guestfs/supermin.d/daemon.tar.gz
type gzip base image (tar)
supermin: build: visiting /usr/lib/guestfs/supermin.d/excludefiles
type uncompressed excludefiles
supermin: build: visiting /usr/lib/guestfs/supermin.d/hostfiles type
uncompressed hostfiles
supermin: build: visiting /usr/lib/guestfs/supermin.d/init.tar.gz
type gzip base image (tar)
supermin: build: visiting /usr/lib/guestfs/supermin.d/packages type
uncompressed packages
supermin: build: visiting
/usr/lib/guestfs/supermin.d/udev-rules.tar.gz type gzip base image (tar)
supermin: mapping package names to installed packages
supermin: resolving full list of package dependencies
supermin: failure: failed to parse epoch:version-release field 29-1.0
libguestfs: error: /usr/bin/supermin exited with error status 1, see
debug messages above
libguestfs: trace: launch = -1 (error)
libguestfs: trace: close
libguestfs: closing guestfs handle 0x560ec787ee10 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsZ5RkIL
5. guestmount 1.42.0, installed on manjaro 20.2.1 using yay 10.1.0
5 years
[PATCH v3 0/7] v2v: rhv-upload-plugin: Performance improvments
by Nir Soffer
Update the plugin to API_VERSION 2, and enable parallel threading model. With
unordered writes in qemu-img, and 8 threads in nbdkit, matching number of
parallel coroutines in qemu-img, I see about 50% speedup compared with current
master.
I tested this on a vm, using NFS storage provided by another vm, and accessing
ovirt-engine on a third vm. Results are not stable, and can vary by 100%
between runs. I'm comparing the best result from 3-5 runs.
We need to test these changes with real images, real servers, and real storage
to get more reliable results, but I could not find avilable server yet.
Changes since v2:
- Add plugin#write_out_order method and use it to enable out of order writes
(-W) in the rhv upload plugin.
- Update the commit message about fua and flush support, based on the
discussion with Eric.
- Fix more typos in comments
v2 was here:
https://www.redhat.com/archives/libguestfs/2021-January/msg00067.html
Nir Soffer (7):
v2v: output_rhv_upload: Require nbdkit >= 1.22
v2v: rhv-upload-plugin: Use API_VERSION 2
v2v: rhv-upload-plugin: Support FUA
v2v: rhv-upload-plugin: Get imageio connections limits
v2v: rhv-upload-plugin: Support multiple connections
v2v: rhv-upload: Use out of order writes
v2v: rvh-upload: Match nbdkit threads to qemu-img coroutines
v2v/nbdkit.ml | 4 +
v2v/nbdkit.mli | 1 +
v2v/output_rhv_upload.ml | 13 +-
v2v/rhv-upload-plugin.py | 318 +++++++++++++++++++++++++++------------
v2v/types.ml | 1 +
v2v/types.mli | 2 +
v2v/v2v.ml | 1 +
7 files changed, 238 insertions(+), 102 deletions(-)
--
2.26.2
5 years
[PATCH nbdkit 0/6] cow: Implement trimming and extents.
by Richard W.M. Jones
This patch series implements trimming and extents in
nbdkit-cow-filter. The aim of this is to have feature parity with
qcow2 zero clusters, which we can then use to replace the qcow2
overlays currently used to protect the source disk in virt-v2v.
First 3 patches are some preparatory enhancements/clean-up.
To implement extents: We iterate over the blocks in the filter, if the
block is allocated (ie. contains a write which has been saved in the
overlay) then the whole block is allocated data, else we have to ask
the underlying plugin for the information about that block. (This
ends up making lots of small extents calls into the plugin, which
could be optimized in future.)
To implement trim: We extend the overlay bitmap with an extra bit per
block so we can store whether the block has been trimmed. A future
optimization is to actually trim the overlay (it only saves space,
it's not needed for correctness), but this patch series does not do
this.
Final patch implements a couple of tests.
Rich.
5 years
