pradeep | 1 Oct 05:30 2011
Picon

ethtool


Hello Amos, Lmr

Couple of networking tests like ethtool, file_transfer..etc are not
doing cleaning properly.  Huge files are not getting deleted after the
test. So guest running out of space for next tests. 

--Pradeep

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Nikola Ciprich | 1 Oct 09:36 2011
Picon

Re: Re: tcpdump locks up kvm host for a while.

well, give it a try ;)
I still haven't fully resolved this, but I'm sure it has to do something with
the timesource - with kvm-clock, it got much worse...
n.

> [    1.911056] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode
> 
> Will hpet do any better?
> 
> -Robin
> 

--

-- 
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.:   +420 596 603 142
fax:    +420 596 621 273
mobil:  +420 777 093 799

www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: servis <at> linuxbox.cz
-------------------------------------
Onkar N Mahajan | 1 Oct 14:16 2011
Picon

Guest freezes "Refined TSC clocksource calibration ..."


Compiled 3.1.0-rc3+ from source (see attached config file) and updated 
the host(fc14) kernel ;
So host is now running 3.1.0-rc3+

Now I also want to try to boot FC14 guest with this updated kernel , 
like this -

./qemu-kvm-virtfs -drive file=/home/onkar/bin/v9fs-guest.img,if=virtio 
-m 1024 -smp 4 -net nic,macaddr=54:52:00:46:26:84,model=virtio -net 
tap,script=./qemu-ifup,ifname=vnet1 --enable-kvm -vnc :10 -kernel 
/boot/vmlinuz-3.1.0-rc3p -initrd /boot/initrd-3.1.0-rc3p.img -append 
'root=UUID=97e4bdfa-c88b-4e1f-8609-10f76d6a35fa' -monitor stdio

-append 'root=UUID=97e4bdfa-c88b-4e1f-8609-10f76d6a35fa'
has come from guest grub/menu.lst file generated during installation , 
which looks like this :

=====================================================================
title Fedora (2.6.35.6-45.fc14.x86_64)
     root (hd0,0)
     kernel /boot/vmlinuz-2.6.35.6-45.fc14.x86_64 ro 
root=UUID=97e4bdfa-c88b-4e1f-8609-10f76d6a35fa rd_NO_LUKS rd_NO_LVM 
rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us 
rhgb quiet
     initrd /boot/initramfs-2.6.35.6-45.fc14.x86_64.img
=====================================================================

But, the guest freezes with error (see screen shot attached) when tried 
to run
(Continue reading)

Robin Lee Powell | 2 Oct 02:45 2011

Re: Re: [kvm] Re: tcpdump locks up kvm host for a while.

I'm afraid clocksource=hpet didn't help much; after about 24 hours
up, tcpdump hung the machine for for about 10 seconds.  That may or
may not be better than usual; I haven't been timing things
precisely.  My suspicion is that it's slightly better, but it's
still not great.

Also:

rlpowell <at> vrici> dmesg | grep -i clock
[    0.000000] Command line: ro root=/dev/vda2 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=ttyS0,115200 clocksource=hpet
[    0.000000] kvm-clock: Using msrs 12 and 11
[    0.000000] kvm-clock: cpu 0, msr 0:1b567c1, boot clock
[    0.000000] kvm-clock: cpu 0, msr 0:5fc137c1, primary cpu clock
[    0.000000] Kernel command line: ro root=/dev/vda2 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM
LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=ttyS0,115200 clocksource=hpet
[    0.000000] hpet clockevent registered
[    0.260136] Switching to clocksource hpet
[    1.009393] rtc_cmos 00:01: setting system clock to 2011-10-01 07:49:50 UTC (1317455390)
[    1.821905] Refined TSC clocksource calibration: 2394.030 MHz.
[60555.473797] Clocksource tsc unstable (delta = -42950328292 ns)

(note the last line)

-Robin

