|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |