xen August 2011

xen@lists.fedoraproject.org

11 participants
12 discussions

execute commands from dom0 into domU
by silviu d 06 Jun '15

06 Jun '15

Hello, I was wondering if there is a way to execute commands from dom0 into domU without loging into domU with ssh. thanks

3 2

xen packages to test
by M A Young 24 Oct '11

24 Oct '11

I have a couple of temporary builds of xen release candidates available for testing; xen-4.0.2-rc4 built for F14 at http://koji.fedoraproject.org/koji/taskinfo?taskID=3085546 and xen-4.1.1-rc1 built for F15 at http://koji.fedoraproject.org/koji/taskinfo?taskID=3086043 Also if you are interested in testing packages for RHEL6 see http://koji.fedoraproject.org/koji/taskinfo?taskID=3086043 Michael Young

4 6

Xen release candidates to test
by M A Young 08 Oct '11

08 Oct '11

I have built 4.0.3-rc1 for Fedora 14 (temporarily) at http://koji.fedoraproject.org/koji/taskinfo?taskID=3303194 and 4.1.2-rc1 for Fedora 15 (temporarily) at http://koji.fedoraproject.org/koji/taskinfo?taskID=3302767 for testing. Let me know and/or post on the xen-devel list if you see any problems. Michael Young

1 2

Re: [Fedora-xen] Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))
by Todd Deshane 30 Aug '11

30 Aug '11

(adding fedora-xen to the CC) On Tue, Aug 30, 2011 at 5:17 PM, jim burns <jim_burn(a)bellsouth.net> wrote: > On Tue August 23 2011, 5:12:52 PM, jim burns wrote: >> On Tue August 16 2011, 7:46:33 PM, jim burns wrote: >> > On Mon August 15 2011, 4:04:20 AM, jim burns wrote: >> >> Pls cc me with responses, as I'm not subscribed. >> > >> > Yay! After a string of fedora rawhide 3.1.0-rc0 and -rc1's that did not >> > boot under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen, it has >> > the vga patch, and xen-pciback correctly siezes my wireless device. >> > Unfortunately, while a baremetal boot is clean, a xen boot has several >> >> > BUG:'s of the form: >> Rawhide is up to 3.1.0-0.rc3.git0.0.fc17.x86_64 , and it still has the same >> BUGS: of the form: >> >> BUG: scheduling while atomic: modprobe/493/0x10000002 >> >> BUG: sleeping function called from invalid context at kernel/mutex.c:271 >> >> BUG: scheduling while atomic: xenstored/3184/0x10000002 >> >> both while booting up under xen, and when starting and stopping a(n hvm) >> guest. > > Rawhide is up to 3.1.0-0.rc4.git0.0.fc17 , and still the same bugs, plus the > new one 'spinlock wrong CPU': > > Aug 30 17:07:13 Insp6400 kernel: [ 9.657492] BUG: sleeping function called > from invalid context at kernel/mutex.c:271 > Aug 30 17:07:13 Insp6400 kernel: [ 9.657553] in_atomic(): 1, > irqs_disabled(): 0, pid: 254, name: modprobe > -- > Aug 30 17:07:13 Insp6400 kernel: [ 9.714251] BUG: scheduling while atomic: > modprobe/254/0x10000002 > Aug 30 17:07:13 Insp6400 kernel: [ 9.715224] 3 locks held by modprobe/254: > -- > Aug 30 17:07:13 Insp6400 kernel: [ 52.675476] BUG: sleeping function called > from invalid context at kernel/mutex.c:271 > Aug 30 17:07:13 Insp6400 kernel: [ 52.676191] in_atomic(): 1, > irqs_disabled(): 0, pid: 511, name: modprobe > -- > Aug 30 17:07:13 Insp6400 kernel: [ 52.682754] BUG: scheduling while atomic: > modprobe/511/0x10000002 > Aug 30 17:07:13 Insp6400 kernel: [ 52.682754] 3 locks held by modprobe/511: > -- > Aug 30 17:07:13 Insp6400 kernel: [ 52.867221] BUG: spinlock wrong CPU on > CPU#1, modprobe/511 > Aug 30 17:07:13 Insp6400 kernel: [ 52.868082] lock: ffffffff81a7de60, > .magic: dead4ead, .owner: modprobe/511, .owner_cpu: 0 > -- > Aug 30 17:07:13 Insp6400 kernel: [ 55.038559] BUG: sleeping function called > from invalid context at kernel/mutex.c:271 > Aug 30 17:07:13 Insp6400 kernel: [ 55.039487] in_atomic(): 1, > irqs_disabled(): 0, pid: 508, name: modprobe > -- > Aug 30 17:07:13 Insp6400 kernel: [ 55.039487] BUG: scheduling while atomic: > modprobe/508/0x10000002 > Aug 30 17:07:13 Insp6400 kernel: [ 55.039487] INFO: lockdep is turned off. > -- > Aug 30 17:07:13 Insp6400 kernel: [ 55.153964] BUG: scheduling while atomic: > modprobe/508/0x10000002 > Aug 30 17:07:13 Insp6400 kernel: [ 55.154664] INFO: lockdep is turned off. > -- > Aug 30 17:08:04 Insp6400 kernel: [ 117.158477] BUG: sleeping function called > from invalid context at kernel/mutex.c:271 > Aug 30 17:08:04 Insp6400 kernel: [ 117.159068] in_atomic(): 1, > irqs_disabled(): 0, pid: 3204, name: xenstored > > > _______________________________________________ > Xen-users mailing list > Xen-users(a)lists.xensource.com > http://lists.xensource.com/xen-users > -- Todd Deshane http://www.linkedin.com/in/deshantm http://www.xen.org/products/cloudxen.html http://runningxen.com/

