Bug 908148
| Summary: | should block to mount the fs when the guest fs frozen via virtagent commands "guest-fsfreeze-freeze" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> |
| Component: | qemu-kvm | Assignee: | Virtualization Maintenance <virt-maint> |
| Status: | CLOSED CANTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | acathrow, chayang, dgibson, flang, hhuang, juzhang, kwolf, lcapitulino, michen, ngu, pbonzini, qzhang, sluo, virt-maint, xuma |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-06 11:21:25 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: | |
| Embargoed: | |||
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: 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 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 > 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. 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. |
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: