I've got a Digium PCI telephone card that I'm trying to use with an AsteriskNow guest, on a CentOS 5.2 host. I've tried setting up the pciback stuff, and think I've done it right, but the card does not show up in the guest. I'm obviously missing something, so any help (including ways to debug this!) would be greatly appreciated.
Here's some more info:
The guest is fully virtualized, so I'm assuming that nothing should need to be configured within the guest.
On the host, the card shows up as:
[root@xenhost bus]# lspci | grep Digium 07:01.0 Ethernet controller: Digium, Inc. Unknown device 8005 (rev 11)
I think the pciback is set up properly. When I load the module, the /sys/bus/pci/drivers/pciback/ is created, and everything looks the way I think it should:
[root@xenhost pciback]# pwd ; cat slots ; file 0000:07:01.0
/sys/bus/pci/drivers/pciback 0000:07:01.0 0000:07:01.0: symbolic link to `../../../../devices/pci0000:00/0000:00:02.0/0000:01:00.3/0000:07:01.0'
This shows up in /var/log/messages:
Oct 24 16:34:58 xenhost kernel: pciback 0000:07:01.0: seizing device Oct 24 16:34:58 xenhost kernel: PCI: Enabling device 0000:07:01.0 (0000 -> 0003) Oct 24 16:34:58 xenhost kernel: ACPI: PCI Interrupt 0000:07:01.0[A] -> GSI 24 (level, low) -> IRQ 20 Oct 24 16:34:58 xenhost kernel: ACPI: PCI interrupt for device 0000:07:01.0 disabled
Here is my xen config file, with the PCI line at the end:
name = "asterisk_now" uuid = "02f476ce-7a98-e58c-f715-0bb28a3c6c3d" maxmem = 2048 memory = 1024 vcpus = 1 builder = "hvm" kernel = "/usr/lib/xen/boot/hvmloader" boot = "c" pae = 1 acpi = 1 apic = 1 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib/xen/bin/qemu-dm" sdl = 0 vnc = 1 vncunused = 1 keymap = "en-us" disk = [ "phy:/dev/datafarm/asterisk_now,hda,w", ",hdc:cdrom,r" ] vif = [ "mac=00:16:3e:6c:ae:c2,bridge=xenbr0" ] serial = "pty" pci = [ "07:01.00" ]
(In the scattered bits of documentation I've found on this topic, I've seen a couple of different formats for specifying the PCI, including "pci = [ "0000:07:01.00" ] and "7,1,0". None of them seemed to work either.
My virtual AsteriskNow machine is not yet running (and I've tried restarting xend at this point), but when I start the machine, no card is visible:
[admin@192-168-6-94 ~]$ lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01) 00:01.3 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01) 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20)
Thanks in advance for any assistance!
Ken
On Fri, Oct 24, 2008 at 7:58 PM, Kenneth Tanzer ktanzer@desc.org wrote:
I've got a Digium PCI telephone card that I'm trying to use with an AsteriskNow guest, on a CentOS 5.2 host. I've tried setting up the pciback stuff, and think I've done it right, but the card does not show up in the guest. I'm obviously missing something, so any help (including ways to debug this!) would be greatly appreciated.
Here's some more info:
The guest is fully virtualized, so I'm assuming that nothing should need to be configured within the guest.
Just a sanity check, proper IOMMU support, such as Intel VT-d, is needed for passing devices to fully virt guests. Does your system support VT-d?
Cheers, Todd
Well I'm all for sanity checks, not having realized that anything beyond "vt support" was needed. This is new territory for me, but based on my host lspci output (below), I'm guessing that I've got a 3100 chipset, which seems not to support vt-d, leaving me SOL.
Can you confirm I'm interpreting this properly, or offer some other means to determine vt-d support? Many thanks!
Ken
[root@xenhost proc]# lspci 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev b1) 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1) 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev b1) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) 00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) 00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) 00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) 00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09) 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) 03:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) 03:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) 06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 07:01.0 Ethernet controller: Digium, Inc. Unknown device 8005 (rev 11) 08:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID (rev 01) 0b:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
Todd Deshane wrote:
On Fri, Oct 24, 2008 at 7:58 PM, Kenneth Tanzer ktanzer@desc.org wrote:
I've got a Digium PCI telephone card that I'm trying to use with an AsteriskNow guest, on a CentOS 5.2 host. I've tried setting up the pciback stuff, and think I've done it right, but the card does not show up in the guest. I'm obviously missing something, so any help (including ways to debug this!) would be greatly appreciated.
Here's some more info:
The guest is fully virtualized, so I'm assuming that nothing should need to be configured within the guest.
Just a sanity check, proper IOMMU support, such as Intel VT-d, is needed for passing devices to fully virt guests. Does your system support VT-d?
Cheers, Todd
On Mon, Oct 27, 2008 at 1:03 PM, Kenneth Tanzer ktanzer@desc.org wrote:
Well I'm all for sanity checks, not having realized that anything beyond "vt support" was needed. This is new territory for me, but based on my host lspci output (below), I'm guessing that I've got a 3100 chipset, which seems not to support vt-d, leaving me SOL.
Can you confirm I'm interpreting this properly, or offer some other means to determine vt-d support? Many thanks!
The chipsets that support VT-d are listed on this page: http://wiki.xensource.com/xenwiki/VTdHowTo
Cheers, Todd
OK, thanks. Our vendor says our processor and chipset both don't support VT-d, so we're definitely out of luck!
Maybe someone can help with some related xen-ignorance on my part. Since it can't work with full virtualization, I'd like to try running paravirtualized. (Sanity check: you can do PCI passthroughs with PV guests, right?)
So I've downloaded the AsteriskNow 1.5 beta, which is (conveniently) built off of CentOS 5.2. I installed it fully virtualized, fired it up and installed the xen kernel. I can run the Xen kernel (albeit very slowly) in a fully-virtual environment, but I can't get it to boot as a PV guest. I get this instead:
Error: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF image has no shstrtab\n')
With some tweaking that I can no longer recreate, I was able to get the kernel to load, but then it paniced and died. Any help with the correct boot magic would be greatly appreciated!
Ken
This is my xen configuration:
name = "anow_15b_pv" uuid = "ef2d9b6c-0668-4d12-989c-876882b28099" maxmem = 512 memory = 512 vcpus = 1 bootloader = "/usr/bin/pygrub" on_poweroff = "destroy" on_reboot = "restart" on_crash = "preserve" vfb = [ "type=vnc,vncunused=1,keymap=en-us" ] disk = [ "phy:/dev/datafarm/asterisk_now_15b,hda,w" ] vif = [ "mac=00:16:3e:27:72:11,bridge=xenbr0" ]
This is my grub.conf file:
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/hda default=1 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-92.1.13.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-92.1.13.el5 module /vmlinuz-2.6.18-92.1.13.el5xen ro root=/dev/VolGroup00/LogVol00 module /initrd-2.6.18-92.1.13.el5xen.img title CentOS (2.6.18-92.1.13.el5) root (hd0,0) kernel /vmlinuz-2.6.18-92.1.13.el5 ro root=/dev/VolGroup00/LogVol00 initrd /initrd-2.6.18-92.1.13.el5.img
Todd Deshane wrote:
On Mon, Oct 27, 2008 at 1:03 PM, Kenneth Tanzer ktanzer@desc.org wrote:
Well I'm all for sanity checks, not having realized that anything beyond "vt support" was needed. This is new territory for me, but based on my host lspci output (below), I'm guessing that I've got a 3100 chipset, which seems not to support vt-d, leaving me SOL.
Can you confirm I'm interpreting this properly, or offer some other means to determine vt-d support? Many thanks!
The chipsets that support VT-d are listed on this page: http://wiki.xensource.com/xenwiki/VTdHowTo
Cheers, Todd
On Thu, Oct 30, 2008 at 6:37 PM, Kenneth Tanzer ktanzer@desc.org wrote:
OK, thanks. Our vendor says our processor and chipset both don't support VT-d, so we're definitely out of luck!
Maybe someone can help with some related xen-ignorance on my part. Since it can't work with full virtualization, I'd like to try running paravirtualized. (Sanity check: you can do PCI passthroughs with PV guests, right?)
Yes.
So I've downloaded the AsteriskNow 1.5 beta, which is (conveniently) built off of CentOS 5.2. I installed it fully virtualized, fired it up and installed the xen kernel. I can run the Xen kernel (albeit very slowly) in a fully-virtual environment, but I can't get it to boot as a PV guest. I get this instead:
Error: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF image has no shstrtab\n')
The easiest way to get this to boot is to change remove the bootloader option and replace it with kernel and ramdisk options
So remove:
bootloader='/usr/bin/pygrub'
and add
kernel='/boot/vmlinuz-<your dom0 xen kernel version>' (found in /boot) ramdisk='/boot/initrd-<your dom0 xen ramdisk version>' (found in /boot)
This will also get rid of any potential pygrub security issues as well.
Hope that helps, Cheers, Todd
So remove:
bootloader='/usr/bin/pygrub'
and add
kernel='/boot/vmlinuz-<your dom0 xen kernel version>' (found in /boot) ramdisk='/boot/initrd-<your dom0 xen ramdisk version>' (found in /boot)
I tried this a couple of ways. If I add just the kernel file, and not the parameters, like so:
kernel="/boot/vmlinuz-2.6.18-92.1.13.el5xen" ramdisk="/boot/initrd-2.6.18-92.1.13.el5xen.img"
It starts booting, but then dies with:
Kernel panic - not syncing: Attempted to kill init!
If I add the "ro root=/dev/VolGroup00/LogVol00" to the kernel line, I either get a kernel not found message (if the parameteres are inside the quotation marks), or an invalid parameter message (if outside the quotes). I tried adding:
root="/dev/VolGroup00/LogVol00"
(with and without a "ro" at the end), and it still boots the kernel but then panics. Which is what I'm starting to do! :)
Thanks again. Full console output from a boot below, in case it helps.
Ken
[root@xenhost xen]# xm create anow_15b_pv ; xm console anow_15b_pv Using config file "./anow_15b_pv". Started domain anow_15b_pv Linux version 2.6.18-92.1.13.el5xen (mockbuild@builder16.centos.org) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Wed Sep 24 20:44:26 EDT 2008 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000020800000 (usable) 0MB HIGHMEM available. 520MB LOWMEM available. NX (Execute Disable) protection: active ACPI in unprivileged domain disabled Built 1 zonelists. Total pages: 133120 Kernel command line: root=/dev/VolGroup00/LogVol00 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c073c000 soft=c071c000 PID hash table entries: 4096 (order: 12, 16384 bytes) Xen reported: 2999.996 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: e1000000-f4ffe000, maxmem 2d7fe000 Memory: 506496k/532480k available (2099k kernel code, 17432k reserved, 870k data, 176k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 7503.65 BogoMIPS (lpj=15007302) Security Framework v1.0.0 initialized SELinux: Initializing. selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 13k freed Brought up 1 CPUs checking if image is initramfs... it is Freeing initrd memory: 6916k freed Grant table initialized NET: Registered protocol family 16 ACPI Exception (utmutex-0262): AE_BAD_PARAMETER, Thread C06EAAA0 could not acquire Mutex [2] [20060707] No dock devices found. ACPI Exception (utmutex-0262): AE_BAD_PARAMETER, Thread C06EAAA0 could not acquire Mutex [2] [20060707] Brought up 1 CPUs PCI: Fatal: No PCI config space access function found PCI: setting up Xen PCI frontend stub ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled xen_mem: Initialising balloon driver. usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) audit(1225408235.766:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key 20B65DCA289A0EEF - User ID: CentOS (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 rtc: IRQ 8 is not free. Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize Xen virtual console successfully installed as xvc0 Event-channel device installed. Console: switching to colour frame buffer device 100x37 input: Xen Virtual Keyboard/Mouse as /class/input/input0 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx ide-floppy driver 0.99.newide usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. mice: PS/2 mouse device common for all mice md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 TCP bic registered Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI No-Shortcut mode XENBUS: Device with no driver: device/vbd/768 XENBUS: Device with no driver: device/vif/0 Freeing unused kernel memory: 176k freed Write protecting the kernel read-only data: 379k USB Universal Host Controller Interface driver v3.0 SCSI subsystem initialized 3ware 9000 Storage Controller device driver for Linux v2.26.02.008. device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.11.5-ioctl (2007-12-12) initialised: dm-devel@redhat.com Kernel panic - not syncing: Attempted to kill init!
On Thu, Oct 30, 2008 at 7:12 PM, Kenneth Tanzer ktanzer@desc.org wrote:
I tried this a couple of ways. If I add just the kernel file, and not the parameters, like so:
kernel="/boot/vmlinuz-2.6.18-92.1.13.el5xen" ramdisk="/boot/initrd-2.6.18-92.1.13.el5xen.img"
good
It starts booting, but then dies with:
:(
Kernel panic - not syncing: Attempted to kill init!
If I add the "ro root=/dev/VolGroup00/LogVol00" to the kernel line, I either get a kernel not found message (if the parameteres are inside the quotation marks), or an invalid parameter message (if outside the quotes). I tried adding:
root="/dev/VolGroup00/LogVol00"
(with and without a "ro" at the end), and it still boots the kernel but then panics. Which is what I'm starting to do! :)
add the ro and any of kernel parameters to an extra boot parameter example extra="ro"
I am not seeing the errors in the red hat based boot that I am familiar with, but it seems that you are running into one of the following (or similar:
Your guest root file system is not where you expect it to be. If you haven't already, check the grub.conf in the guest.
OR
You are missing modules in your ramdisk that are needed by your guest (in which case you would need to use mkinitrd to rebuild your xen initrd and make sure you include the necessary modules)
OR
Some combination of the above, you should be able to pretty closely mirror the kernel command line with the combination of kernel, root, and extra parameters.
The only tricky part would be to rebuild with any missing modules.
Hope that helps, Cheers, Todd
Thanks, I'll try to check into this. One quick question, though, which I forgot to ask. When I installed the xen kernel in the guest, it set up this line in grub.conf:
kernel /xen.gz-2.6.18-92.1.13.el5
Which we haven't referenced anywhere in the config file. Do I need it? Is that the actual kernel to specify, and if so, how do I specify the vmlinuz file that is referenced as a "module" in the grub config?
Ken
Todd Deshane wrote:
On Thu, Oct 30, 2008 at 7:12 PM, Kenneth Tanzer ktanzer@desc.org wrote:
I tried this a couple of ways. If I add just the kernel file, and not the parameters, like so:
kernel="/boot/vmlinuz-2.6.18-92.1.13.el5xen" ramdisk="/boot/initrd-2.6.18-92.1.13.el5xen.img"
good
It starts booting, but then dies with:
:(
Kernel panic - not syncing: Attempted to kill init!
If I add the "ro root=/dev/VolGroup00/LogVol00" to the kernel line, I either get a kernel not found message (if the parameteres are inside the quotation marks), or an invalid parameter message (if outside the quotes). I tried adding:
root="/dev/VolGroup00/LogVol00"
(with and without a "ro" at the end), and it still boots the kernel but then panics. Which is what I'm starting to do! :)
add the ro and any of kernel parameters to an extra boot parameter example extra="ro"
I am not seeing the errors in the red hat based boot that I am familiar with, but it seems that you are running into one of the following (or similar:
Your guest root file system is not where you expect it to be. If you haven't already, check the grub.conf in the guest.
OR
You are missing modules in your ramdisk that are needed by your guest (in which case you would need to use mkinitrd to rebuild your xen initrd and make sure you include the necessary modules)
OR
Some combination of the above, you should be able to pretty closely mirror the kernel command line with the combination of kernel, root, and extra parameters.
The only tricky part would be to rebuild with any missing modules.
Hope that helps, Cheers, Todd
On Thu, Oct 30, 2008 at 7:35 PM, Kenneth Tanzer ktanzer@desc.org wrote:
Thanks, I'll try to check into this. One quick question, though, which I forgot to ask. When I installed the xen kernel in the guest, it set up this line in grub.conf:
kernel /xen.gz-2.6.18-92.1.13.el5
Which we haven't referenced anywhere in the config file. Do I need it? Is that the actual kernel to specify, and if so, how do I specify the vmlinuz file that is referenced as a "module" in the grub config?
The xen.gz is the hypervisor, the guest must also have a Xen setup in it.
I am guessing that you don't want to run xen within a xen guest, so don't use that :)
Todd
I'm trying to get a USB printer which works on the host (CentOS 5.2 x86_64) to work on a guest (also CentOS 5.2 x86_64).
I'm reading Running Xen at the moment, it is a great starting point that brings together all manner of information in one coherent place, but I'm finding the section on Device Virtualisation a bit unclear (or lacking detail).
As I read it, to create a USB device for a HVM machine I need
device_model = "/usr/lib64/xen/bin/qemu-dm" usb = 1
in the guest's config file. There is not much more specified in the text than this.
I've done this but without success. When I go to add a device to the guest in the GUI tool, I still don't get an option for any kind of USB device.
What have I missed?
Hi Mick,
On Thu, Oct 30, 2008 at 9:05 PM, mick@mjhall.org wrote:
I'm trying to get a USB printer which works on the host (CentOS 5.2 x86_64) to work on a guest (also CentOS 5.2 x86_64).
I'm reading Running Xen at the moment, it is a great starting point that brings together all manner of information in one coherent place, but I'm finding the section on Device Virtualisation a bit unclear (or lacking detail).
Thanks for the feedback.
As I read it, to create a USB device for a HVM machine I need
device_model = "/usr/lib64/xen/bin/qemu-dm" usb = 1
in the guest's config file. There is not much more specified in the text than this.
I've done this but without success. When I go to add a device to the guest in the GUI tool, I still don't get an option for any kind of USB device.
What GUI tool are you trying to use here?
What have I missed?
Take a look here (with a closer look at the usbdevice option) http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/user.html#SECTIO...
Also see some more details and commentary here: http://www.olivetalks.com/2008/02/03/usb-forwarding-on-xen-it-just-does-not-...
It seems that some devices don't always work out of the box, but xen-users or xen-devel may be of help if you get to the point of trying to debug it further.
Thanks again for the comments on the book, if you haven't already, please consider joining the mailing list for the book. It is very low traffic, but the suggestions such as the one above as improvement to future editions of the book are always welcome. The link is: http://runningxen.com/mailman/listinfo/readers_runningxen.com
Cheers, Todd
I am not seeing the errors in the red hat based boot that I am familiar with,
As I understand it, this Asterisk disk I have is built on Centos 5.2, so I'm assuming Asterisk=CentOS=Redhat, at least for this purpose.
it seems that you are running into one of the following (or similar:
Your guest root file system is not where you expect it to be. If you haven't already, check the grub.conf in the guest.
Here's my grub file:
title CentOS (2.6.18-92.1.13.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-92.1.13.el5 module /vmlinuz-2.6.18-92.1.13.el5xen ro root=/dev/VolGroup00/LogVol00 module /initrd-2.6.18-92.1.13.el5xen.img
Here's the corresponding xen entries:
kernel="/boot/vmlinuz-2.6.18-92.1.13.el5xen" ramdisk="/boot/initrd-2.6.18-92.1.13.el5xen.img" root="/dev/VolGroup00/LogVol00" extra="ro"
They seem to match to me. Sanity check: the "root" in the xen config is specified as seen by the guest, right?
OR
You are missing modules in your ramdisk that are needed by your guest (in which case you would need to use mkinitrd to rebuild your xen initrd and make sure you include the necessary modules)
I can boot the xen kernel as a fully-virtualized machine (with the grub.conf mentioned above). Is that a fair indicator that all the required modules exist? If not, any idea how to figure out what might be missing?
Ken
Todd Deshane wrote:
On Thu, Oct 30, 2008 at 7:12 PM, Kenneth Tanzer ktanzer@desc.org wrote:
I tried this a couple of ways. If I add just the kernel file, and not the parameters, like so:
kernel="/boot/vmlinuz-2.6.18-92.1.13.el5xen" ramdisk="/boot/initrd-2.6.18-92.1.13.el5xen.img"
good
It starts booting, but then dies with:
:(
Kernel panic - not syncing: Attempted to kill init!
If I add the "ro root=/dev/VolGroup00/LogVol00" to the kernel line, I either get a kernel not found message (if the parameteres are inside the quotation marks), or an invalid parameter message (if outside the quotes). I tried adding:
root="/dev/VolGroup00/LogVol00"
(with and without a "ro" at the end), and it still boots the kernel but then panics. Which is what I'm starting to do! :)
add the ro and any of kernel parameters to an extra boot parameter example extra="ro"
I am not seeing the errors in the red hat based boot that I am familiar with, but it seems that you are running into one of the following (or similar:
Your guest root file system is not where you expect it to be. If you haven't already, check the grub.conf in the guest.
OR
You are missing modules in your ramdisk that are needed by your guest (in which case you would need to use mkinitrd to rebuild your xen initrd and make sure you include the necessary modules)
OR
Some combination of the above, you should be able to pretty closely mirror the kernel command line with the combination of kernel, root, and extra parameters.
The only tricky part would be to rebuild with any missing modules.
Hope that helps, Cheers, Todd
On Thu, Oct 30, 2008 at 8:04 PM, Kenneth Tanzer ktanzer@desc.org wrote:
I am not seeing the errors in the red hat based boot that I am familiar with,
As I understand it, this Asterisk disk I have is built on Centos 5.2, so I'm assuming Asterisk=CentOS=Redhat, at least for this purpose.
Yeah, I meant Red Hat-based, CentOS, fedora etc. are quite similar
it seems that you are running into one of the following (or similar:
Your guest root file system is not where you expect it to be. If you haven't already, check the grub.conf in the guest.
Here's my grub file:
title CentOS (2.6.18-92.1.13.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-92.1.13.el5 module /vmlinuz-2.6.18-92.1.13.el5xen ro root=/dev/VolGroup00/LogVol00 module /initrd-2.6.18-92.1.13.el5xen.img
Here's the corresponding xen entries:
kernel="/boot/vmlinuz-2.6.18-92.1.13.el5xen" ramdisk="/boot/initrd-2.6.18-92.1.13.el5xen.img" root="/dev/VolGroup00/LogVol00" extra="ro"
They seem to match to me. Sanity check: the "root" in the xen config is specified as seen by the guest, right?
Yes, with the guest disk image.
OR
You are missing modules in your ramdisk that are needed by your guest (in which case you would need to use mkinitrd to rebuild your xen initrd and make sure you include the necessary modules)
I can boot the xen kernel as a fully-virtualized machine (with the grub.conf mentioned above). Is that a fair indicator that all the required modules exist? If not, any idea how to figure out what might be missing?
Actually no, the fully virtual kernel modules in the guest are not used when booting with the kernel and ramdisk options in the xen config.
Some of those more familiar with centos might be able to jump in to help with specific modules, but if I was you I would boot the full virtual guest, do an lsmod and compare the modules, especially the ones to do with disk drivers, lvm, device mappers etc. with the /lib/modules/<xen kernel version>/modules
Simply rebuilding the initrd with a mkinitrd and the right modules included might be all you need. This only the basic idea, I would suggest to take some time to search xen.markmail.org for either error messags or key words that may lead you to some exact instructions of the mkinitrd that will work for your setup.
Hope that helps, Cheers, Todd
What I ended up doing was looking at my working CentOS PV guest, listing all the modules, and finding the ones that were not loaded in my AsteriskNow guest. That seemed to do the trick, and it booted. (Once I realized that the initrd file had to be in /boot on the _host_, not the guest!)
Unfortunately, as it turns out, there are then a bunch of additional Asterisk modules that I would need to build for the xen kernel, and I didn't have any luck finding the source, so I think I might give up on this for a while.
Thanks very much for your help!
Ken
p.s., I felt like I spent a bunch of time scratching my head on this stuff because I couldn't find good, clear documentation. Is there such documentation to be found somewhere, or is it just lacking at this point?
p.p.s., In case it's useful for others, this is the mkinitrd command I used within the guest, and then copied the initrd to /boot on the host:
mkinitrd --with=i2c_dev --with=ip6table_filter --with=ip6_tables --with=ip6t_REJECT --with=ip_conntrack --with=ip_conntrack_netbios_ns --with=iptable_filter --with=ip_tables --with=ipt_REJECT --with=nfnetlink --with=xenblk --with=xennet --with=x_tables --with=xt_state --with=xt_tcpudp /boot/initrd-2.6.18-92.1.13.el5xen.img.new 2.6.18-92.1.13.el5xen
Todd Deshane wrote:
On Thu, Oct 30, 2008 at 8:04 PM, Kenneth Tanzer ktanzer@desc.org wrote:
I am not seeing the errors in the red hat based boot that I am familiar with,
As I understand it, this Asterisk disk I have is built on Centos 5.2, so I'm assuming Asterisk=CentOS=Redhat, at least for this purpose.
Yeah, I meant Red Hat-based, CentOS, fedora etc. are quite similar
it seems that you are running into one of the following (or similar:
Your guest root file system is not where you expect it to be. If you haven't already, check the grub.conf in the guest.
Here's my grub file:
title CentOS (2.6.18-92.1.13.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-92.1.13.el5 module /vmlinuz-2.6.18-92.1.13.el5xen ro root=/dev/VolGroup00/LogVol00 module /initrd-2.6.18-92.1.13.el5xen.img
Here's the corresponding xen entries:
kernel="/boot/vmlinuz-2.6.18-92.1.13.el5xen" ramdisk="/boot/initrd-2.6.18-92.1.13.el5xen.img" root="/dev/VolGroup00/LogVol00" extra="ro"
They seem to match to me. Sanity check: the "root" in the xen config is specified as seen by the guest, right?
Yes, with the guest disk image.
OR
You are missing modules in your ramdisk that are needed by your guest (in which case you would need to use mkinitrd to rebuild your xen initrd and make sure you include the necessary modules)
I can boot the xen kernel as a fully-virtualized machine (with the grub.conf mentioned above). Is that a fair indicator that all the required modules exist? If not, any idea how to figure out what might be missing?
Actually no, the fully virtual kernel modules in the guest are not used when booting with the kernel and ramdisk options in the xen config.
Some of those more familiar with centos might be able to jump in to help with specific modules, but if I was you I would boot the full virtual guest, do an lsmod and compare the modules, especially the ones to do with disk drivers, lvm, device mappers etc. with the /lib/modules/<xen kernel version>/modules
Simply rebuilding the initrd with a mkinitrd and the right modules included might be all you need. This only the basic idea, I would suggest to take some time to search xen.markmail.org for either error messags or key words that may lead you to some exact instructions of the mkinitrd that will work for your setup.
Hope that helps, Cheers, Todd
Kenneth Tanzer wrote:
Unfortunately, as it turns out, there are then a bunch of additional Asterisk modules that I would need to build for the xen kernel, and I didn't have any luck finding the source, so I think I might give up on this for a while.
If you are using paravirtualisation then you can use pygrub instead of booting the kernel directly so that the kernel/initrd files etc are in the guest's storage. The virt-manager will configure pygrub by default when installing a client. You could install a temporary guest using virt-manager and see how it does the config of pygrub.
This thread has some interesting info:
http://lists.xensource.com/archives/html/xen-users/2006-12/msg00902.html
Brett
Thanks. I actually was running pygrub, and I _swear_ that the first time I ran it, it said that the initrd was not found. I then copied it to the host, and it ran. This actually brings me to another question/issue:
It really honestly seems to me that sometimes I was getting inconsistent results, at least vis a vis the _current_ state of configuration files. Also, I've had situations where I've been unable to destory machines from the graphical virt-manager, but able to do so with xm. Yesterday, I had a guest that didn't show up on an xm list, but showed up in the virt-manager, constantly toggling between running and stopped.
My questions are:
1) whether either xm or virt-manager do any kind of caching of settings, so that your current configuration might not actually be what is executed?
2) does going through the xen / grub boot process do any kind of changing or writing of settings? Again, I swear there were times where I got different results on the second boot than the first one.
3) finally, what would account for the differences between virt-manager and xm, and also is there any magic way to destroy an un-destroyable machine without having to reboot your computer?
Thanks all--this seems like a very helpful mailing list!
Ken
Brett Worth wrote:
Kenneth Tanzer wrote:
Unfortunately, as it turns out, there are then a bunch of additional Asterisk modules that I would need to build for the xen kernel, and I didn't have any luck finding the source, so I think I might give up on this for a while.
If you are using paravirtualisation then you can use pygrub instead of booting the kernel directly so that the kernel/initrd files etc are in the guest's storage. The virt-manager will configure pygrub by default when installing a client. You could install a temporary guest using virt-manager and see how it does the config of pygrub.
This thread has some interesting info:
http://lists.xensource.com/archives/html/xen-users/2006-12/msg00902.html
Brett _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Kenneth Tanzer ktanzer@desc.org writes:
It really honestly seems to me that sometimes I was getting inconsistent results, at least vis a vis the _current_ state of configuration files. Also, I've had situations where I've been unable to destory machines from the graphical virt-manager, but able to do so with xm. Yesterday, I had a guest that didn't show up on an xm list, but showed up in the virt-manager, constantly toggling between running and stopped.
xm and the virt-manager tools are different. I would suggest either always using one or always using the other.
My questions are:
- whether either xm or virt-manager do any kind of caching of
settings, so that your current configuration might not actually be what is executed?
libvirt (virt-manager) does use a different config file, and can convert from the xm config format (I don't know if it does this automatically or if it uses the xm config file unchanged or what.) to the libvirt xml format. I would suggest you either use the libvirt/virt-manager tools, or the xm tools, but don't switch between them on the same installation, especially for guest startup. It's easy to get confused as to config file locations.
if you want to use the libvirt tools on the command line, the tool you want is virsh.
(personally, I use the xm tools, because I am more interested in Xen than RedHat, though I am currently running Xen on CentOS. I will, in fact, be abandoning the redhat xen kernels on my next servers so I get PVGRUB. )
- does going through the xen / grub boot process do any kind of
changing or writing of settings? Again, I swear there were times where I got different results on the second boot than the first one.
Pygrub is read-only, as far as I know. It should not change your config file or guest disk.
- finally, what would account for the differences between
virt-manager and xm, and also is there any magic way to destroy an un-destroyable machine without having to reboot your computer?
'xm destroy' has worked fine for me for some time. I think it's been more than a year since I've been unable to kill a zombie. Are you running a recent kernel?
On Fri, Oct 31, 2008 at 7:17 PM, Kenneth Tanzer ktanzer@desc.org wrote:
What I ended up doing was looking at my working CentOS PV guest, listing all the modules, and finding the ones that were not loaded in my AsteriskNow guest. That seemed to do the trick, and it booted. (Once I realized that the initrd file had to be in /boot on the _host_, not the guest!)
Unfortunately, as it turns out, there are then a bunch of additional Asterisk modules that I would need to build for the xen kernel, and I didn't have any luck finding the source, so I think I might give up on this for a while.
Thanks very much for your help!
Ken
p.s., I felt like I spent a bunch of time scratching my head on this stuff because I couldn't find good, clear documentation. Is there such documentation to be found somewhere, or is it just lacking at this point?
There really isn't good, clear, complete documentation on all of this. It is a bit scattered in READMEs, some on the xen wiki, some very good blog and sides site, there are a number of Xen books (I am a co-author on one called Running Xen), but what really needs to happen is the Xen wiki needs to be cleaned up a lot and kept up to date. Xen.org actually has documentation/the wiki in its plans to be worked on soon. I hope that that will help the documentation situation get a lot better.
See our book's website (runningxen.com) for a lot of links and resources.
Cheers, Todd
p.p.s., In case it's useful for others, this is the mkinitrd command I used within the guest, and then copied the initrd to /boot on the host:
mkinitrd --with=i2c_dev --with=ip6table_filter --with=ip6_tables --with=ip6t_REJECT --with=ip_conntrack --with=ip_conntrack_netbios_ns --with=iptable_filter --with=ip_tables --with=ipt_REJECT --with=nfnetlink --with=xenblk --with=xennet --with=x_tables --with=xt_state --with=xt_tcpudp /boot/initrd-2.6.18-92.1.13.el5xen.img.new 2.6.18-92.1.13.el5xen
On Fri, 31 Oct 2008, Todd Deshane wrote:
p.s., I felt like I spent a bunch of time scratching my head on this stuff because I couldn't find good, clear documentation. Is there such documentation to be found somewhere, or is it just lacking at this point?
on one called Running Xen), but what really needs to happen is the Xen wiki needs to be cleaned up a lot and kept up to date. ...
Isn't this basically the skew problem with any documentation which is not integrated with a release. A secondary source necessarily lags the primary released code; a wiki, or other webpage can linger 'forever', particularly if cross-linked or mirrored
(I was unpleasantly surprised to find content that has 'rolled off' planet.centos.org, being mirrored by two seemingly separate unaffiliated third parties in a search earlier tonight -- static content that _will_ last forever, and be 'uncorrectable' - sadly it appeared in the google results before the primary source article I was seeking)
I think wiki's (websites, secondary sources in general) seem to degenerate into 'write and abandon' because the 'payback' for keeping them up to date is less than the satisfaction of moving on to new development, once the old 'itch' is satisfied.
-- Russ herrold
Kenneth Tanzer wrote:
p.p.s., In case it's useful for others, this is the mkinitrd command I used within the guest, and then copied the initrd to /boot on the host:
mkinitrd --with=i2c_dev --with=ip6table_filter --with=ip6_tables --with=ip6t_REJECT --with=ip_conntrack --with=ip_conntrack_netbios_ns --with=iptable_filter --with=ip_tables --with=ipt_REJECT --with=nfnetlink --with=xenblk --with=xennet --with=x_tables --with=xt_state --with=xt_tcpudp /boot/initrd-2.6.18-92.1.13.el5xen.img.new 2.6.18-92.1.13.el5xen
Do you really need more than xennet and xenblk in the initrd? You only need to get the machine running with it. The remaining modules whould be loaded from /lib/modules.