| Summary: | wrong authority permitted message when attach a read-only VHDX disk | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> |
| Component: | qemu-kvm | Assignee: | Jeff Cody <jcody> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.0 | CC: | acathrow, bsarathy, chayang, famz, hhuang, jcody, juzhang, michen, mkenneth, qzhang, sluo, virt-maint, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1017586 | Environment: | |
| Last Closed: | 2014-05-27 18:44:10 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: | |
| Bug Depends On: | 1017586 | ||
| Bug Blocks: | |||
|
Comment 1
Sibiao Luo
2013-11-13 02:59:51 UTC
(In reply to Sibiao Luo from comment #1) > host info: > 3.10.0-48.el7.x86_64 > qemu-kvm-1.5.3-19.el7.x86_64 > guest info: > 3.10.0-48.el7.x86_64 > > Steps: > 1.create a VHDX image via hyper-V. > # qemu-img info /home/sluo-rhel7.0-64bit.vhdx > image: /home/sluo-rhel7.0-64bit.vhdx > file format: vhdx > virtual size: 10G (10737418240 bytes) > disk size: 1.3G > 2.copy the vhdx image into localhost and boot guest with this VHDX image as > data disk which was specified read-only. > e.g:... -drive > file=/home/sluo-RHEL6.4.z-32bit.vhdx,if=none,id=drive-virtio-disk1, > format=vhdx,cache=none,aio=native,werror=stop,rerror=stop,readonly -device > virtio-blk-pci,vectors=0,bus=pci.0,addr=0x7,scsi=off,drive=drive-virtio- > disk1,id=virtio-disk1,bootindex=2 > 3.format the data disk in guest. > # mkfs.ext4 /dev/vdX > I've been unable to reproduce this, from -19 up to the currently git head version of qemu-kvm-1.5.3-60.el7, I get the appropriate message of: # mkfs.ext4 /dev/vdb /dev/vdb: Operation not permitted while setting up superblock > Results: > after step 3, the VHDX disk(/dev/vdb) has a wrong authority permitted > message. > # mkfs.ext4 /dev/vda Shouldn't this be /dev/vdb? > mke2fs 1.42.8 (20-Jun-2013) > /dev/vda is apparently in use by the system; will not make a filesystem here! If this was accidentally run on /dev/vda (the boot device), this would be an appropriate error message. (In reply to Jeff Cody from comment #3) > (In reply to Sibiao Luo from comment #1) > > host info: > > 3.10.0-48.el7.x86_64 > > qemu-kvm-1.5.3-19.el7.x86_64 > > guest info: > > 3.10.0-48.el7.x86_64 > > > > Steps: > > 1.create a VHDX image via hyper-V. > > # qemu-img info /home/sluo-rhel7.0-64bit.vhdx > > image: /home/sluo-rhel7.0-64bit.vhdx > > file format: vhdx > > virtual size: 10G (10737418240 bytes) > > disk size: 1.3G > > 2.copy the vhdx image into localhost and boot guest with this VHDX image as > > data disk which was specified read-only. > > e.g:... -drive > > file=/home/sluo-RHEL6.4.z-32bit.vhdx,if=none,id=drive-virtio-disk1, > > format=vhdx,cache=none,aio=native,werror=stop,rerror=stop,readonly -device > > virtio-blk-pci,vectors=0,bus=pci.0,addr=0x7,scsi=off,drive=drive-virtio- > > disk1,id=virtio-disk1,bootindex=2 > > 3.format the data disk in guest. > > # mkfs.ext4 /dev/vdX > > > > I've been unable to reproduce this, from -19 up to the currently git head > version of qemu-kvm-1.5.3-60.el7, I get the appropriate message of: > > # mkfs.ext4 /dev/vdb > /dev/vdb: Operation not permitted while setting up superblock > > > Results: > > after step 3, the VHDX disk(/dev/vdb) has a wrong authority permitted > > message. > > # mkfs.ext4 /dev/vda > > Shouldn't this be /dev/vdb? No, /dev/vda is my system disk, /dev/vdb is the data disk. > > mke2fs 1.42.8 (20-Jun-2013) > > /dev/vda is apparently in use by the system; will not make a filesystem here! > > If this was accidentally run on /dev/vda (the boot device), this would be an > appropriate error message. My data disk has OS file system in it as I created it in step 1 via Hyper-V(IIRC i have installed guest OS in it, then copy it out to my local host) in comment #0. Maybe the problem is that why it prompt 'in use by the system' while not 'Operation not permitted' when i assigned it with read-only specified in qemu-kvm command line ? Best Regards, sluo (In reply to Sibiao Luo from comment #4) > (In reply to Jeff Cody from comment #3) > > (In reply to Sibiao Luo from comment #1) > > > host info: > > > 3.10.0-48.el7.x86_64 > > > qemu-kvm-1.5.3-19.el7.x86_64 > > > guest info: > > > 3.10.0-48.el7.x86_64 > > > > > > Steps: > > > 1.create a VHDX image via hyper-V. > > > # qemu-img info /home/sluo-rhel7.0-64bit.vhdx > > > image: /home/sluo-rhel7.0-64bit.vhdx > > > file format: vhdx > > > virtual size: 10G (10737418240 bytes) > > > disk size: 1.3G > > > 2.copy the vhdx image into localhost and boot guest with this VHDX image as > > > data disk which was specified read-only. > > > e.g:... -drive > > > file=/home/sluo-RHEL6.4.z-32bit.vhdx,if=none,id=drive-virtio-disk1, > > > format=vhdx,cache=none,aio=native,werror=stop,rerror=stop,readonly -device > > > virtio-blk-pci,vectors=0,bus=pci.0,addr=0x7,scsi=off,drive=drive-virtio- > > > disk1,id=virtio-disk1,bootindex=2 > > > 3.format the data disk in guest. > > > # mkfs.ext4 /dev/vdX > > > > > > > I've been unable to reproduce this, from -19 up to the currently git head > > version of qemu-kvm-1.5.3-60.el7, I get the appropriate message of: > > > > # mkfs.ext4 /dev/vdb > > /dev/vdb: Operation not permitted while setting up superblock > > > > > Results: > > > after step 3, the VHDX disk(/dev/vdb) has a wrong authority permitted > > > message. > > > # mkfs.ext4 /dev/vda > > > > Shouldn't this be /dev/vdb? > > No, /dev/vda is my system disk, /dev/vdb is the data disk. > But in the text pasted above you have: # mkfs.ext4 /dev/vda Which is your system disk, and will be mounted. If that case the error message is correct for "mkfs.ext4 /dev/vda". Maybe I am misreading the description? What is your boot device; are you booting and mounting as '/' /dev/vda or /dev/vdb? > > > mke2fs 1.42.8 (20-Jun-2013) > > > /dev/vda is apparently in use by the system; will not make a filesystem here! > > > > If this was accidentally run on /dev/vda (the boot device), this would be an > > appropriate error message. > > My data disk has OS file system in it as I created it in step 1 via > Hyper-V(IIRC i have installed guest OS in it, then copy it out to my local > host) in comment #0. > > Maybe the problem is that why it prompt 'in use by the system' while not > 'Operation not permitted' when i assigned it with read-only specified in > qemu-kvm command line ? > If the partition is already mounted, you will get the message "/dev/vda is apparently in use by the system; will not make a filesystem here!" as the correct error message. Make sure that the partition is not mounted at all, before trying to run mkfs on it. Part of what is confusing is that this is an issue on RHEL6 (this incorrect message used on a non-mounted read-only qemu drive), but not on RHEL7 or upstream (at least, not from my testing). (In reply to Sibiao Luo from comment #4) > (In reply to Jeff Cody from comment #3) > > (In reply to Sibiao Luo from comment #1) > > > host info: > > > 3.10.0-48.el7.x86_64 > > > qemu-kvm-1.5.3-19.el7.x86_64 > > > guest info: > > > 3.10.0-48.el7.x86_64 > > > > > > Steps: > > > 1.create a VHDX image via hyper-V. > > > # qemu-img info /home/sluo-rhel7.0-64bit.vhdx > > > image: /home/sluo-rhel7.0-64bit.vhdx > > > file format: vhdx > > > virtual size: 10G (10737418240 bytes) > > > disk size: 1.3G > > > 2.copy the vhdx image into localhost and boot guest with this VHDX image as > > > data disk which was specified read-only. > > > e.g:... -drive > > > file=/home/sluo-RHEL6.4.z-32bit.vhdx,if=none,id=drive-virtio-disk1, > > > format=vhdx,cache=none,aio=native,werror=stop,rerror=stop,readonly -device > > > virtio-blk-pci,vectors=0,bus=pci.0,addr=0x7,scsi=off,drive=drive-virtio- > > > disk1,id=virtio-disk1,bootindex=2 > > > 3.format the data disk in guest. > > > # mkfs.ext4 /dev/vdX > > > > > > > I've been unable to reproduce this, from -19 up to the currently git head > > version of qemu-kvm-1.5.3-60.el7, I get the appropriate message of: > > > > # mkfs.ext4 /dev/vdb > > /dev/vdb: Operation not permitted while setting up superblock > > > > > Results: > > > after step 3, the VHDX disk(/dev/vdb) has a wrong authority permitted > > > message. > > > # mkfs.ext4 /dev/vda > > > > Shouldn't this be /dev/vdb? > > No, /dev/vda is my system disk, /dev/vdb is the data disk. > > > > mke2fs 1.42.8 (20-Jun-2013) > > > /dev/vda is apparently in use by the system; will not make a filesystem here! > > > > If this was accidentally run on /dev/vda (the boot device), this would be an > > appropriate error message. > > My data disk has OS file system in it as I created it in step 1 via > Hyper-V(IIRC i have installed guest OS in it, then copy it out to my local > host) in comment #0. > > Maybe the problem is that why it prompt 'in use by the system' while not > 'Operation not permitted' when i assigned it with read-only specified in > qemu-kvm command line ? > You are right, rhel7 guest did not have such issue according to my re-testing it, maybe i did make a mistake by chance when i cloned it to rhel7. You can help close it, thanks. e.g:...-drive file=/home/my-data-disk.vhdx,if=none,id=drive-virtio-disk1,format=vhdx,cache=none,aio=native,werror=stop,rerror=stop,readonly=on -device virtio-blk-pci,vectors=0,bus=pci.0,addr=0x7,scsi=off,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=2 (qemu) info block drive-virtio-disk: removable=0 io-status=ok file=/home/RHEL-Server-7.0-64-virtio.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 drive-virtio-disk1: removable=0 io-status=ok file=/home/my-data-disk.vhdx ro=1 drv=vhdx encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted] floppy0: removable=1 locked=0 tray-open=0 [not inserted] sd0: removable=1 locked=0 tray-open=0 [not inserted] guest ] # fdisk -l Disk /dev/vda: 21.5 GB, 21474836480 bytes, 41943040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000c211a Device Boot Start End Blocks Id System /dev/vda1 * 2048 1026047 512000 83 Linux /dev/vda2 1026048 41943039 20458496 8e Linux LVM Disk /dev/vdb: 10.7 GB, 10737418240 bytes, 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ... guest ]# mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=935848k,nr_inodes=233962,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) /dev/mapper/rhel-root on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota) tmpfs on /etc/machine-id type tmpfs (ro,relatime,seclabel,mode=755) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel) configfs on /sys/kernel/config type configfs (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) sunrpc on /proc/fs/nfsd type nfsd (rw,relatime) /dev/vda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota) guest ]# mkfs.ext4 /dev/vdb mke2fs 1.42.8 (20-Jun-2013) /dev/vdb: Operation not permitted while setting up superblock Best Regards, sluo |