[Libguestfs] HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs

[Исаев Виталий Анатольевич]

________________________________________
От: Itamar Heim [iheim at redhat.com]
Отправлено: 21 ноября 2013 г. 20:10
Кому: Richard W.M. Jones; Исаев Виталий Анатольевич
Копия: libguestfs at redhat.com
Тема: Re: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using libguestfs

On 11/21/2013 05:56 PM, Richard W.M. Jones wrote:
> [Adding Itamar: Any suggestions on where Vitaly could get help on this
> RHEV-M API problem?]
>
> On Thu, Nov 21, 2013 at 02:27:08PM +0000, Исаев Виталий Анатольевич wrote:
>> Dear libguestfs developers,
>>
>> We are developing the protected enterprise system based on several
>> Red Hat technologies (Red Hat Enterprise Virtualisation, the IdM
>> server and so on). Our current goal is to prevent the booting of the
>> virtual machine in case of integrity loss. So what we are trying to
>> do Is to intercept the event of the VM's start (using the RHEV
>> Manager hook scripts), mount the starting VM's disk image with
>> libguestfs and check the hash sums of the system files.
>>
>> When we have a local storage of disk images (manager, hypervisor and
>> storage - all in one host), this approach works just perfect.
>>
>> But even a little bit complex network (with at least one manager,
>> one hypervisor and one iSCSI/FC storage - three standalone physical
>> hosts) blows our minds. RHEV Manager API provides the list of disk
>> images which are (in this configurations) are logical volumes on the
>> hypervisor and appear in hypervisor's /dev/mapper directory. But
>> libguestfs from RHEV manager cannot access them.
>
> When you say "cannot access them" do you get an error message?  Could
> it be an SELinux denial?

Yes, when I am trying to open some logical volume on the hypervisor side, for instance:
    $ guestfish -a /dev/mapper/dm-xx
libguestfs fails with an error message kind of that:
    $ libguestfs-supermin-helper: failed to find a suitable kernel.
    I looked for kernels in /boot and modules in /lib/modules.
    If this is a Xen guest, and you only have Xen domU kernels
    installed, try installing a fullvirt kernel (only for
    libguestfs use, you shouldn't boot the Xen guest with it).
So this is correct because hypervisor's file system is minimalist and therefore contains 
kernel files neither in /boot nor in /lib/modules. 

And it is still not clear for me, how should I implement interaction between the RHEV-M API,
which tells me what logical volume (disk image) belongs to the every VM, and the hypervisor's, to which 
all the logical volume (disk images) are mapped. 

So can I access the VM's disk images directly from the RHEV Manager in case 
if manager, hypervisor and storage are different hosts? 

>
> I can tell you that libguestfs *should* be able to open any disk image
> or block device.  But libguestfs doesn't have a magic way to bypass
> permissions: if the block device needs (for example) root permissions
> or SELinux is stopping things, libguestfs won't be able to open the
> file, in the same way that /bin/cat or vi couldn't open it.
>

Oh, that's nice idea. I'll try to turn SELinux off. 

>> Examples from libguestfs and guestfish guide (for instance, over
>> ssh)
>
> Remote access over ssh isn't enabled in RHEL 6 (nor in RHEL 7, sadly).
> Is this a remote disk?  RHEL 7.0 will support NBD remote access only,
> which probably doesn't help you.

Unfortunately, we cannot upgrade from 6.4 due to conditions beyond our control...

> Fedora of course enables every possible remote access method, but you
> get to keep the pieces if it breaks.
>
>> do not work. And even more, which host should we access - a
>> hypervisor (with a different logical volumes) or a storage (with a
>> monolith volume group)?
>
> Itamar can probably help better than me here.
>
>> Software version: RHEV 3.1, libguestfs 1.16.34, guest OS - RHEL 6.4, arch: x86_64.
>>
>> P.S. May be I had to post this message directly to the support, but I'd suggest that this topic would be useful for community.
>>
>> Thank you,
>> Виталий Исаев
>> Инженер-программист
>> Группа разработки и внедрения ПСЗИ
>> Департамент информационной безопасности
>> ОАО <Финтех>
>
> Rich.
>

>i may be missing something, but wouldn't vdsm hooks be a better fit:
>http://www.ovirt.org/VDSM-Hooks
>
>for example, I think the "checkimages" one would cover what you are
>trying to do already?

Thank you, this hook was useful, but "gemu-img check" command is slightly different from our purposes, 
because we are trying to prevent the booting from disk image with changed system binaries. 

>http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;
>
>you can also ask such questions on users at ovirt.org.

Thank you for your attention and advises.
Vitaly