[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [BUG] Assertion failed: !blk->legacy_dev


  • To: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Roman Shaposhnik <roman@xxxxxxxxxx>
  • Date: Wed, 31 Jul 2019 13:11:22 -0700
  • Delivery-date: Wed, 31 Jul 2019 20:11:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi!

Andrew reminded me that EVE has a weird in-tree patch for Xen's qemu
to deal with an issue we can't quite explain:
    
https://github.com/lf-edge/eve/blob/master/pkg/xen-tools/patches-4.12.0/01-remove-assert.patch

The way this problem manifests itself is *sometime after* an HVM domain
with a qcow2 disk attached get started we get QEMU failing with:
    Assertion failed: !blk->legacy_dev
(/xen/tools/qemu-xen/block/block-backend.c: blk_get_attached_dev_id:
903)

The domain configuration is super, plain vanilla (see xl.cfg below) and the most
annoying thing is that after inspecting qemu source I can't possibly understand
how this is happening. After all,  blk_attach_dev_legacy() is
literally the only place
where that variable is being set to true and I don't quite understand how do we
end up there.

Now, you may say that disabling that assertion is not the right fix --
which I would
totally agree with. However, we've been running like this for a few months now
and it doesn't seem to be causing any kind of cascading errors.

Thanks,
Roman.

name = "roman-container.1"
type = "hvm"
uuid = "f98b451a-67e2-4323-9194-0323cfcaf319"
memory = 1024
maxmem = 1024
vcpus = 1
maxcpus = 1
boot = "dc"
disk = 
['/persist/sha512-50c181f684ff7d86307e57398a4ba7ca38f1f18996e71929fe291758de6b9bcd,8,xvda,rw']
vif = []
serial = ['pty']

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.