[Libguestfs] LVM mounting issue

Fri Jan 17 14:38:43 UTC 2014

-----Original Message-----
From: Richard W.M. Jones [mailto:rjones at redhat.com]
Sent: Friday, January 17, 2014 4:40 PM
To: Исаев Виталий Анатольевич
Cc: libguestfs at redhat.com
Subject: Re: [Libguestfs] LVM mounting issue

On Fri, Jan 17, 2014 at 09:45:34AM +0000, Исаев Виталий Анатольевич wrote:

> Be sure, that “unknown device” was not written by me :)

>

> I use libguestfs 1.16.34:

> [root at rhevh1 ~]# rpm -qa | grep guest

> libguestfs-1.16.34-2.el6.x86_64

> libguestfs-winsupport-1.0-7.el6.x86_64

> python-libguestfs-1.16.34-2.el6.x86_64

> libguestfs-tools-c-1.16.34-2.el6.x86_64

This is a bug.  I have filed a bug about this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=1054761

However it does indicate that you are not presenting all physical volumes to libguestfs, which means you're probably not adding every device that belongs to the guest.  That's going to cause other problems for you.

> Full trace of the guestfish session is attached to this message.

> ><fs> add-ro /dev/dm-40

Based on your reply in bug 1053684 I still don't know which is the correct device name to open, but it's obviously not /dev/dm-40.  I spent quite a long time yesterday trying to get someone from the oVirt team to help out, but without success so far.  I will keep you informed on bug 1053684.

Rich.

--

Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

Rich, thank you for your patience and advices. It seems for me that we mixed two different problems:

1.       Problems while accessing ANY of thin provisioned (qcow2) disk with libguestfs 1.16.34 on the hypervisor (it’s discussed in bug 1053684);

2.       Problems while mounting SOME of disk images with libguestfs 1.16.34 (strictly speaking there are only 2 VMs with such problem of 17 ones I have on my cluster);

However, both of the mentioned issues require the correct disk images paths to be provided. But as you say that /dev/dm-XX devices are obviously not suitable for usage with libguestfs, I would ask you for a last thing – to check all my steps on the way to define and access the disk image. May be there is an error in my logic.

1.       I want to inspect VM’s disk image. There are two disk images belonging to this VM (look at the “vm” xml file attached);

2.       I determine the disk_image_id of the VM’s bootable disk (look at the image_id node in “disks” xml file attached);

3.       Now I go to the RHEV-H to look for the disk image itself:

[root at rhevh1 /]# find / -name cc6e4400-7c98-4170-9075-5f5790dfcff3
/dev/1a9aa971-f81f-4ad8-932f-607034c924fc/cc6e4400-7c98-4170-9075-5f5790dfcff3
/var/lib/stateless/writable/rhev/data-center/mnt/blockSD/1a9aa971-f81f-4ad8-932f-607034c924fc/images/8a3e02de-d8ab-4357-ba8c-490f3ba3e85c/cc6e4400-7c98-4170-9075-5f5790dfcff3
/rhev/data-center/mnt/blockSD/1a9aa971-f81f-4ad8-932f-607034c924fc/images/8a3e02de-d8ab-4357-ba8c-490f3ba3e85c/cc6e4400-7c98-4170-9075-5f5790dfcff3

4.       Note that all these files are symbolic links:

[root at rhevh1 /]# find / -name cc6e4400-7c98-4170-9075-5f5790dfcff3 -exec readlink -f {} \;
/dev/dm-40
/dev/dm-40
/dev/dm-40

5.       One more symbolic link is in /dev/mapper:

[root at rhevh1 /]# ls -l /dev/mapper/1a9aa971--f81f--4ad8--932f--607034c924fc-cc6e4400--7c98--4170--9075--5f5790dfcff3
lrwxrwxrwx. 1 root root 8 2013-11-20 10:59 /dev/mapper/1a9aa971--f81f--4ad8--932f--607034c924fc-cc6e4400--7c98--4170--9075--5f5790dfcff3 -> ../dm-40

6.       So I have no choice and I try to open /dev/dm-40 with libguestfs or guestfish. What's next, you already know.

I apologize for spending your time again, but please evaluate the proposed method of disk image definition.

Sincerely,
Vitaly Isaev
Software engineer
Information security department
Fintech JSC, Moscow, Russia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20140117/c277d133/attachment.htm>