kvm 84 update

kvm 84 update

[Armindo Silva]

Hi,

I am using ubuntu hardy 8.04.2 on my servers, and just updated to kvm
84 (from the ppa repo).
There are a few glitches/problems with this version (at least using
win2k3 server as guest). The problems with the vnc window only
disappear when i create a new guest, with the old ones the mouse is
still out of sync.
Other problem is that all my guest lost their default network config -
they all had static ips if i configure them again with the same
settings windows warn me about that address being in use by a hidden
network device (if i ignore that message it works - at least as far i
can tell). Also now, all of them (including fresh VMs) have a new PCI
Device to which i cannot find drivers - i am not using virtio so
everything thing should be working, right?

Any ideas/pointers?

Cheers

Armindo


PS: I don't know if any of these was already answered, but i am not
able to find it, so if you can point me in the right direction.

--



--
"The only way of discovering the limits of the possible is to venture
a little way past them into the impossible."
Sir Arthur C. Clarke

Re: kvm 84 update

[Charles Duffy]

Armindo Silva wrote:
> There are a few glitches/problems with this version (at least using
> win2k3 server as guest). The problems with the vnc window only
> disappear when i create a new guest, with the old ones the mouse is
> still out of sync.

What problems with the VNC window?

> Other problem is that all my guest lost their default network config -
> they all had static ips if i configure them again with the same
> settings windows warn me about that address being in use by a hidden
> network device (if i ignore that message it works - at least as far i
> can tell).

Perhaps you aren't specifying MAC address on the command line, so they 
get a new one every boot?

> Also now, all of them (including fresh VMs) have a new PCI
> Device to which i cannot find drivers - i am not using virtio so
> everything thing should be working, right?

That's the virtio console. It's on by default, and completely harmless; 
ignore it.

Re: kvm 84 update

[Armindo Silva]

On Tue, Apr 14, 2009 at 12:40 AM, Charles Duffy
<Charles_Duffy@messageone.com> wrote:
> Armindo Silva wrote:
>>
>> There are a few glitches/problems with this version (at least using
>> win2k3 server as guest). The problems with the vnc window only
>> disappear when i create a new guest, with the old ones the mouse is
>> still out of sync.
>
> What problems with the VNC window?

The mouse is always out of sync.
>
>> Other problem is that all my guest lost their default network config -
>> they all had static ips if i configure them again with the same
>> settings windows warn me about that address being in use by a hidden
>> network device (if i ignore that message it works - at least as far i
>> can tell).
>
> Perhaps you aren't specifying MAC address on the command line, so they get a
> new one every boot?

I am launching the machines like this (i am using libvirt):
 /usr/bin/kvm -M pc -m 2000 -smp 3 -monitor pty -localtime -boot c
-drive file=/mnt/vm/db/newroot.qcow2,if=ide,index=0,boot=on -drive
file=/mnt/vm/db/databases.qcow2,if=ide,index=1 -drive
file=/mnt/backup/isos/os/w2k3_server_sp2.iso,if=ide,media=cdrom,index=2
-net nic,macaddr=00:16:3e:67:a9:4a,vlan=0 -net tap,fd=7,script=,vlan=0
-usb -vnc 192.168.0.250:10008

There is a mac in there.

>
>> Also now, all of them (including fresh VMs) have a new PCI
>> Device to which i cannot find drivers - i am not using virtio so
>> everything thing should be working, right?
>
> That's the virtio console. It's on by default, and completely harmless;
> ignore it.

Even with virtio disabled?


Thanks for your reply.
Armindo


-- 



--
"The only way of discovering the limits of the possible is to venture
a little way past them into the impossible."
Sir Arthur C. Clarke

Re: kvm 84 update

[Charles Duffy]

Armindo Silva wrote:
> On Tue, Apr 14, 2009 at 12:40 AM, Charles Duffy
> <Charles_Duffy@messageone.com> wrote:
>> What problems with the VNC window?
> The mouse is always out of sync.

That's what -usbdevice tablet is for.

>>> Other problem is that all my guest lost their default network config -
>>> they all had static ips if i configure them again with the same
>>> settings windows warn me about that address being in use by a hidden
>>> network device (if i ignore that message it works - at least as far i
>>> can tell).
>> Perhaps you aren't specifying MAC address on the command line, so they get a
>> new one every boot?
> 
> I am launching the machines like this (i am using libvirt):
>  /usr/bin/kvm -M pc -m 2000 -smp 3 -monitor pty -localtime -boot c
> -drive file=/mnt/vm/db/newroot.qcow2,if=ide,index=0,boot=on -drive
> file=/mnt/vm/db/databases.qcow2,if=ide,index=1 -drive
> file=/mnt/backup/isos/os/w2k3_server_sp2.iso,if=ide,media=cdrom,index=2
> -net nic,macaddr=00:16:3e:67:a9:4a,vlan=0 -net tap,fd=7,script=,vlan=0
> -usb -vnc 192.168.0.250:10008

Yup, looks fine.

I don't know Windows well enough to know under which circumstances it 
behaves as you describe, and would suggest diagnosing things starting 
from that direction.

>>> Also now, all of them (including fresh VMs) have a new PCI
>>> Device to which i cannot find drivers - i am not using virtio so
>>> everything thing should be working, right?
>> That's the virtio console. It's on by default, and completely harmless;
>> ignore it.
> 
> Even with virtio disabled?

There isn't really a concept of globally disabling virtio. Even if you 
haven't enabled the virtio network or block devices, the virtio console 
is still enabled by default in kvm-84.

Re: kvm 84 update

[Brent A Nelson]

I, too, am trying out the KVM 84 build for Hardy.  I didn't have any 
problems with networking (I'm using a bridge interface), except I had to 
specify script=/etc/kvm/kvm-ifup, unlike with KVM 62.  Without 
specifying any script=, kvm looks for /etc/kvm-ifup, which does not exist. 
Perhaps this is just a glitch with the way the Ubuntu folks built the 
package.

However, live migration simply doesn't work right.  When it completes, the 
migrated guest always immediately crashes in some fashion (I've had an 
oops, a panic, and a reboot).  I can send the original a "cont" command, 
however, and it will resume as if nothing had happened.

If I first stop the guest, then migration works great, and it's fast 
enough to hardly notice the brief unresponsiveness.  However, there's a 
nuisance here, too.  The migrated VM uses the full amount of memory 
allocated to it, even though the original may have been using only a small 
fraction.  I tried issuing a balloon command to shrink it; the guest VM did 
see the smaller memory size, but the kvm process itself did not change 
memory consumption.  When I used the balloon command to set it back to the 
original, full size, the guest VM saw its memory shrink down to nothing 
until all processes had been killed by the out-of-memory killer.

"info balloon" tells me:
Using KVM without synchronous MMU, ballooning disabled

So, I assume I don't have everything I need to try ballooning properly to 
see if I can reduce the excess memory consumed by the migrated guest VM.

Thanks,

Brent Nelson
Director of Computing
Dept. of Physics
University of Florida

Re: kvm 84 update

[Brent A Nelson]

Well, I just tried disabling smp on my guest, and live migration worked 
fine.  I see that there are already SMP complaints with live migration in 
KVM:84 in the bug database, so I guess this is just another, "Me, too."

Is this expected to be fixed in the soon-to-be-released KVM:85?

Thanks,

Brent

PS The migrated guest still uses its full memory allocation, even though 
the original was nowhere close.
PPS The perceptible delay in an open ssh session was similar between the 
live and offline migrations.  I guess this is beyond KVMs control, though, 
and more dependent on how quickly gratuitous arp is being handled, or 
something else to do with the transition of the IP/MAC between nodes. 
It's just a handful of seconds, either way.

On Fri, 17 Apr 2009, Brent A Nelson wrote:

> I, too, am trying out the KVM 84 build for Hardy.  I didn't have any problems 
> with networking (I'm using a bridge interface), except I had to specify 
> script=/etc/kvm/kvm-ifup, unlike with KVM 62.  Without specifying any 
> script=, kvm looks for /etc/kvm-ifup, which does not exist. Perhaps this is 
> just a glitch with the way the Ubuntu folks built the package.
>
> However, live migration simply doesn't work right.  When it completes, the 
> migrated guest always immediately crashes in some fashion (I've had an oops, 
> a panic, and a reboot).  I can send the original a "cont" command, however, 
> and it will resume as if nothing had happened.
>
> If I first stop the guest, then migration works great, and it's fast enough 
> to hardly notice the brief unresponsiveness.  However, there's a nuisance 
> here, too.  The migrated VM uses the full amount of memory allocated to it, 
> even though the original may have been using only a small fraction.  I tried 
> issuing a balloon command to shrink it; the guest VM did see the smaller 
> memory size, but the kvm process itself did not change memory consumption. 
> When I used the balloon command to set it back to the original, full size, 
> the guest VM saw its memory shrink down to nothing until all processes had 
> been killed by the out-of-memory killer.
>
> "info balloon" tells me:
> Using KVM without synchronous MMU, ballooning disabled
>
> So, I assume I don't have everything I need to try ballooning properly to see 
> if I can reduce the excess memory consumed by the migrated guest VM.
>
> Thanks,
>
> Brent Nelson
> Director of Computing
> Dept. of Physics
> University of Florida
>

Re: kvm 84 update

[Avi Kivity]

Brent A Nelson wrote:
> Well, I just tried disabling smp on my guest, and live migration 
> worked fine.  I see that there are already SMP complaints with live 
> migration in KVM:84 in the bug database, so I guess this is just 
> another, "Me, too."
>
> Is this expected to be fixed in the soon-to-be-released KVM:85?

There's a fix in kvm-86.

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