hello, I know this not quite a xen problem but im sure a fair number of people are using debian for their dom0 and maybe have some insight into this. I have a large number of dom0''s running squeeze and for a long time i was hoping for pvhvm to make into the official debian xen packages and recently during some periodic updates I noticed pvhvm working after a kernel package update. Now I have been testing wheezy to get familiar with migrating to xl toolstack and I''ve noticed that on my fully up to date wheezy system, pvhvm doesnt appear to work. At first I thought the kernel of my test domU maybe did not have pvhvm drivers or something was not picking it up. So I migrated (not live) a domU with working pvhvm drivers from a squeeze dom0 and on wheezy the pvhvm drivers dont load despite the xen_platform_pci=1 being in the domU config and lspci showing the identical output for the platform pci device as it does on squeeze. Any ideas if somehow this is just missed in wheezy packaging or if theres something new that I''m missing that is making it not work? I hope we would have working pvhvm for wheezy its great. Thanks chris _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Fri, 2012-08-24 at 16:43 +0100, chris wrote:> hello, > > > I know this not quite a xen problem but im sure a fair number of > people are using debian for their dom0 and maybe have some insight > into this. > > > I have a large number of dom0''s running squeeze and for a long time i > was hoping for pvhvm to make into the official debian xen packages and > recently during some periodic updates I noticed pvhvm working after a > kernel package update.You mean a dom0 kernel package update? As opposed to guest I mean. What versions of xen+kernel do you have in dom0? and which kernel in the guest? (Knowing the working/non-working version of whichever one changed when the breakage occurred would be useful too) I''ve just done a squeeze domU install on a wheezy dom0 which was freshly installed this morning and pvhvm appears to be working ok. Are you able to capture a guest console log, there may be some hints in there. http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs together with serial=''pty'' in your guest config and config=ttyS0,115200n8 on your guest command line might help. What do your guest configurations look like?> Now I have been testing wheezy to get familiar with migrating to xl > toolstack and I''ve noticed that on my fully up to date wheezy system, > pvhvm doesnt appear to work. At first I thought the kernel of my > test domU maybe did not have pvhvm drivers or something was not > picking it up. So I migrated (not live) a domU with working pvhvm > drivers from a squeeze dom0 and on wheezy the pvhvm drivers dont load > despite the xen_platform_pci=1 being in the domU config and lspci > showing the identical output for the platform pci device as it does on > squeeze. > > > Any ideas if somehow this is just missed in wheezy packaging or if > theres something new that I''m missing that is making it not work? I > hope we would have working pvhvm for wheezy its great. > > > Thanks > chris > >
the issue seems to be with wheezy not squeeze im just trying to figure out why with wheezy with newer versions of everything pvhvm is not working. on my wheezy system i have: ii libxen-4.1 4.1.3-1 amd64 Public libs for Xen ii libxenstore3.0 4.1.3-1 amd64 Xenstore communications library for Xen ii xen-hypervisor-4.1-amd64 4.1.3-1 amd64 Xen Hypervisor on AMD64 ii xen-system-amd64 4.1.3-1 amd64 Xen System on AMD64 (meta-package) ii xen-tools 4.3.1-1 all Tools to manage Xen virtual servers ii xen-utils-4.1 4.1.3-1 amd64 XEN administrative tools ii xen-utils-common 4.1.3-1 all Xen administrative tools - common files ii xenstore-utils 4.1.3-1 amd64 Xenstore utilities for Xen and in domU''s I compared the lspci of the xen platform pci device to the lspci output from a working pvhvm domU that resides on a squeeze dom0. so my guess is that its related to hypervisor? thanks chris On Tue, Aug 28, 2012 at 10:39 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Fri, 2012-08-24 at 16:43 +0100, chris wrote: > > hello, > > > > > > I know this not quite a xen problem but im sure a fair number of > > people are using debian for their dom0 and maybe have some insight > > into this. > > > > > > I have a large number of dom0''s running squeeze and for a long time i > > was hoping for pvhvm to make into the official debian xen packages and > > recently during some periodic updates I noticed pvhvm working after a > > kernel package update. > > You mean a dom0 kernel package update? As opposed to guest I mean. > > What versions of xen+kernel do you have in dom0? and which kernel in the > guest? (Knowing the working/non-working version of whichever one changed > when the breakage occurred would be useful too) > > I''ve just done a squeeze domU install on a wheezy dom0 which was freshly > installed this morning and pvhvm appears to be working ok. > > Are you able to capture a guest console log, there may be some hints in > there. > http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs > together with serial=''pty'' in your guest config and > config=ttyS0,115200n8 on your guest command line might help. > > What do your guest configurations look like? > > > Now I have been testing wheezy to get familiar with migrating to xl > > toolstack and I''ve noticed that on my fully up to date wheezy system, > > pvhvm doesnt appear to work. At first I thought the kernel of my > > test domU maybe did not have pvhvm drivers or something was not > > picking it up. So I migrated (not live) a domU with working pvhvm > > drivers from a squeeze dom0 and on wheezy the pvhvm drivers dont load > > despite the xen_platform_pci=1 being in the domU config and lspci > > showing the identical output for the platform pci device as it does on > > squeeze. > > > > > > Any ideas if somehow this is just missed in wheezy packaging or if > > theres something new that I''m missing that is making it not work? I > > hope we would have working pvhvm for wheezy its great. > > > > > > Thanks > > chris > > > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Tue, 2012-08-28 at 18:52 +0100, chris wrote:> the issue seems to be with wheezy not squeeze im just trying to figure > out why with wheezy with newer versions of everything pvhvm is not > working.I upgraded my test Squeeze VM to Wheezy and PVHVM continued working (this is on a fresh Wheezy dom0).> and in domU''s I compared the lspci of the xen platform pci device to > the lspci output from a working pvhvm domU that resides on a squeeze > dom0.And they were identical?> so my guess is that its related to hypervisor?I don''t think we have enough evidence to decide one way or the other. Can you provide the logs and guest configurations which I asked for please. Ian.
Hi Ian, Finally got a chance to play with this again. Working box (squeeze dom0, centos domU) --- dom0 (squeeze) --- root@cyrax:~# dpkg -l | grep xen ii libxenstore3.0 4.0.1-4 Xenstore communications library for Xen ii linux-image-2.6.32-5-xen-amd64 2.6.32-45 Linux 2.6.32 for 64-bit PCs, Xen dom0 support ii xen-hypervisor-4.0-amd64 4.0.1-4 The Xen Hypervisor on AMD64 ii xen-linux-system-2.6-xen-amd64 2.6.32+29 Xen system with Linux 2.6 for 64-bit PCs (meta-package) ii xen-linux-system-2.6.32-5-xen-amd64 2.6.32-45 Xen system with Linux 2.6.32 on 64-bit PCs (meta-package) ii xen-qemu-dm-4.0 4.0.1-2+squeeze1 Xen Qemu Device Model virtual machine hardware emulator ii xen-utils-4.0 4.0.1-4 XEN administrative tools ii xen-utils-common 4.0.0-1 XEN administrative tools - common files ii xenstore-utils 4.0.1-4 Xenstore utilities for Xen root@cyrax:~# uname -a Linux cyrax 2.6.32-5-xen-amd64 #1 SMP Sun May 6 08:57:29 UTC 2012 x86_64 GNU/Linux working domU (centos) [root@sektor ~]# cat /etc/redhat-release CentOS release 5.5 (Final) [root@sektor ~]# uname -a Linux sektor 2.6.18-194.3.1.el5 #1 SMP Thu May 13 13:08:30 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [root@sektor ~]# lspci | grep Xen 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01) [root@sektor ~]# lsmod | grep xen xen_vnif 58817 0 [permanent] xen_vbd 50345 0 xen_balloon 45641 1 xen_vnif,[permanent] xen_platform_pci 117741 3 xen_vnif,xen_vbd,xen_balloon,[permanent] As you can see above the platform pci device shows in lspci and you can see in lsmod that the pv interfaces are being detected and used New box (wheezy, nonworking) root@barium:~# dpkg -l | grep xen ii libxen-4.1 4.1.3-1 amd64 Public libs for Xen ii libxenstore3.0 4.1.3-1 amd64 Xenstore communications library for Xen ii xen-hypervisor-4.1-amd64 4.1.3-1 amd64 Xen Hypervisor on AMD64 ii xen-system-amd64 4.1.3-1 amd64 Xen System on AMD64 (meta-package) ii xen-utils-4.1 4.1.3-1 amd64 XEN administrative tools ii xen-utils-common 4.1.3-1 all Xen administrative tools - common files ii xenstore-utils 4.1.3-1 amd64 Xenstore utilities for Xen root@barium:~# uname -a Linux barium 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux domU (centos) [root@baraka ~]# cat /etc/redhat-release CentOS release 5.5 (Final) [root@baraka ~]# uname -a Linux baraka 2.6.18-194.3.1.el5 #1 SMP Thu May 13 13:08:30 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [root@baraka ~]# lspci | grep Xen 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01) [root@baraka ~]# lsmod | grep xen xen_platform_pci 117741 0 [permanent] 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 I''ve attached the configs and logs that you asked for 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. thanks chris On Wed, Aug 29, 2012 at 4:41 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Tue, 2012-08-28 at 18:52 +0100, chris wrote: > > the issue seems to be with wheezy not squeeze im just trying to figure > > out why with wheezy with newer versions of everything pvhvm is not > > working. > > I upgraded my test Squeeze VM to Wheezy and PVHVM continued working > (this is on a fresh Wheezy dom0). > > > and in domU''s I compared the lspci of the xen platform pci device to > > the lspci output from a working pvhvm domU that resides on a squeeze > > dom0. > > And they were identical? > > > so my guess is that its related to hypervisor? > > I don''t think we have enough evidence to decide one way or the other. > > Can you provide the logs and guest configurations which I asked for > please. > > Ian. > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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 lspciIs 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 forI 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.
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@citrix.com>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@lists.xen.org http://lists.xen.org/xen-users
So I found the drivers, are you saying these are not pvhvm drivers? # 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 [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@gmail.com> 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@citrix.com>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@lists.xen.org http://lists.xen.org/xen-users
On Mon, 2012-09-10 at 13:00 +0100, chris wrote:> 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=1I''m a little bit annoyed by this since neither of the two VM configurations you previously sent, one of which you claimed represented the broken VM, had this in it. If it had I would have immediately mentioned it since it was one of the things I considered. Please, when you ask for help on a list and expect people to spend their valuable time helping you always try and provide correct, consistent and above all *truthful* information. By providing such incorrect information you have caused me to waste my time trying to provide help based on a false understanding of your configuration. Ian.
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 packageI 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@gmail.com> 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@citrix.com> 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. > > > > > >