windows 7 guest and acpi/apic with virt-preview

[Gianluca Cecchi]

hello,
using Fedora 14 and virt-preview.
I notice that my windows 7 guest 32bit has neither acpi nor apic enabled.
trying to enable one of them in virt-manager it gets automatically
reset and in virt-manager.log I get:
[Thu, 31 Mar 2011 00:13:54 virt-manager 17300] DEBUG
(libvirtobject:144) Redefine requested, but XML didn't change!

Is there any reason, such as not supported and automatically black
listed in any way... or a bug?
At the moment I have 3 guests: w2k3, w7 and centos 5 and this problem
is present for all of them...

I noticed this because after half an hour of inactivity my windows 7
went in black screen and no other way than powering off...
I saw that by default sleep was enabled after 30 minutes. At first I'm
disabling it, but I think that actually the problem of this freeze
could depend by acpi not enabled...
so I discovered the problem
virt-manager-0.8.6-1.fc14.noarch
libvirt-0.8.8-2.fc14.x86_64

Connecting an iso cd or changing network device type or other things
works ok. it seems only these two settings....
Gianluca

[Gianluca Cecchi]

On Thu, Mar 31, 2011 at 12:21 AM, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com&gt; wrote:
>  hello,
>  using Fedora 14 and virt-preview.
>  I notice that my windows 7 guest 32bit has neither acpi nor apic enabled.
>  trying to enable one of them in virt-manager it gets automatically
>  reset and in virt-manager.log I get:
>  [Thu, 31 Mar 2011 00:13:54 virt-manager 17300] DEBUG
>  (libvirtobject:144) Redefine requested, but XML didn't change! 

BTW: even if I don't see the check box selected in virt-manager window
and I cannot change it, my xml does contain this:
  <features>
    <acpi/>
    <pae/>
  </features>

but when I run the guest, the command produced is:
/usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 1536 -smp
1,sockets=1,cores=1,threads=1 -name w7test -uuid
de5dbc9e-14f0-f56b-8e8a-4f4986d61ad8 -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/w7test.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
-boot order=dc,menu=off -drive if=none,id=drive-fdc0-0-0,format=raw
-global isa-fdc.driveA=drive-fdc0-0-0 -drive
if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
file=/var/lib/libvirt/images/w7test.img,if=none,id=drive-virtio-disk0,boot=on,format=raw
-device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0
-netdev tap,fd=24,id=hostnet0 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d3:8e:29,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -usb -device
usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing
-vga qxl -device AC97,id=sound0,bus=pci.0,addr=0x4 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

[Cole Robinson]

On 03/30/2011 06:21 PM, Gianluca Cecchi wrote:
>  hello,
>  using Fedora 14 and virt-preview.
>  I notice that my windows 7 guest 32bit has neither acpi nor apic enabled.
>  trying to enable one of them in virt-manager it gets automatically
>  reset and in virt-manager.log I get:
>  [Thu, 31 Mar 2011 00:13:54 virt-manager 17300] DEBUG
>  (libvirtobject:144) Redefine requested, but XML didn't change!
>   
That's a virt-manager bug, fixed in the version in f15/rawhide,
virt-manager-0.8.7-1. virt-preview will likely get that version soon as
well.

- Cole

