Red Hat Bugzilla – Bug 908148
should block to mount the fs when the guest fs frozen via virtagent commands "guest-fsfreeze-freeze"
Last modified: 2015-08-14 04:59:33 EDT
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).
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/
after step 3, the guest fs was thawed status and format data disk successfully.
after step 4, frozen the guest fs successfully.
after step 5, check guest fs status was frozen successfully.
B.it block to create a file in guest.
after step 6, mount the data disk successfully (it should block).
/dev/sdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
should be blocked to mount the data disk in step 5 when the guest fs was frozen status.
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
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.
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.
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:
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.
(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.
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.
(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
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.
now,the operation, mount or umount fs, can't be excuted when fs was frozened.