From loganjerry at gmail.com Mon Aug 3 21:19:17 2009 From: loganjerry at gmail.com (Jerry James) Date: Mon, 3 Aug 2009 15:19:17 -0600 Subject: [fedora-virt] end_request: I/O error, dev vda, sector 0 Message-ID: <870180fe0908031419k353d3ad4sb3ae4b49b36cf061@mail.gmail.com> On Thu, Jul 2, 2009 at 8:55 AM, Jerry James wrote: > I just made a Rawhide virtual machine to see if it suffers from the > same problem. ?Zillions of copies of this message are being spewed to > the console, although the machine itself seems to be running normally > (if sluggishly): > > end_request: I/O error, dev vda, sector 0 > > Any idea what that's all about? On a Fedora 11 x86_64 host with the latest updates installed, I just made a fresh KVM guest with virt-manager. I made the disk image fresh, too, just in case that had something to do with it. I installed Rawhide. I cannot login through GDM for reasons I haven't tracked down yet. Sending Ctrl+Alt+F2 to the guest gives me a text console where the message above is printed frequently. Is anybody else seeing this? -- Jerry James http://www.jamezone.org/ From markmc at redhat.com Tue Aug 4 15:36:37 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 04 Aug 2009 16:36:37 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249057022.3320.35.camel@blaa> References: <1244034684.5001.134.camel@blaa> <1244046483.5001.180.camel@blaa> <1244197459.27876.0.camel@blaa> <1246303956.11688.148.camel@blaa> <1246628572.13604.2.camel@blaa> <1246636154.13604.8.camel@blaa> <1247763853.3038.105.camel@blaa> <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> Message-ID: <1249400197.3212.73.camel@blaa> More updates available in http://markmc.fedorapeople.org/virt-preview Thanks to Jan for reporting the extboot issue == qemu == * Tue Aug 4 2009 Mark McLoughlin - 2:0.10.91-0.4.rc1 - Update to qemu-kvm-0.11-rc1; no changes from rc1-rc0 * Tue Aug 4 2009 Mark McLoughlin - 2:0.10.91-0.3.rc1.rc0 - Fix extboot checksum (bug #514899) Cheers, Mark. From rjones at redhat.com Tue Aug 4 15:47:22 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 4 Aug 2009 16:47:22 +0100 Subject: [fedora-virt] Supermin question In-Reply-To: <6172c17e0907310823v60edaf0fu6567219f2cefe4cf@mail.gmail.com> References: <6172c17e0907310823v60edaf0fu6567219f2cefe4cf@mail.gmail.com> Message-ID: <20090804154722.GA13372@amd.home.annexia.org> On Fri, Jul 31, 2009 at 09:23:02AM -0600, Thomas S Hatch wrote: > I imagine I am missing something obvious, but I can't figure out how to > start a supermin appliance. I ran the helper script and generated my initrd > and symbolic link to my kernel, but I can't figure out how to use it beyond > that, how to actually boot it. Not quite sure what you're wanting to do with it, but you can create & boot the supermin appliance just by running any libguestfs-using program, eg. $ ./fish/guestfish -v alloc /tmp/test.img 10M : time run 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 jlaska at redhat.com Tue Aug 4 20:26:39 2009 From: jlaska at redhat.com (James Laska) Date: Tue, 04 Aug 2009 16:26:39 -0400 Subject: [fedora-virt] sysrq key when using 'virsh console' Message-ID: <1249417599.2835.52.camel@flatline.devel.redhat.com> Greetings, I'm not able to find if this exists or not, but in attempting to debug a problem observed in a guest, I need to grab output from several sysrq commands. Does the kvm ttyS0 console offer a sysrq hotkey when connecting using 'virsh console'? Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ondrejj at salstar.sk Wed Aug 5 07:30:59 2009 From: ondrejj at salstar.sk (=?utf-8?B?SsOhbiBPTkRSRUogKFNBTCk=?=) Date: Wed, 5 Aug 2009 09:30:59 +0200 Subject: [fedora-virt] sysrq key when using 'virsh console' In-Reply-To: <1249417599.2835.52.camel@flatline.devel.redhat.com> References: <1249417599.2835.52.camel@flatline.devel.redhat.com> Message-ID: <20090805073059.GJ10711@salstar.sk> On Tue, Aug 04, 2009 at 04:26:39PM -0400, James Laska wrote: > I'm not able to find if this exists or not, but in attempting to debug a > problem observed in a guest, I need to grab output from several sysrq > commands. > > Does the kvm ttyS0 console offer a sysrq hotkey when connecting using > 'virsh console'? Hello, I am interested too to use this function. There was "xm sysrq" for xen, but I can't see any ability to send sysrq commands to guests in KVM. My script for backups of virtual machines works better, if guest cache is synced to disk using sysrq s command. I think in Xen this worked over xenbus, not over serial console. SAL From markmc at redhat.com Wed Aug 5 10:35:02 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 05 Aug 2009 11:35:02 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <20090731165740.GC2701@salstar.sk> References: <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <20090731165740.GC2701@salstar.sk> Message-ID: <1249468503.28554.37.camel@blaa> On Fri, 2009-07-31 at 18:57 +0200, J?n ONDREJ (SAL) wrote: > groupadd: GID 107 is not singular > useradd: unknown group qemu > Non-fatal POSTIN scriptlet failure in rpm package > 2:qemu-common-0.10.91-0.2.rc1.rc0.fc11.i586 > varovanie: %post(qemu-common-2:0.10.91-0.2.rc1.rc0.fc11.i586) scriptlet > failed, exit status 6 > > Messages have been manually translated from slovak (my language) to english. > May be they are not correct. > > OpenVPN is using gid 107 on my system. Okay, it took me a while to figure out this one. The first problem is that 'groupadd -r' doesn't know that the 100-200 range is reserved for system accounts: https://bugzilla.redhat.com/515667 This sounds nasty, but it's actually not too bad - 'groupadd -r' should allocate gids from 499 downwards. However, in rawhide and F-11 updates-testing, this was broken recently: https://bugzilla.redhat.com/515671 You need to do something like: 1) downgrade to shadow-utils-4.1.2-13.fc11 2) yum erase openvpn qemu* 3) groupdel openvpn 4) yum install openvpn qemu > virtio booting is still not working. :( This should be resolved now. Thanks, Mark. From ondrejj at salstar.sk Wed Aug 5 11:25:37 2009 From: ondrejj at salstar.sk (=?utf-8?B?SsOhbiBPTkRSRUogKFNBTCk=?=) Date: Wed, 5 Aug 2009 13:25:37 +0200 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249468503.28554.37.camel@blaa> References: <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <20090731165740.GC2701@salstar.sk> <1249468503.28554.37.camel@blaa> Message-ID: <20090805112537.GA2711@salstar.sk> On Wed, Aug 05, 2009 at 11:35:02AM +0100, Mark McLoughlin wrote: > On Fri, 2009-07-31 at 18:57 +0200, J?n ONDREJ (SAL) wrote: > > groupadd: GID 107 is not singular > > useradd: unknown group qemu > > Non-fatal POSTIN scriptlet failure in rpm package > > 2:qemu-common-0.10.91-0.2.rc1.rc0.fc11.i586 > > varovanie: %post(qemu-common-2:0.10.91-0.2.rc1.rc0.fc11.i586) scriptlet > > failed, exit status 6 > > > > Messages have been manually translated from slovak (my language) to english. > > May be they are not correct. > > > > OpenVPN is using gid 107 on my system. > > Okay, it took me a while to figure out this one. > > The first problem is that 'groupadd -r' doesn't know that the 100-200 > range is reserved for system accounts: > > https://bugzilla.redhat.com/515667 > > This sounds nasty, but it's actually not too bad - 'groupadd -r' should > allocate gids from 499 downwards. > > However, in rawhide and F-11 updates-testing, this was broken recently: I don't use updates-testing. My system is Fedora 11 (stable updates only). > You need to do something like: > > 1) downgrade to shadow-utils-4.1.2-13.fc11 It's my version. There was no newer shadow-utils on my system. My packages: r[ondrejj at work ~]$ rpm -q qemu shadow-utils kernel-PAE qemu-0.10.91-0.4.rc1.fc11.i586 shadow-utils-4.1.2-13.fc11.i586 kernel-PAE-2.6.29.6-213.fc11.i686 kernel-PAE-2.6.29.6-217.2.3.fc11.i686 > > virtio booting is still not working. :( > > This should be resolved now. Still don't boot. Eating CPU, no action, I can only kill this virtual machine. [ondrejj at work ~]$ uname -a Linux work.salstar.sk 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686 i686 i386 GNU/Linux SAL From markmc at redhat.com Wed Aug 5 11:47:21 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 05 Aug 2009 12:47:21 +0100 Subject: [fedora-virt] end_request: I/O error, dev vda, sector 0 In-Reply-To: <870180fe0908031419k353d3ad4sb3ae4b49b36cf061@mail.gmail.com> References: <870180fe0908031419k353d3ad4sb3ae4b49b36cf061@mail.gmail.com> Message-ID: <1249472841.28554.90.camel@blaa> On Mon, 2009-08-03 at 15:19 -0600, Jerry James wrote: > On Thu, Jul 2, 2009 at 8:55 AM, Jerry James wrote: > > I just made a Rawhide virtual machine to see if it suffers from the > > same problem. Zillions of copies of this message are being spewed to > > the console, although the machine itself seems to be running normally > > (if sluggishly): > > > > end_request: I/O error, dev vda, sector 0 > > > > Any idea what that's all about? > > On a Fedora 11 x86_64 host with the latest updates installed, I just > made a fresh KVM guest with virt-manager. I made the disk image > fresh, too, just in case that had something to do with it. I > installed Rawhide. I cannot login through GDM for reasons I haven't > tracked down yet. Sending Ctrl+Alt+F2 to the guest gives me a text > console where the message above is printed frequently. Is anybody > else seeing this? Thanks for the report, it looks like this: https://bugzilla.redhat.com/514901 Both suspect patches were added in 2.6.31-rc1. Could you perhaps try a 2.6.30 kernel and see if that works? http://koji.fedoraproject.org/koji/buildinfo?buildID=105567 Thanks again, Mark. From markmc at redhat.com Wed Aug 5 11:53:56 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 05 Aug 2009 12:53:56 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <20090805112537.GA2711@salstar.sk> References: <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <20090731165740.GC2701@salstar.sk> <1249468503.28554.37.camel@blaa> <20090805112537.GA2711@salstar.sk> Message-ID: <1249473236.28554.95.camel@blaa> On Wed, 2009-08-05 at 13:25 +0200, J?n ONDREJ (SAL) wrote: > On Wed, Aug 05, 2009 at 11:35:02AM +0100, Mark McLoughlin wrote: > > You need to do something like: > > > > 1) downgrade to shadow-utils-4.1.2-13.fc11 > > It's my version. There was no newer shadow-utils on my system. > > My packages: > r[ondrejj at work ~]$ rpm -q qemu shadow-utils kernel-PAE > qemu-0.10.91-0.4.rc1.fc11.i586 > shadow-utils-4.1.2-13.fc11.i586 What does this give: $> groupadd -r foo $> getent group foo That version of shadow-utils should be allocating system groups high in the 400-500 range Cheers, Mark. From ondrejj at salstar.sk Wed Aug 5 14:25:34 2009 From: ondrejj at salstar.sk (=?utf-8?B?SsOhbiBPTkRSRUogKFNBTCk=?=) Date: Wed, 5 Aug 2009 16:25:34 +0200 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249473236.28554.95.camel@blaa> References: <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <20090731165740.GC2701@salstar.sk> <1249468503.28554.37.camel@blaa> <20090805112537.GA2711@salstar.sk> <1249473236.28554.95.camel@blaa> Message-ID: <20090805142534.GB2711@salstar.sk> On Wed, Aug 05, 2009 at 12:53:56PM +0100, Mark McLoughlin wrote: > On Wed, 2009-08-05 at 13:25 +0200, J?n ONDREJ (SAL) wrote: > > On Wed, Aug 05, 2009 at 11:35:02AM +0100, Mark McLoughlin wrote: > > > > You need to do something like: > > > > > > 1) downgrade to shadow-utils-4.1.2-13.fc11 > > > > It's my version. There was no newer shadow-utils on my system. > > > > My packages: > > r[ondrejj at work ~]$ rpm -q qemu shadow-utils kernel-PAE > > qemu-0.10.91-0.4.rc1.fc11.i586 > > shadow-utils-4.1.2-13.fc11.i586 > > What does this give: > > $> groupadd -r foo > $> getent group foo > > That version of shadow-utils should be allocating system groups high in > the 400-500 range Yes, this does. [root at work ondrejj]# groupadd -r foo [root at work ondrejj]# getent group foo foo:x:488: [root at work ondrejj]# Why do you think, this problem was caused by ascending or descending allocation? I think it does not matter, how it's allocated, when it's allocating same GID for 2 groups. SAL From markmc at redhat.com Wed Aug 5 15:12:41 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 05 Aug 2009 16:12:41 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <20090805142534.GB2711@salstar.sk> References: <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <20090731165740.GC2701@salstar.sk> <1249468503.28554.37.camel@blaa> <20090805112537.GA2711@salstar.sk> <1249473236.28554.95.camel@blaa> <20090805142534.GB2711@salstar.sk> Message-ID: <1249485161.28554.106.camel@blaa> On Wed, 2009-08-05 at 16:25 +0200, J?n ONDREJ (SAL) wrote: > On Wed, Aug 05, 2009 at 12:53:56PM +0100, Mark McLoughlin wrote: > > On Wed, 2009-08-05 at 13:25 +0200, J?n ONDREJ (SAL) wrote: > > > On Wed, Aug 05, 2009 at 11:35:02AM +0100, Mark McLoughlin wrote: > > > > > > You need to do something like: > > > > > > > > 1) downgrade to shadow-utils-4.1.2-13.fc11 > > > > > > It's my version. There was no newer shadow-utils on my system. > > > > > > My packages: > > > r[ondrejj at work ~]$ rpm -q qemu shadow-utils kernel-PAE > > > qemu-0.10.91-0.4.rc1.fc11.i586 > > > shadow-utils-4.1.2-13.fc11.i586 > > > > What does this give: > > > > $> groupadd -r foo > > $> getent group foo > > > > That version of shadow-utils should be allocating system groups high in > > the 400-500 range > > Yes, this does. > > [root at work ondrejj]# groupadd -r foo > [root at work ondrejj]# getent group foo > foo:x:488: > [root at work ondrejj]# > > Why do you think, this problem was caused by ascending or descending > allocation? I think it does not matter, how it's allocated, when it's > allocating same GID for 2 groups. The openvpn group is added using the 'groupadd -r openvpn' command I don't understand how that ever allocated gid 107, unless you had shadow-utils-4.1.2-13.fc11 installed at some point because it should normally allocate a gid closer to 107. In any case, the version of shadow-utils just built today will never allocate gids in the 100-200 range. The qemu group is added using 'groupadd -g 107 -r qemu' because it has had gid 107 reserved for it. See the uidgid file in the setup RPM. Cheers, Mark. From loganjerry at gmail.com Wed Aug 5 15:23:22 2009 From: loganjerry at gmail.com (Jerry James) Date: Wed, 5 Aug 2009 09:23:22 -0600 Subject: [fedora-virt] end_request: I/O error, dev vda, sector 0 In-Reply-To: <1249472841.28554.90.camel@blaa> References: <870180fe0908031419k353d3ad4sb3ae4b49b36cf061@mail.gmail.com> <1249472841.28554.90.camel@blaa> Message-ID: <870180fe0908050823j5e2a0453j10a4a011331110f8@mail.gmail.com> On Wed, Aug 5, 2009 at 5:47 AM, Mark McLoughlin wrote: > Thanks for the report, it looks like this: > > ?https://bugzilla.redhat.com/514901 > > Both suspect patches were added in 2.6.31-rc1. Could you perhaps try a > 2.6.30 kernel and see if that works? > > ?http://koji.fedoraproject.org/koji/buildinfo?buildID=105567 > > Thanks again, > Mark. Thanks for the pointer, Mark. I'll post any further information on that bug. -- Jerry James http://www.jamezone.org/ From ondrejj at salstar.sk Wed Aug 5 15:46:43 2009 From: ondrejj at salstar.sk (=?utf-8?B?SsOhbiBPTkRSRUogKFNBTCk=?=) Date: Wed, 5 Aug 2009 17:46:43 +0200 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249485161.28554.106.camel@blaa> References: <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <20090731165740.GC2701@salstar.sk> <1249468503.28554.37.camel@blaa> <20090805112537.GA2711@salstar.sk> <1249473236.28554.95.camel@blaa> <20090805142534.GB2711@salstar.sk> <1249485161.28554.106.camel@blaa> Message-ID: <20090805154643.GC2711@salstar.sk> On Wed, Aug 05, 2009 at 04:12:41PM +0100, Mark McLoughlin wrote: > On Wed, 2009-08-05 at 16:25 +0200, J?n ONDREJ (SAL) wrote: > > On Wed, Aug 05, 2009 at 12:53:56PM +0100, Mark McLoughlin wrote: > > > On Wed, 2009-08-05 at 13:25 +0200, J?n ONDREJ (SAL) wrote: > > > > On Wed, Aug 05, 2009 at 11:35:02AM +0100, Mark McLoughlin wrote: > > > > > > > > You need to do something like: > > > > > > > > > > 1) downgrade to shadow-utils-4.1.2-13.fc11 > > > > > > > > It's my version. There was no newer shadow-utils on my system. > > > > > > > > My packages: > > > > r[ondrejj at work ~]$ rpm -q qemu shadow-utils kernel-PAE > > > > qemu-0.10.91-0.4.rc1.fc11.i586 > > > > shadow-utils-4.1.2-13.fc11.i586 > > > > > > What does this give: > > > > > > $> groupadd -r foo > > > $> getent group foo > > > > > > That version of shadow-utils should be allocating system groups high in > > > the 400-500 range > > > > Yes, this does. > > > > [root at work ondrejj]# groupadd -r foo > > [root at work ondrejj]# getent group foo > > foo:x:488: > > [root at work ondrejj]# > > > > Why do you think, this problem was caused by ascending or descending > > allocation? I think it does not matter, how it's allocated, when it's > > allocating same GID for 2 groups. > > The openvpn group is added using the 'groupadd -r openvpn' command > > I don't understand how that ever allocated gid 107, unless you had > shadow-utils-4.1.2-13.fc11 installed at some point because it should > normally allocate a gid closer to 107. May be it has nothing with shadow-utils, but may be with an older openvpn. My openvpn was installed years ago, may be in Fedora 8. > In any case, the version of shadow-utils just built today will never > allocate gids in the 100-200 range. > > The qemu group is added using 'groupadd -g 107 -r qemu' because it has > had gid 107 reserved for it. See the uidgid file in the setup RPM. Hmm, ok. So I have to change my openvpn group. I will do this. But why we can't have dynamic qemu group? Why it need to be defined statically? May be it will conflict with another packages or user settings. SAL From berrange at redhat.com Wed Aug 5 15:52:35 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 5 Aug 2009 16:52:35 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <20090805154643.GC2711@salstar.sk> References: <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <20090731165740.GC2701@salstar.sk> <1249468503.28554.37.camel@blaa> <20090805112537.GA2711@salstar.sk> <1249473236.28554.95.camel@blaa> <20090805142534.GB2711@salstar.sk> <1249485161.28554.106.camel@blaa> <20090805154643.GC2711@salstar.sk> Message-ID: <20090805155235.GB15540@redhat.com> On Wed, Aug 05, 2009 at 05:46:43PM +0200, J?n ONDREJ (SAL) wrote: > On Wed, Aug 05, 2009 at 04:12:41PM +0100, Mark McLoughlin wrote: > > On Wed, 2009-08-05 at 16:25 +0200, J?n ONDREJ (SAL) wrote: > > > On Wed, Aug 05, 2009 at 12:53:56PM +0100, Mark McLoughlin wrote: > > > > On Wed, 2009-08-05 at 13:25 +0200, J?n ONDREJ (SAL) wrote: > > > > > On Wed, Aug 05, 2009 at 11:35:02AM +0100, Mark McLoughlin wrote: > > > > > > > > > > You need to do something like: > > > > > > > > > > > > 1) downgrade to shadow-utils-4.1.2-13.fc11 > > > > > > > > > > It's my version. There was no newer shadow-utils on my system. > > > > > > > > > > My packages: > > > > > r[ondrejj at work ~]$ rpm -q qemu shadow-utils kernel-PAE > > > > > qemu-0.10.91-0.4.rc1.fc11.i586 > > > > > shadow-utils-4.1.2-13.fc11.i586 > > > > > > > > What does this give: > > > > > > > > $> groupadd -r foo > > > > $> getent group foo > > > > > > > > That version of shadow-utils should be allocating system groups high in > > > > the 400-500 range > > > > > > Yes, this does. > > > > > > [root at work ondrejj]# groupadd -r foo > > > [root at work ondrejj]# getent group foo > > > foo:x:488: > > > [root at work ondrejj]# > > > > > > Why do you think, this problem was caused by ascending or descending > > > allocation? I think it does not matter, how it's allocated, when it's > > > allocating same GID for 2 groups. > > > > The openvpn group is added using the 'groupadd -r openvpn' command > > > > I don't understand how that ever allocated gid 107, unless you had > > shadow-utils-4.1.2-13.fc11 installed at some point because it should > > normally allocate a gid closer to 107. > > May be it has nothing with shadow-utils, but may be with an older openvpn. > My openvpn was installed years ago, may be in Fedora 8. > > > In any case, the version of shadow-utils just built today will never > > allocate gids in the 100-200 range. > > > > The qemu group is added using 'groupadd -g 107 -r qemu' because it has > > had gid 107 reserved for it. See the uidgid file in the setup RPM. > > Hmm, ok. So I have to change my openvpn group. I will do this. > > But why we can't have dynamic qemu group? Why it need to be defined > statically? May be it will conflict with another packages or user settings. When libvirt runs QEMU as 'qemu' it needs to change ownership of disks to match. If those disks are on shared storage, you want the 'qemu' user ID to be the same everywhere. Not everyone uses NIS, so reserving a static UID is a wise precaution. 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 gianluca.cecchi at gmail.com Thu Aug 6 13:25:46 2009 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 6 Aug 2009 15:25:46 +0200 Subject: [fedora-virt] live migration blocked until dump run in virsh Message-ID: <561c252c0908060625g2b679f23nd71625a4a9e8cd19@mail.gmail.com> With standard F11 x86_64 host I was able to do live migration through virsh but not inside virt-manager (I got libvirtError: invalid argument in only tcp URIs are supported for KVM migrations) After enabling fedora-virt-preview repo, I now have: gpxe-roms-qemu-0.9.7-4.fc11.noarch libvirt-0.7.0-0.9.gite195b43.fc11.x86_64 libvirt-client-0.7.0-0.9.gite195b43.fc11.x86_64 libvirt-python-0.7.0-0.9.gite195b43.fc11.x86_64 perl-Sys-Virt-0.2.0-2.fc11.x86_64 python-virtinst-0.500.0-1.fc11.noarch qemu-common-0.10.91-0.4.rc1.fc11.x86_64 qemu-img-0.10.91-0.4.rc1.fc11.x86_64 qemu-kvm-0.10.91-0.4.rc1.fc11.x86_64 qemu-system-x86-0.10.91-0.4.rc1.fc11.x86_64 virt-df-1.0.64-2.fc11.x86_64 virt-manager-0.8.0-1.fc11.noarch virt-top-1.0.3-4.fc11.x86_64 virt-viewer-0.2.0-1.fc11.x86_64 I'm able to run live migration inside virt-manager: it completes, the vm appears running on the new host (I can also see the qemu process) but actually it is frozen from an OS point of view. I found a sort of workaround doing this from inside virsh: virsh # list Id Name State ---------------------------------- 1 centos53 running 2 centos53_node2 running 3 prova2 running virsh # dump 3 /tmp/dump_prova2.log Domain 3 dumped to /tmp/dump_prova2.log As soon that the command completes (about 10 seconds with a vm having 768MB of ram defined) I have again the vm runni ng and reachable through network..... Any insight? Also, how to migrate a powered off vm? Question: a vm migrated form host1 to host2 still appears on the source host as shutoff.... but right click on it in virt-manager gives the option to "run" it..... What does it happens in this case? I think corruption, as the vm is actually running on host2.... Or would I receive a sort of error preventing me to do this? Thanks, Gianluca From markmc at redhat.com Thu Aug 6 15:37:36 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 06 Aug 2009 16:37:36 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249400197.3212.73.camel@blaa> References: <1244034684.5001.134.camel@blaa> <1244046483.5001.180.camel@blaa> <1244197459.27876.0.camel@blaa> <1246303956.11688.148.camel@blaa> <1246628572.13604.2.camel@blaa> <1246636154.13604.8.camel@blaa> <1247763853.3038.105.camel@blaa> <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <1249400197.3212.73.camel@blaa> Message-ID: <1249573056.3721.62.camel@blaa> More updates available in http://markmc.fedorapeople.org/virt-preview == libvirt == * Thu Aug 6 2009 Mark McLoughlin - 0.7.0-2 - Make sure qemu can access kernel/initrd (bug #516034) - Set perms on /var/lib/libvirt/boot to 0711 (bug #516034) * Wed Aug 5 2009 Daniel Veillard - 0.7.0-1 - Upstream release of 0.7.0 - ESX, VBox3, Power Hypervisor drivers - new net filesystem glusterfs - Storage cloning for LVM and Disk backends - interface implementation based on netcf - Support cgroups in QEMU driver - QEmu hotplug NIC support - a lot of fixes Cheers, Mark. From cochranb at speakeasy.net Thu Aug 6 20:51:31 2009 From: cochranb at speakeasy.net (Robert L Cochran) Date: Thu, 06 Aug 2009 16:51:31 -0400 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249573056.3721.62.camel@blaa> References: <1244034684.5001.134.camel@blaa> <1244046483.5001.180.camel@blaa> <1244197459.27876.0.camel@blaa> <1246303956.11688.148.camel@blaa> <1246628572.13604.2.camel@blaa> <1246636154.13604.8.camel@blaa> <1247763853.3038.105.camel@blaa> <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <1249400197.3212.73.camel@blaa> <1249573056.3721.62.camel@blaa> Message-ID: <4A7B4253.1000003@speakeasy.net> On 08/06/2009 11:37 AM, Mark McLoughlin wrote: > More updates available in http://markmc.fedorapeople.org/virt-preview > > == libvirt == > > * Thu Aug 6 2009 Mark McLoughlin - 0.7.0-2 > - Make sure qemu can access kernel/initrd (bug #516034) > - Set perms on /var/lib/libvirt/boot to 0711 (bug #516034) > > * Wed Aug 5 2009 Daniel Veillard - 0.7.0-1 > - Upstream release of 0.7.0 > - ESX, VBox3, Power Hypervisor drivers > - new net filesystem glusterfs > - Storage cloning for LVM and Disk backends > - interface implementation based on netcf > - Support cgroups in QEMU driver > - QEmu hotplug NIC support > - a lot of fixes > > Cheers, > Mark. > > For these, do I need the latest netcf (netcf-0.1.0-2.fc12.src.rpm) and augeas (augeas-0.5.2-2.fc12.src.rpm) from rawhide? Thanks Bob From markmc at redhat.com Thu Aug 6 21:32:15 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 06 Aug 2009 22:32:15 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <4A7B4253.1000003@speakeasy.net> References: <1244034684.5001.134.camel@blaa> <1244046483.5001.180.camel@blaa> <1244197459.27876.0.camel@blaa> <1246303956.11688.148.camel@blaa> <1246628572.13604.2.camel@blaa> <1246636154.13604.8.camel@blaa> <1247763853.3038.105.camel@blaa> <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <1249400197.3212.73.camel@blaa> <1249573056.3721.62.camel@blaa> <4A7B4253.1000003@speakeasy.net> Message-ID: <1249594335.31541.1.camel@blaa> On Thu, 2009-08-06 at 16:51 -0400, Robert L Cochran wrote: > On 08/06/2009 11:37 AM, Mark McLoughlin wrote: > > More updates available in http://markmc.fedorapeople.org/virt-preview > > > > == libvirt == > > > > * Thu Aug 6 2009 Mark McLoughlin - 0.7.0-2 > > - Make sure qemu can access kernel/initrd (bug #516034) > > - Set perms on /var/lib/libvirt/boot to 0711 (bug #516034) > > > > * Wed Aug 5 2009 Daniel Veillard - 0.7.0-1 > > - Upstream release of 0.7.0 > > - ESX, VBox3, Power Hypervisor drivers > > - new net filesystem glusterfs > > - Storage cloning for LVM and Disk backends > > - interface implementation based on netcf > > - Support cgroups in QEMU driver > > - QEmu hotplug NIC support > > - a lot of fixes > > > > Cheers, > > Mark. > > > > > > For these, do I need the latest netcf (netcf-0.1.0-2.fc12.src.rpm) and > augeas (augeas-0.5.2-2.fc12.src.rpm) from rawhide? A bit of a mishap on my part - I accidentally pushed libvirt-0.7.0-2.fc12 rather than libvirt-0.7.0-2.fc11 I've fixed it up now, try again Thanks, Mark. From cochranb at speakeasy.net Fri Aug 7 00:34:16 2009 From: cochranb at speakeasy.net (Robert L Cochran) Date: Thu, 06 Aug 2009 20:34:16 -0400 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249594335.31541.1.camel@blaa> References: <1244034684.5001.134.camel@blaa> <1244046483.5001.180.camel@blaa> <1244197459.27876.0.camel@blaa> <1246303956.11688.148.camel@blaa> <1246628572.13604.2.camel@blaa> <1246636154.13604.8.camel@blaa> <1247763853.3038.105.camel@blaa> <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <1249400197.3212.73.camel@blaa> <1249573056.3721.62.camel@blaa> <4A7B4253.1000003@speakeasy.net> <1249594335.31541.1.camel@blaa> Message-ID: <4A7B7688.1010908@speakeasy.net> On 08/06/2009 05:32 PM, Mark McLoughlin wrote: > On Thu, 2009-08-06 at 16:51 -0400, Robert L Cochran wrote: > >> On 08/06/2009 11:37 AM, Mark McLoughlin wrote: >> >>> More updates available in http://markmc.fedorapeople.org/virt-preview >>> >>> == libvirt == >>> >>> * Thu Aug 6 2009 Mark McLoughlin - 0.7.0-2 >>> - Make sure qemu can access kernel/initrd (bug #516034) >>> - Set perms on /var/lib/libvirt/boot to 0711 (bug #516034) >>> >>> * Wed Aug 5 2009 Daniel Veillard - 0.7.0-1 >>> - Upstream release of 0.7.0 >>> - ESX, VBox3, Power Hypervisor drivers >>> - new net filesystem glusterfs >>> - Storage cloning for LVM and Disk backends >>> - interface implementation based on netcf >>> - Support cgroups in QEMU driver >>> - QEmu hotplug NIC support >>> - a lot of fixes >>> >>> Cheers, >>> Mark. >>> >>> >>> >> For these, do I need the latest netcf (netcf-0.1.0-2.fc12.src.rpm) and >> augeas (augeas-0.5.2-2.fc12.src.rpm) from rawhide? >> > > A bit of a mishap on my part - I accidentally pushed > libvirt-0.7.0-2.fc12 rather than libvirt-0.7.0-2.fc11 > > I've fixed it up now, try again > > Thanks, > Mark. > Actually Mark, I started out rather confused about how to actually get the libvirt goodies, and I think we both benefited. You updated libvirt and I figured out how to use your repo, and now have libvirt 0.7.0. Bob > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Fri Aug 7 09:58:17 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 07 Aug 2009 10:58:17 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249573056.3721.62.camel@blaa> References: <1244034684.5001.134.camel@blaa> <1244046483.5001.180.camel@blaa> <1244197459.27876.0.camel@blaa> <1246303956.11688.148.camel@blaa> <1246628572.13604.2.camel@blaa> <1246636154.13604.8.camel@blaa> <1247763853.3038.105.camel@blaa> <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <1249400197.3212.73.camel@blaa> <1249573056.3721.62.camel@blaa> Message-ID: <1249639097.3260.5.camel@blaa> More updates available in http://markmc.fedorapeople.org/virt-preview == qemu == * Fri Aug 7 2009 Mark McLoughlin - 2:0.10.91-0.5.rc1 - Fix virtio_net with -net user (#516022) Cheers, Mark. From markmc at redhat.com Fri Aug 7 10:13:47 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 07 Aug 2009 11:13:47 +0100 Subject: [fedora-virt] live migration blocked until dump run in virsh In-Reply-To: <561c252c0908060625g2b679f23nd71625a4a9e8cd19@mail.gmail.com> References: <561c252c0908060625g2b679f23nd71625a4a9e8cd19@mail.gmail.com> Message-ID: <1249640027.3260.7.camel@blaa> Hi Gianluca, On Thu, 2009-08-06 at 15:25 +0200, Gianluca Cecchi wrote: > With standard F11 x86_64 host I was able to do live migration through > virsh but not inside virt-manager > (I got libvirtError: invalid argument in only tcp URIs are supported > for KVM migrations) > > After enabling fedora-virt-preview repo, I now have: > > gpxe-roms-qemu-0.9.7-4.fc11.noarch > libvirt-0.7.0-0.9.gite195b43.fc11.x86_64 > libvirt-client-0.7.0-0.9.gite195b43.fc11.x86_64 > libvirt-python-0.7.0-0.9.gite195b43.fc11.x86_64 > perl-Sys-Virt-0.2.0-2.fc11.x86_64 > python-virtinst-0.500.0-1.fc11.noarch > qemu-common-0.10.91-0.4.rc1.fc11.x86_64 > qemu-img-0.10.91-0.4.rc1.fc11.x86_64 > qemu-kvm-0.10.91-0.4.rc1.fc11.x86_64 > qemu-system-x86-0.10.91-0.4.rc1.fc11.x86_64 > virt-df-1.0.64-2.fc11.x86_64 > virt-manager-0.8.0-1.fc11.noarch > virt-top-1.0.3-4.fc11.x86_64 > virt-viewer-0.2.0-1.fc11.x86_64 > > I'm able to run live migration inside virt-manager: it completes, the > vm appears running on the > new host (I can also see the qemu process) but actually it is frozen > from an OS point of > view. > I found a sort of workaround doing this from inside virsh: > > virsh # list > Id Name State > ---------------------------------- > 1 centos53 running > 2 centos53_node2 running > 3 prova2 running > > virsh # dump 3 /tmp/dump_prova2.log > Domain 3 dumped to /tmp/dump_prova2.log > > As soon that the command completes (about 10 seconds with a vm having > 768MB of ram defined) I have again the vm runni ng and reachable > through network..... > Any insight? That sounds like this bug: https://bugzilla.redhat.com/516187 Cheers, Mark. From gianluca.cecchi at gmail.com Fri Aug 7 13:06:48 2009 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 7 Aug 2009 15:06:48 +0200 Subject: [fedora-virt] no virbr0 with libvirt-0.7.0-2 Message-ID: <561c252c0908070606g66d2d97fi622f8d4ded56d094@mail.gmail.com> With libvirt-0.7.0-0.9.gite195b43.fc11.x86_64 all ok, with libvirt-0.7.0-2.fc11.x86_64 updated today virbr0 is ko. It doesn't start automatically as configured and in /var/log/messages I find this: Aug 7 12:57:43 virtfed libvirtd: 12:57:43.559: error : networkDisableIPV6:806 : cannot enable /proc/sys/net/ipv6/conf/virbr0/disable_ipv6: No such file or directory previously I didn't get this error (and NetworkManager and ipv6 was already disabled) Trying to start manually the "default" network inside virt-manager host details window I get this traceback: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/host.py", line 247, in start_network net.start() File "/usr/share/virt-manager/virtManager/network.py", line 71, in start self.net.create() File "/usr/lib64/python2.6/site-packages/libvirt.py", line 620, in create if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self) libvirtError: cannot enable /proc/sys/net/ipv6/conf/virbr0/disable_ipv6: No such file or directory Current config files on my f11 x86_64 with fedora-virt-preview repo enabled: [root]# cat /etc/modprobe.d/noipv6.conf alias net-pf-10 off alias ipv6 off [root]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=myhostname.domain.com NOZEROCONF=yes NETWORKING_IPV6=off [root at virtfed log]# cat /etc/libvirt/qemu/networks/default.xml default 2e877982-bc6c-48b6-975b-317231c43ce4 Thanks, Gianluca From guy.carmin at gmail.com Mon Aug 10 07:53:07 2009 From: guy.carmin at gmail.com (Guy Carmin) Date: Mon, 10 Aug 2009 10:53:07 +0300 Subject: [fedora-virt] no virbr0 Message-ID: After connecting to "Rawhide Virtualization Repository available for Fedora 11" and "yum update" (virt-manager 0.7*) the default network does not start up (automatic nor manually) with the following error: virsh # net-start default error: Failed to start network default error: cannot enable /proc/sys/net/ipv6/conf/virbr0/disable_ipv6: No such file or directory whereas the IPV6 is disable at my F11. (and virbr0 has been worked before the update to 0.7) ---- ?Only when the last tree has died, and the last river has been poisoned, and the last fish has been caught, will we realize that we cannot eat money.? (Chief Seattle) ---- may the source be with you. ----- Sure Linux is user-friendly, it's just picky about who its friends are. ------ Free your mind, And your OS will follow ------ echo hvz/dbsnjoAhnbjm/dpn | perl -pe 's/./chr(ord($&)-1)/ge' -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Mon Aug 10 10:26:07 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 10 Aug 2009 11:26:07 +0100 Subject: [fedora-virt] no virbr0 with libvirt-0.7.0-2 In-Reply-To: <561c252c0908070606g66d2d97fi622f8d4ded56d094@mail.gmail.com> References: <561c252c0908070606g66d2d97fi622f8d4ded56d094@mail.gmail.com> Message-ID: <1249899967.8784.73.camel@blaa> Hi Gianluca (and Guy), On Fri, 2009-08-07 at 15:06 +0200, Gianluca Cecchi wrote: > With libvirt-0.7.0-0.9.gite195b43.fc11.x86_64 all ok, > > with libvirt-0.7.0-2.fc11.x86_64 updated today virbr0 is ko. > It doesn't start automatically as configured and in /var/log/messages > I find this: > > Aug 7 12:57:43 virtfed libvirtd: 12:57:43.559: error : > networkDisableIPV6:806 : cannot enable > /proc/sys/net/ipv6/conf/virbr0/disable_ipv6: No such file or directory ... > [root]# cat /etc/modprobe.d/noipv6.conf > alias net-pf-10 off > alias ipv6 off Okay, the key thing here is that you have ipv6 support disabled. A fix for libvirt is on its way to handle that. Many thanks for the report, but please do always file these kind of issues in bugzilla, even if you send them to this list too. Thanks, Mark. From markmc at redhat.com Mon Aug 10 10:30:27 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 10 Aug 2009 11:30:27 +0100 Subject: [fedora-virt] no virbr0 with libvirt-0.7.0-2 In-Reply-To: <1249899967.8784.73.camel@blaa> References: <561c252c0908070606g66d2d97fi622f8d4ded56d094@mail.gmail.com> <1249899967.8784.73.camel@blaa> Message-ID: <1249900227.8784.75.camel@blaa> On Mon, 2009-08-10 at 11:26 +0100, Mark McLoughlin wrote: > Many thanks for the report, but please do always file these kind of > issues in bugzilla, even if you send them to this list too. Ah, Guy did that! ttps://bugzilla.redhat.com/516497 Thanks, Mark. From markmc at redhat.com Mon Aug 10 10:36:52 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 10 Aug 2009 11:36:52 +0100 Subject: [fedora-virt] ANNOUNCE: Rawhide virt repo for F11 users In-Reply-To: <1249639097.3260.5.camel@blaa> References: <1244034684.5001.134.camel@blaa> <1244046483.5001.180.camel@blaa> <1244197459.27876.0.camel@blaa> <1246303956.11688.148.camel@blaa> <1246628572.13604.2.camel@blaa> <1246636154.13604.8.camel@blaa> <1247763853.3038.105.camel@blaa> <1248769817.3089.20.camel@blaa> <1248776732.3089.45.camel@blaa> <1248859649.3021.28.camel@blaa> <20090729093637.GC10723@salstar.sk> <1248868438.3021.31.camel@blaa> <1248873640.3021.34.camel@blaa> <1248879462.3021.39.camel@blaa> <1248882336.3021.40.camel@blaa> <1248974623.3275.4.camel@blaa> <1249057022.3320.35.camel@blaa> <1249400197.3212.73.camel@blaa> <1249573056.3721.62.camel@blaa> <1249639097.3260.5.camel@blaa> Message-ID: <1249900612.8784.79.camel@blaa> More updates available in http://markmc.fedorapeople.org/virt-preview == libvirt == * Mon Aug 10 2009 Mark McLoughlin - 0.7.0-3 - Don't fail to start network if ipv6 modules is not loaded (#516497) Cheers, Mark. From gianluca.cecchi at gmail.com Mon Aug 10 15:09:19 2009 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Mon, 10 Aug 2009 17:09:19 +0200 Subject: [fedora-virt] Re: no virbr0 with libvirt-0.7.0-2 In-Reply-To: <1249899967.8784.73.camel@blaa> References: <561c252c0908070606g66d2d97fi622f8d4ded56d094@mail.gmail.com> <1249899967.8784.73.camel@blaa> Message-ID: <561c252c0908100809va3f3003o4adc65dcee27ae25@mail.gmail.com> Ok, thanks. I will keep in mind to make them in bugzilla too. On 8/10/09, Mark McLoughlin wrote: > Hi Gianluca (and Guy), > > On Fri, 2009-08-07 at 15:06 +0200, Gianluca Cecchi wrote: >> With libvirt-0.7.0-0.9.gite195b43.fc11.x86_64 all ok, >> >> with libvirt-0.7.0-2.fc11.x86_64 updated today virbr0 is ko. >> It doesn't start automatically as configured and in /var/log/messages >> I find this: >> >> Aug 7 12:57:43 virtfed libvirtd: 12:57:43.559: error : >> networkDisableIPV6:806 : cannot enable >> /proc/sys/net/ipv6/conf/virbr0/disable_ipv6: No such file or directory > ... >> [root]# cat /etc/modprobe.d/noipv6.conf >> alias net-pf-10 off >> alias ipv6 off > > Okay, the key thing here is that you have ipv6 support disabled. > > A fix for libvirt is on its way to handle that. > > Many thanks for the report, but please do always file these kind of > issues in bugzilla, even if you send them to this list too. > > Thanks, > Mark. > > From pasik at iki.fi Mon Aug 10 17:09:47 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 10 Aug 2009 20:09:47 +0300 Subject: [fedora-virt] [Xen-devel] [ANNOUNCE] Xen 3.3.2 and 3.4.1 released Message-ID: <20090810170947.GC24960@edu.joroinen.fi> ----- Forwarded message from Keir Fraser ----- From: Keir Fraser To: "xen-devel at lists.xensource.com" , xen-users at lists.xensource.com Cc: Date: Thu, 06 Aug 2009 23:35:08 +0100 Subject: [Xen-devel] [ANNOUNCE] Xen 3.3.2 and 3.4.1 released Folks, New releases in the 3.3 and 3.4 stable branches are now tagged and released. You can pick up the source repositories here: http://xenbits.xensource.com/xen-3.3-testing.hg (tagged RELEASE-3.3.2) http://xenbits.xensource.com/xen-3.4-testing.hg (tagged RELEASE-3.4.1) Or you can pick up tarballs from the following webpages: 3.3.2: http://www.xen.org/download/index_3.3.2.html 3.4.1: http://www.xen.org/download/ -- Keir _______________________________________________ Xen-devel mailing list Xen-devel at lists.xensource.com http://lists.xensource.com/xen-devel ----- End forwarded message ----- From jkeating at redhat.com Mon Aug 10 17:40:16 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Aug 2009 10:40:16 -0700 Subject: [fedora-virt] Spec weirdness Message-ID: <1249926016.3310.32.camel@localhost.localdomain> I'm looking at the spec file for libguestfs, and all I can say is WTF. There is a lot of crazyness going on in this spec, chroots within chroots, making a repo of yum cache packages and using it again, calling qemu, and none of it is really documented in the spec as for what and why things are done this way. The review for this is extremely light on comments regarding the spec file construction as well, it looks very suspiciously like "it built and passed rpmlint, let it in!" I'd really like to see some comments around what's going on here, and maybe some discussion on public lists of what you're trying to do and whether or not there are better ways to do that within our buildsystem. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From berrange at redhat.com Mon Aug 10 18:17:38 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 10 Aug 2009 19:17:38 +0100 Subject: [fedora-virt] Spec weirdness In-Reply-To: <1249926016.3310.32.camel@localhost.localdomain> References: <1249926016.3310.32.camel@localhost.localdomain> Message-ID: <20090810181738.GH9568@redhat.com> On Mon, Aug 10, 2009 at 10:40:16AM -0700, Jesse Keating wrote: > I'm looking at the spec file for libguestfs, and all I can say is WTF. > There is a lot of crazyness going on in this spec, chroots within > chroots, making a repo of yum cache packages and using it again, calling > qemu, and none of it is really documented in the spec as for what and > why things are done this way. > > The review for this is extremely light on comments regarding the spec > file construction as well, it looks very suspiciously like "it built and > passed rpmlint, let it in!" I didn't do the review myself, but looking at the specfile in devel/ it's a pretty clean & well written spec. That said I do agree it would benefit from comment explaining why it needs to build a yum repository. The spawning of QEMU is just what libguestfs as an application is all about & you shouldn't need to document the application itself in the spec file. Anyway, here's an explanation of what libguestfs as a app does during its build (nb this is not fedora specific - it does similar for all distros, give or take a bit) Part of the libguestfs application is a filesystem image that is run within a virtual machine. Since distributing pre-built blobs is bad, libguestfs prefers to build the filesystem from a distributions pristine package repos. On Fedora this is done using febootstrap, which is a Fedora equivalent of debootstrap from Debian world & indeed it uses debootstrap on Debian. The idea of (fe|de)bootstrap is to allow ordinary unprivileged users to be able to install a set of packages (RPMS / Debs) into a virtual root directory of their own, without needing any privileged component. This is done by using fakeroot & fakechroot. If a user builds libguestfs straight from a upstream release, or GIT repo, then the libguestfs build system uses a yum config that points to an online Fedora yum repo. After populating the root dir, it pulls it all together into a fs image that is what libguestfs will later use at runtime. Now back to the Koji bit. Since libguestfs has a build system which works completely unprivileged technically there are no specific features required in the Fedora buildsystem required in order to support it. The default mode of operation though, builds from an online YUM repo - since that YUm repo may change at anytime its not desirable to use that from a RPM formal build. Thus, the RPM spec just configures libguestfs to use a local YUM repo, and populates this using the RPMs that mock has already deployed into the RPM buildroot. This ensure the filesystem image thats built uses a predictable set of RPM n-e-v-rs. ie, if you can recreate the original mock buildroot, you'll get the same libguestfs image coming back out. The one area where I see it could be useful to have explicit mock or koji suport, would be if they explicitly made the yum repo available, so the spec didn't rely on the directory of RPMs that mock leaves visible. We certainly would not want to make the libguestfs build process itself be tied into mock though - they should be loosely coupled, since libguestfs needs to be easily buildable from non-Fedora distros, as well as outside of mock/koji. So in summary, the only real special requirement here is that libguestfs needs a reproducable / stable YUM repo to point at during build. 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 berrange at redhat.com Mon Aug 10 18:36:48 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 10 Aug 2009 19:36:48 +0100 Subject: [fedora-virt] Spec weirdness In-Reply-To: <20090810181738.GH9568@redhat.com> References: <1249926016.3310.32.camel@localhost.localdomain> <20090810181738.GH9568@redhat.com> Message-ID: <20090810183648.GI9568@redhat.com> On Mon, Aug 10, 2009 at 07:17:38PM +0100, Daniel P. Berrange wrote: > On Mon, Aug 10, 2009 at 10:40:16AM -0700, Jesse Keating wrote: > > I'm looking at the spec file for libguestfs, and all I can say is WTF. > > There is a lot of crazyness going on in this spec, chroots within > > chroots, making a repo of yum cache packages and using it again, calling > > qemu, and none of it is really documented in the spec as for what and > > why things are done this way. > > > > The review for this is extremely light on comments regarding the spec > > file construction as well, it looks very suspiciously like "it built and > > passed rpmlint, let it in!" > The idea of (fe|de)bootstrap is to allow ordinary unprivileged users to > be able to install a set of packages (RPMS / Debs) into a virtual root > directory of their own, without needing any privileged component. > This is done by using fakeroot & fakechroot. If a user builds libguestfs BTW, for those not familiar with fakeroot/fakechroot, the man pages have quite useful descriptions For fakeroot fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership. Without fakeroot one would need to have root privileges to create the constituent files of the archives with the correct permissions and owner- ship, and then pack them up, or one would have to construct the archives directly, without using the archiver. fakeroot works by replacing the file manipulation library func- tions (chmod(2), stat(2) etc.) by ones that simulate the effect the real library functions would have had, had the user really been root. These wrapper functions are in a shared library /usr/lib/libfakeroot.so* which is loaded through the LD_PRELOAD mechanism of the dynamic loader. (See ld.so(8)) And for fakechroot fakechroot runs a command in an environment were is additional possibility to use chroot(8) command without root privileges. This is useful for allowing users to create own chrooted environment with possibility to install another packages without need for root privileges. fakechroot replaces more library functions (chroot(2), open(2), etc.) by ones that simulate the effect the real library functions would have had, had the user really been in chroot. These wrapper functions are in a shared library /usr/lib/fakechroot/libfakechroot.so which is loaded through the LD_PRELOAD mechanism of the dynamic loader. (See ld.so(8)) .... In the current version, the fakechroot does not provide the fakeroot(1) functionality! You might to call fakechroot with fakeroot command, if you want to emulate root environment, i.e.: $ fakeroot fakechroot /usr/sbin/chroot /tmp/debian /bin/sh # id uid=0(root) gid=0(root) groups=0(root) And most importantly of all on security fakeroot is a regular, non-setuid program. It does not enhance a user???s privileges, or decrease the system???s security. fakechroot is a regular, non-setuid program. It does not enhance a user???s privileges, or decrease the system???s security. 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 rjones at redhat.com Mon Aug 10 18:45:04 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 10 Aug 2009 19:45:04 +0100 Subject: [fedora-virt] Re: Spec weirdness In-Reply-To: <1249926016.3310.32.camel@localhost.localdomain> References: <1249926016.3310.32.camel@localhost.localdomain> Message-ID: <20090810184504.GW3501@amd.home.annexia.org> On Mon, Aug 10, 2009 at 10:40:16AM -0700, Jesse Keating wrote: > I'm looking at the spec file for libguestfs, and all I can say is WTF. > There is a lot of crazyness going on in this spec, chroots within > chroots, making a repo of yum cache packages and using it again, calling > qemu, and none of it is really documented in the spec as for what and > why things are done this way. Hey Jesse, I'll explain below what the general idea is, then provide at the end some commentary inline on specific points within the specfile. It certainly is a complex specfile. In case you aren't familiar with it, libguestfs (http://libguestfs.org) is a tool for modifying VM disk images. For example: $ guestfish -a Fedora10.img Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help with commands 'quit' to quit the shell > run > list-devices /dev/vda > list-partitions /dev/vda1 /dev/vda2 /dev/vda3 > lvs /dev/VolGroup00/LogVol00 /dev/VolGroup00/LogVol01 > file /dev/VolGroup00/LogVol00 Linux rev 1.0 ext3 filesystem data (large files) > mount /dev/VolGroup00/LogVol00 / > cat /etc/redhat-release Fedora release 10 (Cambridge) > vi /etc/passwd > ^D What we do to make this happen is run a small Fedora distro (called the "appliance") under qemu which is attached to the disk image in question. The appliance runs a Linux kernel, LVM tools etc etc and thus has full access to the disk. You can also run qemu as non-root, which means you don't need to be root to edit disk images. The complexity in the specfile is mainly around building this appliance. We use a tool called febootstrap which is basically a shell script that runs 'yum' as non-root, using Debian's fakeroot and fakechroot programs. febootstrap can take any yum repository and turn it into an appliance, without needing root permission: $ febootstrap fedora-11 ./f11 $ febootstrap-to-initramfs ./f11 > initrd.img Of course during the Koji build we don't have a yum repository, and we don't have (or want) network access. So we make one using createrepo + the BuildRequired rpms from the mock cache. There's a further complexity here -- a normal appliance would actually contain the kernel + glibc + libraries + programs. However that is undesirable from a Fedora point of view, since it's very similar to static linking. If we really shipped that as an appliance then there would be obvious security / patching headaches if (for example) glibc had a security bug. Therefore we don't actually bundle any binaries. We remove those from the final appliance, and get them from the host system at runtime. The technique is called building a "supermin appliance" and it's described here: http://libguestfs.org/README.txt under "supermin appliance" It is important to reiterate that the appliance we ship in the RPM *does not* contain any libraries or binaries. We just remember where those files were, and pull them out of the host's filesystem at runtime. >From the point of view of improving Koji (or mock) it would be nice to have a more official method to access the build RPMs, although the technique we are using works fine. On to the specfile itself: # Enable to build w/o network. %global buildnonet 1 Summary: Access and modify virtual machine disk images Name: libguestfs [...] # Basic build requirements: BuildRequires: /usr/bin/pod2man BuildRequires: /usr/bin/pod2text BuildRequires: febootstrap >= 2.3 BuildRequires: augeas-devel >= 0.5.0 BuildRequires: readline-devel BuildRequires: squashfs-tools BuildRequires: qemu-kvm >= 0.10-7 BuildRequires: createrepo BuildRequires: glibc-static # This is only needed for RHEL 5 because readline-devel doesn't # properly depend on it, but doesn't do any harm on other platforms: BuildRequires: ncurses-devel These are the basic build requires for making the actual package. # Build requirements for the appliance (see 'make.sh.in' in the source): BuildRequires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng BuildRequires: MAKEDEV, net-tools, augeas-libs, file BuildRequires: module-init-tools, procps, strace, iputils BuildRequires: dosfstools, zerofree, lsof, scrub %ifarch %{ix86} x86_64 BuildRequires: grub, ntfsprogs %endif These are the BRs reflecting what is inside the appliance ... # Must match the above set of BuildRequires exactly! Requires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng Requires: MAKEDEV, net-tools, augeas-libs, file Requires: module-init-tools, procps, strace, iputils Requires: dosfstools, zerofree, lsof, scrub %ifarch %{ix86} x86_64 Requires: grub, ntfsprogs %endif ... and at runtime we need the same set of Requires, because of the supermin appliance described above. Those files that we evicted from the appliance at build time must exist in the host system at runtime. [...] %build %if %{buildnonet} mkdir repo find /var/cache/yum -type f -name '*.rpm' -print0 | xargs -0 cp -t repo createrepo repo %define extra --with-mirror=file://$(pwd)/repo --with-repo=fedora-12 --with-updates=none %else %define extra %nil %endif This is the part where we create the local repository from the mock cache. The %{buildnonet} switch allows people to build from the Fedora repos instead if they do have network access. # --with-net-if=ne2k_pci is a workaround for RHBZ#516022. ./configure \ --prefix=%{_prefix} --libdir=%{_libdir} \ --mandir=%{_mandir} \ --with-qemu="qemu-kvm qemu-system-%{_build_arch} qemu" \ --enable-debug-command \ --enable-supermin \ --with-net-if=ne2k_pci \ %{extra} # This ensures that /usr/sbin/chroot is on the path. Not needed # except for RHEL 5, it shouldn't do any harm on other platforms. export PATH=/usr/sbin:$PATH # 'INSTALLDIRS' ensures that perl libs are installed in the vendor dir # not the site dir. make INSTALLDIRS=vendor %{?_smp_mflags} This bit is building the library + appliance + 6 language bindings. %check # Enable debugging - very useful if a test does fail, although # it produces masses of output in the build.log. export LIBGUESTFS_DEBUG=1 # Uncomment one of these, depending on whether you want to # do a very long and thorough test ('make check') or just # a quick test to see if things generally work. # Tracking test issues: # BZ archs branch reason # 494075 ppc, ppc64 openbios bug causes "invalid/unsupported opcode" # 504273 ppc, ppc64 "no opcode defined" # 505109 ppc, ppc64 "Boot failure! No secondary bootloader specified" # 502058 i386, x86-64 F-11 need to boot with noapic (WORKAROUND ENABLED) # 502074 i386 F-11 commands segfault randomly # 503236 i386 F-12 cryptomgr_test at doublefault_fn # 507066 all F-12 sequence of chroot calls (FIXED) # 513249 all F-12 guestfwd broken in qemu (FIXED) # 516022 all F-12 virtio-net gives "Network is unreachable" errors # (WORKAROUND ENABLED) # 516096 ? F-11 race condition in swapoff/blockdev --rereadpt # 516543 ? F-12 qemu-kvm segfaults when run inside a VM #%ifarch x86_64 #make check #%endif Normally we run the extensive test suite. However because of a bug in qemu (#516543) we are unable to run that at the moment. And the rest is just concerned with the language bindings. 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 rjones at redhat.com Mon Aug 10 18:50:19 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 10 Aug 2009 19:50:19 +0100 Subject: [fedora-virt] Spec weirdness In-Reply-To: <20090810181738.GH9568@redhat.com> References: <1249926016.3310.32.camel@localhost.localdomain> <20090810181738.GH9568@redhat.com> Message-ID: <20090810185019.GX3501@amd.home.annexia.org> On Mon, Aug 10, 2009 at 07:17:38PM +0100, Daniel P. Berrange wrote: > On Fedora this is done using febootstrap, which is a Fedora equivalent > of debootstrap from Debian world & indeed it uses debootstrap on Debian. > The idea of (fe|de)bootstrap is to allow ordinary unprivileged users to > be able to install a set of packages (RPMS / Debs) into a virtual root > directory of their own, without needing any privileged component. And indeed Debian are now packaging libguestfs. They ported it to use debootstrap instead of febootstrap, but the build requirements are the same: http://pkg-libvirt.alioth.debian.org/packages/unstable/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jonr at destar.net Mon Aug 10 23:04:00 2009 From: jonr at destar.net (jonr at destar.net) Date: Mon, 10 Aug 2009 15:04:00 -0800 Subject: [fedora-virt] fc11 and xen Message-ID: <20090810150400.846213pflie53nmo@www.destar.net> Hello List, I would like to install xen with dom0 and HVM support on FC11 with a recent kernel. Is this possible and if so, is there any documentation that would help me to get the right pieces? Thank you for any help, Jon From itamar at ispbrasil.com.br Mon Aug 10 23:10:24 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 10 Aug 2009 20:10:24 -0300 Subject: [fedora-virt] fc11 and xen In-Reply-To: <20090810150400.846213pflie53nmo@www.destar.net> References: <20090810150400.846213pflie53nmo@www.destar.net> Message-ID: yes please look https://fedoraproject.org/wiki/Features/XenPvopsDom0 M A Young has built unofficial pv_ops dom0 kernel RPMs for testing, available from his directory http://fedorapeople.org/~myoung/dom0/ On Mon, Aug 10, 2009 at 8:04 PM, wrote: > Hello List, > > I would like to install xen with dom0 and HVM support on FC11 with a recent > kernel. Is this possible and if so, is there any documentation that would > help me to get the right pieces? > > Thank you for any help, > > Jon ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From pasik at iki.fi Tue Aug 11 06:01:53 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Tue, 11 Aug 2009 09:01:53 +0300 Subject: [fedora-virt] fc11 and xen In-Reply-To: References: <20090810150400.846213pflie53nmo@www.destar.net> Message-ID: <20090811060153.GG24960@edu.joroinen.fi> On Mon, Aug 10, 2009 at 08:10:24PM -0300, Itamar Reis Peixoto wrote: > yes please look > > > https://fedoraproject.org/wiki/Features/XenPvopsDom0 > > M A Young has built unofficial pv_ops dom0 kernel RPMs for testing, > available from his directory > > http://fedorapeople.org/~myoung/dom0/ > Note that at the moment only the 64bit pv_ops dom0 kernel works! 32bit will (most probably) crash on start. That bug is being worked on, and will hopefully be fixed soon. -- Pasi > > On Mon, Aug 10, 2009 at 8:04 PM, wrote: > > Hello List, > > > > I would like to install xen with dom0 and HVM support on FC11 with a recent > > kernel. Is this possible and if so, is there any documentation that would > > help me to get the right pieces? > > > > Thank you for any help, > > > > Jon > > ------------ > > Itamar Reis Peixoto > > e-mail/msn: itamar at ispbrasil.com.br > sip: itamar at ispbrasil.com.br > skype: itamarjp > icq: 81053601 > +55 11 4063 5033 > +55 34 3221 8599 > > _______________________________________________ > Fedora-virt mailing list > Fedora-virt at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-virt From kraxel at redhat.com Tue Aug 11 08:24:29 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 11 Aug 2009 10:24:29 +0200 Subject: [fedora-virt] Re: [Fedora-xen] [Xen-devel] [ANNOUNCE] Xen 3.3.2 and 3.4.1 released In-Reply-To: <20090810170947.GC24960@edu.joroinen.fi> References: <20090810170947.GC24960@edu.joroinen.fi> Message-ID: <4A812ABD.9050402@redhat.com> Hi, > 3.4.1: http://www.xen.org/download/ Great timing. They managed to do the release just one day after the alpha freeze. Packages are built, but they will not hit the repos until the alpha is done. You can grab them from koji though: http://kojipkgs.fedoraproject.org/packages/xen/3.4.1/1.fc12/ enjoy, Gerd From markmc at redhat.com Tue Aug 11 09:00:49 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 11 Aug 2009 10:00:49 +0100 Subject: [fedora-virt] Re: [Fedora-xen] [Xen-devel] [ANNOUNCE] Xen 3.3.2 and 3.4.1 released In-Reply-To: <4A812ABD.9050402@redhat.com> References: <20090810170947.GC24960@edu.joroinen.fi> <4A812ABD.9050402@redhat.com> Message-ID: <1249981249.3494.28.camel@blaa> Hi Gerd, On Tue, 2009-08-11 at 10:24 +0200, Gerd Hoffmann wrote: > Hi, > > > 3.4.1: http://www.xen.org/download/ > > Great timing. They managed to do the release just one day after the > alpha freeze. Packages are built, but they will not hit the repos until > the alpha is done. You can grab them from koji though: > > http://kojipkgs.fedoraproject.org/packages/xen/3.4.1/1.fc12/ See: https://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy You can file a tag request to have it tagged into f12-alpha. I've done a number of these: https://fedorahosted.org/rel-eng/ticket/2051 https://fedorahosted.org/rel-eng/ticket/2052 https://fedorahosted.org/rel-eng/ticket/2053 https://fedorahosted.org/rel-eng/ticket/2060 https://fedorahosted.org/rel-eng/ticket/2088 The alpha has been delayed a week now and since problems in the xen package are only going to affect a small number of bleeding edge testers, I don't see why rel-eng would refuse the request. Cheers, Mark. From loganjerry at gmail.com Tue Aug 11 15:30:17 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 11 Aug 2009 09:30:17 -0600 Subject: [fedora-virt] AVC denials on F-11 Message-ID: <870180fe0908110830g38c53df5u75f204b61a245fa7@mail.gmail.com> I just did a yum upgrade this morning, and got glibc-2.10.1-4.x86_64, where the top ChangeLog entry says: * Tue Aug 04 2009 Andreas Schwab - 2.10.1-4 - Reenable setuid on pt_chown. Now trying to start a virtual machine with virt-manager yields this AVC denial: node=localhost.localdomain type=AVC msg=audit(1250004330.149:46142): avc: denied { setrlimit } for pid=18539 comm="qemu-kvm" scontext=system_u:system_r:svirt_t:s0:c141,c175 tcontext=system_u:system_r:svirt_t:s0:c141,c175 tclass=process node=localhost.localdomain type=SYSCALL msg=audit(1250004330.149:46142): arch=c000003e syscall=160 success=no exit=-13 a0=4 a1=7fff65c9ef50 a2=0 a3=7fac28fde220 items=0 ppid=18535 pid=18539 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c141,c175 key=(null) ... and two instances of this AVC denial: node=localhost.localdomain type=AVC msg=audit(1250004330.150:46143): avc: denied { setattr } for pid=18539 comm="pt_chown" name="6" dev=devpts ino=9 scontext=system_u:system_r:svirt_t:s0:c141,c175 tcontext=system_u:object_r:devpts_t:s0:c141,c175 tclass=chr_file node=localhost.localdomain type=SYSCALL msg=audit(1250004330.150:46143): arch=c000003e syscall=92 success=no exit=-13 a0=7fc194e8f1d0 a1=0 a2=5 a3=7fff01c34de0 items=0 ppid=18535 pid=18539 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pt_chown" exe="/usr/libexec/pt_chown" subj=system_u:system_r:svirt_t:s0:c141,c175 key=(null) ... and a dialog box from virt-manager that says: "Error starting domain: internal error unable to start guest: qemu: could not open monitor device 'pty'" with this traceback: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 493, in run_domain vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 573, in startup self.vm.create() File "/usr/lib64/python2.6/site-packages/libvirt.py", line 287, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error unable to start guest: qemu: could not open monitor device 'pty' Whose bug is this? Also, is there anything to be done about this besides rolling glibc back to its previous version? -- Jerry James http://www.jamezone.org/ From markmc at redhat.com Tue Aug 11 15:55:55 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 11 Aug 2009 16:55:55 +0100 Subject: [fedora-virt] AVC denials on F-11 In-Reply-To: <870180fe0908110830g38c53df5u75f204b61a245fa7@mail.gmail.com> References: <870180fe0908110830g38c53df5u75f204b61a245fa7@mail.gmail.com> Message-ID: <1250006156.3494.50.camel@blaa> On Tue, 2009-08-11 at 09:30 -0600, Jerry James wrote: > I just did a yum upgrade this morning, and got glibc-2.10.1-4.x86_64, > where the top ChangeLog entry says: > > * Tue Aug 04 2009 Andreas Schwab - 2.10.1-4 > - Reenable setuid on pt_chown. Ah, that's where it came from! Thanks for that, could you add that information to this bug: https://bugzilla.redhat.com/515521 Cheers, Mark. From loganjerry at gmail.com Tue Aug 11 16:06:16 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 11 Aug 2009 10:06:16 -0600 Subject: [fedora-virt] AVC denials on F-11 In-Reply-To: <1250006156.3494.50.camel@blaa> References: <870180fe0908110830g38c53df5u75f204b61a245fa7@mail.gmail.com> <1250006156.3494.50.camel@blaa> Message-ID: <870180fe0908110906o6b64e234oefb548c02cb88a5c@mail.gmail.com> On Tue, Aug 11, 2009 at 9:55 AM, Mark McLoughlin wrote: > Ah, that's where it came from! Thanks for that, could you add that > information to this bug: > > ?https://bugzilla.redhat.com/515521 > > Cheers, > Mark. Done. I've rolled back to glibc-2.10.1-2 in the meantime so that I can get some work done. -- Jerry James http://www.jamezone.org/ From tom.horsley at att.net Tue Aug 11 16:54:15 2009 From: tom.horsley at att.net (Tom Horsley) Date: Tue, 11 Aug 2009 12:54:15 -0400 Subject: [fedora-virt] Am I using kvm? Message-ID: <20090811125415.15af24c5@tomh> That is the question :-). I've used virt-manager on f11 to create a VM where I am at the moment installing an f11 vm, but I don't see the string "kvm" in anything involved in this VM. How can I tell what kind of emulation is being used for the machine? (Shouldn't that be mentioned in the Details tab somewhere?) The machine is a xeon system where "vmx" does show up in /proc/cpuinfo and lsmod shows a "kvm" module. Is it just a given that I will therefore be using kvm? The only "Virt Type" I was offered by virt-manager when doing the install was "qemu". From berrange at redhat.com Tue Aug 11 17:00:08 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 11 Aug 2009 18:00:08 +0100 Subject: [fedora-virt] Am I using kvm? In-Reply-To: <20090811125415.15af24c5@tomh> References: <20090811125415.15af24c5@tomh> Message-ID: <20090811170008.GA11084@redhat.com> On Tue, Aug 11, 2009 at 12:54:15PM -0400, Tom Horsley wrote: > That is the question :-). > > I've used virt-manager on f11 to create a VM where I am at the moment > installing an f11 vm, but I don't see the string "kvm" in anything > involved in this VM. How can I tell what kind of emulation is being > used for the machine? (Shouldn't that be mentioned in the Details > tab somewhere?) > > The machine is a xeon system where "vmx" does show up in /proc/cpuinfo > and lsmod shows a "kvm" module. Is it just a given that I will > therefore be using kvm? The only "Virt Type" I was offered by > virt-manager when doing the install was "qemu". It would have offered you 'kvm' is that was available, so you'll be using QEMU. You want to check 'virsh capabilities' to verify that libvirt actually detected presence of KVM. 'virsh dumpxml GUEST' should also show type='kvm' and pointing go qemu-kvm if virt-manager actually requested it. 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 Tue Aug 11 17:30:46 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 11 Aug 2009 18:30:46 +0100 Subject: [fedora-virt] Am I using kvm? In-Reply-To: <20090811125415.15af24c5@tomh> References: <20090811125415.15af24c5@tomh> Message-ID: <1250011846.3494.54.camel@blaa> On Tue, 2009-08-11 at 12:54 -0400, Tom Horsley wrote: > That is the question :-). And does this answer it? :-) https://fedoraproject.org/wiki/Reporting_virtualization_bugs#Is_My_Guest_Using_KVM.3F Cheers, Mark. From tom.horsley at att.net Tue Aug 11 17:59:17 2009 From: tom.horsley at att.net (Tom Horsley) Date: Tue, 11 Aug 2009 13:59:17 -0400 Subject: [fedora-virt] Am I using kvm? In-Reply-To: <20090811170008.GA11084@redhat.com> References: <20090811125415.15af24c5@tomh> <20090811170008.GA11084@redhat.com> Message-ID: <20090811135917.3359fb49@tomh> On Tue, 11 Aug 2009 18:00:08 +0100 Daniel P. Berrange wrote: > It would have offered you 'kvm' is that was available, so you'll be > using QEMU. You want to check 'virsh capabilities' to verify that > libvirt actually detected presence of KVM. 'virsh dumpxml GUEST' > should also show type='kvm' and pointing go qemu-kvm if > virt-manager actually requested it. OK, I found it was the BIOS - it only took two tries to fix it since I missed the fine print saying I also had to power cycle the machine for the change to take effect :-). Now virsh capabilities does indeed mention kvm. Thanks for the info. From jkeating at redhat.com Wed Aug 12 23:56:15 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Aug 2009 16:56:15 -0700 Subject: [fedora-virt] Re: Spec weirdness In-Reply-To: <20090810184504.GW3501@amd.home.annexia.org> References: <1249926016.3310.32.camel@localhost.localdomain> <20090810184504.GW3501@amd.home.annexia.org> Message-ID: <1250121375.2733.62.camel@localhost.localdomain> On Mon, 2009-08-10 at 19:45 +0100, Richard W.M. Jones wrote: > On Mon, Aug 10, 2009 at 10:40:16AM -0700, Jesse Keating wrote: > > I'm looking at the spec file for libguestfs, and all I can say is WTF. > > There is a lot of crazyness going on in this spec, chroots within > > chroots, making a repo of yum cache packages and using it again, calling > > qemu, and none of it is really documented in the spec as for what and > > why things are done this way. > > Hey Jesse, I'll explain below what the general idea is, then provide > at the end some commentary inline on specific points within the > specfile. It certainly is a complex specfile. > > In case you aren't familiar with it, libguestfs (http://libguestfs.org) > is a tool for modifying VM disk images. For example: > > $ guestfish -a Fedora10.img > > Welcome to guestfish, the libguestfs filesystem interactive shell for > editing virtual machine filesystems. > > Type: 'help' for help with commands > 'quit' to quit the shell > > > run > > list-devices > /dev/vda > > list-partitions > /dev/vda1 > /dev/vda2 > /dev/vda3 > > lvs > /dev/VolGroup00/LogVol00 > /dev/VolGroup00/LogVol01 > > file /dev/VolGroup00/LogVol00 > Linux rev 1.0 ext3 filesystem data (large files) > > mount /dev/VolGroup00/LogVol00 / > > cat /etc/redhat-release > Fedora release 10 (Cambridge) > > > vi /etc/passwd > > ^D > > What we do to make this happen is run a small Fedora distro (called > the "appliance") under qemu which is attached to the disk image in > question. The appliance runs a Linux kernel, LVM tools etc etc and > thus has full access to the disk. You can also run qemu as non-root, > which means you don't need to be root to edit disk images. > > The complexity in the specfile is mainly around building this > appliance. > > We use a tool called febootstrap which is basically a shell script > that runs 'yum' as non-root, using Debian's fakeroot and fakechroot > programs. > > febootstrap can take any yum repository and turn it into an appliance, > without needing root permission: > > $ febootstrap fedora-11 ./f11 > $ febootstrap-to-initramfs ./f11 > initrd.img > > Of course during the Koji build we don't have a yum repository, and we > don't have (or want) network access. So we make one using createrepo > + the BuildRequired rpms from the mock cache. > > There's a further complexity here -- a normal appliance would actually > contain the kernel + glibc + libraries + programs. However that is > undesirable from a Fedora point of view, since it's very similar to > static linking. If we really shipped that as an appliance then there > would be obvious security / patching headaches if (for example) glibc > had a security bug. Therefore we don't actually bundle any binaries. > We remove those from the final appliance, and get them from the host > system at runtime. The technique is called building a "supermin > appliance" and it's described here: http://libguestfs.org/README.txt > under "supermin appliance" It is important to reiterate that the > appliance we ship in the RPM *does not* contain any libraries or > binaries. We just remember where those files were, and pull them out > of the host's filesystem at runtime. > > From the point of view of improving Koji (or mock) it would be nice to > have a more official method to access the build RPMs, although the > technique we are using works fine. So first question, why isn't the chroot that mock created for you good enough? Why do you have to create a second chroot? > On to the specfile itself: > > # Enable to build w/o network. > %global buildnonet 1 > > Summary: Access and modify virtual machine disk images > Name: libguestfs > [...] > # Basic build requirements: > BuildRequires: /usr/bin/pod2man > BuildRequires: /usr/bin/pod2text > BuildRequires: febootstrap >= 2.3 > BuildRequires: augeas-devel >= 0.5.0 > BuildRequires: readline-devel > BuildRequires: squashfs-tools > BuildRequires: qemu-kvm >= 0.10-7 > BuildRequires: createrepo > BuildRequires: glibc-static > > # This is only needed for RHEL 5 because readline-devel doesn't > # properly depend on it, but doesn't do any harm on other platforms: > BuildRequires: ncurses-devel > > These are the basic build requires for making the actual package. > > # Build requirements for the appliance (see 'make.sh.in' in the source): > BuildRequires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng > BuildRequires: MAKEDEV, net-tools, augeas-libs, file > BuildRequires: module-init-tools, procps, strace, iputils > BuildRequires: dosfstools, zerofree, lsof, scrub > %ifarch %{ix86} x86_64 > BuildRequires: grub, ntfsprogs > %endif > > These are the BRs reflecting what is inside the appliance ... > > # Must match the above set of BuildRequires exactly! > Requires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng > Requires: MAKEDEV, net-tools, augeas-libs, file > Requires: module-init-tools, procps, strace, iputils > Requires: dosfstools, zerofree, lsof, scrub > %ifarch %{ix86} x86_64 > Requires: grub, ntfsprogs > %endif > > ... and at runtime we need the same set of Requires, because of the > supermin appliance described above. Those files that we evicted from > the appliance at build time must exist in the host system at runtime. > > [...] > %build > %if %{buildnonet} > mkdir repo > find /var/cache/yum -type f -name '*.rpm' -print0 | xargs -0 cp -t repo > createrepo repo > %define extra --with-mirror=file://$(pwd)/repo --with-repo=fedora-12 --with-updates=none > %else > %define extra %nil > %endif > > This is the part where we create the local repository from the mock > cache. The %{buildnonet} switch allows people to build from the > Fedora repos instead if they do have network access. > > # --with-net-if=ne2k_pci is a workaround for RHBZ#516022. > ./configure \ > --prefix=%{_prefix} --libdir=%{_libdir} \ > --mandir=%{_mandir} \ > --with-qemu="qemu-kvm qemu-system-%{_build_arch} qemu" \ > --enable-debug-command \ > --enable-supermin \ > --with-net-if=ne2k_pci \ > %{extra} > > # This ensures that /usr/sbin/chroot is on the path. Not needed > # except for RHEL 5, it shouldn't do any harm on other platforms. > export PATH=/usr/sbin:$PATH > > # 'INSTALLDIRS' ensures that perl libs are installed in the vendor dir > # not the site dir. > make INSTALLDIRS=vendor %{?_smp_mflags} > > This bit is building the library + appliance + 6 language bindings. > > %check > # Enable debugging - very useful if a test does fail, although > # it produces masses of output in the build.log. > export LIBGUESTFS_DEBUG=1 > > # Uncomment one of these, depending on whether you want to > # do a very long and thorough test ('make check') or just > # a quick test to see if things generally work. > > # Tracking test issues: > # BZ archs branch reason > # 494075 ppc, ppc64 openbios bug causes "invalid/unsupported opcode" > # 504273 ppc, ppc64 "no opcode defined" > # 505109 ppc, ppc64 "Boot failure! No secondary bootloader specified" > # 502058 i386, x86-64 F-11 need to boot with noapic (WORKAROUND ENABLED) > # 502074 i386 F-11 commands segfault randomly > # 503236 i386 F-12 cryptomgr_test at doublefault_fn > # 507066 all F-12 sequence of chroot calls (FIXED) > # 513249 all F-12 guestfwd broken in qemu (FIXED) > # 516022 all F-12 virtio-net gives "Network is unreachable" errors > # (WORKAROUND ENABLED) > # 516096 ? F-11 race condition in swapoff/blockdev --rereadpt > # 516543 ? F-12 qemu-kvm segfaults when run inside a VM > > #%ifarch x86_64 > #make check > #%endif > > Normally we run the extensive test suite. However because of a bug in > qemu (#516543) we are unable to run that at the moment. > > And the rest is just concerned with the language bindings. > > Rich. > -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From phil at pricom.com.au Thu Aug 13 05:57:19 2009 From: phil at pricom.com.au (Philip Rhoades) Date: Thu, 13 Aug 2009 15:57:19 +1000 Subject: [fedora-virt] KVM Virtual machine mounting physical drive In-Reply-To: References: Message-ID: <4A83AB3F.7000707@pricom.com.au> People, I need to upgrade and I want to start using 64bit hardware that can do KVM but I have a question before I start spending money: I have been using Fedora since the beginning and regularly upgrade my current hardware with each new version. To minimise restoring data, I have a pair of drives setup as RAID 1 (ie separate from other partitions) that is used for /home . So after an upgrade, I simply mount /dev/md0 on /home. Would I be able to do this from a virtual machine in a new KVM setup? Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil at pricom.com.au From rjones at redhat.com Thu Aug 13 08:01:51 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 13 Aug 2009 09:01:51 +0100 Subject: [fedora-virt] Re: Spec weirdness In-Reply-To: <1250121375.2733.62.camel@localhost.localdomain> References: <1249926016.3310.32.camel@localhost.localdomain> <20090810184504.GW3501@amd.home.annexia.org> <1250121375.2733.62.camel@localhost.localdomain> Message-ID: <20090813080151.GP3501@amd.home.annexia.org> On Wed, Aug 12, 2009 at 04:56:15PM -0700, Jesse Keating wrote: > So first question, why isn't the chroot that mock created for you good > enough? Why do you have to create a second chroot? We have to put custom files (configuration, /init etc.) into our chroot, because the appliance we build is different from the host under which it runs. We also rm -rf large parts of the appliance in order to make it small enough to boot in memory. Also we don't just build in mock. In fact that is the rare case. Most people build using ./configure && make. And of course we support Debian etc. You can see how we build the appliance here: http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/make.sh.in;hb=HEAD http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/update.sh.in;hb=HEAD Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From ondrejj at salstar.sk Thu Aug 13 08:18:39 2009 From: ondrejj at salstar.sk (=?utf-8?B?SsOhbiBPTkRSRUogKFNBTCk=?=) Date: Thu, 13 Aug 2009 10:18:39 +0200 Subject: [fedora-virt] Re: Spec weirdness In-Reply-To: <20090813080151.GP3501@amd.home.annexia.org> References: <1249926016.3310.32.camel@localhost.localdomain> <20090810184504.GW3501@amd.home.annexia.org> <1250121375.2733.62.camel@localhost.localdomain> <20090813080151.GP3501@amd.home.annexia.org> Message-ID: <20090813081839.GD5934@salstar.sk> On Thu, Aug 13, 2009 at 09:01:51AM +0100, Richard W.M. Jones wrote: > On Wed, Aug 12, 2009 at 04:56:15PM -0700, Jesse Keating wrote: > > So first question, why isn't the chroot that mock created for you good > > enough? Why do you have to create a second chroot? > > We have to put custom files (configuration, /init etc.) into our > chroot, because the appliance we build is different from the host > under which it runs. We also rm -rf large parts of the appliance in > order to make it small enough to boot in memory. > > Also we don't just build in mock. In fact that is the rare case. > Most people build using ./configure && make. And of course we support > Debian etc. And also there are different requirements for package build and for appliance for libguestfs. For example mock needs gcc, ... libguestfs don't. If there will be mock cache available in mock's chroot, then may be Rich can use them to prefill febootstrap cache. SAL From berrange at redhat.com Thu Aug 13 08:36:19 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 13 Aug 2009 09:36:19 +0100 Subject: [fedora-virt] Re: Spec weirdness In-Reply-To: <20090813081839.GD5934@salstar.sk> References: <1249926016.3310.32.camel@localhost.localdomain> <20090810184504.GW3501@amd.home.annexia.org> <1250121375.2733.62.camel@localhost.localdomain> <20090813080151.GP3501@amd.home.annexia.org> <20090813081839.GD5934@salstar.sk> Message-ID: <20090813083619.GE10257@redhat.com> On Thu, Aug 13, 2009 at 10:18:39AM +0200, J?n ONDREJ (SAL) wrote: > On Thu, Aug 13, 2009 at 09:01:51AM +0100, Richard W.M. Jones wrote: > > On Wed, Aug 12, 2009 at 04:56:15PM -0700, Jesse Keating wrote: > > > So first question, why isn't the chroot that mock created for you good > > > enough? Why do you have to create a second chroot? > > > > We have to put custom files (configuration, /init etc.) into our > > chroot, because the appliance we build is different from the host > > under which it runs. We also rm -rf large parts of the appliance in > > order to make it small enough to boot in memory. > > > > Also we don't just build in mock. In fact that is the rare case. > > Most people build using ./configure && make. And of course we support > > Debian etc. > > And also there are different requirements for package build and for > appliance for libguestfs. For example mock needs gcc, ... libguestfs don't. > > If there will be mock cache available in mock's chroot, then may be Rich can > use them to prefill febootstrap cache. That's what the specfile is already doing. It is pointing febootstrap at a yum repo populated from the mock RPM cache inside the chroot. 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 rjones at redhat.com Thu Aug 13 18:47:56 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 13 Aug 2009 19:47:56 +0100 Subject: [fedora-virt] KVM Virtual machine mounting physical drive In-Reply-To: <4A83AB3F.7000707@pricom.com.au> References: <4A83AB3F.7000707@pricom.com.au> Message-ID: <20090813184756.GA22141@amd.home.annexia.org> On Thu, Aug 13, 2009 at 03:57:19PM +1000, Philip Rhoades wrote: > People, > > I need to upgrade and I want to start using 64bit hardware that can do > KVM but I have a question before I start spending money: > > I have been using Fedora since the beginning and regularly upgrade my > current hardware with each new version. To minimise restoring data, I > have a pair of drives setup as RAID 1 (ie separate from other > partitions) that is used for /home . So after an upgrade, I simply > mount /dev/md0 on /home. Would I be able to do this from a virtual > machine in a new KVM setup? Yes, virtual machines can access drives directly, so you can export /dev/md0 on the host into a guest (inside the guest it will see it as /dev/vdb or similar). What you can't do is to share any filesystem between the host and a guest simultaneously, or between guests simultaneously. In order to do that you have to use a special sort of filesystem, called a cluster filesystem, for example Red Hat GFS. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Thu Aug 13 19:04:42 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 13 Aug 2009 20:04:42 +0100 Subject: [fedora-virt] ANNOUNCE: libguestfs 1.0.67 released Message-ID: <20090813190442.GB22141@amd.home.annexia.org> I'm pleased to announce the release of libguestfs 1.0.67. Libguestfs is a library for accessing and modifying virtual machine disk images. Home page: http://libguestfs.org/ Source: http://libguestfs.org/download/ Binaries: http://libguestfs.org/FAQ.html#binaries Fedora builds aren't ready yet because of the current Koji outage. (These release notes cover all the significant changes since the last announcement which was for 1.0.64, 3 weeks ago). New features - SELinux support, for guests that use it - inotify support - Allow swapon/swapoff from a swap file - New command: fallocate - New commands to make hard and symbolic links, readlink - New command: realpath - New commands to grep files - New command: file-architecture - 'file' command can now look in compressed files automatically Bugs fixed - Big rewrite of daemon code that uses device and path parameters (Jim Meyering) - Do malloc fuzzing during tests (Jim Meyering) - Fix case where grub /boot is not a separate filesystem (Matthew Booth) - Use grub to find kernels (Matthew Booth) - Can now access disk images which are located on a tmpfs - Tons of code fixes and cleanups (Jim Meyering) - Fix segfault in guestfish tab completion - Fix CD-ROM device recognition (Matthew Booth) - Uses gnulib (Jim Meyering) - Improve speed of tests by using squashfs disks for any static test data - Improve shell quoting in the daemon using custom formatters Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From tom.horsley at att.net Thu Aug 13 19:32:56 2009 From: tom.horsley at att.net (Tom Horsley) Date: Thu, 13 Aug 2009 15:32:56 -0400 Subject: [fedora-virt] Does this virtual disk exist? Message-ID: <20090813153256.7728a124@tomh> I've seen all kinds of virtual disk devices for virtual machines to use, but I was wondering just the other day if this (possibly silly) sort of virtual disk exists: Take partitions /dev/sda1, /dev/sdb2, slap together a pretend MBR and partition table out of thin air, and tell this virtual machine it is his virtual disk drive. The motivation being to easily run a virtual machine from a partition I can also boot as a stand alone separate boot partition. Naturally, the initrd stuff would get kind of dicey (hence the "possibly silly" qualifier :-). From m3freak at thesandhufamily.ca Thu Aug 13 19:49:52 2009 From: m3freak at thesandhufamily.ca (m3freak at thesandhufamily.ca) Date: Thu, 13 Aug 2009 15:49:52 -0400 Subject: [fedora-virt] KVM VMs and vlans Message-ID: Hello All, I need to use VLAN tags for a couple of KVM VMs and the KVM host. However, I'm unsure if I should create all of the vlan tagged interfaces on the host side (and then use two of those interface in the VMs), or if I should only tag the VM interfaces in the VMs themselves (and tag host NIC for the host's use). In either case, I've assumed the host NIC should be configured as a bridge device. What's the best/right way to do this? Regards, Ranbir -- Kanwar Ranbir Sandhu From markmc at redhat.com Fri Aug 14 08:23:33 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 14 Aug 2009 09:23:33 +0100 Subject: [fedora-virt] Does this virtual disk exist? In-Reply-To: <20090813153256.7728a124@tomh> References: <20090813153256.7728a124@tomh> Message-ID: <1250238213.3010.28.camel@blaa> On Thu, 2009-08-13 at 15:32 -0400, Tom Horsley wrote: > I've seen all kinds of virtual disk devices for virtual machines > to use, but I was wondering just the other day if this (possibly > silly) sort of virtual disk exists: > > Take partitions /dev/sda1, /dev/sdb2, slap together a pretend > MBR and partition table out of thin air, and tell this virtual > machine it is his virtual disk drive. > > The motivation being to easily run a virtual machine from > a partition I can also boot as a stand alone separate boot > partition. > > Naturally, the initrd stuff would get kind of dicey (hence > the "possibly silly" qualifier :-). You would probably be able to achieve this with the device-mapper linear target. It would take a lot of experimentation, but the idea would be: 1) Create a single sector loopback device containing the MBR and partition table 2) Create a device mapper device with a table like this: 0 1 linear /dev/loop0 0 1 N_sda1_sects linear /dev/sda1 0 1+N_sda1_sects N_sdb2_sects linear /dev/sdb2 0 3) Pass the device mapper device to the virtual machine Fun project! :-) Cheers, Mark. From m.a.young at durham.ac.uk Fri Aug 14 21:32:34 2009 From: m.a.young at durham.ac.uk (M A Young) Date: Fri, 14 Aug 2009 22:32:34 +0100 (BST) Subject: [fedora-virt] Re: [Fedora-xen] Dom0 kernels In-Reply-To: References: <20090328163545.GM31725@salstar.sk> <20090414143618.GH351@redhat.com> Message-ID: Here is another update. (kernel-2.6.31-0.1.2.52.rc6.xendom0.fc12) at http://koji.fedoraproject.org/koji/taskinfo?taskID=1605651 and the repository http://fedorapeople.org/~myoung/dom0/ . I have had trouble getting x86_64 kernels built over the last week or so to boot, but this one does work. I haven't tried i686. Michael Young From dlbewley at lib.ucdavis.edu Mon Aug 17 03:35:07 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Sun, 16 Aug 2009 20:35:07 -0700 Subject: [fedora-virt] KVM VMs and vlans In-Reply-To: References: Message-ID: <1250480107.6686.12.camel@seitan.home.bewley.net> On Thu, 2009-08-13 at 15:49 -0400, m3freak at thesandhufamily.ca wrote: > Hello All, > > I need to use VLAN tags for a couple of KVM VMs and the KVM host. However, > I'm unsure if I should create all of the vlan tagged interfaces on the host > side (and then use two of those interface in the VMs), or if I should only > tag the VM interfaces in the VMs themselves (and tag host NIC for the > host's use). In either case, I've assumed the host NIC should be > configured as a bridge device. > > What's the best/right way to do this? I terminate the 802.1q trunk at the host, and create bridges from each VLAN interface. These bridges are what is used by the guests. They can of course optionally have an IP address for use by the host. For example host# cat ifcfg-vlan6 DEVICE=eth0.6 BRIDGE=br6 VLAN=yes ONBOOT=yes BOOTPROTO=none host# cat ifcfg-br6 DEVICE=br6 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes host# virsh dumpxml 12 |grep bridge