Open Stack

On 02/19/2015 12:45 PM, Richard W.M. Jones wrote:
> On Wed, Feb 18, 2015 at 07:23:52PM +0100, Raphael Glon wrote:
>> I entcountered a similar case more recently on powerkvm 2.1.0
>> (defect with the libguestfs)
> What's the actual bug?  We've worked hard, with IBM, to make
> libguestfs work on POWER 7 and POWER 8 systems.  I have full access to
> those systems through Red Hat.  If there's a new bug I'm sure we'll be
> able to fix it.
>
> Rich.
>
Hi, thank you for all your answers.

Not saying there are "actual" bugs (anyway I'm stuck here because i 
would need to find time+environment to recheck all/reproduce) -> i 
haven't even deployed juno on pkvm yet

We've talked with ibm (and they have likely been working with you) and 
they are really responsive in fixing defects with their distribution

We've entcountered two problems with powerkvm regarding nova + libguestfs.

1. since pkvm 2.1.x is forked from a Fedo 19, we fell back to this Red 
Hat bug you fixed regarding the attach method

Note that one of the workaround proposed was

sudo sysctl -w fs.protected_hardlinks=0 + common user nova/qemu


-> Not a specialist here, but seems like to be able to use libguestfs to 
avoid "potential" issues with fuse mounts, we open other "potential" 
holes somewhere else

2. because pkvm 2.1.x is forked from fedo 19 it embeds rather old 
versions of libguestfs and libvirt.

We also entcountered the following issue(as you see from the dates, it 
is rather "old"). About this, i was not perfectly accurate saying it was 
a libguestfs defect, it was a pkvm defect embedding an old version of 
libguestfs and anyway it also has been fixed quickly

http://paste.ubuntu.com/8465699/

Sep 30 14:25:33 host-power8-1 libvirtd[15894]: Domain id=2 
name='guestfs-xv6mh1nvhr17ktj6' 
uuid=341b09bc-6583-4b72-9df8-dc9b18116303 is tainted: custom-argv
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: Unable to read from 
monitor: Connection reset by peer
Sep 30 14:25:33 host-power8-1 kernel: [  878.869394] 
qemu-system-ppc[16250]: unhandled signal 11 at 00000000000000d8 nip 
000000003070c0ac lr 000000003070bff4 code 30001
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default 
selinux label for /tmp/libguestfsrOhcjP/console.sock
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default 
selinux label for /tmp/libguestfsrOhcjP/guestfsd.sock
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default 
selinux label for /var/tmp/.guestfs-0/kernel.16152
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default 
selinux label for /var/tmp/.guestfs-0/initrd.16152


3. Had no time to investigate on this but when using libguestfs with 
nova, the ghost was not always destroyed after file injection. 
Sometimes, you could find an instance spawned with the libguestfs ghost 
still running in the same time. Anyway, I've got no logs to detailthis 
issue, i'll try to get some one day

So summing up this patch was about:

File injection with libguestfs not working in some specific environment 
(dist pkvm 2.1.0 + libguestfs pkvm packaged version + nova havana) and i 
supposed i was not the only one concerned

On our side we had to temporarily disable file injection using libguestfs

Since nova still considers fuse mounts as acceptableit would have been 
practical if, at the time, it had been flexible on the fact to use or 
not libguestfs when this one is installed. (By the way, correct me if 
wrong, but there are no current open issues with fuse mounts, and if 
there are, why is it still proposed in nova ? would even say this is the 
default/most used method because there is no dist considering libguestfs 
is a dependency for the nova-compute package)

Get your reluctance. Giving up with the patch.

regards

raphael


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150223/9e72a3e2/attachment.html>