vice
virtio-blk-device,drive=inst-blk -drive
file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw
console=ttyAMA0" -nographic
Is there anything to do to understand, if this is a hardware related
failure or probably just a missing parameter?
Regards
Lutz
To
console=ttyAMA0" -nographic
Is there anything to do to understand, if this is a hardware related
failure or probably just a missing parameter?
Regards
Lutz
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836501/+subscriptions
; -nographic
Is there anything to do to understand, if this is a hardware related
failure or probably just a missing parameter?
Regards
Lutz
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836501/+subscriptions
there anything to do to understand, if this is a hardware related
failure or probably just a missing parameter?
Regards
Lutz
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
htt
On 04/21/2016 05:54 PM, Lutz Vieweg wrote:
And indeed, the errors occured exactly at the time a backup procedure
was preparing a read-only snapshot with "btrfs subvolume snapshot -r" -
so until I can upgrade to a mainline kernel including the fix, I'll
pause the qemu process w
On 04/20/2016 04:38 PM, Lutz Vieweg wrote:
I've now a
strace -f -p 10727 -e trace=pwrite,pwritev,fdatasync,file -t 2>&1 | gzip -1 -c
>trace.gz
attached to the qemu-process.
If the incident rate stays the same, by tomorrow I should be able
to correlate newly emitted I/O-erro
rocess.
If the incident rate stays the same, by tomorrow I should be able
to correlate newly emitted I/O-errors in the guest with that log.
Regards,
Lutz Vieweg
for in the output - some failed "pwrite()"
to the image file?)
Regards,
Lutz Vieweg
- providing a 10-fold speed increase in
my tests.
Regards,
Lutz Vieweg
Adding to my symptom description: I re-tested with "vhost=on" in addition
and verified this feature was actually used.
But this didn't change the benchmark results.
Regards,
Lutz Vieweg
On 01/20/2012 04:10 PM, Lutz Vieweg wrote:
Hi,
I've been using qemu-kvm along with
twork devices?)
Regards,
Lutz Vieweg
am not sure whether
this is the whole reason for the bad performance.
Any ideas?
Or should I rather stay with ordinary tap/brctl, or try yet another
virtual NIC technique?
Regards,
Lutz Vieweg
ons
on which syscall number is associated with what function.
In fact, the so often used syscall was "preadv", not "openat".
Thus my only suggestion is to change the default for "msize="
to 131072 (128k), this results in a speed up from ~ 30MB/s to ~ 290MB/s
in the
rce) - the functions that contain those calls
are static and seem to become inlined.
Does anyone have an idea what may have caused this? Do you still see
good read performance when reading big plain files from a 9p mount.
Regards,
Lutz Vieweg
tional ACLs,
not requiring any additional tools being run, not requiring any
exploit-prone suid executables?
Regards,
Lutz Vieweg
-kvm 0.15 now works
with the USB device as good as before.
Regards,
Lutz Vieweg
Public bug reported:
When I try to start a virtual machine (x86_64 guest on a x86_64 host
that has 32GB memory, using kvm_amd module, both host and guest running
linux-2.6.39 kernels) with "qemu-system-x86_64 -cpu host -smp 2 -m 4096
...", shortly after the guest kernel starts, qemu aborts with a
17 matches
Mail list logo
