** Description changed: [Impact] - * An explanation of the effects of the bug on users and + * An explanation of the effects of the bug on users and - * justification for backporting the fix to the stable release. + * justification for backporting the fix to the stable release. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. [Test Case] - * Prepare a guest - $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily + * Prepare a guest + $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial label=daily - * Shut it down and use virsh edit to add a channel for the agent + * Shut it down and use virsh edit to add a channel for the agent. Add this somewhere under <devices>: <channel type='unix'> - <source mode='bind'/> - <target type='virtio' name='org.qemu.guest_agent.0'/> + <source mode='bind'/> + <target type='virtio' name='org.qemu.guest_agent.0'/> </channel> - * Start the guest again, in it install qemu-guest-agent + * Start the guest again, in it install qemu-guest-agent - * + * - * On the Host then freeze and thaw the guest - $ virsh domfsfreeze x-freeze - $ virsh domfsthaw x-freeze + * On the Host then freeze and thaw the guest + $ virsh domfsfreeze x-freeze + $ virsh domfsthaw x-freeze - # The above works, then trigger the issue, in the guest do - $ sudo mkdir /mnt/test - $ sudo mount -o bind / /mnt/test/ + # The above works, then trigger the issue, in the guest do + $ sudo mkdir /mnt/test + $ sudo mount -o bind / /mnt/test/ - * Now the freeze/thaw will fail unless the fix is applied. + * Now the freeze/thaw will fail unless the fix is applied. [Regression Potential] - * From looking at the code alone I could think of a different cause that - makes it return EBUSY. - The biggest risk I could see due to that is the agent reporting a - successful freeze due to accepting EBUSY which is not actually true. - But we have that in Ubuntu since Artful and - upstream since January 2017 and there are no such reports. + * From looking at the code alone I could think of a different cause that + makes it return EBUSY. + The biggest risk I could see due to that is the agent reporting a + successful freeze due to accepting EBUSY which is not actually true. + But we have that in Ubuntu since Artful and + upstream since January 2017 and there are no such reports. [Other Info] - - * n/a + * n/a --- Having two mounts of the same device makes fsfreeze through qemu-ga impossible. root@CmsrvMTA:/# mount -l | grep /dev/vda2 /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@) /dev/vda2 on /home type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@home) Having two mounts is rather common with btrfs, so the feature fsfreeze is unusable on these systems. Below more information about how we encountered this issue... Message send to qemu-disc...@nongnu.org: Message 1: ---------- I use external snapshots to backup my guests. I use the 'quiesce' option to flush and frees the guest file system with the qemu guest agent. With the exeption of one guest, this procedure works fine. On the 'unwilling' guest, I get this error message: "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy" I don't think this is not some sort of time-out error, because activation of the fsfreeze and the error message happen immediately after each other: $ grep qemu-ga syslog.1 May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called This is the only entry of the qemu guest agent in syslog. $ sudo virsh version Compiled against library: libvirt 1.3.1 Using library: libvirt 1.3.1 Gebruikte API: QEMU 1.3.1 Draaiende hypervisor: QEMU 2.5.0 $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}' {"return":{"version":"2.5.0", ... ,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true}, ... } For making an external snapshot, I use this command: $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic --quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1 Piece of reply 1: ----------------- I have encountered this before. Some operating systems may have bind-mounts that let a device appear multiple times in the mount list. Unfortunately the guest agent is not smart enough to consider a device that has been frozen as succesfull and keep going. This causes this specific error. Piece of reply 2: ----------------- Ok, that seems to be it. I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on two separate sub volumes.
-- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1587065 Title: btrfs qemu-ga - multiple mounts block fsfreeze Status in QEMU: Fix Released Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Xenial: In Progress Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Case] * Prepare a guest $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial label=daily * Shut it down and use virsh edit to add a channel for the agent. Add this somewhere under <devices>: <channel type='unix'> <source mode='bind'/> <target type='virtio' name='org.qemu.guest_agent.0'/> </channel> * Start the guest again, in it install qemu-guest-agent * * On the Host then freeze and thaw the guest $ virsh domfsfreeze x-freeze $ virsh domfsthaw x-freeze # The above works, then trigger the issue, in the guest do $ sudo mkdir /mnt/test $ sudo mount -o bind / /mnt/test/ * Now the freeze/thaw will fail unless the fix is applied. [Regression Potential] * From looking at the code alone I could think of a different cause that makes it return EBUSY. The biggest risk I could see due to that is the agent reporting a successful freeze due to accepting EBUSY which is not actually true. But we have that in Ubuntu since Artful and upstream since January 2017 and there are no such reports. [Other Info] * n/a --- Having two mounts of the same device makes fsfreeze through qemu-ga impossible. root@CmsrvMTA:/# mount -l | grep /dev/vda2 /dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@) /dev/vda2 on /home type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@home) Having two mounts is rather common with btrfs, so the feature fsfreeze is unusable on these systems. Below more information about how we encountered this issue... Message send to qemu-disc...@nongnu.org: Message 1: ---------- I use external snapshots to backup my guests. I use the 'quiesce' option to flush and frees the guest file system with the qemu guest agent. With the exeption of one guest, this procedure works fine. On the 'unwilling' guest, I get this error message: "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy" I don't think this is not some sort of time-out error, because activation of the fsfreeze and the error message happen immediately after each other: $ grep qemu-ga syslog.1 May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called This is the only entry of the qemu guest agent in syslog. $ sudo virsh version Compiled against library: libvirt 1.3.1 Using library: libvirt 1.3.1 Gebruikte API: QEMU 1.3.1 Draaiende hypervisor: QEMU 2.5.0 $ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}' {"return":{"version":"2.5.0", ... ,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true}, ... } For making an external snapshot, I use this command: $ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic --quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1 Piece of reply 1: ----------------- I have encountered this before. Some operating systems may have bind-mounts that let a device appear multiple times in the mount list. Unfortunately the guest agent is not smart enough to consider a device that has been frozen as succesfull and keep going. This causes this specific error. Piece of reply 2: ----------------- Ok, that seems to be it. I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on two separate sub volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1587065/+subscriptions
