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

Re: [Xen-users] Xen DomU Communication Problems


  • To: "Sarah Scheibe" <scheibe@xxxxxxxxxxxx>
  • From: "Todd Deshane" <deshantm@xxxxxxxxx>
  • Date: Tue, 19 Feb 2008 11:06:46 -0500
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 19 Feb 2008 08:07:20 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=wP3Gm5swzbrpKXnavSXsIGJbjywC0QJxVdp7XDJuiM1z41/V6Hq/W0N+i5dp+ftiTL6PUd06wDccJCYBmycRrRkxL8bsVI34YFf8g5pHngmk37XTCvHX3NLM4D1S2kDbmOK62ut4cvjF+ZI1C6dcm/Mpm0yrWYAEEQOjn5Ic14Q=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>


Hi,

On Feb 19, 2008 11:03 AM, Sarah Scheibe <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 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
>>> http://lists.xensource.com/xen-users
>>
>>
>

_______________________________________________
Xen-users mailing list
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®.