1 0

F15 kernel Xen support missing PCI passthrough?
by Hilton Day 25 Aug '11

25 Aug '11

After recently discovering 2.6.40 is secretly Kernel 3 in disguise, and includes pvops, 5 years after my last post on Fedora-Xen, I'm back. I've been running Xen on a home server for well, just over 5 years, the last three of which have been on a Centos5 dom0, in the absence of dom0 support in Fedora since FC6. I've installed a fresh machine, and can get a dom0 running in Fedora 15 using 2.6.40 and the default xen-4.1.1 packages, as well as DomU's running Centos5, Scientific Linux 6, Fedora 15 and Solaris 11, so all good there. But I've hit a snag. The Fedora kernel doesn't appear to include the xen-pciback kernel module (or indeed any module with "pciback" in its name). I use PCI Passthrough to donate a physical NIC to one of the domU's which runs the network gateway/firewall/transparent proxy etc. for the network. I've grabbed the kernel source rpm and checked out the config files, and they appear to be completely missing the XEN_PCIDEV_BACKEND flags. Being new to Fedora 15, Kernel 3 and Xen4.x all at once, is there some new trick that isn't documented online, or am I right in seeing a lack of PCI pass-through support in the Fedora kernel? My next step is to try adding the compile flags to the .config and rebuilding the kernel - but would appreciate anyone's input with more experience of the Fedora environment. Thanks, Hilton.

5 6

Positive experience updating Dom0 from f14/2.6.32/4.0.2 to f15/2.6.40/4.1
by Bill McGonigle 17 Aug '11

17 Aug '11

Just some notes, in case others are planning similar upgrades. I was running 2.6.32 from M. Young's repo. My goal was to get up to 2.6.40 on Fedora 15 (mainline dom0!) with minimal downtime. I found that f15's version of Xen (4.1) wouldn't run, even after re-compiling on f14. So, that couldn't be staged ahead of time. As a retreat plan, I made sure to have rpm's for Xen 4.0.2 handy, but they wound up being unnecessary. I knew there'd be some xend breakage during the upgrade, so I opened ssh sessions to each VM. I then started the yum upgrade, first with yum and rpm, then only the fedora and updates repos, then other repos. Some package upgrade problems needed to be solved (I have too much in dom0), but nothing worse than usual. Once all the upgrades were in place, I hand-edited grub.conf since the new kernel installed a non-Xen entry. At this point, I should have checked to see that my initramfs was made properly (it wasn't, locally packaged zfs modules broke the scriptlet). I had to come back in with rescue mode to re-run dracut. Once all the updates were installed, I shut down each of the VM's using native 'shutdown -h now' inside the vm. xm shutdown was broken at this point. Now, the only ugly part is that systemd wasn't yet running, but 'reboot' is replaced. So, to reboot the system, I had to do 'sync;sync;sync [reset button]'. I had filesystems mounted -o data=journal, so I was at least feeling good about consistency. Some people wouldn't tolerate this option, but it worked out OK for me. With a working initramfs, the system came up just fine, the VM's started as they should, and everything seemed OK from the Xen perspective. All the domU's function, no domU updates required (Fedora 12/13/14, CentOS 5). If I had noticed the initramfs problem properly, I would have gotten away with only about a 4 minute outage. Quite glad to be re-united, after many years in the Fedora/Xen exile community! Much kudos to Michael Young, Pasi, and all the others who have helped up through the dark times. -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.855.SW.LIBRE Email, IM, VOIP: bill(a)bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle

4 6

CentOS 6 install via virt-install - "No usable disks have been found."
by Bill McGonigle 17 Aug '11

17 Aug '11

Hi, all, I'm not seeing disks under CentOS 6 when trying to install. I'm using: xen-4.0.2-1.fc14.x86_64 2.6.32.39-175.xendom0.fc13.x86_64 installing using: virt-install --debug -n sully --mac=02:00:0A:01:01:10 -f /var/lib/xen/images/sully -s 12 -r 2048 --vcpus=2 --nographics -p --os-type=linux --os-variant=rhel6 --location http://librescu.bfccomputing.com/cobbler/ks_mirror/centos6-x86_64/ It sounded like: https://bugzilla.redhat.com/show_bug.cgi?id=678374 so I tried dropping the --nonsparse option, but I'm using a newer version of python-virtinstall: python-virtinst-0.500.6-1.fc14.noarch than should be required, and I'm seeing this with and with the option anyway. I do see the disk image is created, and attached to the DomU. e.g.: [2011-07-26 01:01:47 18534] DEBUG (DevController:97) DevController: writing {'domain': 'sully', 'frontend': '/local/domain/18/device/vbd/51712', 'uuid': '3380cea8-a322-292d-cc5d-8bb084306976', 'bootable': '1', 'dev': 'xvda', 'state': '1', 'params': 'aio:/var/lib/xen/images/sully', 'mode': 'w', 'online': '1', 'frontend-id': '18', 'type': 'tap'} to /local/domain/0/backend/tap/18/51712. and I can see the disk image if I dump configuration from virsh. I do see this in the DomU kernel messages: XENBUS: Device with no driver: device/vbd/51712 XENBUS: Device with no driver: device/vif/0 XENBUS: Device with no driver: device/console/0 but I see reports online that say not to worry about those, initrd will load the modules. The initrd does have: ./kernel/drivers/xen ./kernel/drivers/xen/xenfs ./kernel/drivers/net/xen-netfront.ko.gz ./kernel/drivers/block/xen-blkfront.ko.gz on it. I tried adding: xen_emul_unplug=never to the kernel parameters per a previous thread here, but that didn't seem to change anything. It seems like others are having success with CentOS 6 in general: http://grantmcwilliams.com/tech/virtualization/xen-howtos/538-centos-6-virt… so I suspect it's got something to do with Xen 4.0.2, but I'm not sure where to look right now. Any suggestions? -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.855.SW.LIBRE Email, IM, VOIP: bill(a)bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle

3 3

Re: [Fedora-xen] [Xen-devel] Re: Xl and /dev/null (no domU cfgfile)
by Ian Jackson 09 Aug '11

09 Aug '11

Ian Campbell writes ("Re: [Xen-devel] Re: [Fedora-xen] Xl and /dev/null (no domU cfgfile)"): > On Mon, 2011-08-01 at 23:03 +0100, Pasi Kärkkäinen wrote: > > On Mon, Aug 01, 2011 at 01:30:43PM -0500, W. Michael Petullo wrote: > > > $ sudo xl create /dev/null > > > libxl: error: libxl_utils.c:328:libxl_read_file_contents /dev/null is not a plain file: Success > > > Failed to read config file: /dev/null: Inappropriate ioctl for device > > That's a pretty weird interface, probably more of a coincidence than a > deliberate feature. Far better would be to just make the file optional. > Can someone cook up such a patch? The error message is a bit poor too. > If we are looking to be bug/oddity compatible with xm then we could > remove the S_ISREG check from libxl_read_file_contents. I suppose that, > in principal at least, there is no reason to prevent people reading > pipes, fifos, symlinks or even character devices to get the > configuration file. (unless we might potentially read it multiple > times?). The reason for the S_ISREG check is that xl needs to take the config file and store it as the userdata. That means it needs to read the whole thing into memory, which is easier if you can stat the file to find out its length. It would not be impossible or unreasonable to relax this restriction. I would be happy to take a patch that used a realloc approach in the !S_ISREG case. Ian.

1 0

Fedora 15 Xen Kernel Make w/Mutex Errors
by Michael J. Fuhrman 09 Aug '11

09 Aug '11

2 1

grub2 is not able to boot XEN Dom0 on Fedora 16: initramfs missing.
by Marko Ristola 07 Aug '11

07 Aug '11

Hi grub2 is not able to find initramfs image for XEN Dom0 on Fedora 16. Probably Rawhide is affected as well. Patch included. https://bugzilla.redhat.com/show_bug.cgi?id=728775 This is critical for grub2-mkconfig -o /boot/grub2/grub.cfg to work properly on Fedora 16 / rawhide. Another issue is that kernel upgrade doesn't install XEN Dom0 grub2 lines ("--class xen"). but at least grub2-mkconfig command is able to fix the problem. Regards, Marko Ristola

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xen August 2011