Re: [Libguestfs] Libguestfs can't launch with one of the disk images in the RHEV cluster

Dear Rich, thank you for a prompt reply on my question. The similar problems have been found with all of the rest Thin Provisioned disks in the cluster, while all the Preallocated disks were handled with libguestfs correctly. I guess these issues were caused by (b) and probably (c) reasons: The backing file of any of the thin provisioned disks does not exist. For instance let’s consider the /dev/mapper/1a9aa971--f81f--4ad8--932f--607034c924fc-666faa62--da73--4465--aed2--912119fcf67f symbolic link pointing to /dev/dm-30 : [root@rhevh1 mapper]# pwd /dev/mapper [root@rhevh1 mapper]# qemu-img info 1a9aa971--f81f--4ad8--932f--607034c924fc-666faa62--da73--4465--aed2--912119fcf67f image: 1a9aa971--f81f--4ad8--932f--607034c924fc-666faa62--da73--4465--aed2--912119fcf67f file format: qcow2 virtual size: 40G (42949672960 bytes) disk size: 0 cluster_size: 65536 backing file: ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e90023e5 [root@rhevh1 mapper]# ll ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e90023e5 ls: cannot access ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e90023e5: No such file or directory Note that /dev/dm-30 is not accessible with libguestfs. Now I am trying to find the files with the same name. As a result I receive three symbolic links pointing to /dev/1a9aa971-f81f-4ad8-932f-607034c924fc/cbe36298-6397-4ffa-ba8c-5f64e90023e5: [root@rhevh1 mapper]# find / -name cbe36298-6397-4ffa-ba8c-5f64e90023e5 /dev/1a9aa971-f81f-4ad8-932f-607034c924fc/cbe36298-6397-4ffa-ba8c-5f64e90023e5 /var/lib/stateless/writable/rhev/data-center/mnt/blockSD/1a9aa971-f81f-4ad8-932f-607034c924fc/images/6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e90023e5 /rhev/data-center/mnt/blockSD/1a9aa971-f81f-4ad8-932f-607034c924fc/images/6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e90023e5 In turn, the /dev/1a9aa971-f81f-4ad8-932f-607034c924fc/cbe36298-6397-4ffa-ba8c-5f64e90023e5 file is a symbolic link which points to the /dev/dm-19 At last I am trying to launch libguestfs with block device directly: [root@rhevh1 mapper]# qemu-img info /dev/dm-19 image: /dev/dm-19 file format: raw virtual size: 40G (42949672960 bytes) disk size: 0 [root@rhevh1 mapper]# python Python 2.6.6 (r266:84292, Oct 12 2012, 14:23:48) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import guestfs >>> g = guestfs.GuestFS() >>> g.add_drive_opts("/dev/dm-19",readonly=1) >>> g.launch() >>> g.lvs() [] >>> g.pvs() [] >>> g.list_partitions() ['/dev/vda1', '/dev/vda2'] >>> g.inspect_os() ['/dev/vda1']

Now I’m a little bit confused with the results of my research. I found that VM with the only disk attached has at least two block devices mapped to the hypervisor’s file system in fact – I mean /dev/dm-19 (raw) and /dev/dm-30 (qcow2). The RHEV-M API (aka Python oVirt SDK) provides no info about the first one, but the second cannot be accessed from libguestfs. I have an urgent need to work with a chosen VM disk images through the libguestfs layer, but I don’t know which images belong to every VM exactly. It seems like I’m going the hard way :) Sincerely,