Re: [Fedora-xen] [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)
by Pasi Kärkkäinen
On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris Derzhavets wrote:
> Seems to related
>
> https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
>
Thanks, that seems to be the same bug.
Is the bugfix patch from xen-unstable going to backported to xen-4.1-testing.hg ?
(4.1 backported patch available on ubuntu's launchpad above..)
-- Pasi
> Boris.
>
> --- On Mon, 10/31/11, Pasi Kärkkäinen <pasik(a)iki.fi> wrote:
>
> From: Pasi Kärkkäinen <pasik(a)iki.fi>
> Subject: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0
> 8139cp transmit queue timed out)
> To: xen-devel(a)lists.xensource.com
> Date: Monday, October 31, 2011, 2:49 PM
>
> Hello,
>
> While testing Xen 4.1.2 and HVM guests I noticed the following problem
> with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the VM):
>
> The errors (call trace) happens pretty much immediately when there's
> some network traffic going on..
>
> Simple "yum update" in the VM triggers the problem..
>
> [ 0.000000] Linux version 3.1.0-5.fc16.x86_64
> ([1]mockbuild(a)x86-10.phx2.fedoraproject.org) (gcc version 4.6.1 20111003
> (Red Hat 4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC 2011
> [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
> root=/dev/mapper/vg_f16test64hvm-lv_root ro
> rd.lvm.lv=vg_f16test64hvm/lv_root rd.dm=0 SYSFONT=latarcyrheb-sun16 rhgb
> KEYTABLE=fi rd.md=0 rd.luks=0 rd.lvm.lv=vg_f16test64hvm/lv_swap
> LANG=en_US.UTF-8 console=ttyS0,38400 console=tty0
> <snip>
>
> [ 28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps, full-duplex,
> lpa 0x05E1
> [ 149.712071] ------------[ cut here ]------------
> [ 149.717216] WARNING: at net/sched/sch_generic.c:255
> dev_watchdog+0xf0/0x150()
> [ 149.724709] Hardware name: HVM domU
> [ 149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0 timed
> out
> [ 149.735537] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
> nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state
> ip6_tables nf_conntrack 81
> 39too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core joydev
> [last unloaded: scsi_wait_scan]
> [ 149.768028] Pid: 0, comm: swapper Not tainted 3.1.0-5.fc16.x86_64 #1
> [ 149.774639] Call Trace:
> [ 149.777765] <IRQ> [<ffffffff81057a56>]
> warn_slowpath_common+0x83/0x9b
> [ 149.784024] [<ffffffff81057b11>] warn_slowpath_fmt+0x46/0x48
> [ 149.790141] [<ffffffff813ef49d>] ? netif_tx_lock+0x4a/0x7c
> [ 149.799007] [<ffffffff813ef613>] dev_watchdog+0xf0/0x150
> [ 149.806361] [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
> [ 149.814392] [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [ 149.821650] [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
> [ 149.828926] [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
> [ 149.836803] [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [ 149.843422] [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> [ 149.850067] [<ffffffff81010b45>] do_softirq+0x46/0x81
> [ 149.856760] [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> [ 149.863035] [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
> [ 149.871144] [<ffffffff814be76e>] xen_hvm_callback_vector+0x6e/0x80
> [ 149.879494] <EOI> [<ffffffff8102f2f1>] ? native_safe_halt+0xb/0xd
> [ 149.888220] [<ffffffff81015b7e>] default_idle+0x4e/0x86
> [ 149.894962] [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> [ 149.901461] [<ffffffff814934ee>] rest_init+0x72/0x74
> [ 149.908949] [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
> [ 149.916617] [<ffffffff81b762c4>] x86_64_start_reservations+0xaf/0xb3
> [ 149.929148] [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
> [ 149.936797] [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
> [ 149.944336] ---[ end trace d8786cb7d6a57f8a ]---
> [ 149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout, status
> d 3b 15 80ff
> [ 149.961879] ------------[ cut here ]------------
> [ 149.962245] WARNING: at kernel/softirq.c:159
> _local_bh_enable_ip+0x44/0x8e()
> [ 149.962245] Hardware name: HVM domU
> [ 149.962245] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
> nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state
> ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc mii parport
> i2c_piix4 i2c_core joydev [last unloaded: scsi_wait_scan]
> [ 149.962245] Pid: 0, comm: swapper Tainted: G
> W 3.1.0-5.fc16.x86_64 #1
> [ 149.962245] Call Trace:
> [ 149.962245] <IRQ> [<ffffffff81057a56>]
> warn_slowpath_common+0x83/0x9b
> [ 149.962245] [<ffffffff813ce599>] ? skb_release_data+0xca/0xcf
> [ 149.962245] [<ffffffff81057a88>] warn_slowpath_null+0x1a/0x1c
> [ 149.962245] [<ffffffff8105d462>] _local_bh_enable_ip+0x44/0x8e
> [ 149.962245] [<ffffffff8105d4ba>] local_bh_enable_ip+0xe/0x10
> [ 149.962245] [<ffffffff814b5db4>] _raw_spin_unlock_bh+0x15/0x17
> [ 149.962245] [<ffffffffa0053969>] destroy_conntrack+0x9d/0xdc
> [nf_conntrack]
> [ 149.962245] [<ffffffff813fa343>] nf_conntrack_destroy+0x19/0x1b
> [ 149.962245] [<ffffffff813ce7ad>] skb_release_head_state+0xa7/0xef
> [ 149.962245] [<ffffffff813ce5b1>] __kfree_skb+0x13/0x83
> [ 149.962245] [<ffffffff813ce677>] consume_skb+0x56/0x6b
> [ 149.962245] [<ffffffffa003c1b9>] cp_clean_rings+0xb4/0x114 [8139cp]
> [ 149.962245] [<ffffffffa003c371>] cp_tx_timeout+0x88/0x10e [8139cp]
> [ 149.962245] [<ffffffff813ef627>] dev_watchdog+0x104/0x150
> [ 149.962245] [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
> [ 149.962245] [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [ 149.962245] [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
> [ 149.962245] [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
> [ 149.962245] [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [ 149.962245] [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> [ 149.962245] [<ffffffff81010b45>] do_softirq+0x46/0x81
> [ 149.962245] [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> [ 149.962245] [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
> [ 149.962245] [<ffffffff814be76e>] xen_hvm_callback_vector+0x6e/0x80
> [ 149.962245] <EOI> [<ffffffff8102f2f1>] ? native_safe_halt+0xb/0xd
> [ 149.962245] [<ffffffff81015b7e>] default_idle+0x4e/0x86
> [ 149.962245] [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> [ 149.962245] [<ffffffff814934ee>] rest_init+0x72/0x74
> [ 149.962245] [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
> [ 149.962245] [<ffffffff81b762c4>] x86_64_start_reservations+0xaf/0xb3
> [ 149.962245] [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
> [ 149.962245] [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
> [ 149.962245] ---[ end trace d8786cb7d6a57f8b ]---
>
> Full guest kernel dmesg attached to this email.
> The host is running F16 with Xen 4.1.2 and Linux 3.1.0 dom0 kernel.
>
> Xen cfgfile for the HVM domain:
>
> kernel = "hvmloader"
> builder='hvm'
> device_model = 'qemu-dm'
> name = "f16test64hvm"
> memory = 1024
> vcpus=1
> pae=1
> acpi=1
> apic=1
> vif = [ 'type=ioemu, mac=00:16:3f:03:01:14, bridge=virbr0' ]
> disk = [ 'phy:/dev/vg_f16/f16test64hvm,hda,w',
> 'file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r' ]
> boot='cd'
> xen_platform_pci=0
> on_poweroff = 'destroy'
> on_reboot = 'restart'
> on_crash = 'restart'
> sdl=0
> vnc=1
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> usb=1
> usbdevice='tablet'
> keymap='fi'
>
> Using "model=e1000" instead for the vif works OK.. no problems with the
> emulated intel nic.
>
> Any ideas what the problem with the emulated realtek nic?
>
> Thanks,
>
> -- Pasi
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Xen-devel mailing list
> [2]Xen-devel(a)lists.xensource.com
> [3]http://lists.xensource.com/xen-devel
>
> References
>
> Visible links
> 1. file:///mc/compose?to=mockbuild@x86-10.phx2.fedoraproject.org
> 2. file:///mc/compose?to=Xen-devel@lists.xensource.com
> 3. http://lists.xensource.com/xen-devel
11 years, 6 months
F16 Xen dom0 SElinux problems with LVM volumes for domUs
by Pasi Kärkkäinen
Hello,
I need to do "setenforce 0" before I'm able to install Xen VMs with LVM volumes as disk backends..
Should I file a bugzilla entry about this?
See here for an example about the issue:
# rpm -qa|grep -i xen
xen-licenses-4.1.1-8.fc16.x86_64
netxen-firmware-4.0.534-4.fc15.noarch
xen-libs-4.1.1-8.fc16.x86_64
xen-4.1.1-8.fc16.x86_64
xen-hypervisor-4.1.1-8.fc16.x86_64
xen-runtime-4.1.1-8.fc16.x86_64
# rpm -qa|grep -i selinux
libselinux-python-2.1.5-5.1.fc16.x86_64
libselinux-utils-2.1.5-5.1.fc16.x86_64
selinux-policy-3.10.0-40.fc16.noarch
libselinux-2.1.5-5.1.fc16.x86_64
selinux-policy-targeted-3.10.0-40.fc16.noarch
# getenforce
Enforcing
# uname -a
Linux f16.localdomain 3.1.0-0.rc9.git0.0.fc16.x86_64 #1 SMP Wed Oct 5 15:30:54 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 4 r----- 74.0
# virt-install -d -n f16test32 -r 1024 --vcpus=2 -f /dev/vg_f16/f16test32 --vnc -p -l "http://server.tld/fedora/mount-f16-final-tc1-i386/"
Sun, 16 Oct 2011 11:42:00 DEBUG Launched with command line:
/usr/bin/virt-install -d -n f16test32 -r 1024 --vcpus=2 -f /dev/vg_f16/f16test32 --vnc -p -l http://server.tld/fedora/mount-f16-final-tc1-i386/
Sun, 16 Oct 2011 11:42:00 DEBUG Requesting libvirt URI default
Sun, 16 Oct 2011 11:42:01 DEBUG Received libvirt URI xen:///
Sun, 16 Oct 2011 11:42:01 DEBUG Requesting virt method 'xen', hv type 'default'.
Sun, 16 Oct 2011 11:42:01 DEBUG Received virt method 'xen'
Sun, 16 Oct 2011 11:42:01 DEBUG Hypervisor name is 'xen'
Sun, 16 Oct 2011 11:42:01 DEBUG --graphics compat generated: vnc
Sun, 16 Oct 2011 11:42:01 DEBUG DistroInstaller location is a network source.
Sun, 16 Oct 2011 11:42:01 DEBUG Attempting to detect distro:
Sun, 16 Oct 2011 11:42:01 DEBUG Fetching URI: http://server.tld/fedora/mount-f16-final-tc1-i386/.treeinfo
Sun, 16 Oct 2011 11:42:01 DEBUG Saved file to /var/tmp/virtinst-.treeinfo.Fx9zj5
Sun, 16 Oct 2011 11:42:01 DEBUG Guest.has_install_phase: True
Starting install...
Sun, 16 Oct 2011 11:42:01 DEBUG scratchdir=/var/lib/xen
Sun, 16 Oct 2011 11:42:01 DEBUG Attempting to detect distro:
Sun, 16 Oct 2011 11:42:01 DEBUG Fetching URI: http://server.tld/fedora/mount-f16-final-tc1-i386/.treeinfo
Sun, 16 Oct 2011 11:42:01 DEBUG Saved file to /var/lib/xen/virtinst-.treeinfo.tFlBQU
Retrieving file .treeinfo... | 1.8 kB 00:00 ...
Sun, 16 Oct 2011 11:42:01 DEBUG Fetching URI: http://server.tld/fedora/mount-f16-final-tc1-i386/images/pxeboot/vmlinuz-PAE
Sun, 16 Oct 2011 11:42:01 DEBUG Saved file to /var/lib/xen/virtinst-vmlinuz-PAE.iI_tC0
Retrieving file vmlinuz-PAE... | 7.9 MB 00:00 ...
Sun, 16 Oct 2011 11:42:01 DEBUG Fetching URI: http://server.tld/fedora/mount-f16-final-tc1-i386/images/pxeboot/initrd-P...
Sun, 16 Oct 2011 11:42:06 DEBUG Saved file to /var/lib/xen/virtinst-initrd-PAE.img.cpypw0==================== ] 31 MB/s | 119 MB 00:00 ETA
Retrieving file initrd-PAE.img... | 257 MB 00:04 ...
Sun, 16 Oct 2011 11:42:06 DEBUG Auto detected OS type as: linux
Sun, 16 Oct 2011 11:42:06 DEBUG Auto detected OS variant as: fedora16
Sun, 16 Oct 2011 11:42:06 DEBUG Have access to local system scratchdir so nothing to upload
Sun, 16 Oct 2011 11:42:06 DEBUG Generated install XML:
<domain type='xen'>
<name>f16test32</name>
<uuid>3dafa790-e0e1-8ca9-da0c-4083336c3096</uuid>
<memory>1048576</memory>
<currentMemory>1048576</currentMemory>
<vcpu>2</vcpu>
<os>
<type arch='x86_64'>linux</type>
<kernel>/var/lib/xen/virtinst-vmlinuz-PAE.iI_tC0</kernel>
<initrd>/var/lib/xen/virtinst-initrd-PAE.img.cpypw0</initrd>
<cmdline>method=http://server.tld/fedora/mount-f16-final-tc1-i386/</cmdline>
</os>
<features>
<acpi/><apic/>
</features>
<on_poweroff>destroy</on_poweroff>
<on_reboot>destroy</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<disk type='block' device='disk'>
<source dev='/dev/vg_f16/f16test32'/>
<target dev='xvda' bus='xen'/>
</disk>
<interface type='network'>
<source network='default'/>
<mac address='00:16:3e:12:3c:49'/>
</interface>
<input type='mouse' bus='xen'/>
<graphics type='vnc' port='-1' keymap='fi'/>
<video>
<model type='cirrus'/>
</video>
</devices>
</domain>
Sun, 16 Oct 2011 11:42:06 DEBUG Generated boot XML:
<domain type='xen'>
<name>f16test32</name>
<uuid>3dafa790-e0e1-8ca9-da0c-4083336c3096</uuid>
<memory>1048576</memory>
<currentMemory>1048576</currentMemory>
<vcpu>2</vcpu>
<bootloader>/usr/bin/pygrub</bootloader>
<features>
<acpi/><apic/>
</features>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<disk type='block' device='disk'>
<source dev='/dev/vg_f16/f16test32'/>
<target dev='xvda' bus='xen'/>
</disk>
<interface type='network'>
<source network='default'/>
<mac address='00:16:3e:12:3c:49'/>
</interface>
<input type='mouse' bus='xen'/>
<graphics type='vnc' port='-1' keymap='fi'/>
<video>
<model type='cirrus'/>
</video>
</devices>
</domain>
Sun, 16 Oct 2011 11:42:08 DEBUG Removing /var/lib/xen/virtinst-vmlinuz-PAE.iI_tC0
Sun, 16 Oct 2011 11:42:08 DEBUG Removing /var/lib/xen/virtinst-initrd-PAE.img.cpypw0
Sun, 16 Oct 2011 11:42:08 ERROR Domain not found: xenUnifiedDomainLookupByName
Sun, 16 Oct 2011 11:42:08 DEBUG Traceback (most recent call last):
File "/usr/bin/virt-install", line 620, in start_install
noboot=options.noreboot)
File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1223, in start_install
noboot)
File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1291, in _create_guest
dom = self.conn.createLinux(start_xml or final_xml, 0)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2077, in createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: Domain not found: xenUnifiedDomainLookupByName
Sun, 16 Oct 2011 11:42:08 DEBUG Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect xen:/// start f16test32
otherwise, please restart your installation.
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect xen:/// start f16test32
otherwise, please restart your installation.
-- Pasi
11 years, 7 months
Re: [Fedora-xen] [Xen-devel] Xen 4.1.2 PVHVM guest with Linux 3.1.0 network problem, empty MAC address (all zeroes)
by Pasi Kärkkäinen
On Mon, Oct 31, 2011 at 10:13:36PM +0200, Pasi Kärkkäinen wrote:
> Hello,
>
> While testing Fedora 16 Xen PVHVM guests I noticed the following problem:
>
> When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear on dom0,
> but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the
> vif/tap interfaces disappear from dom0..
> so the bridge in dom0 doesn't have any vifs/taps connected to it anymore.
>
> Has anyone seen that behaviour?
>
> I bet that's also the reason why eth0 inside the PVHVM guest
> has a MAC address with only zeroes in it: 00:00:00:00:00:00.
>
> If I disable PVHVM with "xen_platform_pci=0" in the domain cfgfile
> then network for the guest works OK using the qemu-dm emulated nic.
>
> PVHVM guest cfgfile:
>
<snip>
>
> Some output from inside the PVHVM guest:
>
> # ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
<snip>
>
> Full PVHVM guest kernel (Linux 3.1.0) dmesg attached to this email.
> Some parts of the guest dmesg here:
>
> $ egrep -i 'xen|vif' xen-4.1.2-f16pvhvm-linux-3.1.0-dmesg.txt
>
<snip>
>
> dom0 kernel (Linux 3.1.0 aswell) messages:
>
<snip>
>
>
> "xm log" doesn't have any errors.
> Any ideas how to fix this? Why do the vif/tap devices disappear from dom0?
>
Well.. it was actually as simple as removing "type=ioemu" from the vif line.
Working vif-example for Xen PVHVM Linux guest VM:
vif = [ 'mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000' ]
So uhm.. when enabling PVHVM there's no need to modify the disk line,
but you need to modify the vif-line.. is that like it should be ?
-- Pasi
11 years, 7 months
Re: [Fedora-xen] Grubby Issues with F16 Dom0
by M A Young
On Mon, 24 Oct 2011, Tim Flink wrote:
> Yeah, that's 744717. The bug isn't incredibly clear and I didn't do a
> very good job of summarizing it. If you look at the before and
> after grub.cfg files, you can see it though.
>
> How often would that happen in a guest? I don't think that I have
> submenu entries in any of my DomUs.
I don't think it is particularly likely to happen unless submenus are used for
something else. Someone might install a xen hypervisor on a guest by mistake,
but it isn't that likely. I did it deliberately for grub2 testing as I am still
on grub1 on my base system.
Michael Young
11 years, 7 months
Grubby Issues with F16 Dom0
by Tim Flink
Just as a heads up, there seem to be a couple of issues with grubby and
the grub.cfg submenus used for Xen right now. My system still boots
after triggering any of these but it's usually not running Xen and not
always running the kernel I want it to be running.
Kernel submenu entries aren't updated w/ kernel updates:
- https://bugzilla.redhat.com/show_bug.cgi?id=748551
This can be worked around by regenerating grub.cfg @ every kernel
update ('grub2-mkconfig -o /boot/grub2/grub.cfg')
There are a couple other grubby issues that I haven't hit naturally yet
(not difficult to provoke, though). Both can be worked around by
regenerating grub.cfg after making kernel changes but before rebooting.
- Extra entries are being removed from grub.cfg @ kernel pkg removal
* https://bugzilla.redhat.com/show_bug.cgi?id=744717
* I haven't personally seen this during kernel removal @ upgrade time
but it's something to watch out for if you are removing kernels
- Whitespace is removed from grub default once grub.cfg is processed
by grubby.
* https://bugzilla.redhat.com/show_bug.cgi?id=742720
* 748551 also stomps on the default in grub.cfg, so I haven't seen
this yet but it could show up.
11 years, 7 months
virt-manager destroying the guest leaves a "ghost" in xend.
by Konrad Rzeszutek Wilk
I tried to install a guest and midway during it decided to install something
else so I stopped the process and killed the guest.
But got an error and xend.log has this:
[2011-10-10 17:42:06 961] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51712
[2011-10-10 17:43:29 961] ERROR (SrvBase:88) Request destroy failed.
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/xen/web/SrvBase.py", line 85, in perform
return op_method(op, req)
File "/usr/lib64/python2.7/site-packages/xen/xend/server/SrvDomain.py", line 89, in op_destroy
return self.xd.domain_destroy(self.dom.domid)
File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line 1315, in domain_destroy
dominfo = self.domain_lookup_nr(domid)
File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line 588, in domain_lookup_nr
if int(domid) in self.domains:
TypeError: int() argument must be a string or a number, not 'NoneType'
and "xm list" tells me
[root@tst006 /]# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 3343 2 r----- 162.2
F15_test 1024 1 0.0
Quitting virt-manager and then 'Deleting' the F15_test makes xend finally remove the
ghost:
[2011-10-10 17:45:27 961] INFO (XendDomain:1126) Domain F15_test (18eaec13-8ed3-ad0c-6473-7947366fce02) deleted.
So.. has anybody else hit this?
11 years, 7 months
High Volume of Syslog Messages on Fedora 16 Dom0
by Tim Flink
I just upgraded an older Opteron machine that I've been using as Xen
Dom0 from RHEL5 to Fedora 16.
When I boot with Xen, my syslog is full of messages (several per
second) like the following:
kernel: [ 1.226209] powernow-k8: fid trans failed, fid 0x2, curr 0x0
kernel: [ 1.226271] powernow-k8: transition frequency failed
Things seem to be working (I can use xm list) but I would rather not
have my system log be quite that noisy. Unfortunately, I'm quite sure
where to go from here to debug and fix the issue; any suggestions?
Tim
Fedora 16
3.1.0-0.rc8.git0.1.fc16.x86_64
xen-4.1.1-6
2x Dual Core AMD Opteron(tm) Processor 865 HE
11 years, 7 months
