support it? I can't use PCI passthrough feature to
pass the whole USB controller to VM, because the hypervisor also needs
to use some USB ports.
If I use Windows XP or Linux, the USB drive can work well.
I think it's because qemu/kvm does not support USB 2.0.
http://wiki.qemu.org/Plann
On 20.04.2011 11:28, Thomas Treutner wrote:
On 03/28/2011 10:14 PM, Tomasz Chmielewski wrote:
On 28.03.2011 22:04, Andrea Arcangeli wrote:
Tomasz, how easily can you reproduce?
Well, this server runs 10 VMs or so, and it happens after 1-2 days of
uptime.
I reverted now to a 2.6.35.x, as it
some time with a
kernel known to cause problems.
Could you upload to the site the
output of objdump -dr arch/x86/kvm/mmu.o too?
http://virtall.com/files/temp/mmu-objdump.txt
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" i
If you need to look at the config, it's available here:
http://www.virtall.com/files/temp/config-2.6.38.1
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordom
On 26.03.2011 10:15, Avi Kivity wrote:
> On 03/25/2011 11:32 AM, Tomasz Chmielewski wrote:
>> I got this on a 2.6.38.1 system which (I think) had some problem
>> accessing guest image on a btrfs filesystem.
>>
>>
>> general protection fault: [#1] SMP
(...)
85201a339b7635fc ]---
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18.01.2011 15:42, Marcelo Tosatti wrote:
Patch against 2.6.36 attached.
Thanks.
Do you know if this bug is present in 2.6.37?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.
On 09.01.2011 17:25, Avi Kivity wrote:
On 01/07/2011 10:43 PM, Tomasz Chmielewski wrote:
The following happened when I tried to reboot a virtual machine (host
running qemu 0.13.0, kernel 2.6.36.2).
After a while, the server hanged and was no longer reachable.
kvm: 3927: cpu0 unhandled wrmsr
890
[] ? alloc_page_vma+0x89/0x140
[] ? do_wp_page+0x209/0x930
[] ? __do_fault+0x47d/0x580
[] ? call_rcu_sched+0x15/0x20
[] ? handle_mm_fault+0x63d/0xb80
[] ? path_put+0x31/0x40
[] ? do_filp_open+0x250/0x660
[] ? do_page_fault+0x1eb/0x490
[] ? autoremove_wake_function+0x0/0x40
[] ? alloc_fd+0x129/0x150
[]
ted. TIA
Did you try;
# modprobe virtio-copypaste
?
Seriously, qemu does not make it easy (well, its GUI does not make most
things easy) and you'll need a tool which synchronizes the clipboard
between two machines (google for "qemu copy paste"?).
--
Tomasz Chmielewski
http
[ 282.364871] Oops: [#1] SMP
[ 282.364873] last sysfs file:
/sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
(...)
If it's interesting to anyone, kvm starts fine here if I start it
_before_ starting X.
If I first start X, then kvm - machines starts to Oops.
--
Tomasz Chmiel
: 00020001
[ 282.365046] ---[ end trace 7fb0c79c903996ce ]---
--
Tomasz Chmielewski
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I've never heard of any KVM specific distributions. Are you aware of
any?
Have you heard of Proxmox VE[1]?
It's built on top of Debian with virtualization in mind.
[1] http://pve.proxmox.com
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line &q
5a0
[ 923.418732] [] ? kvm_on_user_return+0x73/0x80 [kvm]
[ 923.418734] [] ? sys_ioctl+0x81/0xa0
[ 923.418737] [] ? system_call_fastpath+0x16/0x1b
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to maj
:/* obsolete */
+ r = 0;
You'll probaby have to do it manually (this disables pvmmu).
With this, some guests fail to start with kernel panic; some have soft
lockups all the time. Some don't start at all.
And generally, everything is "dead slow".
--
Tom
ation (fallocate),
instead of "traditional" dd or a sparse file.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
be syscall lm
constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr lahf_lm
bogomips: 4270.04
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
--
Tomasz Chmielewski
http://wpkg.org
--
To u
ction of that.
Sot sure how it would matter here, but probably it would.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ng KVM (support
not compiled in, and kvm didn't complain when starting).
IO and CPU speed was rather OK, so I didn't notice ;)
To sum up the thread: I guess qemu _without_ KVM will only use one CPU,
even when you assign more CPUs to the guest?
--
Tomasz Chmielewski
http://wpkg.org
--
Avi Kivity wrote:
On 10/20/2009 10:19 PM, Tomasz Chmielewski wrote:
I meant, how many qemu threads are there, and how much cpu does each
take?
There is only one qemu thread for the 4-cpu guest.
Not possible. Even a single-cpu guest has two threads.
"ps auxH" shuld show me a
Avi Kivity wrote:
On 10/20/2009 07:17 PM, Tomasz Chmielewski wrote:
Avi Kivity wrote:
On 10/20/2009 06:03 PM, Tomasz Chmielewski wrote:
On a 8 CPU host, I created a guest with 4 CPUs (-smp 4).
Unfortunately, the guest only uses one host CPU.
For example, running "cat /dev/urandom | gz
Avi Kivity wrote:
On 10/20/2009 06:03 PM, Tomasz Chmielewski wrote:
On a 8 CPU host, I created a guest with 4 CPUs (-smp 4).
Unfortunately, the guest only uses one host CPU.
For example, running "cat /dev/urandom | gzip -9 >/dev/null &" several
times on this guest causes load
-rc5 and qemu-kvm-0.11. I also tried 2.6.31.5
with qemu-kvm-0.11 with the same result.
I have another machine, running 2.6.24 kernel, where it works just fine
(running several CPU-intensive tasks on a guest result in several host
CPUs being loaded).
--
Tomasz Chmielewski
http://wpkg.org
t;) fit better for virtio block device?
Maybe. I guess that are compatibility problem with "other" operating systems.
Thanks for clarifications.
It makes sense in that case - I don't have any more questions ;)
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe fr
Luca Tettamanti wrote:
On Mon, Oct 19, 2009 at 2:14 PM, Tomasz Chmielewski wrote:
lspci implies that the virtio block device is a "SCSI storage controller",
i.e.:
00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device
However, virtio block devide does not have much
k does not
depend on any SCSI moduled like sd_mod).
Is "SCSI storage controller" a proper description for this device?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.or
ed already.
For me, it turned out that KVM I was running (coming with Proxmox VE)
had a "fairsched" patch (OpenVZ-related) which caused this broken behaviour.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
t
Avi Kivity wrote:
Tomasz Chmielewski wrote:
Maybe virtio is racy and a loaded host exposes the race.
I see it happening with virtio on 2.6.29.x guests as well.
So, what would you do if you saw it on your systems as well? ;)
Add some debug routines into virtio_* modules?
I'm no v
Avi Kivity wrote:
Tomasz Chmielewski wrote:
Avi Kivity wrote:
Tomasz Chmielewski wrote:
I still observe this "slowness" with kvm-86 after the guest is
running for some time (virtio_net and virtio_console seem to be
affected; guest restart doesn't fix it).
Anything in gu
Avi Kivity wrote:
Tomasz Chmielewski wrote:
I still observe this "slowness" with kvm-86 after the guest is running
for some time (virtio_net and virtio_console seem to be affected;
guest restart doesn't fix it).
Anything in guest dmesg?
No.
No hints in syslog, dmesg...
Rusty Russell wrote:
On Tuesday 07 April 2009 00:49:17 Tomasz Chmielewski wrote:
Tomasz Chmielewski schrieb:
As I mentioned, it was using virtio net.
Guests running with e1000 (and virtio_blk) don't have this problem.
Also, virtio_console seem to be affected by this "slowness&quo
Avi Kivity wrote:
Tomasz Chmielewski wrote:
This system is running as a kvm-85 guest.
This is a guest oops, right?
Yes, that was a guest Oops.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
SS:ESP 0068:f5879d30
---[ end trace 03bc6e65c375750f ]---
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Chmielewski schrieb:
Tomasz Chmielewski schrieb:
The keyboard is not present after I reboot the guest and usually type
before Linux is started. It does not happen always.
Observed with kvm-83, kvm-84, kvm-85 on multiple KVM hosts (different
hardware).
Anyone else seeing this? If
Tomasz Chmielewski schrieb:
The keyboard is not present after I reboot the guest and usually type
before Linux is started. It does not happen always.
Observed with kvm-83, kvm-84, kvm-85 on multiple KVM hosts (different
hardware).
Anyone else seeing this? If you're not sure, do some
ller found" /var/log/kern*)
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rusty Russell schrieb:
On Tuesday 07 April 2009 00:49:17 Tomasz Chmielewski wrote:
Tomasz Chmielewski schrieb:
As I mentioned, it was using virtio net.
Guests running with e1000 (and virtio_blk) don't have this problem.
Also, virtio_console seem to be affected by this "slown
Tomasz Chmielewski schrieb:
As I mentioned, it was using virtio net.
Guests running with e1000 (and virtio_blk) don't have this problem.
Also, virtio_console seem to be affected by this "slowness" issue.
Am I correct to think that if:
* on guest "lsmod" out
em running rhel3 and rhel4 guests using e1000/scsi devices.
As I mentioned, it was using virtio net.
Guests running with e1000 (and virtio_blk) don't have this problem.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
file to your disk and point kvm there.
It's the easiest to do; your problem is not really kvm-specific.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordom
=0,ifname=vnet1 -serial none -parallel none -usb
-vnc 127.0.0.1:1 -k en-us
And I try other disk type:
But that produces the same error.
What else can I add in order to boot from cdrom?
What does:
md5sum /dev/sr0
output?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list
?
/some/where/fedora.iso
_not_ a mounted directory!
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Gerry Reno schrieb:
Tomasz Chmielewski wrote:
Gerry Reno schrieb:
Today we upgraded one of our VM's from F9 to F10 and after the first
reboot we see the dreaded GRUB prompt. This it turns out is a known
problem with F10 installs. And the recovery is usually very simple.
You boot
VM?
What parameters do you use to start the guest?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Javier Guerra schrieb:
On Mon, Mar 30, 2009 at 10:15 AM, Tomasz Chmielewski wrote:
Still, if there is free memory on host, why not use it for cache?
because it's best used on the guest;
It is correct, but not realistic from the administrative point of view.
Let's say you have s
Felix Leimbach schrieb:
Tomasz Chmielewski wrote:
Felix Leimbach schrieb:
Out of 3 e1000 guests none has ever been hit.
Observed with kvm-83 and kvm-84 with the host running in-kernel KVM
code (linux 2.6.25.7)
Could you add a (unused) e1000 interface to your virtio guests?
As this issue
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
Double caching is indeed a bad idea. That's why you have cache=off
(though it isn't recommended with qcow2).
cache= option is about write cache, right?
Here, I'm talking about read cache.
Or, does "cache=none" d
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
What about cache/buffers sharing between the host kernel and running
processes?
If I'm not mistaken, right now, memory is "wasted" by caching the same
data by host and guest kernels.
For example, let's say we have a host
with that
size), cache for file_1 will be emptied on both guest and host as we
read file_2.
Ideal situation would be if host and guest caches could be "shared", to
a degree (and have both file_1 and file_2 in memory, doesn't matter if
it's guest or host).
--
Tomasz Chmiel
Gerrit Slomma schrieb:
Hello and good day.
I have filed a bug report via bugzilla.redhat.com with the id
With what ID?
Could you give the full URL?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
Nolan schrieb:
Tomasz Chmielewski wpkg.org> writes:
I'm trying to perform live migration by following the instructions on
http://www.linux-kvm.org/page/Migration.
Unfortunately, it doesn't work very well - guest is migrated, but looses
access to its disk.
The LSI logic scsi
lsof, kvm process uses a proper /dev/sdX device on
both hosts.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Chmielewski schrieb:
Tomasz Chmielewski schrieb:
Tomasz Chmielewski schrieb:
I'm trying to perform live migration by following the instructions on
http://www.linux-kvm.org/page/Migration.
Unfortunately, it doesn't work very well - guest is migrated, but
looses access to its
Tomasz Chmielewski schrieb:
Tomasz Chmielewski schrieb:
I'm trying to perform live migration by following the instructions on
http://www.linux-kvm.org/page/Migration.
Unfortunately, it doesn't work very well - guest is migrated, but
looses access to its disk.
On the destination
Tomasz Chmielewski schrieb:
I'm trying to perform live migration by following the instructions on
http://www.linux-kvm.org/page/Migration.
Unfortunately, it doesn't work very well - guest is migrated, but looses
access to its disk.
On the destination host, I'm starting the gue
a1
sd 0:0:0:0: rejecting I/O to offline device
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t if there is 1 distro which is
clearly better as host OS when it comes to KVM+virt-manager, I am
willing to use something else... ;-)
Did you try this one:
http://pve.proxmox.com/wiki/Main_Page
It's Debian based and have everything you need for virtualisation
already prepared.
Izik Eidus schrieb:
Tomasz Chmielewski wrote:
Evert schrieb:
Hi all,
According to the Wikipedia (
http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines
) both VirtualBox & VMware server support something called 'Live
memory allocation'.
Does KVM support this a
it the same as "ballooning" used by
KVM?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is pretty old. It used to be that we used phys_ram_base for
loading kernel/initrds which would break when using > 3.5GB of memory.
I wouldn't be surprised if that fix happened post kvm-72.
Doesn't he say that it did work for him with kvm-72, but does not with
kvm-84?
--
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
Although I think my guests don't use it, you never know.
Is it possible to disable NX for chosen guests?
-cpu qemu64,-nx
Thanks.
I updated the FAQ and migration pages to contain this information.
--
Tomasz Chmielewski
http://wpkg.org
which don't support NX
(or XD), but for 64-bit hosts back and forth migration should work
well. Migration of 32-bit guests should work between 32-bit hosts and
64-bit hosts.
Looks like that paragraph assumes that all 64-bit hosts have NX. Your
/proc/cpuinfo proves otherwise.
-
: 4266.87
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger
Gleb Natapov schrieb:
This fixes Vista boot from virtio-blk issue.
Did I miss Windows virtio block drivers? ;)
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordo
n't seem to be showing up?
Did you try other guests?
For example, try downloading a SystemRescueCd beta - it includes virtio
drivers:
http://www.sysresccd.org/Beta-x86
Boot the guest from this CD, with a drive attached as virtio.
Load virtio drivers - do you see /dev/vda?
--
Tomasz
Tomasz Chmielewski schrieb:
Note how _time_ is different (similar timings are to other unaffected
guests):
This is also pretty interesting:
# ping -c 10
PING 192.168.4.4 (192.168.4.4) 56(84) bytes of data.
64 bytes from 192.168.4.4: icmp_seq=1 ttl=64 time=1.25 ms
64 bytes from 192.168.4.4
David S. Ahern schrieb:
David S. Ahern wrote:
Rusty Russell wrote:
On Wednesday 18 March 2009 16:59:36 Avi Kivity wrote:
Tomasz Chmielewski wrote:
virtio_net virtio0: id 64 is not a head!
This means that qemu said "I've finished with buffer 64" and the guest didn't
Tomasz Chmielewski schrieb:
Tomasz Chmielewski schrieb:
Sorry, both machines run Debian Lenny and 2.6.26 kernel.
The only difference is that machine which crashes (with MTU=100) or
locks up (with MTU=1500) runs a "2.6.26-1-686" kernel and the one
which doesn't lock up run
Tomasz Chmielewski schrieb:
Sorry, both machines run Debian Lenny and 2.6.26 kernel.
The only difference is that machine which crashes (with MTU=100) or
locks up (with MTU=1500) runs a "2.6.26-1-686" kernel and the one which
doesn't lock up runs "2.6.26-1-486"
Tomasz Chmielewski schrieb:
See this screenshot:
http://www1.wpkg.org/lockup.png
Guest that locks up is running Debian Lenny with 2.6.26 kernel.
Guest that does not lock up runs Mandriva 2009.0 with 2.6.27.x kernel.
(data being transferred both side to/from each of these hosts).
Sorry
a 2009.0 with 2.6.27.x kernel.
(data being transferred both side to/from each of these hosts).
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
Tomasz Chmielewski schrieb:
Avi Kivity schrieb:
Felix Leimbach wrote:
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
Might it be that some counter overflowed? What are the packet
counts on long running guests?
Here is the current ifconfig output of a machine which suffered the
problem
Avi Kivity schrieb:
Felix Leimbach wrote:
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
Might it be that some counter overflowed? What are the packet
counts on long running guests?
Here is the current ifconfig output of a machine which suffered the
problem before:
eth0 Link
Opteron(tm) Processor 2212
stepping: 2
cpu MHz : 1994.996
cache size : 1024 KB
It's exactly the same CPU I have.
Almost. My is 5.004 MHz faster ;)
model name : Dual-Core AMD Opteron(tm) Processor 2212
stepping: 2
cpu MHz : 2000.000
--
T
you Tomasz are also running kvm-83. Maybe kvm-84 fixed
the issue already?
No, I run kvm-84.
With kvm-83 I had this issue much more frequently. With kvm-84, is seems
less frequent. Or maybe that's just what I'd like to believe ;)
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubs
again (i.e. stop kvm/qemu
process and start a new one) to make the network working properly again?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
e the packet counts on
long running guests?
I don't think so.
I just made both counters (TX, RX) of ifconfig for virtio interfaces
overflow several times and everything is still as fast as it should be.
(output of ifconfig, even on an unaffected e1000 guest, might help)
--
Tomasz Chmiel
very same
guest).
BTW, what CPU do you have?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
After a week or so, network in one guest got slow with kvm-84 and no
cpufreq.
This is virtio, right? What about e1000?
(I realize it takes a week to reproduce, but maybe you have some more
experience)
Yes, all affected had virtio
Tomasz Chmielewski schrieb:
Avi Kivity schrieb:
I'm guessing there's a problem with timers or timer interrupts.
What is the host cpu?
4 entries like this in /proc/cpuinfo:
processor : 3
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name
rrectly (at least it
does for a week now)
Does anything from this make any sense? I would really like to use
cpufreq/ondemand on the host with KVM, as my tests show it would save me
about 50 EUR on electricity bills per one of such servers yearly.
--
Tomasz Chmielewski
http://wpkg.o
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
Why do my guests show "Clocksource tsc unstable" on bootup?
Linux expects the tsc to be monotonic and to have a 1:1 correspondence
with real time, which isn't easy to achieve with virtualization.
But the clocksource is kvm-clo
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
It was kvm-clock.
I tried changing it to acpi_pm, jiffies, tsc, but it made no difference.
Actually, I don't think that I checked tsc, because when I changed to
jiffies, the time has stopped:
# echo jiffies >
/sys/devices/system/clo
to 2009-03-09 11:41:30 UTC
(1236598890)
[ 41.500623] Clocksource tsc unstable (delta = -153498948 ns)
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Tomasz Chmielewski schrieb:
Avi Kivity schrieb:
I'm guessing there's a problem with timers or timer interrupts.
What is the host cpu?
4 entries like this in /proc/cpuinfo:
processor : 3
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name
irtio card or not (I've never seen this issue on a guest which doesn't
use virtio drivers - so far at least).
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
I'm guessing there's a problem with timers or timer interrupts.
What is the host cpu?
4 entries like this in /proc/cpuinfo:
processor : 3
vendor_id : AuthenticAMD
cpu family : 15
model
ime=22.2 ms
64 bytes from 192.168.113.85: icmp_seq=6 ttl=64 time=1.60 ms
64 bytes from 192.168.113.85: icmp_seq=7 ttl=64 time=49.8 ms
64 bytes from 192.168.113.85: icmp_seq=8 ttl=64 time=23.3 ms
64 bytes from 192.168.113.85: icmp_seq=9 ttl=64 time=999 ms
64 bytes from 192.168.113.85: icmp_seq=10 ttl=6
Tomasz Chmielewski schrieb:
I upgraded ~2 days ago to kvm-84 and the same just happened for a guest
with 256 MB memory.
Note how _time_ is different (similar timings are to other unaffected
guests):
This is also pretty interesting:
# ping -c 10
PING 192.168.4.4 (192.168.4.4) 56(84) bytes
Tomasz Chmielewski schrieb:
The host is running kvm-83.
Affected guests are running 2.6.27.14 kernels and use virtio drivers.
The problem happens only _sometimes_. Out of 9 guests I have running on
this host, I saw this problem only on 3 guests. I never saw this
happening on more than one
losses
and/or ping roundtrip times ;)
"dd if=/dev/vda of=/dev/null" curing the problem also excludes the
nameserver idea.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kerne
virtio drivers.
The problem happens only _sometimes_. Out of 9 guests I have running on
this host, I saw this problem only on 3 guests. I never saw this
happening on more than one guest at a time.
All three have 512 MB memory assigned, other guests have less memory.
--
Tomasz Chmielewski
http://w
[] kthread+0x0/0x80
[] child_rip+0x0/0x12
Code: Bad RIP value.
RIP []
RSP
CR2: 88429721
---[ end trace e6b0e16fe814aeb1 ]---
note: kondemand/0[20389] exited with preempt_count 1
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm&quo
Do I have to configure something special on the quest?
On my guests, "vnc mouse pointer" moves much faster than the real one -
both when X is started, but also in console, with gpm started.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "uns
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
Currently, using mouse with vncviewer is a bit broken: "VNC mouse
pointer" moves much faster than the real mouse pointer.
As a result, it's not always easy to point&click in the right area.
Is there a workaround for that?
-u
Currently, using mouse with vncviewer is a bit broken: "VNC mouse
pointer" moves much faster than the real mouse pointer.
As a result, it's not always easy to point&click in the right area.
Is there a workaround for that?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubsc
Alpár Török schrieb:
2009/2/25 Tomasz Chmielewski :
Alpár Török schrieb:
Indeed virtio performs better than e1000.
It should work, please provide host kernel version, kvm version, virtio
net
version and
windows guest type. Also the cmdline and monitor command will help.
kernel is 2.6.25.16
igrate "exec:dd of=state.img"
reboot machine
qemu -incoming exec:dd if=state.img -other -options
Should be:
qemu -incoming "exec:dd if=state.img" -other -options
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm"
(also shipped with the distribution)
This is pretty ancient version - could you try kvm-84 to see if it
solves your problems?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kerne
Javier Guerra schrieb:
On Wed, Feb 25, 2009 at 8:20 AM, Tomasz Chmielewski wrote:
Is it possible to make snapshots when using raw devices (i.e. disk,
partition, LVM volume) as guest's disk image?
According to documentation[1] (and some tests I made) it is only possible
with qcow2 i
1 - 100 of 117 matches
Mail list logo
