Bug 1301019
Summary: | [RFE] add support for LUKS disk encryption format driver w/ RBD, iSCSI, and qcow2 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Daniel Berrangé <berrange> | ||||||||
Component: | qemu-kvm-rhev | Assignee: | Daniel Berrangé <berrange> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Ping Li <pingl> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 7.3 | CC: | berrange, chayang, huding, jinzhao, jliberma, jomurphy, juzhang, knoel, lhinds, mrezanin, pingl, sgordon, tlavigne, virt-maint, xfu, yanyang, yisun | ||||||||
Target Milestone: | rc | Keywords: | FutureFeature | ||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | qemu-kvm-rhev-2.6.0-24.el7 | Doc Type: | Enhancement | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | |||||||||||
: | 1301021 (view as bug list) | Environment: | |||||||||
Last Closed: | 2016-11-07 20:56:54 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 1230405, 1262120, 1301021, 1305606, 1411525, 1419712 | ||||||||||
Attachments: |
|
Description
Daniel Berrangé
2016-01-22 10:56:14 UTC
*** Bug 1297980 has been marked as a duplicate of this bug. *** When try to start a vm with luks image, it failed because not whitelisted. Pls help to confirm. virsh dumpxml virtlab_test | grep luks -a10 ... <disk type='volume' device='disk'> <driver name='qemu' type='qcow2'/> <source pool='luks' volume='luks_1.img'/> <target dev='vdb' bus='virtio'/> <encryption format='luks'> <secret type='passphrase' uuid='4ff78f8c-6ee6-4a8d-b638-2b59d5d49279'/> </encryption> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </disk> ... # virsh start virtlab_test error: Failed to start domain virtlab_test error: internal error: process exited while connecting to monitor: 2016-08-17T10:06:37.533147Z qemu-kvm: -drive file=/var/lib/libvirt/images/luks/luks_1.img,key-secret=virtio-disk1-luks-secret0,format=luks,if=none,id=drive-virtio-disk1: Driver 'luks' is not whitelisted Hi Daniel, The issue is fixed in qemu 2.6, but i have no clue how to verify it. Could you help to share the steps to verify this bug fix? Thanks in advance. Moving back to POST since the RPM build did not enable LUKS Hi Daniel, From libvirt perspective, I wrote a script to create luks volume with all possible parameters. As follow: ... cipher_names = ["aes","des","cast5","serpent","twofish","invalid"] cipher_sizes = ["256","192","128","6"] # 6 is invalid value for negative test cipher_modes = ["cbc","xts","ecb","invalid"] cipher_hashes = ["md5","sha1","sha256","invalid"] ivgen_names = ["plain","plain64","essiv","invalid"] ivgen_hashes = ["md5","sha1","sha256","invalid"] ... There are 6144 possible combinations. And some questions need your confirmation 1. DES not supported as expected? As follow: # qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | base64`,format=base64 -o key-secret=sec0,cipher-alg=des-rfb 1.img 1G Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=des-rfb qemu-img: 1.img: Algorithm 'des-rfb' not supported 2. when cipher-alg is aes/twofish/serpent, and ivgen-alg=essiv,ivgen-hash-alg=sha1, there always a "No AES/Serpent/Twofish cipher with key size 20 available" error, not quite understand why the key size is 20 here (128/196/258 passed actually) # qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | base64`,format=base64 -o key-secret=sec0,cipher-alg=aes-128,cipher-mode=ecb,hash-alg=sha256,ivgen-alg=essiv,ivgen-hash-alg=sha1 1.img 1G Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=aes-128 cipher-mode=ecb ivgen-alg=essiv ivgen-hash-alg=sha1 hash-alg=sha256 qemu-img: 1.img: No AES cipher with key size 20 available 3. (THIS MAYBE A BUG) when cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a "unexpected fatal signal 11" # cat /tmp/luks_vol.xml <volume> <name>luks1.img</name> <capacity unit='G'>1</capacity> <target> <path>/var/lib/libvirt/images/luks/luks1.img</path> <format type='raw'/> <encryption format='luks'> <secret type='passphrase' uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/> <cipher name='cast5' size='128' mode='xts' hash='md5'/> <ivgen name='essiv' hash='md5'/> </encryption> </target> </volume> Running: virsh vol-create luks /tmp/luks_vol.xml error: Failed to create vol from /tmp/luks_vol.xml error: internal error: Child process (/usr/bin/qemu-img create -f luks --object secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img.secret.eaTuyc -o key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5,ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img 1048576K) unexpected fatal signal 11 Fix included in qemu-kvm-rhev-2.6.0-22.el7 (In reply to yisun from comment #7) > Hi Daniel, > From libvirt perspective, I wrote a script to create luks volume with all > possible parameters. As follow: > ... > cipher_names = ["aes","des","cast5","serpent","twofish","invalid"] > cipher_sizes = ["256","192","128","6"] # 6 is invalid value for negative test > cipher_modes = ["cbc","xts","ecb","invalid"] > cipher_hashes = ["md5","sha1","sha256","invalid"] > ivgen_names = ["plain","plain64","essiv","invalid"] > ivgen_hashes = ["md5","sha1","sha256","invalid"] > ... > > There are 6144 possible combinations. Ok, it is important to note you cannot assume all combinations are valid. eg, using xts + essiv, while technically possible, is nothing something you'd ever do in practice. Also, the ivgen hashses are only relevant when using essiv. The QEMU iotest 149 gives a representative set of combinations that cover the "normal" combinations you'd expect 99% of people to use http://git.qemu.org/?p=qemu.git;a=blob;f=tests/qemu-iotests/149;h=84072513db0bb3331214f752c3f1654297824c65;hb=HEAD > And some questions need your > confirmation > 1. DES not supported as expected? As follow: > # qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | > base64`,format=base64 -o key-secret=sec0,cipher-alg=des-rfb 1.img 1G > > Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0 > cipher-alg=des-rfb > qemu-img: 1.img: Algorithm 'des-rfb' not supported 'des-rfb' != 'des'. 'des-rfb' is a special crippled version of des used only by RFB (aka VNC). It is not at all relevant to LUKS. We've no intention of adding real support for DES to LUKS since it is a broken cipher > 2. when cipher-alg is aes/twofish/serpent, and > ivgen-alg=essiv,ivgen-hash-alg=sha1, there always a "No AES/Serpent/Twofish > cipher with key size 20 available" error, not quite understand why the key > size is 20 here (128/196/258 passed actually) > # qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | > base64`,format=base64 -o > key-secret=sec0,cipher-alg=aes-128,cipher-mode=ecb,hash-alg=sha256,ivgen- > alg=essiv,ivgen-hash-alg=sha1 1.img 1G > > Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0 > cipher-alg=aes-128 cipher-mode=ecb ivgen-alg=essiv ivgen-hash-alg=sha1 > hash-alg=sha256 > qemu-img: 1.img: No AES cipher with key size 20 available > The cipher is used in two places - first for ciphering actual disk data, and second for ciphering the Initialization vector with essiv. The key size you provide only relates to cipher of disk data. The key size used when ciphering initialization vectors is determined indirectly by the ivgen hash algorithm. You chose SHA1, which has a digest size of 20 bytes / 160 bits. So it is trying to find a cipher keysize of 160, which is not supported. IOW, use of SHA1 is simply not compatible with the ciphers you list. Realistically only sha256 / sha512 make sense as options. > 3. (THIS MAYBE A BUG) when > cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value > doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a > "unexpected fatal signal 11" > > # cat /tmp/luks_vol.xml > <volume> > <name>luks1.img</name> > <capacity unit='G'>1</capacity> > <target> > <path>/var/lib/libvirt/images/luks/luks1.img</path> > <format type='raw'/> > <encryption format='luks'> > <secret type='passphrase' > uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/> > <cipher name='cast5' size='128' mode='xts' hash='md5'/> > <ivgen name='essiv' hash='md5'/> > </encryption> > </target> > </volume> > > Running: virsh vol-create luks /tmp/luks_vol.xml > error: Failed to create vol from /tmp/luks_vol.xml > error: internal error: Child process (/usr/bin/qemu-img create -f luks > --object > secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img. > secret.eaTuyc -o > key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5, > ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img > 1048576K) unexpected fatal signal 11 Yep, seeing a signal 11 is always a bug. I'll investigate this (In reply to Daniel Berrange from comment #9) > > 3. (THIS MAYBE A BUG) when > > cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value > > doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a > > "unexpected fatal signal 11" > > > > # cat /tmp/luks_vol.xml > > <volume> > > <name>luks1.img</name> > > <capacity unit='G'>1</capacity> > > <target> > > <path>/var/lib/libvirt/images/luks/luks1.img</path> > > <format type='raw'/> > > <encryption format='luks'> > > <secret type='passphrase' > > uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/> > > <cipher name='cast5' size='128' mode='xts' hash='md5'/> > > <ivgen name='essiv' hash='md5'/> > > </encryption> > > </target> > > </volume> > > > > Running: virsh vol-create luks /tmp/luks_vol.xml > > error: Failed to create vol from /tmp/luks_vol.xml > > error: internal error: Child process (/usr/bin/qemu-img create -f luks > > --object > > secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img. > > secret.eaTuyc -o > > key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5, > > ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img > > 1048576K) unexpected fatal signal 11 > > Yep, seeing a signal 11 is always a bug. I'll investigate this I'm unable to reproduce that crash. Can you provide information about what version of QEMU you saw this with, what OS platform, etc. Also could you capture a stack trace with GDB Created attachment 1193155 [details]
coredump file
(In reply to Daniel Berrange from comment #11) > (In reply to Daniel Berrange from comment #9) > > > 3. (THIS MAYBE A BUG) when > > > cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value > > > doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a > > > "unexpected fatal signal 11" > > > > > > # cat /tmp/luks_vol.xml > > > <volume> > > > <name>luks1.img</name> > > > <capacity unit='G'>1</capacity> > > > <target> > > > <path>/var/lib/libvirt/images/luks/luks1.img</path> > > > <format type='raw'/> > > > <encryption format='luks'> > > > <secret type='passphrase' > > > uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/> > > > <cipher name='cast5' size='128' mode='xts' hash='md5'/> > > > <ivgen name='essiv' hash='md5'/> > > > </encryption> > > > </target> > > > </volume> > > > > > > Running: virsh vol-create luks /tmp/luks_vol.xml > > > error: Failed to create vol from /tmp/luks_vol.xml > > > error: internal error: Child process (/usr/bin/qemu-img create -f luks > > > --object > > > secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img. > > > secret.eaTuyc -o > > > key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5, > > > ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img > > > 1048576K) unexpected fatal signal 11 > > > > Yep, seeing a signal 11 is always a bug. I'll investigate this > > I'm unable to reproduce that crash. Can you provide information about what > version of QEMU you saw this with, what OS platform, etc. Also could you > capture a stack trace with GDB qemu versions: qemu-img-rhev-2.6.0-22.el7.x86_64 qemu-kvm-rhev-2.6.0-22.el7.x86_64 libvirt version: libvirt-2.0.0-6.el7.x86_64 I tried with pure qemu-img cmd and it's not reproducible. Only reproducible with virsh command mentioned in comment 7. Got gdb bt as follow (and coredump attached as attachment 1193155 [details]): Thread 1 (Thread 0x7ffff7fc6a40 (LWP 27602)): #0 qcrypto_cipher_encrypt (cipher=0xd2ff8da21cd30e09, in=in@entry=0x5555564b0170, out=out@entry=0x5555564b0170, len=len@entry=8, errp=errp@entry=0x55555661bf90) at crypto/cipher-gcrypt.c:255 ctx = <optimized out> err = <optimized out> __func__ = "qcrypto_cipher_encrypt" #1 0x00005555555d4a30 in qcrypto_ivgen_essiv_calculate (ivgen=<optimized out>, sector=1, iv=0x5555564b0168 "\227Րd\240\033\002o\001", niv=8, errp=0x55555661bf90) at crypto/ivgen-essiv.c:86 essiv = 0x5555564b0160 ndata = 8 data = 0x5555564b0170 "\001" #2 0x00005555555d5997 in qcrypto_block_encrypt_helper (cipher=cipher@entry=0x555556488120, niv=8, ivgen=ivgen@entry=0x555556501480, sectorsize=sectorsize@entry=512, startsector=1, startsector@entry=0, buf=0x555556628200 "\307ʭ.\005\215S\340c\t\364\r\314Ƙ[\302\006P\214\200\237\313f\315\030ZW\253a\365,I\220zs!\260\024\\Ʉ\376\354\313VL\257X\362\307O2vt\345\371Cb\024n\374\006\247\377^%q\220-\370\n\217\342$\251\222\360\331\365\036\302\200DZ\271\260\350p\316Qu|\372p+\331t\350\355\017\a\v~H\324AC%\314\327A$\331\327ָϛ3\212\tH\251qPNR\f\201\323\025\071\340\060n\236\316\024\360C\231X\340a\255u昒ϋ[p\333\340=9\235\221\375?\343h\373. ӎ\214\315`H3߳E@A8\257|\034\226\262\355\324!\251\177\231\024\362\022m\324\325\324\024\264"..., buf@entry=0x555556628000 "Hj\223\235\210\035\324e\206z+\211+\360H\021<Cj߈\245\376\315Y\323r\225\065j\370S\224\276\061\006\250.\375\337\\\244BI\242\350\036\215\313\366\342\313\362\235\360hρ}j=\v\321N\t\270\322\177\rrj\243\356\260\063B*\224\037\242X \bۉr+\001ZPB\242\027\241\366\016\017\317I\276\017\223\250X\f,\222\225\030\275\372\071\f\035\020B\375I\v0\233(B\361\355e\035\246\307\320WZ\217U\235-o\211\064Μ\210ч\264\067\031\v\370ی\211[\326\376\372\341\235\016&kv\334\\\360\037χ\217\067\275", <incomplete sequence \354>, len=127488, len@entry=128000, errp=errp@entry=0x55555661bf90) at crypto/block.c:232 nbytes = <optimized out> iv = 0x5555564b0168 "\227Րd\240\033\002o\001" ret = -1 #3 0x00005555555d65b9 in qcrypto_block_luks_create (block=0x555556490a80, options=<optimized out>, initfunc=0x5555555c1640 <block_crypto_init_func>, writefunc=0x5555555c15e0 <block_crypto_write_func>, opaque=0x55555661bf30, errp=0x55555661bf90) at crypto/block-luks.c:1167 luks = 0x55555661c000 luks_opts = {has_key_secret = true, key_secret = 0x55555648a0a0 "luks1.img_luks0", has_cipher_alg = true, cipher_alg = QCRYPTO_CIPHER_ALG_CAST5_128, has_cipher_mode = true, cipher_mode = QCRYPTO_CIPHER_MODE_XTS, has_ivgen_alg = true, ivgen_alg = QCRYPTO_IVGEN_ALG_ESSIV, has_ivgen_hash_alg = true, ivgen_hash_alg = QCRYPTO_HASH_ALG_MD5, has_hash_alg = true, hash_alg = QCRYPTO_HASH_ALG_MD5} local_err = 0x0 masterkey = 0x555556501200 "\267\215\031\263\202\243\006%o\222Y\326-\323au\240\325\371\260.>\261\032\357\023m\005\270S\242M@\022PVUU" slotkey = 0x555556501300 ",\207\345\027Y\200\253R\376$z\373g\356[\220ljS\346\027\356\223\340v\017gP\021ƶ\272`~\207UUU" splitkey = 0x555556628000 "Hj\223\235\210\035\324e\206z+\211+\360H\021<Cj߈\245\376\315Y\323r\225\065j\370S\224\276\061\006\250.\375\337\\\244BI\242\350\036\215\313\366\342\313\362\235\360hρ}j=\v\321N\t\270\322\177\rrj\243\356\260\063B*\224\037\242X \bۉr+\001ZPB\242\027\241\366\016\017\317I\276\017\223\250X\f,\222\225\030\275\372\071\f\035\020B\375I\v0\233(B\361\355e\035\246\307\320WZ\217U\235-o\211\064Μ\210ч\264\067\031\v\370ی\211[\326\376\372\341\235\016&kv\334\\\360\037χ\217\067\275", <incomplete sequence \354> splitkeylen = 128000 i = <optimized out> cipher = 0x555556488120 ivgen = 0x555556501480 password = 0x5555564b0080 "redhat" cipher_mode = <optimized out> ivgen_alg = <optimized out> ivgen_hash_alg = <optimized out> hash_alg = <optimized out> cipher_mode_spec = 0x555556488100 "xts-essiv:md5" ivcipheralg = QCRYPTO_CIPHER_ALG_CAST5_128 __func__ = "qcrypto_block_luks_create" #4 0x00005555555d5703 in qcrypto_block_create (options=options@entry=0x555556490280, initfunc=initfunc@entry=0x5555555c1640 <block_crypto_init_func>, writefunc=writefunc@entry=0x5555555c15e0 <block_crypto_write_func>, opaque=opaque@entry=0x55555661bf30, errp=errp@entry=0x55555661bf90) at crypto/block.c:98 block = 0x555556490a80 __func__ = "qcrypto_block_create" #5 0x00005555555c18cc in block_crypto_create_generic (format=Q_CRYPTO_BLOCK_FORMAT_LUKS, errp=0x55555661bf90, opts=<optimized out>, filename=<optimized out>) at block/crypto.c:353 ret = -22 create_opts = <optimized out> data = {filename = 0x55555648cc30 "/var/lib/libvirt/images/luks/luks1.img", opts = 0x5555564c0050, blk = 0x0, size = 1073741824} crypto = 0x0 #6 block_crypto_create_luks (filename=<optimized out>, opts=<optimized out>, errp=0x55555661bf90) at block/crypto.c:562 No locals. #7 0x0000555555572d4a in bdrv_create_co_entry (opaque=0x7fffffffdff0) at block.c:313 local_err = 0x0 ret = <optimized out> cco = 0x7fffffffdff0 #8 0x000055555561f15a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:78 self = 0x5555564bc120 co = 0x5555564bc120 #9 0x00007ffff3063110 in ?? () from /lib64/libc.so.6 No symbol table info available. (In reply to yisun from comment #13) > (In reply to Daniel Berrange from comment #11) > > (In reply to Daniel Berrange from comment #9) > > > > 3. (THIS MAYBE A BUG) when > > > > cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value > > > > doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a > > > > "unexpected fatal signal 11" > > > > > > > > # cat /tmp/luks_vol.xml > > > > <volume> > > > > <name>luks1.img</name> > > > > <capacity unit='G'>1</capacity> > > > > <target> > > > > <path>/var/lib/libvirt/images/luks/luks1.img</path> > > > > <format type='raw'/> > > > > <encryption format='luks'> > > > > <secret type='passphrase' > > > > uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/> > > > > <cipher name='cast5' size='128' mode='xts' hash='md5'/> > > > > <ivgen name='essiv' hash='md5'/> > > > > </encryption> > > > > </target> > > > > </volume> > > > > > > > > Running: virsh vol-create luks /tmp/luks_vol.xml > > > > error: Failed to create vol from /tmp/luks_vol.xml > > > > error: internal error: Child process (/usr/bin/qemu-img create -f luks > > > > --object > > > > secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img. > > > > secret.eaTuyc -o > > > > key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5, > > > > ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img > > > > 1048576K) unexpected fatal signal 11 > > > > > > Yep, seeing a signal 11 is always a bug. I'll investigate this > > > > I'm unable to reproduce that crash. Can you provide information about what > > version of QEMU you saw this with, what OS platform, etc. Also could you > > capture a stack trace with GDB > > qemu versions: > qemu-img-rhev-2.6.0-22.el7.x86_64 > qemu-kvm-rhev-2.6.0-22.el7.x86_64 > > libvirt version: > libvirt-2.0.0-6.el7.x86_64 > > I tried with pure qemu-img cmd and it's not reproducible. Only reproducible > with virsh command mentioned in comment 7. Thanks, I've reproduced it now and figured out theproblem cast5-128 with xts is not a valid combination, since the former has a 8 byte blocksize, while xts mandates a 16 byte block size. Thus we were writing beyond the end of a buffer, causing memory corruption. We should report an error immediately for this invalid combination of xts + cast5-128 - the same applies to xts + aes-128, or any other -128 or -160 cipher - only -256 ciphers are permitted with xts. IOW, we should fix the bug in QEMU, and for your testing you should check that you see a nice error message for this combination - you shouldn't expect it to succeed. In debugging this, I also noticed the qemu is mistakenly built against gcrypt instead of nettle, so we must fix that too Hi, I made an attempt to create luks image on AMD host but failed. And it reports an error as follows. I have no idea why it failed on this platform. qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this platform # virsh secret-list UUID Usage -------------------------------------------------------------------------------- 2ee92d96-c090-457a-8012-e22a7821235c ceph client.ceph d0d5ded3-1647-4e35-b954-31c157c2fa0d volume luks.secret # cat vol-luks.xml <volume> <name>luks.img</name> <source> </source> <capacity unit="G">1</capacity> <target> <format type='raw'/> <encryption format='luks'> <secret type='passphrase' usage='luks.secret'/> </encryption> </target> </volume> # virsh vol-create default vol-luks.xml error: Failed to create vol from vol-luks.xml error: internal error: Child process (/usr/local/bin/qemu-img create -f luks --object secret,id=luks.img_luks0,file=/var/run/libvirt/storage/default.luks.img.secret.4itYUR -o key-secret=luks.img_luks0 /var/lib/libvirt/images/luks.img 1048576K) unexpected exit status 1: 2016-08-29 05:19:52.223+0000: 28127: debug : virFileClose:102 : Closed fd 28 2016-08-29 05:19:52.223+0000: 28127: debug : virFileClose:102 : Closed fd 30 2016-08-29 05:19:52.223+0000: 28127: debug : virFileClose:102 : Closed fd 26 qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this platform Created attachment 1195188 [details]
virsh capabilities
Added output of virsh capabilities
(In reply to yangyang from comment #15) > Hi, > > I made an attempt to create luks image on AMD host but failed. And it > reports an error as follows. I have no idea why it failed on this platform. > > qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this > platform This message says it is missing libuuid.so but the official RPM builds include this. Did you build qemu yourself ? (In reply to Daniel Berrange from comment #17) > (In reply to yangyang from comment #15) > > Hi, > > > > I made an attempt to create luks image on AMD host but failed. And it > > reports an error as follows. I have no idea why it failed on this platform. > > > > qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this > > platform > > This message says it is missing libuuid.so but the official RPM builds > include this. > > Did you build qemu yourself ? No. I uses the official qemu build qemu-kvm-rhev-2.6.0-22.el7.x86_64 Fix included in qemu-kvm-rhev-2.6.0-24.el7 Comment 18 yangyang 2016-09-05 06:30:20 EDT has some questions not confirmed yet, thx. Please re-test with the newer build qemu-kvm-rhev-2.6.0-24.el7 which has switched to using nettle instead of gcrypt You've installed a duplicate version of QEMU in /usr/local that is clashing with the RPM installed version and missing functionality of the proper RPM install. So all testing you've done in this particular host is invalid, as its potentially using the wrong QEMU. (In reply to Daniel Berrange from comment #26) > You've installed a duplicate version of QEMU in /usr/local that is clashing > with the RPM installed version and missing functionality of the proper RPM > install. So all testing you've done in this particular host is invalid, as > its potentially using the wrong QEMU. Hi Yangyang, Could you have a look? Best Regards, Junyi Daniel and Junyi I apologize for the duplicate QEMU in my host and thank you. Re-tested it after removing self-build QEMU. The problem is not reproduced Thanks Hi Daniel, I have tested luks as comment 29 described. Could you help to confirm below questions? 1. Is it enough to verify this bz? If not, could you help to share some suggestion for verification? 2. If there is something wrong in the comment 29, please help to correct it. Thanks in advance. Hi Daniel, I tested qemu-iotests both in upstream and redhat repo. But the results are different from what you shared. Coudld you help to check it? For detailed result, you can refer the attachment. Seems redhat repo doesn't support to test luks format, as there is no "-luks" option in tests/qemu-iotests/common. upstream repo: git://git.qemu.org/qemu.git redhat repo: git://git.app.eng.bos.redhat.com/virt/rhel7/qemu-kvm.git Steps of qemu-iotests for luks: #git clone git://git.qemu.org/qemu.git #cd qemu #yum install zlib* glib* -y #git submodule update --init pixman #git submodule update --init dtc #./configure #cd tests/qemu-iotests/ #export QEMU_PROG=/usr/libexec/qemu-kvm #./check -luks Passed: 001 002 003 004 005 008 009 010 011 012 021 032 048 052 143 149 Not run: 007 013 014 015 017 018 019 020 022 023 024 025 026 027 028 029 030 031 034 035 036 037 038 039 040 041 042 043 044 045 046 047 049 050 051 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 101 102 103 104 105 107 108 109 110 111 112 113 114 115 116 117 118 119 121 122 123 124 128 129 130 131 132 133 134 135 136 137 138 139 141 142 144 146 148 150 152 154 155 156 Failures: 033 120 140 145 157 162 Failed 6 of 22 tests Created attachment 1203602 [details]
result for qemu-iotests of luks format
Oh, my mistake. I forgot that the iotest support was not added until QEMU 2.7, so we can't test it in RHEL-7.3 version of QEMU 2.6. So just ignore the iotests suggestion. (In reply to Daniel Berrange from comment #36) > Oh, my mistake. I forgot that the iotest support was not added until QEMU > 2.7, so we can't test it in RHEL-7.3 version of QEMU 2.6. So just ignore the > iotests suggestion. Yes. I checked the tag in upstream repo, the latest tag is v2.7.0-rc5. Maybe that is why I can test luks format in upstream repo. Above all, may i set this BZ as verified? (In reply to pingl from comment #37) > Above all, may i set this BZ as verified? Yep, that's ok (In reply to Daniel Berrange from comment #38) > (In reply to pingl from comment #37) > > Above all, may i set this BZ as verified? > > Yep, that's ok @Daniel Appreciate for kindly help. Set this BZ as verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2673.html |