[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-users] pvhvm on debian
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
|
