RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 908148 - should block to mount the fs when the guest fs frozen via virtagent commands "guest-fsfreeze-freeze"
Summary: should block to mount the fs when the guest fs frozen via virtagent commands ...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-06 02:28 UTC by Sibiao Luo
Modified: 2015-08-14 08:59 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-06 11:21:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sibiao Luo 2013-02-06 02:28:49 UTC 
Description of problem:
boot a guest with a data disk, and mkfs to it, then frozen the guest fs via virtagent commands "guest-fsfreeze-freeze", check the guest fs status was frozen, but can mount the data disk successfully (it should be blocked).

host info:
kernel-3.7.0-0.34.el7
qemu-kvm-1.3.0-3.el7
guest info:
kernel-3.7.0-0.34.el7
qemu-guest-agent-1.3.0-3.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.start guest with virtio-serial and attach a data disk.
e.g:...-drive file=/home/my-data-disk.qcow2,if=none,id=drive-data-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x8 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0,id=sr0
2.start guest agent inside guest and connect the chardev socket in host side for sending commands to guest.
guest] # /usr/bin/qemu-ga on
host ] # nc -U /tmp/qga.sock
3.check guest fs status and format the data disk in guest.
{"execute":"guest-fsfreeze-status"}
guest] # mkfs.ext4 /dev/sdb
4.frozen the guest fs via virtagent commands "guest-fsfreeze-freeze".
{"execute":"guest-fsfreeze-freeze"}
{"execute":"guest-fsfreeze-status"}
5.check guest fs status.
 A.Run guest-fsfreeze-status again:
   {"execute":"guest-fsfreeze-status"}
 B.try to create a file inside the guest.
   # echo foo > /tmp/foo
6.monut the data disk to /mnt and check it.
# mount /dev/sdb /mnt/
# mount

Actual results:
after step 3, the guest fs was thawed status and format data disk successfully.
{"execute":"guest-fsfreeze-status"}
{"return": "thawed"}
after step 4, frozen the guest fs successfully.
{"execute":"guest-fsfreeze-freeze"}
{"return": 2}
{"execute":"guest-fsfreeze-status"}
{"return": "frozen"}
after step 5, check guest fs status was frozen successfully.
 A.{"execute":"guest-fsfreeze-status"}
   {"return": "frozen"}
 B.it block to create a file in guest.
after step 6, mount the data disk successfully (it should block).
# mount
...
/dev/sdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)

Expected results:
should be blocked to mount the data disk in step 5 when the guest fs was frozen status.

Additional info:
Comment 1 Sibiao Luo 2013-02-06 02:55:01 UTC 
my qemu-kvm command line:
# /usr/libexec/qemu-kvm -M pc-1.3 -cpu Westmere -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -name sluo-test -uuid 350e716b-5f98-4bf0-9a2a-c8e423295244 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/RHEL-Server-7.0-64-virtio.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device scsi-hd,drive=drive-system-disk,bus=scsi0.0,id=system-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=08:2E:5F:0A:0D:B1,bus=pci.0,addr=0x5,bootindex=2,event_idx=off -device virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -device usb-ehci,id=ehci,bus=pci.0,addr=0x7 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3 -drive file=/home/my-data-disk.qcow2,if=none,id=drive-data-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x8 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk -k en-us -boot menu=on -qmp tcp:0:4444,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :1 -drive file=/home/floppy.vfd,if=none,id=drive-fdc0-0-0,format=raw -global isa-fdc.driveA=drive-fdc0-0-0 -drive file=/home/my-cdrom.iso,if=none,media=cdrom,format=raw,id=drive-ide1-0-1 -device ide-drive,drive=drive-ide1-0-1,id=ide1-0-1,bus=ide.0,unit=0 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0,id=sr0 -monitor stdio
Comment 2 Luiz Capitulino 2013-02-06 11:21:25 UTC 
Why it should be blocked? The purpose of FS freeze is to block writes so that the FS is in a consistent state for a snapshot.
Comment 3 Paolo Bonzini 2013-02-06 12:31:13 UTC 
I think it's not NOTABUG, but rather CANTFIX.  It would be desirable, but it's not possible.

guest-fsfreeze-freeze is only able to freeze _filesystem_, not block devices.  So, if you mount a filesystem after the freeze has happened it won't work, because the filesystem didn't exist (for the OS; it existed on disk) at the time guest-fsfreeze-freeze is invoked.
Comment 4 Gu Nini 2014-11-27 01:42:47 UTC 
I met a similar issue under PPC system on PPC64 host/PPC64le guest, i.e. after guest fs frozen, "umount /dev/sdb" can be succeed, but couldn't "mkfs.ext4 /dev/sdb" after the umount; and if "dd if=/dev/zero of=/dev/sdb bs=1M count=1", then mount the device again with cmd "mount /dev/sdb /media", it's a failure, while mount a new device with cmd "mount /dev/sdc /media" would be a success.

The software versions are:
qemu-kvm:
qemu-kvm-2.0.0-2.1.pkvm2_1_1.20.39.ppc64
qemu-kvm-tools-2.0.0-2.1.pkvm2_1_1.20.39.ppc64

host kernel:
3.10.42-2018.1.pkvm2_1_1.46.ppc64

guest kernel:
3.10.0-201.ae17a.ppc64le
Comment 5 Luiz Capitulino 2014-11-28 14:21:10 UTC 
The same answer from comment 2 and comment 3 applies. The original use-case behind this feature is to freeze a file-system for the purposes of a getting a snapshot. If we need anything beyond that, then an RFE should be opened with the intended use-case description.
Comment 6 Gu Nini 2015-04-01 11:30:44 UTC 
(In reply to Gu Nini from comment #4)


For a rhel7.2 Power PC host with kernel 3.10.0-234.el7.ppc64, when guest file system is frozen, for guest rhel7.2, the 'mount'/'umount' operation could be executed; while for guest rhel6.7, the corresponding operation could indeed not be executed. Besides, for the 'umount', there is bz 1208090 issue.
Comment 8 David Gibson 2015-04-08 04:54:41 UTC 
Sorry, I don't really understand what the question is.

I don't know much about the block layer, so I don't really know what the semantics of fsfreeze are supposed to be.

Are you saying there is a difference in behaviour between ppc64 and x86_64?  Are you saying there is a difference between RHEL6 and RHEL7?

So far, I can't see anything which suggests there's something ppc specific here.
Comment 9 Gu Nini 2015-04-09 02:37:59 UTC 
(In reply to David Gibson from comment #8)
... ...
> 
> Are you saying there is a difference in behaviour between ppc64 and x86_64? 
> Are you saying there is a difference between RHEL6 and RHEL7?
> 
> So far, I can't see anything which suggests there's something ppc specific
> here.

Yes, there is only difference between RHEL6.7 and RHEL7.2 guest, both on the same RHEL7.2 HOST; and I have only done test on PPC64 host/guests, so not relate to x86_64 and the difference.

In comment 6, from my test result, I just want to say the difference of 'mount/umount' behaviour between RHEL6.7 and RHEL7.2 guests on the same RHEL HOST, and point out bz 1208090 on both guests.
Comment 10 Xujun Ma 2015-08-14 08:59:33 UTC 
host info:
kernel-3.10.0-302.el7.ppc64le
qemu-kvm-rhev-2.3.0-17.el7.ppc64le
guest info:
kernel-3.10.0-302.el7.ppc64le
qemu-guest-agent-2.3.0-2.el7.ppc64le

now,the operation, mount or umount fs, can't be excuted when fs was frozened.
Note You need to log in before you can comment on or make changes to this bug.