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
On Thu, Mar 31, 2011 at 12:21 AM, Gianluca Cecchi gianluca.cecchi@gmail.com 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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/virt
On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson crobinso@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.
- 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?
On Thu, Mar 31, 2011 at 5:50 PM, Gianluca Cecchi gianluca.cecchi@gmail.comwrote:
On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson crobinso@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.
- 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.
On Thu, Mar 31, 2011 at 4:40 PM, Emre Erenoglu erenoglu@gmail.com 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
On Thu, Mar 31, 2011 at 7:11 PM, Gianluca Cecchi gianluca.cecchi@gmail.comwrote:
On Thu, Mar 31, 2011 at 4:40 PM, Emre Erenoglu erenoglu@gmail.com 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,
On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson crobinso@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
On 04/01/2011 03:08 AM, Gianluca Cecchi wrote:
On Thu, Mar 31, 2011 at 3:25 PM, Cole Robinson crobinso@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
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 Robinsoncrobinso@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@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
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