On Sat, Oct 01, 2011 at 09:36:43AM +0200, Nikola Ciprich wrote:
> well, give it a try ;)
> I still haven't fully resolved this, but I'm sure it has to do something with
> the timesource - with kvm-clock, it got much worse...
(Continue reading)

Mulyadi Santosa | 2 Oct 09:24 2011
Picon

Re: [Qemu-devel] Guest freezes "Refined TSC clocksource calibration ..."

Hi..... :)

On Sat, Oct 1, 2011 at 19:16, Onkar N Mahajan <kernzap <at> gmail.com> wrote:
>
> Compiled 3.1.0-rc3+ from source (see attached config file) and updated the
> host(fc14) kernel ;
> So host is now running 3.1.0-rc3+
>
> Now I also want to try to boot FC14 guest with this updated kernel , like
> this -
>
> ./qemu-kvm-virtfs -drive file=/home/onkar/bin/v9fs-guest.img,if=virtio -m
> 1024 -smp 4 -net nic,macaddr=54:52:00:46:26:84,model=virtio -net
> tap,script=./qemu-ifup,ifname=vnet1 --enable-kvm -vnc :10 -kernel
> /boot/vmlinuz-3.1.0-rc3p -initrd /boot/initrd-3.1.0-rc3p.img -append
> 'root=UUID=97e4bdfa-c88b-4e1f-8609-10f76d6a35fa' -monitor stdio

Quite simple things you can try first:
- what if you use device name like /dev/sda1 instead? does that work?

- are you sure you have included the suitable filesystem module for
the root partition in the initrd or the main kernel image?

--

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
(Continue reading)

Dor Laor | 2 Oct 10:24 2011
Picon

Re: Guest freezes "Refined TSC clocksource calibration ..."

On 10/02/2011 09:24 AM, Mulyadi Santosa wrote:
> Hi..... :)
>
> On Sat, Oct 1, 2011 at 19:16, Onkar N Mahajan<kernzap <at> gmail.com>  wrote:
>>
>> Compiled 3.1.0-rc3+ from source (see attached config file) and updated the
>> host(fc14) kernel ;
>> So host is now running 3.1.0-rc3+
>>
>> Now I also want to try to boot FC14 guest with this updated kernel , like
>> this -
>>
>> ./qemu-kvm-virtfs -drive file=/home/onkar/bin/v9fs-guest.img,if=virtio -m
>> 1024 -smp 4 -net nic,macaddr=54:52:00:46:26:84,model=virtio -net
>> tap,script=./qemu-ifup,ifname=vnet1 --enable-kvm -vnc :10 -kernel
>> /boot/vmlinuz-3.1.0-rc3p -initrd /boot/initrd-3.1.0-rc3p.img -append
>> 'root=UUID=97e4bdfa-c88b-4e1f-8609-10f76d6a35fa' -monitor stdio
>
> Quite simple things you can try first:
> - what if you use device name like /dev/sda1 instead? does that work?
>
> - are you sure you have included the suitable filesystem module for
> the root partition in the initrd or the main kernel image?
>

It indeed looks that this is the problem because your log shows that no 
root device was found after the successful tsc calibration stage.

Avi Kivity | 2 Oct 10:56 2011
Picon

Re: Re: [kvm] Re: [kvm] Re: [kvm] Re: Questions about duplicate memory work

