From lucarx76 at gmail.com Wed Jul 2 18:01:07 2008 From: lucarx76 at gmail.com (Gianluca USA) Date: Wed, 2 Jul 2008 11:01:07 -0700 Subject: [Fedora-xen] XEN configuration Message-ID: <3d87aabd0807021101h6bda1144x911e76ca8812a3d2@mail.gmail.com> Hi all, I'm using XEN on Fedora 8. I tried building a rootfilesystem over ram disk, but when I use it to boot XEN I got the following error: (XEN) Panic on CPU 0: (XEN) Domain 0 allocation is too small for kernel image. (XEN) **************************************** (XEN) If instead I use a normal initial filesystem, I noticed (looking at XEN's boot output) that (XEN) PHYSICAL MEMORY ARRANGMENT: (XEN) Dom0 alloc.: 000000003c000000->000000003e000000 (470953 pages to be allocated) (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c1000000->c1401000 (XEN) Init. ramdisk: c1401000->c1afe800 (XEN) Phys-Mach map: c1aff000->c1cd2ea4 (XEN) Start info: c1cd3000->c1cd346c (XEN) Page tables: c1cd4000->c1ce9000 (XEN) Boot stack: c1ce9000->c1cea000 (XEN) TOTAL: c0000000->c2000000 (XEN) ENTRY ADDRESS: c1000000 (XEN) Dom0 has maximum 2 VCPUs So it seems that if my root filesystem is too big (more than 33M) there is no space for XEN to load the kernel and the root filesystem in memory. Is there a way to change the XEN physical memory arrangement (in order to have enough space for the kernel and the root filesystem)? My system has 2G of RAM. My root filesystem is 250M and I'm planning to assign 512M to domain 0. Thanks, Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From xen at tequilasolutions.com Thu Jul 3 09:33:04 2008 From: xen at tequilasolutions.com (Jack) Date: Thu, 3 Jul 2008 10:33:04 +0100 Subject: [Fedora-xen] Xen and disaster recovery / redundancy / failover Message-ID: <011301c8dcef$cb928210$62b78630$@com> Hi All, Forgive me if this was discussed last week I'm new... I currently run two servers, one for mail, one for web + db, but will be expanding In future so a virtual architecture seems a good idea, especially if I can run the VM's on any of the physical machines on the fly as load / failures dictate. Ideally this would all be automatic and the VM's would share processor / storage transparently amongst available machines, and I would also like to add extra storage as necessary without having to rebuild arrays or reinstall stuff. I'd like to replace the os on both physical machines with minimal fedora 8 + xen and run the mail / web / db services inside VM's. I've got a F9 system running inside a VM on the mailserver now but don't know how to get it running on both machines as I'm not sure what's possible with exporting / sharing VM settings. For now, What I need is to be able to run the image of the F9 system on my web box when the mail server crashes so that the mail server is still available should the physical mail server break. My thinking was if both machines just run a minimal system + the VM's then the other disks in the machines can be running a raided gfs across both machines to provide a redundant storage system that can survive a machine failure. Hopefully then should a box pack up I can still run all my services in VM's on a single machine since the VM images will be available to both machines on the shared filesystem. I don't even know which parts of this are possible or whether its a bad strategy, perhaps there's a better approach to all of this, ideas welcome, Thanks, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From xen at tequilasolutions.com Thu Jul 3 12:28:06 2008 From: xen at tequilasolutions.com (Jack) Date: Thu, 3 Jul 2008 13:28:06 +0100 Subject: [Fedora-xen] FW: VNC clash with virt-manager installer Message-ID: <019801c8dd08$3f58a4f0$be09eed0$@com> Hi All, I connect to my machine remotely over vnc, if I install a new VM through Virt-manager, it gives me a flashing screen complaining or TCP errors and connection refused to the VNC service. I'm guessing virt manager is clashing with my remote VNC connection so it cant display the booting os. Is there a way to get virt-manager to use a different VNC port? Or some other way to get them to play nicely? Thanks, Jack. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora.lists at burns.me.uk Fri Jul 4 06:44:09 2008 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 4 Jul 2008 07:44:09 +0100 Subject: [Fedora-xen] FW: VNC clash with virt-manager installer In-Reply-To: <019801c8dd08$3f58a4f0$be09eed0$@com> References: <019801c8dd08$3f58a4f0$be09eed0$@com> Message-ID: 2008/7/3 Jack : > I connect to my machine remotely over vnc, Using vnc-server, or vino (or other)? > Is there a way to get virt-manager to use a different VNC port? For me, a newly created VM under virt-manager *does* pick a free port number. From fedora.lists at burns.me.uk Fri Jul 4 06:52:26 2008 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 4 Jul 2008 07:52:26 +0100 Subject: [Fedora-xen] Xen and disaster recovery / redundancy / failover In-Reply-To: <011301c8dcef$cb928210$62b78630$@com> References: <011301c8dcef$cb928210$62b78630$@com> Message-ID: 2008/7/3 Jack : > I currently run two servers, one for mail, one for web + db, but will be > expanding in future so a virtual architecture seems a good idea, especially if I can > run the VM's on any of the physical machines on the fly as load / failures dictate. If you want to be able to failover VMs between hosts, you need the storage for the virtual disks to either be replicated between all hosts (drbd, cluster filesystem, etc), or to be stored on a external device (iSCSI, NFS etc) without that each VM depends on the single server where its disk resides. From sathakkar at ebay.com Thu Jul 3 17:44:28 2008 From: sathakkar at ebay.com (sachint) Date: Thu, 3 Jul 2008 10:44:28 -0700 (PDT) Subject: [Fedora-xen] Cannot start HVM DomU In-Reply-To: <1204735746.3707.34.camel@rlt60f8.laptop.redhat.com> References: <1204735746.3707.34.camel@rlt60f8.laptop.redhat.com> Message-ID: <18264811.post@talk.nabble.com> Hi Robert, Were you able to solve this issue? I am running into the same problem and would appreciate any advice. Thanks, Sachin Robert Locke wrote: > > This has newly started, so I am presuming that it is perhaps related to > some recently updated package on F8 in say the last week or so. > > I have a WindowsXP DomU that when I try to start from virt-manager gives > the following error: > > Error starting domain: virDomainCreate() failed POST operation failed: > (xend.err 'int argument required') > > Details shows: > > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/engine.py", line 472, in > run_domain > vm.startup() > File "/usr/share/virt-manager/virtManager/domain.py", line 379, in > startup > self.vm.create() > File "/usr/lib/python2.5/site-packages/libvirt.py", line 240, in > create > if ret == -1: raise libvirtError ('virDomainCreate() failed', > dom=self) > libvirtError: virDomainCreate() failed POST operation failed: (xend.err > 'int argument required') > > > I have no idea what other information to supply or where to particularly > find it since this has generally "just worked" for the occasional > running of a Windows instance that I have needed for the last several > months. > > Thanks for any help, > > --Rob > > > -- > Fedora-xen mailing list > Fedora-xen at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-xen > > -- View this message in context: http://www.nabble.com/Cannot-start-HVM-DomU-tp15854832p18264811.html Sent from the Fedora Xen mailing list archive at Nabble.com. From fedora.lists at burns.me.uk Fri Jul 4 21:24:31 2008 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 4 Jul 2008 22:24:31 +0100 Subject: [Fedora-xen] F10 crystal ball gazing Message-ID: Given that xen is entering feature freeze for updated release ~August is it too early to ask what the *hopes* are for xen in fedora10? xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? kernel 2.6.27(or late rc) with pv_ops for 32 and 64 bit, dom0 and domU? oVirt? updates to libvirt/virt-manager as usual From lists at ralii.com Fri Jul 4 22:11:47 2008 From: lists at ralii.com (Robert Locke) Date: Fri, 04 Jul 2008 18:11:47 -0400 Subject: [Fedora-xen] Cannot start HVM DomU In-Reply-To: <18264811.post@talk.nabble.com> References: <1204735746.3707.34.camel@rlt60f8.laptop.redhat.com> <18264811.post@talk.nabble.com> Message-ID: <1215209507.3749.2.camel@rlt60f8.laptop.redhat.com> Not sure if I am much help, but the issue did "go away".... Couple of things. I have noticed several "updates" to virt-manager and libvirt. I did have to "manually" kick it off, and once I did that, it seems to be "keeping on". By manual, I mean, I had to create a .xml file and use xm create to start it once (messed up my mouse until I figured out the correct setting in the .xml), but after that it kept going and would start from the GUI.... HTH, --Rob On Thu, 2008-07-03 at 10:44 -0700, sachint wrote: > Hi Robert, > > Were you able to solve this issue? I am running into the same problem and > would appreciate any advice. > > Thanks, > Sachin > > > Robert Locke wrote: > > > > This has newly started, so I am presuming that it is perhaps related to > > some recently updated package on F8 in say the last week or so. > > > > I have a WindowsXP DomU that when I try to start from virt-manager gives > > the following error: > > > > Error starting domain: virDomainCreate() failed POST operation failed: > > (xend.err 'int argument required') > > > > Details shows: > > > > Traceback (most recent call last): > > File "/usr/share/virt-manager/virtManager/engine.py", line 472, in > > run_domain > > vm.startup() > > File "/usr/share/virt-manager/virtManager/domain.py", line 379, in > > startup > > self.vm.create() > > File "/usr/lib/python2.5/site-packages/libvirt.py", line 240, in > > create > > if ret == -1: raise libvirtError ('virDomainCreate() failed', > > dom=self) > > libvirtError: virDomainCreate() failed POST operation failed: (xend.err > > 'int argument required') > > > > > > I have no idea what other information to supply or where to particularly > > find it since this has generally "just worked" for the occasional > > running of a Windows instance that I have needed for the last several > > months. > > > > Thanks for any help, > > > > --Rob > > > > > > -- > > Fedora-xen mailing list > > Fedora-xen at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-xen > > > > > From markmc at redhat.com Sat Jul 5 10:39:27 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Sat, 05 Jul 2008 11:39:27 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: References: Message-ID: <1215254367.4394.10.camel@muff> On Fri, 2008-07-04 at 22:24 +0100, Andy Burns wrote: > Given that xen is entering feature freeze for updated release ~August > is it too early to ask what the *hopes* are for xen in fedora10? There has been very little progress on the Dom0 pv_ops work of late, so it's getting harder to imagine it being in shape for Fedora 10. Still hope, for sure, but getting slimmer. > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? Not really important if there's no Dom0 kernel. If there is, we'll definitely update. > kernel 2.6.27(or late rc) with pv_ops for 32 and 64 bit, dom0 and domU? I would expect our DomU kernel to continue tracking the bare-metal kernel versions - so, yeah, 2.6.27 probably. Jeremy Fitzhardinge sounds fairly confident of having much of x86_64 DomU ready for the 2.6.27 merge window. If that happens, our patch set would be quite small and I'd imagine we'd enable CONFIG_XEN in the bare-metal kernel and drop the kernel-xen package. Cheers, Mark. From fedora.lists at burns.me.uk Sat Jul 5 14:23:45 2008 From: fedora.lists at burns.me.uk (Andy Burns) Date: Sat, 5 Jul 2008 15:23:45 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <1215254367.4394.10.camel@muff> References: <1215254367.4394.10.camel@muff> Message-ID: 2008/7/5 Mark McLoughlin : > There has been very little progress on the Dom0 pv_ops work of late Oh, I thought from reading some of the Xen Summit slides that xen3.3 would mean pv_ops becoming the default for dom0 as well as domU. > it's getting harder to imagine it being in shape for Fedora 10 Gulp, that tightens the noose on those of us with fedora 8 dom0 machines. > I would expect our DomU kernel to continue tracking the bare-metal > kernel versions - so, yeah, 2.6.27 probably. > > Jeremy Fitzhardinge sounds fairly confident of having much of x86_64 > DomU ready for the 2.6.27 merge window. If that happens, our patch set > would be quite small and I'd imagine we'd enable CONFIG_XEN in the > bare-metal kernel and drop the kernel-xen package. Some potential good news then, thanks for the info. From markmc at redhat.com Sat Jul 5 15:34:22 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Sat, 05 Jul 2008 16:34:22 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: References: <1215254367.4394.10.camel@muff> Message-ID: <1215272062.26168.1.camel@muff> On Sat, 2008-07-05 at 15:23 +0100, Andy Burns wrote: > 2008/7/5 Mark McLoughlin : > > > There has been very little progress on the Dom0 pv_ops work of late > > Oh, I thought from reading some of the Xen Summit slides that xen3.3 > would mean pv_ops becoming the default for dom0 as well as domU. Here's the slides from the talk Stephen and I gave: http://markmc.fedorapeople.org/XenSummit.pdf Cheers, Mark. From berrange at redhat.com Sat Jul 5 16:45:51 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 5 Jul 2008 17:45:51 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: References: Message-ID: <20080705164551.GA8795@redhat.com> On Fri, Jul 04, 2008 at 10:24:31PM +0100, Andy Burns wrote: > Given that xen is entering feature freeze for updated release ~August > is it too early to ask what the *hopes* are for xen in fedora10? > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen RPM and hypervisor. This will at least let people build their own legacy Xen kernel from upstream's 2.6.18 xen kernel if they're lucky enough to have hardware which works with it. > oVirt? As far as most of the development work is concerned, oVirt is KVM based. Hypervisors are really becoming comoditized and the interesting stuff is occcurring in the management tools. As such oVirt development effort is best spent on the management tools and not on porting to multiple differnt hypervisors at this time. > updates to libvirt/virt-manager as usual Whatever the latest versions at time of freeze will be included. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From fedora.lists at burns.me.uk Sat Jul 5 18:17:50 2008 From: fedora.lists at burns.me.uk (Andy Burns) Date: Sat, 5 Jul 2008 19:17:50 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <1215272062.26168.1.camel@muff> References: <1215254367.4394.10.camel@muff> <1215272062.26168.1.camel@muff> Message-ID: 2008/7/5 Mark McLoughlin : > Here's the slides from the talk Stephen and I gave: That's quite bleak (but honest) I had considered KVM, I tried it on fedora9 but it doesn't have PCI passthrough yet (unless I'm out-of-date) and also I have some xen servers at work, so keeping the number of hypervisors down seemed a good idea when installing a home server. Just watched the video of your talk, an it does sound quite so bleak. From pasik at iki.fi Mon Jul 7 06:53:27 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 7 Jul 2008 09:53:27 +0300 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <1215254367.4394.10.camel@muff> References: <1215254367.4394.10.camel@muff> Message-ID: <20080707065327.GC3773@edu.joroinen.fi> On Sat, Jul 05, 2008 at 11:39:27AM +0100, Mark McLoughlin wrote: > On Fri, 2008-07-04 at 22:24 +0100, Andy Burns wrote: > > > Given that xen is entering feature freeze for updated release ~August > > is it too early to ask what the *hopes* are for xen in fedora10? > > There has been very little progress on the Dom0 pv_ops work of late, so > it's getting harder to imagine it being in shape for Fedora 10. Still > hope, for sure, but getting slimmer. > Hmm.. I thought there was 2 fulltime developers at redhat/fedora working with dom0 stuff.. mentioned in some other mail on this list. Is there some bigger problem with dom0 work? -- Pasi From felix.schwarz at web.de Mon Jul 7 19:42:35 2008 From: felix.schwarz at web.de (Felix Schwarz) Date: Mon, 07 Jul 2008 21:42:35 +0200 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080707065327.GC3773@edu.joroinen.fi> References: <1215254367.4394.10.camel@muff> <20080707065327.GC3773@edu.joroinen.fi> Message-ID: <487271AB.5040301@web.de> Pasi K?rkk?inen schrieb: > Hmm.. I thought there was 2 fulltime developers at redhat/fedora working with > dom0 stuff.. mentioned in some other mail on this list. > > Is there some bigger problem with dom0 work? As I understand it the whole paravirt_ops/Dom0 is pretty much a complete rewrite of Xen's kernel part given the old 2.6.18 base and all the things to work out with paravirt_ops (even without all the 'special' features like PCI pass through etc). Furthermore I guess that there is a lot of ground work to evolve the paravirt_ops interfaces etc so that the new port does not need to much kernel patching. Given all the circumstances, two full-time developers aren't that many and getting something in the mainline kernel is never easy... fs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From xen at tequilasolutions.com Mon Jul 7 23:46:56 2008 From: xen at tequilasolutions.com (Jack) Date: Tue, 8 Jul 2008 00:46:56 +0100 Subject: [Fedora-xen] In case this helps. Message-ID: <015a01c8e08b$bda1c270$38e54750$@com> I've been fighting xen for a few weeks now so sorry if this is old news but here's what I 've found, hope it helps a few. 1) You cant run xen dom0 in vmware - not true it seems...? Yes you can. I did a lot of searching and found lots of 'you cant' it has to be bare metal to work but its not true. BTW - you can search for days and not find anything on fedora / xen / clustering its really a hard time at the moment we need to sort it out... I was installing FC8 on VMware and trying everything but xen says on boot "relinquishing vga console". This is bad and means when you later run virt-manager you will be only be offered qemu emulation and paravirtualization will not be available because XEN didn't really boot. So I installed FC8 native straight on the hardware, and still the same thing happened, Xen wouldn't boot properly and virt-manager only offered my qemu emulation. Some searching suggested machines with 4gb may be the problem so maybe it works for you but FC8 out of the box does not work on my AMD 64X2 Nforce motherboard system with 5Gb ram. My working machine ran FC7, and the kernel-xen was kernel-xen......7.rpm My FC8 was running kernel-xen.....7.3. I removed kernel-xen .....7.3 and installed the kernel-xen .....7.rpm from website rpmfind and now it booted and xen emulation was available in virt-manager. Virt-manger didn't work first time so I had to give it a push with: virt-manager -c xen:///system and then all was good. No longer was qemu the only option and I could create proper paravirtualized machines. I wondered if the 'vmware doesn't work with xen' was really true after this and sure enough, replacing the FC8 kernel with the kernel-xen ....7 from fc7 also gave me proper dom0 emulation in vmware too. Hope this helps someone. Basically - its not always your fault you need the right mix of kernel and xen to support your hardware and if you get the "xen relingquishing vga console" message on boot it means you don't have xen working properly and need to explore a different build for your hardware. J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From margusja at kodila.ee Fri Jul 11 09:00:19 2008 From: margusja at kodila.ee (Margusja) Date: Fri, 11 Jul 2008 12:00:19 +0300 Subject: [Fedora-xen] Problem to using virt-install Message-ID: <48772123.6090405@kodila.ee> Hello, can somebody give me some hint how to resolve my problem? [root at bacula ~]# uname -a Linux bacula 2.6.21.7-3.fc8xen #1 SMP Thu Mar 20 14:57:53 EDT 2008 i686 i686 i386 GNU/Linux kernel-xen.i686 2.6.21.7-3.fc8 installed kernel-xen-devel.i686 2.6.21.7-3.fc8 installed xen.i386 3.1.2-2.fc8 installed xen-devel.i386 3.1.2-2.fc8 installed xen-libs.i386 3.1.2-2.fc8 installed libvirt.i386 0.4.4-1.fc8 installed libvirt-python.i386 0.4.4-1.fc8 installed python-virtinst.noarch 0.300.2-4.fc8 installed virt-manager.i386 0.5.3-2.fc8 installed [root at bacula ~]# virt-install -f /var/xen/xen1 -r 512 libvir: Remote error : Connection refused libvir: warning : Failed to find the network: Is the daemon running ? libvir: Remote error : Connection refused What is the name of your virtual machine? xen1 libvir: Xen Daemon error : GET operation failed: xend_get: error from xen daemon: Would you like to enable graphics support? (yes or no) no What is the install location? ftp://ftp.linux.ee/pub/fedora/linux/releases/8/Fedora/i386/os/ Starting install... libvir: Xen Daemon error : GET operation failed: xend_get: error from xen daemon: Retrieving file .treeinfo 100% |=========================| 430 B 00:00 Retrieving file vmlinuz.. 100% |=========================| 2.1 MB 00:04 Retrieving file initrd.im 100% |=========================| 6.4 MB 00:17 libvir: Xen Daemon error : GET operation failed: xend_get: error from xen daemon: libvir: Xen Daemon error : GET operation failed: xend_get: error from xen daemon: virDomainLookupByID() failed GET operation failed: xend_get: error from xen daemon: Domain installation may not have been successful. If it was, you can restart your domain by running 'virsh start xen1'; otherwise, please restart your installation. Fri, 11 Jul 2008 10:30:21 ERROR virDomainLookupByID() failed GET operation failed: xend_get: error from xen daemon Traceback (most recent call last) File "/usr/sbin/virt-install", line 502, in main() File "/usr/sbin/virt-install", line 462, in main dom = guest.start_install(conscb,progresscb) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 813, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 829, in _do_install self._create_devices(meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 727, in _create_devices nic.setup(self.conn) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 281, in setup vm = conn.lookupByID(id) File "/usr/lib/python2.5/site-packages/libvirt.py", line 920, in lookupByID if ret is None:raise libvirtError('virDomainLookupByID() failed', conn=self) libvirtError: virDomainLookupByID() failed GET operation failed: xend_get: error from xen daemon [root at bacula ~]# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 489 1 r----- 738.2 -- --- Margusja +3725148780 skype: margusja msn: margusja at kodila.ee homepage: http://margusja.pri.ee From phil at pricom.com.au Sat Jul 12 17:50:14 2008 From: phil at pricom.com.au (Philip Rhoades) Date: Sun, 13 Jul 2008 03:50:14 +1000 Subject: [Fedora-xen] Testing LiveCD distros as guests? Message-ID: <4878EED6.9000109@pricom.com.au> People, I want to test out a bunch of LiveCD distributions - is it possible to set these up as guests under Xen so I don't have to shut down my main machine? Thanks, Phil. -- Philip Rhoades Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275) GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil at pricom.com.au From tom.horsley at att.net Sat Jul 12 20:46:06 2008 From: tom.horsley at att.net (Tom Horsley) Date: Sat, 12 Jul 2008 16:46:06 -0400 Subject: [Fedora-xen] Testing LiveCD distros as guests? In-Reply-To: <4878EED6.9000109@pricom.com.au> References: <4878EED6.9000109@pricom.com.au> Message-ID: <20080712164606.492182a9@zooty> On Sun, 13 Jul 2008 03:50:14 +1000 Philip Rhoades wrote: > I want to test out a bunch of LiveCD distributions - is it possible to > set these up as guests under Xen so I don't have to shut down my main > machine? If your hardware supports HVM installs, then just tell virt-manager you are going to install a new HVM virtual machine and the install media is the live cd image. With no HVM support, I don't know - some live CDs might run paravirt, but I have no specific knowledge of such a beast. From rjones at redhat.com Sun Jul 13 21:09:35 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 13 Jul 2008 22:09:35 +0100 Subject: [Fedora-xen] Problem to using virt-install In-Reply-To: <48772123.6090405@kodila.ee> References: <48772123.6090405@kodila.ee> Message-ID: <20080713210935.GA1999@amd.home.annexia.org> On Fri, Jul 11, 2008 at 12:00:19PM +0300, Margusja wrote: > Hello, can somebody give me some hint how to resolve my problem? Looks like xend isn't running on your machine. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From pasik at iki.fi Mon Jul 14 08:07:15 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 14 Jul 2008 11:07:15 +0300 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080705164551.GA8795@redhat.com> References: <20080705164551.GA8795@redhat.com> Message-ID: <20080714080714.GL3771@edu.joroinen.fi> On Sat, Jul 05, 2008 at 05:45:51PM +0100, Daniel P. Berrange wrote: > On Fri, Jul 04, 2008 at 10:24:31PM +0100, Andy Burns wrote: > > Given that xen is entering feature freeze for updated release ~August > > is it too early to ask what the *hopes* are for xen in fedora10? > > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen > RPM and hypervisor. This will at least let people build their own legacy > Xen kernel from upstream's 2.6.18 xen kernel if they're lucky enough to > have hardware which works with it. > If pv_ops dom0 won't be ready for F10, would it be possible to ship xensource 2.6.18 based dom0 kernel? At least that's supported upstream.. Would be better than nothing.. Is there something with pv_ops dom0 work that could be done to help? What's the status atm? -- Pasi From berrange at redhat.com Mon Jul 14 08:47:48 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 14 Jul 2008 09:47:48 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080714080714.GL3771@edu.joroinen.fi> References: <20080705164551.GA8795@redhat.com> <20080714080714.GL3771@edu.joroinen.fi> Message-ID: <20080714084748.GA27537@redhat.com> On Mon, Jul 14, 2008 at 11:07:15AM +0300, Pasi K?rkk?inen wrote: > On Sat, Jul 05, 2008 at 05:45:51PM +0100, Daniel P. Berrange wrote: > > On Fri, Jul 04, 2008 at 10:24:31PM +0100, Andy Burns wrote: > > > Given that xen is entering feature freeze for updated release ~August > > > is it too early to ask what the *hopes* are for xen in fedora10? > > > > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > > > Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen > > RPM and hypervisor. This will at least let people build their own legacy > > Xen kernel from upstream's 2.6.18 xen kernel if they're lucky enough to > > have hardware which works with it. > > > > If pv_ops dom0 won't be ready for F10, would it be possible to ship > xensource 2.6.18 based dom0 kernel? At least that's supported upstream.. > > Would be better than nothing.. No, it is worse than nothing. It is incompatible with a large number of userspace packages which expect interfaces/ABIs from newer kernel versions and thus uttery unsupportable. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pasik at iki.fi Mon Jul 14 08:26:12 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 14 Jul 2008 11:26:12 +0300 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080714080714.GL3771@edu.joroinen.fi> References: <20080705164551.GA8795@redhat.com> <20080714080714.GL3771@edu.joroinen.fi> Message-ID: <20080714082612.GM3771@edu.joroinen.fi> On Mon, Jul 14, 2008 at 11:07:15AM +0300, Pasi K?rkk?inen wrote: > On Sat, Jul 05, 2008 at 05:45:51PM +0100, Daniel P. Berrange wrote: > > On Fri, Jul 04, 2008 at 10:24:31PM +0100, Andy Burns wrote: > > > Given that xen is entering feature freeze for updated release ~August > > > is it too early to ask what the *hopes* are for xen in fedora10? > > > > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > > > Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen > > RPM and hypervisor. This will at least let people build their own legacy > > Xen kernel from upstream's 2.6.18 xen kernel if they're lucky enough to > > have hardware which works with it. > > > > If pv_ops dom0 won't be ready for F10, would it be possible to ship > xensource 2.6.18 based dom0 kernel? At least that's supported upstream.. > > Would be better than nothing.. > Or maybe rhel5 kernel? I understand maintaining multiple kernels is a pain, but then again rhel5 (and xensource 2.6.18 xen) kernels are maintained anyway upstream.. -- Pasi From berrange at redhat.com Mon Jul 14 09:51:53 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 14 Jul 2008 10:51:53 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080714082612.GM3771@edu.joroinen.fi> References: <20080705164551.GA8795@redhat.com> <20080714080714.GL3771@edu.joroinen.fi> <20080714082612.GM3771@edu.joroinen.fi> Message-ID: <20080714095153.GA29536@redhat.com> On Mon, Jul 14, 2008 at 11:26:12AM +0300, Pasi K?rkk?inen wrote: > On Mon, Jul 14, 2008 at 11:07:15AM +0300, Pasi K?rkk?inen wrote: > > On Sat, Jul 05, 2008 at 05:45:51PM +0100, Daniel P. Berrange wrote: > > > On Fri, Jul 04, 2008 at 10:24:31PM +0100, Andy Burns wrote: > > > > Given that xen is entering feature freeze for updated release ~August > > > > is it too early to ask what the *hopes* are for xen in fedora10? > > > > > > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > > > > > Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen > > > RPM and hypervisor. This will at least let people build their own legacy > > > Xen kernel from upstream's 2.6.18 xen kernel if they're lucky enough to > > > have hardware which works with it. > > > > > > > If pv_ops dom0 won't be ready for F10, would it be possible to ship > > xensource 2.6.18 based dom0 kernel? At least that's supported upstream.. > > > > Would be better than nothing.. > > Or maybe rhel5 kernel? No, this is no better - it is still 2.6.18 based which is unsupportable when Fedora is in 2.6.26 > I understand maintaining multiple kernels is a pain, but then again rhel5 > (and xensource 2.6.18 xen) kernels are maintained anyway upstream.. It is not just multiple kernels - it is the age of the kernels - a kernel which is 8 versions behind the non-Xen kernel is not supportable. The situation is either Dom0 pv_ops, or no Dom0 at all. Those are the only two viable options that exist. We can't continue to waste effort on something as old as 2.6.18 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pasik at iki.fi Mon Jul 14 10:18:53 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 14 Jul 2008 13:18:53 +0300 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080714095153.GA29536@redhat.com> References: <20080705164551.GA8795@redhat.com> <20080714080714.GL3771@edu.joroinen.fi> <20080714082612.GM3771@edu.joroinen.fi> <20080714095153.GA29536@redhat.com> Message-ID: <20080714101853.GN3771@edu.joroinen.fi> On Mon, Jul 14, 2008 at 10:51:53AM +0100, Daniel P. Berrange wrote: > On Mon, Jul 14, 2008 at 11:26:12AM +0300, Pasi K?rkk?inen wrote: > > On Mon, Jul 14, 2008 at 11:07:15AM +0300, Pasi K?rkk?inen wrote: > > > On Sat, Jul 05, 2008 at 05:45:51PM +0100, Daniel P. Berrange wrote: > > > > On Fri, Jul 04, 2008 at 10:24:31PM +0100, Andy Burns wrote: > > > > > Given that xen is entering feature freeze for updated release ~August > > > > > is it too early to ask what the *hopes* are for xen in fedora10? > > > > > > > > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > > > > > > > Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen > > > > RPM and hypervisor. This will at least let people build their own legacy > > > > Xen kernel from upstream's 2.6.18 xen kernel if they're lucky enough to > > > > have hardware which works with it. > > > > > > > > > > If pv_ops dom0 won't be ready for F10, would it be possible to ship > > > xensource 2.6.18 based dom0 kernel? At least that's supported upstream.. > > > > > > Would be better than nothing.. > > > > Or maybe rhel5 kernel? > > No, this is no better - it is still 2.6.18 based which is unsupportable > when Fedora is in 2.6.26 > Ok. > > I understand maintaining multiple kernels is a pain, but then again rhel5 > > (and xensource 2.6.18 xen) kernels are maintained anyway upstream.. > > It is not just multiple kernels - it is the age of the kernels - a kernel > which is 8 versions behind the non-Xen kernel is not supportable. > Yep.. I guess it would create too many problems with other packages/software assuming/needing something from the kernel. > The situation is either Dom0 pv_ops, or no Dom0 at all. Those are the > only two viable options that exist. We can't continue to waste effort > on something as old as 2.6.18 > Ok. Thanks for clearing this up (again) :) Now I just wish all the best for pv_ops dom0 work.. Anything people could help with? Any status updates? -- Pasi From pasik at iki.fi Mon Jul 14 10:29:27 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 14 Jul 2008 13:29:27 +0300 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080714084748.GA27537@redhat.com> References: <20080705164551.GA8795@redhat.com> <20080714080714.GL3771@edu.joroinen.fi> <20080714084748.GA27537@redhat.com> Message-ID: <20080714102927.GO3771@edu.joroinen.fi> On Mon, Jul 14, 2008 at 09:47:48AM +0100, Daniel P. Berrange wrote: > On Mon, Jul 14, 2008 at 11:07:15AM +0300, Pasi K?rkk?inen wrote: > > On Sat, Jul 05, 2008 at 05:45:51PM +0100, Daniel P. Berrange wrote: > > > On Fri, Jul 04, 2008 at 10:24:31PM +0100, Andy Burns wrote: > > > > Given that xen is entering feature freeze for updated release ~August > > > > is it too early to ask what the *hopes* are for xen in fedora10? > > > > > > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > > > > > Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen > > > RPM and hypervisor. This will at least let people build their own legacy > > > Xen kernel from upstream's 2.6.18 xen kernel if they're lucky enough to > > > have hardware which works with it. > > > > > > > If pv_ops dom0 won't be ready for F10, would it be possible to ship > > xensource 2.6.18 based dom0 kernel? At least that's supported upstream.. > > > > Would be better than nothing.. > > No, it is worse than nothing. It is incompatible with a large number of > userspace packages which expect interfaces/ABIs from newer kernel versions > and thus uttery unsupportable. > Yeah well, that makes sense.. damn, really crappy situation right now with kernels compatible with xen dom0 :( -- Pasi From bkearney at redhat.com Mon Jul 14 11:32:18 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 14 Jul 2008 07:32:18 -0400 Subject: [Fedora-xen] Testing LiveCD distros as guests? In-Reply-To: <4878EED6.9000109@pricom.com.au> References: <4878EED6.9000109@pricom.com.au> Message-ID: <487B3942.2090502@redhat.com> Philip Rhoades wrote: > People, > > I want to test out a bunch of LiveCD distributions - is it possible to > set these up as guests under Xen so I don't have to shut down my main > machine? > > Thanks, > > Phil. You should be able to launch it via virsh or virt-manager with no issues. -- bk From berrange at redhat.com Mon Jul 14 11:39:40 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 14 Jul 2008 12:39:40 +0100 Subject: [Fedora-xen] Testing LiveCD distros as guests? In-Reply-To: <4878EED6.9000109@pricom.com.au> References: <4878EED6.9000109@pricom.com.au> Message-ID: <20080714113940.GG29536@redhat.com> On Sun, Jul 13, 2008 at 03:50:14AM +1000, Philip Rhoades wrote: > I want to test out a bunch of LiveCD distributions - is it possible to > set these up as guests under Xen so I don't have to shut down my main > machine? Look at the man page for 'virt-install' - in the 'Examples' section it shows how to run a LiveCD. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From winston.l.wang at intel.com Tue Jul 15 00:03:56 2008 From: winston.l.wang at intel.com (Wang, Winston L) Date: Mon, 14 Jul 2008 17:03:56 -0700 Subject: [Fedora-xen] Does anybody know F8 Xen support power managemnet or not? Message-ID: <0B53E02A2965CE4F9ADB38B34501A3A10653FCBB@orsmsx505.amr.corp.intel.com> Hi, Does anybody know F8 Xen support power management or not? I found there is no /sys/power folder after boot. Best Regards, Winston, -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasik at iki.fi Wed Jul 16 12:36:26 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 16 Jul 2008 15:36:26 +0300 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <1215254367.4394.10.camel@muff> References: <1215254367.4394.10.camel@muff> Message-ID: <20080716123626.GH3771@edu.joroinen.fi> On Sat, Jul 05, 2008 at 11:39:27AM +0100, Mark McLoughlin wrote: > On Fri, 2008-07-04 at 22:24 +0100, Andy Burns wrote: > > > Given that xen is entering feature freeze for updated release ~August > > is it too early to ask what the *hopes* are for xen in fedora10? > > There has been very little progress on the Dom0 pv_ops work of late, so > it's getting harder to imagine it being in shape for Fedora 10. Still > hope, for sure, but getting slimmer. > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > Not really important if there's no Dom0 kernel. If there is, we'll > definitely update. > > > kernel 2.6.27(or late rc) with pv_ops for 32 and 64 bit, dom0 and domU? > > I would expect our DomU kernel to continue tracking the bare-metal > kernel versions - so, yeah, 2.6.27 probably. > > Jeremy Fitzhardinge sounds fairly confident of having much of x86_64 > DomU ready for the 2.6.27 merge window. If that happens, our patch set > would be quite small and I'd imagine we'd enable CONFIG_XEN in the > bare-metal kernel and drop the kernel-xen package. > At the moment it looks like x86_64 xen domU patches are going in for 2.6.27. http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary and http://wiki.xensource.com/xenwiki/XenParavirtOps -- Pasi From markmc at redhat.com Wed Jul 16 12:53:03 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 16 Jul 2008 13:53:03 +0100 Subject: [Fedora-xen] F10 crystal ball gazing In-Reply-To: <20080716123626.GH3771@edu.joroinen.fi> References: <1215254367.4394.10.camel@muff> <20080716123626.GH3771@edu.joroinen.fi> Message-ID: <1216212783.29458.8.camel@muff> On Wed, 2008-07-16 at 15:36 +0300, Pasi K?rkk?inen wrote: > On Sat, Jul 05, 2008 at 11:39:27AM +0100, Mark McLoughlin wrote: > > On Fri, 2008-07-04 at 22:24 +0100, Andy Burns wrote: > > > > > Given that xen is entering feature freeze for updated release ~August > > > is it too early to ask what the *hopes* are for xen in fedora10? > > > > There has been very little progress on the Dom0 pv_ops work of late, so > > it's getting harder to imagine it being in shape for Fedora 10. Still > > hope, for sure, but getting slimmer. > > > > > xen 3.3.0 (or late rc) or is this still likely to be 3.2.1 or 3.2.2? > > > > Not really important if there's no Dom0 kernel. If there is, we'll > > definitely update. > > > > > kernel 2.6.27(or late rc) with pv_ops for 32 and 64 bit, dom0 and domU? > > > > I would expect our DomU kernel to continue tracking the bare-metal > > kernel versions - so, yeah, 2.6.27 probably. > > > > Jeremy Fitzhardinge sounds fairly confident of having much of x86_64 > > DomU ready for the 2.6.27 merge window. If that happens, our patch set > > would be quite small and I'd imagine we'd enable CONFIG_XEN in the > > bare-metal kernel and drop the kernel-xen package. > > > > At the moment it looks like x86_64 xen domU patches are going in for 2.6.27. > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary > > and > > http://wiki.xensource.com/xenwiki/XenParavirtOps Yep, and that's excellent progress. As soon as the stock rawhide kernel makes its first move to 2.6.27, I plan to build a new kernel-xen based on that. What we're discussing currently, though, is whether at that point we should immediately progress with the plan of merging kernel-xen back into the stock kernel so that you boot the same pv_ops enabled kernel for Xen DomU and bare-metal. If it looks like the Dom0 work is making progress, we might hold off on doing that until Dom0 is upstream. Personally, I can't see Dom0 being in shape for F10 and so we should proceed with completing the DomU work. Cheers, Mark. From markmc at redhat.com Fri Jul 18 16:26:58 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 18 Jul 2008 17:26:58 +0100 Subject: [Fedora-xen] New kernel-xen in rawhide Message-ID: <1216398418.16264.22.camel@muff> Hi, Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place of Eduardo's xen-pvops-64.git tree. Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 already and the other half is queued up, hopefully to be included before the merge window ends. If we can get that stuff some testing, perhaps it might help the cause of getting it merged. This is all irrelevant if the build fails, of course :-) http://koji.fedoraproject.org/koji/taskinfo?taskID=725025 Cheers, Mark. [1] - http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=shortlog;h=xen-64bit From joe_hesse at actcx.com Fri Jul 18 16:46:45 2008 From: joe_hesse at actcx.com (Joseph Hesse) Date: Fri, 18 Jul 2008 11:46:45 -0500 Subject: [Fedora-xen] Motherboard to Experiment with Xen Message-ID: <000601c8e8f5$e14adaf0$a3e090d0$@com> Hi, Can anyone recommend a motherboard to use to learn Linux virtualization? Better yet, are there any to be avoided? Many thanks, Joe Hesse E-mail message checked by Spyware Doctor (5.5.1.322) Database version: 5.10280e http://www.pctools.com/en/spyware-doctor/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Fri Jul 18 18:10:41 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 18 Jul 2008 19:10:41 +0100 Subject: [Fedora-xen] New kernel-xen in rawhide In-Reply-To: <1216398418.16264.22.camel@muff> References: <1216398418.16264.22.camel@muff> Message-ID: <20080718181041.GB20716@redhat.com> On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > Hi, > Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place > of Eduardo's xen-pvops-64.git tree. > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > already and the other half is queued up, hopefully to be included before > the merge window ends. If we can get that stuff some testing, perhaps it > might help the cause of getting it merged. > > This is all irrelevant if the build fails, of course :-) Seems to have succeeded, so how about putting it into the real kernel RPM directly, and finally kill kernel-xen as an RPM :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From felix.schwarz at web.de Sat Jul 19 12:20:50 2008 From: felix.schwarz at web.de (Felix Schwarz) Date: Sat, 19 Jul 2008 14:20:50 +0200 Subject: [Fedora-xen] Re: Motherboard to Experiment with Xen In-Reply-To: <000601c8e8f5$e14adaf0$a3e090d0$@com> References: <000601c8e8f5$e14adaf0$a3e090d0$@com> Message-ID: <4881DC22.3040301@web.de> Joseph Hesse schrieb: > Can anyone recommend a motherboard to use to learn Linux > virtualization? Better yet, are there any to be avoided? I never had problems getting Xen running on any decent hardware (it worked even on a Compaq/Intel board with a P3). Most of my current hardware is Dell-based but no problems their either. Just look that the CPU/board/bios supports hardware virtualization. And if you don't need special management tools, I would advise starting with KVM because it has some advantages and it looks like Fedora won't have a functional Dom0 on a supported Fedora release in a few months. fs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From lists at akixa.info Mon Jul 21 12:12:59 2008 From: lists at akixa.info (Gerhard Scheffler) Date: Mon, 21 Jul 2008 14:12:59 +0200 Subject: [Fedora-xen] How to kill a domU that has no id Message-ID: <200807211412.59914.lists@akixa.info> How to kill a domU that has no id? # xm list Name ID Mem VCPUs State Time(s) Domain-0 0 512 2 r----- 2745.2 m1 1 1024 2 -b---- 7764.6 m3 2 1024 2 -b---- 6765.8 m4 5 512 2 -b---- 1032.5 m5 512 2 0.0 Does m5 realy consume memory? xm lists m5 even after dom0 reboot. Gerhard From markmc at redhat.com Mon Jul 21 13:13:00 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 21 Jul 2008 14:13:00 +0100 Subject: [Fedora-xen] New kernel-xen in rawhide In-Reply-To: <20080718181041.GB20716@redhat.com> References: <1216398418.16264.22.camel@muff> <20080718181041.GB20716@redhat.com> Message-ID: <1216645980.5090.11.camel@muff> On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > Hi, > > Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to > > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place > > of Eduardo's xen-pvops-64.git tree. > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > already and the other half is queued up, hopefully to be included before > > the merge window ends. If we can get that stuff some testing, perhaps it > > might help the cause of getting it merged. > > > > This is all irrelevant if the build fails, of course :-) > > Seems to have succeeded, so how about putting it into the real kernel > RPM directly, and finally kill kernel-xen as an RPM :-) Yes, I'd very much like to make that happen soon. There are two considerations, though: 1) The second half of the xen x86_64 DomU work has not yet been merged upstream. It's a fairly big patch: 49 files changed, 2344 insertions(+), 913 deletions(-) so, if it doesn't get merged, it's possible it's easier to maintain that patch in a separate kernel-xen RPM. It's also questionable as to whether the stock kernel RPM maintainers would be willing to carry such a big patch. The 2.6.27 merge window is still open, though, so hopefully Ingo will push it up to Linus before it closes and this point will be moot. 2) For the same reasons, if we kill the separate kernel-xen RPM, that restricts our ability to pull in a work-in-progress Dom0 tree in future. I expect if we do kill kernel-xen, we won't see Dom0 in Fedora until it's fully upstream. Since so little progress is being made currently on the Dom0 front, though, I don't think this is a good reason to hold off on merging the RPMs. So, my plan is to push ahead with killing off the separate RPM if the rest of x86_64 DomU gets merged. If it doesn't, then we'll need to take a closer look at how invasive the patch is and discuss it with the core kernel RPM maintainers. Cheers, Mark. From gastonkeller at gmail.com Mon Jul 21 13:26:02 2008 From: gastonkeller at gmail.com (=?ISO-8859-1?Q?Gast=F3n_Keller?=) Date: Mon, 21 Jul 2008 09:26:02 -0400 Subject: [Fedora-xen] How to kill a domU that has no id In-Reply-To: <200807211412.59914.lists@akixa.info> References: <200807211412.59914.lists@akixa.info> Message-ID: On Mon, Jul 21, 2008 at 8:12 AM, Gerhard Scheffler wrote: > How to kill a domU that has no id? xm delete m5 ? I think I have to do that once. > > # xm list > Name ID Mem VCPUs State > Time(s) > Domain-0 0 512 2 r----- 2745.2 > m1 1 1024 2 -b---- 7764.6 > m3 2 1024 2 -b---- 6765.8 > m4 5 512 2 -b---- 1032.5 > m5 512 2 0.0 > > Does m5 realy consume memory? I think it's not consuming memory. The 512 MB allocated are just a statement of how much memory the VM can use, but if it is not running, no memory is being used. Gaston > xm lists m5 even after dom0 reboot. > > Gerhard > > -- > Fedora-xen mailing list > Fedora-xen at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-xen > -- La ?nica verdad es la realidad. From lists at akixa.info Mon Jul 21 14:16:32 2008 From: lists at akixa.info (Gerhard Scheffler) Date: Mon, 21 Jul 2008 16:16:32 +0200 Subject: [Fedora-xen] How to kill a domU that has no id In-Reply-To: References: <200807211412.59914.lists@akixa.info> Message-ID: <200807211616.33271.lists@akixa.info> Am Montag 21 Juli 2008 15:26:02 schrieb Gast?n Keller: > On Mon, Jul 21, 2008 at 8:12 AM, Gerhard Scheffler wrote: > > How to kill a domU that has no id? > > xm delete m5 ? I think I have to do that once. thanks! Gerhard From markmc at redhat.com Mon Jul 21 16:15:41 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 21 Jul 2008 17:15:41 +0100 Subject: [Fedora-xen] New kernel-xen in rawhide In-Reply-To: <1216645980.5090.11.camel@muff> References: <1216398418.16264.22.camel@muff> <20080718181041.GB20716@redhat.com> <1216645980.5090.11.camel@muff> Message-ID: <1216656941.5090.26.camel@muff> On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > Hi, > > > Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to > > > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place > > > of Eduardo's xen-pvops-64.git tree. > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > already and the other half is queued up, hopefully to be included before > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > might help the cause of getting it merged. > > > > > > This is all irrelevant if the build fails, of course :-) > > > > Seems to have succeeded, so how about putting it into the real kernel > > RPM directly, and finally kill kernel-xen as an RPM :-) > > Yes, I'd very much like to make that happen soon. > > There are two considerations, though: > > 1) The second half of the xen x86_64 DomU work has not yet been > merged upstream. It's a fairly big patch: > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > so, if it doesn't get merged, Sweet, Ingo has just pushed it up to Linus: http://lkml.org/lkml/2008/7/21/201 Cheers, Mark. From pasik at iki.fi Thu Jul 24 10:32:37 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 24 Jul 2008 13:32:37 +0300 Subject: [Fedora-xen] New kernel-xen in rawhide In-Reply-To: <1216656941.5090.26.camel@muff> References: <1216398418.16264.22.camel@muff> <20080718181041.GB20716@redhat.com> <1216645980.5090.11.camel@muff> <1216656941.5090.26.camel@muff> Message-ID: <20080724103237.GY3771@edu.joroinen.fi> On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote: > On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > > Hi, > > > > Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to > > > > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place > > > > of Eduardo's xen-pvops-64.git tree. > > > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > > already and the other half is queued up, hopefully to be included before > > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > > might help the cause of getting it merged. > > > > > > > > This is all irrelevant if the build fails, of course :-) > > > > > > Seems to have succeeded, so how about putting it into the real kernel > > > RPM directly, and finally kill kernel-xen as an RPM :-) > > > > Yes, I'd very much like to make that happen soon. > > > > There are two considerations, though: > > > > 1) The second half of the xen x86_64 DomU work has not yet been > > merged upstream. It's a fairly big patch: > > > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > > > so, if it doesn't get merged, > > Sweet, Ingo has just pushed it up to Linus: > > http://lkml.org/lkml/2008/7/21/201 > That's really nice progress with upstream merging.. I still think it might be a good idea to keep separate kernel-xen until upstream has "all" the needed features.. Like said, adding dom0 patches should be easier to separate rpm? -- Pasi From berrange at redhat.com Thu Jul 24 10:37:05 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Jul 2008 11:37:05 +0100 Subject: [Fedora-xen] New kernel-xen in rawhide In-Reply-To: <20080724103237.GY3771@edu.joroinen.fi> References: <1216398418.16264.22.camel@muff> <20080718181041.GB20716@redhat.com> <1216645980.5090.11.camel@muff> <1216656941.5090.26.camel@muff> <20080724103237.GY3771@edu.joroinen.fi> Message-ID: <20080724103705.GM1138@redhat.com> On Thu, Jul 24, 2008 at 01:32:37PM +0300, Pasi K?rkk?inen wrote: > On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote: > > On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > > > Hi, > > > > > Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to > > > > > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place > > > > > of Eduardo's xen-pvops-64.git tree. > > > > > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > > > already and the other half is queued up, hopefully to be included before > > > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > > > might help the cause of getting it merged. > > > > > > > > > > This is all irrelevant if the build fails, of course :-) > > > > > > > > Seems to have succeeded, so how about putting it into the real kernel > > > > RPM directly, and finally kill kernel-xen as an RPM :-) > > > > > > Yes, I'd very much like to make that happen soon. > > > > > > There are two considerations, though: > > > > > > 1) The second half of the xen x86_64 DomU work has not yet been > > > merged upstream. It's a fairly big patch: > > > > > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > > > > > so, if it doesn't get merged, > > > > Sweet, Ingo has just pushed it up to Linus: > > > > http://lkml.org/lkml/2008/7/21/201 > > > > That's really nice progress with upstream merging.. > > I still think it might be a good idea to keep separate kernel-xen until > upstream has "all" the needed features.. > > Like said, adding dom0 patches should be easier to separate rpm? Possibly - that's TDB when we have working Dom0 patches again. The Dom0 patches will have to work against latest LKML tree, so it might turn out to be easy to do against the main kernel RPM. It really depends how unstable/invasive Dom0 bits are. This is a decision that is independant of the guest stuff though. In terms of guest support, we absolutely want 1 kernel for F10. A core point of paravirt_ops is that a single kernel binary can boot and auto detect the hypervisor its running on. This means we can get rid of the separate vmlinuz/initrd in the install trees, get rid of anaconda logic to install a different kernel in Xen guests, and lots of other cleanup. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From markmc at redhat.com Thu Jul 24 10:53:01 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 24 Jul 2008 11:53:01 +0100 Subject: [Fedora-xen] New kernel-xen in rawhide In-Reply-To: <20080724103237.GY3771@edu.joroinen.fi> References: <1216398418.16264.22.camel@muff> <20080718181041.GB20716@redhat.com> <1216645980.5090.11.camel@muff> <1216656941.5090.26.camel@muff> <20080724103237.GY3771@edu.joroinen.fi> Message-ID: <1216896781.19852.8.camel@muff> On Thu, 2008-07-24 at 13:32 +0300, Pasi K?rkk?inen wrote: > I still think it might be a good idea to keep separate kernel-xen until > upstream has "all" the needed features.. > > Like said, adding dom0 patches should be easier to separate rpm? Yeah, it's a trade-off. But consider: a) davej is rebasing the stock kernel up to twice daily; it would be a huge time sync to try and keep kernel-xen in sync with that pace; b) There's relatively little Dom0 work going on a the moment, so there's little chance of having usable Dom0 patches for Fedora 10 c) It's not inconceivable that we could add work-in-progress Dom0 patches to kernel/devel; the bar would be higher than for kernel-xen, though I sent a bunch of patches to fedora-kernel-list yesterday: https://www.redhat.com/archives/fedora-kernel-list/2008-July/thread.html#00062 Cheers, Mark. From pasik at iki.fi Thu Jul 24 10:56:29 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 24 Jul 2008 13:56:29 +0300 Subject: [Fedora-xen] New kernel-xen in rawhide In-Reply-To: <20080724103705.GM1138@redhat.com> References: <1216398418.16264.22.camel@muff> <20080718181041.GB20716@redhat.com> <1216645980.5090.11.camel@muff> <1216656941.5090.26.camel@muff> <20080724103237.GY3771@edu.joroinen.fi> <20080724103705.GM1138@redhat.com> Message-ID: <20080724105629.GA3771@edu.joroinen.fi> On Thu, Jul 24, 2008 at 11:37:05AM +0100, Daniel P. Berrange wrote: > On Thu, Jul 24, 2008 at 01:32:37PM +0300, Pasi K?rkk?inen wrote: > > On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote: > > > On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > > > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > > > > Hi, > > > > > > Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to > > > > > > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place > > > > > > of Eduardo's xen-pvops-64.git tree. > > > > > > > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > > > > already and the other half is queued up, hopefully to be included before > > > > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > > > > might help the cause of getting it merged. > > > > > > > > > > > > This is all irrelevant if the build fails, of course :-) > > > > > > > > > > Seems to have succeeded, so how about putting it into the real kernel > > > > > RPM directly, and finally kill kernel-xen as an RPM :-) > > > > > > > > Yes, I'd very much like to make that happen soon. > > > > > > > > There are two considerations, though: > > > > > > > > 1) The second half of the xen x86_64 DomU work has not yet been > > > > merged upstream. It's a fairly big patch: > > > > > > > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > > > > > > > so, if it doesn't get merged, > > > > > > Sweet, Ingo has just pushed it up to Linus: > > > > > > http://lkml.org/lkml/2008/7/21/201 > > > > > > > That's really nice progress with upstream merging.. > > > > I still think it might be a good idea to keep separate kernel-xen until > > upstream has "all" the needed features.. > > > > Like said, adding dom0 patches should be easier to separate rpm? > > Possibly - that's TDB when we have working Dom0 patches again. The Dom0 > patches will have to work against latest LKML tree, so it might turn > out to be easy to do against the main kernel RPM. It really depends how > unstable/invasive Dom0 bits are. This is a decision that is independant > of the guest stuff though. > Ok. > In terms of guest support, we absolutely want 1 kernel for F10. A core > point of paravirt_ops is that a single kernel binary can boot and auto > detect the hypervisor its running on. This means we can get rid of the > separate vmlinuz/initrd in the install trees, get rid of anaconda logic > to install a different kernel in Xen guests, and lots of other cleanup. > That makes sense. Thanks. -- Pasi From markmc at redhat.com Thu Jul 24 17:46:57 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 24 Jul 2008 18:46:57 +0100 Subject: [Fedora-xen] kernel-xen is dead Message-ID: <1216921617.19183.18.camel@muff> Hey, When this build finishes: http://koji.fedoraproject.org/koji/buildinfo?buildID=57402 rawhide kernel-PAE.i686 and kernel.x86_64 will contain support for i686 and x86_64 Xen DomU guests. We've added Obsoletes/Provides, so a simple yum update should work fine[1]. Today the world has been made a little more sane. Rejoice :-) Cheers, Mark. [1] - With the caveat that the new kernel won't be made the default in grub.conf ... I'll fix up that soon, see: https://bugzilla.redhat.com/show_bug.cgi?id=456558 From paul at xelerance.com Thu Jul 24 18:24:35 2008 From: paul at xelerance.com (Paul Wouters) Date: Thu, 24 Jul 2008 14:24:35 -0400 (EDT) Subject: [Fedora-xen] kernel-xen is dead In-Reply-To: <1216921617.19183.18.camel@muff> References: <1216921617.19183.18.camel@muff> Message-ID: On Thu, 24 Jul 2008, Mark McLoughlin wrote: > When this build finishes: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=57402 > > rawhide kernel-PAE.i686 and kernel.x86_64 will contain support for i686 > and x86_64 Xen DomU guests. > > We've added Obsoletes/Provides, so a simple yum update should work > fine[1]. > > Today the world has been made a little more sane. Rejoice :-) But not dom0 right? Is there a doc somewhere to say how to migrate from Xen boots using rootfs (not bootable disk image) to kvm? Paul From markmc at redhat.com Fri Jul 25 14:46:33 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 25 Jul 2008 15:46:33 +0100 Subject: [Fedora-xen] kernel-xen is dead In-Reply-To: References: <1216921617.19183.18.camel@muff> Message-ID: <1216997193.7098.56.camel@muff> On Thu, 2008-07-24 at 14:24 -0400, Paul Wouters wrote: > On Thu, 24 Jul 2008, Mark McLoughlin wrote: > > > When this build finishes: > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=57402 > > > > rawhide kernel-PAE.i686 and kernel.x86_64 will contain support for i686 > > and x86_64 Xen DomU guests. > > > > We've added Obsoletes/Provides, so a simple yum update should work > > fine[1]. > > > > Today the world has been made a little more sane. Rejoice :-) > > But not dom0 right? Correct; no dom0 support. > Is there a doc somewhere to say how to migrate from Xen boots using rootfs > (not bootable disk image) to kvm? You mean it's a disk image with no partition table and bootloader? So, you're booting the guest by specifying a kernel and initrd along with the disk image? If so, you should be able to do exactly the same with KVM - you'll just need to manually create a suitable initrd using whatever method you used to create the original initrd for Xen. But no, I don't know of any good docs describing how to migrate xen guests to KVM ... it'd be very cool if someone could write something up on fedoraproject.org/wiki as they go through the process, though ... Cheers, Mark. From addw at phcomp.co.uk Fri Jul 25 14:59:13 2008 From: addw at phcomp.co.uk (Alain Williams) Date: Fri, 25 Jul 2008 15:59:13 +0100 Subject: [Fedora-xen] kernel-xen is dead In-Reply-To: <1216997193.7098.56.camel@muff> References: <1216921617.19183.18.camel@muff> <1216997193.7098.56.camel@muff> Message-ID: <20080725145913.GO6297@mint.phcomp.co.uk> On Fri, Jul 25, 2008 at 03:46:33PM +0100, Mark McLoughlin wrote: > On Thu, 2008-07-24 at 14:24 -0400, Paul Wouters wrote: > > On Thu, 24 Jul 2008, Mark McLoughlin wrote: > > > > > When this build finishes: > > > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=57402 > > > > > > rawhide kernel-PAE.i686 and kernel.x86_64 will contain support for i686 > > > and x86_64 Xen DomU guests. > > > > > > We've added Obsoletes/Provides, so a simple yum update should work > > > fine[1]. > > > > > > Today the world has been made a little more sane. Rejoice :-) > > > > But not dom0 right? > > Correct; no dom0 support. I rebuilt my test/debug box with fedora 9 to find that it will not do dom0. I am going to have to wipe & install fedora 8 or CentOS 5 or something. 1) will dom0 appear (be added back) at some point in fedora 9 lifetime ? 2) why was it taken out ? I gather that dom0 support will be added back in fedora 10. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include From markmc at redhat.com Fri Jul 25 16:27:28 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 25 Jul 2008 17:27:28 +0100 Subject: [Fedora-xen] kernel-xen is dead In-Reply-To: <20080725145913.GO6297@mint.phcomp.co.uk> References: <1216921617.19183.18.camel@muff> <1216997193.7098.56.camel@muff> <20080725145913.GO6297@mint.phcomp.co.uk> Message-ID: <1217003248.7098.73.camel@muff> Hi, All your questions are covered in the archives, btw ... On Fri, 2008-07-25 at 15:59 +0100, Alain Williams wrote: > 1) will dom0 appear (be added back) at some point in fedora 9 lifetime ? Highly unlikely it'll appear as an F9 update, no. > 2) why was it taken out ? kernel-xen lagged the bare-metal kernel by several release; we no longer wanted to waste time forward porting the 2.6.18 tree, so we switched over to what's upstream - 32 and 64 bit pv_ops DomU See also: http://markmc.fedorapeople.org/XenSummit.pdf > I gather that dom0 support will be added back in fedora 10. That's looking rather unlikely at this point since there hasn't been much progress of late. It'll be in Fedora as soon (and maybe even shortly before) it's available upstream in Linus's tree. Cheers, Mark. From dlbewley at lib.ucdavis.edu Sat Jul 26 16:35:51 2008 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Sat, 26 Jul 2008 09:35:51 -0700 Subject: [Fedora-xen] kernel-xen is dead In-Reply-To: References: <1216921617.19183.18.camel@muff> Message-ID: <1217090151.3115.16.camel@seitan.home.bewley.net> On Thu, 2008-07-24 at 14:24 -0400, Paul Wouters wrote: > Is there a doc somewhere to say how to migrate from Xen boots using rootfs > (not bootable disk image) to kvm? There are some of us with some fairly substantial servers bought just a few years ago that don't have hardware virtualization support. I believe KVM still requires such support, and I don't know if that's ever going to change. So, until there is a new dom0 in Fedora there will be us poor souls living back on F8 with little budget to swap out and buy HVM capable hardware. As long as future fedora domU's continue to work on F8 dom0, I suppose we can float along for a couple of releases until something changes. It's a little worrisome that patches won't be forthcoming for F8, but we can mitigate that somewhat by running little more than the hypervisor on the dom0. Keep up the great work and forward momentum, but have pity on those of us using Fedora in production with the above limitations. From davidsen at tmr.com Sat Jul 26 16:48:37 2008 From: davidsen at tmr.com (Bill Davidsen) Date: Sat, 26 Jul 2008 12:48:37 -0400 Subject: [Fedora-xen] Re: kernel-xen is dead In-Reply-To: <1216997193.7098.56.camel@muff> References: <1216921617.19183.18.camel@muff> <1216997193.7098.56.camel@muff> Message-ID: <488B5565.4020309@tmr.com> Mark McLoughlin wrote: > On Thu, 2008-07-24 at 14:24 -0400, Paul Wouters wrote: >> On Thu, 24 Jul 2008, Mark McLoughlin wrote: >> >>> When this build finishes: >>> >>> http://koji.fedoraproject.org/koji/buildinfo?buildID=57402 >>> >>> rawhide kernel-PAE.i686 and kernel.x86_64 will contain support for i686 >>> and x86_64 Xen DomU guests. >>> >>> We've added Obsoletes/Provides, so a simple yum update should work >>> fine[1]. >>> >>> Today the world has been made a little more sane. Rejoice :-) >> But not dom0 right? > > Correct; no dom0 support. > >> Is there a doc somewhere to say how to migrate from Xen boots using rootfs >> (not bootable disk image) to kvm? > > You mean it's a disk image with no partition table and bootloader? > > So, you're booting the guest by specifying a kernel and initrd along > with the disk image? > > If so, you should be able to do exactly the same with KVM - you'll just > need to manually create a suitable initrd using whatever method you used > to create the original initrd for Xen. > > But no, I don't know of any good docs describing how to migrate xen > guests to KVM ... it'd be very cool if someone could write something up > on fedoraproject.org/wiki as they go through the process, though ... > There's a tool, I don't have the name handy, but I saw it on either the rawhide or FC9-testing update notices. Give me an hour or two to look on the machine I use for that stuff and I'll post it. -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot From davidsen at tmr.com Sat Jul 26 17:01:45 2008 From: davidsen at tmr.com (Bill Davidsen) Date: Sat, 26 Jul 2008 13:01:45 -0400 Subject: [Fedora-xen] Re: Testing LiveCD distros as guests? In-Reply-To: <4878EED6.9000109@pricom.com.au> References: <4878EED6.9000109@pricom.com.au> Message-ID: <488B5879.2020903@tmr.com> Philip Rhoades wrote: > People, > > I want to test out a bunch of LiveCD distributions - is it possible to > set these up as guests under Xen so I don't have to shut down my main > machine? > If you have HVM, probably yes (although you might have better luck with kvm), otherwise it requires paravirt support in the Live-CD, which moves it to the "it depends" column. I have done all my testing using KVM, due to the dubious state of xen WRT FC{9,10}. And frankly I find it as easy to use unless I have a bunch of VMs on a single host. -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot From smooge at gmail.com Sat Jul 26 17:33:42 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 26 Jul 2008 11:33:42 -0600 Subject: [Fedora-xen] kernel-xen is dead In-Reply-To: <1217090151.3115.16.camel@seitan.home.bewley.net> References: <1216921617.19183.18.camel@muff> <1217090151.3115.16.camel@seitan.home.bewley.net> Message-ID: <80d7e4090807261033y69ad3223s36ee5c650df38467@mail.gmail.com> On Sat, Jul 26, 2008 at 10:35 AM, Dale Bewley wrote: > On Thu, 2008-07-24 at 14:24 -0400, Paul Wouters wrote: >> Is there a doc somewhere to say how to migrate from Xen boots using rootfs >> (not bootable disk image) to kvm? > > There are some of us with some fairly substantial servers bought just a > few years ago that don't have hardware virtualization support. I believe > KVM still requires such support, and I don't know if that's ever going > to change. > > So, until there is a new dom0 in Fedora there will be us poor souls > living back on F8 with little budget to swap out and buy HVM capable > hardware. As long as future fedora domU's continue to work on F8 dom0, I > suppose we can float along for a couple of releases until something > changes. > > It's a little worrisome that patches won't be forthcoming for F8, but we > can mitigate that somewhat by running little more than the hypervisor on > the dom0. > > Keep up the great work and forward momentum, but have pity on those of > us using Fedora in production with the above limitations. > I think that in those cases for long term support you will want to Look at running RHEL/CentOS-5 for the Dom0. This should allow you to have the DomU's to be newer versions and keep the non-HVM hardware useful. > -- > Fedora-xen mailing list > Fedora-xen at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-xen > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From berrange at redhat.com Sun Jul 27 17:52:24 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 27 Jul 2008 18:52:24 +0100 Subject: [Fedora-xen] kernel-xen is dead In-Reply-To: <1217090151.3115.16.camel@seitan.home.bewley.net> References: <1216921617.19183.18.camel@muff> <1217090151.3115.16.camel@seitan.home.bewley.net> Message-ID: <20080727175224.GC11676@redhat.com> On Sat, Jul 26, 2008 at 09:35:51AM -0700, Dale Bewley wrote: > On Thu, 2008-07-24 at 14:24 -0400, Paul Wouters wrote: > > Is there a doc somewhere to say how to migrate from Xen boots using rootfs > > (not bootable disk image) to kvm? > > There are some of us with some fairly substantial servers bought just a > few years ago that don't have hardware virtualization support. I believe > KVM still requires such support, and I don't know if that's ever going > to change. > > So, until there is a new dom0 in Fedora there will be us poor souls > living back on F8 with little budget to swap out and buy HVM capable > hardware. As long as future fedora domU's continue to work on F8 dom0, I > suppose we can float along for a couple of releases until something > changes. > > It's a little worrisome that patches won't be forthcoming for F8, but we > can mitigate that somewhat by running little more than the hypervisor on > the dom0. > > Keep up the great work and forward momentum, but have pity on those of > us using Fedora in production with the above limitations. We feel the pain too. We'd love to be able to offer a virtualization host which didn't require hardware virt support, but its just not viable until Dom0 is ported to pv_ops. The best bet if you want something to use in a production scenario is to use RHEL-5 or CentOS-5, since these have a much longer lifetime than Fedora for updates & hardware enablement (Fedora 8 will go end-of-life shortly after f10 comes out). Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From lucarx76 at gmail.com Tue Jul 29 00:21:03 2008 From: lucarx76 at gmail.com (Luca) Date: Mon, 28 Jul 2008 17:21:03 -0700 Subject: [Fedora-xen] source code Message-ID: <3d87aabd0807281721v51fd39c1xebdaf3e0a07d0cac@mail.gmail.com> Hi all, I'm using Fedora 8. With yum install xen yum groupinstall 'Virtualization' I can install XEN and Domain 0 and everything works. Now I would like to get the source code for the version of XEN and the kernel installed with the previous commands (I eventually need to modify and recompile them). How can I get the source code? Thanks in advance. Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora.lists at burns.me.uk Tue Jul 29 00:50:26 2008 From: fedora.lists at burns.me.uk (Andy Burns) Date: Tue, 29 Jul 2008 01:50:26 +0100 Subject: [Fedora-xen] source code In-Reply-To: <3d87aabd0807281721v51fd39c1xebdaf3e0a07d0cac@mail.gmail.com> References: <3d87aabd0807281721v51fd39c1xebdaf3e0a07d0cac@mail.gmail.com> Message-ID: 2008/7/29 Luca : > I'm using Fedora 8 With > yum install xen > yum groupinstall 'Virtualization' > > How can I get the source code? Install the corresponding SRPM for each RPM you have installed, I believe the yum-utils package provides some helpers for this http://wiki.linux.duke.edu/YumFaq#head-134041fa9924034f794dac660334b4d8ffc66491 you will want to do a yum groupinstall "Development Tools" too From lucarx76 at gmail.com Wed Jul 30 01:27:06 2008 From: lucarx76 at gmail.com (Luca) Date: Tue, 29 Jul 2008 18:27:06 -0700 Subject: [Fedora-xen] diskless boot Message-ID: <3d87aabd0807291827j3bbc083cue5ebf70dbe36df@mail.gmail.com> Hi all, following the fedora-xen instruction, I was able to install XEN and Domain 0 and create an initial ram disk with mkinitrd (which will then mount the real root filesystem located on an hard drive on the same workstation). I wonder if what follows, is possible. On a workstation, I would not install anything. Instead I would use etherboot, for instance, to download Xen hypervisor, Domain 0 and an initial ram disk from a server. Everything would be loaded in memory. The initial ram disk would then mount the real root filesystem, located this time not on the same workstation, but on a different workstation connected to the network. I have tried building by myself an initial ram disk capable of mounting a real filesystem located on a different workstation but it didn't work. I'm not a fedora or Xen expert, so I hope someone here could help me. Of course, I assume the NFS server is working. Thanks, Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From deshantm at gmail.com Wed Jul 30 01:36:13 2008 From: deshantm at gmail.com (Todd Deshane) Date: Tue, 29 Jul 2008 21:36:13 -0400 Subject: [Fedora-xen] diskless boot In-Reply-To: <3d87aabd0807291827j3bbc083cue5ebf70dbe36df@mail.gmail.com> References: <3d87aabd0807291827j3bbc083cue5ebf70dbe36df@mail.gmail.com> Message-ID: <1e16a9ed0807291836n78284edevc00587fbd87021df@mail.gmail.com> On Tue, Jul 29, 2008 at 9:27 PM, Luca wrote: > Hi all, > following the fedora-xen instruction, I was able to install XEN and Domain > 0 and create an initial ram disk with mkinitrd (which will then mount the > real root filesystem located on an hard drive on the same workstation). > > I wonder if what follows, is possible. > > On a workstation, I would not install anything. Instead I would use > etherboot, for instance, to download Xen hypervisor, Domain 0 and an initial > ram disk from a server. Everything would be loaded in memory. The initial > ram disk would then mount the real root filesystem, located this time not on > the same workstation, but on a different workstation connected to the > network. > > I have tried building by myself an initial ram disk capable of mounting a > real filesystem located on a different workstation but it didn't work. I'm > not a fedora or Xen expert, so I hope someone here could help me. > This claims to be out of date, but maybe it will give you some hints. http://fedoraproject.org/wiki/StatelessLinux/NFSRoot Cheers, Todd > Of course, I assume the NFS server is working. > > Thanks, > Luca > > -- > Fedora-xen mailing list > Fedora-xen at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-xen > > -- Todd Deshane http://todddeshane.net check out our book: http://runningxen.com From pasik at iki.fi Thu Jul 31 07:13:23 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 31 Jul 2008 10:13:23 +0300 Subject: [Fedora-xen] [Xen-devel] State of Xen in upstream Linux Message-ID: <20080731071323.GE3771@edu.joroinen.fi> ----- Forwarded message from Jeremy Fitzhardinge ----- From: Jeremy Fitzhardinge To: Xen-devel , xen-users at lists.xensource.com, Virtualization Mailing List Cc: Date: Wed, 30 Jul 2008 17:51:37 -0700 Subject: [Xen-devel] State of Xen in upstream Linux Well, the mainline kernel just hit 2.6.27-rc1, so it's time for an update about what's new with Xen. I'm trying to aim this at both the user and developer audiences, so bear with me if I seem to be waffling about something irrelevant. 2.6.26 was mostly a bugfix update compared with 2.6.25, with a few small issues fixed up. Feature-wise, it supports 32-bit domU with the core devices needed to make it work (netfront, blockfront, console). It also has xen-pvfb support, which means you can run the standard X server without needing to set up Xvnc. I don't know of any bugs in 2.6.26, so I'd recommend you try it out for all your 32-bit domU needs. It has had fairly wide exposure in Fedora kernels, so I'd rank its stability as fairly high. If you're migrating from 2.6.18-xen, then there'll be a few things you need to pay attention to. http://wiki.xensource.com/xenwiki/XenParavirtOps should help, but if it doesn't, please either fix it and/or ask! 2.6.27 will be a much more interesting release. It has two major feature additions: save/restore/migrate (including checkpoint and live migration), and x86-64 support. In keeping with the overall unification of i386 and x86-64 code in the kernel, the 32- and 64-bit Xen code is largely shared, so they have feature parity. The Xen support seems fairly stable in linux-2.6.git, but the kernel is still at -rc1, so lots of other things will tend to break. I encourage you to try it out if you're comfortable with what's still a fairly high rate of change. My current patch stack is pretty much empty - everything has been merged into linux-2.6.git - so it makes a good base for any changes you may have Now that Xen can directly boot a bzImage format kernel, distros have a lot of flexibilty in how they package Xen. A single grub.conf entry can be used to boot either a native kernel (via normal grub), or a paravirtualized Xen kernel (via pygrub), without modification. Fedora 9's kernel-xen package has been based on the mainline kernel from the outset, but it is still packaged as a separate kernel. kernel-xen has been dropped from rawhide (what will become Fedora 10), and all Xen support - both 32 and 64 bit - has been rolled into the main kernel package. So, what's next? The obvious big piece of missing functionality is dom0 support. That will be my focus in this next kernel development window, and I hope we'll have it merged into 2.6.28. Some roadblock may appear which prevents this (kernel development is always a bit uncertain), but that's the current plan. We're planning on setting up a xen.git on xen.org somewhere. We still need to work out the precise details, but my expectation is that will become the place where dom0 work continues, and I also hope that other Xen developers will start using it as the base for their own Xen work. Expect to see some more concrete details over the next week or so. What can I do? I'm glad you asked. Here's my current TODO list. These are mostly fairly small-scale projects which just need some attention. I'd love people to adopt things from this list. x86-64: SMP broken with CONFIG_PREEMPT It crashes early after bringing up a second CPU when preempt is enabled. I think it's failing to set up the CPU topology properly, and leaving something uninitialized. The desired topology is the simplest possible - one core per package, no SMT/HT, no multicore, no shared caches. It should be simple to set up. irq balancing causes lockups Using irq balancing causes the kernel to lock up after a while. It looks like it's losing interrupts. It's probably dropping interrupts if you migrate an irq beween vcpus while an event is pending. Shouldn't be too hard to fix. (In the meantime, the workaround is to make sure that you don't enable in-kernel irq balancing, and you don't run irqbalanced.) block device hotplug Hotplugging devices should work already, but I haven't really tested it. Need to make sure that both the in-kernel driver stuff works properly, and that udev events are raised properly, scripts run, device nodes added - and conversely for unplug. Also, a modular xen-blockfront.ko should be unloadable. net device hotplug Similar to block devices, but with a slight extra complication. If the driver has outstanding granted pages, then the module can't be immediately unloaded, because you can't free the pages if dom0 has a reference to them. My thought is to add a simple kernel thread which takes ownership of unwanted granted pages: it would periodically try to ungrant them, and if successful, free the page. That means that netfront could hand ownership of those pages over to that thread, and unload immediately. Performance measurement and tuning By design, the paravirt-ops-based Xen implementation should have high performance. It uses batching where-ever possible, late pin/early unpin, and all the other performance tricks available to a Xen kernel. However, my emphasis has been on correctness and features, so I have not extensively benchmarked or performance tuned the code. There's plenty of scope for measuring both synthetic and real-world benchmarks (ideally, applications you really care about), and try to work out how things can be tuned. One thing that has already come to light is a general regression in context switch time compared to 2.6.18.8-xen. It's unclear where it's coming from; a close look at the actual context switch code itself shows that it should perform the same as 2.6.18-xen (same number of hypercalls performed, for example). This would be an excellent opportunity to become familiar with Xen's tracing and performance measurement tools... Balloon driver The current in-kernel balloon driver only supports shrinking and regrowing a domain up to its original size. There's no support for growing a domain beyond that. My plan is to use hotplug memory to add new memory to the system. I have some prototype code to do this, which works OK, but the hotplug memory subsystem needs some modifications to really deal with the kinds of incremental memory increases that we need for ballooning (it assumes that you're actually plugging in physical DIMMs). The other area which needs attention is some sanity checking when deflating a domain, to prevent killing the domain by stealing too much memory. 2.6.18-xen uses a simple static minimum memory heuristic based on the original size of the domain. This helps, but doesn't really prevent over-shrinking a domain which is already under memory pressure. A better approach might be to register a shrinker callback, which means that the balloon driver can see how much memory pressure the system is under by looking getting feedback from it. A more advanced project is to modify the kernel VM subsystem to measure refault distance, which is how long a page is evicted before being faulted back in again. That measurement can tell you how much more memory you need to add to a domain in order to get the fault rate below a given rate. gdb gives bad info in a 64-bit domain For some reason, gdb doesn't work properly. If you set a breakpoint, the program will stop as expected, but the register state will be wrong. Other users of the ptrace syscall, such as strace, seem to get good results, so I'm not sure what's going on here. It might be a simple fix, or symptomatic of a more serious problem. But it needs investigation first. My Pet Project What's missing? What do you depend on? What's needed before you can use mainline Xen as your sole Xen kernel? Thanks, J From paul at xelerance.com Thu Jul 31 14:47:55 2008 From: paul at xelerance.com (Paul Wouters) Date: Thu, 31 Jul 2008 10:47:55 -0400 (EDT) Subject: [Fedora-xen] [Xen-devel] State of Xen in upstream Linux In-Reply-To: <20080731071323.GE3771@edu.joroinen.fi> References: <20080731071323.GE3771@edu.joroinen.fi> Message-ID: Thanks for the xen writeup. I hope to be able to stick to xen, which for me means having dom0 support. > My Pet Project > > What's missing? What do you depend on? What's needed before you > can use mainline Xen as your sole Xen kernel? What has been missing from the start, and is becoming more and more painful, is the lack of entropy/random in the guests. Having openssh not start due to not having entropy, or have openswan block way too long is causing me troubles. Somehow linking the guests random to the host's random seems to be a very useful feature to have, since all the entropy gathering device drivers are not present in guests. Paul From berrange at redhat.com Thu Jul 31 15:18:42 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 31 Jul 2008 16:18:42 +0100 Subject: [Fedora-xen] [Xen-devel] State of Xen in upstream Linux In-Reply-To: References: <20080731071323.GE3771@edu.joroinen.fi> Message-ID: <20080731151842.GI18548@redhat.com> On Thu, Jul 31, 2008 at 10:47:55AM -0400, Paul Wouters wrote: > > Thanks for the xen writeup. I hope to be able to stick to xen, which for me > means > having dom0 support. > > >My Pet Project > > > > What's missing? What do you depend on? What's needed before you > > can use mainline Xen as your sole Xen kernel? > > What has been missing from the start, and is becoming more and more > painful, is > the lack of entropy/random in the guests. Having openssh not start due to > not > having entropy, or have openswan block way too long is causing me troubles. > > Somehow linking the guests random to the host's random seems to be a very > useful feature to have, since all the entropy gathering device drivers are > not present in guests. It has already been tried - at least for lguest - rusty's VirtIO-RNG patch in this thread... http://kerneltrap.org/mailarchive/linux-kernel/2008/5/15/1836574 http://kerneltrap.org/mailarchive/linux-kernel/2008/5/16/1841664 No idea, offhand, if that was ever merged. Using it would involve creating a Xen VirtIO transport I guess. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|