Re: RBD volume not made available to Xen virtual guest on openSUSE 15.2 (with libvirt 6.0.0)

[Marcel Juffermans <mjuffermans@xxxxxxxxxxxxxxxxxx>]

Further to this, the error may be coming from QEMU, but the guests work 
fine when started using KVM (+ libvirt + QEMU) instead of Xen (+ libvirt 
+ QEMU). So is it possible the problem is in libvirt, or rather, in the 
interaction between libvirt, Xen and QEMU?

Marcel
On 27/10/20 9:18 am, Marcel Juffermans wrote:
> It's QEMU 4.2.1-lp152.9.6.1.
>
> I've tried updating it from the Open Build Service repos but there's 
> too many version conflicts.
>
> Marcel
> On 26/10/20 9:02 pm, Ján Tomko wrote:
> > On a Friday in 2020, Marcel Juffermans wrote:
> > > Hi there,
> > >
> > > Since upgrading to openSUSE 15.2 (which includes libvirt 6.0.0) the 
> > > virtual guests don't get their RBD disks made available to them. On 
> > > openSUSE 15.1 (which includes libvirt 5.1.0) that worked fine. The 
> > > XML is as follows:
> >
> > [...]
> >
> > > I tried to strace libvirtd. The results are as follows:
> > >
> > > On openSUSE 15.2 with libvirt 6.0.0 (not working), we see this:
> > >
> > > 1682Â  openat(AT_FDCWD, 
> > > "rbd:guests/mytwotel-a:id=libvirt:key=AQCAUpBbrcaiFxAA1sztXPbkdW1L54i99oUpyA==:auth_supported=cephx\\;none", 
> > > O_RDWR|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > > 1682Â  rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
> > > 1682Â  mmap(NULL, 1052672, PROT_READ|PROT_WRITE, 
> > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f538aefd000
> > > 1682Â  mprotect(0x7f538aefd000, 4096, PROT_NONE <unfinished ...>
> > > 1682Â  <... mprotect resumed>)Â Â Â Â Â Â Â Â Â Â  = 0
> > > 1682Â  rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM 
> > > IO], 8) = 0
> > > 1682Â  rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
> > > 1682Â  mmap(NULL, 1052672, PROT_READ|PROT_WRITE, 
> > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...>
> > > 1682Â  <... mmap resumed>)Â Â Â Â Â Â Â Â Â Â Â Â Â Â  = 0x7f538adfc000
> > > 1682Â  mprotect(0x7f538adfc000, 4096, PROT_NONE <unfinished ...>
> > > 1682Â  <... mprotect resumed>)Â Â Â Â Â Â Â Â Â Â  = 0
> > > 1682Â  rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], <unfinished ...>
> > > 1682Â  <... rt_sigprocmask resumed>[BUS USR1 ALRM IO], 8) = 0
> > > 1682Â  write(2, "qemu-system-i386: failed to crea"..., 232 
> > > <unfinished ...>
> > > ...
> > >
> > > On the other hand, on openSUSE 15.1 with libvirt 5.1.0 (working), we 
> > > see this:
> > >
> > > 16267 openat(AT_FDCWD, 
> > > "rbd:guests/mytwotel-a:id=libvirt:key=AQCAUpBbrcaiFxAA1sztXPbkdW1L54i99oUpyA==:auth_supported=cephx\\;none", 
> > > O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > > 16267 
> > > stat("rbd:guests/mytwotel-a:id=libvirt:key=AQCAUpBbrcaiFxAA1sztXPbkdW1L54i99oUpyA==:auth_supported=cephx\\;none", 
> > > 0x7fff83e2e2b0) = -1 ENOENT (No such file or directory)
> > > 16267 access("/usr/lib64/qemu/block-rbd.so", F_OK) = 0
> > > 16267 stat("/usr/lib64/qemu/block-rbd.so", {st_mode=S_IFREG|0644, 
> > > st_size=27448, ...}) = 0
> > > 16267 openat(AT_FDCWD, "/usr/lib64/qemu/block-rbd.so", 
> > > O_RDONLY|O_CLOEXEC) = 60
> > > 16267 read(60, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 
> > > &\0\0\0\0\0\0"..., 832) = 832
> > > 16267 fstat(60, {st_mode=S_IFREG|0644, st_size=27448, ...}) = 0
> > > 16267 mmap(NULL, 2122672, PROT_READ|PROT_EXEC, 
> > > MAP_PRIVATE|MAP_DENYWRITE, 60, 0) = 0x7f8e6030f000
> > > 16267 mprotect(0x7f8e60315000, 2093056, PROT_NONE) = 0
> > > 16267 mmap(0x7f8e60514000, 8192, PROT_READ|PROT_WRITE, 
> > > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 60, 0x5000) = 0x7f8e60514000
> > > 16267 close(60)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  = 0
> > > ...
> > >
> > > Note that the latter opens "/usr/lib64/qemu/block-rbd.so". That 
> > > library *does* exist on openSUSE 15.2 but it doesn't seem to be used.
> >
> > The error message comes from QEMU, what QEMU version are you using?
> >
> > Jano
> >
> > > I've tried to update libvirt to a newer version using the Open Build 
> > > Service repos, but then ran into so many conflicting versions that I 
> > > gave up.
> > >
> > > At this point I'm stuck. Does anyone have an idea I can try?
> > >
> > > Many thanks,
> > >
> > > Marcel