>  Is there any reason, such as not supported and automatically black
>  listed in any way... or a bug?
>  At the moment I have 3 guests: w2k3, w7 and centos 5 and this problem
>  is present for all of them...
>  
>  I noticed this because after half an hour of inactivity my windows 7
>  went in black screen and no other way than powering off...
>  I saw that by default sleep was enabled after 30 minutes. At first I'm
>  disabling it, but I think that actually the problem of this freeze
>  could depend by acpi not enabled...
>  so I discovered the problem
>  virt-manager-0.8.6-1.fc14.noarch
>  libvirt-0.8.8-2.fc14.x86_64
>  
>  Connecting an iso cd or changing network device type or other things
>  works ok. it seems only these two settings....
>  Gianluca
>  _______________________________________________
>  virt mailing list
>  virt(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/virt

[Gianluca Cecchi]

On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson <crobinso(a)redhat.com&gt; wrote:
>  That's a virt-manager bug, fixed in the version in f15/rawhide,
>  virt-manager-0.8.7-1. virt-preview will likely get that version soon as
>  well.
>
>  - Cole 
Ok, thanks.
Is it a bug of only virt-manager setting or also involving qemu-kvm
command line?
I try to explain better:
- viewing the xml definition, I can see that my vm indeed has the acpi
setting in features section
- does this mean that win7 starts with acpi enabled from qemu-kvm
point of view?

running with --help I can see
QEMU emulator version 0.14.0 (qemu-kvm-0.14.0), Copyright (c)
2003-2008 Fabrice Bellard

and
i386 target only:
-win2k-hack     use it when installing Windows 2000 to avoid a disk full bug
-no-fd-bootchk  disable boot signature checking for floppy disks
-no-acpi        disable ACPI

Does this mean that acpi is set by default in qemu-kvm and when in an
updated virt-manager I uncheck acpi setting this will involve to run
the qemu-kvm process with "-no-acpi" ?

what is it exactly intended with "i386 target"?
In recent virt-manager, even if I create a 32bit win7 guest, by
default the hypervisor settings are:
Hypervisor: kvm
Architecture: x86_64
Emulator: /usr/bin/qemu-kvm

I have to force i686 during guest creation....
Thanks,
Gianluca

BTW: I notice that while I'm creating a test vm to experiment, in
version  virt-manager-0.8.6-1.fc14.noarch, I'm unable to delete the
newly created guest (the option is greyed out). i have to run
virsh undefine testvm
Instead, pre-existing guests have the option to delete...
Is this already tracked or do I have to open a bug?

[Emre Erenoglu]

On Thu, Mar 31, 2011 at 5:50 PM, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com&gt;wrote:

>  On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson
> <crobinso(a)redhat.com&gt;
>  wrote:
>  > That's a virt-manager bug, fixed in the version in f15/rawhide,
>  > virt-manager-0.8.7-1. virt-preview will likely get that version soon as
>  > well.
>  >
>  > - Cole
>  Ok, thanks.
>  Is it a bug of only virt-manager setting or also involving qemu-kvm
>  command line?
>  I try to explain better:
>  - viewing the xml definition, I can see that my vm indeed has the acpi
>  setting in features section
>  - does this mean that win7 starts with acpi enabled from qemu-kvm
>  point of view?
>
>  running with --help I can see
>  QEMU emulator version 0.14.0 (qemu-kvm-0.14.0), Copyright (c)
>  2003-2008 Fabrice Bellard
>
>  and
>  i386 target only:
>  -win2k-hack     use it when installing Windows 2000 to avoid a disk full
>  bug
>  -no-fd-bootchk  disable boot signature checking for floppy disks
>  -no-acpi        disable ACPI
>
>  Does this mean that acpi is set by default in qemu-kvm and when in an
>  updated virt-manager I uncheck acpi setting this will involve to run
>  the qemu-kvm process with "-no-acpi" ?
>
>  what is it exactly intended with "i386 target"?
>  In recent virt-manager, even if I create a 32bit win7 guest, by
>  default the hypervisor settings are:
>  Hypervisor: kvm
>  Architecture: x86_64
>  Emulator: /usr/bin/qemu-kvm
>
>  I have to force i686 during guest creation....
>  Thanks,
>  Gianluca
>
>  BTW: I notice that while I'm creating a test vm to experiment, in
>  version  virt-manager-0.8.6-1.fc14.noarch, I'm unable to delete the
>  newly created guest (the option is greyed out). i have to run
>  virsh undefine testvm
>  Instead, pre-existing guests have the option to delete...
>  Is this already tracked or do I have to open a bug?
>  
Gianluca, what does the device manager of the virtual system show as your
computer? Is it ACPI Multiprocessor PC?  Can you confirm if qemu enabled the
ACPI support by default.

-- 
Emre

[Gianluca Cecchi]

On Thu, Mar 31, 2011 at 4:40 PM, Emre Erenoglu <erenoglu(a)gmail.com&gt; wrote:
>  Gianluca, what does the device manager of the virtual system show as your
>  computer? Is it ACPI Multiprocessor PC?  Can you confirm if qemu enabled the
>  ACPI support by default.
>  --
>  Emre
>  
My guest is configured with one cpu and in device manager --> computer
it appears as:
ACPI x86-based PC

while in windows/system32/ the current hal.dll file is referred in properties as
details --> original filename: halmacpi.dll

I can see that in windows 7 there are only
halacpi.dll
halmacpi.dll

I don't know if this answers your question; let me know in case...
BTW: yesterday I updated to SP1

Gianluca

[Emre Erenoglu]

On Thu, Mar 31, 2011 at 7:11 PM, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com&gt;wrote:

>  On Thu, Mar 31, 2011 at 4:40 PM, Emre Erenoglu
> <erenoglu(a)gmail.com&gt; wrote:
>  >
>  > Gianluca, what does the device manager of the virtual system show as your
>  > computer? Is it ACPI Multiprocessor PC?  Can you confirm if qemu enabled
>  the
>  > ACPI support by default.
>  > --
>  > Emre
>  >
>
>  My guest is configured with one cpu and in device manager --> computer
>  it appears as:
>  ACPI x86-based PC
>
>  
If it appears that it's ACPI PC, then you're done, ACPI is enabled, no
need
to worry.


>  while in windows/system32/ the current hal.dll file is referred in
>  properties as
>  details --> original filename: halmacpi.dll
>
>  I can see that in windows 7 there are only
>  halacpi.dll
>  halmacpi.dll
>
>  
I guess one is for single processor PC's and the other is for
multi-processor PC's. You don't need to worry about them.

I don't know if this answers your question; let me know in case...
>  BTW: yesterday I updated to SP1
>
>  
Best regards,
-- 
Emre

[Gianluca Cecchi]

On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson <crobinso(a)redhat.com&gt; wrote:
>  That's a virt-manager bug, fixed in the version in f15/rawhide,
>  virt-manager-0.8.7-1. virt-preview will likely get that version soon as
>  well. 
virt-manager landed but python-virtinst dependency not yet.
When available I will try it and the nice features I can see inside
its changelog....

--> Running transaction check
---> Package virt-manager.noarch 0:0.8.7-2.fc14 set to be updated
--> Processing Dependency: python-virtinst >= 0.500.6 for package:
virt-manager-0.8.7-2.fc14.noarch
--> Finished Dependency Resolution
Error: Package: virt-manager-0.8.7-2.fc14.noarch (fedora-virt-preview)
           Requires: python-virtinst >= 0.500.6
           Installed: python-virtinst-0.500.5-1.fc14.noarch
(@fedora-virt-preview)
               python-virtinst = 0.500.5-1.fc14
           Available: python-virtinst-0.500.4-1.fc14.noarch (fedora)
               python-virtinst = 0.500.4-1.fc14

Gianluca

[Cole Robinson]

On 04/01/2011 03:08 AM, Gianluca Cecchi wrote:
>  On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson
> <crobinso(a)redhat.com&gt; wrote:
> >
> > That's a virt-manager bug, fixed in the version in f15/rawhide,
> > virt-manager-0.8.7-1. virt-preview will likely get that version soon as
> > well.
>  
>  virt-manager landed but python-virtinst dependency not yet.
>  When available I will try it and the nice features I can see inside
>  its changelog....
>  
>  --> Running transaction check
>  ---> Package virt-manager.noarch 0:0.8.7-2.fc14 set to be updated
>  --> Processing Dependency: python-virtinst >= 0.500.6 for package:
>  virt-manager-0.8.7-2.fc14.noarch
>  --> Finished Dependency Resolution
>  Error: Package: virt-manager-0.8.7-2.fc14.noarch (fedora-virt-preview)
>             Requires: python-virtinst >= 0.500.6
>             Installed: python-virtinst-0.500.5-1.fc14.noarch
>  (@fedora-virt-preview)
>                 python-virtinst = 0.500.5-1.fc14
>             Available: python-virtinst-0.500.4-1.fc14.noarch (fedora)
>                 python-virtinst = 0.500.4-1.fc14
>  
>  Gianluca 
virtinst will also be in updates-testing shortly (might even be right now), so
you can --enablerepo=updates-testing and it might work.

- Cole

[Konstantin Svist]

On 04/01/2011 06:40 AM, Cole Robinson wrote:
>  On 04/01/2011 03:08 AM, Gianluca Cecchi wrote:
> > On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson<crobinso(a)redhat.com>  wrote:
> >> That's a virt-manager bug, fixed in the version in f15/rawhide,
> >> virt-manager-0.8.7-1. virt-preview will likely get that version soon as
> >> well.
> > virt-manager landed but python-virtinst dependency not yet.
> > When available I will try it and the nice features I can see inside
> > its changelog....
> >
> > -->  Running transaction check
> > --->  Package virt-manager.noarch 0:0.8.7-2.fc14 set to be updated
> > -->  Processing Dependency: python-virtinst>= 0.500.6 for package:
> > virt-manager-0.8.7-2.fc14.noarch
> > -->  Finished Dependency Resolution
> > Error: Package: virt-manager-0.8.7-2.fc14.noarch (fedora-virt-preview)
> >             Requires: python-virtinst>= 0.500.6
> >             Installed: python-virtinst-0.500.5-1.fc14.noarch
> > (@fedora-virt-preview)
> >                 python-virtinst = 0.500.5-1.fc14
> >             Available: python-virtinst-0.500.4-1.fc14.noarch (fedora)
> >                 python-virtinst = 0.500.4-1.fc14
> >
> > Gianluca
>  virtinst will also be in updates-testing shortly (might even be right now), so
>  you can --enablerepo=updates-testing and it might work.
>
>  - Cole
>  _______________________________________________
>  virt mailing list
>  virt(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/virt
>  
I found one here 
http://www.linux-kvm.com/content/virt-manager-087-released-new-ui-features

[Konstantin Svist]

On 04/01/2011 09:38 AM, Konstantin Svist wrote:
>  I found one here 
>  http://www.linux-kvm.com/content/virt-manager-087-released-new-ui-features 
Also, appears fixed in virt-preview now