-----Original Message----- From: Richard W.M. Jones [mailto:rjo...@redhat.com] Sent: Tuesday, January 14, 2014 9:43 PM To: Исаев Виталий Анатольевич Cc: libguestfs@redhat.com Subject: Re: [Libguestfs] Libguestfs can't launch with one of the disk images in the RHEV cluster
On Tue, Jan 14, 2014 at 02:57:35PM +0000, Исаев Виталий Анатольевич wrote: > 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--9 > 12119fcf67f > image: > 1a9aa971--f81f--4ad8--932f--607034c924fc-666faa62--da73--4465--aed2--9 > 12119fcf67f > 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-5f64e9 > 0023e5 > [root@rhevh1 mapper]# ll > ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e9 > 0023e5 > ls: cannot access > ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e9 > 0023e5: 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-5f64 > e90023e5 > /var/lib/stateless/writable/rhev/data-center/mnt/blockSD/1a9aa971-f81f > -4ad8-932f-607034c924fc/images/6439863f-2d4e-48ae-a150-f9054650789c/cb > e36298-6397-4ffa-ba8c-5f64e90023e5 > /rhev/data-center/mnt/blockSD/1a9aa971-f81f-4ad8-932f-607034c924fc/ima > ges/6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e > 90023e5 > > In turn, the > /dev/1a9aa971-f81f-4ad8-932f-607034c924fc/cbe36298-6397-4ffa-ba8c-5f64 > e90023e5 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'] This works because you're accessing the backing disk, not the top disk. Since the backing disk (in this case) doesn't itself have a backing disk, qemu has no problem opening it. > 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, Basically you need to find out which directory RHEV-M itself starts qemu in. Try going onto the node and doing: ps ax | grep qemu ls -l /proc/PID/cwd substituting PID for some of the qemu process IDs. My guess would be some subdirectory of /rhev/data-center/mnt/blockSD/ Then start your test script from that directory. Another thing you could do is to file a bug against oVirt asking them not to use relative paths for backing disks, since plenty of people have problems with this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org Thank you, Richard. I’ve posted a message to the RH bugtracker: https://bugzilla.redhat.com/show_bug.cgi?id=1053684 Further work on this problem made the things even more complicated, because I found that several qcow2 disks have qcow2 disks as backing disks in turn. So now I have to resolve qcow2 to raw disks recursively in order to access them with libguestfs. Vitaly Isaev Software engineer Information security department Fintech JSC, Moscow, Russia
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs