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

Results:
after step 3, the VHDX disk(/dev/vdb) has a wrong authority permitted message.
# mkfs.ext4 /dev/vda
mke2fs 1.42.8 (20-Jun-2013)
/dev/vda is apparently in use by the system; will not make a filesystem here!

(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