xen November 2010

xen@lists.stg.fedoraproject.org

21 participants
8 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

2.6.32.x dom0 kernel
by M A Young 28 Apr '11

28 Apr '11

I have built another 2.6.32.x based kernel (2.6.32.25-172.xendom0.fc12) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not actually change anything), and uses a later version of xen/stable-2.6.3.32.x which adds a couple of xen fixes. Michael Young

5 18

Dom0 xen support in Fedora 15?
by M A Young 21 Jan '11

21 Jan '11

I am trying to work out whether it is practical to propose Dom0 xen support as a feature for Fedora 15. The kernel situation is that Domain 0 has been accepted upstream for 2.6.37. Assuming a 3 month kernel release cycle, F15 will most likely ship with a 2.6.37.x kernel, with 2.6.38 coming out either after the F15 release or just before but too late to be included. If the plan to get key xen drivers into 2.6.38 succeeds, then F15 may be become usable as a Domain 0 system at some point during its lifetime as the kernel package in a Fedora version typically has one major update. If the kernel team accept backported patches then it might just be possible to ship F15 with usable Domain 0 support but the timescale for that would be very tight. The other thing we would need to consider is what needs to be done to make xen friendly enough to be usable by an ordinary user. The page https://fedoraproject.org/wiki/Features/XenPvopsDom0 contains plans from when dom0 xen support was expected to make a quick return to Fedora, but they are a couple of years old now so probably need updating. I think as a minimum we would need a way to add a dom0 enabled grub entry for a kernel, rather than requiring the user to hand edit the grub file. We should also make sure that xen works with the other Fedora virtualisation tools. What do others think about this? For example is it achievable as a feature, is it too early and better to wait for F16, and what else should we aim to do to make xen usable in Fedora? Michael Young

20 45

2.6.37-rc1 dom0 kernel
by M A Young 07 Jan '11

07 Jan '11

I have built another test kernel (2.6.37-0.1.rc1.git0.xendom0.fc15) to play with at http://koji.fedoraproject.org/koji/taskinfo?taskID=2581020 . As with the previous kernel this is entirely based on the upstream kernel and Fedora kernel patches, and is probably close to what the Fedora 15 kernel will look like soon. I haven't tested it yet. Michael Young

5 17

XenPvopsDom0, Fedora 15 Feature
by W. Michael Petullo 30 Nov '10

30 Nov '10

I just completed some updates of https://fedoraproject.org/wiki/Features/XenPvopsDom0. I would like to submit this to the Fedora Feature Wranglers on Wednesday as a proposed feature for Fedora 15. If you are interested, please review the document and provide feedback. If you are a previous editor of the page, I hope you don't mind me trying to move this forward. I will appreciate any comments. Thanks, -- Mike :wq

3 2

Xen and grubby
by W. Michael Petullo 29 Nov '10

29 Nov '10

As far as I can tell, Fedora's grubby does not yet support the GRUB syntax required by Xen, e.g., title Fedora (2.6.32.23-170.1.xendom0.fc12.x86_64) root (hd0,0) kernel /xen-4.0.1.gz ==> module /vmlinuz-2.6.32.23-170.1.xendom0.fc12.x86_64 ... ==> module /initramfs-2.6.32.23-170.1.xendom0.fc12.x86_64.img I don't think it supports multiple "module" keywords. I am presently working on extending grubby to allow something like the following (note that the --add-kernel parameter name might change): grubby --add-multiboot=/boot/xen.gz --mbargs="[xen arguments]" \ --add-kernel=/boot/vmlinuz-2.6.32.23-170.1.xendom0.fc12.x86_64 \ --args="[kernel arguments]" \ --add-kernel=/boot/initramfs-2.6.32.23-170.1.xendom0.fc12.x86_64.img \ --title="Xen Hypervisor" Does this make sense? How could we tie this into anaconda kernel upgrades? I am thinking of adding something to /etc/sysconfig/kernel that new-kernel-pkg would look for. If the flag is present, then new-kernel-pkg could use the extended grubby syntax. The Fedora Wiki's XenPvopsDom0 document mentions /etc/sysconfig/xen instead, is this up to date? Should we use this instead of /etc/sysconfig/kernel? -- Mike :wq

