[Qemu-devel] [Bug 1455475] Re: Block Commit: [100 %]error: failed to pivot job for disk vda
** Also affects: ubuntu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1455475 Title: Block Commit: [100 %]error: failed to pivot job for disk vda Status in QEMU: New Status in Ubuntu: Confirmed Bug description: Hi, i´ve a Problem with committing a snapshot. The problem was discussed on the libvirt mailing list earlier this year. https://www.redhat.com/archives/libvirt- users/2015-January/msg00029.html Iam running gentoo and: Compiled against library: libvirt 1.2.14 Using library: libvirt 1.2.14 Using API: QEMU 1.2.14 Running hypervisor: QEMU 2.3.0 I´am running a Windows Server 2012 R2 VM with the latest quest driver (0.1.96) and QEMU quest Agent 0.12.1 installed. The domain is started with following command line: /usr/bin/qemu-system-x86_64 -name $DOMAIN -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid c96ef576-dbfc-49aa-9dd0-068886c4ef0e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/$DOMAIN.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/$DOMAIN.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:07:b4:0a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 127.0.0.1:6 -k de -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on char device redirected to /dev/pts/2 (label charserial0) I´ve created the snapshot with: virsh # snapshot-create-as --domain $DOMAIN snap1 --diskspec vda,file=/var/lib/libvirt/images/snap1.qcow2 --quiesce --disk-only --atomic --no-metadata Domain snapshot snap1 created If i try to commit the snapshot i get this error: virsh # blockcommit $DOMAIN vda --active --verbose --pivot error: internal error: unable to execute QEMU command 'block-commit': Device 'drive-virtio-disk0' is busy: block device is in use by block job: commit virsh # blockjob $DOMAIN /var/lib/libvirt/images/snap1.qcow2 Block Commit: [100 %] virsh # $DOMAIN var/lib/libvirt/images/snap1.qcow2 --abort virsh # blockjob $DOMAIN /var/lib/libvirt/images/snap1.qcow2 No current block job for /var/lib/libvirt/images/snap1.qcow2 I´ve test this with qemu 2.1 and the problem does`nt exist. /usr/bin/qemu-system-x86_64 -name $DOMAIN -S -machine pc- i440fx-1.6,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid 30c49f37-6e62-49f6-a9df- ad2fef1fa312 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/$DOMAIN.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb- uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id =virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/$DOMAIN.qcow2,if=none,id=drive-virtio- disk0,format=qcow2 -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait -device virtserialport,bus=virtio- serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k de -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on Compiled against library: libvirt 1.2.11 Using library: libvirt 1.2.11 Using API: QEMU 1.2.11 Running hypervisor: QEMU 2.1.2 virsh # snapshot-create-as --domain windows.trohde-snapshot-test windows.trohde-snapshot-test_snap1 --diskspec vda,file=/var/lib/libvirt/images/windows.trohde-snapshot-test_snap1.qcow2 --quiesce --disk-only --atomic --no-metadata Domain snapshot windows.trohde-snapshot-test_snap1 created virsh # blockcommit $DOMAIN vda --active --verbose --pivot Block Commit: [100 %] Successfully pivoted Cheers Tim To manage notifications about this bug go to:
[Qemu-devel] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files
** Also affects: ubuntu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handles on unlinked files
Status in QEMU:
New
Status in Ubuntu:
New
Bug description:
This was originally filed over here:
https://bugzilla.redhat.com/show_bug.cgi?id=1114221
The open-unlink-fstat idiom used in some places to create an anonymous
private temporary file does not work in a QEMU guest over a virtio-9p
filesystem.
Version-Release number of selected component (if applicable):
qemu-kvm-1.6.2-6.fc20.x86_64
qemu-system-x86-1.6.2-6.fc20.x86_64
(those are fedora RPMs)
How reproducible:
Always. See this example C program:
https://bugzilla.redhat.com/attachment.cgi?id=913069
Steps to Reproduce:
1. Export a filesystem with virt-manager for the guest.
(type: mount, driver: default, mode: passthrough)
2. Start guest and mount that filesystem
(mount -t 9p -o trans=virtio,version=9p2000.L ...)
3. Run a program that uses open-unlink-fstat
(in my case it was trying to compile Perl 5.20)
Actual results:
fstat fails:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename")= 0
fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or
directory)
close(3)
Expected results:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename")= 0
fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
close(3)
Additional info:
There was a patch put into the kernel back in '07 to handle this very
problem for other filesystems; maybe its helpful:
http://lwn.net/Articles/251228/
There is also a thread on LKML from last December specifically about
this very problem:
https://lkml.org/lkml/2013/12/31/163
There was a discussion on the QEMU list back in '11 that doesn't seem
to have come to a conclusion, but did provide the test program that
i've attached to this report:
http://marc.info/?l=qemu-devel=130443605720648=2
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1336794/+subscriptions
[Qemu-devel] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files
I would appreciate this patch being committed as I *think* it's
affecting a system i'm building now.
I have a backup host with 2 VMs. For business reasons they need to be
network isolated from each other and the host, so each is passed through
a physical NIC. Each VM does need access to a variable size datastore on
the host so I am using virtfs /9p to expose a mountpoint to each VM.
The VMs each backup servers to their respective mountpoint to this
virtfs mount using rsync. Just backing up one server with ~4000 files
and 3 large sparse VM images saw the open files on the backup host
increase to over *80* and the rsync progressively get slower.
Shutting down these VMs then takes hours as it can't unlock the files it
has open on the backup host.
I understand rsync does use open-unlink-fstat extensively, hence why I
think this is the issue.
This is a deal breaker for any production use of virtfs. Does anybody
know if this is fixed in other builds of qemu?
tl;dr - to recreate this on 16.04 - create a VM with a virtfs/9p mount
to the host. Do lots of rsyncs to this mount within the VM, watch 'lsof
| wc -l' go higher and higher on the host.
Thanks,
/Sean
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handles on unlinked files
Status in QEMU:
New
Bug description:
This was originally filed over here:
https://bugzilla.redhat.com/show_bug.cgi?id=1114221
The open-unlink-fstat idiom used in some places to create an anonymous
private temporary file does not work in a QEMU guest over a virtio-9p
filesystem.
Version-Release number of selected component (if applicable):
qemu-kvm-1.6.2-6.fc20.x86_64
qemu-system-x86-1.6.2-6.fc20.x86_64
(those are fedora RPMs)
How reproducible:
Always. See this example C program:
https://bugzilla.redhat.com/attachment.cgi?id=913069
Steps to Reproduce:
1. Export a filesystem with virt-manager for the guest.
(type: mount, driver: default, mode: passthrough)
2. Start guest and mount that filesystem
(mount -t 9p -o trans=virtio,version=9p2000.L ...)
3. Run a program that uses open-unlink-fstat
(in my case it was trying to compile Perl 5.20)
Actual results:
fstat fails:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename")= 0
fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or
directory)
close(3)
Expected results:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename")= 0
fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
close(3)
Additional info:
There was a patch put into the kernel back in '07 to handle this very
problem for other filesystems; maybe its helpful:
http://lwn.net/Articles/251228/
There is also a thread on LKML from last December specifically about
this very problem:
https://lkml.org/lkml/2013/12/31/163
There was a discussion on the QEMU list back in '11 that doesn't seem
to have come to a conclusion, but did provide the test program that
i've attached to this report:
http://marc.info/?l=qemu-devel=130443605720648=2
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1336794/+subscriptions
