Re: [Libguestfs] Libguestfs can't launch with one of the disk images in the RHEV cluster
----- Original Message -----
From: "Richard W.M. Jones" <rjones(a)redhat.com>
To: "Исаев Виталий Анатольевич" <isaev(a)fintech.ru>
Cc: libguestfs(a)redhat.com
Sent: Tuesday, January 14, 2014 6:42:23 PM
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:
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/
Yes, the full path to the images is:
/rhev/data-center/mnt/blockSD/<sdUUID>/images/<imgUUID>/
sdUUID is the uuid of the storage domain (vg name) where the images
are stored and imgUUID is the uuid of the image (as reported in the
"Disks" tab in the webadmin).
The symlinks and the LVs are managed by vdsm (activated when the VM
starts, deactivated as soon as the VM is stopped).
If you just want to access these images once and you're sure that
they are not in use you could activate the relevant LVs and create
the symlinks yourself on any machine (no need of oVirt/vdsm), e.g.
/tmp/ovirt-images/<imgUUID>/<volUUID1> -> /dev/dm-xx
/tmp/ovirt-images/<imgUUID>/<volUUID2> -> /dev/dm-xx
/tmp/ovirt-images/<imgUUID>/<volUUID3> -> /dev/dm-xx
this could even be automated eventually (from the qemu-img output).
If instead you're trying to integrate with oVirt and you need a
more reliable/automated solution I invite you start a thread on
the oVirt mailing list.
The imgUUIDs can be found also with: lvs -o +tags looking for the
tags starting with "IU_".
--
Federico