Bug 908148 - should block to mount the fs when the guest fs frozen via virtagent commands "guest-fsfreeze-freeze"
should block to mount the fs when the guest fs frozen via virtagent commands ...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Virtualization Maintenance
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2013-02-05 21:28 EST by Sibiao Luo
Modified: 2015-08-14 04:59 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-06 06:21:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sibiao Luo 2013-02-05 21:28:49 EST
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:
guest info:

How reproducible:

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.
guest] # mkfs.ext4 /dev/sdb
4.frozen the guest fs via virtagent commands "guest-fsfreeze-freeze".
5.check guest fs status.
 A.Run guest-fsfreeze-status again:
 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.
{"return": "thawed"}
after step 4, frozen the guest fs successfully.
{"return": 2}
{"return": "frozen"}
after step 5, check guest fs status was frozen successfully.
   {"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-05 21:55:01 EST
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 06:21:25 EST
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 07:31:13 EST
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-26 20:42:47 EST
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:

host kernel:

guest kernel:
Comment 5 Luiz Capitulino 2014-11-28 09:21:10 EST
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 07:30:44 EDT
(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 00:54:41 EDT
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-08 22:37:59 EDT
(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 04:59:33 EDT
host info:
guest info:

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.