having an issue with updating a template

Status
Not open for further replies.
W

williamflow

New Member
Feb 13, 2024
3
0
1
so I am trying to run this command:

virt-customize -a /mnt/data/images/107/base-107-disk-0.qcow2 --update

and I get this error:
libguestfs: trace: launch = -1 (error)
virt-customize: error: libguestfs error: guestfs_launch failed, see earlier
error messages

If reporting bugs, run virt-customize with debugging enabled and include
the complete output:

virt-customize -v -x [...]
libguestfs: trace: close
libguestfs: closing guestfs handle 0x5c5224c9ba20 (state 0)


The full message is:
root@proxmox:/mnt/data/images/117# virt-customize -a /mnt/data/images/107/base-107-disk-0.qcow2 --update
[ 0.0] Examining the guest ...
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: trace: set_network true
libguestfs: trace: set_network = 0
libguestfs: trace: add_drive "/mnt/data/images/107/base-107-disk-0.qcow2" "readonly:false" "protocol:file" "discard:besteffort"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: max_disks
libguestfs: trace: max_disks = 255
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: version
libguestfs: trace: version = <struct guestfs_version = major: 1, minor: 48, release: 6, extra: , >
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
libguestfs: launch: program=virt-customize
libguestfs: launch: version=1.48.6
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfskMMaeU
libguestfs: launch: umask=0022
libguestfs: launch: euid=0
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-0/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d
supermin: version: 5.2.2
supermin: package handler: debian/dpkg
supermin: acquiring lock on /var/tmp/.guestfs-0/lock
supermin: if-newer: output does not need rebuilding
libguestfs: finished building supermin appliance
libguestfs: begin testing qemu features
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: checking for previously cached test results of /usr/bin/qemu-system-x86_64, in /var/tmp/.guestfs-0
libguestfs: loading previously cached test results
libguestfs: qemu version: 9.2
libguestfs: qemu mandatory locking: yes
libguestfs: qemu KVM: enabled
libguestfs: trace: get_backend_setting "force_tcg"
libguestfs: trace: get_backend_setting = NULL (error)
libguestfs: trace: get_backend_setting "force_kvm"
libguestfs: trace: get_backend_setting = NULL (error)
libguestfs: trace: get_sockdir
libguestfs: trace: get_sockdir = "/tmp"
libguestfs: finished testing qemu features
libguestfs: trace: get_backend_setting "gdb"
libguestfs: trace: get_backend_setting = NULL (error)
/usr/bin/qemu-system-x86_64 \
-global virtio-blk-pci.scsi=off \
-no-user-config \
-nodefaults \
-display none \
-machine accel=kvm:tcg,graphics=off \
-cpu max,la57=off \
-m 1280 \
-no-reboot \
-rtc driftfix=slew \
-global kvm-pit.lost_tick_policy=discard \
-kernel /var/tmp/.guestfs-0/appliance.d/kernel \
-initrd /var/tmp/.guestfs-0/appliance.d/initrd \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0 \
-device virtio-scsi-pci,id=scsi \
-drive file=/mnt/data/images/107/base-107-disk-0.qcow2,cache=writeback,discard=unmap,id=hd0,if=none \
-device scsi-hd,drive=hd0 \
-drive file=/var/tmp/.guestfs-0/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none,format=raw \
-device scsi-hd,drive=appliance \
-device virtio-serial-pci \
-serial stdio \
-chardev socket,path=/tmp/libguestfsvuosYn/guestfsd.sock,id=channel0 \
-device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
-netdev user,id=usernet,net=169.254.0.0/16 \
-device virtio-net-pci,netdev=usernet \
-append "panic=1 console=ttyS0 edd=off udevtimeout=6000 udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=UUID=8849a280-45de-4287-8968-ee072aa62637 selinux=0 guestfs_verbose=1 guestfs_network=1 TERM=xterm"
qemu-system-x86_64: -drive file=/mnt/data/images/107/base-107-disk-0.qcow2,cache=writeback,discard=unmap,id=hd0,if=none: Could not open '/mnt/data/images/107/base-107-disk-0.qcow2': Operation not permitted
libguestfs: child_cleanup: 0x5c5224c9ba20: child process died
libguestfs: sending SIGTERM to process 1435820
libguestfs: trace: launch = -1 (error)
virt-customize: error: libguestfs error: guestfs_launch failed, see earlier
error messages

If reporting bugs, run virt-customize with debugging enabled and include
the complete output:

virt-customize -v -x [...]
libguestfs: trace: close
libguestfs: closing guestfs handle 0x5c5224c9ba20 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfskMMaeU
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsvuosYn
root@proxmox:/mnt/data/images/117#




I have no clue what to do any help would be great
 
Hi @williamflow ,

I believe virt-customize is not included in a default Proxmox VE installation, which suggests that this and other packages were added manually after the fact. It's difficult to pinpoint the issue - it could be due to missing packages, kernel modules not being loaded, or other environment mismatches.

As a general rule, it's best to treat a PVE installation like an appliance. If you need to manipulate a QCOW image, you should: spin up a disposable Ubuntu or Debian VM, and follow one of the many well-documented guides on how to work with these images

If something breaks, simply discard the VM

In short: keep your hypervisor clean and isolated from unrelated experiments.

Cheers


PS that said: Could not open '/mnt/data/images/107/base-107-disk-0.qcow2': Operation not permitted

The template can be locked, marked immutable or read only. Copy the file elsewhere and edit out-of-band

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
I recommend to not use the "convert to template" features of PVE if you want to update the underlying image. It's easier to have just a normal VM that you can spin up, update and spin down.
 
Status
Not open for further replies.
Top Bottom