<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="RU" link="blue" vlink="purple"> <div class="WordSection1"> -----Original Message----- From: Richard W.M. Jones [mailto:rjones@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<o:p></o:p> <o:p> </o:p> On Tue, Jan 14, 2014 at 02:57:35PM +0000, Исаев Виталий Анатольевич wrote:<o:p></o:p> > Dear Rich, thank you for a prompt reply on my question. The similar <o:p></o:p> > problems have been found with all of the rest Thin Provisioned disks <o:p></o:p> > in the cluster, while all the Preallocated disks were handled with <o:p></o:p> > libguestfs correctly. I guess these issues were caused by (b) and <o:p></o:p> > probably (c) reasons:<o:p></o:p> > <o:p></o:p> > 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 :<o:p></o:p> > [root@rhevh1 mapper]# pwd<o:p></o:p> > /dev/mapper<o:p></o:p> > [root@rhevh1 mapper]# qemu-img info <o:p></o:p> > 1a9aa971--f81f--4ad8--932f--607034c924fc-666faa62--da73--4465--aed2--9<o:p></o:p> > 12119fcf67f<o:p></o:p> > image: <o:p></o:p> > 1a9aa971--f81f--4ad8--932f--607034c924fc-666faa62--da73--4465--aed2--9<o:p></o:p> > 12119fcf67f<o:p></o:p> > file format: qcow2<o:p></o:p> > virtual size: 40G (42949672960 bytes)<o:p></o:p> > disk size: 0<o:p></o:p> > cluster_size: 65536<o:p></o:p> > backing file: <o:p></o:p> > ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e9<o:p></o:p> > 0023e5<o:p></o:p> > [root@rhevh1 mapper]# ll <o:p></o:p> > ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e9<o:p></o:p> > 0023e5<o:p></o:p> > ls: cannot access <o:p></o:p> > ../6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e9<o:p></o:p> > 0023e5: No such file or directory<o:p></o:p> ><o:p> </o:p> > Note that /dev/dm-30 is not accessible with libguestfs.<o:p></o:p> > <o:p></o:p> > 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:<o:p></o:p> > [root@rhevh1 mapper]# find / -name <o:p></o:p> > cbe36298-6397-4ffa-ba8c-5f64e90023e5<o:p></o:p> > /dev/1a9aa971-f81f-4ad8-932f-607034c924fc/cbe36298-6397-4ffa-ba8c-5f64<o:p></o:p> > e90023e5<o:p></o:p> > /var/lib/stateless/writable/rhev/data-center/mnt/blockSD/1a9aa971-f81f<o:p></o:p> > -4ad8-932f-607034c924fc/images/6439863f-2d4e-48ae-a150-f9054650789c/cb<o:p></o:p> > e36298-6397-4ffa-ba8c-5f64e90023e5<o:p></o:p> > /rhev/data-center/mnt/blockSD/1a9aa971-f81f-4ad8-932f-607034c924fc/ima<o:p></o:p> > ges/6439863f-2d4e-48ae-a150-f9054650789c/cbe36298-6397-4ffa-ba8c-5f64e<o:p></o:p> > 90023e5<o:p></o:p> > <o:p></o:p> > In turn, the <o:p></o:p> > /dev/1a9aa971-f81f-4ad8-932f-607034c924fc/cbe36298-6397-4ffa-ba8c-5f64<o:p></o:p> > e90023e5 file is a symbolic link which points to the /dev/dm-19<o:p></o:p> > <o:p></o:p> > At last I am trying to launch libguestfs with block device directly:<o:p></o:p> > [root@rhevh1 mapper]# qemu-img info /dev/dm-19<o:p></o:p> > image: /dev/dm-19<o:p></o:p> > file format: raw<o:p></o:p> > virtual size: 40G (42949672960 bytes)<o:p></o:p> > disk size: 0<o:p></o:p> > [root@rhevh1 mapper]# python<o:p></o:p> > Python 2.6.6 (r266:84292, Oct 12 2012, 14:23:48) [GCC 4.4.6 20120305 <o:p></o:p> > (Red Hat 4.4.6-4)] on linux2 Type "help", "copyright", "credits" or <o:p></o:p> > "license" for more information.<o:p></o:p> > >>> import guestfs<o:p></o:p> > >>> g = guestfs.GuestFS()<o:p></o:p> > >>> g.add_drive_opts("/dev/dm-19",readonly=1)<o:p></o:p> > >>> g.launch()<o:p></o:p> > >>> g.lvs()<o:p></o:p> > []<o:p></o:p> > >>> g.pvs()<o:p></o:p> > []<o:p></o:p> > >>> g.list_partitions()<o:p></o:p> > ['/dev/vda1', '/dev/vda2']<o:p></o:p> > >>> g.inspect_os()<o:p></o:p> > ['/dev/vda1']<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> > Now I’m a little bit confused with the results of my research. I found <o:p></o:p> > that VM with the only disk attached has at least two block devices <o:p></o:p> > mapped to the hypervisor’s file system in fact – I mean<o:p></o:p> > /dev/dm-19 (raw) and /dev/dm-30 (qcow2). The RHEV-M API (aka Python <o:p></o:p> > oVirt SDK) provides no info about the first one, but the second cannot <o:p></o:p> > be accessed from libguestfs. I have an urgent need to work with a <o:p></o:p> > chosen VM disk images through the libguestfs layer, but I don’t know <o:p></o:p> > which images belong to every VM exactly. It seems like I’m going the <o:p></o:p> > hard way :) Sincerely,<o:p></o:p> <o:p> </o:p> Basically you need to find out which directory RHEV-M itself starts qemu in. Try going onto the node and doing:<o:p></o:p> <o:p> </o:p> ps ax | grep qemu<o:p></o:p> ls -l /proc/PID/cwd<o:p></o:p> <o:p> </o:p> substituting PID for some of the qemu process IDs.<o:p></o:p> <o:p> </o:p> My guess would be some subdirectory of /rhev/data-center/mnt/blockSD/<o:p></o:p> <o:p> </o:p> Then start your test script from that directory.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Rich.<o:p></o:p> <o:p> </o:p> --<o:p></o:p> Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones">http://people.redhat.com/~rjones</a> libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. <a href="http://libguestfs.org"> http://libguestfs.org</a><o:p></o:p> <o:p> </o:p> Thank you, Richard. I’ve posted a message to the RH bugtracker: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1053684">https://bugzilla.redhat.com/show_bug.cgi?id=1053684</a><o:p></o:p> 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.<o:p></o:p> <o:p> </o:p> Vitaly Isaev<o:p></o:p> Software engineer<o:p></o:p> Information security department<o:p></o:p> Fintech JSC, Moscow, Russia<o:p></o:p> <o:p> </o:p> </div> </body> </html>