xen October 2011

xen@lists.fedoraproject.org

8 participants
14 discussions

execute commands from dom0 into domU
by silviu d 06 Jun '15

06 Jun '15

Hello, I was wondering if there is a way to execute commands from dom0 into domU without loging into domU with ssh. thanks

3 2

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 03 Nov '11

03 Nov '11

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

1 2

F16 Xen dom0 SElinux problems with LVM volumes for domUs
by Pasi Kärkkäinen 01 Nov '11

01 Nov '11

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-PAE… 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

3 4

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 31 Oct '11

31 Oct '11

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

1 1

Testing (and karma) needed for F16 enhancement xen-4.1.1-8.fc16 enhancement update
by Pasi Kärkkäinen 25 Oct '11

25 Oct '11

Hello, Michael patched xen-4.1.1-8.fc16 to support Fedora 16 default GPT partition tables, with Xen PV domUs using pygrub, so everyone please test the the new F16 xen rpms from updates-testing, and leave feedback (positive karma) so the package can move out of updates-testing. Bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=745335 And to leave feedback / add karma: https://admin.fedoraproject.org/updates/xen-4.1.1-8.fc16 Thanks, -- Pasi

1 1

Re: [Fedora-xen] Grubby Issues with F16 Dom0
by M A Young 24 Oct '11

24 Oct '11

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

1 0

Grubby Issues with F16 Dom0
by Tim Flink 24 Oct '11

24 Oct '11

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.

2 2

xen packages to test
by M A Young 24 Oct '11

24 Oct '11

I have a couple of temporary builds of xen release candidates available for testing; xen-4.0.2-rc4 built for F14 at http://koji.fedoraproject.org/koji/taskinfo?taskID=3085546 and xen-4.1.1-rc1 built for F15 at http://koji.fedoraproject.org/koji/taskinfo?taskID=3086043 Also if you are interested in testing packages for RHEL6 see http://koji.fedoraproject.org/koji/taskinfo?taskID=3086043 Michael Young

4 6

virt-manager destroying the guest leaves a "ghost" in xend.
by Konrad Rzeszutek Wilk 17 Oct '11

17 Oct '11

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?

3 2

High Volume of Syslog Messages on Fedora 16 Dom0
by Tim Flink 14 Oct '11

14 Oct '11

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

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xen October 2011