[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] pvhvm on debian
On Mon, 2012-09-10 at 13:13 +0100, chris wrote: > So I found the drivers, are you saying these are not pvhvm drivers? Strictly speaking no, these are the 3rd party modules irefered to earlier. > > > # find /lib/modules/2.6.18-194.3.1.el5/ | grep xen > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/net/netxen > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/net/netxen/netxen_nic.ko > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/platform-pci > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/platform-pci/xen-platform-pci.ko > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/netfront > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/netfront/xen-vnif.ko > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/blkfront > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/blkfront/xen-vbd.ko > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/balloon > /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/xenpv_hvm/balloon/xen-balloon.ko > > > I can't find any packages that look like a seperate package for the > drivers only, I have a feeling its integrated with the kernel package I suspect RH have simply incorporated them into their kernel build directly for convenience (they also incorporate the hypervisor into the kenrel package) > [root@baraka ~]# rpm -qa | grep -i xen > [root@baraka ~]# rpm -qa | grep -i pv > iptables-ipv6-1.3.5-5.3.el5_4.1 > [root@baraka ~]# rpm -qa | grep -i hvm > > > Any idea how can I track down which drivers it is being used? > > > chris > > On Mon, Sep 10, 2012 at 8:00 AM, chris <tknchris@xxxxxxxxx> wrote: > Ian, > > > You are awesome! I figured it out by looking at console logs. > The nonworking domU had this in its console: > > > Detected Xen platform device but not Xen VMM? (sig Microsoft > Hv, eax 40000006) > xen-platform-pci: probe of 0000:00:03.0 failed with error -22 > > > The mention of hyperv reminded me back when I had to add > viridian=1 in order to avoid bluescreens in certain newer > versions of windows, and sure enough the nonworking centos > domU had viridian=1 > After removing/disabling this option the Xen pv drivers come > up properly. > > > Just for clarification on the centos side though, in regard to > your guest about if I installed any additional standalone PV > drivers, the answer is no. The only reason I referred to it as > PVHVM was I assumed that maybe pvhvm had become mainline and > the kernel centos was using had these features now. > > > Anyway its all working now and its good to know it works in > wheezy and I can continue to move towards that in production. > > > Thanks for all your time and help > chris > > On Mon, Sep 10, 2012 at 5:02 AM, Ian Campbell > <Ian.Campbell@xxxxxxxxxx> wrote: > On Sun, 2012-09-09 at 21:23 +0100, chris wrote: > > So as you can see the domU is identical kernel in > both cases however > > when the domU is running on the wheezy dom0 even > despite that the > > platform pci device appears exactly the same in > lspci > > > Is the contents of the initrd identical in both cases? > Specifically do > they both contain the same set of kernel modules? > > Note that CentOS does not strictly speaking contain > "PVHVM", which is a > more recent upstream development. What you have here > is the PV drivers > add on driver from the unmodified_drivers. Did these > drivers ship with > CentOS or did you get them from elsewhere? Do you have > the source for > them? > > The difference is that PVHVM is part of the kernel > itself and are > tightly integrated, while the unmodified_drivers are a > set of drivers > used as an "add-on" pack for various existing OSes > (similar in principal > to how e.g. the Windows drivers are supplied for > Windows). The main > differences in practice will be at setup and > initialisation time, which > of course is where things appear to be going wrong for > you. > > I think this highlights why it is important to always > give all the > precise details in a bug report, this is the first > time CentOS has been > mentioned at all so I think I can be forgiven for > assuming you were > running Debian PVHVM in the guest too (which is what I > spent time > reproducing). > > > I've attached the configs and logs that you asked > for > > > I asked for guest console logs. The guest console logs > are where the > guest decisions about PVHVM drivers will be logged, if > anywhere. > > sektor-qemu.txt and baraka-qemu.txt are identical, but > they both contain > references to "baraka" which should surely be "sektor" > in the at least > one place (e.g. the disk path) for that VM. > > Your vm configs show the name has changed in the disk > path so I don't > see why it isn't different in the logs too. re you > sure these are the > actual logs from real runs of the guest? > > > Any ideas how to debug further? The difference > between the working > > scenario and nonworking is the dom0 distro (squeeze > vs wheezy), dom0 > > kernel and dom0 hypervisor > > Testing with both scenario's was done with the exact > same domU so I > > cant see how it could be a domU issue. > > > Comparing your guest configs shows that they aren't > actual quite > identical though, for reasons other than the different > names. > > One has apic=1 then other doesn't, I'm not sure what > the default is, and > also one names its vif with vifname and the other > doesn't. > > Perhaps these don't matter but it suggests that you > need to double check > your assumption that these VMs are "identical". > > Ian. > > > > > > _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |