similar to: CEBA-2016:0218 CentOS 7 ipxe BugFix Update

Hi, I try to exchange datas between host and Guest by adding these lines in a guest .xml conf file : <channel type='pty'> <target type='virtio' name='arbitrary.virtio.serial.port.name'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> Then

On Wed, Aug 26, 2015 at 12:17:20PM +0000, Jean-Pierre Ribeauville wrote: > Hi, > > I try to exchange datas between host and Guest by adding these lines in a guest .xml conf file : > > <channel type='pty'> > <target type='virtio' name='arbitrary.virtio.serial.port.name'/> > <address type='virtio-serial'

Hi, I've installed a OpenStack KILO all-in-one . For private need , I've to add a channel device to all my GUESTS on my compute node. It works fine (e.g. via a virsh command). Problem is that , in the xml describing the Guest , this 'state' value : <target type='virtio' name='agent' state='disconnected'/> showing if the channel is connected

Hi list, i use a centos 7 as virtual host with two guests with windows 2012 standard ( as storage i use RAW files). My problem is that sometime during the bakup my server reboot without leaving information in the log files ( /var/log/messages ). The backup does this steps: 1) Save the state of the virtual guest ( with the command "virsh save " ) 2) Make a snapshot of the filesystem (

Hi, Discard this request , I was investigating on the wrong compute node. It works fine. Sorry for incovenience. Regards, J.P. De : Jean-Pierre Ribeauville Envoyé : mercredi 20 janvier 2016 16:18 À : 'libvirt-users@redhat.com' Objet : channel device "state" value missing within OpenStack Kilo version Hi, I've installed a OpenStack KILO all-in-one . For private

Hi, All I want to use the SR-IOV of intel 82576 NIC. I enabled IOMMU and VT-d and SR-IOV in BIOS. And enabled VT-d in kernel. The OS information is bellow: [root@host3 nova]# cat /etc/redhat-release CentOS Linux release 7.1.1503 (Core) [root@host3 nova]# uname -an Linux host3.localdomain 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@host3 nova]#

Dear all, After "yum update" and reboot on a CentOS 7 server running kvm, all VM guests fail to receive keyboard input. Even sending ctrl-alt-delete from the virt-manager "Send Key" menu is inoperative. Most guests are set up as spice + QXL, and viewed on remote X sessions using virt-manager. Extensive browsing for a solution has turned up only dead ends. I tried reverting to

Hello, I can't help with the problems on real hardware but have come across the qemu problems before and maybe I can give some hints on that. On Fri, 31 Jul 2015, Oscar Roozen via Syslinux wrote: > So it was time for the next step. Migrate this setup to our automated testing > environment that runs under qemu-kvm. For this I had to use OVMF so the nodes > would boot in EFI mode

> I can't help with the problems on real hardware but have come across the > qemu problems before and maybe I can give some hints on that. Thank you, your help is much appreciated! >> The short story is that I never got further than syslinux proclaiming >> "Failed to read blocks: 0xC" before even getting to the stage where it >> tries to load ldlinux.e64.

On Jul 1, 2014 10:37 PM, "Alexander Perlis" <aperlis at math.lsu.edu> wrote: > > I believe I'm seeing a bug in lpxelinux.0 6.03-pre17 but I need some advice on how to isolate and troubleshoot this. (I can't try pre18 at the moment, but did try 4.07 and 5.10 and saw similar behavior, also with pxelinux.0, so although I'll give pre18 a try soon, some

Hi, I just tested by using "unix virtio" channel instead of pty. It looks easier to handle. Thx for help. Regards, J.P. -----Message d'origine----- De : libvirt-users-bounces@redhat.com [mailto:libvirt-users-bounces@redhat.com] De la part de libvirt-users-request@redhat.com Envoyé : mercredi 26 août 2015 15:38 À : libvirt-users@redhat.com Objet : libvirt-users Digest, Vol 68,

>>> Using VMware I built a test setup of a server with dhcp, tftp and a http-server and several pxe-clients with EFI mode turned on. This setup worked, albeit with the exponential-like decay of IO rate I described earlier. The work-around of using HTTP works beautifully though. <<< ""exponential-like decay of IO rate"" could you please post a link on

I installed CentOS6 with the xen4centos set of packages; then I tried to install KVM (for performance comparison), I got the following error in YUM: --> Processing Dependency: /usr/share/gpxe/e1000-0x100e.rom for package: 2:qemu-kvm-0.12.1.2-2.415.el6_5.4.x86_64 Package gpxe-roms-qemu is obsoleted by ipxe-roms-qemu, but obsoleting package does not provide for requirements I manually

Op 2014-07-01 om 22:55 schreef Gene Cumm: > On Jul 1, 2014 10:37 PM, "Alexander Perlis" wrote: > > > > I believe I'm seeing a bug in lpxelinux.0 6.03-pre17 but I need some > > advice on how to isolate and troubleshoot this. (I can't try pre18 > > at the moment, but did try 4.07 and 5.10 and saw similar behavior, > > also with pxelinux.0, so

I believe I'm seeing a bug in lpxelinux.0 6.03-pre17 but I need some advice on how to isolate and troubleshoot this. (I can't try pre18 at the moment, but did try 4.07 and 5.10 and saw similar behavior, also with pxelinux.0, so although I'll give pre18 a try soon, some isolation/troubleshooting advice will be a good education no matter what.) To get to our PXE-launched tools from

On Thu, Oct 10, 2013 at 10:00 AM, Michael Brown <mbrown at fensystems.co.uk> wrote: > On 09/10/13 10:45, Robin Smidsr?d wrote: >> >> On 09.10.2013 02:56, H. Peter Anvin wrote: >>> >>> The gPXE in the Syslinux tree is ridiculously old. We could either >>> replace it with iPXE or just drop it, giving people a recipe for how to >>> integrate

> The gPXE in the Syslinux tree is ridiculously old. We could either > replace it with iPXE or just drop it, giving people a recipe for how to > integrate with iPXE themselves. > > What do people think? My vote is replace with iPXE. I've manually replaced gPXE with iPXE for years, works like charm. I suggest updating the Makefile to use undionly.kkkpxe because of the change

From: Gene Cumm <gene.cumm at gmail.com> Date: Mon, Mar 17, 2014 at 7:39 PM Subject: Re: [ipxe-devel] iPXE boot from both ports (from diferent subnets) not working To: Wissam Shoukair <wissams at mellanox.com> Cc: "ipxe-devel at lists.ipxe.org" <ipxe-devel at lists.ipxe.org> On Mon, Mar 17, 2014 at 4:43 AM, Wissam Shoukair <wissams at mellanox.com> wrote: >

CentOS Errata and Security Advisory 2015:2619 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-2619.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: f4cd30964bac5a16549d01ddbbe62fa95463e51e11de3eeeddddea171dff989a autocorr-af-4.3.7.2-5.el7_2.1.noarch.rpm

On 25/10/15 01:04, Gene Cumm wrote: > On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux > <syslinux at zytor.com> wrote: > >> Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115 > > A fork is a fork, regardless the reasons behind it (yes, I have some > understanding in this case). iPXE is based off of forking further > development as of a