Re: [CentOS-virt] What is the purpose setting console=hvc0 in the dom0 grub config?
On Wed, May 17, 2017 at 08:37:13AM -0700, Jerry wrote: > On Wed, May 17, 2017 at 8:25 AM, Konrad Rzeszutek Wilk < > konrad.w...@oracle.com> wrote: > > > > This is what's defined in /etc/default/grub following the install of the > > > Xen: > > > > > > GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M cpuinfo > > com1=115200,8n1 > > > console=com1,tty loglvl=all guest_loglvl=all" > > > GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 earlyprintk=xen > > > nomodeset" > > > > > > I didn't set these myself, this is what the xen package (or one of its > > > dependencies) is doing. > > > > > > I'm still not clear on why hvc0 is needed, or why it's being set, but > > what > > > I do know for sure is it was causing the boot messages to be suppressed. > > > > So the hvc0 is to use the PV console driver to pipe all the messages to > > the Xen one. > > > > And Xen is configured to use the serial console (com1=115200,8n1). > > > > Which means that all you Linux bootup info should be piped to that. > > > > > So how would I properly configure it to still write to tty without > disabling hvc0? Perhaps something like this? > > GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0,tty earlyprintk=xen > nomodeset" console=hvc0 console=tty And that should do it. > > Looks like I have some learning to do. Do you happen to know of a good > article explaining how console redirection works? You add the 'console' and it will pipe date to it. If you add more, then it will duplicate it to those. > > > > But Linux is pretty quiet unless you add 'loglevel=10' or 'debug' on the > > Linux command line. > > > > > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > https://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] What is the purpose setting console=hvc0 in the dom0 grub config?
> This is what's defined in /etc/default/grub following the install of the > Xen: > > GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 > console=com1,tty loglvl=all guest_loglvl=all" > GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 earlyprintk=xen > nomodeset" > > I didn't set these myself, this is what the xen package (or one of its > dependencies) is doing. > > I'm still not clear on why hvc0 is needed, or why it's being set, but what > I do know for sure is it was causing the boot messages to be suppressed. So the hvc0 is to use the PV console driver to pipe all the messages to the Xen one. And Xen is configured to use the serial console (com1=115200,8n1). Which means that all you Linux bootup info should be piped to that. But Linux is pretty quiet unless you add 'loglevel=10' or 'debug' on the Linux command line. > > Thanks, > Jerry > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > https://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] NIC Stability Problems Under Xen 4.4 / CentOS 6 / Linux 3.18
On Tue, Jan 24, 2017 at 09:29:39PM +0800, -=X.L.O.R.D=- wrote: > Kevin Stange, > It can be either kernel or update the NIC driver or firmware of the NIC > card. Hope that helps! > > Xlord > -Original Message- > From: CentOS-virt [mailto:centos-virt-boun...@centos.org] On Behalf Of Kevin > Stange > Sent: Tuesday, January 24, 2017 1:04 AM > To: centos-virt@centos.org > Subject: [CentOS-virt] NIC Stability Problems Under Xen 4.4 / CentOS 6 / > Linux 3.18 > > I have three different types of CentOS 6 Xen 4.4 based hypervisors (by > hardware) that are experiencing stability issues which I haven't been able > to track down. All three types seem to be having issues with NIC and/or > PCIe. In most cases, the issues are unrecoverable and require a hard boot > to resolve. All have Intel NICs. > > Often the systems will remain stable for days or weeks, then suddenly > encounter one of these issues. I have yet to tie the error to any specific > action on the systems and can't reproduce it reliably. > > - Supermicro X8DT3, Dual Xeon E5620, 2x 82575EB NICs, 2x 82576 NICs > > Kernel messages upon failure: > > pcieport :00:03.0: AER: Multiple Corrected error received: id=0018 > pcieport :00:03.0: PCIe Bus Error: severity=Corrected, type=Transaction > Layer, id=0018(Receiver ID) > pcieport :00:03.0: device [8086:340a] error > status/mask=2000/1001 > pcieport :00:03.0:[13] Advisory Non-Fatal > pcieport :00:03.0: Error of this Agent(0018) is reported first > igb :04:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, > id=0400(Receiver ID) > igb :04:00.0: device [8086:10a7] error status/mask=2001/2000 > igb :04:00.0:[ 0] Receiver Error (First) > igb :04:00.1: PCIe Bus Error: severity=Corrected, type=Physical Layer, > id=0401(Receiver ID) > igb :04:00.1: device [8086:10a7] error status/mask=2001/2000 > igb :04:00.1:[ 0] Receiver Error (First) > > This spams to the console continuously until hard booting. > > - Supermicro X9DRD-iF/LF, Dual Xeon E5-2630, 2x I350, 2x 82575EB > > igb :82:00.0: Detected Tx Unit Hang > Tx Queue <1> > TDH <43> > TDT <50> > next_to_use <50> > next_to_clean<43> > buffer_info[next_to_clean] > time_stamp <12e6bc0b6> next_to_watch > jiffies <12e6bc8dc> > desc.status <1c8210> > > This spams to the console continuously until hard booting. > > - Supermicro X9DRT, Dual Xeon E5-2650, 2x I350, 2x 82571EB > > e1000e :04:00.0 eth2: Detected Hardware Unit Hang: > TDH > TDT <33> > next_to_use <33> > next_to_clean > buffer_info[next_to_clean]: > time_stamp <138230862> > next_to_watch > jiffies <138231ac0> > next_to_watch.status <0> > MAC Status <80383> > PHY Status <792d> > PHY 1000BASE-T Status <3c00> > PHY Extended Status<3000> > PCI Status <10> > > This type of system, the NIC automatically recovers and I don't need to > reboot. > > So far I tried using pcie_aspm=off to see that would help, but it appears > that the 3.18 kernel turns off ASPM by default on these due to probing the > BIOS. Stability issues were not resolved by the changes. > > On the latter system type I also turned off all offloading setting. It > appears the stability increased slightly but it didn't fully resolve the > problem. I haven't adjusted offload settings on the first two server types > yet. > > I suspect this problem is related to the 3.18 kernel used by the virt SIG, > as we had these running Xen on CentOS 5's kernel with no issues for years, > and systems of these types used elsewhere in our facility are stable under > CentOS 6's standard kernel. This affects more than one server of each type, > so I don't believe it is a hardware failure, or else it's a hardware design > flaw. > > Has anyone experienced similar issues with this configuration, and if so, > does anyone have tips on how to resolve the issues? Honeslty I would email Intel and see if they can help. This looks like the NIC decides something is wrong, throws off an PCIe error and then resets itself. It could also be an error in the Linux stack which would "eat" an interrupt when migrating interrupts (which was fixed upstream, see below). Are you running irqbalance? Could you try turning it off? Did you have these issues with an earlier kernel? The fix was ff1e22e7a638a0782f54f81a6c9cb139aca2da35 Author: Boris Ostrovsky Date: Fri Mar 18 10:11:07 2016 -0400 xen/events: Mask a moving irq and then there was a fix to this fix: commit f0f393877c71ad227d36705d61d1e4062bc29cf5 Author: Ross Lagerwall Date: Tue May 10 16:11:00 2016 +0100 xen/events: Don't move disabled irqs > > -- > Kevin Stange > Chief Technology Officer > Steadfast | Managed Infrastru
Re: [CentOS-virt] Beta CentOS 7 Xen packages available
On Tue, Sep 08, 2015 at 11:22:58AM -0400, Alvin Starr wrote: > On 09/08/2015 10:58 AM, Konrad Rzeszutek Wilk wrote: > > On Tue, Sep 08, 2015 at 10:50:57AM -0400, Alvin Starr wrote: > >> FIrstly Centos is primarily a RHEL clone. > >> This means that the primary design decisions are to be as RHEL like as > >> possible. > >> After that there are additions and upgrades. > >> > >> Secondly Fedora does not actively support Xen. > > Nonsense. Have you done 'yum install xen' ? > Sorry. I mis-spoke there. > I should have said RedHad does not actively support Xen. > > > >> As a long time Xen and RH/Fedora user I have spent lots of time > >> building/rebuilding broken/missing packages in Fedora. > >> Quite frankly Xen under Fedora is somewhat broken. > > It is? Please open bugs and CC me on them (ketuzs...@darnok.org) > > CPU features/flags are just outright is not there. > I tend to run into the problems as I am trying to use Xen for my > development environment. > I have posted fixes and bugs in the past and will in the future. Excellent! > But Xen/Centos does not have a big dedicated development or a small one > for that matter. > So Xen development will lag a bit. > This is not a criticism but just a fact of life. Please open bugs for these issues. The CPU features/flags is an important feature that needs to be properly addressed in libxl toolstack. Right now it is a bit of a trainwreck. > > > > > >> Libvirt support for KVM is very good because RH pays people to support KVM. > >> Xen under the old config format has reasonable support(possibly 60% of > >> features) but under libxl the support is much worse (possibly 30% of > >> features). > > Please file bugs so we can figure out which ones are missing. > When I fight my way through my current provisioning environment I will > be likely posting more bugs. Fantastic! > I have to admit that I am not the best contributor because often I just > fix the bugs. I would say that is the best contributor! > Partly because being outside the community learning all the nuances of > posting fixes is way more effort than just fixing them. Oh, .. I must be missing something here. Posting fixes seems like an excellent way of removing the issues you had found by them not reappearing in the future? > > > > >> Thirdly RedHat has been active at times to remove Xen support in favour > >> of KVM(Their own virtualization technology). > > Not sure I follow as Fedora does not make this distinction. > As of the last time I checked you could not build a RedHat 7 kernel with > Xen enabled. Odd. I thought you could. The only one missing was the PV framebuffer + intial domain support but the rest were enabled. And that initial domain support was due to them mucking with Kconfig to outright disable it. > The point to be made is that Fedora is not RHEL and Centos is more like > RHEL. > > So comparing Centos to Fedora is like complaining that RHEL should > support all the current Fedora packages/features. > There is a relationship between all of them but they are not the same. Right. > > > > > >> Xen has been driven to some extents by the needs of Citrix and although > >> they have helped others build packages for Fedora and libvirt its a good > >> will effort and its hard to expect Citrix to spend effort on work that > >> may not be in their best corporate interests. > >> > >> > >> > >> > >> On 09/08/2015 09:02 AM, Itamar Reis Peixoto wrote: > >>> > >>>> not fragment to a bunch of different individual people making a bunch of > >>>> different RPM sets that the community does not know who produces, etc. > >>>> > >>> what you're doing its a complete crap, what you said is different from > >>> what you did, why you' (centos virt sig) not contributed to the work > >>> of fedora guys instead of reinventing the wheel ? > >>> > >>> > >>> > >>> ___ > >>> CentOS-virt mailing list > >>> CentOS-virt@centos.org > >>> https://lists.centos.org/mailman/listinfo/centos-virt > >> > >> -- > >> Alvin Starr || voice: (905)513-7688 > >> Netvel Inc. || Cell: (416)806-0133 > >> al...@netvel.net || > >> > >> ___ > >> CentOS-virt mailing list > >> CentOS-virt@centos.org > >> https://lists.centos.org/mailman/listinfo/centos-virt > > ___ > > CentOS-virt mailing list > > CentOS-virt@centos.org > > https://lists.centos.org/mailman/listinfo/centos-virt > > > -- > Alvin Starr || voice: (905)513-7688 > Netvel Inc. || Cell: (416)806-0133 > al...@netvel.net || > > > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > https://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Beta CentOS 7 Xen packages available
On Tue, Sep 08, 2015 at 10:50:57AM -0400, Alvin Starr wrote: > FIrstly Centos is primarily a RHEL clone. > This means that the primary design decisions are to be as RHEL like as > possible. > After that there are additions and upgrades. > > Secondly Fedora does not actively support Xen. Nonsense. Have you done 'yum install xen' ? > As a long time Xen and RH/Fedora user I have spent lots of time > building/rebuilding broken/missing packages in Fedora. > Quite frankly Xen under Fedora is somewhat broken. It is? Please open bugs and CC me on them (ketuzs...@darnok.org) > Libvirt support for KVM is very good because RH pays people to support KVM. > Xen under the old config format has reasonable support(possibly 60% of > features) but under libxl the support is much worse (possibly 30% of > features). Please file bugs so we can figure out which ones are missing. > > Thirdly RedHat has been active at times to remove Xen support in favour > of KVM(Their own virtualization technology). Not sure I follow as Fedora does not make this distinction. > Xen has been driven to some extents by the needs of Citrix and although > they have helped others build packages for Fedora and libvirt its a good > will effort and its hard to expect Citrix to spend effort on work that > may not be in their best corporate interests. > > > > > On 09/08/2015 09:02 AM, Itamar Reis Peixoto wrote: > > > > > > > not fragment to a bunch of different individual people making a bunch of > > > different RPM sets that the community does not know who produces, etc. > > > > > > > what you're doing its a complete crap, what you said is different from > > what you did, why you' (centos virt sig) not contributed to the work > > of fedora guys instead of reinventing the wheel ? > > > > > > > > ___ > > CentOS-virt mailing list > > CentOS-virt@centos.org > > https://lists.centos.org/mailman/listinfo/centos-virt > > > -- > Alvin Starr || voice: (905)513-7688 > Netvel Inc. || Cell: (416)806-0133 > al...@netvel.net || > > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > https://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Centos 6.5 Xen Stock cannot run dom-u PCI: Fatal: - ipmi_si
.snip.. > >> > >> I add the module to initrd, didn't fix the issue. > > > > Can you post the full dmesg output please? Do you see 'xen-blkfront' > > being loaded on it? > The issue is that I cannot connect to the dom-u to get the output, > exist a way for this? You did it before didn't you? ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Centos 6.5 Xen Stock cannot run dom-u PCI: Fatal: - ipmi_si
On Mon, Jun 16, 2014 at 09:09:04PM -0700, Periko Support wrote: > On Mon, Jun 16, 2014 at 11:34 AM, Periko Support > wrote: > > On Mon, Jun 16, 2014 at 11:10 AM, Periko Support > > wrote: > >> On Mon, Jun 16, 2014 at 10:55 AM, Konrad Rzeszutek Wilk > >> wrote: > >>> On Mon, Jun 16, 2014 at 10:51:54AM -0700, Periko Support wrote: > >>>> On Mon, Jun 16, 2014 at 10:46 AM, Periko Support > >>>> wrote: > >>>> > On Mon, Jun 16, 2014 at 10:37 AM, Konrad Rzeszutek Wilk > >>>> > wrote: > >>>> >> On Mon, Jun 16, 2014 at 10:21:45AM -0700, Periko Support wrote: > >>>> >>> --- > >>>> >>> So if I understand you correct - in 5.9 you did not see this, but > >>>> >>> in 6.5 you do? > >>>> >>> -- > >>>> >>> > >>>> >>> Yes, just with centos 6.5 dom-u. > >>>> >>> > >>>> >>> But none of both vm's run. > >>>> >> > >>>> >> Please do not top post. > >>>> >> .. snip.. > >>>> >> .. snip.. > >>>> >>> >> Loading xenblk.ko module > >>>> >>> >> XENBUS: Waiting for devices to initialise: > >>>> >>> >> 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... > >>>> >>> >> XENBUS: Timeout connecting to device: device/vbd/51712 (local > >>>> >>> >> state 3, > >>>> >>> >> remote state 1) > >>>> >>> >> Loading dm-mod.ko module > >>>> >>> >> device-mapper: uevent: version 1.0.3 > >>>> >>> >> device-mapper: ioctl: 4.11.6-ioctl (2011-02-18) initialised: > >>>> >>> >> dm-de...@redhat.com > >>>> >>> >> Loading dm-log.ko module > >>>> >>> >> Loading dm-mirror.ko module > >>>> >>> >> Loading dm-zero.ko module > >>>> >>> >> Loading dm-snapshot.ko module > >>>> >>> >> Loading dm-mem-cache.ko module > >>>> >>> >> Loading dm-region_hash.ko module > >>>> >>> >> Loading dm-message.ko module > >>>> >>> >> Loading dm-raid45.ko module > >>>> >>> >> device-mapper: dm-raid45: initialized v0.2594l > >>>> >>> >> Scanning and configuring dmraid supported devices > >>>> >>> >> Scanning logical volumes > >>>> >>> >> Reading all physical volumes. This may take a while... > >>>> >>> >> No volume groups found > >>>> >>> >> Activating logical volumes > >>>> >>> >> Volume group "VolGroup00" not found > >>>> >>> >> Creating root device. > >>>> >>> >> Mounting root filesystem. > >>>> >>> >> mount: could not find filesystem '/dev/root' > >>>> >>> >> Setting up other filesystems. > >>>> >>> >> Setting up new root fs > >>>> >>> >> setuproot: moving /dev failed: No such file or directory > >>>> >>> >> no fstab.sys, mounting internal defaults > >>>> >>> >> setuproot: error mounting /proc: No such file or directory > >>>> >>> >> setuproot: error mounting /sys: No such file or directory > >>>> >>> >> Switching to new root and running init. > >>>> >>> >> unmounting old /dev > >>>> >>> >> unmounting old /proc > >>>> >>> >> unmounting old /sys > >>>> >>> >> switchroot: mount failed: No such file or directory > >>>> >>> >> Kernel panic - not syncing: Attempted to kill init! > >>>> >> > >>>> >> > >>>
Re: [CentOS-virt] Centos 6.5 Xen Stock cannot run dom-u PCI: Fatal: - ipmi_si
On Mon, Jun 16, 2014 at 10:51:54AM -0700, Periko Support wrote: > On Mon, Jun 16, 2014 at 10:46 AM, Periko Support > wrote: > > On Mon, Jun 16, 2014 at 10:37 AM, Konrad Rzeszutek Wilk > > wrote: > >> On Mon, Jun 16, 2014 at 10:21:45AM -0700, Periko Support wrote: > >>> --- > >>> So if I understand you correct - in 5.9 you did not see this, but > >>> in 6.5 you do? > >>> -- > >>> > >>> Yes, just with centos 6.5 dom-u. > >>> > >>> But none of both vm's run. > >> > >> Please do not top post. > >> .. snip.. > >> .. snip.. > >>> >> Loading xenblk.ko module > >>> >> XENBUS: Waiting for devices to initialise: > >>> >> 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... > >>> >> XENBUS: Timeout connecting to device: device/vbd/51712 (local state 3, > >>> >> remote state 1) > >>> >> Loading dm-mod.ko module > >>> >> device-mapper: uevent: version 1.0.3 > >>> >> device-mapper: ioctl: 4.11.6-ioctl (2011-02-18) initialised: > >>> >> dm-de...@redhat.com > >>> >> Loading dm-log.ko module > >>> >> Loading dm-mirror.ko module > >>> >> Loading dm-zero.ko module > >>> >> Loading dm-snapshot.ko module > >>> >> Loading dm-mem-cache.ko module > >>> >> Loading dm-region_hash.ko module > >>> >> Loading dm-message.ko module > >>> >> Loading dm-raid45.ko module > >>> >> device-mapper: dm-raid45: initialized v0.2594l > >>> >> Scanning and configuring dmraid supported devices > >>> >> Scanning logical volumes > >>> >> Reading all physical volumes. This may take a while... > >>> >> No volume groups found > >>> >> Activating logical volumes > >>> >> Volume group "VolGroup00" not found > >>> >> Creating root device. > >>> >> Mounting root filesystem. > >>> >> mount: could not find filesystem '/dev/root' > >>> >> Setting up other filesystems. > >>> >> Setting up new root fs > >>> >> setuproot: moving /dev failed: No such file or directory > >>> >> no fstab.sys, mounting internal defaults > >>> >> setuproot: error mounting /proc: No such file or directory > >>> >> setuproot: error mounting /sys: No such file or directory > >>> >> Switching to new root and running init. > >>> >> unmounting old /dev > >>> >> unmounting old /proc > >>> >> unmounting old /sys > >>> >> switchroot: mount failed: No such file or directory > >>> >> Kernel panic - not syncing: Attempted to kill init! > >> > >> > >> > >> Ah, that is because you do not have xen-blkfront loaded in your initrd. > >> Somehow it thinks it is called 'xenblk'. If you recreate your initrd > >> (either dracut or mkinitrd) make sure you specify that you want to > >> have the 'xen-blkfront' driver as part of it. The usual parameter > >> is '--add' or such. > >> > >> How did you generate your initrd? > >> ___ > >> CentOS-virt mailing list > >> CentOS-virt@centos.org > >> http://lists.centos.org/mailman/listinfo/centos-virt > > > > No, I'm using the instructions from xen4centos project. Nothing manually. > > > > U mention 2 things: > > > > For centos6 is normal the error, I have to connect to my console using > > other methods and see if centos6 dom-u is running, I will let u know. > > 2nd u mention that we need a module xen-blkfront for centos5 dom-u, > > hope the developers read this and fix this asap. > > > > Thanks. > > If u need info from me, let me know, because this happen in both > servers with different year of manufacturing. > and different centos version 5.9/6.0. Huh? You do not need any developers. You just need to regenerate your initrd to have extra drivers. That is it. > > Thanks for your time!!! > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Centos 6.5 Xen Stock cannot run dom-u PCI: Fatal: - ipmi_si
On Mon, Jun 16, 2014 at 10:21:45AM -0700, Periko Support wrote: > --- > So if I understand you correct - in 5.9 you did not see this, but > in 6.5 you do? > -- > > Yes, just with centos 6.5 dom-u. > > But none of both vm's run. Please do not top post. .. snip.. .. snip.. > >> Loading xenblk.ko module > >> XENBUS: Waiting for devices to initialise: > >> 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... > >> XENBUS: Timeout connecting to device: device/vbd/51712 (local state 3, > >> remote state 1) > >> Loading dm-mod.ko module > >> device-mapper: uevent: version 1.0.3 > >> device-mapper: ioctl: 4.11.6-ioctl (2011-02-18) initialised: > >> dm-de...@redhat.com > >> Loading dm-log.ko module > >> Loading dm-mirror.ko module > >> Loading dm-zero.ko module > >> Loading dm-snapshot.ko module > >> Loading dm-mem-cache.ko module > >> Loading dm-region_hash.ko module > >> Loading dm-message.ko module > >> Loading dm-raid45.ko module > >> device-mapper: dm-raid45: initialized v0.2594l > >> Scanning and configuring dmraid supported devices > >> Scanning logical volumes > >> Reading all physical volumes. This may take a while... > >> No volume groups found > >> Activating logical volumes > >> Volume group "VolGroup00" not found > >> Creating root device. > >> Mounting root filesystem. > >> mount: could not find filesystem '/dev/root' > >> Setting up other filesystems. > >> Setting up new root fs > >> setuproot: moving /dev failed: No such file or directory > >> no fstab.sys, mounting internal defaults > >> setuproot: error mounting /proc: No such file or directory > >> setuproot: error mounting /sys: No such file or directory > >> Switching to new root and running init. > >> unmounting old /dev > >> unmounting old /proc > >> unmounting old /sys > >> switchroot: mount failed: No such file or directory > >> Kernel panic - not syncing: Attempted to kill init! Ah, that is because you do not have xen-blkfront loaded in your initrd. Somehow it thinks it is called 'xenblk'. If you recreate your initrd (either dracut or mkinitrd) make sure you specify that you want to have the 'xen-blkfront' driver as part of it. The usual parameter is '--add' or such. How did you generate your initrd? ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Are xen and centos incompatible?
On Sat, Jun 14, 2014 at 09:07:51AM +0200, lee wrote: > Konrad Rzeszutek Wilk writes: > > >> Hm, xen kinda makes the cpus and their power management invisible, too: > >> > >> > >> root@heimdall:~# xenpm get-cpufreq-para > >> [CPU0] failed to get cpufreq parameter > >> [...] > >> root@heimdall:~# xenpm get-cpufreq-states > >> root@heimdall:~# > >> > >> > >> So I guess it could as well make it so that lspci doesn't show > >> passed-out devices. > > > > I am wondering if you are using an older kernel. The xen-acpi-processor > > driver should be loaded which would give the C and P states to the > > hypervisor. Which in turn would result in those above commands > > providing the right data. > > Linux heimdall 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux > > This is what comes in Debian. Unfortunately, this kernel crashes when > I'm copying data to a domU NFS server over the network :(( I need to > find out how to get some useful information out of it to make a bug > report. > > How do I know whether the xen-acpi-processor driver is loaded or not? lsmod But it looks like v3.4 and later were the kernels that started having this driver. That would explain why it does not exist as you are using 3.2. > > >> BTW, getting some info in dmesg might be nice, like a message saying > >> "xen-pciback: device 06:00.0 can be passed through to guests". We could > > > > You just need to boot with 'debug' - and it should tell you that > > a device is being assigned to another guest (when assigning). Also > > at bootup it will tell you that it is seizinging. > > > > Just do 'dmesg | grep pciback' and you will get it. > > Ok, I enabled debugging. Maybe that also helps to get some more info > about the crashes. > > >> actually see right away if it did work or not. That a device disappears > >> isn't too great as indication, especially not when lspci still lists it. > >> > >> Of course, you could use the command (which I don't remember) to show > >> devices that can be passed through. But that may just work as well as > > > > Such as xl or xm pci-list-assignable? > > yes > > >> 'xenpm get-cpufreq-states': Apparently, there aren't any CPUs ... > > > > See if xen-acpi-processor is loaded or built in. > > Unless it's called "processor", it doesn't seem to exist: > > > root@heimdall:~# lsmod |grep proc > processor 28149 1 acpi_cpufreq > thermal_sys18040 1 processor > root@heimdall:~# grep -i proces /boot/config-3.2.0-4-amd64 |less > > > > root@heimdall:~# find /lib/modules/3.2.0-4-amd64/ -name "*proces*" > /lib/modules/3.2.0-4-amd64/kernel/drivers/acpi/processor.ko > root@heimdall:~# find /lib/modules/3.2.0-4-amd64/ -name "*xen*" > /lib/modules/3.2.0-4-amd64/kernel/drivers/net/xen-netfront.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/net/xen-netback > /lib/modules/3.2.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/net/ethernet/qlogic/netxen > /lib/modules/3.2.0-4-amd64/kernel/drivers/net/ethernet/qlogic/netxen/netxen_nic.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/watchdog/xen_wdt.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen/xen-gntalloc.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen/xen-gntdev.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen/xen-evtchn.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen/xen-pciback > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen/xen-pciback/xen-pciback.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen/xenfs > /lib/modules/3.2.0-4-amd64/kernel/drivers/xen/xenfs/xenfs.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/block/xen-blkfront.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/block/xen-blkback > /lib/modules/3.2.0-4-amd64/kernel/drivers/block/xen-blkback/xen-blkback.ko > /lib/modules/3.2.0-4-amd64/kernel/drivers/pci/xen-pcifront.ko > root@heimdall:~# grep -i proces /boot/config-3.2.0-4-amd64 > CONFIG_BSD_PROCESS_ACCT=y > CONFIG_BSD_PROCESS_ACCT_V3=y > # Processor type and features > CONFIG_ACPI_PROCESSOR=m > CONFIG_ACPI_PROCESSOR_AGGREGATOR=m > # Audio decoders, processors and mixers > root@heimdall:~# grep -i xen /boot/config-3.2.0-4-amd64 >
Re: [CentOS-virt] Centos 6.5 Xen Stock cannot run dom-u PCI: Fatal: - ipmi_si
On Mon, Jun 16, 2014 at 08:42:49AM -0700, Periko Support wrote: > I had a supermicro server SuperServer 1027R-WRF4+ and a old Dell PowerEdge > 2950. > > In both machines I setup centos 6.5, which is running > 3.10.34-11.el6.centos.alt.x86_64. > > I follow Xen4Cen wiki to setup Xen, I had other servers running Centos > 5.x without issues. > > Now, once I build my vm's dom-u centos 6.5/centos 5.9 both x64, I > receive different erros, let me show u the message I receive in my > console for centos 6.5 dum-u. > > xl console oerp-server > PCI: Fatal: No config space access function found > ipmi_si: Could not set up I/O space > ipmi_si: Could not set up I/O space > ipmi_si: Could not set up I/O space > > Something related to ipmi in my server which is enable by default? can > be, now what happen is I try to boot xentos 5.9 x64 dom-u: So if I understand you correct - in 5.9 you did not see this, but in 6.5 you do? And the error is that some driver that looks to be built in is telling you that it can't set up I/O space? Well, that is OK - if it can't it cannot. > > Brought up 1 CPUs > checking if image is initramfs... it is > Grant table initialized > NET: Registered protocol family 16 > Brought up 1 CPUs > PCI: setting up Xen PCI frontend stub > ACPI: Interpreter disabled. > Linux Plug and Play Support v0.97 (c) Adam Belay > pnp: PnP ACPI: disabled > xen_mem: Initialising balloon driver. > usbcore: registered new driver usbfs > usbcore: registered new driver hub > PCI: System does not support PCI > PCI: System does not support PCI > NetLabel: Initializing > NetLabel: domain hash size = 128 > NetLabel: protocols = UNLABELED CIPSOv4 > NetLabel: unlabeled traffic allowed by default > NET: Registered protocol family 2 > IP route cache hash table entries: 65536 (order: 7, 524288 bytes) > TCP established hash table entries: 262144 (order: 10, 4194304 bytes) > TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) > TCP: Hash tables configured (established 262144 bind 65536) > TCP reno registered > audit: initializing netlink socket (disabled) > type=2000 audit(1402907331.494:1): initialized > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > Initializing Cryptographic API > alg: No test for crc32c (crc32c-generic) > ksign: Installing public key data > Loading keyring > - Added public key 691B840A64868995 > - User ID: CentOS (Kernel Module GPG key) > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered (default) > pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > rtc: IRQ 8 is not free. > Non-volatile memory driver v1.2 > Linux agpgart interface v0.101 (c) Dave Jones > brd: module loaded > Xen virtual console successfully installed as xvc0 > Event-channel device installed. > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx > ide-floppy driver 0.99.newide > usbcore: registered new driver hiddev > usbcore: registered new driver usbhid > drivers/usb/input/hid-core.c: v2.6:USB HID core driver > PNP: No PS/2 controller found. Probing ports directly. > i8042.c: No controller found. > mice: PS/2 mouse device common for all mice > md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md: bitmap version 4.39 > TCP bic registered > Initializing IPsec netlink socket > NET: Registered protocol family 1 > NET: Registered protocol family 17 > XENBUS: Device with no driver: device/vbd/51712 > XENBUS: Device with no driver: device/vif/0 > XENBUS: Device with no driver: device/console/0 > Initalizing network drop monitor service > Write protecting the kernel read-only data: 506k > Red Hat nash version 5.1.19.6 starting > Mounting proc filesystem > Mounting sysfs filesystem > Creating /dev > Creating initial device nodes > Setting up hotplug. > Creating block device nodes. > Loading ehci-hcd.ko module > Loading ohci-hcd.ko module > Loading uhci-hcd.ko module > USB Universal Host Controller Interface driver v3.0 > Loading jbd.ko module > Loading ext3.ko module > Loading xenblk.ko module > XENBUS: Waiting for devices to initialise: > 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... > XENBUS: Timeout connecting to device: device/vbd/51712 (local state 3, > remote state 1) > Loading dm-mod.ko module > device-mapper: uevent: version 1.0.3 > device-mapper: ioctl: 4.11.6-ioctl (2011-02-18) initialised: > dm-de...@redhat.com > Loading dm-log.ko module > Loading dm-mirror.ko module > Loading dm-zero.ko module > Loading dm-snapshot.ko module > Loading dm-mem-cache.ko module > Loa
Re: [CentOS-virt] Are xen and centos incompatible?
> Hm, xen kinda makes the cpus and their power management invisible, too: > > > root@heimdall:~# xenpm get-cpufreq-para > [CPU0] failed to get cpufreq parameter > [...] > root@heimdall:~# xenpm get-cpufreq-states > root@heimdall:~# > > > So I guess it could as well make it so that lspci doesn't show > passed-out devices. I am wondering if you are using an older kernel. The xen-acpi-processor driver should be loaded which would give the C and P states to the hypervisor. Which in turn would result in those above commands providing the right data. > > BTW, getting some info in dmesg might be nice, like a message saying > "xen-pciback: device 06:00.0 can be passed through to guests". We could You just need to boot with 'debug' - and it should tell you that a device is being assigned to another guest (when assigning). Also at bootup it will tell you that it is seizinging. Just do 'dmesg | grep pciback' and you will get it. > actually see right away if it did work or not. That a device disappears > isn't too great as indication, especially not when lspci still lists it. > > Of course, you could use the command (which I don't remember) to show > devices that can be passed through. But that may just work as well as Such as xl or xm pci-list-assignable? > 'xenpm get-cpufreq-states': Apparently, there aren't any CPUs ... See if xen-acpi-processor is loaded or built in. > > > -- > Knowledge is volatile and fluid. Software is power. > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Are xen and centos incompatible?
On Tue, Jun 10, 2014 at 06:47:20PM +0200, lee wrote: > Konrad Rzeszutek Wilk writes: > > > On Tue, Jun 10, 2014 at 04:44:23AM +0200, lee wrote: > >>> Konrad Rzeszutek Wilk writes: > >> > > >> > The device should be visible in the dom0 - even when it is for > >> > passthrough. > >> > >> Why should it be visible when it's hidden? > > > > The 'hide' part is to hide it from the device drivers in the initial > > domain - dom0. That is so that they will not try to use it - as we > > plan to pass them to a guest. We need it in the dom0 to do admin type > > work - FLR it, etc. > > With Debian, it's not visible in dom0 when the passthrough works. > That's how I found out that it does work to begin with, and it makes > sense to me. That is a surprise. If you do 'lspci' in your dom0 do you see the device (06:00.0)? > > What does FLR mean? And how do you do something with a device for which > no drivers are loaded? I'd find it rather unusual to have a device > without drivers and even be able to use it; such devices usually don't > show up. Function Level Reset. You pass the device to a guest so it can load the drivers and the initial domain (dom0) won't use it. > > >> > But irrespective of that - the steps mentioned there are out of date. > >> > The correct option should be 'xen-pciback.hide=(06:00.0) > >> > xen-pciback.permissive=1' > >> > >> That's one of the problems: Xen is very poorly documented. > > > > Any help in improving the documentations would be appreciated. Every month > > we run 'Documentation days' and any work - either on Wiki, manuals, docs, > > etc > > would be quite appreciated. > > If I have some time, I might make a writeup about how to set up what I > did. But it seems I'm using an outdated version of xen, which is what > comes with Debian, so by the time I'd finish the writeup, it would be > outdated and contribute to confusion more than do any good. > > And considering xen, I don't really know anything. I figured out that > passthrough doesn't work out of the box on Debian because the module for > the device was loaded from the initrd.img before the xen-pciback module > and made a bug report because you're supposed to be able to use files in > /etc/modprobe.d which can specify dependencies and when you do that, you > can't have that just overridden or there's no point in doing that --- > and there doesn't seem to be any other way to specify the order in which > modules are loaded, and long ago, Debian came up with a policy that > things should work out of the box whenever possible (which they might > have forgotten by now ...). So maybe they'll fix this problem. > > Anyway, it probably goes for other distributions as well, and a hint in > the xen docs probably won't hurt. > > > Please see http://wiki.xenproject.org/wiki/Xen_Project_Document_Days > > I tried to make a request to become a "wiki editor". There might be > some places in the docs I might be able to make clearer. I don't know > if that was successful, though. It seemed to want to redirect me to > some google website ... > > > -- > Knowledge is volatile and fluid. Software is power. > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Are xen and centos incompatible?
On Tue, Jun 10, 2014 at 04:44:23AM +0200, lee wrote: > Konrad Rzeszutek Wilk writes: > > > On Sat, Jun 07, 2014 at 02:44:54AM +0200, lee wrote: > >> Hi, > >> > >> I'm trying to pass a physical network interface through to a domU. > >> > >> This seems to be impossible because the way xen wants to do it is > >> incompatible with the way centos wants to do it. > > > > Huh? > >> > >> I followed documentation on http://www.xen-support.com/?p=151 and tried > >> booting with 'pciback.permissive pciback.hide=(06:00.0)'. This gives a > >> hint in dmesg "kernel: xen-pciback: backend is vpci", and the device is > >> still visible in dom0. So this obviously doesn't work. > > > > The device should be visible in the dom0 - even when it is for passthrough. > > Why should it be visible when it's hidden? The 'hide' part is to hide it from the device drivers in the initial domain - dom0. That is so that they will not try to use it - as we plan to pass them to a guest. We need it in the dom0 to do admin type work - FLR it, etc. > > > But irrespective of that - the steps mentioned there are out of date. > > The correct option should be 'xen-pciback.hide=(06:00.0) > > xen-pciback.permissive=1' > > That's one of the problems: Xen is very poorly documented. Any help in improving the documentations would be appreciated. Every month we run 'Documentation days' and any work - either on Wiki, manuals, docs, etc would be quite appreciated. Please see http://wiki.xenproject.org/wiki/Xen_Project_Document_Days > > I replaced centos with debian and finally got it to work. Things are > much easier with debian. Glad to hear you solved the problems. ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Are xen and centos incompatible?
On Sat, Jun 07, 2014 at 02:44:54AM +0200, lee wrote: > Hi, > > I'm trying to pass a physical network interface through to a domU. > > This seems to be impossible because the way xen wants to do it is > incompatible with the way centos wants to do it. Huh? > > I followed documentation on http://www.xen-support.com/?p=151 and tried > booting with 'pciback.permissive pciback.hide=(06:00.0)'. This gives a > hint in dmesg "kernel: xen-pciback: backend is vpci", and the device is > still visible in dom0. So this obviously doesn't work. The device should be visible in the dom0 - even when it is for passthrough. But irrespective of that - the steps mentioned there are out of date. The correct option should be 'xen-pciback.hide=(06:00.0) xen-pciback.permissive=1' > > Following http://wiki.xen.org/wiki/Xen_PCI_Passthrough: which is mentioned in that link. > > > [root@heimdall ~]# xl pci-assignable-add 06:00.0 > xend is running, which may cause unpredictable results when using > this xl command. Please shut down xend before continuing. > > (This check can be overridden with the -f option.) > [root@heimdall ~]# > > > There doesn't seem to be any documentation about what xend does or is > for and how to pass a physical network interface through with it. Did you just try using the same parameter but replace 'xl' with 'xm'? > > I'm starting to think that using centos for a server os is an extremely > bad choice because nothing works. It's not like a Linux distribution > but like a mess of pieces from several unrelated puzzles thrown together > randomly. > > > -- > Knowledge is volatile and fluid. Software is power. > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Xen DomU supoprt in RHEL 7 and the CentOS Plan
On Wed, May 28, 2014 at 08:29:33AM +0100, Simon Rowe wrote: > On 28/05/14 01:22, Mason Loring Bliss wrote: > > XenCenter still doesn't have a proper, free equivalent that deals with guest > > extensions and such, as far as I know. > The XenCenter codebase is also on GitHub > > https://github.com/xenserver/xenadmin I am not sure why we are discussing Citrix's code as what would be going in the CentOS land is the Xen upstream (http://xenbits.xen.org/) hypervisor and toolstack. That is - the same RPMs and code that has been in Fedora for some time (do 'yum install xen' under Fedora and you will have the stock Xen code). That code runs with libvirt, so you can use virsh, libvirt (if they are compiled to use Xen libraries), virt-manager, or xl if you prefer. Perhaps I am missing something obvious here? Could you please enlighten me? > > Simon > > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Xen DomU supoprt in RHEL 7 and the CentOS Plan
On Tue, May 27, 2014 at 01:04:21PM +0100, David Vrabel wrote: > On 23/05/14 18:58, Konrad Rzeszutek Wilk wrote: > > On Fri, May 23, 2014 at 03:59:14AM -1000, NightLightHosts Admin wrote: > >> +3 XEN! > >> > >> On Fri, May 23, 2014 at 3:56 AM, O'Reilly, Dan > >> wrote: > >>> +2 > >>> > >>> -Original Message- > >>> From: centos-virt-boun...@centos.org > >>> [mailto:centos-virt-boun...@centos.org] On Behalf Of Antony Messerli > >>> Sent: Friday, May 23, 2014 7:49 AM > >>> To: > >>> Subject: Re: [CentOS-virt] Xen DomU supoprt in RHEL 7 and the CentOS Plan > >>> > >>> +1 on Xen support, I haven't had time to test on RHEL yet or poke around > >>> in the kernel yet, but has all of the Xen support been removed from the > >>> kernel? > > > > It has not been removed, but .. let me go in details. > > > > You can boot an RHEL7 guest as PV, but there are issues: > > > > 1). The FB driver has been unset (CONFIG_XEN_FBDEV_FRONTEND) that means > > you can > > still do a text-console (in theory). > > Is this an interesting use case? XenServer, for example, doesn't > present a PV frame buffer to any PV guest and I don't recall anyone ever > asking for it. There are better technologies for graphical remote > access (e.g., remote X over SSH, RDP, VNC...). Yes it is. Folks often use 'vncviewer'. > > > 3). There are also some systemd and udev things missing. > > Really? What? There shouldn't be anything extra for a pure PV guest vs > a PVHVM guest (which RedHat do support).] I don't know the details, John Haxby (CCed here) knows them. > > David > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Xen DomU supoprt in RHEL 7 and the CentOS Plan
On Fri, May 23, 2014 at 03:59:14AM -1000, NightLightHosts Admin wrote: > +3 XEN! > > On Fri, May 23, 2014 at 3:56 AM, O'Reilly, Dan > wrote: > > +2 > > > > -Original Message- > > From: centos-virt-boun...@centos.org > > [mailto:centos-virt-boun...@centos.org] On Behalf Of Antony Messerli > > Sent: Friday, May 23, 2014 7:49 AM > > To: > > Subject: Re: [CentOS-virt] Xen DomU supoprt in RHEL 7 and the CentOS Plan > > > > +1 on Xen support, I haven't had time to test on RHEL yet or poke around in > > the kernel yet, but has all of the Xen support been removed from the kernel? It has not been removed, but .. let me go in details. You can boot an RHEL7 guest as PV, but there are issues: 1). The FB driver has been unset (CONFIG_XEN_FBDEV_FRONTEND) that means you can still do a text-console (in theory). 2). The Xorg fb seems to suffer from some bug - which is why the Xen FB has be turned off. 3). There are also some systemd and udev things missing. I understand that folks are interested in getting this fixed, but I was wondering what the protocol is for getting said patches in the respective RPMS (xorg-some-server, udev, systemd, kernel)? Naturally this needs to be fixed upstream first, but once that has been completed it should be fairly easy to backport it. Oh, and the Xen support has not been removed - as in, the kernel can easily boot as an PVHVM guest. It is just that the PV part had been. > > > > Ant > > > >> On May 23, 2014, at 8:31 AM, "Kai Schaetzl" > >> wrote: > >> > >> Karanbir Singh wrote on Fri, 23 May 2014 13:19:45 +0100: > >> > >>> so far, in rhel7rc its pretty clear that Xen instances ( domUs ) are > >>> not going to boot with the RHEL7rc kernel. > >> > >> What a pity. Not to mention Dom0. > >> > >>> Wondering if someone has looked into what the challenges might be to > >>> enable this support, and then what the options are to deliver this > >>> support ? > >> > >> I'm sorry, I haven't yet, not even tested RHEL7rc. I just want to > >> raise my hand and say, yes, I would like to have xen support if you > >> can make it happen without too many hooplas. But I won't be able to help > >> much. > >> > >> Kai > >> > >> -- > >> Get your web at Conactive Internet Services: http://www.conactive.com > >> > >> > >> > >> ___ > >> CentOS-virt mailing list > >> CentOS-virt@centos.org > >> http://lists.centos.org/mailman/listinfo/centos-virt > > ___ > > CentOS-virt mailing list > > CentOS-virt@centos.org > > http://lists.centos.org/mailman/listinfo/centos-virt > > ___ > > CentOS-virt mailing list > > CentOS-virt@centos.org > > http://lists.centos.org/mailman/listinfo/centos-virt > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Bug system?
On Fri, May 16, 2014 at 11:51:40AM +0100, Karanbir Singh wrote: > On 05/14/2014 01:21 PM, Lars Kurth wrote: > > Konrad, > > we have not figured this out yet. I will put it onto the agenda for the > > next meeting > > Lars > > > > On 12/05/2014 17:55, Konrad Rzeszutek Wilk wrote: > >> Hey, > >> > >> For the kernel and hypervisor related issues I would ask that I get > >> copied (or the other Linux Xen maintainers). > >> > >> But I am unclear what the bug system is - if any - so that I can > >> create an account on it? > >> > > we should be able to just use bugs.centos.org, since we send all system > reports there anyway OK. Let me open a bug account there. If there are any Xen related bugs (Linux kernel or Xen) please CC my account: 'konradrzeszutekwilk'. (is there a way to make it automatic so that any bugs reported against xen package gets me included?) Thanks! > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > ___ > CentOS-virt mailing list > CentOS-virt@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
[CentOS-virt] Bug system?
Hey, For the kernel and hypervisor related issues I would ask that I get copied (or the other Linux Xen maintainers). But I am unclear what the bug system is - if any - so that I can create an account on it? Thanks! ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