2 1

Compiling myoung's f12 dom0 on RHEL6
by Digimer 17 Nov '10

17 Nov '10

I hope this isn't too off-topic. :) I'm trying to recompile Michael Young's F12 dom0 kernel[1] on RHEL 6. I've run into a small issue that I could probably push through, but I wanted to ask for opinions here. The source RPM depends on 'asciidoc', which isn't in the main Red Hat repository (at least, not that I could find). I was wondering what, exactly, needs asciidoc and if it would be safe/easy/possible/advisable to remove that dependency. Thanks! 1. http://fedorapeople.org/~myoung/dom0/src/kernel-2.6.32.25-172.xendom0.fc12.… -- Digimer E-Mail: digimer(a)alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org

2 5

Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel
by Boris Derzhavets 07 Nov '10

07 Nov '10

Dmesg log is attached :- [ 42.140012] WARNING: at lib/debugobjects.c:259 debug_print_object+0x5b/0x63() [ 42.140012] Hardware name: System Product Name [ 42.140012] ODEBUG: free active (active state 0) object type: percpu_counter [ 42.140012] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat deflate zlib_deflate ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_generic twofish_x86_64 twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel tunnel6 af_key sunrpc bridge stp llc ipv6 evtchn xenfs uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel r8169 mii snd_hda_codec snd_hwdep shpchp snd_seq snd_seq_device snd_pcm microcode snd_timer iTCO_wdt i2c_i801 asus_atk0110 snd iTCO_vendor_support soundcore snd_page_alloc pata_acpi firewire_ohci firewire_core ata_generic crc_itu_t pata_jmicron radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] [ 42.140012] Pid: 53, comm: kworker/u:6 Not tainted 2.6.37-0.1.rc1.git0.xendom0.fc14.x86_64 #1 [ 42.140012] Call Trace: [ 42.140012] [<ffffffff81051d68>] warn_slowpath_common+0x85/0x9d [ 42.140012] [<ffffffff81051e23>] warn_slowpath_fmt+0x46/0x48 [ 42.140012] [<ffffffff812573e9>] debug_print_object+0x5b/0x63 [ 42.140012] [<ffffffff81257c1f>] debug_check_no_obj_freed+0x99/0x18a [ 42.140012] [<ffffffff8107d997>] ? arch_local_save_flags+0xb/0xd [ 42.140012] [<ffffffff810822b4>] ? debug_check_no_locks_freed+0x11c/0x138 [ 42.140012] [<ffffffff813f76b8>] ? net_free+0x2c/0x31 [ 42.140012] [<ffffffff81123804>] kmem_cache_free+0x6f/0x10b [ 42.140012] [<ffffffff813f76b8>] net_free+0x2c/0x31 [ 42.140012] [<ffffffff813f7835>] cleanup_net+0x178/0x197 [ 42.140012] [<ffffffff81068d8f>] process_one_work+0x1f4/0x361 [ 42.140012] [<ffffffff81068cfb>] ? process_one_work+0x160/0x361 [ 42.140012] [<ffffffff813f76bd>] ? cleanup_net+0x0/0x197 [ 42.140012] [<ffffffff8106a1a8>] worker_thread+0x104/0x1a4 [ 42.140012] [<ffffffff8106a0a4>] ? worker_thread+0x0/0x1a4 [ 42.140012] [<ffffffff8106dbee>] kthread+0xa0/0xa8 [ 42.140012] [<ffffffff81082165>] ? trace_hardirqs_on_caller+0x10b/0x12f [ 42.140012] [<ffffffff8100ab64>] kernel_thread_helper+0x4/0x10 [ 42.140012] [<ffffffff814b23d0>] ? restore_args+0x0/0x30 [ 42.140012] [<ffffffff8100ab60>] ? kernel_thread_helper+0x0/0x10 [ 42.140012] ---[ end trace c2d2451e1a620a4f ]--- [ 42.140012] BUG: sleeping function called from invalid context at kernel/mutex.c:278 [ 42.140012] in_atomic(): 0, irqs_disabled(): 1, pid: 53, name: kworker/u:6 [ 42.140012] 2 locks held by kworker/u:6/53: [ 42.140012] #0: (netns){+.+.+.}, at: [<ffffffff81068cfb>] process_one_work+0x160/0x361 [ 42.140012] #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff81068cfb>] process_one_work+0x160/0x361 [ 42.140012] irq event stamp: 7666 [ 42.140012] hardirqs last enabled at (7665): [<ffffffff81123756>] kfree+0x11f/0x136 [ 42.140012] hardirqs last disabled at (7666): [<ffffffff811237cd>] kmem_cache_free+0x38/0x10b [ 42.140012] softirqs last enabled at (7620): [<ffffffff8141ea6c>] netlink_release+0x1f3/0x208 [ 42.140012] softirqs last disabled at (7618): [<ffffffff8141ea54>] netlink_release+0x1db/0x208 [ 42.140012] Pid: 53, comm: kworker/u:6 Tainted: G W 2.6.37-0.1.rc1.git0.xendom0.fc14.x86_64 #1 [ 42.140012] Call Trace: [ 42.140012] [<ffffffff810807a8>] ? print_irqtrace_events+0xa0/0xa4 [ 42.140012] [<ffffffff81043256>] __might_sleep+0x103/0x108 [ 42.140012] [<ffffffff814b0512>] mutex_lock_nested+0x25/0x43 [ 42.140012] [<ffffffff8125ae02>] percpu_counter_destroy+0x3c/0x66 [ 42.140012] [<ffffffff8125ae42>] percpu_counter_fixup_free+0x16/0x32 [ 42.140012] [<ffffffff8125723b>] debug_object_fixup+0x1e/0x2b [ 42.140012] [<ffffffff81257c54>] debug_check_no_obj_freed+0xce/0x18a [ 42.140012] [<ffffffff810822b4>] ? debug_check_no_locks_freed+0x11c/0x138 [ 42.140012] [<ffffffff813f76b8>] ? net_free+0x2c/0x31 [ 42.140012] [<ffffffff81123804>] kmem_cache_free+0x6f/0x10b [ 42.140012] [<ffffffff813f76b8>] net_free+0x2c/0x31 [ 42.140012] [<ffffffff813f7835>] cleanup_net+0x178/0x197 [ 42.140012] [<ffffffff81068d8f>] process_one_work+0x1f4/0x361 [ 42.140012] [<ffffffff81068cfb>] ? process_one_work+0x160/0x361 [ 42.140012] [<ffffffff813f76bd>] ? cleanup_net+0x0/0x197 [ 42.140012] [<ffffffff8106a1a8>] worker_thread+0x104/0x1a4 [ 42.140012] [<ffffffff8106a0a4>] ? worker_thread+0x0/0x1a4 [ 42.140012] [<ffffffff8106dbee>] kthread+0xa0/0xa8 [ 42.140012] [<ffffffff81082165>] ? trace_hardirqs_on_caller+0x10b/0x12f [ 42.140012] [<ffffffff8100ab64>] kernel_thread_helper+0x4/0x10 [ 42.140012] [<ffffffff814b23d0>] ? restore_args+0x0/0x30 [ 42.140012] [<ffffffff8100ab60>] ? kernel_thread_helper+0x0/0x10 Boris --- On Fri, 11/5/10, M A Young <m.a.young(a)durham.ac.uk> wrote: From: M A Young <m.a.young(a)durham.ac.uk> Subject: [Fedora-xen] 2.6.37-rc1 dom0 kernel To: xen(a)lists.fedoraproject.org Date: Friday, November 5, 2010, 7:32 PM I have built another test kernel (2.6.37-0.1.rc1.git0.xendom0.fc15) to play with at http://koji.fedoraproject.org/koji/taskinfo?taskID=2581020 . As with the previous kernel this is entirely based on the upstream kernel and Fedora kernel patches, and is probably close to what the Fedora 15 kernel will look like soon. I haven't tested it yet. Michael Young -- xen mailing list xen(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xen November 2010