[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Xen DomU Communication Problems



Thank you, that helped at least part of the problem.
I no longer get an error message when trying to create the domU, and it appears that the device is getting passed in. However, dmesg on the domU gives me

"PCI: Enabling device 0000:00:00.0 (0000 -> 0003)
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

Unable to handle kernel NULL pointer dereference at 0000000000000078 RIP:
 [<ffffffff880043a2>] :scsi_mod:scsi_calculate_bounce_limit+0x15/0x49
PGD 20750067 PUD 20751067 PMD 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in: aic7xxx scsi_transport_spi scsi_mod
Pid: 510, comm: modprobe Not tainted 2.6.18-6-xen-amd64 #1
RIP: e030:[<ffffffff880043a2>] [<ffffffff880043a2>] :scsi_mod:scsi_calculate_bounce_limit+0x15/0x49"

.... followed by a call trace, etc. The device does not show up in /dev.

I will keep at it.

~Sarah

Todd Deshane wrote:

Hi,

On Feb 19, 2008 11:03 AM, Sarah Scheibe <scheibe@xxxxxxxxxxxx <mailto:scheibe@xxxxxxxxxxxx>> wrote:

    Hi Again,

    I have been attempting to pass the tape drive through to my domU, but am
    having no luck. I added pciback.hide(03:02.0) to my modules line in
    menu.lst, and added "pci = [ '03:02.0' ]. I've rebooted the dom0,
    and now
    when I try to start the domU I get the following message:



I think you have to fix your pciback.hide line to be:

pciback.hde=(03:02.0)

You may also want to add pciback.permissive to that line.
Todd



    "Error: pci: PCI Backend does not own device 0000:03:02.0
    See the pciback.hide kernel command-line parameter or
    bind your slot/device to the PCI backend using sysfs"

    Any hints would be appreciated.

    Thanks!
    Sarah

    Sarah Scheibe wrote:
     > Stephan,
     >
     > Thank you for your response.
     >
     > I agree that the ideal solution is to get the tape drive to the domU.
     > However, I've tried pci passthrough in the past several times and
    so far
     > have had absolutely no luck. I'm very open to suggestions as to how I
     > can make this tape drive accessible to the domU.
     >
     > ~Sarah
     >
     > Stephan Seitz wrote:
     >>> Good Morning,
     >> Depends ;)
     >>
     >>
     >>> I have a Xen machine with a domU that provides backups for our
     >>> department. The domU is running Bacula. The dom0 hosts the bacula
     >>> storage daemon which communicates with the tape device connected to
     >>> the dom0.
     >>>
     >>> I recently moved our file server onto this machine under this dom0.
     >>> Prior to this move, backups worked fine on the file server as
    well as
     >>> everything else. However, post move, whenever I attempt to back up
     >>> the file server I lose network on both domUs (the backup server and
     >>> the file server) until I either kill the bacula storage daemon
    on the
     >>> dom0 or console in to the backup server and kill bacula from there.
     >>> After that, networking returns to both domUs immediately.
     >>
     >> I've always noticed problems when using load-intensive apps directly
     >> on dom0.
     >>
     >> If you're lucky, you've got enough cores and could try to
    cpu-pin dom0
     >> and
     >> domU's to different, dedicated cores. If your domU's are HVM,
    you should
     >> check if the netfront modules are loaded and used.
     >> Anyway, I would prefer to look on how to get the tape drive
    available in
     >> your bacula domU and leave dom0 for managing stuff.
     >>
     >>
     >>> These two domUs are the only domUs on this machine. Networking is
     >>> never affected on the dom0, just the domUs. Backing up all other
     >>> servers still works just fine.
     >>>
     >>> I am frankly stumped. I am running a debian distribution, and have
     >>> tried upgrading the kernel to version 2.6.18 and upgrading to the
     >>> most recent Xen hypervisor *MailScanner warning: numerical
    links are often malicious:* 3.0.3.1 <http://3.0.3.1> revision, all
    without luck in
     >>> solving the problem.
     >>>
     >>> If anyone has any ideas or has run into this problem and found a
     >>> solution, your advice would be greatly appreciated.
     >>>
     >>> Sincerely,
     >>> Sarah
     >>>
     >>> _______________________________________________
     >>> Xen-users mailing list
     >>> Xen-users@xxxxxxxxxxxxxxxxxxx
    <mailto:Xen-users@xxxxxxxxxxxxxxxxxxx>
     >>> http://lists.xensource.com/xen-users
     >>
     >>
     >

    _______________________________________________
    Xen-users mailing list
    Xen-users@xxxxxxxxxxxxxxxxxxx <mailto:Xen-users@xxxxxxxxxxxxxxxxxxx>
    http://lists.xensource.com/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.