From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Oct 1 09:19:02 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 1 Oct 2007 11:19:02 +0200 Subject: [et-mgmt-tools] [ANNOUNCE] Cobbler 0.6.2 (pre) release In-Reply-To: <46FD1128.40300@redhat.com> References: <46F9902A.8060205@redhat.com> <20070928135344.1eaf852d@python3.es.egwn.lan> <46FD1128.40300@redhat.com> Message-ID: <20071001111902.542fc347@python3.es.egwn.lan> Michael DeHaan wrote : > > I'm asking, because I've just tried again as follows : > > > > # koan -s cobbler -y test -v -V test -b xenbr1 > > > > I should have never put the short args in :) He he, too late now! ;-) > > But the /etc/xen/test file contains : > > vif = [ 'mac=00:16:3e:34:61:3e, bridge=xenbr0', ] > > > > So it seems that something is still going wrong. > > > > It may be that your version of libvirt doesn't support that feature. > > The code in question defaults to "old-style" network setup when it can't > successfully add the interface. > You may want to upgrade your version of virtinst. Oh. Well, then I'll just have to wait for RHEL5.1, hoping it will have a recent enough version. Or maybe I'll try the packages from the beta again. Thanks! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.6-81.fc7 Load : 0.33 0.41 0.43 From fj0588di at aa.jp.fujitsu.com Tue Oct 2 09:44:44 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Tue, 2 Oct 2007 18:44:44 +0900 Subject: [et-mgmt-tools] [PATCH][virt-clone] Check the MAC address confliction with ignoring character case. Message-ID: <200710021844.BBF73858.EG90JK69@aa.jp.fujitsu.com> Hi, This patch adds mac address confliction check for following case on virt-clone. hostA:aa:bb:cc:dd:ee:ff hostB:Aa:Bb:Cc:Dd:Ee:Ff(planned cloning guest) This patch stops cloning for above case, because of MAC address confliction. Signed-off-by: Shigeki Sakamoto Thanks, Shigeki Sakamoto. ---------------------------------------------------------------------- diff -r 219bd66150dd virtinst/CloneManager.py --- a/virtinst/CloneManager.py Fri Sep 28 12:33:09 2007 -0400 +++ b/virtinst/CloneManager.py Tue Oct 02 15:17:44 2007 +0900 @@ -422,12 +422,14 @@ class CloneDesign(object): except: continue ctx = doc.xpathNewContext() + mac_index = (str(doc).upper()).find(mac.upper()) + if mac_index == -1: + continue + mac_comp = str(doc)[mac_index:mac_index+17] try: try: count += ctx.xpathEval("count(/domain/devices/interface/mac[@address='%s'])" - % mac.upper()) - count += ctx.xpathEval("count(/domain/devices/interface/mac[@address='%s'])" - % mac.lower()) + % mac_comp) except: continue finally: From kunkichi at gmail.com Tue Oct 2 10:06:18 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Tue, 2 Oct 2007 19:06:18 +0900 Subject: [et-mgmt-tools] Abount Japanese Translation for Cobbler Documents In-Reply-To: <46FB15DE.7090706@redhat.com> References: <4dd11c330709261750q7925556bo4d437bdee5916cef@mail.gmail.com> <46FB15DE.7090706@redhat.com> Message-ID: <4dd11c330710020306k2759009bs3d1df1a45d3d351a@mail.gmail.com> Hi, I'm still on the way, some basic documents' translating was finished. If there are users in Japan read this, see the following: http://www.cafechantant.com/trac/wiki/cobbler_top Currently, documents in Japanese available are: - cobbler manpage - koan manpage (although I've never used koan...) - quick start guide using "import" - cobbler tutorial from Red Hat Magazine Still in progress: - Using Cobbler to manage yum repositories - Cobbler's DHCP management features After finish translating documents in http://cobbler.et.redhat.com/, I will start those in cobbler wiki. Anyone who helps translating always welcome;-) Thanks. Kuniaki Shimizu kunkichi at gmail.com 2007/9/27, Michael DeHaan : > Shimizu Kuniaki wrote: > > Hi, > > > > As using cobbler, I think Cobbler is a very nice tool, but documents > > are available only in English. > > I would like to translate some cobbler documents into Japanese and put > > on my website. > > Is that OK? > > > > Kuniaki Shimizu > > kunkichi at gmail.com > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > That's great and I'll gladly link to the translations from the main page. > > Thanks! > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From sakaia at jp.fujitsu.com Tue Oct 2 10:23:16 2007 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Tue, 02 Oct 2007 19:23:16 +0900 Subject: [et-mgmt-tools] Abount Japanese Translation for Cobbler Documents In-Reply-To: <4dd11c330710020306k2759009bs3d1df1a45d3d351a@mail.gmail.com> References: <4dd11c330710020306k2759009bs3d1df1a45d3d351a@mail.gmail.com> Message-ID: <200710021023.l92ANbgB025340@fjmscan502.ms.jp.fujitsu.com> Hi, Kuniaki That's a good work! Anyway , I feel following translation is strange. (in first page) Installation trees can be imported directly from media you already have (or copied from a mirror location), and turned into network install sources within minutes. I see it just for my intersting. And Now I understand what the cobber is. Thanks Atsushi SAKAI "Shimizu Kuniaki" wrote: > Hi, > > I'm still on the way, some basic documents' translating was finished. > If there are users in Japan read this, see the following: > > http://www.cafechantant.com/trac/wiki/cobbler_top > > Currently, documents in Japanese available are: > > - cobbler manpage > - koan manpage (although I've never used koan...) > - quick start guide using "import" > - cobbler tutorial from Red Hat Magazine > > Still in progress: > > - Using Cobbler to manage yum repositories > - Cobbler's DHCP management features > > After finish translating documents in http://cobbler.et.redhat.com/, I > will start those in cobbler wiki. > > Anyone who helps translating always welcome;-) > > Thanks. > > Kuniaki Shimizu > kunkichi at gmail.com > > 2007/9/27, Michael DeHaan : > > Shimizu Kuniaki wrote: > > > Hi, > > > > > > As using cobbler, I think Cobbler is a very nice tool, but documents > > > are available only in English. > > > I would like to translate some cobbler documents into Japanese and put > > > on my website. > > > Is that OK? > > > > > > Kuniaki Shimizu > > > kunkichi at gmail.com > > > > > > _______________________________________________ > > > et-mgmt-tools mailing list > > > et-mgmt-tools at redhat.com > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > That's great and I'll gladly link to the translations from the main page. > > > > Thanks! > > > > --Michael > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From kunkichi at gmail.com Tue Oct 2 11:52:38 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Tue, 2 Oct 2007 20:52:38 +0900 Subject: [et-mgmt-tools] Abount Japanese Translation for Cobbler Documents In-Reply-To: <200710021023.l92ANbgB025340@fjmscan502.ms.jp.fujitsu.com> References: <4dd11c330710020306k2759009bs3d1df1a45d3d351a@mail.gmail.com> <200710021023.l92ANbgB025340@fjmscan502.ms.jp.fujitsu.com> Message-ID: <4dd11c330710020452i37a00e67m7ba51704b39e7bab@mail.gmail.com> Thank you for your quick reply:-) 2007/10/2, Atsushi SAKAI : > That's a good work! > Anyway , I feel following translation is strange. > (in first page) > > Installation trees can be imported directly from media you already have (or > copied from a mirror location), and turned into network install sources > within minutes. You're right. There might be a lot of strange translation because I do feel so, too. :-p I just fixed it, but it may sounds like a diffrent expression with a different meaning a little bit. Sometimes I feel I should try to focus on how easy to read in Japanese and do it, but it may be a little far from the meaning of the original, and vice versa.... Anyway, I opened my Trac's ticket system. If you find any strange, just ticket me, not to this mailing list :-) Thanks. > I see it just for my intersting. > And Now I understand what the cobber is. > > Thanks > Atsushi SAKAI > > > "Shimizu Kuniaki" wrote: > > > Hi, > > > > I'm still on the way, some basic documents' translating was finished. > > If there are users in Japan read this, see the following: > > > > http://www.cafechantant.com/trac/wiki/cobbler_top > > > > Currently, documents in Japanese available are: > > > > - cobbler manpage > > - koan manpage (although I've never used koan...) > > - quick start guide using "import" > > - cobbler tutorial from Red Hat Magazine > > > > Still in progress: > > > > - Using Cobbler to manage yum repositories > > - Cobbler's DHCP management features > > > > After finish translating documents in http://cobbler.et.redhat.com/, I > > will start those in cobbler wiki. > > > > Anyone who helps translating always welcome;-) > > > > Thanks. > > > > Kuniaki Shimizu > > kunkichi at gmail.com > > > > 2007/9/27, Michael DeHaan : > > > Shimizu Kuniaki wrote: > > > > Hi, > > > > > > > > As using cobbler, I think Cobbler is a very nice tool, but documents > > > > are available only in English. > > > > I would like to translate some cobbler documents into Japanese and put > > > > on my website. > > > > Is that OK? > > > > > > > > Kuniaki Shimizu > > > > kunkichi at gmail.com > > > > > > > > _______________________________________________ > > > > et-mgmt-tools mailing list > > > > et-mgmt-tools at redhat.com > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > > > > That's great and I'll gladly link to the translations from the main page. > > > > > > Thanks! > > > > > > --Michael > > > > > > _______________________________________________ > > > et-mgmt-tools mailing list > > > et-mgmt-tools at redhat.com > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From mdehaan at redhat.com Tue Oct 2 14:28:11 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 02 Oct 2007 10:28:11 -0400 Subject: [et-mgmt-tools] Abount Japanese Translation for Cobbler Documents In-Reply-To: <4dd11c330710020452i37a00e67m7ba51704b39e7bab@mail.gmail.com> References: <4dd11c330710020306k2759009bs3d1df1a45d3d351a@mail.gmail.com> <200710021023.l92ANbgB025340@fjmscan502.ms.jp.fujitsu.com> <4dd11c330710020452i37a00e67m7ba51704b39e7bab@mail.gmail.com> Message-ID: <4702557B.6040002@redhat.com> Shimizu Kuniaki wrote: > Thank you for your quick reply:-) > > 2007/10/2, Atsushi SAKAI : > >> That's a good work! >> Anyway , I feel following translation is strange. >> (in first page) >> >> Installation trees can be imported directly from media you already have (or >> copied from a mirror location), and turned into network install sources >> within minutes. >> > > You're right. There might be a lot of strange translation because I do > feel so, too. :-p > I just fixed it, but it may sounds like a diffrent expression with a > different meaning a little bit. > > Sometimes I feel I should try to focus on how easy to read in Japanese > and do it, but it may be a little far from the meaning of the > original, and vice versa.... > > Anyway, I opened my Trac's ticket system. If you find any strange, > just ticket me, not to this mailing list :-) > > Thanks. > > > > > > >> I see it just for my intersting. >> And Now I understand what the cobber is. >> >> Thanks >> Atsushi SAKAI >> >> >> "Shimizu Kuniaki" wrote: >> >> >>> Hi, >>> >>> I'm still on the way, some basic documents' translating was finished. >>> If there are users in Japan read this, see the following: >>> >>> http://www.cafechantant.com/trac/wiki/cobbler_top >>> >>> Currently, documents in Japanese available are: >>> >>> - cobbler manpage >>> - koan manpage (although I've never used koan...) >>> - quick start guide using "import" >>> - cobbler tutorial from Red Hat Magazine >>> >>> Still in progress: >>> >>> - Using Cobbler to manage yum repositories >>> - Cobbler's DHCP management features >>> >>> After finish translating documents in http://cobbler.et.redhat.com/, I >>> will start those in cobbler wiki. >>> >>> Anyone who helps translating always welcome;-) >>> >>> Thanks. >>> >>> Kuniaki Shimizu >>> kunkichi at gmail.com >>> >>> 2007/9/27, Michael DeHaan : >>> >>>> Shimizu Kuniaki wrote: >>>> >>>>> Hi, >>>>> >>>>> As using cobbler, I think Cobbler is a very nice tool, but documents >>>>> are available only in English. >>>>> I would like to translate some cobbler documents into Japanese and put >>>>> on my website. >>>>> Is that OK? >>>>> >>>>> Kuniaki Shimizu >>>>> kunkichi at gmail.com >>>>> >>>>> _______________________________________________ >>>>> et-mgmt-tools mailing list >>>>> et-mgmt-tools at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>>>> >>>>> >>>> That's great and I'll gladly link to the translations from the main page. >>>> >>>> Thanks! >>>> >>>> --Michael >>>> >>>> _______________________________________________ >>>> et-mgmt-tools mailing list >>>> et-mgmt-tools at redhat.com >>>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>>> >>>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > Very cool to see this! ( If only I could read Japanese :) ) I'll link this up shortly. Thanks again! --Michael From chris.sarginson at ukfast.net Tue Oct 2 16:32:29 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Tue, 02 Oct 2007 17:32:29 +0100 Subject: [et-mgmt-tools] Cobbler query Message-ID: <4702729D.9010608@ukfast.net> Hi Guys, I'm looking for a quick definitive answer regarding the cobbler system add command: Basically I will be installing VM's, and they are frequently going to have different RAM/disk size etc, so rather than creating an *insane* amount of profiles for each distro + each possible virt config, I was wondering if I could specify it on a system by system basis? Has anyone else tried/required this? I'm currently running on Fedora 7, and am just using yum provided cobbler/koan. -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT Registered in England. Number 384 5616 From berrange at redhat.com Tue Oct 2 16:53:28 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 2 Oct 2007 17:53:28 +0100 Subject: [et-mgmt-tools] [PATCH][virt-clone] Check the MAC address confliction with ignoring character case. In-Reply-To: <200710021844.BBF73858.EG90JK69@aa.jp.fujitsu.com> References: <200710021844.BBF73858.EG90JK69@aa.jp.fujitsu.com> Message-ID: <20071002165328.GE10551@redhat.com> On Tue, Oct 02, 2007 at 06:44:44PM +0900, S.Sakamoto wrote: > Hi, > > This patch adds mac address confliction check for following case on virt-clone. > > hostA:aa:bb:cc:dd:ee:ff > > hostB:Aa:Bb:Cc:Dd:Ee:Ff(planned cloning guest) > > This patch stops cloning for above case, because of MAC address confliction. Instead of doing this: > + mac_index = (str(doc).upper()).find(mac.upper()) > + if mac_index == -1: > + continue > + mac_comp = str(doc)[mac_index:mac_index+17] Can't you simply use the 'lower-case()' function in XPath ? eg something like count(/domain/devices/interface/mac[lower-case(@address)=lower-case('%s')]) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Tue Oct 2 19:11:16 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 02 Oct 2007 15:11:16 -0400 Subject: [et-mgmt-tools] Cobbler query In-Reply-To: <4702729D.9010608@ukfast.net> References: <4702729D.9010608@ukfast.net> Message-ID: <470297D4.6060509@redhat.com> Chris Sarginson wrote: > Hi Guys, > > I'm looking for a quick definitive answer regarding the cobbler system > add command: > > Basically I will be installing VM's, and they are frequently going to > have different RAM/disk size etc, so rather than creating an *insane* > amount of profiles for each distro + each possible virt config, I was > wondering if I could specify it on a system by system basis? > > Has anyone else tried/required this? > > I'm currently running on Fedora 7, and am just using yum provided > cobbler/koan. > > The idea is that a profile should represent what the system does and is... the kickstart file, the RAM requirements, the disk requirements, and so forth -- to keep all of those things together to make a configuration like "virtual-webserver" completely reproducible and consistant. In the end, that might even make there be less to configure, as you wouldn't need to create the per-system records. An example of this is a development or test environment -- that profile might be rolled out an arbitrary number of times, and you wouldn't neccessarily want to require a cobbler record for every instance of that environment. You'd just use koan with "--virt" and "--profile=development-environ". Now, in an environment where you need DHCP reservations, then yes, you'd want the per-system records. How many profiles is insane, by the way? :) One thing that we have in Cobbler that is intended to help make this more manageable are the concept of inherited profiles. The idea is that you could do: cobbler profile add --name=webserver-base .... --distro=blah cobbler profile add --name=webserver-base-moreram --virt-ram=1024 --inherit=webserver-base So, if you want to modify the profile "webserver-base" it would make changes to all of the subprofiles for you. That may help. koan does offer some local overrides, --virt-name, --virt-disk, --virt-bridge ... though we try to keep those minimal since it's supposed to be a central management way of doing things. Those are there for those folks who want to take advantage of a cobbler server outside of their normal working environment -- for instance, a standalone box outside of a datacenter needs to install a cobbler profile, but the default image location does not suit the environment, etc. Anyhow, let me know if the inherited profiles might work for you ... if not, we can think about whether per-system overrides of everything in the profile object is a good idea or not. I'm willing to remove those restrictions if enough folks find them valuable, though I still think profiles (and sub-profiles) are a very meaningful abstraction. For Web UI uses, we may even leave those overrides under an "advanced" tab or something of the like, to still encourage creation of task-specific profiles. Thoughts? --Michael From chris.sarginson at ukfast.net Wed Oct 3 08:42:22 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Wed, 03 Oct 2007 09:42:22 +0100 Subject: [et-mgmt-tools] Cobbler query (and now Xen too) In-Reply-To: <470297D4.6060509@redhat.com> References: <4702729D.9010608@ukfast.net> <470297D4.6060509@redhat.com> Message-ID: <470355EE.4090002@ukfast.net> Hi Michael, I forgot about the sub profiles being able to override things like that, so thats a (good) alternate way of doing things, thanks. I have a couple of other queries: 1) When using the xen kernel to do the installation, I assume that is not doing hardware virtualisation at all? 2) When not using the xen kernel to do the installation (which I can do if I create the VM manually) I get the following error: xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found 3) When using the xen kernel to start the VM I get the following error: xend.err "Boot loader didn't return any data! 4) Are there plans to further expand cobbler to allow you to select the number of virtual CPU's available? Chris Michael DeHaan wrote: > The idea is that a profile should represent what the system does and > is... the kickstart file, the RAM requirements, the disk requirements, > and so forth -- to keep all of those things together to make a > configuration like "virtual-webserver" completely reproducible and > consistant. In the end, that might even make there be less to > configure, as you wouldn't need to create the per-system records. An > example of this is a development or test environment -- that profile > might be rolled out an arbitrary number of times, and you wouldn't > neccessarily want to require a cobbler record for every instance of that > environment. You'd just use koan with "--virt" and > "--profile=development-environ". Now, in an environment where you need > DHCP reservations, then yes, you'd want the per-system records. > How many profiles is insane, by the way? :) One thing that we have in > Cobbler that is intended to help make this more manageable are the > concept of inherited profiles. > > The idea is that you could do: > cobbler profile add --name=webserver-base .... --distro=blah > cobbler profile add --name=webserver-base-moreram --virt-ram=1024 > --inherit=webserver-base > > So, if you want to modify the profile "webserver-base" it would make > changes to all of the subprofiles for you. That may help. > > koan does offer some local overrides, --virt-name, --virt-disk, > --virt-bridge ... though we try to keep those minimal since it's > supposed to be a central management way > of doing things. Those are there for those folks who want to take > advantage of a cobbler server outside of their normal working > environment -- for instance, a standalone > box outside of a datacenter needs to install a cobbler profile, but the > default image location does not suit the environment, etc. > > Anyhow, let me know if the inherited profiles might work for you ... if > not, we can think about whether per-system overrides of everything in > the profile object > is a good idea or not. I'm willing to remove those restrictions if > enough folks find them valuable, though I still think profiles (and > sub-profiles) are a very meaningful > abstraction. For Web UI uses, we may even leave those overrides under > an "advanced" tab or something of the like, to still encourage creation > of task-specific > profiles. > > Thoughts? > > --Michael > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT Registered in England. Number 384 5616 From fj0588di at aa.jp.fujitsu.com Wed Oct 3 09:16:32 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Wed, 3 Oct 2007 18:16:32 +0900 Subject: [et-mgmt-tools] [PATCH][virt-clone] Check the MAC addressconfliction with ignoring character case. In-Reply-To: <20071002165328.GE10551@redhat.com> References: <200710021844.BBF73858.EG90JK69@aa.jp.fujitsu.com> <20071002165328.GE10551@redhat.com> Message-ID: <200710031816.ACH52683.JGE906K9@aa.jp.fujitsu.com> Hi, Dan Thank you for advice. > Instead of doing this: > > > + mac_index = (str(doc).upper()).find(mac.upper()) > > + if mac_index == -1: > > + continue > > + mac_comp = str(doc)[mac_index:mac_index+17] > > > Can't you simply use the 'lower-case()' function in XPath ? > > eg something like > > count(/domain/devices/interface/mac[lower-case(@address)=lower-case('%s')]) > But, the 'lower-case()' function is not included in XPath 1.0 and is included in XPath 2.0. libxml only implements XPath 1.0. The 'translate()' function may simplify it. Thanks, Shigeki Sakamoto. From berrange at redhat.com Wed Oct 3 13:22:01 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Oct 2007 14:22:01 +0100 Subject: [et-mgmt-tools] [PATCH][virt-clone] Check the MAC addressconfliction with ignoring character case. In-Reply-To: <200710031816.ACH52683.JGE906K9@aa.jp.fujitsu.com> References: <200710021844.BBF73858.EG90JK69@aa.jp.fujitsu.com> <20071002165328.GE10551@redhat.com> <200710031816.ACH52683.JGE906K9@aa.jp.fujitsu.com> Message-ID: <20071003132201.GA8342@redhat.com> On Wed, Oct 03, 2007 at 06:16:32PM +0900, S.Sakamoto wrote: > Hi, Dan > Thank you for advice. > > > Instead of doing this: > > > > > + mac_index = (str(doc).upper()).find(mac.upper()) > > > + if mac_index == -1: > > > + continue > > > + mac_comp = str(doc)[mac_index:mac_index+17] > > > > > > Can't you simply use the 'lower-case()' function in XPath ? > > > > eg something like > > > > count(/domain/devices/interface/mac[lower-case(@address)=lower-case('%s')]) > > > But, the 'lower-case()' function is not included in XPath 1.0 and is included in XPath 2.0. > libxml only implements XPath 1.0. > The 'translate()' function may simplify it. Ah, I didn't realize it was new in 2.0. Don't worry about changing it - i'll apply your current patch. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From crobinso at redhat.com Wed Oct 3 14:14:23 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 03 Oct 2007 10:14:23 -0400 Subject: [et-mgmt-tools] [PATCH] reworked virtinst validation testing In-Reply-To: <46FD3503.3020008@redhat.com> References: <46FD3503.3020008@redhat.com> Message-ID: <4703A3BF.5030606@redhat.com> Cole Robinson wrote: > Hi all, > > A couple months back I sent some virtinst validation tests to the list > but the patch was never applied. I reworked it against the current tip > and improved it a bit, and here is the result! > > Thanks, > Cole This is the second spin of this patch: I added some cases for the scenario pointed out by Daniel Berrange where we want to set up a removable media disk with no media attached (path = None). Thanks, Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Wed Oct 3 14:19:33 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 03 Oct 2007 10:19:33 -0400 Subject: [et-mgmt-tools] [PATCH] reworked virtinst validation testing In-Reply-To: <4703A3BF.5030606@redhat.com> References: <46FD3503.3020008@redhat.com> <4703A3BF.5030606@redhat.com> Message-ID: <4703A4F5.3090404@redhat.com> Cole Robinson wrote: > Cole Robinson wrote: >> Hi all, >> >> A couple months back I sent some virtinst validation tests to the list >> but the patch was never applied. I reworked it against the current tip >> and improved it a bit, and here is the result! >> >> Thanks, >> Cole > > This is the second spin of this patch: I added some cases for the > scenario pointed out by Daniel Berrange where we want to set up > a removable media disk with no media attached (path = None). > > Thanks, > Cole > > Blah. I suppose attaching the patch would be helpful :) - Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-validation-testing-02-patch URL: From crobinso at redhat.com Wed Oct 3 14:24:53 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 03 Oct 2007 10:24:53 -0400 Subject: [et-mgmt-tools] [PATCH] reworked virtinst validation fixes In-Reply-To: <20070928193000.GC14112@redhat.com> References: <46FD36EB.2080402@redhat.com> <20070928193000.GC14112@redhat.com> Message-ID: <4703A635.6070706@redhat.com> Daniel P. Berrange wrote: > On Fri, Sep 28, 2007 at 01:16:27PM -0400, Cole Robinson wrote: >> Hi all, >> >> This patch fixes some validation errors in virtinst uncovered by the >> tests I just sent. I sent this a couple months ago but it must have just >> fallen through the cracks, so I reworked it against the current tip. >> This stuff is pretty simple and handy for useful error reporting. > > Looks ok, except for this part: > > - if path != None: > - self.path = os.path.abspath(path) > - else: > - self.path = None > - type = VirtualDisk.TYPE_FILE # Arbitrary choice but avoids the null-path null-type case > - > + self.path = path > + > + if __builtin__.type(self.path) is not __builtin__.type("string"): > + raise ValueError, _("The disk path must be a string.") > + self.path = os.path.abspath(self.path) > + > > And a few places following it which don't cope with fact that self.path > is allowed to be None. Path is allowed to be None for CDROMs so we can > setup a disk whichout any media inserted. I reworked this patch accommodating the case you stated above. In doing so I also worked out a few bugs in the rest of the disk validating code. As a result the patch changes the xml test code to use a path of /etc/test.img instead of /xen/test.img for disk testing, since I added a case to throw an exception if the root directory of the path doesn't exist. > > BTW, can you fix your Thunderbird so it either sends patches as text/plain, > or just inlines them. > > http://lwn.net/Articles/249669/ > > Using text/x-patch as a type makes quoting & replying harder. > > Regards, > Dan. Thanks for the tip. The attachment should be text/plain now. Let me know if there is still an issue. Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-validation-fixes-02-patch URL: From crobinso at redhat.com Wed Oct 3 20:15:23 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 03 Oct 2007 16:15:23 -0400 Subject: [et-mgmt-tools] [PATCH] reworked virtinst validation testing In-Reply-To: <4703A4F5.3090404@redhat.com> References: <46FD3503.3020008@redhat.com> <4703A3BF.5030606@redhat.com> <4703A4F5.3090404@redhat.com> Message-ID: <4703F85B.10208@redhat.com> Cole Robinson wrote: > Cole Robinson wrote: >> Cole Robinson wrote: >>> Hi all, >>> >>> A couple months back I sent some virtinst validation tests to the list >>> but the patch was never applied. I reworked it against the current tip >>> and improved it a bit, and here is the result! >>> >>> Thanks, >>> Cole >> This is the second spin of this patch: I added some cases for the >> scenario pointed out by Daniel Berrange where we want to set up >> a removable media disk with no media attached (path = None). This has been committed. Changeset 282. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=b9456d53dfd8 - Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Wed Oct 3 20:18:36 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 03 Oct 2007 16:18:36 -0400 Subject: [et-mgmt-tools] [PATCH] reworked virtinst validation fixes In-Reply-To: <4703A635.6070706@redhat.com> References: <46FD36EB.2080402@redhat.com> <20070928193000.GC14112@redhat.com> <4703A635.6070706@redhat.com> Message-ID: <4703F91C.60904@redhat.com> Cole Robinson wrote: > > I reworked this patch accommodating the case you stated above. In doing > so I also worked out a few bugs in the rest of the disk validating code. > As a result the patch changes the xml test code to use a path of > /etc/test.img instead of /xen/test.img for disk testing, since I added > a case to throw an exception if the root directory of the > path doesn't exist. This has been committed. Changeset 283. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c0b20d1eaaf2 - Cole -- Cole Robinson crobinso at redhat.com From mdehaan at redhat.com Wed Oct 3 21:45:11 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 03 Oct 2007 17:45:11 -0400 Subject: [et-mgmt-tools] Cobbler query (and now Xen too) In-Reply-To: <470355EE.4090002@ukfast.net> References: <4702729D.9010608@ukfast.net> <470297D4.6060509@redhat.com> <470355EE.4090002@ukfast.net> Message-ID: <47040D67.2050409@redhat.com> Chris Sarginson wrote: > Hi Michael, > > I forgot about the sub profiles being able to override things like > that, so thats a (good) alternate way of doing things, thanks. > > I have a couple of other queries: > > 1) When using the xen kernel to do the installation, I assume that is > not doing hardware virtualisation at all? Currently yes, as I understand it the virtinst library will have PXE support in a release soon (at least in F7/F8?), and at that point we can do fullvirt. Right now, since fullvirt installs require a disk image for provisioning (they can't just be fed a kernel+initrd), we can only do paravirt Xen. However, KVM does allow this currently, so there we are doing hardware. We should have something for Xen soon. > 2) When not using the xen kernel to do the installation (which I can > do if I create the VM manually) I get the following error: > > xend.err "Error creating domain: (2, 'Invalid kernel', > 'xc_dom_find_loader: no loader found > Right... for paravirt Xen you have to use a kernel with "xen" in it. > 3) When using the xen kernel to start the VM I get the following error: > > xend.err "Boot loader didn't return any data! I'm not sure what that is, actually. We'd need the logs from /var/log/xen/xend.log to see for sure. There may also be some relevant logs in ~/.koan > > 4) Are there plans to further expand cobbler to allow you to select > the number of virtual CPU's available? > That's easy to do, and there was a patch for it at some point -- which I believe got lost in the shuffle. I'll add it. RFE filled so I don't forget: https://hosted.fedoraproject.org/projects/cobbler/ticket/27 :) > Chris > > Michael DeHaan wrote: > >> The idea is that a profile should represent what the system does and >> is... the kickstart file, the RAM requirements, the disk >> requirements, and so forth -- to keep all of those things together to >> make a configuration like "virtual-webserver" completely reproducible >> and consistant. In the end, that might even make there be less to >> configure, as you wouldn't need to create the per-system records. An >> example of this is a development or test environment -- that profile >> might be rolled out an arbitrary number of times, and you wouldn't >> neccessarily want to require a cobbler record for every instance of >> that environment. You'd just use koan with "--virt" and >> "--profile=development-environ". Now, in an environment where you >> need DHCP reservations, then yes, you'd want the per-system records. >> How many profiles is insane, by the way? :) One thing that we have >> in Cobbler that is intended to help make this more manageable are the >> concept of inherited profiles. >> >> The idea is that you could do: >> cobbler profile add --name=webserver-base .... --distro=blah >> cobbler profile add --name=webserver-base-moreram --virt-ram=1024 >> --inherit=webserver-base >> >> So, if you want to modify the profile "webserver-base" it would make >> changes to all of the subprofiles for you. That may help. >> >> koan does offer some local overrides, --virt-name, --virt-disk, >> --virt-bridge ... though we try to keep those minimal since it's >> supposed to be a central management way >> of doing things. Those are there for those folks who want to take >> advantage of a cobbler server outside of their normal working >> environment -- for instance, a standalone >> box outside of a datacenter needs to install a cobbler profile, but >> the default image location does not suit the environment, etc. >> >> Anyhow, let me know if the inherited profiles might work for you ... >> if not, we can think about whether per-system overrides of everything >> in the profile object >> is a good idea or not. I'm willing to remove those restrictions if >> enough folks find them valuable, though I still think profiles (and >> sub-profiles) are a very meaningful >> abstraction. For Web UI uses, we may even leave those overrides >> under an "advanced" tab or something of the like, to still encourage >> creation of task-specific >> profiles. >> >> Thoughts? >> >> --Michael >> >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From chris.sarginson at ukfast.net Thu Oct 4 16:19:36 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Thu, 04 Oct 2007 17:19:36 +0100 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] Message-ID: <47051298.8020702@ukfast.net> Michael DeHaan wrote: > > Currently yes, as I understand it the virtinst library will have PXE > support in a release soon (at least in F7/F8?), and at that point we can > do fullvirt. Right now, since fullvirt installs require a disk image > for provisioning (they can't just be fed a kernel+initrd), we can only > do paravirt Xen. However, KVM does allow this currently, so there > we are doing hardware. We should have something for Xen soon. OK, in that case I'll just run paravirtualised machines in the mean time. I'm sure the performance is supposed to be very similar between paravirt + hardware virt - can anyone confirm? >> 2) When not using the xen kernel to do the installation (which I can >> do if I create the VM manually) I get the following error: >> >> xend.err "Error creating domain: (2, 'Invalid kernel', >> 'xc_dom_find_loader: no loader found >> > Right... for paravirt Xen you have to use a kernel with "xen" in it. Yeah, thought so, just making sure that when using Xen it was *only* paravirtualised - hence I tried the non-xen kernel >> 3) When using the xen kernel to start the VM I get the following error: >> >> xend.err "Boot loader didn't return any data! > > I'm not sure what that is, actually. We'd need the logs from > /var/log/xen/xend.log to see for sure. There may also be some > relevant logs in ~/.koan Attached is a snip from my xend.log. The issue is actually caused by the following error initially I suspect: [2007-10-04 17:05:44 2504] DEBUG (XendDomain:960) Creating new managed domain: vps3 [2007-10-04 17:05:48 2504] WARNING (XendDomainInfo:1114) Domain has crashed: name=vps3 id=19. [2007-10-04 17:05:48 2504] DEBUG (XendDomainInfo:1709) XendDomainInfo.destroy: domid=19 I then get the original error i mentioned when i try to start the domain manually. > >> >> 4) Are there plans to further expand cobbler to allow you to select >> the number of virtual CPU's available? >> > That's easy to do, and there was a patch for it at some point -- which I > believe got lost in the shuffle. I'll add it. > > RFE filled so I don't forget: > https://hosted.fedoraproject.org/projects/cobbler/ticket/27 :) Excellent, thanks for that :) Will this be rolled out to the Fedora 7 repos, or is it probably going to be more of an 8 thing? Are you actually on holiday and working btw Michael? If so, even more thanks are in order. Chris -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT Registered in England. Number 384 5616 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xen-debug-snippet.txt URL: From tobert at gmail.com Thu Oct 4 17:34:12 2007 From: tobert at gmail.com (Al Tobey) Date: Thu, 4 Oct 2007 10:34:12 -0700 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <47051298.8020702@ukfast.net> References: <47051298.8020702@ukfast.net> Message-ID: <5ac7acb10710041034h7a0fd9f9y45ca7bb4a3617191@mail.gmail.com> On 10/4/07, Chris Sarginson wrote: > Michael DeHaan wrote: > > > > Currently yes, as I understand it the virtinst library will have PXE > > support in a release soon (at least in F7/F8?), and at that point we can > > do fullvirt. Right now, since fullvirt installs require a disk image > > for provisioning (they can't just be fed a kernel+initrd), we can only > > do paravirt Xen. However, KVM does allow this currently, so there > > we are doing hardware. We should have something for Xen soon. > > OK, in that case I'll just run paravirtualised machines in the mean > time. I'm sure the performance is supposed to be very similar between > paravirt + hardware virt - can anyone confirm? Paravirtualization should be higher performance than full virtualization. Hardware virtualization is faster than software CPU emulation, which is probably what you're thinking of. -Al Tobey > >> 2) When not using the xen kernel to do the installation (which I can > >> do if I create the VM manually) I get the following error: > >> > >> xend.err "Error creating domain: (2, 'Invalid kernel', > >> 'xc_dom_find_loader: no loader found > >> > > Right... for paravirt Xen you have to use a kernel with "xen" in it. > > Yeah, thought so, just making sure that when using Xen it was *only* > paravirtualised - hence I tried the non-xen kernel > > >> 3) When using the xen kernel to start the VM I get the following error: > >> > >> xend.err "Boot loader didn't return any data! > > > > I'm not sure what that is, actually. We'd need the logs from > > /var/log/xen/xend.log to see for sure. There may also be some > > relevant logs in ~/.koan > > Attached is a snip from my xend.log. The issue is actually caused by > the following error initially I suspect: > > [2007-10-04 17:05:44 2504] DEBUG (XendDomain:960) Creating new managed > domain: vps3 > [2007-10-04 17:05:48 2504] WARNING (XendDomainInfo:1114) Domain has > crashed: name=vps3 id=19. > [2007-10-04 17:05:48 2504] DEBUG (XendDomainInfo:1709) > XendDomainInfo.destroy: domid=19 > > I then get the original error i mentioned when i try to start the domain > manually. > > > > >> > >> 4) Are there plans to further expand cobbler to allow you to select > >> the number of virtual CPU's available? > >> > > That's easy to do, and there was a patch for it at some point -- which I > > believe got lost in the shuffle. I'll add it. > > > > RFE filled so I don't forget: > > https://hosted.fedoraproject.org/projects/cobbler/ticket/27 :) > > Excellent, thanks for that :) Will this be rolled out to the Fedora 7 > repos, or is it probably going to be more of an 8 thing? > > Are you actually on holiday and working btw Michael? If so, even more > thanks are in order. > > Chris > -- > Kind regards > > Chris Sarginson > Technical Support > UKFast.Net Ltd > > (t) 0870 111 8866 > (f) 0870 458 4545 > > "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 > > Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net > > UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT > Registered in England. Number 384 5616 > > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:78) XendDomainInfo.create(['vm', ['name', 'vps3'], ['memory', '512'], ['maxmem', '512'], ['vcpus', '1'], ['uuid', 'a9809dfa-8cca-a33a-396a-a9372292edf7'], ['on_poweroff', 'destroy'], ['on_reboot', 'destroy'], ['on_crash', 'destroy'], ['image', ['linux', ['kernel', '/var/lib/xen/vmlinuz'], ['ramdisk', '/var/lib/xen/initrd.img'], ['args', 'ks=http://81.201.128.127/cblr/kickstarts/fedora7-xen-i386/ks.cfg ksdevice=eth0 lang= netmask=255.255.254.0 ip=81.201.128.62 syslog=81.201.128.127:25150 text kssendmac gateway=81.201.128.3 ']]], ['device', ['vbd', ['dev', 'xvda'], ['uname', 'file:/home/vm/linux/vps3'], ['mode', 'w']]], ['device', ['vif', ['mac', '00:16:3e:71:83:f1'], ['bridge', 'xenbr0']]]]) > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:1463) XendDomainInfo.constructDomain > [2007-10-04 17:05:43 2504] DEBUG (balloon:113) Balloon: 930184 KiB free; need 2048; done. > [2007-10-04 17:05:43 2504] DEBUG (XendDomain:443) Adding Domain: 19 > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:1517) XendDomainInfo.initDomain: 19 256 > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:1549) _initDomain:shadow_memory=0x0, memory_static_max=0x20000000, memory_static_min=0x0. > [2007-10-04 17:05:43 2504] DEBUG (balloon:113) Balloon: 930176 KiB free; need 524288; done. > [2007-10-04 17:05:43 2504] INFO (image:129) buildDomain os=linux dom=19 vcpus=1 > [2007-10-04 17:05:43 2504] DEBUG (image:198) domid = 19 > [2007-10-04 17:05:43 2504] DEBUG (image:199) memsize = 512 > [2007-10-04 17:05:43 2504] DEBUG (image:200) image = /var/lib/xen/vmlinuz > [2007-10-04 17:05:43 2504] DEBUG (image:201) store_evtchn = 1 > [2007-10-04 17:05:43 2504] DEBUG (image:202) console_evtchn = 2 > [2007-10-04 17:05:43 2504] DEBUG (image:203) cmdline = ks=http://81.201.128.127/cblr/kickstarts/fedora7-xen-i386/ks.cfg ksdevice=eth0 lang= netmask=255.255.254.0 ip=81.201.128.62 syslog=81.201.128.127:25150 text kssendmac gateway=81.201.128.3 > [2007-10-04 17:05:43 2504] DEBUG (image:204) ramdisk = /var/lib/xen/initrd.img > [2007-10-04 17:05:43 2504] DEBUG (image:205) vcpus = 1 > [2007-10-04 17:05:43 2504] DEBUG (image:206) features = > [2007-10-04 17:05:43 2504] INFO (XendDomainInfo:1365) createDevice: vbd : {'uuid': 'f71f9055-5d20-1fa7-552a-8794eb98deeb', 'bootable': 1, 'driver': 'paravirtualised', 'dev': 'xvda', 'uname': 'file:/home/vm/linux/vps3', 'mode': 'w'} > [2007-10-04 17:05:43 2504] DEBUG (DevController:115) DevController: writing {'backend-id': '0', 'virtual-device': '51712', 'device-type': 'disk', 'state': '1', 'backend': '/local/domain/0/backend/vbd/19/51712'} to /local/domain/19/device/vbd/51712. > [2007-10-04 17:05:43 2504] DEBUG (DevController:117) DevController: writing {'domain': 'vps3', 'frontend': '/local/domain/19/device/vbd/51712', 'uuid': 'f71f9055-5d20-1fa7-552a-8794eb98deeb', 'dev': 'xvda', 'state': '1', 'params': '/home/vm/linux/vps3', 'mode': 'w', 'online': '1', 'frontend-id': '19', 'type': 'file'} to /local/domain/0/backend/vbd/19/51712. > [2007-10-04 17:05:43 2504] INFO (XendDomainInfo:1365) createDevice: vif : {'bridge': 'xenbr0', 'mac': '00:16:3e:71:83:f1', 'uuid': 'a21d1507-6e8f-5bf8-cae9-35d452b9516b'} > [2007-10-04 17:05:43 2504] DEBUG (DevController:115) DevController: writing {'backend-id': '0', 'mac': '00:16:3e:71:83:f1', 'handle': '0', 'state': '1', 'backend': '/local/domain/0/backend/vif/19/0'} to /local/domain/19/device/vif/0. > [2007-10-04 17:05:43 2504] DEBUG (DevController:117) DevController: writing {'bridge': 'xenbr0', 'domain': 'vps3', 'handle': '0', 'uuid': 'a21d1507-6e8f-5bf8-cae9-35d452b9516b', 'script': '/etc/xen/scripts/vif-bridge', 'state': '1', 'frontend': '/local/domain/19/device/vif/0', 'mac': '00:16:3e:71:83:f1', 'online': '1', 'frontend-id': '19', 'type': 'netfront'} to /local/domain/0/backend/vif/19/0. > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:2022) Storing VM details: {'on_xend_stop': 'ignore', 'shadow_memory': '0', 'uuid': 'a9809dfa-8cca-a33a-396a-a9372292edf7', 'on_reboot': 'destroy', 'start_time': '1191513943.72', 'on_poweroff': 'destroy', 'on_xend_start': 'ignore', 'on_crash': 'destroy', 'xend/restart_count': '0', 'vcpus': '1', 'vcpu_avail': '1', 'image': "(linux (kernel /var/lib/xen/vmlinuz) (ramdisk /var/lib/xen/initrd.img) (args 'ks=http://81.201.128.127/cblr/kickstarts/fedora7-xen-i386/ks.cfg ksdevice=eth0 lang= netmask=255.255.254.0 ip=81.201.128.62 syslog=81.201.128.127:25150 text kssendmac gateway=81.201.128.3 ') (notes (HV_START_LOW 4118806528) (FEATURES 'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel') (VIRT_BASE 3221225472) (GUEST_VERSION 2.6) (PADDR_OFFSET 3221225472) (GUEST_OS linux) (HYPERCALL_PAGE 3238006784) (LOADER generic) (PAE_MODE yes) (ENTRY 3238002688) (XEN_VERSION xen-3.0)))", 'name': 'vps3'} > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:873) Storing domain details: {'console/ring-ref': '266778', 'image/entry': '3238002688', 'console/port': '2', 'store/ring-ref': '266779', 'image/loader': 'generic', 'vm': '/vm/a9809dfa-8cca-a33a-396a-a9372292edf7', 'control/platform-feature-multiprocessor-suspend': '1', 'image/hv-start-low': '4118806528', 'image/guest-os': 'linux', 'image/features/writable-descriptor-tables': '1', 'image/virt-base': '3221225472', 'memory/target': '524288', 'image/guest-version': '2.6', 'image/features/supervisor-mode-kernel': '1', 'image/pae-mode': 'yes', 'console/limit': '1048576', 'image/paddr-offset': '3221225472', 'image/hypercall-page': '3238006784', 'cpu/0/availability': 'online', 'image/features/pae-pgdir-above-4gb': '1', 'image/features/writable-page-tables': '1', 'image/features/auto-translated-physmap': '1', 'name': 'vps3', 'domid': '19', 'image/xen-version': 'xen-3.0', 'store/port': '1'} > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:873) Storing domain details: {'console/ring-ref': '266778', 'image/entry': '3238002688', 'control/platform-feature-multiprocessor-suspend': '1', 'image/loader': 'generic', 'vm': '/vm/a9809dfa-8cca-a33a-396a-a9372292edf7', 'store/ring-ref': '266779', 'image/hv-start-low': '4118806528', 'image/guest-os': 'linux', 'image/features/writable-descriptor-tables': '1', 'image/virt-base': '3221225472', 'memory/target': '524288', 'image/guest-version': '2.6', 'image/features/supervisor-mode-kernel': '1', 'image/pae-mode': 'yes', 'console/limit': '1048576', 'image/paddr-offset': '3221225472', 'image/hypercall-page': '3238006784', 'cpu/0/availability': 'online', 'image/features/pae-pgdir-above-4gb': '1', 'image/features/writable-page-tables': '1', 'image/features/auto-translated-physmap': '1', 'name': 'vps3', 'domid': '19', 'image/xen-version': 'xen-3.0', 'store/port': '1'} > [2007-10-04 17:05:43 2504] DEBUG (XendDomainInfo:957) XendDomainInfo.handleShutdownWatch > [2007-10-04 17:05:43 2504] DEBUG (DevController:148) Waiting for devices vif. > [2007-10-04 17:05:43 2504] DEBUG (DevController:153) Waiting for 0. > [2007-10-04 17:05:43 2504] DEBUG (DevController:556) hotplugStatusCallback /local/domain/0/backend/vif/19/0/hotplug-status. > [2007-10-04 17:05:43 2504] DEBUG (DevController:556) hotplugStatusCallback /local/domain/0/backend/vif/19/0/hotplug-status. > [2007-10-04 17:05:44 2504] DEBUG (DevController:570) hotplugStatusCallback 1. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices usb. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices vbd. > [2007-10-04 17:05:44 2504] DEBUG (DevController:153) Waiting for 51712. > [2007-10-04 17:05:44 2504] DEBUG (DevController:556) hotplugStatusCallback /local/domain/0/backend/vbd/19/51712/hotplug-status. > [2007-10-04 17:05:44 2504] DEBUG (DevController:556) hotplugStatusCallback /local/domain/0/backend/vbd/19/51712/hotplug-status. > [2007-10-04 17:05:44 2504] DEBUG (DevController:570) hotplugStatusCallback 1. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices irq. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices vkbd. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices vfb. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices console. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices pci. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices ioports. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices tap. > [2007-10-04 17:05:44 2504] DEBUG (DevController:148) Waiting for devices vtpm. > [2007-10-04 17:05:44 2504] INFO (XendDomain:1123) Domain vps3 (19) unpaused. > [2007-10-04 17:05:44 2504] DEBUG (XendDomainInfo:233) XendDomainInfo.createDormant({'vcpus_params': {}, 'PV_args': '', 'features': '', 'cpus': [], 'devices': {'f6b7c9c3-19fc-d1af-4444-bf4866575003': ('vbd', {'uuid': 'f6b7c9c3-19fc-d1af-4444-bf4866575003', 'bootable': 1, 'driver': 'paravirtualised', 'dev': 'xvda', 'uname': 'file:/home/vm/linux/vps3', 'mode': 'w'}), 'b7e39596-6a7a-c3ae-a6bf-5af08097a9c5': ('vif', {'bridge': 'xenbr0', 'mac': '00:16:3e:71:83:f1', 'uuid': 'b7e39596-6a7a-c3ae-a6bf-5af08097a9c5'})}, 'vcpu_avail': 1, 'VCPUs_live': 1, 'PV_bootloader': '/usr/bin/pygrub', 'actions_after_crash': 'restart', 'vbd_refs': ['f6b7c9c3-19fc-d1af-4444-bf4866575003'], 'PV_ramdisk': '', 'is_control_domain': False, 'name_label': 'vps3', 'VCPUs_at_startup': 1, 'HVM_boot_params': {}, 'platform': {}, 'cpu_weight': 256, 'console_refs': [], 'cpu_cap': 0, 'on_xend_stop': 'ignore', 'memory_static_min': 0, 'HVM_boot_policy': '', 'VCPUs_max': 1, 'memory_static_max': 536870912, 'actions_after_shutdown': 'destroy', 'on_xend_start': 'ignore', 'memory_dynamic_max': 536870912, 'actions_after_suspend': '', 'is_a_template': False, 'memory_dynamic_min': 536870912, 'uuid': 'a9809dfa-8cca-a33a-396a-a9372292edf7', 'PV_kernel': '', 'shadow_memory': 0, 'PV_bootloader_args': '', 'other_config': {}, 'actions_after_reboot': 'restart', 'vif_refs': ['b7e39596-6a7a-c3ae-a6bf-5af08097a9c5'], 'vtpm_refs': [], 'security': None}) > [2007-10-04 17:05:44 2504] DEBUG (XendDomain:960) Creating new managed domain: vps3 > [2007-10-04 17:05:48 2504] WARNING (XendDomainInfo:1114) Domain has crashed: name=vps3 id=19. > [2007-10-04 17:05:48 2504] DEBUG (XendDomainInfo:1709) XendDomainInfo.destroy: domid=19 > [2007-10-04 17:05:48 2504] DEBUG (XendDomainInfo:873) Storing domain details: {'console/ring-ref': '266778', 'image/entry': '3238002688', 'control/platform-feature-multiprocessor-suspend': '1', 'image/loader': 'generic', 'vm': '/vm/a9809dfa-8cca-a33a-396a-a9372292edf7', 'store/ring-ref': '266779', 'image/hv-start-low': '4118806528', 'image/guest-os': 'linux', 'image/features/writable-descriptor-tables': '1', 'image/virt-base': '3221225472', 'memory/target': '524288', 'image/guest-version': '2.6', 'image/features/supervisor-mode-kernel': '1', 'image/pae-mode': 'yes', 'console/limit': '1048576', 'image/paddr-offset': '3221225472', 'image/hypercall-page': '3238006784', 'cpu/0/availability': 'online', 'image/features/pae-pgdir-above-4gb': '1', 'image/features/writable-page-tables': '1', 'image/features/auto-translated-physmap': '1', 'name': 'vps3', 'domid': '19', 'image/xen-version': 'xen-3.0', 'store/port': '1'} > [2007-10-04 17:05:48 2504] DEBUG (XendDomainInfo:1726) XendDomainInfo.destroyDomain(19) > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From berrange at redhat.com Thu Oct 4 17:38:18 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 4 Oct 2007 18:38:18 +0100 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <47051298.8020702@ukfast.net> References: <47051298.8020702@ukfast.net> Message-ID: <20071004173818.GI22533@redhat.com> On Thu, Oct 04, 2007 at 05:19:36PM +0100, Chris Sarginson wrote: > Michael DeHaan wrote: > > > >Currently yes, as I understand it the virtinst library will have PXE > >support in a release soon (at least in F7/F8?), and at that point we can > >do fullvirt. The virtinst library in F8 currently has PXE support. Once F8 has been released & we've had more QA on these new packages I'll update F7 to same codebase. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From chris.sarginson at ukfast.net Thu Oct 4 17:41:11 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Thu, 04 Oct 2007 18:41:11 +0100 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <5ac7acb10710041034h7a0fd9f9y45ca7bb4a3617191@mail.gmail.com> References: <47051298.8020702@ukfast.net> <5ac7acb10710041034h7a0fd9f9y45ca7bb4a3617191@mail.gmail.com> Message-ID: <470525B7.2080306@ukfast.net> Al Tobey wrote: > On 10/4/07, Chris Sarginson wrote: >> Michael DeHaan wrote: >>> Currently yes, as I understand it the virtinst library will have PXE >>> support in a release soon (at least in F7/F8?), and at that point we can >>> do fullvirt. Right now, since fullvirt installs require a disk image >>> for provisioning (they can't just be fed a kernel+initrd), we can only >>> do paravirt Xen. However, KVM does allow this currently, so there >>> we are doing hardware. We should have something for Xen soon. >> OK, in that case I'll just run paravirtualised machines in the mean >> time. I'm sure the performance is supposed to be very similar between >> paravirt + hardware virt - can anyone confirm? > > Paravirtualization should be higher performance than full > virtualization. Hardware virtualization is faster than software CPU > emulation, which is probably what you're thinking of. > > -Al Tobey > Thanks Al Chris -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT Registered in England. Number 384 5616 From clalance at redhat.com Thu Oct 4 17:53:49 2007 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 04 Oct 2007 13:53:49 -0400 Subject: [et-mgmt-tools] [PATCH]: Print a better error message if the disk path doesn't exist Message-ID: <470528AD.3040003@redhat.com> All, Currently with virt-install, if you specify a path for the disk image, and the subdirectories don't exist, like so: virt-install -n chris -r 512 -f /var/lib/xen/images/foo/x.img -s 1 --nonsparse --nographics -p -l nfs:server:/path/to/tree (where /var/lib/xen/images/foo subdir doesn't exist), you get a traceback like so: Starting install... Creating storage file... 100% |=========================| 1.0 GB 00:00 Traceback (most recent call last): File "/usr/sbin/virt-install", line 633, in ? main() File "/usr/sbin/virt-install", line 578, in main dom = guest.start_install(conscb,progresscb) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 649, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 662, in _do_install self._create_devices(meter) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 557, in _create_devices disk.setup(progresscb) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 104, in setup fd = os.open(self.path, os.O_WRONLY | os.O_CREAT) OSError: [Errno 2] No such file or directory: '/var/lib/xen/images/foo/x.img' The attached patch fixes this by adding a try..except inside of the try..finally block to catch the exception and throw a RuntimeError instead. Note that I went the route of nested try..except inside of try..finally to be compatible with python 2.4. Also note that the patch as posted is against the RHEL-5.1 version of virt-install, but should apply pretty easily to upstream virt-install. Comments? Thanks, Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: python-virtinst-file-image-traceback.patch Type: text/x-patch Size: 1672 bytes Desc: not available URL: From crobinso at redhat.com Thu Oct 4 18:26:34 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 04 Oct 2007 14:26:34 -0400 Subject: [et-mgmt-tools] [PATCH]: Print a better error message if the disk path doesn't exist In-Reply-To: <470528AD.3040003@redhat.com> References: <470528AD.3040003@redhat.com> Message-ID: <4705305A.9000505@redhat.com> Chris Lalancette wrote: > All, > Currently with virt-install, if you specify a path for the disk image, and > the subdirectories don't exist, like so: > > virt-install -n chris -r 512 -f /var/lib/xen/images/foo/x.img -s 1 --nonsparse > --nographics -p -l nfs:server:/path/to/tree > > (where /var/lib/xen/images/foo subdir doesn't exist), you get a traceback like so: > > Starting install... > Creating storage file... 100% |=========================| 1.0 GB 00:00 > Traceback (most recent call last): > File "/usr/sbin/virt-install", line 633, in ? > main() > File "/usr/sbin/virt-install", line 578, in main > dom = guest.start_install(conscb,progresscb) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 649, in > start_install > return self._do_install(consolecb, meter) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 662, in > _do_install > self._create_devices(meter) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 557, in > _create_devices > disk.setup(progresscb) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 104, in setup > fd = os.open(self.path, os.O_WRONLY | os.O_CREAT) > OSError: [Errno 2] No such file or directory: '/var/lib/xen/images/foo/x.img' > > The attached patch fixes this by adding a try..except inside of the try..finally > block to catch the exception and throw a RuntimeError instead. Note that I went > the route of nested try..except inside of try..finally to be compatible with > python 2.4. Also note that the patch as posted is against the RHEL-5.1 version > of virt-install, but should apply pretty easily to upstream virt-install. > > Comments? > > Thanks, > Chris Lalancette > Hi Chris, Actually just yesterday I committed some validation cases to virtinst which catch this problem, though in a different location. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c0b20d1eaaf2 It catches it prior to the setup() portion of the code: when the disk path is passed to the VirtualDisk constructor, it now checks to ensure the directory exists, and if not throws a ValueError. This way virt-install can catch this and recover, then prompt the user for a corrected path. Not sure if the relevant portion of that patch fits your needs though. - Cole -- Cole Robinson crobinso at redhat.com From clalance at redhat.com Thu Oct 4 18:48:16 2007 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 04 Oct 2007 14:48:16 -0400 Subject: [et-mgmt-tools] [PATCH]: Print a better error message if the disk path doesn't exist In-Reply-To: <4705305A.9000505@redhat.com> References: <470528AD.3040003@redhat.com> <4705305A.9000505@redhat.com> Message-ID: <47053570.8090702@redhat.com> Cole Robinson wrote: > Hi Chris, > > Actually just yesterday I committed some validation cases to virtinst which > catch this problem, though in a different location. > > http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c0b20d1eaaf2 > > It catches it prior to the setup() portion of the code: when > the disk path is passed to the VirtualDisk constructor, it now checks > to ensure the directory exists, and if not throws a ValueError. This > way virt-install can catch this and recover, then prompt the user for > a corrected path. > > Not sure if the relevant portion of that patch fits your needs > though. > Ah, it mostly does. Actually, I think my patch complements your patch. The problem is that it could be the case that *after* your check, but before the os.open(), the directory could be deleted, so you would still run into the traceback. Unlikely, I know, but still possible, so I think my patch is still worthwhile. Thanks, Chris Lalancette From mdehaan at redhat.com Thu Oct 4 23:19:46 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 04 Oct 2007 19:19:46 -0400 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <20071004173818.GI22533@redhat.com> References: <47051298.8020702@ukfast.net> <20071004173818.GI22533@redhat.com> Message-ID: <47057512.2080904@redhat.com> Daniel P. Berrange wrote: > On Thu, Oct 04, 2007 at 05:19:36PM +0100, Chris Sarginson wrote: > >> Michael DeHaan wrote: >> >>> Currently yes, as I understand it the virtinst library will have PXE >>> support in a release soon (at least in F7/F8?), and at that point we can >>> do fullvirt. >>> > > The virtinst library in F8 currently has PXE support. Once F8 has been > released & we've had more QA on these new packages I'll update F7 > to same codebase. > Nice! I'll put this on my list of things to try out. > Dan. > From mdehaan at redhat.com Thu Oct 4 23:21:42 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 04 Oct 2007 19:21:42 -0400 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <47051298.8020702@ukfast.net> References: <47051298.8020702@ukfast.net> Message-ID: <47057586.6050104@redhat.com> > > Excellent, thanks for that :) Will this be rolled out to the Fedora 7 > repos, or is it probably going to be more of an 8 thing? > I'll push it everywhere. Should be in git sometime next week. > Are you actually on holiday and working btw Michael? If so, even more > thanks are in order. No thanks needed. Computers are just up there with eating, sleeping and breathing and all that :) > > Chris > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From chris.sarginson at ukfast.net Fri Oct 5 10:07:53 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Fri, 05 Oct 2007 11:07:53 +0100 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <47057586.6050104@redhat.com> References: <47051298.8020702@ukfast.net> <47057586.6050104@redhat.com> Message-ID: <47060CF9.9060507@ukfast.net> Michael DeHaan wrote: > > I'll push it everywhere. Should be in git sometime next week. > Thanking you again - would it be possible to get a virt-mac option for Koan? I could do with being able to tell the Virtual Server what its mac is as part of some automation I have built for our stuff. >> Are you actually on holiday and working btw Michael? If so, even more >> thanks are in order. > > No thanks needed. Computers are just up there with eating, sleeping and > breathing and all that :) > So true :) Chris -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT Registered in England. Number 384 5616 From kunkichi at gmail.com Fri Oct 5 13:16:23 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Fri, 5 Oct 2007 22:16:23 +0900 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? Message-ID: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> Hi, I found repository settings when importing distribution might have some troubles. After importing distribution using "cobbler import", config.repo file is generated, but it seems python-cheetah templating doesn't work for "@@server@@" in config.repo file. # cat /var/www/cobbler/ks_mirror/config/centos5-i386-0.repo ----- [core-0] name=core-0 baseurl=http://@@server@@/cobbler/ks_mirror/centos5 enabled=1 gpgcheck=0 ----- # cobbler report ----- distro : centos5-i386 kernel : /var/www/cobbler/ks_mirror/centos5/images/pxeboot/vmlinuz initrd : /var/www/cobbler/ks_mirror/centos5/images/pxeboot/initrd.img kernel options : {} architecture : x86 ks metadata : {'tree': 'http://@@server@@/cblr/links/centos5-i386'} breed : redhat ----- I checked source files and gitweb and found that "@@something@@" is not a bug, but for enabling templating feature for python-cheetah, right? Then, I guess python-cheetah doesn't work well... I tried 2 cases: 1. installing python-cheetah-2.0-0.1.rc8 from RPMforge. 2. get python-cheetah-2.0-0.6.rc SRPM from mirror.linux.duke.edu and built. In both cases, this happened. Q: Is there any requirements for the version of python-cheetah? Also, I tried to fix this using "cobbler distro edit" (because it looked like generating config.repo might be using --ksmeta value.) I replaced "@@server@@" with cobbler server's IP. # cobbler distro edit --name="centos5-i386" --ksmeta="tree=http://192.168.0.254/cblr/links/centos5-i386" # cobbler sync The result of "cobbler report", it seemed to be fixed, but config.repos was not changed and still "@@server@@'" in config.repo and /var/lib/cobbler/distro, both. That means config.repo is generated only when distribution is imported, and will never re-generated by "cobbler sync" based on cobbler's current settings. Therefore, I manually fixed all the files which have "@@server@@" in those, then everything works well. Kuniaki Shimizu kunkichi at gmail.com ----- OS: CentOS5 (for both cobbler server and imported distribution) Cobbler 0.6.2-2 (built from SRPM) From kunkichi at gmail.com Fri Oct 5 13:45:49 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Fri, 5 Oct 2007 22:45:49 +0900 Subject: [et-mgmt-tools] Default "Base" repo file name for CentOS in kickstart is wrong. Message-ID: <4dd11c330710050645h5e40be16w11a4341d276f3951@mail.gmail.com> Hi, again. One more tiny thing, Only for using CentOS. changing yum_core_mirror_from_server to 1 in /var/lib/cobbler/settings, %post section in kickstart file is like this: ----- %post wget http://192.168.0.254/cobbler/ks_mirror/config/centos5-i386-0.repo --output-document=/etc/yum.repos.d/centos5-i386-0.repo ...snip... test -e /etc/yum.repos.d/Centos-Base.repo && mv /etc/yum.repos.d/Centos-Base.repo /etc/yum.repos.d/disabled-Centos-Base ---- CentOS's default "Base" repo file name is "/etc/yum.repos.d/CentOS-Base.repo", not "Centos". # diff action_sync.py action_sync.py.NEW 436c436 < for x in ["fedora-core", "Centos-Base"] : --- > for x in ["fedora-core", "CentOS-Base"] : works for CentOS5 and maybe CentOS4. really tiny one :) Kuniaki Shimizu From rigg0022 at umn.edu Fri Oct 5 16:32:56 2007 From: rigg0022 at umn.edu (Riggs, Ben) Date: Fri, 05 Oct 2007 11:32:56 -0500 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> Message-ID: <47066738.1070704@umn.edu> Double check that the "server: 'you.host.name.here'" line in /var/lib/cobbler/settings is correct. Older rpms (and any make installs) re-write the file back to default. This bit me once as well. Ben Shimizu Kuniaki wrote: > Hi, > > I found repository settings when importing distribution might have > some troubles. > > After importing distribution using "cobbler import", config.repo file > is generated, but it seems python-cheetah templating doesn't work for > "@@server@@" in config.repo file. > > # cat /var/www/cobbler/ks_mirror/config/centos5-i386-0.repo > ----- > [core-0] > name=core-0 > baseurl=http://@@server@@/cobbler/ks_mirror/centos5 > enabled=1 > gpgcheck=0 > ----- > > # cobbler report > ----- > distro : centos5-i386 > kernel : /var/www/cobbler/ks_mirror/centos5/images/pxeboot/vmlinuz > initrd : /var/www/cobbler/ks_mirror/centos5/images/pxeboot/initrd.img > kernel options : {} > architecture : x86 > ks metadata : {'tree': 'http://@@server@@/cblr/links/centos5-i386'} > breed : redhat > ----- > > I checked source files and gitweb and found that "@@something@@" is > not a bug, but for enabling templating feature for python-cheetah, > right? > > Then, I guess python-cheetah doesn't work well... > > I tried 2 cases: > 1. installing python-cheetah-2.0-0.1.rc8 from RPMforge. > 2. get python-cheetah-2.0-0.6.rc SRPM from mirror.linux.duke.edu and built. > In both cases, this happened. > > Q: Is there any requirements for the version of python-cheetah? > > Also, I tried to fix this using "cobbler distro edit" (because it > looked like generating config.repo might be using --ksmeta value.) I > replaced "@@server@@" with cobbler server's IP. > > # cobbler distro edit --name="centos5-i386" > --ksmeta="tree=http://192.168.0.254/cblr/links/centos5-i386" > # cobbler sync > > The result of "cobbler report", it seemed to be fixed, but > config.repos was not changed and still "@@server@@'" in config.repo > and /var/lib/cobbler/distro, both. That means config.repo is generated > only when distribution is imported, and will never re-generated by > "cobbler sync" based on cobbler's current settings. > > Therefore, I manually fixed all the files which have "@@server@@" in > those, then everything works well. > > Kuniaki Shimizu > kunkichi at gmail.com > ----- > OS: CentOS5 (for both cobbler server and imported distribution) > Cobbler 0.6.2-2 (built from SRPM) > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From kunkichi at gmail.com Fri Oct 5 17:58:30 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Sat, 6 Oct 2007 02:58:30 +0900 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <47066738.1070704@umn.edu> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> <47066738.1070704@umn.edu> Message-ID: <4dd11c330710051058h798185a2x746c0c54573c6a4d@mail.gmail.com> Hi, Ben. Thanks for reply. 2007/10/6, Riggs, Ben : > Double check that the "server: 'you.host.name.here'" line in > /var/lib/cobbler/settings is correct. Older rpms (and any make installs) > re-write the file back to default. This bit me once as well. I guess you suggetion is based on that I said "2 cases", right? Actually, I tried to set up cobbler server from bare-metal, each time. Therefore, /var/lib/cobbler/settings have never been re-written by upgrade/downgrade RPM. Currently, my settings are like these: ----- next_server: '192.168.0.254' server: '192.168.0.254' ----- I specified cobbler server's IP' to server' and 'next_server'. If this is incorrect, PXE would not succeed, but it did succeeded... That's why I suspect python-cheetah doesn't work for my environment. Anyway, Thanks. From pnixon at gmail.com Fri Oct 5 21:40:56 2007 From: pnixon at gmail.com (Patrick Nixon) Date: Fri, 5 Oct 2007 17:40:56 -0400 Subject: [et-mgmt-tools] Cheetah and python(abi) Message-ID: I know I got around this last time I installed cobbler, but does anyone recall the solution to: [root at bos3cobbler2 git]# rpm -f -ivh python23-cheetah-0.9.18-1.el4.pyv.i386.rpm warning: python23-cheetah-0.9.18-1.el4.pyv.i386.rpm: Header V3 DSA signature: NOKEY, key ID 4ad653e1 error: Failed dependencies: python(abi) = 2.3 is needed by python23-cheetah-0.9.18-1.el4.pyv.i386 python-cheetah = 0.9.18 is needed by python23-cheetah-0.9.18-1.el4.pyv.i386 It's a Centos5.0 box --Pat From wright at imageworks.com Fri Oct 5 21:59:17 2007 From: wright at imageworks.com (Peter Wright) Date: Fri, 05 Oct 2007 14:59:17 -0700 Subject: [et-mgmt-tools] Cheetah and python(abi) In-Reply-To: References: Message-ID: <4706B3B5.60807@imageworks.com> Patrick Nixon wrote: > > I know I got around this last time I installed cobbler, but does > anyone recall the solution to: > > [root at bos3cobbler2 git]# rpm -f -ivh > python23-cheetah-0.9.18-1.el4.pyv.i386.rpm warning: > python23-cheetah-0.9.18-1.el4.pyv.i386.rpm: Header V3 DSA signature: > NOKEY, key ID 4ad653e1 > error: Failed dependencies: > python(abi) = 2.3 is needed by > python23-cheetah-0.9.18-1.el4.pyv.i386 > python-cheetah = 0.9.18 is needed by > python23-cheetah-0.9.18-1.el4.pyv.i386 > > > It's a Centos5.0 box > looks like you are attempting to install a RHEL4 rpm on an RHEL5 box. that's most likely the issue, the RHEL5 rpms should be available in the testing repo. -pete -- Peter Wright Systems Engineer Sony Pictures Imageworks wright at imageworks.com www.imageworks.com From lfarkas at bppiac.hu Sat Oct 6 12:38:51 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sat, 06 Oct 2007 14:38:51 +0200 Subject: [et-mgmt-tools] virt-manager bugs Message-ID: <470781DB.9090109@bppiac.hu> hi, i'm just recompile virt-manager-0.5.1 on centos-5 and there are a few issues: the latest kvm use /usr/share/qemu in stead of /usr/share/kvm, but virt-manager search for keyboard in /usr/share/kvm so can't start guests. it'd useful to add both place for search path. another problem if i right click on the guests list and try to run it from there it doesn't gives any error or warning just simple don't start it, but if i open it (double-click) and push the run in that window i've got the error message of the above. so it can find the reason of the problem. it'd be useful to get the same error window in the previous case too. -- Levente "Si vis pacem para bellum!" From lfarkas at bppiac.hu Sat Oct 6 12:50:07 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sat, 06 Oct 2007 14:50:07 +0200 Subject: [et-mgmt-tools] virt-manager feature request Message-ID: <4707847F.8000207@bppiac.hu> hi, there are different hypervisor supported by virt-manager and it's not possible to add all features of all hypervisor to the gui, what's more even for common features missing from the gui. meanwhile these wil be implemented it'd be useful to be able to use these feature even for those who use virt-manager. so imho it'd be useful if i can define additional parameters to the command line argument which is composed by virt-manager or libvirt. eg: with kvm as all newer version then kvm-36 has many bugs the developer always ask what happendes with -no-kvm-irqchip? but currently i can't run guests from virt-manager with this settings. so it'd be useful if i can define addition command line argument to qemu-kvm eg. a simple imput line which is appended to the command line would be useful. and all hypervisor can benefit from this feature. thanks. -- Levente "Si vis pacem para bellum!" From berrange at redhat.com Sat Oct 6 19:39:26 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 6 Oct 2007 20:39:26 +0100 Subject: [et-mgmt-tools] virt-manager bugs In-Reply-To: <470781DB.9090109@bppiac.hu> References: <470781DB.9090109@bppiac.hu> Message-ID: <20071006193926.GC17053@redhat.com> On Sat, Oct 06, 2007 at 02:38:51PM +0200, Farkas Levente wrote: > hi, > i'm just recompile virt-manager-0.5.1 on centos-5 and there are a few > issues: > the latest kvm use /usr/share/qemu in stead of /usr/share/kvm, but > virt-manager search for keyboard in /usr/share/kvm so can't start > guests. it'd useful to add both place for search path. I'm not sure what you mean by that. virt-manager doesn't look for any keymaps in either /usr/share/qemu or /usr/share/kvm. The qemu binary itself is responsible for finding its approprate keymaps. > another problem if i right click on the guests list and try to run it > from there it doesn't gives any error or warning just simple don't start > it, but if i open it (double-click) and push the run in that window i've > got the error message of the above. so it can find the reason of the > problem. it'd be useful to get the same error window in the previous > case too. Yep, that's a bug not reporting failures when starting from the popup menu. It should use the same error reporting as the main toolbar buttons. Please file a BZ about it. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Sat Oct 6 19:47:58 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 6 Oct 2007 20:47:58 +0100 Subject: [et-mgmt-tools] virt-manager feature request In-Reply-To: <4707847F.8000207@bppiac.hu> References: <4707847F.8000207@bppiac.hu> Message-ID: <20071006194758.GD17053@redhat.com> On Sat, Oct 06, 2007 at 02:50:07PM +0200, Farkas Levente wrote: > hi, > there are different hypervisor supported by virt-manager and it's not > possible to add all features of all hypervisor to the gui, what's more > even for common features missing from the gui. meanwhile these wil be > implemented it'd be useful to be able to use these feature even for > those who use virt-manager. so imho it'd be useful if i can define > additional parameters to the command line argument which is composed by > virt-manager or libvirt. eg: with kvm as all newer version then kvm-36 > has many bugs the developer always ask what happendes with > -no-kvm-irqchip? but currently i can't run guests from virt-manager with > this settings. so it'd be useful if i can define addition command line > argument to qemu-kvm eg. a simple imput line which is appended to the > command line would be useful. and all hypervisor can benefit from this > feature. The trouble with allowing the defining of arbitrary extra command line parameters is that this can change the behaviour of QEMU which will impact the ability of libvirt to reliably manage the guest process. QEMU is very sensitive to the order of command line args in some cases & adding extra args can have unpredictable effects on the way it runs. Furthermore hacks like -no-kvm-irqchip are not sustainable / supportable long term - the only viable approach is to make KVM itself more reliable. If this means sticking on -36 for a while while bugs with the KVM IRQ handling in newer releases are ironed out so be it. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From lfarkas at bppiac.hu Sun Oct 7 22:39:25 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 08 Oct 2007 00:39:25 +0200 Subject: [et-mgmt-tools] virt-manager feature request In-Reply-To: <20071006194758.GD17053@redhat.com> References: <4707847F.8000207@bppiac.hu> <20071006194758.GD17053@redhat.com> Message-ID: <4709601D.8030702@bppiac.hu> Daniel P. Berrange wrote: > On Sat, Oct 06, 2007 at 02:50:07PM +0200, Farkas Levente wrote: >> hi, >> there are different hypervisor supported by virt-manager and it's not >> possible to add all features of all hypervisor to the gui, what's more >> even for common features missing from the gui. meanwhile these wil be >> implemented it'd be useful to be able to use these feature even for >> those who use virt-manager. so imho it'd be useful if i can define >> additional parameters to the command line argument which is composed by >> virt-manager or libvirt. eg: with kvm as all newer version then kvm-36 >> has many bugs the developer always ask what happendes with >> -no-kvm-irqchip? but currently i can't run guests from virt-manager with >> this settings. so it'd be useful if i can define addition command line >> argument to qemu-kvm eg. a simple imput line which is appended to the >> command line would be useful. and all hypervisor can benefit from this >> feature. > > The trouble with allowing the defining of arbitrary extra command line > parameters is that this can change the behaviour of QEMU which will impact > the ability of libvirt to reliably manage the guest process. QEMU is very > sensitive to the order of command line args in some cases & adding extra > args can have unpredictable effects on the way it runs. Furthermore hacks > like -no-kvm-irqchip are not sustainable / supportable long term - the only > viable approach is to make KVM itself more reliable. If this means sticking > on -36 for a while while bugs with the KVM IRQ handling in newer releases > are ironed out so be it. but in this way we can't help/speed up this process. and there will be always new flags. or you can mark it as advanced options:-) -- Levente "Si vis pacem para bellum!" From mdehaan at redhat.com Mon Oct 8 14:31:40 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 08 Oct 2007 10:31:40 -0400 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <47060CF9.9060507@ukfast.net> References: <47051298.8020702@ukfast.net> <47057586.6050104@redhat.com> <47060CF9.9060507@ukfast.net> Message-ID: <470A3F4C.1000700@redhat.com> Chris Sarginson wrote: > Michael DeHaan wrote: >> >> I'll push it everywhere. Should be in git sometime next week. >> > Thanking you again - would it be possible to get a virt-mac option for > Koan? I could do with being able to tell the Virtual Server what its > mac is as part of some automation I have built for our stuff. I think so. However, the current bug that doesn't honor the mac unless it's also in $name needs to be fixed and will be for the next release. So the following: cobbler system add --name=foo --mac=AA:BB:CC:DD:EE:FF --profile=xyz Is supposed to do that... Do you have a need to be able to do it client side? It's not hard to add, just trying to understand things :) > >>> Are you actually on holiday and working btw Michael? If so, even >>> more thanks are in order. >> >> No thanks needed. Computers are just up there with eating, sleeping >> and breathing and all that :) >> > So true :) > > Chris From mdehaan at redhat.com Mon Oct 8 14:41:00 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 08 Oct 2007 10:41:00 -0400 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> Message-ID: <470A417C.4010302@redhat.com> Shimizu Kuniaki wrote: > Hi, > > I found repository settings when importing distribution might have > some troubles. > > After importing distribution using "cobbler import", config.repo file > is generated, but it seems python-cheetah templating doesn't work for > "@@server@@" in config.repo file. Good catch, thanks! This file doesn't go through the templating engine. It probably should. Here's the patch, which I've also checked in to git: --- a/cobbler/action_reposync.py +++ b/cobbler/action_reposync.py @@ -224,9 +224,12 @@ class RepoSync: config_file.write("[%s]\n" % repo.name) config_file.write("name=%s\n" % repo.name) if output: - config_file.write("baseurl=http://%s/cobbler/repo_mirror/%s\n" % (self.setting + line = "baseurl=http://%s/cobbler/repo_mirror/%s\n" % (self.settings.server, r + config_file.write(line) else: - config_file.write("baseurl=%s\n" % repo.mirror) + line = "baseurl=%s\n" % repo.mirror + line = line.replace("@@server@@",self.settings.server) From mdehaan at redhat.com Mon Oct 8 14:44:08 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 08 Oct 2007 10:44:08 -0400 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <4dd11c330710051058h798185a2x746c0c54573c6a4d@mail.gmail.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> <47066738.1070704@umn.edu> <4dd11c330710051058h798185a2x746c0c54573c6a4d@mail.gmail.com> Message-ID: <470A4238.9010106@redhat.com> Shimizu Kuniaki wrote: > > I specified cobbler server's IP' to server' and 'next_server'. > If this is incorrect, PXE would not succeed, but it did succeeded... > > That's why I suspect python-cheetah doesn't work for my environment. > > It does work :) It's just that the repo config file is generated without going through the templating engine, so a variable was left unsubstituted. My previous email fixes that problem. Hopefully that will work for you now. > Anyway, Thanks. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From chris.sarginson at ukfast.net Mon Oct 8 15:54:54 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Mon, 08 Oct 2007 16:54:54 +0100 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <470A3F4C.1000700@redhat.com> References: <47051298.8020702@ukfast.net> <47057586.6050104@redhat.com> <47060CF9.9060507@ukfast.net> <470A3F4C.1000700@redhat.com> Message-ID: <470A52CE.2030600@ukfast.net> Michael DeHaan wrote: > Chris Sarginson wrote: >> Michael DeHaan wrote: >>> >>> I'll push it everywhere. Should be in git sometime next week. >>> >> Thanking you again - would it be possible to get a virt-mac option for >> Koan? I could do with being able to tell the Virtual Server what its >> mac is as part of some automation I have built for our stuff. > > I think so. However, the current bug that doesn't honor the mac unless > it's also in $name needs to be fixed and will be for the next release. > > So the following: > > cobbler system add --name=foo --mac=AA:BB:CC:DD:EE:FF --profile=xyz > > Is supposed to do that... > > Do you have a need to be able to do it client side? It's not hard to > add, just trying to understand things :) Yeah, basically the the virtual server will boot and do the install, and during the install a custom perl script is run, which based on the servers MAC address pulls details from a database and sets them on the server. Kludgey, but pretty effective :) Are you saying however that I could create a system in cobbler that will tell koan what the MAC address is meant to be and set it appropriately? I would have to look into it, but that may be a viable option, but having the ability to do it through koan is probably the best way tbh :) Chris > > >> >>>> Are you actually on holiday and working btw Michael? If so, even >>>> more thanks are in order. >>> >>> No thanks needed. Computers are just up there with eating, sleeping >>> and breathing and all that :) >>> >> So true :) >> >> Chris > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT Registered in England. Number 384 5616 From mdehaan at redhat.com Mon Oct 8 15:48:54 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 08 Oct 2007 11:48:54 -0400 Subject: [Re: [et-mgmt-tools] Cobbler query (and now Xen too)] In-Reply-To: <470A52CE.2030600@ukfast.net> References: <47051298.8020702@ukfast.net> <47057586.6050104@redhat.com> <47060CF9.9060507@ukfast.net> <470A3F4C.1000700@redhat.com> <470A52CE.2030600@ukfast.net> Message-ID: <470A5166.1020200@redhat.com> Chris Sarginson wrote: > > Michael DeHaan wrote: >> Chris Sarginson wrote: >>> Michael DeHaan wrote: >>>> >>>> I'll push it everywhere. Should be in git sometime next week. >>>> >>> Thanking you again - would it be possible to get a virt-mac option >>> for Koan? I could do with being able to tell the Virtual Server >>> what its mac is as part of some automation I have built for our stuff. >> >> I think so. However, the current bug that doesn't honor the mac >> unless it's also in $name needs to be fixed and will be for the next >> release. >> >> So the following: >> >> cobbler system add --name=foo --mac=AA:BB:CC:DD:EE:FF --profile=xyz >> >> Is supposed to do that... >> >> Do you have a need to be able to do it client side? It's not hard >> to add, just trying to understand things :) > > Yeah, basically the the virtual server will boot and do the install, > and during the install a custom perl script is run, which based on the > servers MAC address pulls details from a database and sets them on the > server. Kludgey, but pretty effective :) > > Are you saying however that I could create a system in cobbler that > will tell koan what the MAC address is meant to be and set it > appropriately? Yes.... Right now you have to set the name to the MAC, though it was intended that --mac=AA:BB:CC:DD:EE:FF would work in koan also. I'm going to fix that :) > I would have to look into it, but that may be a viable option, but > having the ability to do it through koan is probably the best way tbh :) Sure, that's doable. > > Chris > >> >> >>> >>>>> Are you actually on holiday and working btw Michael? If so, even >>>>> more thanks are in order. >>>> >>>> No thanks needed. Computers are just up there with eating, >>>> sleeping and breathing and all that :) >>>> >>> So true :) >>> >>> Chris >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From kunkichi at gmail.com Mon Oct 8 16:15:17 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Tue, 9 Oct 2007 01:15:17 +0900 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <470A417C.4010302@redhat.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> <470A417C.4010302@redhat.com> Message-ID: <4dd11c330710080915t7fe1400gb1a2ade5790b6268@mail.gmail.com> Hi, Michael. Thanks, but it doesn't work... You patched action_reposync.py, which replace those python-cheetah's template valiables in repo files in "/var/www/cobbler/repo_mirror/". Actually, "cobbler" reposync seemes to generate repo files correctly, even without that patch. These repo files are created by "cobbler repo add" and used for other repositories to be updated, such as updates, extras and addons. But repo files I mentioned are in "/var/www/cobbler/ks_mirror/config/", which is created by "cobbler import" and used for "Base" repository. After I sent the last mail, I checked source files and found that action_import.py set "@@server@@" to repo file but no other files replace it with the appropriate values. So, in this case, action_import.py or action_sync.py should be patched, I guess. # "Base" repository is not used for updating package installed, but used for installing # new packages which is not installed before. # So, I think it can be used and should be generated correctly. Sorry for my bad English ;( From kunkichi at gmail.com Mon Oct 8 16:20:59 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Tue, 9 Oct 2007 01:20:59 +0900 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <4dd11c330710080915t7fe1400gb1a2ade5790b6268@mail.gmail.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> <470A417C.4010302@redhat.com> <4dd11c330710080915t7fe1400gb1a2ade5790b6268@mail.gmail.com> Message-ID: <4dd11c330710080920k30d5d96cl19de0cd632a3e85e@mail.gmail.com> One thing I made a mistake. 2007/10/9, Shimizu Kuniaki : > These repo files are created by "cobbler repo add" and used for other I meant "cobbler reposync", not "cobbler repo add". From mdehaan at redhat.com Mon Oct 8 17:26:20 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 08 Oct 2007 13:26:20 -0400 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <4dd11c330710080915t7fe1400gb1a2ade5790b6268@mail.gmail.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> <470A417C.4010302@redhat.com> <4dd11c330710080915t7fe1400gb1a2ade5790b6268@mail.gmail.com> Message-ID: <470A683C.4090900@redhat.com> Shimizu Kuniaki wrote: > These repo files are created by "cobbler repo add" and used for other > repositories to be updated, such as updates, extras and addons. But > repo files I mentioned are in "/var/www/cobbler/ks_mirror/config/", > which is created by "cobbler import" and used for "Base" repository. > Ok, I see. As these are not generated by each sync, the Cheetah engine isn't being run on them. These should probably not have @@server@@ in them. I'll fix this. (For those wondering what this is, these are the repos that get installed on the provisioned machines for EL4/EL5 when the yum_core_mirror_from_server parameter is set). > After I sent the last mail, I checked source files and found that > action_import.py set "@@server@@" to repo file but no other files > replace it with the appropriate values. > > So, in this case, action_import.py or action_sync.py should be patched, I guess. > > # "Base" repository is not used for updating package installed, but > used for installing > # new packages which is not installed before. > # So, I think it can be used and should be generated correctly. > > Sorry for my bad English ;( > No apologies needed. I'm not having any problems with it at all :) > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From mdehaan at redhat.com Mon Oct 8 17:55:19 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 08 Oct 2007 13:55:19 -0400 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <470A683C.4090900@redhat.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> <470A417C.4010302@redhat.com> <4dd11c330710080915t7fe1400gb1a2ade5790b6268@mail.gmail.com> <470A683C.4090900@redhat.com> Message-ID: <470A6F07.5060605@redhat.com> Michael DeHaan wrote: > Shimizu Kuniaki wrote: >> These repo files are created by "cobbler repo add" and used for other >> repositories to be updated, such as updates, extras and addons. But >> repo files I mentioned are in "/var/www/cobbler/ks_mirror/config/", >> which is created by "cobbler import" and used for "Base" repository. >> > Ok, I see. As these are not generated by each sync, the Cheetah > engine isn't being run on them. These should probably not have > @@server@@ in them. I'll fix this. (For those wondering what this > is, these are the repos that get installed on the provisioned machines > for EL4/EL5 when the yum_core_mirror_from_server parameter is set). Fix pushed to git now. I've tested this with an EL5 import and have verified "@@server@@" is not in the repo_mirror/config directory files. If you have yum_core_mirror_from_server enabled *and* are on a laptop that moves around frequently (in terms of the server address), you may have to manually change the aforementioned repo config files when the hostname changes. Otherwise, you'll be fine. (In the future, this is probably something else that will become a Cheetah template -- the trend is to make pretty much all computer generated files templates throughout the program). --Michael From kunkichi at gmail.com Tue Oct 9 08:51:33 2007 From: kunkichi at gmail.com (Shimizu Kuniaki) Date: Tue, 9 Oct 2007 17:51:33 +0900 Subject: [et-mgmt-tools] python-cheetah templating not working for config.repo? In-Reply-To: <470A6F07.5060605@redhat.com> References: <4dd11c330710050616k24a88857j64eb57a9d4190484@mail.gmail.com> <470A417C.4010302@redhat.com> <4dd11c330710080915t7fe1400gb1a2ade5790b6268@mail.gmail.com> <470A683C.4090900@redhat.com> <470A6F07.5060605@redhat.com> Message-ID: <4dd11c330710090151j8df42cbka2322a1e3b7bd60@mail.gmail.com> Thank You, Michael! I've tested it with CentOS4.5, CentOS5, and Fedora 7, and works well. 2007/10/9, Michael DeHaan : > Michael DeHaan wrote: > If you have yum_core_mirror_from_server enabled *and* are on a laptop > that moves around frequently (in terms of the server address), you may > have to manually change the aforementioned repo config files when the > hostname changes. Otherwise, you'll be fine. I will not move cobber server, and importing distribution is a kind of one-time thing, so that's OK. (I think cases like DHCP can be moved on a laptop may be controversial in terms of management and security, though it can be flexible in terms of provisioning.) > (In the future, this is probably something else that will become a > Cheetah template -- the trend is to make pretty much all computer > generated files templates throughout the program). That makes cobbler commands more flexible and enables deploying in various situations :) Thanks. From dpaulo at fedoraproject.org Tue Oct 9 17:53:14 2007 From: dpaulo at fedoraproject.org (Davidson Rodrigues Paulo) Date: Tue, 9 Oct 2007 14:53:14 -0300 Subject: [et-mgmt-tools] [virt-manager] - VNC does not use correct keyboard map In-Reply-To: References: Message-ID: Hi all, I'm using virt-manager to manage Xen and Qemu guests. My keyboard map is Brazilian ABNT2 (br-abnt2 on /etc/sysconfig/keyboard), but it's not being correctly recognized when I connect to a guest using VNC. There is a way to specify which keyboard layout virt-manager/viewer must use on VNC connections do guests? Thanks, Davidson Paulo From andy.grover at oracle.com Tue Oct 9 22:55:53 2007 From: andy.grover at oracle.com (Andy Grover) Date: Tue, 09 Oct 2007 15:55:53 -0700 Subject: [et-mgmt-tools] [PATCH] virt-manager: small exception handling fix Message-ID: <1191970553.2939.16.camel@lute.groveronline.com> Hi, This patch fixes exception handling slightly in virt-manager. Thanks -- Andy diff -r 334e563e54c9 src/virtManager/domain.py --- a/src/virtManager/domain.py Sat Oct 06 16:14:45 2007 -0400 +++ b/src/virtManager/domain.py Tue Oct 09 15:51:16 2007 -0700 @@ -681,7 +681,7 @@ class vmmDomain(gobject.GObject): try: if self.is_active(): self.vm.attachDevice(xml) - except libvirtError, e: + except libvirt.libvirtError, e: device_exception = str(e) index = vmxml.find("") @@ -703,7 +703,7 @@ class vmmDomain(gobject.GObject): if self.is_active(): try: self.vm.detachDevice(dev_xml) - except libvirtError, e: + except libvirt.libvirtError, e: device_exception = str(e) # then the stored XML From mdehaan at redhat.com Tue Oct 9 23:11:45 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 09 Oct 2007 19:11:45 -0400 Subject: [et-mgmt-tools] Pending support for multiple NICs in cobbler/koan (FYI) Message-ID: <470C0AB1.8000403@redhat.com> Ok... so it's about done, but not quite :) So lots of folks have expressed interest in being able to provision hardware with Multiple NICs (for instance you might want to use cobbler to manage DHCP for both of them), as well as create virtual machines that way. For those that are so interested, read on. This is describing how things work upstream now (in git) as I work on polishing this up. I would not recommend trying the codebase at this point, though it should be ready for experimentation soon enough. It's going to work much like before. In the interest of readability, I'm giving command line examples, though this will all work through the Web UI also. All the old commands and the old templates you have will still work. Upgrades will be seamless also. Here's how it works now: cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF [--ip=192.168.1.50] [--hostname=test12345.example.com] [--dhcp-tag=...] [...] If you want more NICs, it's: cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF [--ip=192.168.1.50] [--hostname=test12345.example.com] [--mac1=...] [--ip1=...] [--hostname1=...] [--dhcp-tag=...] Koan looks the same, basically (for both Xen or KVM, depending on your virt type setting in cobbler). Notice these are unchanged: koan --server=cobbler.example.org --virt --profile=profileXYZ koan --server=cobbler.example.org --virt --system=test1234 However, if you need to override the virtual bridge to be used, you can only do so for --profile (not --system) in koan. (Also, for profiles, the restriction is that you'll only get one NIC with a random MAC. You can't get two.). This is so that we don't inflate koan with a lot of options that duplicate things in Cobbler. So, the virtualization provisioning by profile remains as: koan --server=cobbler.example.org --virt --profile=profileXYZ [--virt-bridge=mybridge0] If you wanted to specify a cobbler system that used two seperate bridges, you now have to do that in cobbler. If you don't define them, cobbler will need to try and guess, and most likely you do not want that... Besides, with this much information it will be good to keep it all centrally: cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF [--ip=192.168.1.50] [--hostname=test12345.example.com] [--virt-bridge0=xenbr0] [--mac1=...] [--ip1=...] [--hostname1=...] [--virt-bridge1=xenbr1] I'll make this much more clear on the Wiki as things go on. I don't think it really complicates things in practice as if you don't want multiple NICs for virtual machines, this is all largely optional... and for those that do, the Web UI will make it easy enough to understand. I wanted to bring this up now for those that had an idea how they thought multiple NICs might work from a user perspective to speak up if this really wouldn't work for them. Another topic -- Earlier there was the discussion of having overrides for things like the virtual mac address in koan. Given the complexity of all of the above, and wanting to keep things simple and centrally managed, this is most likely not going to happen as it would overcomplicate the model a bit too much. Again, these are things that are easily enough expressed in cobbler. Right now we can override -virt-name, --virt-path, and --virt-type in koan ... which will likely stay for now, though since they are all settable in cobbler they may become deprecated. - -virt-name can be controlled by creating a system object, --virt-path can be set in profile and/or system objects, and --virt-type can be set globally and in the various objects. For hardcore templating users, variables like $mac_address can be used for the first entry (backwards compatibility), though $mac_address_intf1, and $mac_address_intf2 will also work. Or you'll be able to walk the interfaces as they are exposed to templating as a hash. If anyone is manually generating YAML to create Cobbler files, this does imply a format change, so it would be a good time to switch over to the cobbler API. (I know a few people are mapping Cobbler from LDAP this way...which is not really a version-safe way to go). Hopefully I did not confuse anyone too much by the above. Again, the WUI code is not in git yet, and koan isn't completely tested, but that is my best guess as to how the above will look at this point. More info on the Wiki later. --Michael From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Oct 10 12:21:12 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 10 Oct 2007 14:21:12 +0200 Subject: [et-mgmt-tools] Pending support for multiple NICs in cobbler/koan (FYI) In-Reply-To: <470C0AB1.8000403@redhat.com> References: <470C0AB1.8000403@redhat.com> Message-ID: <20071010142112.3583f860@python3.es.egwn.lan> Michael DeHaan wrote : [...] > I wanted to bring this up now for those that had an idea > how they thought multiple NICs might work from a user perspective to > speak up if this really wouldn't work for them. Sounds all great! I've only got one question. This is exactly what I wanted : cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF [--ip=192.168.1.50] [--hostname=test12345.example.com] [--virt-bridge0=xenbr0] [--mac1=...] [--ip1=...] [--hostname1=...] [--virt-bridge1=xenbr1] But will it be possible to have koan install the system using xenbr1? koan --server=cobbler.example.org --virt --system=test1234 --virt-bridge=xenbr1 Would this get the system and its two NICs from the cobbler server, while telling koan to use xenbr1 to install the system? In my setups, I basically have Xen guests with eth0 as the public interface and eth1 as the private interface, and I'd prefer having cobbler/dhcpd only run on the private LAN. > Another topic -- Earlier there was the discussion of having overrides > for things like the virtual mac address in koan. Given the complexity > of all of the above, and wanting to keep things simple and centrally > managed, this is most likely not going to happen as it would > overcomplicate the model a bit too much. Again, these are things that > are easily > enough expressed in cobbler. I only wanted to override the MAC address in koan because it was randomly generating it instead of getting the one I configured in cobbler (not as the system name). It might be interesting to override the MAC address when using a profile instead of a system, though... Thanks again for all your great work :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.6-81.fc7 Load : 1.25 1.44 1.31 From marcmo at foxriver.com Wed Oct 10 13:50:09 2007 From: marcmo at foxriver.com (Marc Mondragon) Date: Wed, 10 Oct 2007 08:50:09 -0500 Subject: [et-mgmt-tools] Bug in latest version of cobbler from git Message-ID: Found this little one this morning in action_sync.py at line 195: - system_definitions[inteface["dhcp_tag"]] = system_definitions[inteface["dhcp_tag"]] + systxt + system_definitions[interface["dhcp_tag"]] = system_definitions[interface["dhcp_tag"]] + systxt I really need to learn how to submit this the right way .... Marc Mondragon Fox River Financial Resources/Ritchie Capital Investments, Ltd. 2100 Enterprise Avenue Geneva, IL 60134 marcmo at foxriver.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed Oct 10 14:33:53 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 10 Oct 2007 10:33:53 -0400 Subject: [et-mgmt-tools] Bug in latest version of cobbler from git In-Reply-To: References: Message-ID: <470CE2D1.3010906@redhat.com> Marc Mondragon wrote: > > Found this little one this morning in action_sync.py at line 195: > Thanks. I did mention git was a bit "in-progress" at this point (especially for koan), though I appreciate the heads up. > - system_definitions[inteface["dhcp_tag"]] = > system_definitions[inteface["dhcp_tag"]] + systxt > > + system_definitions[interface["dhcp_tag"]] = > system_definitions[interface["dhcp_tag"]] + systxt > > I really need to learn how to submit this the right way ?. > git-send-email and/or git-format-patch > Marc Mondragon > > Fox River Financial Resources/Ritchie Capital Investments, Ltd. > 2100 Enterprise Avenue > Geneva, IL 60134 > marcmo at foxriver.com > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Wed Oct 10 14:37:36 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 10 Oct 2007 10:37:36 -0400 Subject: [et-mgmt-tools] Pending support for multiple NICs in cobbler/koan (FYI) In-Reply-To: <20071010142112.3583f860@python3.es.egwn.lan> References: <470C0AB1.8000403@redhat.com> <20071010142112.3583f860@python3.es.egwn.lan> Message-ID: <470CE3B0.90007@redhat.com> Matthias Saou wrote: > Michael DeHaan wrote : > > [...] > >> I wanted to bring this up now for those that had an idea >> how they thought multiple NICs might work from a user perspective to >> speak up if this really wouldn't work for them. >> > > Sounds all great! I've only got one question. > > This is exactly what I wanted : > > cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF > [--ip=192.168.1.50] [--hostname=test12345.example.com] > [--virt-bridge0=xenbr0] > [--mac1=...] [--ip1=...] > [--hostname1=...] [--virt-bridge1=xenbr1] > > But will it be possible to have koan install the system using xenbr1? > Yes. You'd pass in --virt-bridge0=xenbr1 to cobbler (or for a second interface, --virt-bridge1=xenbr1. > koan --server=cobbler.example.org --virt --system=test1234 > --virt-bridge=xenbr1 > > Would this get the system and its two NICs from the cobbler server, > while telling koan to use xenbr1 to install the system? > For --system, you have to define the virt-bridge values in cobbler now. For --profile, you can specify it on the koan side, but you can only do one NIC that way. > In my setups, I basically have Xen guests with eth0 as the public > interface and eth1 as the private interface, and I'd prefer having > cobbler/dhcpd only run on the private LAN. > > Sure. >> Another topic -- Earlier there was the discussion of having overrides >> for things like the virtual mac address in koan. Given the complexity >> of all of the above, and wanting to keep things simple and centrally >> managed, this is most likely not going to happen as it would >> overcomplicate the model a bit too much. Again, these are things that >> are easily >> enough expressed in cobbler. >> > > I only wanted to override the MAC address in koan because it was > randomly generating it instead of getting the one I configured in > cobbler (not as the system name). > It might be interesting to override the MAC address when using a > profile instead of a system, though... > Hmm... point taken. I'll think about this some. Deprecating --virt-name in particular is probably not a good idea. The main thing was to avoid duplicating a lot of cobbler logic in koan, which I really don't think it will be as complicated as I originally let on :) > Thanks again for all your great work :-) > > You're welcome! Thanks for the feedback. > Matthias > > From hbrock at redhat.com Wed Oct 10 15:32:45 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 10 Oct 2007 11:32:45 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: small exception handling fix In-Reply-To: <1191970553.2939.16.camel@lute.groveronline.com> References: <1191970553.2939.16.camel@lute.groveronline.com> Message-ID: <470CF09D.6070305@redhat.com> Andy Grover wrote: > Hi, > > This patch fixes exception handling slightly in virt-manager. > > Thanks -- Andy > > diff -r 334e563e54c9 src/virtManager/domain.py > --- a/src/virtManager/domain.py Sat Oct 06 16:14:45 2007 -0400 > +++ b/src/virtManager/domain.py Tue Oct 09 15:51:16 2007 -0700 > @@ -681,7 +681,7 @@ class vmmDomain(gobject.GObject): > try: > if self.is_active(): > self.vm.attachDevice(xml) > - except libvirtError, e: > + except libvirt.libvirtError, e: > device_exception = str(e) > > index = vmxml.find("") > @@ -703,7 +703,7 @@ class vmmDomain(gobject.GObject): > if self.is_active(): > try: > self.vm.detachDevice(dev_xml) > - except libvirtError, e: > + except libvirt.libvirtError, e: > device_exception = str(e) > > # then the stored XML > Thanks for this, I'll add it shortly... --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock at redhat.com | virtualization library http://libvirt.org From berrange at redhat.com Wed Oct 10 18:32:29 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Oct 2007 19:32:29 +0100 Subject: [et-mgmt-tools] [virt-manager] - VNC does not use correct keyboard map In-Reply-To: References: Message-ID: <20071010183228.GH12998@redhat.com> On Tue, Oct 09, 2007 at 02:53:14PM -0300, Davidson Rodrigues Paulo wrote: > Hi all, > > I'm using virt-manager to manage Xen and Qemu guests. My keyboard map > is Brazilian ABNT2 (br-abnt2 on /etc/sysconfig/keyboard), but it's not > being correctly recognized when I connect to a guest using VNC. Virt-manager looks at the keyboard setting in /etc/sysconfig/keyboard and maps that to one of the QEMU keymaps for the VNC server. This is an inexact science because QEMU has a fairly limited set of keymaps it supports. For Brazilian it supports 'pt-br' - if that is compatible with br-abnt2 I can make sure we setup a mapping for br-abnt2 -> pt-br > There is a way to specify which keyboard layout virt-manager/viewer > must use on VNC connections do guests? It has to be configured at the time the guest OS is installed. So with virt-manager it is automatically mapped if it is supported by QEMU. With virt-install you have use the --keymap arg to specify one of the QEMU keymaps (see /usr/share/qemu/keymaps) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Wed Oct 10 19:33:14 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Oct 2007 20:33:14 +0100 Subject: [et-mgmt-tools] [virt-manager] - VNC does not use correct keyboard map In-Reply-To: References: <20071010183228.GH12998@redhat.com> Message-ID: <20071010193314.GI12998@redhat.com> On Wed, Oct 10, 2007 at 04:28:42PM -0300, Davidson Rodrigues Paulo wrote: > 2007/10/10, Daniel P. Berrange : > > For Brazilian it supports 'pt-br' - if that is compatible > > with br-abnt2 I can make sure we setup a mapping for br-abnt2 -> pt-br > > Searching on the net I've found that this mapping is stored in a > Python array in /usr/share/virt-manager/virtManager/keytable.py. I've > not found any entry for 'br-abnt2' keymap, so I modified the file, > including the following line: > > "br-abnt2":"pt-br", > > After that I recompiled the Python file and restarted libvirtd, but > this not work... It'll only take effect for guests created in virt-manager after this change. In the logs /root/.virt-manager/virt-manager.log you ought to see the XML description of the guest, with a tag mentioning the keymap > > It has to be configured at the time the guest OS is installed. > > And after, there is a way to change this? virsh dumpxml {NAME|UUID|ID of GUEST} > guest.xml edit the guest.xml tag to set keymap="pt-br" virsh define guest.xml (Add --connect qemu:///system if using QEMU/KVM rather than Xen) Then when you start the guest, it should pick up the new keymap. You can check by looking at the 'qemu' process that gets run. ps -axfuww | grep qemu which should have a -k option with the keymap Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Wed Oct 10 21:23:56 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 10 Oct 2007 17:23:56 -0400 Subject: [et-mgmt-tools] Pending support for multiple NICs in cobbler/koan (FYI) In-Reply-To: <470C0AB1.8000403@redhat.com> References: <470C0AB1.8000403@redhat.com> Message-ID: <470D42EC.6050703@redhat.com> Michael DeHaan wrote: > Ok... so it's about done, but not quite :) Ok, we're ready for some testing. It's simpler to use than I let on earlier. For starters, --virt-bridge is now gone from koan. It's much easier to set this in cobbler anyway. The idea is to keep making koan simpler and simpler. As a side effect of this, koan will no longer try to guess what bridge it should use -- it will use what you tell it, as obtained from Cobbler. You can specify the bridge value in the cobbler settings file, in the profile (overrides the default in settings), or you can define it seperately for any NICs on a cobbler system (overriding the profile). So it basically works like any other parameter. Yes, you can use the same bridge for each NIC if you want. Or any combination thereof. I've tested multi-NIC systems on KVM and Xen alike, as well as profile-based provisioning with a single NIC. mac addresses, ip's, hostnames, and other details can be set on each NIC. As indicated before that's as simple as --mac=AA:BB:CC:DD:EE:FF --mac1=AA:BB:CC:DD:FF:FF. (Same for --ip1, --hostname1, and so on). If you'd like to try this out (testing and comments much appreciated), you'll need to install both Cobbler and Koan from git (the versions should be 0.6.3-1). I would recommend backing up your /var/lib/cobbler/* first -- in the future, the RPM will likely do this for you. Note: I have yet to update the Web UI to support multiple NIC editing -- it should mostly be able to edit the first NIC, but not the others. That's next up on the list (along with finally paying attention to --virt-cpus). Hopefully this works like everyone wants, if not, let me know. Today I also corrected a bug in the WebUI where it wouldn't authenticate under EL4. That's fixed if anyone is interested. Patch here: http://git.fedoraproject.org/?p=hosted/cobbler;a=commitdiff;h=a985d8584b3b6dfd8c58ecb59c8d0d865ae83ab1 Thanks! --Michael From mdehaan at redhat.com Wed Oct 10 22:23:28 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 10 Oct 2007 18:23:28 -0400 Subject: [et-mgmt-tools] Cobbler now has --virt-cpus support Message-ID: <470D50E0.4000505@redhat.com> For those that were wanting it, Cobbler profiles now take an optional --virt-cpus parameter (the default is 1), and koan has been updated to process it. Checked in to git ... --Michael From thestrider at gmail.com Wed Oct 10 23:05:57 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Wed, 10 Oct 2007 19:05:57 -0400 Subject: [et-mgmt-tools] Cobbler now has --virt-cpus support In-Reply-To: <470D50E0.4000505@redhat.com> References: <470D50E0.4000505@redhat.com> Message-ID: <470D5AD5.20804@gmail.com> Awesome! Thanks, Michael. -A. Michael DeHaan wrote: > For those that were wanting it, > > Cobbler profiles now take an optional --virt-cpus parameter (the > default is 1), and koan has been updated to process it. > > Checked in to git ... > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From lfarkas at bppiac.hu Thu Oct 11 08:34:59 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Thu, 11 Oct 2007 10:34:59 +0200 Subject: [et-mgmt-tools] virt-manager crash Message-ID: <470DE033.7090908@bppiac.hu> hi, when try to install a new guest through virt-manager using simple file as a storage i always got this error after create image or even if i try to use a previously created image (after which virt-manager crash): --------------------------------------------------- Unable to complete install 'libvirt.libvirtError virDomainCreateLinux() failed Timed out while reading console startup output Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 616, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 724, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 741, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.4/site-packages/libvirt.py", line 573, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: virDomainCreateLinux() failed Timed out while reading console startup output' --------------------------------------------------- this is with virt-manager-0.5.1-1. is there any solution/fix/workaround for this to be able to use create guest with file storage (ie. not partition)? thanks. -- Levente "Si vis pacem para bellum!" From tim.verhoeven.be at gmail.com Fri Oct 12 08:05:15 2007 From: tim.verhoeven.be at gmail.com (Tim Verhoeven) Date: Fri, 12 Oct 2007 10:05:15 +0200 Subject: [et-mgmt-tools] Cobbler Triggers Message-ID: <2a7fce340710120105w37b080afk6b0211a968865036@mail.gmail.com> Hello, Let me first try to explain what I would like to setup. I'm building a central repo/installation server using Cobbler. We also (already) have a central DHCP and DNS server (ISC dhcpd and bind). The idea is that I let the Cobbler server generate pieces of configfile for these services and then copy the files over to the DHCP and DNS server and use them through includes so that I do not have to touch the main configfiles. For the DHCP part my idea was to let Cobbler to it's thing like it does now (when manage_dhcp is set to 1). But it think there are 2 issues with this setup. First, there is no trigger for the sync action, and that is (as far as I can see) the place where the dhcp.conf file get created/updated by Cobbler. Secondly, when manage_dhcp is set to 1 it will also try to restart dhcpd. In my setup I don't need this since my trigger will do that on the remote side. IMHO there are 2 ways to make this work. First is to add another option that tell Cobbler to create all the necessary configfiles but to not try to start any daemon itself. And then also add a trigger on the sync action (which would be a good idea anyway, I think that can be used for other things too). The second idea is to add "remote" functionality to Cobbler itself. Meaning when the remote option is set Cobbler will scp files over to another system and restart any daemons there using ssh. This last part should be not that invasive using a set of well written functions for this. So what is the prefered option here ? Then for the DNS part. With the triggers for add and delete system it should not be that hard to write something that creates part of a zonefile and copy that over to the DNS server, increments the serial and reloads bind. But I've seen in the code that Cobbler already generates something simular (although simpler) for dnsmasq. What is the feeling to add bind type zonefiles output to Cobbler ? Then the trigger only needs to copy it and reload bind. Anyway, if someone else has working trigger scripts that he or she is willing to share as examplecode, I would appreciate it. Regards, Tim -- Tim Verhoeven - tim.verhoeven.be at gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. (Linus Torvalds) From terry.allen.gotzon at census.gov Fri Oct 12 14:01:26 2007 From: terry.allen.gotzon at census.gov (terry.allen.gotzon at census.gov) Date: Fri, 12 Oct 2007 10:01:26 -0400 Subject: [et-mgmt-tools] Terry Gotzon is out of the office. Message-ID: I will be out of the office starting 10/12/2007 and will not return until 10/23/2007. I will be unable to check my email while on vacation. However, I will respond to your email when I return. In the mean time, please contact Jason Leidner for any issues concerning blade servers. From mdehaan at redhat.com Fri Oct 12 14:29:45 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 12 Oct 2007 10:29:45 -0400 Subject: [et-mgmt-tools] Cobbler Triggers In-Reply-To: <2a7fce340710120105w37b080afk6b0211a968865036@mail.gmail.com> References: <2a7fce340710120105w37b080afk6b0211a968865036@mail.gmail.com> Message-ID: <470F84D9.5070305@redhat.com> Tim Verhoeven wrote: > Hello, > > Let me first try to explain what I would like to setup. I'm building a > central repo/installation server using Cobbler. We also (already) have > a central DHCP and DNS server (ISC dhcpd and bind). The idea is that I > let the Cobbler server generate pieces of configfile for these > services and then copy the files over to the DHCP and DNS server and > use them through includes so that I do not have to touch the main > configfiles. > > For the DHCP part my idea was to let Cobbler to it's thing like it > does now (when manage_dhcp is set to 1). But it think there are 2 > issues with this setup. First, there is no trigger for the sync > action, and that is (as far as I can see) the place where the > dhcp.conf file get created/updated by Cobbler. > Secondly, when manage_dhcp is set to 1 it will also try to restart > dhcpd. In my setup I don't need this since my trigger will do that on > the remote side. > Adding a sync trigger is fairly simple. We could also add a setting for sync_restarts_dhcp. I'm thinking that might be useful anyway because then you could update cobbler all you like but you'd get to choose when to update DHCP. (ISC has live-update capabilities, I've been referred to OMAPI/omshell before, but it seems rather over-complicated for not a lot of gain). > IMHO there are 2 ways to make this work. First is to add another > option that tell Cobbler to create all the necessary configfiles but > to not try to start any daemon itself. And then also add a trigger on > the sync action (which would be a good idea anyway, I think that can > be used for other things too). > Making the dhcp restart a sync-trigger itself seems like a good idea. We could ship it by default, and the trigger could be written to only run when DHCP management was enabled. > The second idea is to add "remote" functionality to Cobbler itself. > Meaning when the remote option is set Cobbler will scp files over to > another system and restart any daemons there using ssh. This last part > should be not that invasive using a set of well written functions for > this. > > So what is the prefered option here ? > Well, if we do the trigger system above, you could modify the "sync" trigger to rsync the bits over, instead of doing the DHCP restart. That seems like a win to me. > Then for the DNS part. With the triggers for add and delete system it > should not be that hard to write something that creates part of a > zonefile and copy that over to the DNS server, increments the serial > and reloads bind. But I've seen in the code that Cobbler already > generates something simular (although simpler) for dnsmasq. What is > the feeling to add bind type zonefiles output to Cobbler ? Then the > trigger only needs to copy it and reload bind. > Seems reasonable. Does anyone want to take a shot at adding it? Ideally the dnsmasq/ISC code should be a bit more modular, though that is something that could be cleaned up later -- or at the same time as adding this. > Anyway, if someone else has working trigger scripts that he or she is > willing to share as examplecode, I would appreciate it. > > Regards, > Tim > > > From jjneely at ncsu.edu Fri Oct 12 19:31:40 2007 From: jjneely at ncsu.edu (Jack Neely) Date: Fri, 12 Oct 2007 15:31:40 -0400 Subject: [et-mgmt-tools] [PATCH] Inherited profiles can put ks=<> in the pxe configuration Message-ID: <20071012193140.GA9627@anduril.unity.ncsu.edu> This fixes the case where I was getting pxe stanzas generated with "ks=<>" Jack Neely --- cobbler/action_sync.py | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py index 5d3cd10..3de38a8 100644 --- a/cobbler/action_sync.py +++ b/cobbler/action_sync.py @@ -715,7 +715,9 @@ class BootSync: # find kernel and initrd kernel_path = os.path.join("/images",distro.name,os.path.basename(distro.kernel)) initrd_path = os.path.join("/images",distro.name,os.path.basename(distro.initrd)) - kickstart_path = profile.kickstart + + # Find the kickstart if we inherit from another profile + kickstart_path = utils.blender(True, profile)["kickstart"] # --- # choose a template -- 1.5.3.1 -- Jack Neely NCSU Campus Linux Services Lead Office of Information Technology, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From mdehaan at redhat.com Fri Oct 12 19:57:22 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 12 Oct 2007 15:57:22 -0400 Subject: [et-mgmt-tools] [PATCH] Inherited profiles can put ks=<> in the pxe configuration In-Reply-To: <20071012193140.GA9627@anduril.unity.ncsu.edu> References: <20071012193140.GA9627@anduril.unity.ncsu.edu> Message-ID: <470FD1A2.5040802@redhat.com> Jack Neely wrote: > This fixes the case where I was getting pxe stanzas generated with > "ks=<>" > > Jack Neely > > --- > cobbler/action_sync.py | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py > index 5d3cd10..3de38a8 100644 > --- a/cobbler/action_sync.py > +++ b/cobbler/action_sync.py > @@ -715,7 +715,9 @@ class BootSync: > # find kernel and initrd > kernel_path = os.path.join("/images",distro.name,os.path.basename(distro.kernel)) > initrd_path = os.path.join("/images",distro.name,os.path.basename(distro.initrd)) > - kickstart_path = profile.kickstart > + > + # Find the kickstart if we inherit from another profile > + kickstart_path = utils.blender(True, profile)["kickstart"] > > # --- > # choose a template > Applied, thanks! --Michael From jjneely at ncsu.edu Fri Oct 12 20:09:55 2007 From: jjneely at ncsu.edu (Jack Neely) Date: Fri, 12 Oct 2007 16:09:55 -0400 Subject: [et-mgmt-tools] Cobbler and non-Linux "distros" Message-ID: <20071012200955.GM8398@anduril.unity.ncsu.edu> Folks, One of my goals at NCSU has been to create a boot service that can handle all Intel-ish machines. I have that running now and am looking at using Cobbler as the glue to pull all the various parts together and to take advantage of koan. What thought has been given to non-Linux distributions? We install windows with linux but cobbler's mandated usage of ks=foo and other things on the append line don't make since here. What about other utilities such as memtest or dban? Perhaps a different breed option to alter the feature set? Jack -- Jack Neely NCSU Campus Linux Services Lead Office of Information Technology, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From hyclak at math.ohiou.edu Fri Oct 12 20:19:27 2007 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Fri, 12 Oct 2007 16:19:27 -0400 Subject: [et-mgmt-tools] Cobbler and non-Linux "distros" In-Reply-To: <20071012200955.GM8398@anduril.unity.ncsu.edu> References: <20071012200955.GM8398@anduril.unity.ncsu.edu> Message-ID: <20071012201927.GF16531@math.ohiou.edu> On Fri, Oct 12, 2007 at 04:09:55PM -0400, Jack Neely enlightened us: > Folks, > > One of my goals at NCSU has been to create a boot service that can > handle all Intel-ish machines. I have that running now and am looking > at using Cobbler as the glue to pull all the various parts together and > to take advantage of koan. > > What thought has been given to non-Linux distributions? We install > windows with linux but cobbler's mandated usage of ks=foo and other > things on the append line don't make since here. What about other > utilities such as memtest or dban? > > Perhaps a different breed option to alter the feature set? > memtest and dban I just put into the pxe template file as individual entries. I have a windows installation system that is kicked off from a linux boot disk that I could pxe boot, but I think the same thing could be done - just an entry in the pxe template. If I could get the machine definitions to live inside cobbler too, that'd be nice, but there's quite a bit of info that I'm not sure would shoehorn very well. Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 From pnixon at gmail.com Fri Oct 12 20:22:06 2007 From: pnixon at gmail.com (Patrick Nixon) Date: Fri, 12 Oct 2007 16:22:06 -0400 Subject: [et-mgmt-tools] Cobbler and non-Linux "distros" In-Reply-To: <20071012201927.GF16531@math.ohiou.edu> References: <20071012200955.GM8398@anduril.unity.ncsu.edu> <20071012201927.GF16531@math.ohiou.edu> Message-ID: Matt, Can you share the information on the windows installation system you mentioned? --Pat > memtest and dban I just put into the pxe template file as individual > entries. I have a windows installation system that is kicked off from a > linux boot disk that I could pxe boot, but I think the same thing could be > done - just an entry in the pxe template. If I could get the machine > definitions to live inside cobbler too, that'd be nice, but there's quite a > bit of info that I'm not sure would shoehorn very well. > > Matt > > -- > Matt Hyclak > Department of Mathematics > Department of Social Work > Ohio University > (740) 593-1263 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From jjneely at ncsu.edu Fri Oct 12 20:41:29 2007 From: jjneely at ncsu.edu (Jack Neely) Date: Fri, 12 Oct 2007 16:41:29 -0400 Subject: [et-mgmt-tools] Cobbler and non-Linux "distros" In-Reply-To: <20071012201927.GF16531@math.ohiou.edu> References: <20071012200955.GM8398@anduril.unity.ncsu.edu> <20071012201927.GF16531@math.ohiou.edu> Message-ID: <20071012204129.GN8398@anduril.unity.ncsu.edu> On Fri, Oct 12, 2007 at 04:19:27PM -0400, Matt Hyclak wrote: > On Fri, Oct 12, 2007 at 04:09:55PM -0400, Jack Neely enlightened us: > > Folks, > > > > One of my goals at NCSU has been to create a boot service that can > > handle all Intel-ish machines. I have that running now and am looking > > at using Cobbler as the glue to pull all the various parts together and > > to take advantage of koan. > > > > What thought has been given to non-Linux distributions? We install > > windows with linux but cobbler's mandated usage of ks=foo and other > > things on the append line don't make since here. What about other > > utilities such as memtest or dban? > > > > Perhaps a different breed option to alter the feature set? > > > > memtest and dban I just put into the pxe template file as individual > entries. I have a windows installation system that is kicked off from a > linux boot disk that I could pxe boot, but I think the same thing could be > done - just an entry in the pxe template. If I could get the machine > definitions to live inside cobbler too, that'd be nice, but there's quite a > bit of info that I'm not sure would shoehorn very well. > > Matt > Yeah...that's the stopgap. However, I'd like to not have to touch an old server, rather just schedule it to reboot and run dban and have the server room folks carry it off to surplus the next day. ;-) Same applies to the windows labs as fitting koan into the little linux image that maintains the windows junk would be easy. Jack -- Jack Neely NCSU Campus Linux Services Lead Office of Information Technology, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From wright at imageworks.com Fri Oct 12 21:21:39 2007 From: wright at imageworks.com (Peter Wright) Date: Fri, 12 Oct 2007 14:21:39 -0700 Subject: [et-mgmt-tools] Cobbler and non-Linux "distros" In-Reply-To: <20071012200955.GM8398@anduril.unity.ncsu.edu> References: <20071012200955.GM8398@anduril.unity.ncsu.edu> Message-ID: <470FE563.10203@imageworks.com> Jack Neely wrote: > Folks, > > One of my goals at NCSU has been to create a boot service that can > handle all Intel-ish machines. I have that running now and am looking > at using Cobbler as the glue to pull all the various parts together and > to take advantage of koan. > > What thought has been given to non-Linux distributions? We install > windows with linux but cobbler's mandated usage of ks=foo and other > things on the append line don't make since here. What about other > utilities such as memtest or dban? > > Perhaps a different breed option to alter the feature set? > > Jack > Can't speak about Windows or MacOS platforms - but I've done a little investigating in using cobbler to assist with booting/building FreeBSD systems and theoretically it should work. Granted I have not looked at what patches would be need to make this happen - but the underlying mechanics are there (you can feed a response file similar to kickstart to Freebsd, pxe booting works very will with freebsd etc.). at this point this is one of the things on my ever growing "would be nice to get done soon" list :) -pete -- Peter Wright Systems Engineer Sony Pictures Imageworks wright at imageworks.com www.imageworks.com From hyclak at math.ohiou.edu Fri Oct 12 21:35:14 2007 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Fri, 12 Oct 2007 17:35:14 -0400 Subject: [et-mgmt-tools] Cobbler and non-Linux "distros" In-Reply-To: References: <20071012200955.GM8398@anduril.unity.ncsu.edu> <20071012201927.GF16531@math.ohiou.edu> Message-ID: <20071012213514.GG16531@math.ohiou.edu> On Fri, Oct 12, 2007 at 04:22:06PM -0400, Patrick Nixon enlightened us: > Matt, > Can you share the information on the windows installation system you mentioned? > http://unattended.sourceforge.net It has it's limitations - i.e. it won't install Vista since they removed the dos version of the installer, but for now it works quite well. Matt > --Pat > > > memtest and dban I just put into the pxe template file as individual > > entries. I have a windows installation system that is kicked off from a > > linux boot disk that I could pxe boot, but I think the same thing could be > > done - just an entry in the pxe template. If I could get the machine > > definitions to live inside cobbler too, that'd be nice, but there's quite a > > bit of info that I'm not sure would shoehorn very well. > > > > Matt > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 From mdehaan at redhat.com Fri Oct 12 21:31:09 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 12 Oct 2007 17:31:09 -0400 Subject: [et-mgmt-tools] Cobbler and non-Linux "distros" In-Reply-To: <470FE563.10203@imageworks.com> References: <20071012200955.GM8398@anduril.unity.ncsu.edu> <470FE563.10203@imageworks.com> Message-ID: <470FE79D.3080106@redhat.com> Peter Wright wrote: > Jack Neely wrote: >> Folks, >> >> One of my goals at NCSU has been to create a boot service that can >> handle all Intel-ish machines. I have that running now and am looking >> at using Cobbler as the glue to pull all the various parts together and >> to take advantage of koan. >> >> What thought has been given to non-Linux distributions? We install >> windows with linux but cobbler's mandated usage of ks=foo and other >> things on the append line don't make since here. What about other >> utilities such as memtest or dban? >> >> Perhaps a different breed option to alter the feature set? >> >> Jack >> > > Can't speak about Windows or MacOS platforms - but I've done a little > investigating in using cobbler to assist with booting/building FreeBSD > systems and theoretically it should work. Granted I have not looked > at what patches would be need to make this happen - but the underlying > mechanics are there (you can feed a response file similar to kickstart > to Freebsd, pxe booting works very will with freebsd etc.). > > at this point this is one of the things on my ever growing "would be > nice to get done soon" list :) > > -pete > I'm extremely interested in those kinds of things (both koan doing DBAN and the other OS support). Given I'm not an expert in deploying non-Linux OS's, I won't be adding these myself (I may be able to test some) ... but if someone wants to add patches for *BSD or even Windows, I'll gladly take them. Mixed environments are a reality, and especially once we have Xen PXE integrated into Cobbler (which is already available in F8), it would be nice to be able to deploy those OS's in hardware virtualization with koan, with just a single command. There's already a parameter in Cobbler to identify a distro as foreign, it's "--breed" and we do some things already to deal with Debian and SuSE kernel parameters. Since kickstarts are treated as generic answer files -- text -- (except by koan, which needs to learn to /not/ read them once again), there's nothing really keying in Cobbler to just kickstart-based deployments. However, it's always going to do those best :) BTW, here's an example of how someone added DBAN as a Cobbler profile for PXE (not just added into the template file), though koan would probably need some tweaking to tolerate it. Might be a useful starting point: https://hosted.fedoraproject.org/projects/cobbler/wiki/SystemRetirement --Michael From mdehaan at redhat.com Fri Oct 12 22:23:54 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 12 Oct 2007 18:23:54 -0400 Subject: [et-mgmt-tools] Cobbler WebUI and Multiple NICs (checked in) Message-ID: <470FF3FA.6070006@redhat.com> Web UI update... So, the Cobbler/koan 0.6.3 as a release is looking like it will address primarily Web UI features (and of course multiple NICs). Future releases will not be so Web-UI centric, so if you aren't seeing your favorite RFE's committed ... they'll be coming soon enough. For those interested in the WebUI, however, I've committed some newness that should be useful and interesting. Namely, multiple NIC editing is now in the Web UI (thanks to M?ir?n Duffy for lots of DHTML help) and should make infinitely more sense than trying to pass dozens of arguments on the command line to configure 4 or 8 different NICs. Each NIC is shown seperately and can be expanded/collapsed as needed. There's also a button to remove an interface if you've added one too many. You can also edit virtual bridge settings for each NIC and get to the virtual CPU setting. A couple of other features I'd like to get into this release are pagination for the "list" pages, which should help for when there are an extremely large number of systems (as in thousands) in the Cobbler DB. Database-backing (or something faster than YAML) as an option will probably come in a later release as all of the above changes are enough for now. As an aside, someone has also asked for "cobbler sync" to get triggers (just like the "add" and "remove" commands -- https://hosted.fedoraproject.org/projects/cobbler/wiki/CobblerTriggers ) and I'm planning on including this in 0.6.3 as well. This means that we'll move service restarts (DHCP, ISC) out into triggers, ship those triggers by default, and make configuration settings for whether or not they should be run. This is the beginning of making the sync code more abstracted and the core a bit lighter weight. Admins can then be able to write their own hooks, such as using the cobbler interface to manage DHCP files which are then rsync'd and applied to a remote system -- seperating cobbler and the DHCP server, or possibly using cobbler to configure multiple DHCP servers (we'll see where this goes). If you're interested in the WebUI, everything has been uploaded to git, and installation instructions haven't changed. Feedback welcome! As I've said before, the Web UI is all generated from Cheetah templates, so if folks are interested in improving it, you shouldn't find it all that different than editing kickstarts :) --Michael From sakaia at jp.fujitsu.com Mon Oct 15 01:18:46 2007 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Mon, 15 Oct 2007 10:18:46 +0900 Subject: [et-mgmt-tools] virt-manager japanese translation at Fedora 8 Message-ID: <200710150119.l9F1JBQf016675@fjmscan502.ms.jp.fujitsu.com> Hi, Dan I have one question about virt-manager on Fedora 8. At this moment, Fedora 8 includes change set 633. http://hg.et.redhat.com/virt/applications/virt-manager--devel Hyugabaru translation(cset 635) is already commited to virt-manager tree. But its translation is not included in Fedora 8. Is his translation planned to include on Fedora 8 Release? Since his work is purposed for Fedora 8. Thanks Atsushi SAKAI From rjones at redhat.com Mon Oct 15 11:16:12 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 15 Oct 2007 12:16:12 +0100 Subject: [et-mgmt-tools] virt-manager crash In-Reply-To: <470DE033.7090908@bppiac.hu> References: <470DE033.7090908@bppiac.hu> Message-ID: <47134BFC.2040303@redhat.com> Farkas Levente wrote: > libvirtError: virDomainCreateLinux() failed Timed out while reading > console startup output' > --------------------------------------------------- > this is with virt-manager-0.5.1-1. > is there any solution/fix/workaround for this to be able to use create > guest with file storage (ie. not partition)? > thanks. The error is from Xen and IIRC in this case it indicates that hotplug isn't working (surprise, surprise). Take a look at /var/log/xen/xend.log, xend-debug.log and see if you see any further messages which might help to diagnose this. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From lfarkas at bppiac.hu Mon Oct 15 11:24:55 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 15 Oct 2007 13:24:55 +0200 Subject: [et-mgmt-tools] virt-manager crash In-Reply-To: <47134BFC.2040303@redhat.com> References: <470DE033.7090908@bppiac.hu> <47134BFC.2040303@redhat.com> Message-ID: <47134E07.7060404@bppiac.hu> Richard W.M. Jones wrote: > Farkas Levente wrote: >> libvirtError: virDomainCreateLinux() failed Timed out while reading >> console startup output' >> --------------------------------------------------- >> this is with virt-manager-0.5.1-1. >> is there any solution/fix/workaround for this to be able to use create >> guest with file storage (ie. not partition)? >> thanks. > > The error is from Xen and IIRC in this case it indicates that hotplug > isn't working (surprise, surprise). > > Take a look at /var/log/xen/xend.log, xend-debug.log and see if you see > any further messages which might help to diagnose this. no this is when we try to install a kvm quest. -- Levente "Si vis pacem para bellum!" From mdehaan at redhat.com Mon Oct 15 13:01:25 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 15 Oct 2007 09:01:25 -0400 Subject: [et-mgmt-tools] fc6 xen install question (was Re: ) In-Reply-To: References: Message-ID: <471364A5.9000504@redhat.com> Eugeniusz Krywult wrote: > hi > I was creating vm machine ( fc6) on rhel5 x86_64 all was ok until > installation required restart after it i lost everything. > Only left file which even i cannot restart. > I think im doing big mistake but where I have no idea? > regards > genek > Eugeniusz Krywult > OBR SM BOSMAL > Ul. Sarni Stok 93 > 43-300 Bielsko-Bia?a Poland > > tel.: 33 8 130 483 > dom : 33 8 103 514 > mob.: 503 400 832 > www.bosmal.com.pl > skype,inspeak: genek-53 > > > > > Mail checked by IMSS TrendMirco. > Is this fc6 paravirt? How did you create the virtual machine? You might want to try posting to fedora-xen at redhat.com as that's a bit more on-topic of a list ... without any error messages from the logs (such as /var/log/xen) it is difficult to say what is going on. With further information there (or from other logs), it may be more obvious. --Michael From jjneely at ncsu.edu Mon Oct 15 15:24:34 2007 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 15 Oct 2007 11:24:34 -0400 Subject: [et-mgmt-tools] [PATCH] Let users keep images in /tftpboot Message-ID: <20071015152434.GA25807@anduril.unity.ncsu.edu> I tend to keep images in the /tftpboot space ordered by support group. This makes cobbler use hard/soft links in that case and does some simple testing for filesystem suckiness. Jack Neely --- cobbler/action_sync.py | 29 +++++++++++++++++++++++++++-- 1 files changed, 27 insertions(+), 2 deletions(-) diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py index 3de38a8..ee707f3 100644 --- a/cobbler/action_sync.py +++ b/cobbler/action_sync.py @@ -302,8 +302,14 @@ class BootSync: raise CX(_("initrd not found: %(file)s, distro: %(distro)s") % { "file" : d.initrd, "distro" : d.name }) b_kernel = os.path.basename(kernel) b_initrd = os.path.basename(initrd) - self.copyfile(kernel, os.path.join(distro_dir, b_kernel)) - self.copyfile(initrd, os.path.join(distro_dir, b_initrd)) + if kernel.startswith(dirtree): + self.linkfile(kernel, os.path.join(distro_dir, b_kernel)) + else: + self.copyfile(kernel, os.path.join(distro_dir, b_kernel)) + if initrd.startswith(dirtree): + self.linkfile(initrd, os.path.join(distro_dir, b_initrd)) + else: + self.copyfile(initrd, os.path.join(distro_dir, b_initrd)) def validate_kickstarts(self): """ @@ -840,6 +846,25 @@ class BootSync: fd.write(yaml.dump(blended)) fd.close() + def linkfile(self, src, dst): + """ + Attempt to create a link dst that points to src. Because file + systems suck we attempt several different methods or bail to + self.copyfile() + """ + + try: + return os.link(src, dst) + except (IOError, OSError): + pass + + try: + return os.symlink(src, dst) + except (IOError, OSError): + pass + + return self.copyfile(src, dst) + def copyfile(self,src,dst): try: return shutil.copyfile(src,dst) -- 1.5.3.1 -- Jack Neely NCSU Campus Linux Services Lead Office of Information Technology, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From andy.grover at oracle.com Mon Oct 15 20:08:14 2007 From: andy.grover at oracle.com (Andy Grover) Date: Mon, 15 Oct 2007 13:08:14 -0700 Subject: [et-mgmt-tools] serial console to windows hvm guest Message-ID: <1192478894.28759.12.camel@lute.groveronline.com> Hi all, If I understand correctly, I need to define serial='pty' in my guest's config file in order for xm (or virsh) console to work. However, I didn't use a config file, I had virt-manager/libvirt do it. What is the XML equivalent of serial='pty'? I tried virsh dumpxml, adding "pty", but it didn't stick after doing virsh define. (I'm trying to hook up a serial debugger to a windows hvm guest, as described here: http://www.evilbitz.com/2006/12/13/howto-debugging-a-remote-windows-hvm-under-xen-using-windbg/ so if there's a better way to do this please let me know.) Thanks -- Regards -- Andy From berrange at redhat.com Mon Oct 15 20:21:17 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 15 Oct 2007 21:21:17 +0100 Subject: [et-mgmt-tools] serial console to windows hvm guest In-Reply-To: <1192478894.28759.12.camel@lute.groveronline.com> References: <1192478894.28759.12.camel@lute.groveronline.com> Message-ID: <20071015202117.GE14352@redhat.com> On Mon, Oct 15, 2007 at 01:08:14PM -0700, Andy Grover wrote: > Hi all, > > If I understand correctly, I need to define serial='pty' in my guest's > config file in order for xm (or virsh) console to work. However, I > didn't use a config file, I had virt-manager/libvirt do it. > > What is the XML equivalent of serial='pty'? I tried virsh dumpxml, > adding "pty", but it didn't stick after doing virsh > define. When the guest is running 'pty' will be replaced by the actuall path that was opened, and you can use 'virsh console' to access it. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Mon Oct 15 20:43:32 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 15 Oct 2007 16:43:32 -0400 Subject: [et-mgmt-tools] [PATCH] Let users keep images in /tftpboot In-Reply-To: <20071015152434.GA25807@anduril.unity.ncsu.edu> References: <20071015152434.GA25807@anduril.unity.ncsu.edu> Message-ID: <4713D0F4.3050801@redhat.com> Jack Neely wrote: > I tend to keep images in the /tftpboot space ordered by support group. > This makes cobbler use hard/soft links in that case and does some simple > testing for filesystem suckiness. > > Jack Neely > > --- > cobbler/action_sync.py | 29 +++++++++++++++++++++++++++-- > 1 files changed, 27 insertions(+), 2 deletions(-) > > diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py > index 3de38a8..ee707f3 100644 > --- a/cobbler/action_sync.py > +++ b/cobbler/action_sync.py > @@ -302,8 +302,14 @@ class BootSync: > raise CX(_("initrd not found: %(file)s, distro: %(distro)s") % { "file" : d.initrd, "distro" : d.name }) > b_kernel = os.path.basename(kernel) > b_initrd = os.path.basename(initrd) > - self.copyfile(kernel, os.path.join(distro_dir, b_kernel)) > - self.copyfile(initrd, os.path.join(distro_dir, b_initrd)) > + if kernel.startswith(dirtree): > + self.linkfile(kernel, os.path.join(distro_dir, b_kernel)) > + else: > + self.copyfile(kernel, os.path.join(distro_dir, b_kernel)) > + if initrd.startswith(dirtree): > + self.linkfile(initrd, os.path.join(distro_dir, b_initrd)) > + else: > + self.copyfile(initrd, os.path.join(distro_dir, b_initrd)) > > def validate_kickstarts(self): > """ > @@ -840,6 +846,25 @@ class BootSync: > fd.write(yaml.dump(blended)) > fd.close() > > + def linkfile(self, src, dst): > + """ > + Attempt to create a link dst that points to src. Because file > + systems suck we attempt several different methods or bail to > + self.copyfile() > + """ > + > + try: > + return os.link(src, dst) > + except (IOError, OSError): > + pass > + > + try: > + return os.symlink(src, dst) > + except (IOError, OSError): > + pass > + > + return self.copyfile(src, dst) > + > def copyfile(self,src,dst): > try: > return shutil.copyfile(src,dst) > Sounds good and applied, thanks! --Michael From andy.grover at oracle.com Mon Oct 15 20:52:09 2007 From: andy.grover at oracle.com (Andy Grover) Date: Mon, 15 Oct 2007 13:52:09 -0700 Subject: [et-mgmt-tools] serial console to windows hvm guest In-Reply-To: <20071015202117.GE14352@redhat.com> References: <1192478894.28759.12.camel@lute.groveronline.com> <20071015202117.GE14352@redhat.com> Message-ID: <1192481529.28759.21.camel@lute.groveronline.com> On Mon, 2007-10-15 at 21:21 +0100, Daniel P. Berrange wrote: > > What is the XML equivalent of serial='pty'? I tried virsh dumpxml, > > adding "pty", but it didn't stick after doing virsh > > define. > > Ah, thanks. I am still not seeing this echoed back as part of virsh dumpxml's output, which may be bad? > When the guest is running 'pty' will be replaced by the actuall path that > was opened, and you can use 'virsh console' to access it. It says, "No console available for domain". Thanks -- Andy From fj0588di at aa.jp.fujitsu.com Tue Oct 16 07:09:06 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Tue, 16 Oct 2007 16:09:06 +0900 Subject: [et-mgmt-tools] [PATCH] bugzillaID:329091 In-Reply-To: <200710161541.BGJ65120.E06J9K9G@aa.jp.fujitsu.com> References: <200710161450.AGF26966.KJ99EG60@aa.jp.fujitsu.com> <200710160618.l9G6I6Xl010227@fjmscan503.ms.jp.fujitsu.com> <200710161541.BGJ65120.E06J9K9G@aa.jp.fujitsu.com> Message-ID: <200710161609.CAE43776.6EJ0G99K@aa.jp.fujitsu.com> Hi I make a patch of BugzillaID-329091. https://bugzilla.redhat.com/show_bug.cgi?id=329091 Thanks, Shigeki Sakamoto. ---------------------------------------------------------------------- diff -r 531b73491ac2 virt-install --- a/virt-install Wed Oct 10 14:24:48 2007 -0400 +++ b/virt-install Tue Oct 16 16:01:29 2007 +0900 @@ -15,6 +15,7 @@ import os, sys, string +from stat import * from optparse import OptionParser, OptionValueError import subprocess import logging @@ -48,10 +49,10 @@ def get_disk(disk, size, sparse, guest, if not size is None: msg = _("Please enter the path to the file you would like to use for storage. It will have size %sGB.") %(size,) disk = cli.prompt_for_input(msg, disk) - if os.path.exists(disk) and os.path.isfile(disk): + if os.path.exists(disk) and ( S_ISBLK(os.stat(disk)[ST_MODE]) or S_ISREG(os.stat(disk)[ST_MODE]) ): while 1: retryFlg = False - warnmsg = _("You are going to overwrite file '%s'!\n") % disk + warnmsg = _("You are going to overwrite '%s'!\n") % disk res = cli.prompt_for_input(warnmsg + _("Do you really want to use the file (yes or no)? ")) try: if cli.yes_or_no(res) is True: ---------------------------------------------------------------------- From atodorov at redhat.com Tue Oct 16 12:03:15 2007 From: atodorov at redhat.com (Alexander Todorov) Date: Tue, 16 Oct 2007 14:03:15 +0200 Subject: [et-mgmt-tools] virt-manager and multiple CDs swapping In-Reply-To: <47134E07.7060404@bppiac.hu> References: <470DE033.7090908@bppiac.hu> <47134BFC.2040303@redhat.com> <47134E07.7060404@bppiac.hu> Message-ID: <4714A883.4020602@redhat.com> Hello, I found a couple of e-mail explaining how to change the iso file used for CDROM when performing full virt install. The approach with pressing Ctrl+Alt+2 to switch to qemu-dm console is not obvious and not always a pleasant experience. To solve this I propose the following: 1) FEATURE: instead of choosing a single iso file user chooses a list of files. The user is responsible for compiling a list with all media required for installation. Guest OS will try to boot from the first iso in the list and proceed with installation. At som epoint the installer will "eject" the disc and prompt for the next one. This will result in the software unmounting the image and instructing qemu-dm to change the virtual device to next file in the list. or 2) The GUI showing the virtual console (the one with On/Off/Pause buttons) will have another button : CDROM. Pressing this button will result in dialog prompting the user for the location of next image and when chosen change the virtual CD device to that image. NOTES: Pressing OK button in the installer after disc has been inserted is responsibility of the user performing the install or installation program detecting the new disc and continuing. 1 and 2 depend on the ability to send instructions to qemu-dm remotely (which at this point I don't know howif possible.) Please vote for 1) or 2) or add any other useful information. Thanks, Alexander. From berrange at redhat.com Tue Oct 16 13:30:03 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 16 Oct 2007 14:30:03 +0100 Subject: [et-mgmt-tools] virt-manager and multiple CDs swapping In-Reply-To: <4714A883.4020602@redhat.com> References: <470DE033.7090908@bppiac.hu> <47134BFC.2040303@redhat.com> <47134E07.7060404@bppiac.hu> <4714A883.4020602@redhat.com> Message-ID: <20071016133003.GA2107@redhat.com> On Tue, Oct 16, 2007 at 02:03:15PM +0200, Alexander Todorov wrote: > Hello, > I found a couple of e-mail explaining how to change the iso file used > for CDROM when performing full virt install. The approach with pressing > Ctrl+Alt+2 to switch to qemu-dm console is not obvious and not always a > pleasant experience. To solve this I propose the following: The QEMU console is a security hole. We disabled access to it in Fedora. > 1) FEATURE: instead of choosing a single iso file user chooses a list of > files. The user is responsible for compiling a list with all media > required for installation. Guest OS will try to boot from the first iso > in the list and proceed with installation. At som epoint the installer > will "eject" the disc and prompt for the next one. This will result in > the software unmounting the image and instructing qemu-dm to change the > virtual device to next file in the list. > > or > > 2) The GUI showing the virtual console (the one with On/Off/Pause > buttons) will have another button : CDROM. Pressing this button will > result in dialog prompting the user for the location of next image and > when chosen change the virtual CD device to that image. > > NOTES: > > Pressing OK button in the installer after disc has been inserted is > responsibility of the user performing the install or installation > program detecting the new disc and continuing. > > 1 and 2 depend on the ability to send instructions to qemu-dm remotely > (which at this point I don't know howif possible.) > > Please vote for 1) or 2) or add any other useful information. Neither. Virt-manager 0.5.2 or later already has the ability to change the CDROM drive media for a running guest. This works for Xen currently, and libvirt support for the same in KVM is in progress. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From Nick.Couchman at seakr.com Tue Oct 16 21:25:29 2007 From: Nick.Couchman at seakr.com (Nick Couchman) Date: Tue, 16 Oct 2007 15:25:29 -0600 Subject: [et-mgmt-tools] No module named glib Message-ID: <4714D7E9.87A6.0099.1@seakr.com> I'm trying to run virt-manager 0.5.1 on RHEL4. I've gone through the lengthy list of prereqs for the software and have gotten it compiled, but now when I try to run virt-manager, I get the following error in the log file: ImportError: No module named glib The line before that states that it's trying to import dbus.glib when it fails. Anyone had any success getting virt-manager running on RHEL4U5, and, if so, how? Any clues as to what needs to be done to fix the above error? Thanks, Nick Nick Couchman SEAKR Engineering, Inc. 6221 South Racine Circle Centennial, CO 80111 Main: (303) 790-8499 Fax: (303) 790-8720 Web: http://www.seakr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Tue Oct 16 21:48:04 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 16 Oct 2007 22:48:04 +0100 Subject: [et-mgmt-tools] No module named glib In-Reply-To: <4714D7E9.87A6.0099.1@seakr.com> References: <4714D7E9.87A6.0099.1@seakr.com> Message-ID: <20071016214804.GQ30866@redhat.com> On Tue, Oct 16, 2007 at 03:25:29PM -0600, Nick Couchman wrote: > I'm trying to run virt-manager 0.5.1 on RHEL4. I've gone through the > lengthy list of prereqs for the software and have gotten it compiled, > but now when I try to run virt-manager, I get the following error in > the log file: > ImportError: No module named glib > > The line before that states that it's trying to import dbus.glib when it > fails. Anyone had any success getting virt-manager running on RHEL4U5, > and, if so, how? Any clues as to what needs to be done to fix the above > error? RHEL-4 ships with an old version of dbus which just isn't going to work in the slightest. Upgrading dbus on RHEL-4 is also not practical because it impacts core system daemon. Probably your only semi-practical option is to remove/comment out the dbus stuff in virt-manager, but then you loose functionality for integrating with the host network when creating new guests & virtual networks Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From cam at cs.ualberta.ca Tue Oct 16 21:50:05 2007 From: cam at cs.ualberta.ca (Cam Macdonell) Date: Tue, 16 Oct 2007 15:50:05 -0600 Subject: [et-mgmt-tools] No module named glib In-Reply-To: <4714D7E9.87A6.0099.1@seakr.com> References: <4714D7E9.87A6.0099.1@seakr.com> Message-ID: <4715320D.1030303@cs.ualberta.ca> Nick Couchman wrote: > > > I'm trying to run virt-manager 0.5.1 on RHEL4. I've gone through the > lengthy list of prereqs for the software and have gotten it compiled, > but now when I try to run virt-manager, I get the following error in the > log file: > > ImportError: No module named glib > Hey Nick, Ya, virtmanager is a pain in terms of prereqs. That looks like a python module is missing. I'm not sure what package includes that. Maybe glib2-devel? Cam From Nick.Couchman at seakr.com Tue Oct 16 22:55:16 2007 From: Nick.Couchman at seakr.com (Nick Couchman) Date: Tue, 16 Oct 2007 16:55:16 -0600 Subject: [et-mgmt-tools] No module named glib In-Reply-To: <20071016214804.GQ30866@redhat.com> References: <4714D7E9.87A6.0099.1@seakr.com> <20071016214804.GQ30866@redhat.com> Message-ID: <4714ECF4.87A6.0099.1@seakr.com> Hmm...so why doesn't using the "--no-dbus" option make a difference? Also, would things be better if I go back to previous versions? I've tried using virt-manager 0.3.2 and get the following error, instead: TypeError: basicConfig() takes no arguments (5 given) Looking at the 0.3.2 readme file, the RHEL4 packages still don't quite meet those requirements, so maybe it's still something to do with that?? Thanks, Nick >>> On 2007/10/16 at 15:48, "Daniel P. Berrange" wrote: On Tue, Oct 16, 2007 at 03:25:29PM -0600, Nick Couchman wrote: > I'm trying to run virt-manager 0.5.1 on RHEL4. I've gone through the > lengthy list of prereqs for the software and have gotten it compiled, > but now when I try to run virt-manager, I get the following error in > the log file: > ImportError: No module named glib > > The line before that states that it's trying to import dbus.glib when it > fails. Anyone had any success getting virt-manager running on RHEL4U5, > and, if so, how? Any clues as to what needs to be done to fix the above > error? RHEL-4 ships with an old version of dbus which just isn't going to work in the slightest. Upgrading dbus on RHEL-4 is also not practical because it impacts core system daemon. Probably your only semi-practical option is to remove/comment out the dbus stuff in virt-manager, but then you loose functionality for integrating with the host network when creating new guests & virtual networks Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Tue Oct 16 23:06:20 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 17 Oct 2007 00:06:20 +0100 Subject: [et-mgmt-tools] No module named glib In-Reply-To: <4714ECF4.87A6.0099.1@seakr.com> References: <4714D7E9.87A6.0099.1@seakr.com> <20071016214804.GQ30866@redhat.com> <4714ECF4.87A6.0099.1@seakr.com> Message-ID: <20071016230620.GR30866@redhat.com> On Tue, Oct 16, 2007 at 04:55:16PM -0600, Nick Couchman wrote: > Hmm...so why doesn't using the "--no-dbus" option make a difference? Also, Virt-manager exposes some of its external API via DBus, so that other desktop apps can control virt-manager's UI. The --no-dbus flag merely disables this remote UI control ability. Virt-manager still needs DBus to talk with HAL. > would things be better if I go back to previous versions? Not really, we've been using DBus since day 1. Basically we made a conscious design decision to only support virt-manager on the modern Linux desktop platform, which in practice means approximately Fedora Core 6 vintage or later. There is a lot of development in the Linux desktop arena & to get the best user interaction experiance we need to take advtange of this. RHEL-4 just doesn't cut it as a viable desktop because it is frozen on a application stack more than 2 years old at this point. By all means run servers on RHEL-4, but for desktop applications something more recent is a far better bet. NB, I know until recently you had to run virt-manager on the same host as you are virtualizing, so if you're running Xen on a RHEL-4 host I understand why you'd want to run virt-manager on a RHEL-4 host. We are evolving to the point where virt-manager will be run remotely for all operations - we're 50% there - you can manage existing guests, but not create new guests at this time. Dan, -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From tobert at gmail.com Wed Oct 17 00:33:49 2007 From: tobert at gmail.com (Al Tobey) Date: Tue, 16 Oct 2007 17:33:49 -0700 Subject: [et-mgmt-tools] koan automatic network configuration patch Message-ID: <5ac7acb10710161733l5e27ca37pb99126d729b1dcab@mail.gmail.com> Attached is a patch to add a -A/--autonet option to koan. As an introduction, here's the relevant part of the man page: --autonet Tells koan to configure the installer's networking on the kernel command line using ip=/netmask=/gateway=, etc.. First, it will download the kickstart configuration and check for a network --bootproto=static method. If that fails and --replace-self has been specified, it will use the current system's network configuration, as found using iproute2. Obviously this only supports Linux systems. Also, this isn't really useful to most people without cobbler 0.6.3 (unreleased) or weird template hacks to do netmask/gateway lookups like I'm using. It's working really well for me both on Xen VM's and for re-imaging servers to new/different OS's. Please comment. -Al Tobey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-autonet-A-support.patch Type: text/x-patch Size: 15166 bytes Desc: not available URL: From mdehaan at redhat.com Wed Oct 17 14:38:36 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 17 Oct 2007 10:38:36 -0400 Subject: [et-mgmt-tools] koan automatic network configuration patch In-Reply-To: <5ac7acb10710161733l5e27ca37pb99126d729b1dcab@mail.gmail.com> References: <5ac7acb10710161733l5e27ca37pb99126d729b1dcab@mail.gmail.com> Message-ID: <47161E6C.40007@redhat.com> Al Tobey wrote: > Attached is a patch to add a -A/--autonet option to koan. > > As an introduction, here's the relevant part of the man page: > > --autonet Tells koan to configure the installer's networking on the > kernel command line using ip=/netmask=/gateway=, etc.. First, it > will download the kickstart configuration and check for a network > --bootproto=static method. If that fails and --replace-self has been > specified, it will use the current system's network configuration, as > found using iproute2. > > To summarize: it keeps the real or virtual system from having to initially DHCP when enough information is stored in Cobbler (or can be found on the local system) so that it's not required. Depending on the kickstarts employed, the kickstart may still indicate a DHCP configuration, so this would only save the initial DHCP. Did I get that right? > Obviously this only supports Linux systems. Also, this isn't really > useful to most people without cobbler 0.6.3 (unreleased) or weird > template hacks to do netmask/gateway lookups like I'm using. It's > working really well for me both on Xen VM's and for re-imaging servers > to new/different OS's. > For clarification, Cobbler 0.6.3 is relevant because each NIC has an optional --gateway and --subnet parameter, where before there's not as clean of a way to save/access that information (--ksmeta). > Please comment. > -Al Tobey > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Nick.Couchman at seakr.com Wed Oct 17 14:56:41 2007 From: Nick.Couchman at seakr.com (Nick Couchman) Date: Wed, 17 Oct 2007 08:56:41 -0600 Subject: [et-mgmt-tools] No module named glib In-Reply-To: <20071016230620.GR30866@redhat.com> References: <4714D7E9.87A6.0099.1@seakr.com> <20071016214804.GQ30866@redhat.com> <4714ECF4.87A6.0099.1@seakr.com> <20071016230620.GR30866@redhat.com> Message-ID: <4715CE48.87A6.0099.1@seakr.com> Okay, well, despite advice to the contrary I'm attempting to compile all the dependencies for this package for RHEL4. I've upgraded dbus, which seemed to go just fine. One note, though. The README file has the requirement for pygtk2 listed as >= 1.99.12.6. However, the about dialog box uses the about_dialog_set_email_hook function, which doesn't appear until pygtk 2.6 or so (definitely not in pygtk 2.4 that RHEL4 uses. I've had to do GTK+ and GLIB to get things working - too much more and I'll likely give it up. --Nick >>> On Tue, Oct 16, 2007 at 5:06 PM, "Daniel P. Berrange" wrote: On Tue, Oct 16, 2007 at 04:55:16PM -0600, Nick Couchman wrote: > Hmm...so why doesn't using the "--no-dbus" option make a difference? Also, Virt-manager exposes some of its external API via DBus, so that other desktop apps can control virt-manager's UI. The --no-dbus flag merely disables this remote UI control ability. Virt-manager still needs DBus to talk with HAL. > would things be better if I go back to previous versions? Not really, we've been using DBus since day 1. Basically we made a conscious design decision to only support virt-manager on the modern Linux desktop platform, which in practice means approximately Fedora Core 6 vintage or later. There is a lot of development in the Linux desktop arena & to get the best user interaction experiance we need to take advtange of this. RHEL-4 just doesn't cut it as a viable desktop because it is frozen on a application stack more than 2 years old at this point. By all means run servers on RHEL-4, but for desktop applications something more recent is a far better bet. NB, I know until recently you had to run virt-manager on the same host as you are virtualizing, so if you're running Xen on a RHEL-4 host I understand why you'd want to run virt-manager on a RHEL-4 host. We are evolving to the point where virt-manager will be run remotely for all operations - we're 50% there - you can manage existing guests, but not create new guests at this time. Dan, -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ ( http://search.cpan.org/~danberr/ ) -=| |=- Projects: http://freshmeat.net/~danielpb/ ( http://freshmeat.net/~danielpb/ ) -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobert at gmail.com Wed Oct 17 16:31:34 2007 From: tobert at gmail.com (Al Tobey) Date: Wed, 17 Oct 2007 09:31:34 -0700 Subject: [et-mgmt-tools] koan automatic network configuration patch In-Reply-To: <47161E6C.40007@redhat.com> References: <5ac7acb10710161733l5e27ca37pb99126d729b1dcab@mail.gmail.com> <47161E6C.40007@redhat.com> Message-ID: <5ac7acb10710170931h2ae40708lf9f8c090d5cd616f@mail.gmail.com> On 10/17/07, Michael DeHaan wrote: > Al Tobey wrote: > > Attached is a patch to add a -A/--autonet option to koan. > > > > As an introduction, here's the relevant part of the man page: > > > > --autonet Tells koan to configure the installer's networking on the > > kernel command line using ip=/netmask=/gateway=, etc.. First, it > > will download the kickstart configuration and check for a network > > --bootproto=static method. If that fails and --replace-self has been > > specified, it will use the current system's network configuration, as > > found using iproute2. > > > > > To summarize: it keeps the real or virtual system from having to > initially DHCP when enough information is > stored in Cobbler (or can be found on the local system) so that it's not > required. Depending on the kickstarts > employed, the kickstart may still indicate a DHCP configuration, so this > would only save the initial DHCP. > > Did I get that right? Yes, that's exactly right. > > Obviously this only supports Linux systems. Also, this isn't really > > useful to most people without cobbler 0.6.3 (unreleased) or weird > > template hacks to do netmask/gateway lookups like I'm using. It's > > working really well for me both on Xen VM's and for re-imaging servers > > to new/different OS's. > > > For clarification, Cobbler 0.6.3 is relevant because each NIC has an > optional --gateway and --subnet parameter, where > before there's not as clean of a way to save/access that information > (--ksmeta). > > > > Please comment. > > -Al Tobey From crobinso at redhat.com Wed Oct 17 17:49:05 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 17 Oct 2007 13:49:05 -0400 Subject: [et-mgmt-tools] [PATCH] bugzillaID:329091 In-Reply-To: <200710161609.CAE43776.6EJ0G99K@aa.jp.fujitsu.com> References: <200710161450.AGF26966.KJ99EG60@aa.jp.fujitsu.com> <200710160618.l9G6I6Xl010227@fjmscan503.ms.jp.fujitsu.com> <200710161541.BGJ65120.E06J9K9G@aa.jp.fujitsu.com> <200710161609.CAE43776.6EJ0G99K@aa.jp.fujitsu.com> Message-ID: <47164B11.8080307@redhat.com> S.Sakamoto wrote: > Hi > > I make a patch of BugzillaID-329091. > https://bugzilla.redhat.com/show_bug.cgi?id=329091 > > Thanks, > Shigeki Sakamoto. > > ---------------------------------------------------------------------- > diff -r 531b73491ac2 virt-install > --- a/virt-install Wed Oct 10 14:24:48 2007 -0400 > +++ b/virt-install Tue Oct 16 16:01:29 2007 +0900 > @@ -15,6 +15,7 @@ > > > import os, sys, string > +from stat import * > from optparse import OptionParser, OptionValueError > import subprocess > import logging > @@ -48,10 +49,10 @@ def get_disk(disk, size, sparse, guest, > if not size is None: > msg = _("Please enter the path to the file you would like to use for storage. It will have size %sGB.") %(size,) > disk = cli.prompt_for_input(msg, disk) > - if os.path.exists(disk) and os.path.isfile(disk): > + if os.path.exists(disk) and ( S_ISBLK(os.stat(disk)[ST_MODE]) or S_ISREG(os.stat(disk)[ST_MODE]) ): > while 1: > retryFlg = False > - warnmsg = _("You are going to overwrite file '%s'!\n") % disk > + warnmsg = _("You are going to overwrite '%s'!\n") % disk > res = cli.prompt_for_input(warnmsg + _("Do you really want to use the file (yes or no)? ")) > try: > if cli.yes_or_no(res) is True: > ---------------------------------------------------------------------- Hello, I don't think this is the right approach. From the bug report, I agree that we shouldn't make it so easy to ruin a block device without some kind of precaution, but the right way to do it would be to have something that would require the user to explicitly specify the type of storage desired. Such as --file be just for file based storage, and add a --blkdev or some such option to specify device based storage. Or maintain --file as the storage location and add a --disktype option. Unfortunately this would break the existing interface, but so would this patch, which would require interaction anytime someone wanted to specify a device for storage. Anyone else have an opinion on the right direction to go? I think having an explicit way to specify storage would be handy anyways. - Cole -- Cole Robinson crobinso at redhat.com From berrange at redhat.com Wed Oct 17 18:00:16 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 17 Oct 2007 19:00:16 +0100 Subject: [et-mgmt-tools] [PATCH] bugzillaID:329091 In-Reply-To: <47164B11.8080307@redhat.com> References: <200710161450.AGF26966.KJ99EG60@aa.jp.fujitsu.com> <200710160618.l9G6I6Xl010227@fjmscan503.ms.jp.fujitsu.com> <200710161541.BGJ65120.E06J9K9G@aa.jp.fujitsu.com> <200710161609.CAE43776.6EJ0G99K@aa.jp.fujitsu.com> <47164B11.8080307@redhat.com> Message-ID: <20071017180016.GG27466@redhat.com> On Wed, Oct 17, 2007 at 01:49:05PM -0400, Cole Robinson wrote: > S.Sakamoto wrote: > > Hi > > > > I make a patch of BugzillaID-329091. > > https://bugzilla.redhat.com/show_bug.cgi?id=329091 > > > > Thanks, > > Shigeki Sakamoto. > > > > ---------------------------------------------------------------------- > > diff -r 531b73491ac2 virt-install > > --- a/virt-install Wed Oct 10 14:24:48 2007 -0400 > > +++ b/virt-install Tue Oct 16 16:01:29 2007 +0900 > > @@ -15,6 +15,7 @@ > > > > > > import os, sys, string > > +from stat import * > > from optparse import OptionParser, OptionValueError > > import subprocess > > import logging > > @@ -48,10 +49,10 @@ def get_disk(disk, size, sparse, guest, > > if not size is None: > > msg = _("Please enter the path to the file you would like to use for storage. It will have size %sGB.") %(size,) > > disk = cli.prompt_for_input(msg, disk) > > - if os.path.exists(disk) and os.path.isfile(disk): > > + if os.path.exists(disk) and ( S_ISBLK(os.stat(disk)[ST_MODE]) or S_ISREG(os.stat(disk)[ST_MODE]) ): > > while 1: > > retryFlg = False > > - warnmsg = _("You are going to overwrite file '%s'!\n") % disk > > + warnmsg = _("You are going to overwrite '%s'!\n") % disk > > res = cli.prompt_for_input(warnmsg + _("Do you really want to use the file (yes or no)? ")) > > try: > > if cli.yes_or_no(res) is True: > > ---------------------------------------------------------------------- > > Hello, > > I don't think this is the right approach. From the bug report, I agree > that we shouldn't make it so easy to ruin a block device without some > kind of precaution, but the right way to do it would be to have something > that would require the user to explicitly specify the type of storage > desired. Such as --file be just for file based storage, and add a --blkdev > or some such option to specify device based storage. Or maintain --file as > the storage location and add a --disktype option. > > Unfortunately this would break the existing interface, but so would > this patch, which would require interaction anytime someone wanted > to specify a device for storage. Yep, this is not acceptable. If we force a prompt for all block devices, then the user will just end up using the override flag all the time, defeating the purpose of checking. Using a separate --blkdev flag does not solve the problem either, since they could still easily overwrite the host filesystem. > Anyone else have an opinion on the right direction to go? I think > having an explicit way to specify storage would be handy anyways. Nope, this doesn't solve anything. The problem is that given a block device path /dev/sdN, there is no easy way to determine if it is already used in the host. You can check if its mounted, but that's useless of the volume is used as Swap. It also misses if the device is in fact a physical volume in LVM. It also misses if the device is setup via dmcrypt. It is frankly a loosing battle to try & guess if a device is in use in the host. Xen does a minimal attempt by looking to see if it is mounted but that misses the swap & LVM & device mapper scenarios. I don't see us being able todo any better in virt-install. The only viable long term approach is to develop the libvirt storage APIs, allowing the admin to explicitly design certain devices as being available for guest usage ahead of time. That would let virt-install validate paths given to it for sanity Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From msinhore at gmail.com Wed Oct 17 19:05:40 2007 From: msinhore at gmail.com (Marco Sinhoreli) Date: Wed, 17 Oct 2007 16:05:40 -0300 Subject: [et-mgmt-tools] Problem to compile virt-manager in debian etch Message-ID: <20fe3cf60710171205k17a60649o3dd97577a18c32f5@mail.gmail.com> Hello all, I have a problem to compile the virt-manager in a Debian etch (64 bit version). I got the virt-manager source from mercurial repository. Bellow the output autogen.sh command: ./autogen.sh libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite configure.ac:7: required file `./config.rpath' not found man/Makefile.am:6: `%'-style pattern rules are a GNU make extension pixmaps/Makefile.am:3: wildcard $(srcdir: non-POSIX variable name pixmaps/Makefile.am:3: (probably a GNU make extension) src/Makefile.am:15: wildcard $(srcdir: non-POSIX variable name src/Makefile.am:15: (probably a GNU make extension) src/Makefile.am:35: `%'-style pattern rules are a GNU make extension src/Makefile.am:38: `%'-style pattern rules are a GNU make extension src/Makefile.am:41: `%'-style pattern rules are a GNU make extension src/Makefile.am:44: `%'-style pattern rules are a GNU make extension src/Makefile.am:26: variable `schema_SOURCES' is defined but no program or src/Makefile.am:26: library has `schema' as canonic name (possible typo) src/Makefile.am:11: variable `libexec_SOURCES' is defined but no program or src/Makefile.am:11: library has `libexec' as canonic name (possible typo) src/Makefile.am:4: variable `bin_SOURCES' is defined but no program or src/Makefile.am:4: library has `bin' as canonic name (possible typo) src/Makefile.am:18: variable `desktop_SOURCES' is defined but no program or src/Makefile.am:18: library has `desktop' as canonic name (possible typo) src/Makefile.am:8: variable `python_SOURCES' is defined but no program or src/Makefile.am:8: library has `python' as canonic name (possible typo) src/Makefile.am:22: variable `dbus_SOURCES' is defined but no program or src/Makefile.am:22: library has `dbus' as canonic name (possible typo) src/graphWidgets/Makefile.am:5: `:='-style assignments are not portable src/graphWidgets/Makefile.am:5: shell pkg-config --variable=codegendir pygtk-2.0: non-POSIX variable name src/graphWidgets/Makefile.am:5: (probably a GNU make extension) src/graphWidgets/Makefile.am:6: `:='-style assignments are not portable src/graphWidgets/Makefile.am:6: shell pkg-config --variable=defsdir pygtk-2.0: non-POSIX variable name src/graphWidgets/Makefile.am:6: (probably a GNU make extension) src/virtManager/Makefile.am:3: wildcard $(srcdir: non-POSIX variable name src/virtManager/Makefile.am:3: (probably a GNU make extension) src/virtManager/Makefile.am:7: python_DATA:$(srcdir: non-POSIX variable name src/virtManager/Makefile.am:15: `%'-style pattern rules are a GNU make extension Any idea? regards. -- Marco Sinhoreli From crobinso at redhat.com Wed Oct 17 19:53:42 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 17 Oct 2007 15:53:42 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: small exception handling fix In-Reply-To: <1191970553.2939.16.camel@lute.groveronline.com> References: <1191970553.2939.16.camel@lute.groveronline.com> Message-ID: <47166846.6080905@redhat.com> Andy Grover wrote: > Hi, > > This patch fixes exception handling slightly in virt-manager. > This has been committed. http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=58c46220f2df Thanks, Cole -- Cole Robinson crobinso at redhat.com From rjones at redhat.com Thu Oct 18 08:43:59 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 18 Oct 2007 09:43:59 +0100 Subject: [et-mgmt-tools] Re: [Libvir] Problem to compile virt-manager in debian etch In-Reply-To: <20fe3cf60710171205k17a60649o3dd97577a18c32f5@mail.gmail.com> References: <20fe3cf60710171205k17a60649o3dd97577a18c32f5@mail.gmail.com> Message-ID: <47171CCF.20909@redhat.com> Marco Sinhoreli wrote: > Hello all, > > I have a problem to compile the virt-manager in a Debian etch (64 bit > version). I got the virt-manager source from mercurial repository. > Bellow the output autogen.sh command: > > ./autogen.sh > libtoolize: `config.guess' exists: use `--force' to overwrite > libtoolize: `config.sub' exists: use `--force' to overwrite > libtoolize: `ltmain.sh' exists: use `--force' to overwrite > configure.ac:7: required file `./config.rpath' not found > man/Makefile.am:6: `%'-style pattern rules are a GNU make extension Ah the joys of automake ... You can get rid of the above warnings (at the miniscule cost of requiring GNU make) with the first attached patch. > src/Makefile.am:26: variable `schema_SOURCES' is defined but no program or > src/Makefile.am:26: library has `schema' as canonic name (possible typo) > src/Makefile.am:11: variable `libexec_SOURCES' is defined but no program or > src/Makefile.am:11: library has `libexec' as canonic name (possible typo) > src/Makefile.am:4: variable `bin_SOURCES' is defined but no program or > src/Makefile.am:4: library has `bin' as canonic name (possible typo) > src/Makefile.am:18: variable `desktop_SOURCES' is defined but no program or > src/Makefile.am:18: library has `desktop' as canonic name (possible typo) > src/Makefile.am:8: variable `python_SOURCES' is defined but no program or > src/Makefile.am:8: library has `python' as canonic name (possible typo) > src/Makefile.am:22: variable `dbus_SOURCES' is defined but no program or > src/Makefile.am:22: library has `dbus' as canonic name (possible typo) These are actual error messages. For example: schemadir = $(sysconfdir)/gconf/schemas schema_SOURCES = $(PACKAGE).schemas.in schema_DATA = $(PACKAGE).schemas %.schemas: $(srcdir)/%.schemas.in sed -e "s,::PACKAGE::,$(PACKAGE)," < $< > $@ What appears to be meant here is that virt-manager.schemas.in should be distributed in the tarball, that virt-manager.schemas should be installed in /etc/gconf/schemas, and that virt-manager.schemas is generated from virt-manager.schemas.in. It seems however that the version of automake shipped with Debian doesn't like you using _SOURCES when you are not building a binary or library (instead just list the files to be distributed in EXTRA_DIST). Patch for that attached. I always wonder what problem exactly automake is supposed to solve, and I never use it in my own programs. The final error is: > configure.ac:7: required file `./config.rpath' not found To get this file the first time after you clone the repository, do: autoreconf -f -i -Wno-portability In fact, we should really just use autoreconf instead of the home-brew autogen script. (That's what I recommend people do for virt-top et al.) Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-no-portability-warning.patch Type: text/x-patch Size: 448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-no-sources.patch Type: text/x-patch Size: 1297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Oct 18 09:55:41 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 18 Oct 2007 11:55:41 +0200 Subject: [et-mgmt-tools] koan automatic network configuration patch In-Reply-To: <5ac7acb10710170931h2ae40708lf9f8c090d5cd616f@mail.gmail.com> References: <5ac7acb10710161733l5e27ca37pb99126d729b1dcab@mail.gmail.com> <47161E6C.40007@redhat.com> <5ac7acb10710170931h2ae40708lf9f8c090d5cd616f@mail.gmail.com> Message-ID: <20071018115541.05e8eafc@python3.es.egwn.lan> Al Tobey wrote : > > > Attached is a patch to add a -A/--autonet option to koan. > > > > > > As an introduction, here's the relevant part of the man page: > > > > > > --autonet Tells koan to configure the installer's networking on the > > > kernel command line using ip=/netmask=/gateway=, etc.. First, it > > > will download the kickstart configuration and check for a network > > > --bootproto=static method. If that fails and --replace-self has been > > > specified, it will use the current system's network configuration, as > > > found using iproute2. > > > > > > > > To summarize: it keeps the real or virtual system from having to > > initially DHCP when enough information is > > stored in Cobbler (or can be found on the local system) so that it's not > > required. Depending on the kickstarts > > employed, the kickstart may still indicate a DHCP configuration, so this > > would only save the initial DHCP. > > > > Did I get that right? > > Yes, that's exactly right. Neat. This fits right into some dhcp-less environments I have! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.6-81.fc7 Load : 0.31 0.36 0.41 From msinhore at gmail.com Thu Oct 18 13:00:46 2007 From: msinhore at gmail.com (Marco Sinhoreli) Date: Thu, 18 Oct 2007 10:00:46 -0300 Subject: [et-mgmt-tools] Re: [Libvir] Problem to compile virt-manager in debian etch In-Reply-To: <47171CCF.20909@redhat.com> References: <20fe3cf60710171205k17a60649o3dd97577a18c32f5@mail.gmail.com> <47171CCF.20909@redhat.com> Message-ID: <20fe3cf60710180600y4050c2c5id03b42433a14c578@mail.gmail.com> Hello Rickard, Thanks a lot for your attention. :-) Reporting: It seems fixed the problems. autogen.sh command is worked without any errors, and warnings messages, however it isn't creating the configure script. Best regards, -- Marco Sinhoreli From rjones at redhat.com Thu Oct 18 13:58:31 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 18 Oct 2007 14:58:31 +0100 Subject: [et-mgmt-tools] Re: [Libvir] Problem to compile virt-manager in debian etch In-Reply-To: <20fe3cf60710180600y4050c2c5id03b42433a14c578@mail.gmail.com> References: <20fe3cf60710171205k17a60649o3dd97577a18c32f5@mail.gmail.com> <47171CCF.20909@redhat.com> <20fe3cf60710180600y4050c2c5id03b42433a14c578@mail.gmail.com> Message-ID: <47176687.6090908@redhat.com> Marco Sinhoreli wrote: > Hello Rickard, > > Thanks a lot for your attention. :-) > Reporting: It seems fixed the problems. autogen.sh command is worked > without any errors, and warnings messages, however it isn't creating > the configure script. Not sure ... It definitely worked for me when I tried it out this morning on an up to date Debian etch. Are you sure there are no messages at all? What about when you use autoreconf instead of autogen? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From faberd at vertis.nl Thu Oct 18 14:22:08 2007 From: faberd at vertis.nl (faberd at vertis.nl) Date: Thu, 18 Oct 2007 16:22:08 +0200 Subject: [et-mgmt-tools] bugreport virt-manager Message-ID: <50BD9F2BCFC52840934CBADBBA4481B202F6BE15@aspmail01.ApplicationNet.nl> Hello, I discovered a small bug in virt-manager, version 0.2.6. When creating a new Paravirtualized server, and filing out a kickstart url with an &-sign, the creation fails with a "ERROR: virDomainCreaetLinux() failed" The kickstart file I want to use is actually only accessable with a url that has a &-sign, so I also tried to access it with the url encoded %26 url instead, so: http://install/ks/index.cgi?h=xen%26r=rhel5-i386 instead of http://install/ks/index.cgi?h=xen&r=rhel5-i386. This one also fails, but a bit later, on the CLI with: Entity: line 8: parser error : EntityRef: expecting ';' install/yam/rhel5-i386/disc1 ks=http://install/ks/index.cgi?h=xen&r ^ Also putting quotes around the url did not help. I can work around this by wget-ting the file first and storing it localy and using that file, but this does seem to be a bug. Kind regards, Dirk-Jan Faber From msinhore at gmail.com Thu Oct 18 14:28:30 2007 From: msinhore at gmail.com (Marco Sinhoreli) Date: Thu, 18 Oct 2007 11:28:30 -0300 Subject: [et-mgmt-tools] Re: [Libvir] Problem to compile virt-manager in debian etch In-Reply-To: <47176687.6090908@redhat.com> References: <20fe3cf60710171205k17a60649o3dd97577a18c32f5@mail.gmail.com> <47171CCF.20909@redhat.com> <20fe3cf60710180600y4050c2c5id03b42433a14c578@mail.gmail.com> <47176687.6090908@redhat.com> Message-ID: <20fe3cf60710180728k2990621cj770e70601c6987e7@mail.gmail.com> Hi, On 10/18/07, Richard W.M. Jones wrote: > Marco Sinhoreli wrote: > > Hello Rickard, > > > > Thanks a lot for your attention. :-) > > Reporting: It seems fixed the problems. autogen.sh command is worked > > without any errors, and warnings messages, however it isn't creating > > the configure script. > > Not sure ... It definitely worked for me when I tried it out this > morning on an up to date Debian etch. Are you sure there are no > messages at all? What about when you use autoreconf instead of autogen? autoreconf output (after patches applied): [...] Copying file po/quot.sed Copying file po/remove-potcdate.sin configure.ac:2: installing `./missing' configure.ac:2: installing `./install-sh' src/graphWidgets/Makefile.am: installing `./depcomp' -- Marco Sinhoreli From crobinso at redhat.com Thu Oct 18 21:08:10 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 18 Oct 2007 17:08:10 -0400 Subject: [et-mgmt-tools] [PATCH] Fix virt-install iso path validation (BZ 249424) Message-ID: <4717CB3A.3000604@redhat.com> This patch builds a VirtualDisk object using the cdrom path passed to virt-install to reuse the already present validation. It also touches up some of the error messages the VirtualDisk throws to make them more general specific. This solves bz 249424. - Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-install-cdrom-validation-patch URL: From crobinso at redhat.com Thu Oct 18 21:16:35 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 18 Oct 2007 17:16:35 -0400 Subject: [et-mgmt-tools] [PATCH] Add --nointeract option to virt-install Message-ID: <4717CD33.8020907@redhat.com> The attached patch adds a command line flag to disable interaction in virt-install. I think this would be handy for anyone using virt-install for scripting or automated testing. Setting the flag causes virt-install to throw an exception when there would normally be a prompt for input. I used a global variable in cli.py to accomplish this, which is simple, but there may be a 'more correct' way to do this that I'm missing. Anyone have any input on the method, or the feature itself? Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-nointeract-option-patch URL: From lnitz at hawaii.edu Fri Oct 19 09:37:30 2007 From: lnitz at hawaii.edu (Lawrence Nitz) Date: Thu, 18 Oct 2007 23:37:30 -1000 Subject: [et-mgmt-tools] Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 Message-ID: <1192786650.12383.4.camel@bach> I installed virt-manager 5.0 (and subsequent editions) to take advantage of the new options to change CDs, and to add CD drives to existing guest machines. Each of these versions had fewer working features than the 4.x shipped with Fedora 7--There was no button to create a new machine, a grayed-out button to start an old machine, and so forth. Q: Did I fail in installation, leaving out some critical component? Q Are these versions only partial trials, testing specific operations, but not containing all the features and commands of the older 0.4.x version? Q: Will any of them control VMs, or must I reinstall 0.4.x of virt-manager to get a complete control panel? Thanks, Larry Nitz From hbrock at redhat.com Fri Oct 19 11:25:41 2007 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 19 Oct 2007 07:25:41 -0400 Subject: [et-mgmt-tools] Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: <1192786650.12383.4.camel@bach>; from lnitz@hawaii.edu on Thu, Oct 18, 2007 at 11:37:30PM -1000 References: <1192786650.12383.4.camel@bach> Message-ID: <20071019072541.A20587@redhat.com> On Thu, Oct 18, 2007 at 11:37:30PM -1000, Lawrence Nitz wrote: > I installed virt-manager 5.0 (and subsequent editions) to take advantage > of the new options to change CDs, and to add CD drives to existing guest > machines. > > Each of these versions had fewer working features than the 4.x shipped > with Fedora 7--There was no button to create a new machine, a grayed-out > button to start an old machine, and so forth. > > Q: Did I fail in installation, leaving out some critical component? > Q Are these versions only partial trials, testing specific operations, > but not containing all the features and commands of the older 0.4.x > version? > Q: Will any of them control VMs, or must I reinstall 0.4.x of > virt-manager to get a complete control panel? Sorry, there's been a bit of confusion about the location of the "create" button in the latest virt-manager release. Since creating a guest depends on the hypervisor you're connected to, and virt-manager can now display multiple connections and their guests, the "create" button is now located next to the connection line in the main window. Starting existing guests is accomplished by clicking the "start" button on the right-hand side of the guest's line in the main window. As far as installation, you will need the most recent release of libvirt for the cdrom changing feature to work. We do recommend using 0.5.2, there were some issues in 0.5.0 that are fixed there. Thanks, --Hugh From lfarkas at bppiac.hu Fri Oct 19 12:08:47 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 19 Oct 2007 14:08:47 +0200 Subject: [et-mgmt-tools] Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: <20071019072541.A20587@redhat.com> References: <1192786650.12383.4.camel@bach> <20071019072541.A20587@redhat.com> Message-ID: <47189E4F.6030708@bppiac.hu> Hugh Brock wrote: > On Thu, Oct 18, 2007 at 11:37:30PM -1000, Lawrence Nitz wrote: > As far as installation, you will need the most recent release of > libvirt for the cdrom changing feature to work. We do recommend using > 0.5.2, there were some issues in 0.5.0 that are fixed there. whooh? how can it be possible that on page http://virt-manager.et.redhat.com/download.html the latest virt-manager is 0.5.1 but at the same time in fedora development there is a 0.5.2? -- Levente "Si vis pacem para bellum!" From berrange at redhat.com Fri Oct 19 12:12:21 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 19 Oct 2007 13:12:21 +0100 Subject: [et-mgmt-tools] Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: <47189E4F.6030708@bppiac.hu> References: <1192786650.12383.4.camel@bach> <20071019072541.A20587@redhat.com> <47189E4F.6030708@bppiac.hu> Message-ID: <20071019121221.GC22887@redhat.com> On Fri, Oct 19, 2007 at 02:08:47PM +0200, Farkas Levente wrote: > Hugh Brock wrote: > > On Thu, Oct 18, 2007 at 11:37:30PM -1000, Lawrence Nitz wrote: > > As far as installation, you will need the most recent release of > > libvirt for the cdrom changing feature to work. We do recommend using > > 0.5.2, there were some issues in 0.5.0 that are fixed there. > > whooh? how can it be possible that on page > http://virt-manager.et.redhat.com/download.html > the latest virt-manager is 0.5.1 but at the same time in fedora > development there is a 0.5.2? Its not rocket science. I simply forgot to update it Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From lfarkas at bppiac.hu Fri Oct 19 12:17:15 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 19 Oct 2007 14:17:15 +0200 Subject: [et-mgmt-tools] Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: <20071019121221.GC22887@redhat.com> References: <1192786650.12383.4.camel@bach> <20071019072541.A20587@redhat.com> <47189E4F.6030708@bppiac.hu> <20071019121221.GC22887@redhat.com> Message-ID: <4718A04B.1010503@bppiac.hu> Daniel P. Berrange wrote: > On Fri, Oct 19, 2007 at 02:08:47PM +0200, Farkas Levente wrote: >> Hugh Brock wrote: >>> On Thu, Oct 18, 2007 at 11:37:30PM -1000, Lawrence Nitz wrote: >>> As far as installation, you will need the most recent release of >>> libvirt for the cdrom changing feature to work. We do recommend using >>> 0.5.2, there were some issues in 0.5.0 that are fixed there. >> whooh? how can it be possible that on page >> http://virt-manager.et.redhat.com/download.html >> the latest virt-manager is 0.5.1 but at the same time in fedora >> development there is a 0.5.2? > > Its not rocket science. I simply forgot to update it yes, but wouldn't be better to give us a download url where we can download any version and this won't happened anymore:-(. currently only direct version links exists (ok may be i can guess it if i know there is such a version). -- Levente "Si vis pacem para bellum!" From rjones at redhat.com Fri Oct 19 12:40:40 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 19 Oct 2007 13:40:40 +0100 Subject: [et-mgmt-tools] Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: <4718A04B.1010503@bppiac.hu> References: <1192786650.12383.4.camel@bach> <20071019072541.A20587@redhat.com> <47189E4F.6030708@bppiac.hu> <20071019121221.GC22887@redhat.com> <4718A04B.1010503@bppiac.hu> Message-ID: <4718A5C8.8040105@redhat.com> Farkas Levente wrote: > Daniel P. Berrange wrote: >> On Fri, Oct 19, 2007 at 02:08:47PM +0200, Farkas Levente wrote: >>> Hugh Brock wrote: >>>> On Thu, Oct 18, 2007 at 11:37:30PM -1000, Lawrence Nitz wrote: >>>> As far as installation, you will need the most recent release of >>>> libvirt for the cdrom changing feature to work. We do recommend using >>>> 0.5.2, there were some issues in 0.5.0 that are fixed there. >>> whooh? how can it be possible that on page >>> http://virt-manager.et.redhat.com/download.html >>> the latest virt-manager is 0.5.1 but at the same time in fedora >>> development there is a 0.5.2? >> Its not rocket science. I simply forgot to update it > > yes, but wouldn't be better to give us a download url where we can > download any version and this won't happened anymore:-(. currently only > direct version links exists (ok may be i can guess it if i know there is > such a version). You can also clone the development repository. See: http://virt-manager.org/scmrepo.html Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From berrange at redhat.com Fri Oct 19 13:25:50 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 19 Oct 2007 14:25:50 +0100 Subject: [et-mgmt-tools] Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: <4718A04B.1010503@bppiac.hu> References: <1192786650.12383.4.camel@bach> <20071019072541.A20587@redhat.com> <47189E4F.6030708@bppiac.hu> <20071019121221.GC22887@redhat.com> <4718A04B.1010503@bppiac.hu> Message-ID: <20071019132550.GA11714@redhat.com> On Fri, Oct 19, 2007 at 02:17:15PM +0200, Farkas Levente wrote: > Daniel P. Berrange wrote: > > On Fri, Oct 19, 2007 at 02:08:47PM +0200, Farkas Levente wrote: > >> Hugh Brock wrote: > >>> On Thu, Oct 18, 2007 at 11:37:30PM -1000, Lawrence Nitz wrote: > >>> As far as installation, you will need the most recent release of > >>> libvirt for the cdrom changing feature to work. We do recommend using > >>> 0.5.2, there were some issues in 0.5.0 that are fixed there. > >> whooh? how can it be possible that on page > >> http://virt-manager.et.redhat.com/download.html > >> the latest virt-manager is 0.5.1 but at the same time in fedora > >> development there is a 0.5.2? > > > > Its not rocket science. I simply forgot to update it > > yes, but wouldn't be better to give us a download url where we can > download any version and this won't happened anymore:-(. currently only > direct version links exists (ok may be i can guess it if i know there is > such a version). Again it doesn't take much effort to look at the download directory directly. It doesn't help though, because as I said in my previous mail I forgot to update the website, so there is no 0.5.2 tar.gz there for you to download, whether it was linked to it directly or not. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From rjones at redhat.com Fri Oct 19 15:07:04 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 19 Oct 2007 16:07:04 +0100 Subject: [et-mgmt-tools] [ANNOUNCE] virt-top 0.3.3.0 released Message-ID: <4718C818.7060404@redhat.com> I'm pleased to announce the release of virt-top 0.3.3.0. virt-top is a top-like utility for showing stats of virtualized domains. Many keys and command line options are the same as for ordinary top. It uses libvirt so it capable of showing stats across a variety of different virtualization systems. There are a number of new features, including much better support for running virt-top from non-interactive scripts, more information can be logged to CSV files (and more control over what is logged). As usual there are bug fixes and general improvements. Thanks for invaluable feedback and suggestions from JMH, Mark Wagner, Charlie Wyse. You can read about virt-top here: http://et.redhat.com/~rjones/virt-top/ Source can be grabbed from: http://et.redhat.com/~rjones/ocaml-libvirt/ http://hg.et.redhat.com/virt/applications/virt-top--devel I'll build some binaries later today which will appear here: http://et.redhat.com/~rjones/virt-top/download.html Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mdehaan at redhat.com Fri Oct 19 21:03:19 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 19 Oct 2007 17:03:19 -0400 Subject: [et-mgmt-tools] What's new in Cobbler development lately Message-ID: <47191B97.2010401@redhat.com> A few things of interest to a few people.... There are still a few things upstream that I want to get done before pushing 0.6.3 out. However, it's worth talking about what is already there, in case anyone is interested in those features and would like to play with/test them now. First off -- performance upgrades. Cobbler does great now with an average number of records, but performance with a very large number of systems in the "database" could be better. By switching all serializers (except settings) to serializer_shelve in /etc/cobbler/auth.conf, cobbler gets a lot faster for very large configurations. This is because changes to the cobbler "database" can be made without reading/writing the whole file. I'm still undecided as to whether this should be the default for new Cobbler installs, but there will be a script to migrate users between formats for those that have existing configurations. With the new code, it's possible to run a "cobbler list" command and see 5000 entries come back in 2 seconds -- before, YAML parsing/loading would have made storing a config that large in YAML somewhat painful. Currently this is using BSD-DB (which some of you said is scary, fair enough), though we could also use gddb. I've tested both and performance is identical. sqlite is possible, but maybe not needed. You can read more here: https://hosted.fedoraproject.org/projects/cobbler/wiki/AlternativeSerializers Second -- there was a request to extend the idea of Cobbler triggers ( https://hosted.fedoraproject.org/projects/cobbler/wiki/CobblerTriggers ) to support a "sync" trigger. We have that now. For instance, now we have the service-restart code as a trigger. So by default it will restart dhcpd/dnsmasq after a cobbler sync if you have DHCP management turned on. If you don't, it does nothing. However, suppose you wanted Cobbler to push out DHCP configurations to multiple servers? No problem! Now you can modify the trigger yourself and make it do whatever you want, all without modifying Cobbler code. Both making things more modular (for arbitrary user extensibility) and making things scale for extremely large configurations will definitely be an ongoing focus for subsequent releases. If you're interested in any of the above, check out the git version control repo. --Michael From mdehaan at redhat.com Fri Oct 19 21:05:29 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 19 Oct 2007 17:05:29 -0400 Subject: [et-mgmt-tools] What's new in Cobbler development lately In-Reply-To: <47191B97.2010401@redhat.com> References: <47191B97.2010401@redhat.com> Message-ID: <47191C19.9040402@redhat.com> Michael DeHaan wrote: > By switching all serializers (except settings) to serializer_shelve in > /etc/cobbler/auth.conf, cobbler gets a lot faster for very large > configurations. This should read /etc/cobbler/modules.conf. From lnitz at hawaii.edu Fri Oct 19 21:16:56 2007 From: lnitz at hawaii.edu (Lawrence H Nitz) Date: Fri, 19 Oct 2007 11:16:56 -1000 Subject: [et-mgmt-tools] Re: Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: <20071019124153.B40AF736A3@hormel.redhat.com> References: <20071019124153.B40AF736A3@hormel.redhat.com> Message-ID: Thanks for the kind responses. I think there may be other problems, since I do not see any create buttons in any portion of my 0.5.2 virt-manager screen. I may have contaminated the installation in moving from one release to another. I suspect that the python archive called in the program may be ruined. Is there a straightforward way to uninstall all of the virt-manager directories, so that I can do a truly clean install? Thanks, Larry Nitz From hbrock at redhat.com Fri Oct 19 21:26:31 2007 From: hbrock at redhat.com (Hugh O. Brock) Date: Fri, 19 Oct 2007 17:26:31 -0400 Subject: [et-mgmt-tools] Re: Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 In-Reply-To: References: <20071019124153.B40AF736A3@hormel.redhat.com> Message-ID: <20071019212631.GI15667@redhat.com> On Fri, Oct 19, 2007 at 11:16:56AM -1000, Lawrence H Nitz wrote: > Thanks for the kind responses. > > I think there may be other problems, since I do not see any create buttons in any portion of my 0.5.2 virt-manager screen. I may have contaminated the installation in moving from one release to another. I suspect that the python archive called in the program may be ruined. > > Is there a straightforward way to uninstall all of the virt-manager directories, so that I can do a truly clean install? Are you running virt-manager as root? The UI won't show a create button unless the connection to your hypervisor is fully privileged. Speaking of which, are you using the Xen hypervisor, or KVM? And, do you see any guests you have previously defined (if you defined any)? --Hugh From lippold at gmail.com Sat Oct 20 01:48:38 2007 From: lippold at gmail.com (Aaron Lippold) Date: Fri, 19 Oct 2007 21:48:38 -0400 Subject: [et-mgmt-tools] What's new in Cobbler development lately In-Reply-To: <47191C19.9040402@redhat.com> References: <47191B97.2010401@redhat.com> <47191C19.9040402@redhat.com> Message-ID: <39d2723b0710191848j3ddc224eg29f17aef69f9b3a@mail.gmail.com> Hi Mike and gang, These sound like some great enhancements. I was hoping the list and yourself might help me work out some things. I am going to be putting together a new infrastructure for the open source group at my organization and I was thinking about setting up a virt enviroment for my production services. Webserver, development/project enviroment - i.e. svn, bugs, tickets, etc. most likely trac or sourceforge - a gnumailman service, etc. I was thinking that, if I did this, it might be smart to double up in a kind of virt HA setup. Do you know anyone who has setup this type of thing and how they are succeeding with it. Also, for my testing and pre-deployment I was going to use another virt env. This most likely wouldn't have to be HA. I, of course, was going to use virt-manager to help manage this setup. Thoughts? Suggestions? Specifically what level of hardware would really be needed for a medium load - 10-15 projects - 100 general users etc. I was thinking about a 2 cpu dual or quad core setup with a SAN for the virt images etc. This would be the first deployment of an infrastructure which was virt rather than individual systems. Thoughts? Thanks, Aaron On 10/19/07, Michael DeHaan wrote: > Michael DeHaan wrote: > > By switching all serializers (except settings) to serializer_shelve in > > /etc/cobbler/auth.conf, cobbler gets a lot faster for very large > > configurations. > > This should read /etc/cobbler/modules.conf. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From lnitz at hawaii.edu Sun Oct 21 06:11:15 2007 From: lnitz at hawaii.edu (Lawrence Nitz) Date: Sat, 20 Oct 2007 20:11:15 -1000 Subject: [et-mgmt-tools] Re: Virt-manager: 5.0, 5.1, 5.2 fail in, Fedora 7 In-Reply-To: <20071020160025.3944273185@hormel.redhat.com> References: <20071020160025.3944273185@hormel.redhat.com> Message-ID: <471AED83.2090706@hawaii.edu> et-mgmt-tools-request at redhat.com wrote: > Send et-mgmt-tools mailing list submissions to > et-mgmt-tools at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > or, via email, send a message with subject or body 'help' to > et-mgmt-tools-request at redhat.com > > You can reach the person managing the list at > et-mgmt-tools-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of et-mgmt-tools digest..." > > > Today's Topics: > > 1. What's new in Cobbler development lately (Michael DeHaan) > 2. Re: What's new in Cobbler development lately (Michael DeHaan) > 3. Re: Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 > (Lawrence H Nitz) > 4. Re: Re: Virt-manager: 5.0, 5.1, 5.2 fail in Fedora 7 > (Hugh O. Brock) > 5. Re: What's new in Cobbler development lately (Aaron Lippold) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 19 Oct 2007 17:03:19 -0400 > From: Michael DeHaan > Subject: [et-mgmt-tools] What's new in Cobbler development lately > To: "'et-mgmt-tools at redhat.com'" > Message-ID: <47191B97.2010401 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > A few things of interest to a few people.... There are still a few > things upstream that I want to get done before pushing 0.6.3 out. > However, it's worth talking about what is already there, in case anyone > is interested in those features and would like to play with/test them > now. > > First off -- performance upgrades. Cobbler does great now with an > average number of records, but performance with a very large number of > systems in the "database" could be better. By switching all serializers > (except settings) to serializer_shelve in /etc/cobbler/auth.conf, > cobbler gets a lot faster for very large configurations. This is > because changes to the cobbler "database" can be made without > reading/writing the whole file. I'm still undecided as to whether > this should > be the default for new Cobbler installs, but there will be a script to > migrate users between formats for those that have existing > configurations. With the new code, it's possible > to run a "cobbler list" command and see 5000 entries come back in 2 > seconds -- before, YAML parsing/loading would have made storing a config > that large in YAML somewhat painful. Currently this is using BSD-DB > (which some of you said is scary, fair enough), though we could also use > gddb. I've tested both and performance is identical. sqlite is > possible, but maybe not needed. You can read more here: > https://hosted.fedoraproject.org/projects/cobbler/wiki/AlternativeSerializers > > Second -- there was a request to extend the idea of Cobbler triggers ( > https://hosted.fedoraproject.org/projects/cobbler/wiki/CobblerTriggers ) > to support a "sync" trigger. We have that now. For instance, now we > have the service-restart code as a trigger. So by default it will > restart dhcpd/dnsmasq after a cobbler sync if you have DHCP management > turned on. If you don't, it does nothing. However, suppose you wanted > Cobbler to push out DHCP configurations to multiple servers? No > problem! Now you can modify the trigger yourself and make it do > whatever you want, all without modifying Cobbler code. > > Both making things more modular (for arbitrary user extensibility) and > making things scale for extremely large configurations will definitely > be an ongoing focus for subsequent releases. > > If you're interested in any of the above, check out the git version > control repo. > > --Michael > > > > ------------------------------ > > Message: 2 > Date: Fri, 19 Oct 2007 17:05:29 -0400 > From: Michael DeHaan > Subject: Re: [et-mgmt-tools] What's new in Cobbler development lately > To: Fedora/Linux Management Tools > Message-ID: <47191C19.9040402 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Michael DeHaan wrote: > >> By switching all serializers (except settings) to serializer_shelve in >> /etc/cobbler/auth.conf, cobbler gets a lot faster for very large >> configurations. >> > > This should read /etc/cobbler/modules.conf. > > > > ------------------------------ > > Message: 3 > Date: Fri, 19 Oct 2007 11:16:56 -1000 > From: Lawrence H Nitz > Subject: [et-mgmt-tools] Re: Virt-manager: 5.0, 5.1, 5.2 fail in > Fedora 7 > To: et-mgmt-tools at redhat.com > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Thanks for the kind responses. > > I think there may be other problems, since I do not see any create buttons in any portion of my 0.5.2 virt-manager screen. I may have contaminated the installation in moving from one release to another. I suspect that the python archive called in the program may be ruined. > > Is there a straightforward way to uninstall all of the virt-manager directories, so that I can do a truly clean install? > Thanks, Larry Nitz > > > > ------------------------------ > > Message: 4 > Date: Fri, 19 Oct 2007 17:26:31 -0400 > From: "Hugh O. Brock" > Subject: Re: [et-mgmt-tools] Re: Virt-manager: 5.0, 5.1, 5.2 fail in > Fedora 7 > To: Fedora/Linux Management Tools > Message-ID: <20071019212631.GI15667 at redhat.com> > Content-Type: text/plain; charset=us-ascii > > On Fri, Oct 19, 2007 at 11:16:56AM -1000, Lawrence H Nitz wrote: > >> Thanks for the kind responses. >> >> I think there may be other problems, since I do not see any create buttons in any portion of my 0.5.2 virt-manager screen. I may have contaminated the installation in moving from one release to another. I suspect that the python archive called in the program may be ruined. >> >> Is there a straightforward way to uninstall all of the virt-manager directories, so that I can do a truly clean install? >> > > Are you running virt-manager as root? The UI won't show a create > button unless the connection to your hypervisor is fully > privileged. Speaking of which, are you using the Xen hypervisor, or > KVM? And, do you see any guests you have previously defined (if you > defined any)? > > --Hugh > > > > ------------------------------ > > Message: 5 > Date: Fri, 19 Oct 2007 21:48:38 -0400 > From: "Aaron Lippold" > Subject: Re: [et-mgmt-tools] What's new in Cobbler development lately > To: "Fedora/Linux Management Tools" > Message-ID: > <39d2723b0710191848j3ddc224eg29f17aef69f9b3a at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Mike and gang, > > These sound like some great enhancements. I was hoping the list and > yourself might help me work out some things. > > I am going to be putting together a new infrastructure for the open > source group at my organization and I was thinking about setting up a > virt enviroment for my production services. Webserver, > development/project enviroment - i.e. svn, bugs, tickets, etc. most > likely trac or sourceforge - a gnumailman service, etc. I was thinking > that, if I did this, it might be smart to double up in a kind of virt > HA setup. Do you know anyone who has setup this type of thing and how > they are succeeding with it. > > Also, for my testing and pre-deployment I was going to use another > virt env. This most likely wouldn't have to be HA. > > I, of course, was going to use virt-manager to help manage this setup. > Thoughts? Suggestions? > > Specifically what level of hardware would really be needed for a > medium load - 10-15 projects - 100 general users etc. I was thinking > about a 2 cpu dual or quad core setup with a SAN for the virt images > etc. This would be the first deployment of an infrastructure which was > virt rather than individual systems. Thoughts? > > Thanks, > > Aaron > > > > On 10/19/07, Michael DeHaan wrote: > >> Michael DeHaan wrote: >> >>> By switching all serializers (except settings) to serializer_shelve in >>> /etc/cobbler/auth.conf, cobbler gets a lot faster for very large >>> configurations. >>> >> This should read /etc/cobbler/modules.conf. >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > > > ------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > End of et-mgmt-tools Digest, Vol 14, Issue 27 > ********************************************* > Thank, Hugh! I opened virt-manager explicitly from a root terminal window this evening. Once I connect to the Xen hypervisor, I can see two machines that I made last week, and have the Open and Detatils buttons on the bottom right of the main screen. There is no Create button, even though I am running as root. I have options of Run, Pause, Shutdown, Details, Open in the right mouse button click over the machines. I can open and start either of the two machines, and the machines show cpu and memory usage, but without a window in which to see the execution. I cannot bring up a response to the Details menu option on any of the machines-- Domain-0 or the two guests I had created. From hbrock at redhat.com Mon Oct 22 13:28:01 2007 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 22 Oct 2007 09:28:01 -0400 Subject: [et-mgmt-tools] Re: Virt-manager: 5.0, 5.1, 5.2 fail in, Fedora 7 In-Reply-To: <471AED83.2090706@hawaii.edu> References: <20071020160025.3944273185@hormel.redhat.com> <471AED83.2090706@hawaii.edu> Message-ID: <20071022132801.GL15667@redhat.com> On Sat, Oct 20, 2007 at 08:11:15PM -1000, Lawrence Nitz wrote: > > > Thank, Hugh! > I opened virt-manager explicitly from a root terminal window this > evening. Once I connect to the Xen hypervisor, I can see two machines > that I made last week, and have the Open and Detatils buttons on the > bottom right of the main screen. There is no Create button, even though > I am running as root. > > I have options of Run, Pause, Shutdown, Details, Open in the right mouse > button click over the machines. I can open and start either of the two > machines, and the machines show cpu and memory usage, but without a > window in which to see the execution. > > I cannot bring up a response to the Details menu option on any of the > machines-- Domain-0 or the two guests I had created. > Interesting, something is definitely not right. Do you see anything in /root/.virt-manager/virt-manager.log? Also, what do you see when you run virt-manager as root with the --no-fork option from the command line? Finally, what versions of virtinst and libvirt are you using? Thanks, --Hugh From rigg0022 at umn.edu Mon Oct 22 16:44:18 2007 From: rigg0022 at umn.edu (Riggs, Ben) Date: Mon, 22 Oct 2007 11:44:18 -0500 Subject: [et-mgmt-tools] Koan traceback with cobbler 0.6.3-1 (from git today) Message-ID: <471CD362.7010609@umn.edu> http://cobbler.pastebin.com/m477428e1 [root@ ~]# koan --server=artemis --display Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/koan/app.py", line 181, in main k.run() File "/usr/lib/python2.5/site-packages/koan/app.py", line 348, in run self.system = self.autodetect_system() File "/usr/lib/python2.5/site-packages/koan/app.py", line 385, in autodetect_system detectedsystem = [system['name'] for system in data if system['mac_address'].upper() == mac.upper()] KeyError: 'mac_address' From Riggs at artemis.math.umn.edu Mon Oct 22 17:33:32 2007 From: Riggs at artemis.math.umn.edu (Riggs at artemis.math.umn.edu) Date: Mon, 22 Oct 2007 12:33:32 -0500 Subject: [et-mgmt-tools] [PATCH] Fixed for the case when dhcp is turned off. Message-ID: <11930744124126-git-send-email-rigg0022@umn.edu> From: Ben Riggs --- triggers/restart-services.trigger | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/triggers/restart-services.trigger b/triggers/restart-services.trigger index 98d478b..6a44500 100644 --- a/triggers/restart-services.trigger +++ b/triggers/restart-services.trigger @@ -17,5 +17,7 @@ if manage_dhcp != "0": else: print "- error: unknown DHCP engine: %s" % manage_dhcp_mode rc = 411 +else: + rc = "" sys.exit(rc) -- 1.5.2.4 From lippold at gmail.com Mon Oct 22 20:11:40 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 22 Oct 2007 16:11:40 -0400 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? Message-ID: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> Hi All, Reposted this since it got burried in another posing conversation....- I am going to be putting together a new infrastructure for the open source group at my organization and I was thinking about setting up a virt environment for my production services. Webserver, development/project environment - i.e. svn, bugs, tickets, etc. most likely trac or source forge - a gnu mailman service, etc. I was thinking that, if I did this, it might be smart to double up in a kind of virt HA setup. Do you know anyone who has setup this type of thing and how they are succeeding with it. Also, for my testing and pre-deployment I was going to use another virt env. This most likely wouldn't have to be HA. I, of course, was going to use virt-manager to help manage this setup. Thoughts? Suggestions? Specifically what level of hardware would really be needed for a medium load - 10-15 projects - 100 general users etc. I was thinking about a 2 cpu dual or quad core setup with a SAN for the virt images etc. This would be the first deployment of an infrastructure which was virt rather than individual systems. Thoughts? Thanks, Aaron From lnitz at hawaii.edu Tue Oct 23 05:39:29 2007 From: lnitz at hawaii.edu (Lawrence Nitz) Date: Mon, 22 Oct 2007 19:39:29 -1000 Subject: [et-mgmt-tools] Re: Re: Virt-manager: 5.0, 5.1, 5.2 fail in, Fedora 7 In-Reply-To: <20071022160023.A870973608@hormel.redhat.com> References: <20071022160023.A870973608@hormel.redhat.com> Message-ID: <471D8911.6000505@hawaii.edu> et-mgmt-tools-request at redhat.com wrote: > Send et-mgmt-tools mailing list submissions to > et-mgmt-tools at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > or, via email, send a message with subject or body 'help' to > et-mgmt-tools-request at redhat.com > > You can reach the person managing the list at > et-mgmt-tools-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of et-mgmt-tools digest..." > > > Today's Topics: > > 1. Re: Re: Virt-manager: 5.0, 5.1, 5.2 fail in, Fedora 7 > (Hugh O. Brock) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Oct 2007 09:28:01 -0400 > From: "Hugh O. Brock" > Subject: Re: [et-mgmt-tools] Re: Virt-manager: 5.0, 5.1, 5.2 fail in, > Fedora 7 > To: Fedora/Linux Management Tools > Message-ID: <20071022132801.GL15667 at redhat.com> > Content-Type: text/plain; charset=us-ascii > > On Sat, Oct 20, 2007 at 08:11:15PM -1000, Lawrence Nitz wrote: > >>> >>> >> Thank, Hugh! >> I opened virt-manager explicitly from a root terminal window this >> evening. Once I connect to the Xen hypervisor, I can see two machines >> that I made last week, and have the Open and Detatils buttons on the >> bottom right of the main screen. There is no Create button, even though >> I am running as root. >> >> I have options of Run, Pause, Shutdown, Details, Open in the right mouse >> button click over the machines. I can open and start either of the two >> machines, and the machines show cpu and memory usage, but without a >> window in which to see the execution. >> >> I cannot bring up a response to the Details menu option on any of the >> machines-- Domain-0 or the two guests I had created. >> >> > > Interesting, something is definitely not right. Do you see anything in > /root/.virt-manager/virt-manager.log? Also, what do you see when you > run virt-manager as root with the --no-fork option from the command > line? Finally, what versions of virtinst and libvirt are you using? > > Thanks, > --Hugh > > > > ------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > End of et-mgmt-tools Digest, Vol 14, Issue 29 > ********************************************* > 1.Virt-install version virtinst-0.300-1.tar 2. Libvirt libvirt-python -0.3.3-1.x86_64.rpm 3. libvirt-devel-0.3.3-1.x86_64.rpm In Log, 18 Oct: Cannot find gtkvnc. gtk-vnc-python-0.2.0-2.fc7.x86-64 installed already t the beginning of my session this evening, I installed the gtk-vnc-devel version from the Red Hat installer's archive. Response to virt-manager --no-fork Attempt to open one of the displayed systems gives the window for the machine, then this error prompt. "Enable the local advanced programmable interrupt controller (APIC0. The X64-b ased operating system you are loding does not have APIC enabled. The x64-based operating system yo are loding does not have APIC enab led. Check the system's firmware settings and make sure the firmware has enabled APIC on this system............" {I did not see this on the virt-manager opened without the --no-fork option earlier, but I saw no working screen for installing the client os.} Virt-manager-log2 was collected using the --no-forks option. Using it, I could randomly see my existing VM machines, and could open one, but it had no network connectivity--ip numbers were given in hex, like mac addresses. Attempting to run or open all the other existing virtual machines (some defined only as far as setting up the machine's file) caused the virt-manager to immediately bomb. The logs here are pretty complex. As far as I can tell, I should not use any specification of 2 processors for a VM. There is some issue with the network, but I cannot determine what it is. Finally, I have included my last virt-manager no-fork traceback as it spooled on the root terminal. In this run, there were no bombs, but the windows for the VM systems did not open. I am sorry that I cannot be more clear, but it is very hard for me to tell what is happening across the processes that are running. Larry Nitz -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtmanager_nofork_output.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager.log Type: text/x-log Size: 32505 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-log2 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-nofork-traceback URL: From rjones at redhat.com Tue Oct 23 10:26:34 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 23 Oct 2007 11:26:34 +0100 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> Message-ID: <471DCC5A.5070209@redhat.com> Aaron Lippold wrote: > Hi All, > > Reposted this since it got burried in another posing conversation....- > > I am going to be putting together a new infrastructure for the open > source group at my organization and I was thinking about setting up a > virt environment for my production services. Webserver, > development/project environment - i.e. svn, bugs, tickets, etc. most > likely trac or source forge - a gnu mailman service, etc. I was thinking > that, if I did this, it might be smart to double up in a kind of virt > HA setup. Do you know anyone who has setup this type of thing and how > they are succeeding with it. At my last company I set up such a system and it has been running for over 18 months now. (It was based on a very early Xen 3.0, upgraded several times since). Also plenty of hosting companies are running Xen. For example, http://www.bytemark.co.uk/page/Live/support/tech/dedicated/xen_setup to name one of many. We found virtualisation made a great solution for isolating different servers from each other. We had previously had a problem where our Apache required so many different modules to support the various different services we were running that the Apache config became extremely fragile. No such problem with Xen however since we just ran different Apache instances on different guests, with a web accelerator in front of them (a stripped down Apache with mod_proxy) so that all the backend Apaches would appear on the same IP address. You could reboot a backend server easily if it failed without affecting any other production service. > Also, for my testing and pre-deployment I was going to use another > virt env. This most likely wouldn't have to be HA. > > I, of course, was going to use virt-manager to help manage this setup. > Thoughts? Suggestions? Of course. You may also find that the command line tool (virsh) gives you more flexibility to script actions. And you can use libvirt directly for automation. The advantage of using libvirt is that you aren't tying yourself to Xen. > Specifically what level of hardware would really be needed for a > medium load - 10-15 projects - 100 general users etc. I was thinking > about a 2 cpu dual or quad core setup with a SAN for the virt images > etc. This would be the first deployment of an infrastructure which was > virt rather than individual systems. Thoughts? I think one of the mistakes people make is to think that virtualisation magically enables you to save resources. Like, I can P2V this big stack of servers onto a single box and everything will run fine. It's not the case. Xen doesn't overcommit physical RAM, so if each server requires 1 GB of RAM, and you have 8 servers, then you will need 8 * 1 GB of RAM plus a bit extra for the management domain (dom0), so in practice at least 8.5 GB of RAM. Each operating system install needs just as much disk space as you would normally allocate. So again you will end up multiplying the space required by each OS, by the number of guests. You have a little more flexibility with CPU because you can overcommit here. If your CPU requirements are low (most boxes are idle most of the time) then you'll be fine, but if you expect that some boxes will consume significant CPU, then you can pin those to dedicated cores and have extra cores left over to handle the rest of the work. Oh and for HA, you'll need two of these boxes at least since if a Xen server fails it could literally take out your whole business. SANs help here because they allow you to migrate workloads around easily. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Tue Oct 23 10:32:49 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 23 Oct 2007 11:32:49 +0100 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <471DCC5A.5070209@redhat.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> Message-ID: <471DCDD1.20107@redhat.com> Richard W.M. Jones wrote: > We found virtualisation made a great solution for isolating different > servers from each other. We had previously had a problem where our > Apache required so many different modules to support the various > different services we were running that the Apache config became > extremely fragile. No such problem with Xen however since we just ran > different Apache instances on different guests, with a web accelerator > in front of them (a stripped down Apache with mod_proxy) so that all the > backend Apaches would appear on the same IP address. You could reboot a > backend server easily if it failed without affecting any other > production service. I should add that if you do consider an Apache configuration like the above, then this little module is an absolute life-saver: http://stderr.net/apache/rpaf/ Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From crobinso at redhat.com Tue Oct 23 13:51:15 2007 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 23 Oct 2007 09:51:15 -0400 Subject: [et-mgmt-tools] [PATCH] Fix virt-install iso path validation (BZ 249424) In-Reply-To: <4717CB3A.3000604@redhat.com> References: <4717CB3A.3000604@redhat.com> Message-ID: <471DFC53.50900@redhat.com> Cole Robinson wrote: > This patch builds a VirtualDisk object using the cdrom path passed to > virt-install to reuse the already present validation. It also touches up > some of the error messages the VirtualDisk throws to make them more > general specific. This solves bz 249424. > > - Cole > > > If there is no objections to this then I'll apply it. Thanks, Cole -- Cole Robinson crobinso at redhat.com From hbrock at redhat.com Tue Oct 23 13:59:30 2007 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 23 Oct 2007 09:59:30 -0400 Subject: [et-mgmt-tools] [PATCH] Fix virt-install iso path validation (BZ 249424) In-Reply-To: <471DFC53.50900@redhat.com> References: <4717CB3A.3000604@redhat.com> <471DFC53.50900@redhat.com> Message-ID: <20071023135926.GM15667@redhat.com> On Tue, Oct 23, 2007 at 09:51:15AM -0400, Cole Robinson wrote: > Cole Robinson wrote: > > This patch builds a VirtualDisk object using the cdrom path passed to > > virt-install to reuse the already present validation. It also touches up > > some of the error messages the VirtualDisk throws to make them more > > general specific. This solves bz 249424. > > > > - Cole > > > > > > > > If there is no objections to this then I'll apply it. > +1 looks fine to me... --H From mdehaan at redhat.com Tue Oct 23 14:09:32 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 23 Oct 2007 10:09:32 -0400 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <471DCC5A.5070209@redhat.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> Message-ID: <471E009C.8030406@redhat.com> Richard W.M. Jones wrote: > Aaron Lippold wrote: >> Hi All, >> >> Reposted this since it got burried in another posing conversation....- >> >> I am going to be putting together a new infrastructure for the open >> source group at my organization and I was thinking about setting up a >> virt environment for my production services. Webserver, >> development/project environment - i.e. svn, bugs, tickets, etc. most >> likely trac or source forge - a gnu mailman service, etc. I was thinking >> that, if I did this, it might be smart to double up in a kind of virt >> HA setup. Do you know anyone who has setup this type of thing and how >> they are succeeding with it. > > At my last company I set up such a system and it has been running for > over 18 months now. (It was based on a very early Xen 3.0, upgraded > several times since). Also plenty of hosting companies are running > Xen. For example, > http://www.bytemark.co.uk/page/Live/support/tech/dedicated/xen_setup > to name one of many. > To add to all the good stuff Rich shared -- I know there are several folks on this list using Xen in cluster type setups too that may be able to share details. Also, Fedora Infrastructure uses Xen fairly heavily for build systems and other tasks. If you'd like to speak with those folks, stop by #fedora-admin on irc.freenode.net or email fedora-infrastructure-list at redhat.com ... I'm sure they would be glad to share what they are doing also. --Michael From sberkley at mcclatchyinteractive.com Tue Oct 23 14:10:47 2007 From: sberkley at mcclatchyinteractive.com (Simeon Berkley) Date: Tue, 23 Oct 2007 10:10:47 -0400 Subject: [et-mgmt-tools] [PATCH] Fixed for the case when dhcp is turned off. In-Reply-To: <11930744124126-git-send-email-rigg0022@umn.edu> References: <11930744124126-git-send-email-rigg0022@umn.edu> Message-ID: <471E00E7.4090302@mcclatchyinteractive.com> I tried the patch and it still errored out until I changed the 'rc = ""' to 'rc = 0'. I'm brand new to cobbler (and a green python scripter) so I may not know what I'm tinkering with though ;-). Riggs at artemis.math.umn.edu wrote: > From: Ben Riggs > > --- > triggers/restart-services.trigger | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/triggers/restart-services.trigger b/triggers/restart-services.trigger > index 98d478b..6a44500 100644 > --- a/triggers/restart-services.trigger > +++ b/triggers/restart-services.trigger > @@ -17,5 +17,7 @@ if manage_dhcp != "0": > else: > print "- error: unknown DHCP engine: %s" % manage_dhcp_mode > rc = 411 > +else: > + rc = "" > > sys.exit(rc) -- S i m e o n B e r k l e y Systems Engineer Mcclatchy Interactive From mdehaan at redhat.com Tue Oct 23 14:15:55 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 23 Oct 2007 10:15:55 -0400 Subject: [et-mgmt-tools] Koan traceback with cobbler 0.6.3-1 (from git today) In-Reply-To: <471CD362.7010609@umn.edu> References: <471CD362.7010609@umn.edu> Message-ID: <471E021B.40802@redhat.com> Riggs, Ben wrote: > http://cobbler.pastebin.com/m477428e1 > > [root@ ~]# koan --server=artemis --display > Traceback (most recent call last): > File "/usr/lib/python2.5/site-packages/koan/app.py", line 181, in main > k.run() > File "/usr/lib/python2.5/site-packages/koan/app.py", line 348, in run > self.system = self.autodetect_system() > File "/usr/lib/python2.5/site-packages/koan/app.py", line 385, in > autodetect_system > detectedsystem = [system['name'] for system in data if > system['mac_address'].upper() == mac.upper()] > KeyError: 'mac_address' > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Ah. The autodetect_systems patch needs some new changes to deal with the multiple NIC support. Thanks, I'll take a look at it. --Michael From lippold at gmail.com Tue Oct 23 18:18:20 2007 From: lippold at gmail.com (Aaron Lippold) Date: Tue, 23 Oct 2007 14:18:20 -0400 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <471DCDD1.20107@redhat.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> <471DCDD1.20107@redhat.com> Message-ID: <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> Hi, Thanks so much for the thoughts. So, I would assume then that a 'Xen production env' has advantages not really in quote unquote consolidation but flexibility? What's the one line ROI then to the management in your opinion? A On 10/23/07, Richard W.M. Jones wrote: > Richard W.M. Jones wrote: > > We found virtualisation made a great solution for isolating different > > servers from each other. We had previously had a problem where our > > Apache required so many different modules to support the various > > different services we were running that the Apache config became > > extremely fragile. No such problem with Xen however since we just ran > > different Apache instances on different guests, with a web accelerator > > in front of them (a stripped down Apache with mod_proxy) so that all the > > backend Apaches would appear on the same IP address. You could reboot a > > backend server easily if it failed without affecting any other > > production service. > > I should add that if you do consider an Apache configuration like the > above, then this little module is an absolute life-saver: > > http://stderr.net/apache/rpaf/ > > Rich. > > -- > Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in > England and Wales under Company Registration No. 03798903 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From mdehaan at redhat.com Tue Oct 23 18:34:22 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 23 Oct 2007 14:34:22 -0400 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> <471DCDD1.20107@redhat.com> <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> Message-ID: <471E3EAE.4030708@redhat.com> Aaron Lippold wrote: > Hi, > > Thanks so much for the thoughts. So, I would assume then that a 'Xen > production env' has advantages not really in quote unquote > consolidation but flexibility? Consolidation and resource utilization can be valuable -- especially when existing apps are originally speced out to run on different boxes and there's no reason they need that much hardware. There are also the hardware isolation / QA advantages. > What's the one line ROI then to the > management in your opinion? > > I want to help, but I don't speak MBA-language :) > A > > On 10/23/07, Richard W.M. Jones wrote: > >> Richard W.M. Jones wrote: >> >>> We found virtualisation made a great solution for isolating different >>> servers from each other. We had previously had a problem where our >>> Apache required so many different modules to support the various >>> different services we were running that the Apache config became >>> extremely fragile. No such problem with Xen however since we just ran >>> different Apache instances on different guests, with a web accelerator >>> in front of them (a stripped down Apache with mod_proxy) so that all the >>> backend Apaches would appear on the same IP address. You could reboot a >>> backend server easily if it failed without affecting any other >>> production service. >>> >> I should add that if you do consider an Apache configuration like the >> above, then this little module is an absolute life-saver: >> >> http://stderr.net/apache/rpaf/ >> >> Rich. >> >> -- >> Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ >> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod >> Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in >> England and Wales under Company Registration No. 03798903 >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From tomg at mcclatchyinteractive.com Tue Oct 23 19:36:20 2007 From: tomg at mcclatchyinteractive.com (Tom Georgoulias) Date: Tue, 23 Oct 2007 15:36:20 -0400 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> <471DCDD1.20107@redhat.com> <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> Message-ID: <471E4D34.3060802@mcclatchyinteractive.com> Aaron Lippold wrote: > What's the one line ROI then to the > management in your opinion? IMO the one line ROI is "The jury is still out." There are definite pros/cons with virtualization and whether or not it saves you money and/or improves your system platform really depends on what you are doing now, how you implement virtualization, and what the expectations are. You certainly need beefier servers (more RAM, CPUs, etc.) if you plan to run multiple VMs, and since you are probably going to be asked to use fewer servers then the servers you do use will need to be pretty robust/dependable. That costs money. Also, taking one physical server offline actually takes multiple virtual servers offline, which means you need either flexibility in scheduling maintenance outages (or patience from users when you have system crashes) or rely upon the migration capabilities of VMs. If migrations are the answer, then the storage component is really critical because you need some shared storage technology (like SAN) that all of your physical servers have access to. All of this stuff takes planning and consideration, and getting the design right is important. Tom From lippold at gmail.com Tue Oct 23 19:46:07 2007 From: lippold at gmail.com (Aaron Lippold) Date: Tue, 23 Oct 2007 15:46:07 -0400 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <471E4D34.3060802@mcclatchyinteractive.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> <471DCDD1.20107@redhat.com> <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> <471E4D34.3060802@mcclatchyinteractive.com> Message-ID: <39d2723b0710231246w6c38652ak4ebc2ca79c5e1c10@mail.gmail.com> I totally agree that planning is a big issue - as always. I guess the tipping point for an overall win is still, as you said, in deliberation. On 10/23/07, Tom Georgoulias wrote: > Aaron Lippold wrote: > > What's the one line ROI then to the > > management in your opinion? > > IMO the one line ROI is "The jury is still out." > > There are definite pros/cons with virtualization and whether or not it > saves you money and/or improves your system platform really depends on > what you are doing now, how you implement virtualization, and what the > expectations are. > > You certainly need beefier servers (more RAM, CPUs, etc.) if you plan to > run multiple VMs, and since you are probably going to be asked to use > fewer servers then the servers you do use will need to be pretty > robust/dependable. That costs money. Also, taking one physical server > offline actually takes multiple virtual servers offline, which means you > need either flexibility in scheduling maintenance outages (or patience > from users when you have system crashes) or rely upon the migration > capabilities of VMs. If migrations are the answer, then the storage > component is really critical because you need some shared storage > technology (like SAN) that all of your physical servers have access to. > > All of this stuff takes planning and consideration, and getting the > design right is important. > > Tom > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From ecraymond at gmail.com Tue Oct 23 22:35:31 2007 From: ecraymond at gmail.com (Eric Raymond) Date: Tue, 23 Oct 2007 15:35:31 -0700 Subject: [et-mgmt-tools] Traceback on system add and distro import Message-ID: <9401dd450710231535x179e6fa7i5b44f79f9002b116@mail.gmail.com> Hello All, I am not sure what exactly happened, but it definitely seems like threading issue went wrong. I was importing a distro and during that time, I also added a system, but the newly added system was not using the currently importing distro or profile. The import bombed out with memory corruption error. Then I tried to recover but found that I kept getting traceback errors whenever i ran any cobbler command. I have rebooted, and still cobbler is not able to run now. Before I blow away my installation and try again any suggestions? Here is the full traceback: [root at kickstart ~]# cobbler sync Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 713, in main BootCLI(sys.argv).run() File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 42, in __init__ self.api = api.BootAPI() File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 43, in __init__ self.deserialize() File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 227, in deserialize return self._config.deserialize() File "/usr/lib/python2.4/site-packages/cobbler/config.py", line 170, in deserialize if not serializer.deserialize(x,topological=True): File "/usr/lib/python2.4/site-packages/cobbler/serializer.py", line 45, in deserialize return storage_module.deserialize(obj,topological) File "/usr/lib/python2.4/site-packages/cobbler/modules/serializer_yaml.py", line 82, in deserialize datastruct = yaml.load(data).next() # first record File "/usr/lib/python2.4/site-packages/cobbler/yaml/load.py", line 83, in next self.nestedDocs.nestToNextLine() File "/usr/lib/python2.4/site-packages/cobbler/yaml/stream.py", line 131, in nestToNextLine indentation = indentLevel(line) File "/usr/lib/python2.4/site-packages/cobbler/yaml/stream.py", line 6, in indentLevel while n < len(line) and line[n] == ' ': TypeError: len() of unsized object Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rigg0022 at umn.edu Tue Oct 23 22:45:26 2007 From: rigg0022 at umn.edu (Riggs, Ben) Date: Tue, 23 Oct 2007 17:45:26 -0500 Subject: [et-mgmt-tools] Traceback on system add and distro import In-Reply-To: <9401dd450710231535x179e6fa7i5b44f79f9002b116@mail.gmail.com> References: <9401dd450710231535x179e6fa7i5b44f79f9002b116@mail.gmail.com> Message-ID: <471E7986.8010802@umn.edu> The data files for cobbler are currently written in yaml. Yaml is very, very picky and one of your yaml files got borked. Move the files in /var/lib/cobbler individually and try '> cobbler list' to find out which one is broken. As an aside, posting a traceback in an IRC channel is bad. Check out cobbler.pastebin.com for future reference. Ben Eric Raymond wrote: > Hello All, > > I am not sure what exactly happened, but it definitely seems like > threading issue went wrong. I was importing a distro and during that > time, I also added a system, but the newly added system was not using > the currently importing distro or profile. The import bombed out with > memory corruption error. Then I tried to recover but found that I kept > getting traceback errors whenever i ran any cobbler command. I have > rebooted, and still cobbler is not able to run now. Before I blow away > my installation and try again any suggestions? > > Here is the full traceback: > > [root at kickstart ~]# cobbler sync > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 713, > in main > BootCLI( sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 42, > in __init__ > self.api = api.BootAPI() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 43, in > __init__ > self.deserialize() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 227, in > deserialize > return self._config.deserialize() > File "/usr/lib/python2.4/site-packages/cobbler/config.py", line 170, > in deserialize > if not serializer.deserialize(x,topological=True): > File "/usr/lib/python2.4/site-packages/cobbler/serializer.py", line > 45, in deserialize > return storage_module.deserialize(obj,topological) > File > "/usr/lib/python2.4/site-packages/cobbler/modules/serializer_yaml.py", > line 82, in deserialize > datastruct = yaml.load(data).next() # first record > File "/usr/lib/python2.4/site-packages/cobbler/yaml/load.py", line 83, > in next > self.nestedDocs.nestToNextLine() > File "/usr/lib/python2.4/site-packages/cobbler/yaml/stream.py", line > 131, in nestToNextLine > indentation = indentLevel(line) > File "/usr/lib/python2.4/site-packages/cobbler/yaml/stream.py", line > 6, in indentLevel > while n < len(line) and line[n] == ' ': > TypeError: len() of unsized object > > Thanks, > > Eric > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From fj0588di at aa.jp.fujitsu.com Wed Oct 24 06:10:52 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Wed, 24 Oct 2007 15:10:52 +0900 Subject: [et-mgmt-tools] [PATCH] bugzillaID:329091 In-Reply-To: <20071017180016.GG27466@redhat.com> References: <200710160618.l9G6I6Xl010227@fjmscan503.ms.jp.fujitsu.com> <200710161541.BGJ65120.E06J9K9G@aa.jp.fujitsu.com> <200710161609.CAE43776.6EJ0G99K@aa.jp.fujitsu.com> <47164B11.8080307@redhat.com> <20071017180016.GG27466@redhat.com> Message-ID: <200710241510.FGB17176.99JE6G0K@aa.jp.fujitsu.com> > On Wed, Oct 17, 2007 at 01:49:05PM -0400, Cole Robinson wrote: > > S.Sakamoto wrote: > > > Hi > > > > > > I make a patch of BugzillaID-329091. > > > https://bugzilla.redhat.com/show_bug.cgi?id=329091 > > > > > > Thanks, > > > Shigeki Sakamoto. > > > > > > ---------------------------------------------------------------------- > > > diff -r 531b73491ac2 virt-install > > > --- a/virt-install Wed Oct 10 14:24:48 2007 -0400 > > > +++ b/virt-install Tue Oct 16 16:01:29 2007 +0900 > > > @@ -15,6 +15,7 @@ > > > > > > > > > import os, sys, string > > > +from stat import * > > > from optparse import OptionParser, OptionValueError > > > import subprocess > > > import logging > > > @@ -48,10 +49,10 @@ def get_disk(disk, size, sparse, guest, > > > if not size is None: > > > msg = _("Please enter the path to the file you would like to use for storage. It will have size %sGB.") %(size,) > > > disk = cli.prompt_for_input(msg, disk) > > > - if os.path.exists(disk) and os.path.isfile(disk): > > > + if os.path.exists(disk) and ( S_ISBLK(os.stat(disk)[ST_MODE]) or S_ISREG(os.stat(disk)[ST_MODE]) ): > > > while 1: > > > retryFlg = False > > > - warnmsg = _("You are going to overwrite file '%s'!\n") % disk > > > + warnmsg = _("You are going to overwrite '%s'!\n") % disk > > > res = cli.prompt_for_input(warnmsg + _("Do you really want to use the file (yes or no)? ")) > > > try: > > > if cli.yes_or_no(res) is True: > > > ---------------------------------------------------------------------- > > > > Hello, > > > > I don't think this is the right approach. From the bug report, I agree > > that we shouldn't make it so easy to ruin a block device without some > > kind of precaution, but the right way to do it would be to have something > > that would require the user to explicitly specify the type of storage > > desired. Such as --file be just for file based storage, and add a --blkdev > > or some such option to specify device based storage. Or maintain --file as > > the storage location and add a --disktype option. > > > > Unfortunately this would break the existing interface, but so would > > this patch, which would require interaction anytime someone wanted > > to specify a device for storage. > > Yep, this is not acceptable. If we force a prompt for all block devices, > then the user will just end up using the override flag all the time, > defeating the purpose of checking. Using a separate --blkdev flag does > not solve the problem either, since they could still easily overwrite > the host filesystem. > > > Anyone else have an opinion on the right direction to go? I think > > having an explicit way to specify storage would be handy anyways. > > Nope, this doesn't solve anything. The problem is that given a block > device path /dev/sdN, there is no easy way to determine if it is already > used in the host. You can check if its mounted, but that's useless of > the volume is used as Swap. It also misses if the device is in fact a > physical volume in LVM. It also misses if the device is setup via dmcrypt. > > It is frankly a loosing battle to try & guess if a device is in use in > the host. Xen does a minimal attempt by looking to see if it is mounted > but that misses the swap & LVM & device mapper scenarios. I don't see us > being able todo any better in virt-install. > > > The only viable long term approach is to develop the libvirt storage APIs, > allowing the admin to explicitly design certain devices as being available > for guest usage ahead of time. That would let virt-install validate paths > given to it for sanity > The check of disk is the same as a check of file, I thought that is good. That is why I have made it such a check. But, I understand that it was not a radical solution of the problem. Sorry, Alteration is taking time. Shigeki Sakamoto. From rjones at redhat.com Wed Oct 24 08:07:28 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 24 Oct 2007 09:07:28 +0100 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> <471DCDD1.20107@redhat.com> <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> Message-ID: <471EFD40.4040004@redhat.com> Aaron Lippold wrote: > Thanks so much for the thoughts. So, I would assume then that a 'Xen > production env' has advantages not really in quote unquote > consolidation but flexibility? What's the one line ROI then to the > management in your opinion? The advantages of virtualisation are really about isolation (one service can't stomp on another) and being able to run lots of different operating systems conveniently, eg. for builds or testing. Lesser advantages are migration and load balancing. No idea about "one line ROI"s. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Wed Oct 24 10:49:32 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 24 Oct 2007 11:49:32 +0100 Subject: [et-mgmt-tools] Re: [Libvir] virt-install : *** glibc detected *** /usr/bin/python: free(): invalid pointer *** *** In-Reply-To: <16314edc0710240113l14fffa75p2e3ca60c2bf54e36@mail.gmail.com> References: <16314edc0710240113l14fffa75p2e3ca60c2bf54e36@mail.gmail.com> Message-ID: <471F233C.1050301@redhat.com> suyash jape wrote: > Hi all > > I am getting the following output when i try to use virt-install > > [root at localhost]# virt-install > *** glibc detected *** /usr/bin/python: free(): invalid pointer: > 0x08bea0a0 *** > ======= Backtrace: ========= > /lib/i686/nosegneg/libc.so.6[0x2f89b1] > /lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x2fc060] > /usr/lib/libvirt.so.0[0xb2885e] > /usr/lib/libvirt.so.0[0xb2a07b] > /usr/lib/libvirt.so.0[0xb019d3] > /usr/lib/python2.5/site-packages/libvirtmod.so(libvirt_virConnectOpen+0x66)[0xf09ce6] > > . > . > . > . > b7d25000-b7f25000 r--p 00000000 fd:00 312403 > /usr/lib/locale/locale-archive > b7f25000-b7fa9000 rw-p b7f25000 00:00 0 > b7fb4000-b7fb5000 rw-p b7fb4000 00:00 0 > bff2a000-bff4a000 rw-p bff2a000 00:00 0 [stack] > Aborted > > My package versions : > > [root at localhost ~]# rpm -qa|grep libvirt > libvirt-0.3.3-1.fc7 > libvirt-python-0.3.3-1.fc7 > > [root at localhost ~]# uname -a > Linux localhost.localdomain 2.6.20-2936.fc7xen #1 SMP Fri Sep 21 > 12:07:35 EDT 2007 i686 i686 i386 GNU/Linux > > [root at localhost ~]# rpm -qa|grep xen > xen-libs-3.1.0-6.fc7 > xen-devel-3.1.0-6.fc7 > xen-3.1.0-6.fc7 > kernel-xen-2.6.20-2936.fc7 > kernel-xen-devel-2.6.20-2936.fc7 > > I have attached the full back trace if anyone is interested > Any suggestions ? I'd definitely be interested in the full stacktrace. Also does this occur with the latest releases (ie. enable the development repo): # rpm -qa | grep xen kernel-xen-2.6.21-2949.fc8 kernel-xen-2.6.21-2942.fc8 kernel-xen-devel-2.6.21-2942.fc8 xen-libs-3.1.0-12.fc8 xen-debuginfo-3.1.0-5.fc8 xen-devel-3.1.0-12.fc8 xen-3.1.0-12.fc8 kernel-xen-devel-2.6.21-2949.fc8 (FYI, virt-install runs fine on the above machine). If you want to pursue this further, then compiling libvirt with the --enable-debug=yes option produces a lot of interesting debugging output, and will allow us to see what actual libvirt calls are being made, plus arguments. ./autogen.sh --enable-debug=yes --prefix=$HOME/local make all install LD_LIBRARY_PATH=$HOME/local/lib virt-install Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mdehaan at redhat.com Wed Oct 24 13:59:33 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 24 Oct 2007 09:59:33 -0400 Subject: [et-mgmt-tools] Traceback on system add and distro import In-Reply-To: <9401dd450710231535x179e6fa7i5b44f79f9002b116@mail.gmail.com> References: <9401dd450710231535x179e6fa7i5b44f79f9002b116@mail.gmail.com> Message-ID: <471F4FC5.9070106@redhat.com> Eric Raymond wrote: > Hello All, > > I am not sure what exactly happened, but it definitely seems like > threading issue went wrong. I was importing a distro and during that > time, I also added a system, but the newly added system was not using > the currently importing distro or profile. The import bombed out with > memory corruption error. Then I tried to recover but found that I kept > getting traceback errors whenever i ran any cobbler command. I have > rebooted, and still cobbler is not able to run now. Before I blow > away my installation and try again any suggestions? Hmmm .... Cobbler isn't threaded. Were you using the WebUI and command line at the same time? Ordinarily that should be ok, though if one were to crash (still not sure why it actually crashed?) while it had not yet finished writing the configuration file, that would be a problem. Do you have a copy of the error (traceback) you could post? Part of the goodness about the new serializer (which very well could become the default) is it should solve the problem of the any sort of error occuring while cobbler is writing the configuration file. With the yaml format, cobbler has to rewrite it's entire configuration file when you save a new object, so if it runs out of disk space. The new serializer is able to insert only the changes. Yes, I would delete your existing /var/lib/cobbler/(distros|profiles|systems|repos) files and let cobbler regenerate them. If you want to back up this directory (/var/lib/cobbler) periodically, it would probably be a good idea. > > Here is the full traceback: > > [root at kickstart ~]# cobbler sync > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 713, in main > BootCLI( sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 42, > in __init__ > self.api = api.BootAPI() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 43, in > __init__ > self.deserialize() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 227, in > deserialize > return self._config.deserialize() > File "/usr/lib/python2.4/site-packages/cobbler/config.py", line 170, > in deserialize > if not serializer.deserialize(x,topological=True): > File "/usr/lib/python2.4/site-packages/cobbler/serializer.py", line > 45, in deserialize > return storage_module.deserialize(obj,topological) > File > "/usr/lib/python2.4/site-packages/cobbler/modules/serializer_yaml.py", > line 82, in deserialize > datastruct = yaml.load(data).next() # first record > File "/usr/lib/python2.4/site-packages/cobbler/yaml/load.py", line > 83, in next > self.nestedDocs.nestToNextLine() > File "/usr/lib/python2.4/site-packages/cobbler/yaml/stream.py", line > 131, in nestToNextLine > indentation = indentLevel(line) > File "/usr/lib/python2.4/site-packages/cobbler/yaml/stream.py", line > 6, in indentLevel > while n < len(line) and line[n] == ' ': > TypeError: len() of unsized object > > Thanks, > > Eric > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Wed Oct 24 18:33:07 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 24 Oct 2007 14:33:07 -0400 Subject: [et-mgmt-tools] Traceback on system add and distro import In-Reply-To: <471F4FC5.9070106@redhat.com> References: <9401dd450710231535x179e6fa7i5b44f79f9002b116@mail.gmail.com> <471F4FC5.9070106@redhat.com> Message-ID: <471F8FE3.1050509@redhat.com> Michael DeHaan wrote: > Eric Raymond wrote: >> Hello All, >> >> I am not sure what exactly happened, but it definitely seems like >> threading issue went wrong. I was importing a distro and during that >> time, I also added a system, but the newly added system was not using >> the currently importing distro or profile. The import bombed out >> with memory corruption error. Then I tried to recover but found that >> I kept getting traceback errors whenever i ran any cobbler command. I >> have rebooted, and still cobbler is not able to run now. Before I >> blow away my installation and try again any suggestions? > > Hmmm .... Cobbler isn't threaded. Were you using the WebUI and > command line at the same time? Ordinarily that should be ok, though > if one were to crash (still not sure why it actually crashed?) while > it had not yet finished writing the configuration file, that would be > a problem. Do you have a copy of the error (traceback) you could post? Apparently I'm blind. I see the traceback and that is most certaintly coming from the parser when it's trying to re-read the file, though I'm curious as to what you meant by "memory corruption error". From ecraymond at gmail.com Wed Oct 24 18:59:09 2007 From: ecraymond at gmail.com (Eric Raymond) Date: Wed, 24 Oct 2007 11:59:09 -0700 Subject: [et-mgmt-tools] Traceback on system add and distro import Message-ID: <9401dd450710241159i3fa29550v1b0cfa3948e8a765@mail.gmail.com> What occurred is that I was using the WebUI to add a system, as well as running an import media command from the command line..apparently I ran out of memory, hence the "memory corruption error" during import, so it probably couldnt allocate anymore resource to finish writing the yaml file and broke it. I will need to slow down my efforts in the future. Eric Michael DeHaan wrote: Eric Raymond wrote: Hello All, I am not sure what exactly happened, but it definitely seems like threading issue went wrong. I was importing a distro and during that time, I also added a system, but the newly added system was not using the currently importing distro or profile. The import bombed out with memory corruption error. Then I tried to recover but found that I kept getting traceback errors whenever i ran any cobbler command. I have rebooted, and still cobbler is not able to run now. Before I blow away my installation and try again any suggestions? Hmmm .... Cobbler isn't threaded. Were you using the WebUI and command line at the same time? Ordinarily that should be ok, though if one were to crash (still not sure why it actually crashed?) while it had not yet finished writing the configuration file, that would be a problem. Do you have a copy of the error (traceback) you could post? Apparently I'm blind. I see the traceback and that is most certaintly coming from the parser when it's trying to re-read the file, though I'm curious as to what you meant by "memory corruption error". -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed Oct 24 19:33:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 24 Oct 2007 15:33:05 -0400 Subject: [et-mgmt-tools] Traceback on system add and distro import In-Reply-To: <9401dd450710241159i3fa29550v1b0cfa3948e8a765@mail.gmail.com> References: <9401dd450710241159i3fa29550v1b0cfa3948e8a765@mail.gmail.com> Message-ID: <471F9DF1.3010207@redhat.com> Eric Raymond wrote: > What occurred is that I was using the WebUI to add a system, as well as running an import media > command from the command line..apparently I ran out of memory, hence the "memory corruption error" during import, so it > > probably couldnt allocate anymore resource to finish writing the yaml file and broke it. > > I will need to slow down my efforts in the future. > As an added measure, I can make the non-read-only Cobbler WebUI commands observe cobbler's command line lock. This seems like it would solve the dual-usage problem. The RAM problem seems unrelated though -- rsync gone haywire, perhaps? > Eric > > Michael DeHaan wrote: > > > Eric Raymond wrote: > > > Hello All, > > > > I am not sure what exactly happened, but it definitely seems > like threading issue went wrong. I was importing a distro and > during that time, I also added a system, but the newly added > system was not using the currently importing distro or > profile. The import bombed out with memory corruption error. > Then I tried to recover but found that I kept getting > traceback errors whenever i ran any cobbler command. I have > rebooted, and still cobbler is not able to run now. Before I > blow away my installation and try again any suggestions? > > Hmmm .... Cobbler isn't threaded. Were you using the WebUI and > command line at the same time? Ordinarily that should be ok, > though if one were to crash (still not sure why it actually > crashed?) while it had not yet finished writing the configuration > file, that would be a problem. Do you have a copy of the error > (traceback) you could post? > > Apparently I'm blind. > > > I see the traceback and that is most certaintly coming from the parser > when it's trying to re-read the file, though I'm curious as to what > you meant by "memory corruption error". > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From lippold at gmail.com Wed Oct 24 21:01:19 2007 From: lippold at gmail.com (Aaron Lippold) Date: Wed, 24 Oct 2007 17:01:19 -0400 Subject: [et-mgmt-tools] Xen 'production' services - are we there yet? In-Reply-To: <471EFD40.4040004@redhat.com> References: <39d2723b0710221311x79a5ee75rf1d381607ac2d690@mail.gmail.com> <471DCC5A.5070209@redhat.com> <471DCDD1.20107@redhat.com> <39d2723b0710231118h3afa5edco9f26bae11451efe0@mail.gmail.com> <471EFD40.4040004@redhat.com> Message-ID: <39d2723b0710241401w327f27dcp12bb5df8948d8776@mail.gmail.com> That's pretty close. A On 10/24/07, Richard W.M. Jones wrote: > Aaron Lippold wrote: > > Thanks so much for the thoughts. So, I would assume then that a 'Xen > > production env' has advantages not really in quote unquote > > consolidation but flexibility? What's the one line ROI then to the > > management in your opinion? > > The advantages of virtualisation are really about isolation (one service > can't stomp on another) and being able to run lots of different > operating systems conveniently, eg. for builds or testing. Lesser > advantages are migration and load balancing. > > No idea about "one line ROI"s. > > Rich. > > -- > Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in > England and Wales under Company Registration No. 03798903 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From mnielsen at redhat.com Fri Oct 26 12:55:55 2007 From: mnielsen at redhat.com (Mark Nielsen) Date: Fri, 26 Oct 2007 08:55:55 -0400 Subject: [et-mgmt-tools] Just joined list - introduction Message-ID: <4721E3DB.8000901@redhat.com> Greetings list, My name is Mark Nielsen, I'm with GPS-FED. My contract is with the FBI in Quantico, VA where we are moving away from the idea of one server per task. We've taken Dell 2950's and have built what we call "service grid" clusters using Cluster Suite and GFS. These service grid nodes do nothing but serve Xen. All production data processing happens inside VMs. These VMs are run as services in Cluster Suite, root disks all from SAN LVMs and can be live-migrated, saved, etc. /etc/xen/ is where the GFS part comes in so each node sees the exact same VM config. That's it in a nutshell, there are some other cool things (like using multiple bonded interfaces with VLANs virtually segregating the various virtualized Cluster Suite clusters... nested clusters :) so if you want more info feel free to e-mail me. I'm introducing myself because sometimes I get the feeling there aren't many people putting all of this stuff together in a production environment. I'm looking for a two-way relationship here :) Help with some of the challenges (how to manage all these VMs properly... virt-factory?) and also because we have 3 clusters: test, production, DR. These allow me the opportunity to do some real testing and file many bugzillas. If there's any testing or feedback you'd like, please let me know. The one caveat is that because it's an FBI network, it's classified :( I can't provide any sort of direct access, but I can import test packages and export log data and other debug information. Any suggestions/advice/criticism is greatly appreciated! Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: mnielsen.vcf Type: text/x-vcard Size: 177 bytes Desc: not available URL: From lippold at gmail.com Fri Oct 26 15:59:21 2007 From: lippold at gmail.com (Aaron Lippold) Date: Fri, 26 Oct 2007 11:59:21 -0400 Subject: [et-mgmt-tools] Just joined list - introduction In-Reply-To: <4721E3DB.8000901@redhat.com> References: <4721E3DB.8000901@redhat.com> Message-ID: <39d2723b0710260859u5d7b2fd4l226655b52e5c9cad@mail.gmail.com> Hi Mark, My name is Aaron Lippold. I am the Project and Technical Lead of the Open Source Steering Group at DISA. I am looking at doing a very similar lay down for my environment. We should chat, since I am currently in the middle of 'building' my configuration now. Yours, Aaron On 10/26/07, Mark Nielsen wrote: > Greetings list, > > My name is Mark Nielsen, I'm with GPS-FED. My contract is with the FBI > in Quantico, VA where we are moving away from the idea of one server per > task. We've taken Dell 2950's and have built what we call "service grid" > clusters using Cluster Suite and GFS. These service grid nodes do > nothing but serve Xen. All production data processing happens inside > VMs. These VMs are run as services in Cluster Suite, root disks all from > SAN LVMs and can be live-migrated, saved, etc. /etc/xen/ is where the > GFS part comes in so each node sees the exact same VM config. That's it > in a nutshell, there are some other cool things (like using multiple > bonded interfaces with VLANs virtually segregating the various > virtualized Cluster Suite clusters... nested clusters :) so if you want > more info feel free to e-mail me. > > I'm introducing myself because sometimes I get the feeling there aren't > many people putting all of this stuff together in a production > environment. I'm looking for a two-way relationship here :) Help with > some of the challenges (how to manage all these VMs properly... > virt-factory?) and also because we have 3 clusters: test, production, > DR. These allow me the opportunity to do some real testing and file many > bugzillas. If there's any testing or feedback you'd like, please let me > know. The one caveat is that because it's an FBI network, it's > classified :( I can't provide any sort of direct access, but I can > import test packages and export log data and other debug information. > > Any suggestions/advice/criticism is greatly appreciated! > > Mark > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From tobert at gmail.com Fri Oct 26 20:39:19 2007 From: tobert at gmail.com (Al Tobey) Date: Fri, 26 Oct 2007 13:39:19 -0700 Subject: [et-mgmt-tools] webui patch to switch to Apache digest (or basic or whatever) auth Message-ID: <5ac7acb10710261339x131e7279yc8e84f42b9f37ab9@mail.gmail.com> This patch removes the pass-through authentication and related forms in favor of using Apache's digest auth (by default). This makes it trivial for people to replace the default in their Apache configuration with mod_auth_ldap, mod_auth_pam, or whatever. It is generated against the latest git, but may apply to 0.6.2 with a little manual fudging. The default username/password in .htaccess is "cobbler/ILoveCobbler". Obviously, you will want to change this. A default was deemed safe to include because the webui is disabled by default. New users can be added using the htdigest command. htdigest /var/www/cgi-bin/cobbler/.htaccess "Cobbler WebUI Authentication" $username Switching to other auth modules is left as an exercise to the user for now, but submissions to the wiki for various modules will be welcomed after 0.6.3 is released. -Al -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Switch-auth-from-pass-through-to-Apache-digest-auth.patch Type: text/x-patch Size: 30520 bytes Desc: not available URL: From mdehaan at redhat.com Fri Oct 26 21:41:30 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 26 Oct 2007 17:41:30 -0400 Subject: [et-mgmt-tools] webui patch to switch to Apache digest (or basic or whatever) auth In-Reply-To: <5ac7acb10710261339x131e7279yc8e84f42b9f37ab9@mail.gmail.com> References: <5ac7acb10710261339x131e7279yc8e84f42b9f37ab9@mail.gmail.com> Message-ID: <47225F0A.1040203@redhat.com> Al Tobey wrote: Excellent! This is the first thing on my list for investigating/merging next week. > This patch removes the pass-through authentication and related forms > in favor of using Apache's digest auth (by default). This makes it > trivial for people to replace the default in their Apache > configuration with mod_auth_ldap, mod_auth_pam, or whatever. It is > generated against the latest git, but may apply to 0.6.2 with a little > manual fudging. > > The default username/password in .htaccess is "cobbler/ILoveCobbler". > Obviously, you will want to change this. A default was deemed safe > to include because the webui is disabled by default. > > New users can be added using the htdigest command. > htdigest /var/www/cgi-bin/cobbler/.htaccess "Cobbler WebUI > Authentication" $username > > Switching to other auth modules is left as an exercise to the user for > now, but submissions to the wiki for various modules will be welcomed > after 0.6.3 is released. > > -Al > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Dan at cdChase.com Sat Oct 27 14:25:36 2007 From: Dan at cdChase.com (C. Daniel Chase) Date: Sat, 27 Oct 2007 10:25:36 -0400 Subject: [et-mgmt-tools] The Missing Arch patch for reposync Message-ID: <47234A60.4060809@cdChase.com> I've been trying to get my local repo to update another architecture (my server is i586 but, it serves my i686 laptop) and from my research in the archives & the commit log, I see that the patch was lost for adding the architecture function. Well, I found it during my research! Here: https://www.redhat.com/archives/et-mgmt-tools/2007-June/msg00057.html I was of course confused due to the documentation describing the support! (I am currently using the Fedora yum version 0.6.2-2.fc7.) But, saw the recent commit: http://git.fedoraproject.org/?p=hosted/cobbler;a=commit;h=460256566c776a8a4f3db71de734049f6dd5baa2 Reversing the doc change saying: "lost a patch somewhere?" Thought I'd help out by letting you know where you lost it! I will be downloading the current source, and trying the patch myself locally to help expedite my solution. If I have to make any changes, I'll contribute an updated patch. Thanks for a great tool! -Dan -- C. Daniel Chase (423) 949-4086 http://cdChase.com/ Get Firefox! http://www.spreadfirefox.com/?q=affiliates&id=58708&t=1 Queensbury High School 1977 30th Reunion http://cdchase.com/QHSReunion/ From Dan at cdChase.com Sat Oct 27 19:20:23 2007 From: Dan at cdChase.com (C. Daniel Chase) Date: Sat, 27 Oct 2007 15:20:23 -0400 Subject: [et-mgmt-tools] The Missing Arch patch for reposync -- Updated Patch In-Reply-To: <47234A60.4060809@cdChase.com> References: <47234A60.4060809@cdChase.com> Message-ID: <47238F77.8080802@cdChase.com> As promised, here's the updated patch. FYI, worked great with the current source from git. I'm just getting used to git--I use Subversion most of the time. Do you call it HEAD? I looked for a revision number to specify, show you are aware of what the patch was against in case there were updates prior to my getting this back to you, but could not find any. Guess git requires some study... :-) -Dan -- C. Daniel Chase (423) 949-4086 http://cdChase.com/ Get Firefox! http://www.spreadfirefox.com/?q=affiliates&id=58708&t=1 Queensbury High School 1977 30th Reunion http://cdchase.com/QHSReunion/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cobbler_arch_cdc.patch.git URL: From mdehaan at redhat.com Mon Oct 29 14:38:50 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 29 Oct 2007 10:38:50 -0400 Subject: [et-mgmt-tools] The Missing Arch patch for reposync -- Updated Patch In-Reply-To: <47238F77.8080802@cdChase.com> References: <47234A60.4060809@cdChase.com> <47238F77.8080802@cdChase.com> Message-ID: <4725F07A.6030204@redhat.com> C. Daniel Chase wrote: > As promised, here's the updated patch. FYI, worked great with the > current source from git. Excellent, thanks ... I'll apply this shortly. > I'm just getting used to git--I use Subversion > most of the time. Do you call it HEAD? > I looked for a revision number to > specify, show you are aware of what the patch was against in case there > were updates prior to my getting this back to you, but could not find > any. Guess git requires some study... :-) > Yeah, git also uses 'HEAD'. As far as I know git users refer to versions using the checksums as there is no central authoritative repository as far as git itself is concerned. Thanks! > -Dan > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From crobinso at redhat.com Mon Oct 29 15:02:30 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 29 Oct 2007 11:02:30 -0400 Subject: [et-mgmt-tools] [PATCH]: Print a better error message if the disk path doesn't exist In-Reply-To: <47053570.8090702@redhat.com> References: <470528AD.3040003@redhat.com> <4705305A.9000505@redhat.com> <47053570.8090702@redhat.com> Message-ID: <4725F606.5060508@redhat.com> Chris Lalancette wrote: > Cole Robinson wrote: >> Hi Chris, >> >> Actually just yesterday I committed some validation cases to virtinst which >> catch this problem, though in a different location. >> >> http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c0b20d1eaaf2 >> >> It catches it prior to the setup() portion of the code: when >> the disk path is passed to the VirtualDisk constructor, it now checks >> to ensure the directory exists, and if not throws a ValueError. This >> way virt-install can catch this and recover, then prompt the user for >> a corrected path. >> >> Not sure if the relevant portion of that patch fits your needs >> though. >> > > Ah, it mostly does. Actually, I think my patch complements your patch. The > problem is that it could be the case that *after* your check, but before the > os.open(), the directory could be deleted, so you would still run into the > traceback. Unlikely, I know, but still possible, so I think my patch is still > worthwhile. > > Thanks, > Chris Lalancette One gripe: > + except OSError: > + raise RuntimeError, "Path to diskimage "+self.path+" does not exist" This error message is too general, as it doesn't take into account non-missing-path related errors, so this could swallow another legitimate error message. - Cole -- Cole Robinson crobinso at redhat.com From clalance at redhat.com Mon Oct 29 17:51:32 2007 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 29 Oct 2007 13:51:32 -0400 Subject: [et-mgmt-tools] [PATCH]: Print a better error message if the disk path doesn't exist In-Reply-To: <4725F606.5060508@redhat.com> References: <470528AD.3040003@redhat.com> <4705305A.9000505@redhat.com> <47053570.8090702@redhat.com> <4725F606.5060508@redhat.com> Message-ID: <47261DA4.4020009@redhat.com> Cole Robinson wrote: > > One gripe: > >> + except OSError: >> + raise RuntimeError, "Path to diskimage "+self.path+" does not exist" > > This error message is too general, as it doesn't take into account > non-missing-path related errors, so this could swallow another legitimate > error message. I think you meant "this error message is too specific", but yes, I definitely see your point. I've refreshed the patch here, with a more generic error message. As a side benefit, this also catches the error if you run out of disk space, plus gives useful information about any other errors os.open()/os.write() might throw (like bad file permissions, etc). This patch is against current HEAD of python-virtinst. Signed-off-by: Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: python-virtinst-catch-diskcreate-errors.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: From rabbott at ticom-geo.com Mon Oct 29 18:55:00 2007 From: rabbott at ticom-geo.com (Richard Abbott) Date: Mon, 29 Oct 2007 13:55:00 -0500 Subject: [et-mgmt-tools] Cobbler enchant problem Message-ID: <47262C84.20302@ticom-geo.com> I am having some trouble using the cobbler enchant command. When I type the following 'cobbler enchant --address=192.168.1.200 --profile=rhel4as-Test1-i386' on the cobbler server I get the following error "Cobbler does not understand 'enchant'" I have cobbler-0.6.2-2.fc7 and koan-0.6.2-2.fc7 installed. I have placed the koan-0.6.2-2.fc6.noarch.rpm (have also used the el4.noarch.rpm) file in /var/lib/cobbler and have the following line in the /var/lib/cobbler/settings file "koan_path: /var/lib/cobbler/koan-0.6.2-2.fc6.noarch.rpm" After adding that line I did a "cobbler sync" and when I try to enchant a system it doesn't work. I have followed the instructions in the man page for setting up a cobbler server and everything looks correct in the "cobbler report" output. Anyone know what I'm doing wrong? Thanks -- Richard Abbott TICOM Geomatics, Inc. 9130 Jollyville Rd, Ste 300 Austin, TX 78759 Office : (512)610-8340 Fax : (512)345-9992 Cell : (512)422-2352 From mdehaan at redhat.com Mon Oct 29 19:10:12 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 29 Oct 2007 15:10:12 -0400 Subject: [et-mgmt-tools] Cobbler enchant problem In-Reply-To: <47262C84.20302@ticom-geo.com> References: <47262C84.20302@ticom-geo.com> Message-ID: <47263014.70705@redhat.com> Richard Abbott wrote: > I am having some trouble using the cobbler enchant command. When I type > the following 'cobbler enchant --address=192.168.1.200 > --profile=rhel4as-Test1-i386' on the cobbler server I get the following > error "Cobbler does not understand 'enchant'" > Enchant was deprecated in a previous release, and removed relatively recently -- it was basically a wrapper for several SSH calls (including pushing a copy of koan and installing it), which could be better done with SSH. The main reason it was removed wasn't because of that, but because it required having koan RPMs locally and knew about only one RPM -- which wasn't good if you wanted to use koan against lots of different distributions. It played some games with Python paths and so forth to make this work, but it really wasn't the right way to go, and it was a bit strange to set up as you had to have a local copy of a koan RPM. The solution is to invoke koan over SSH, or, if you would like to use func (https://hosted.fedoraproject.org/projects/func/) it also has a virtualization module that supports calling koan remotely to install profiles/systems -- which will be much easier than SSH because of simplified cert distribution as well as being able to address multiple systems at once. Just putting 'koan' in your packages section of your kickstart eliminates the need of pushing it out with "enchant" ... if you are using Enterprise Linux 5+, you can reference the yum repositories that have koan in them in your kickstart file. If you're using RHEL4, fetch the koan RPM with wget and then install it in post. Hope that helps! --Michael > I have cobbler-0.6.2-2.fc7 and koan-0.6.2-2.fc7 installed. > > I have placed the koan-0.6.2-2.fc6.noarch.rpm (have also used the > el4.noarch.rpm) file in /var/lib/cobbler and have the following line in > the /var/lib/cobbler/settings file "koan_path: > /var/lib/cobbler/koan-0.6.2-2.fc6.noarch.rpm" > > After adding that line I did a "cobbler sync" and when I try to enchant > a system it doesn't work. > > I have followed the instructions in the man page for setting up a > cobbler server and everything looks correct in the "cobbler report" output. > > Anyone know what I'm doing wrong? > > Thanks > > From ecraymond at gmail.com Mon Oct 29 20:08:04 2007 From: ecraymond at gmail.com (Eric Raymond) Date: Mon, 29 Oct 2007 13:08:04 -0700 Subject: [et-mgmt-tools] Cobbler not detecting Arch properly on import Message-ID: <9401dd450710291308w606f5976t89aee787eb16b45d@mail.gmail.com> Hello, I have been having an issue with importing to distro from CD/DVD or from an existing repository. When I import an x86_64 distro, pre RHEL 5/CentOS5, etc..it creates a distro/profile for xen-i386.. It seems strange that it would be interpreted as Xen instead of just 64bit. It does install the correct setup when kickstarted, but it seems like a strange occurrence... Also, I was wondering if there is a documented way to setup the distro without importing media, since I currently have a massive repository/tree for my installations, and dont want to add duplicated data on my system. Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Mon Oct 29 20:16:35 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 29 Oct 2007 16:16:35 -0400 Subject: [et-mgmt-tools] Cobbler not detecting Arch properly on import In-Reply-To: <9401dd450710291308w606f5976t89aee787eb16b45d@mail.gmail.com> References: <9401dd450710291308w606f5976t89aee787eb16b45d@mail.gmail.com> Message-ID: <47263FA3.4060703@redhat.com> Eric Raymond wrote: > Hello, > > I have been having an issue with importing to distro from CD/DVD or > from an existing repository. When I import an x86_64 distro, pre RHEL > 5/CentOS5, etc..it creates a distro/profile for xen-i386.. It seems > strange that it would be interpreted as Xen instead of just 64bit. It > does install the correct setup when kickstarted, but it seems like a > strange occurrence... When you import a tree, cobbler does a scan against that tree to find out what distros are there. Since Xen paravirt kernels are different, they are created as seperate distros. If you are importing an existing directory, most likely what happened is that your directory did not contain a path that explicitly said "x86_64", so Cobbler assumed it was i386. This isn't really a problem as you can rename the distribution yourself... "cobbler profile rename" then "cobbler distro rename". > > Also, I was wondering if there is a documented way to setup the distro > without importing media, since I currently have a massive > repository/tree for my installations, and dont want to add duplicated > data on my system. There are two ways. One is to use "cobbler import --name=blah --path=blah --available-as=nfs://blah:/path/where/blah/is/mounted". This will do the same thing as the regular import but will know not to mirror the data, which seems especially well suited to your existing configuration. The --available-as must point to the directory that corresponds to what was given to path, exactly, as that variable will be inserted into the distro object to indicate where the network install source for that distro is. This can either be an NFS location (as above), or an existing http:// or ftp:// location. Giving this value allows the variable "$tree" to be interpreted in the kickstart file as intended, and getting it wrong will result in a Window poping up during install that indicates the install source was not found. However, if you do get it wrong, it's pretty easy to change later (just do a cobbler distro edit and change the --kopts parameters to reassign 'tree'). The alternative is to do "cobbler distro add" and "cobbler profile add" manually, which is a bit less automated, and is the way things were done before cobbler import had the --available-as option. > > Thanks, > > Eric > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From crobinso at redhat.com Mon Oct 29 20:36:05 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 29 Oct 2007 16:36:05 -0400 Subject: [et-mgmt-tools] [PATCH]: Print a better error message if the disk path doesn't exist In-Reply-To: <47261DA4.4020009@redhat.com> References: <470528AD.3040003@redhat.com> <4705305A.9000505@redhat.com> <47053570.8090702@redhat.com> <4725F606.5060508@redhat.com> <47261DA4.4020009@redhat.com> Message-ID: <47264435.6080900@redhat.com> Chris Lalancette wrote: > Cole Robinson wrote: >> One gripe: >> >>> + except OSError: >>> + raise RuntimeError, "Path to diskimage "+self.path+" does not exist" >> This error message is too general, as it doesn't take into account >> non-missing-path related errors, so this could swallow another legitimate >> error message. > > I think you meant "this error message is too specific", but yes, I definitely Yeah. My brain knew what I meant :) > see your point. I've refreshed the patch here, with a more generic error > message. As a side benefit, this also catches the error if you run out of disk > space, plus gives useful information about any other errors os.open()/os.write() > might throw (like bad file permissions, etc). This patch is against current > HEAD of python-virtinst. > > Signed-off-by: Chris Lalancette > Looks good. I've applied this. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=7030d53677b8 Thanks, Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Mon Oct 29 20:38:27 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 29 Oct 2007 16:38:27 -0400 Subject: [et-mgmt-tools] [PATCH] Fix virt-install iso path validation (BZ 249424) In-Reply-To: <20071023135926.GM15667@redhat.com> References: <4717CB3A.3000604@redhat.com> <471DFC53.50900@redhat.com> <20071023135926.GM15667@redhat.com> Message-ID: <472644C3.20801@redhat.com> Hugh O. Brock wrote: > On Tue, Oct 23, 2007 at 09:51:15AM -0400, Cole Robinson wrote: >> Cole Robinson wrote: >>> This patch builds a VirtualDisk object using the cdrom path passed to >>> virt-install to reuse the already present validation. It also touches up >>> some of the error messages the VirtualDisk throws to make them more >>> general specific. This solves bz 249424. >>> >>> - Cole >>> >>> >>> >> If there is no objections to this then I'll apply it. >> > > +1 looks fine to me... > > --H > I just applied this. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=9a1d35776b3c Thanks, Cole -- Cole Robinson crobinso at redhat.com