On 09/29/2011 09:46 PM, Robin Lee Powell wrote:
> On Thu, Sep 29, 2011 at 02:22:43PM -0300, Marcelo Tosatti wrote:
> >  On Wed, Sep 28, 2011 at 05:14:47PM -0700, Robin Lee Powell wrote:
> >  >  >  >  Please post the contents of /proc/meminfo and /proc/zoneinfo
> >  >  >  >  when this is happening.
> >  >  >
> >  >  >  I just noticed that the amount of RAM the VMs had in VIRT
> >  >  >  added up to considerably more than the host's actual RAM;
> >  >  >  hard_limit is now on.  So I may not be able to replicate this.
> >  >  >  :)
> >  >
> >  >  Or not; even with hard_limit the VIRT value goes to hundreds of
> >  >  MiB more than the limit.  Is that expected?
> >
> >  Yes, VIRT field refers to total memory mapped by the process, not
> >  paged-in memory, which is indicated by the RES field.
>
> Yes, I'm aware of that; that isn't relevant to my question.
>
> I would expect the *total* memory requested by a VM to never go over
> the hard_limit value set in the XML file.  I mean, isn't that what
> the hard_limit *means*?  If not, what does it mean?
>
>

VIRT memory includes both guest memory, and memory reserved (usually not 
used) by qemu.  Don't read too much into it.

--

-- 
error compiling committee.c: too many arguments to function
(Continue reading)

Avi Kivity | 2 Oct 11:05 2011
Picon

Re: [PATCH] KVM: x86: Use do_div for tsc deadline calculation

On 09/30/2011 02:50 PM, Jan Kiszka wrote:
> Required on i386 hosts.
>
>

Thanks, applied.

--

-- 
error compiling committee.c: too many arguments to function

Michael S. Tsirkin | 2 Oct 11:09 2011
Picon

Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X

On Mon, Sep 19, 2011 at 05:19:49PM +0930, Rusty Russell wrote:
> On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst <at> redhat.com> wrote:
> > On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst <at> redhat.com> wrote:
> > > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > > with capability linked list?
> > > > 
> > > > There are any number of ways to lay out the structure.  I went for what
> > > > seemed a simplest one.  For MSI-X the train has left the station.  We
> > > > can probably still tweak where the high 32 bit features
> > > > for 64 bit features are.  No idea if it's worth it.
> > > 
> > > Sorry, this has been in the back of my mind.  I think it's a good idea;
> > > can we use the capability linked list for pre-device specific stuff from
> > > now on?
> > > 
> > > Thanks,
> > > Rusty.
> > 
> > Do we even want capability bits then?
> > We can give each capability an ack flag ...
> 
> We could have, and if I'd known PCI when I designed virtio I might have.
> 
> But it's not easy now to map structure offsets to that scheme, and we
> can't really force such a change on the non-PCI users.  So I'd say we
> should only do it for the non-device-specific options.  ie. we'll still
> have the MSI-X case move the device-specific config, but we'll use a
> linked list from now on, eg. for the next 32 features bits...
(Continue reading)

Michael S. Tsirkin | 2 Oct 11:11 2011
Picon

Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X

On Wed, Sep 28, 2011 at 09:30:51PM +0300, Sasha Levin wrote:
> On Mon, 2011-09-19 at 17:19 +0930, Rusty Russell wrote:
> > On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst <at> redhat.com> wrote:
> > > On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > > > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst <at> redhat.com> wrote:
> > > > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > > > with capability linked list?
> > > > > 
> > > > > There are any number of ways to lay out the structure.  I went for what
> > > > > seemed a simplest one.  For MSI-X the train has left the station.  We
> > > > > can probably still tweak where the high 32 bit features
> > > > > for 64 bit features are.  No idea if it's worth it.
> > > > 
> > > > Sorry, this has been in the back of my mind.  I think it's a good idea;
> > > > can we use the capability linked list for pre-device specific stuff from
> > > > now on?
> > > > 
> > > > Thanks,
> > > > Rusty.
> > > 
> > > Do we even want capability bits then?
> > > We can give each capability an ack flag ...
> > 
> > We could have, and if I'd known PCI when I designed virtio I might have.
> > 
> > But it's not easy now to map structure offsets to that scheme, and we
> > can't really force such a change on the non-PCI users.  So I'd say we
> > should only do it for the non-device-specific options.  ie. we'll still
> > have the MSI-X case move the device-specific config, but we'll use a
(Continue reading)


Gmane