8:27 a.m.
On Thu, Feb 29, 2024 at 05:37:08PM +0200, Andrey Drobyshev wrote:
I discovered that when a VM has an ISO attached via CD-ROM,
libguestfs
fails to read its partition table and therefore fails to perform basic
operations on a VM, e.g. listing a directory or editing a file:
# virsh domblklist rocky9-vm
Target Source
---------------------------------------------------------------------------
sda /vz/vmprivate/e827caad-b9e4-4858-b3dc-53ae6b8a5145/harddisk.hdd
sdb /vzt/images/Rocky-9.3-x86_64-minimal.iso
[Download the ISO from here: https://rockylinux.org/download/]
# virt-ls -d rocky9-vm /
libguestfs: error: inspect_os: sgdisk: Invalid partition data!
# virt-edit -d rocky9-vm /etc/fstab
libguestfs: error: inspect_os: sgdisk: Invalid partition data!
Even virt-inspector can't give us proper output on an ISO9660 image:
# virt-inspector /vzt/images/Rocky-9.3-x86_64-minimal.iso
libguestfs: error: inspect_os: sgdisk: Invalid partition data!
virt-inspector: no operating system could be detected inside this disk
image.
...
First I found a 3 years old topic where you suggested that sgdisk itself
might be too old:
https://listman.redhat.com/archives/libguestfs/2021-March/025939.html.
However this doesn't seem to be it in this case:
I've compiled the latest version from
https://sourceforge.net/projects/gptfdisk -- no luck as well. Seems
that sgdisk isn't capable of recognizing ISO9660 images.
Then I noticed 2 things:
1. libguestfs appliance is being created (with backend=libvirt) with ISO
attached as device='disk' (not 'cdrom'):
> <disk type='file' device='disk'>
> <driver name='qemu' type='qcow2'
cache='unsafe'/>
> <source file='/tmp/libguestfsD7IHvF/overlay2.qcow2'
index='2'/>
> <backingStore type='file' index='5'>
> <format type='raw'/>
> <source file='/vzt/images/Rocky-9.3-x86_64-minimal.iso'/>
> <backingStore/>
> </backingStore>
> <target dev='sdb' bus='scsi'/>
> <alias name='scsi0-0-1-0'/>
> <address type='drive' controller='0' bus='0'
target='1' unit='0'/>
> </disk>
That forces this disk to be supplied with "scsi-hd" driver in use, which
in turn leads to the device being visible inside the guest as a regular
SCSI hdd /dev/sdb. Shouldn't we, for instance, make sure that for such
images device='cdrom' and "scsi-cd" driver are being used? In this
case
the guest will see it as /dev/sr0, and I suspect srX devices are being
skipped by guestfs_inspect_os.
I think /dev/srX would not be ignored:
https://github.com/libguestfs/libguestfs/blob/729d6d55ea84494f0398d02450b...
But anyway I don't think that's the problem here. We try to present
any disk image (even an ISO) as a regular disk to the libguestfs
appliance. That's because we don't need or care about the special
features of /dev/srX like the ability to eject a disk.
I think the central problem is why libguestfs cannot inspect the ISO.
$ virt-inspector -a Rocky-9.3-x86_64-minimal.iso
libguestfs: error: inspect_os: sgdisk: Invalid partition data!
virt-inspector: no operating system could be detected inside this disk image.
$ guestfish --ro -a Rocky-9.3-x86_64-minimal.iso -i
libguestfs: error: inspect_os: sgdisk: Invalid partition data!
etc
Adding -vx options shows the problem is with sgdisk:
command: sgdisk returned 2
command: sgdisk: stderr:
Invalid partition data!
ocaml_exn: 'inspect_os' raised 'Failure' exception
guestfsd: error: sgdisk: Invalid partition data!
guestfsd: => inspect_os (0x1e0) took 0.13 secs
I believe this comes from:
https://github.com/libguestfs/libguestfs/blob/729d6d55ea84494f0398d02450b...
I modified the error message in this file to see what it's trying to
do and it comes from the call to 'part_get_gpt_type'.
I think it's a regression in commit b699111e04. Do you want to try
the attached patch?
Note this still won't allow the ISO to be inspected, but it avoids the
"Invalid partition data!" error, and maybe will cure the original
problem above.
2. When trying to perform the same operation via guestfish,
everything
appears to be working:
# guestfish -a /vzt/images/Rocky-9.3-x86_64-minimal.iso -m /dev/sda ls /
>/dev/null && echo $?
0
I think this is just because we're avoiding inspection?
File edit works as well. From debug output I see that sgdisk
isn't
being invoked at all. That means there's a code path for the same
operations where sgdisk can be omitted. Maybe we should follow that
same code path when invoking other tools like virt-ls or virt-edit?
Overall, what would be an appropriate fix in your opinion? We should at
least make sure that working with domains (with the "-d" option) works
no matter what.
Andrey
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org