From lippold at gmail.com Sun Jul 1 21:56:34 2007 From: lippold at gmail.com (Aaron Lippold) Date: Sun, 1 Jul 2007 23:56:34 +0200 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 Message-ID: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> Hi Mike, I just wanted to let you know that the Revisor folks are very interested in an integration / partnership with Cobbler. They said, "we well * definitely * be putting cobbler integration into Revisor 2.1.x..." . Did the Revisor folks email you at all? Also, I was just wondering if your team has talked about putting a Web Service - or web-ish system stuff - interface onto Cobbler given its Enterprise scale? Just a thought. ( I have lots of those :) ) Yours, Aaron From fukuta.saori at jp.fujitsu.com Mon Jul 2 09:29:03 2007 From: fukuta.saori at jp.fujitsu.com (Saori Fukuta) Date: Mon, 02 Jul 2007 18:29:03 +0900 Subject: [et-mgmt-tools] [PATCH] can not specify the type of driver device Message-ID: <20070702181447.CBBA.FUKUTA.SAORI@jp.fujitsu.com> Hi, I opened the new bugzilla: Bugzilla Bug 246441: can not specify the type of driver device URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246441 And I attached the patch to fix this problem. Thanks, Saori Fukuta From fj0873gn at aa.jp.fujitsu.com Mon Jul 2 10:58:53 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Mon, 2 Jul 2007 19:58:53 +0900 Subject: [et-mgmt-tools] Re: About keeping the cdrom in the permanent XMLfor a guest after install In-Reply-To: <20070628225530.GE12711@redhat.com> References: <4683EC65.7070601@redhat.com><20070628225530.GE12711@redhat.com> Message-ID: <200707021958.CJF00097.O9HG08K4@aa.jp.fujitsu.com> Hi, Hugh and Dan > > Hi there. > > > > I still prefer the idea of leaving the CDROM mounted because the > > heuristic we use to determine if a Windows guest is being installed is a > > big hack, and because we don't use that code at all in virt-manager and > > I would like the cdrom to stay mounted by default in virt-manager > > installs as well. > > > > However, if the earlier behavior is useful to anyone, I'd be happy to > > take a patch for a virtinst argument that would direct virtinst not to > > include the cdrom device in the post-install guest description. > > How about leaving the CDROM device itself always attached, but not having > any file (media) associated with it. That would keep the simplicity of > always doing the same config for all OS, while still allowing people to > use 'xm block-configure' for Windows guests to add the CDROM again. The above-mentioned idea just corresponds to the state before correction. Although Windows may be unique compared with other OS's, the user can enough continue installation by using xm block-configure. > On a side note, we really need a 'xm block-configure' equivalent API in > libvirt, so that we can do CDROM media changes from the virt-manager GUI > and virsh, for both KVM & Xen. I think so, too. Thanks, Nobuhiro Itou. From mdehaan at redhat.com Mon Jul 2 14:52:08 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 02 Jul 2007 10:52:08 -0400 Subject: [et-mgmt-tools] Getting started with cobbler In-Reply-To: References: Message-ID: <46891118.9000707@redhat.com> drew einhorn wrote: > Set up my first cobbler server. > > Tried my first PXE boot. > > After a brief burst of activity the PXE boot dies complaining about a > tftp open timeout. > > Took a look at the network traffic using wireshark. > > I see what appears to be normal RARP/ARP/DHCP traffic where the host > doing the > PXE boot gets an IP number, etc. > > The host then sends the server a: > TFTP read request for /pxelinux.0 > > The server immediately replies with > ICMP > Type 3 (Destination Unreachable) > Code 10 (Host Administratievely prohibited) > > Have not found any other error messages etc. > > Found the archives for this list but as far as I can tell they are not > searchable. > If it's not a firewall/network configuration problem, the other possibility I could think of would be the content for /tftpboot isn't labelled properly for SELinux, if you're using that. From google, the proper context appears to be "system_u:system_r:tftpd_t", doing a ls -lZ on pxelinux.0 should tell you if it is labelled correctly. By the way -- for searching the archives, this seems to work pretty well: "your-keywords et-mgmt-tools site:www.redhat.com" --Michael From mdehaan at redhat.com Mon Jul 2 14:52:45 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 02 Jul 2007 10:52:45 -0400 Subject: [et-mgmt-tools] Re: Getting started with cobbler In-Reply-To: References: Message-ID: <4689113D.2090000@redhat.com> drew einhorn wrote: > Figured out the answers to my questions. > > The server is a CentOS5 box and I needed to add some rules to > the default firewall settings. Ah, good deal ... I should have read the rest of my email before replying :) > > And there is a searchable archive of this list at > http://dir.gmane.org/gmane.linux.redhat.et-mgmt-tools > > On 6/29/07, drew einhorn wrote: >> Set up my first cobbler server. >> >> Tried my first PXE boot. >> >> After a brief burst of activity the PXE boot dies complaining about a >> tftp open timeout. >> >> Took a look at the network traffic using wireshark. >> >> I see what appears to be normal RARP/ARP/DHCP traffic where the host >> doing the >> PXE boot gets an IP number, etc. >> >> The host then sends the server a: >> TFTP read request for /pxelinux.0 >> >> The server immediately replies with >> ICMP >> Type 3 (Destination Unreachable) >> Code 10 (Host Administratievely prohibited) >> >> Have not found any other error messages etc. >> >> Found the archives for this list but as far as I can tell they are not >> searchable. >> >> -- >> Drew Einhorn >> > > From mdehaan at redhat.com Mon Jul 2 14:56:32 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 02 Jul 2007 10:56:32 -0400 Subject: [et-mgmt-tools] Re: Getting started with cobbler In-Reply-To: References: Message-ID: <46891220.5040307@redhat.com> drew einhorn wrote: > Next problem. > > Now that I have the the firewall fixed to allow incomining tftp > requests for the PXE boot. > Things perk along for a while, then it tries to get the kickstart file > from > > http:///cblr/kickstarts_sys//ks.cfg > > Ok, add one more rule to the firewall config. > > Oops, there's no http server running on the server. "cobbler check" (see also: manpage) can be used to detect basic problems in a server configuration, however it doesn't check for service start/stop states. This is something that can be added to the TODO list. Not a bad idea :) Examining the firewall configuration may also prove interesting. --Michael > > On 6/29/07, *drew einhorn* < drew.einhorn at gmail.com > > wrote: > > Figured out the answers to my questions. > > The server is a CentOS5 box and I needed to add some rules to > the default firewall settings. > > And there is a searchable archive of this list at > http://dir.gmane.org/gmane.linux.redhat.et-mgmt-tools > > > On 6/29/07, drew einhorn > wrote: > > Set up my first cobbler server. > > > > Tried my first PXE boot. > > > > After a brief burst of activity the PXE boot dies complaining > about a > > tftp open timeout. > > > > Took a look at the network traffic using wireshark. > > > > I see what appears to be normal RARP/ARP/DHCP traffic where the > host doing the > > PXE boot gets an IP number, etc. > > > > The host then sends the server a: > > TFTP read request for /pxelinux.0 > > > > The server immediately replies with > > ICMP > > Type 3 (Destination Unreachable) > > Code 10 (Host Administratievely prohibited) > > > > Have not found any other error messages etc. > > > > Found the archives for this list but as far as I can tell they > are not > > searchable. > > > > -- > > Drew Einhorn > > > > > -- > Drew Einhorn > > > > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jul 2 15:14:59 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 02 Jul 2007 11:14:59 -0400 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> Message-ID: <46891673.30407@redhat.com> Aaron Lippold wrote: > Hi Mike, > > I just wanted to let you know that the Revisor folks are very > interested in an integration / partnership with Cobbler. They said, > "we well * definitely * be putting cobbler integration into Revisor > 2.1.x..." . > > Did the Revisor folks email you at all? This is the first I've heard of it, though I'll definitely ping them. Neat. > > Also, I was just wondering if your team has talked about putting a Web > Service - or web-ish system stuff - interface onto Cobbler given its > Enterprise scale? Just a thought. ( I have lots of those :) ) Ideally the FOSS community is the team :) To answer the question -- Cobbler is being used as the provisioning backend behind virt-factory (http://virt-factory.et.redhat.com) -- which has a Web UI -- though cobbler itself doesn't have it's own WebUI yet. To be clear, virt-factory is somewhat specialized, so it doesn't fill the same niche, and uses only a subset of cobbler features. A couple of folks have expressed interest in doing a WUI for Cobbler before, though I don't believe anyone is actively pursuing it. I'd like one, though mostly I've been concentrating on the backend and virt-factory, so I haven't had the time to create one. Writing something in TurboGears that uses the Cobbler API seems like a reasonably easy thing to do if anyone wants a side project. It wouldn't even need the database features. An alternate option might be PyGTK for a local configuration client. The other possibility is to enhance the existing XMLRPC API provided by 0.5.0 cobblerd to support authentication, encryption, and the full API set -- so that cobbler could be integrated into more Web UI's that were not necessarily implemented in Python. I've been thinking about doing this, though I'd like to know if this would really be useful first -- just having a simple Web UI might achieve the same purpose. > > Yours, > > Aaron > > _______________________________________________ > 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 Jul 2 15:33:27 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 02 Jul 2007 11:33:27 -0400 Subject: [et-mgmt-tools] VMware? In-Reply-To: References: Message-ID: <46891AC7.6000002@redhat.com> drew einhorn wrote: > Cobbler / Koan supports Xen virtualization. > > Has anyone looked at what it would take to get koan working > on other virtualization platforms? I have a VMware ESX box > I'd like to be able to use it on. > Not to my knowledge -- though I like the idea. As far as I'm aware, vmware does understand PXE installation, so koan would just need a way to create an "empty" guest that would PXE itself. I know this is the plan for how we're going to support fully automatic installs for other virtualization types like KVM, Xen hardware virt, etc. If there are any VMware experts on the list, patches would be great :) It seems like the syntax needed would not need to even access the cobbler server the way --virt does today, ex: koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF --virt-name=foo [...other options...] --virt-type could default to "xenparavirt" and current behavior. --Michael From rjones at redhat.com Mon Jul 2 15:38:48 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 02 Jul 2007 16:38:48 +0100 Subject: [et-mgmt-tools] Proposal: libvirt should remove or rename a save file after a successful restore Message-ID: <46891C08.5050902@redhat.com> Chris Lalancette found this problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246105 Once an "xm restore" has successfully completed, the -save file that it came from should really be deleted. Restoring a domain a second time from the same save file will result in disk corruption; the kernel VM state (in the saved file) will be in an inconsistent state with respect to what is actually on disk (in the domain disk file). The only valid use I can see for the -save file after a restore is possibly for some crash analysis, but even that could be worked around by renaming the save file after a success. In particular, I just ran into this situation (and I'm worried customers might do the same): [and then he goes on to describe a scenario in which you can commonly hit this situation] So the obvious and simple solution, it seems to me, is just to change libvirt.c:virDomainRestore so that if the driver underneath it returns from the restore without error, then we either remove or rename the restore file. It's a trivial patch -- what do people think? My thoughts: * Removing the file might seem quite abrupt/unexpected, and there is the possibility of data loss. * You have to rename the file as a hidden file (dotfile) in order for xendomains to ignore it. However these files are big and having large, hidden files which build up in number over time sounds like it could be a bad thing. * This might be considered a significant behaviour change. * It's easier to handle this for the remote case if we make the change inside libvirt, rather than in virsh etc. 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 Mon Jul 2 15:51:19 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 2 Jul 2007 16:51:19 +0100 Subject: [et-mgmt-tools] Re: [Libvir] Proposal: libvirt should remove or rename a save file after a successful restore In-Reply-To: <46891C08.5050902@redhat.com> References: <46891C08.5050902@redhat.com> Message-ID: <20070702155119.GD23623@redhat.com> On Mon, Jul 02, 2007 at 04:38:48PM +0100, Richard W.M. Jones wrote: > Chris Lalancette found this problem: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246105 > > > Once an "xm restore" has successfully completed, the -save file that it > came from should really be deleted. Restoring a domain a second time > from the same save file will result in disk corruption; the kernel VM > state (in the saved file) will be in an inconsistent state with respect > to what is actually on disk (in the domain disk file). The only valid > use I can see for the -save file after a restore is possibly for some > crash analysis, but even that could be worked around by renaming the > save file after a success. In particular, I just ran into this > situation (and I'm worried customers might do the same): > [and then he goes on to describe a scenario in which you can commonly > hit this situation] > > > So the obvious and simple solution, it seems to me, is just to change > libvirt.c:virDomainRestore so that if the driver underneath it returns > from the restore without error, then we either remove or rename the > restore file. > > It's a trivial patch -- what do people think? > My thoughts: > * Removing the file might seem quite abrupt/unexpected, and there is the > possibility of data loss. That would be placing policy into the API which IMHO is wrong. Policy should be in tools instead. So making virsh/virt-manager remove the file is good, but we shouldn't force it on all users of the API. It is quite possible that a user wishes to restore from the same file mulitple times - assuming they know the caveats about snapshotting the filesystem to match their VM state. > * You have to rename the file as a hidden file (dotfile) in order for > xendomains to ignore it. However these files are big and having large, > hidden files which build up in number over time sounds like it could be > a bad thing. I don't like the idea of renaming just to get around xendomains issues. Ad-hoc saved VMs should not be put in the same directory that xendomains uses for its managed saved-on-shutdown process. This bug should should fixed separately. > * This might be considered a significant behaviour change. > * It's easier to handle this for the remote case if we make the change > inside libvirt, rather than in virsh etc. We can't change the existing API semantics in this way. At best we could add an additional variant of the virDomainRestore which added a 'flags' parameter perhaps. Longer term we need to consider expanding the save/restore APIs because both QEMU & Xen now have an idea of 'managed save images' as well as external save images. WIth managed images, you don't supply a filename, instead you simply tell it to save the VM (optionally with a 'tag' to identify the image). XenD / QEMU can list previously saved images, and optionally restore from one, or delete one. This supports the idea of snapshots/checkpoints too. So I think we'll ultimately need several more APIs in this area. The managed save/restore APIs will end up being separate from the existing unmanaged APIs though. 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 jason.dunn at analog.com Mon Jul 2 17:46:49 2007 From: jason.dunn at analog.com (Jason Dunn) Date: Mon, 02 Jul 2007 13:46:49 -0400 Subject: [et-mgmt-tools] Question about Guest disk image size limit Message-ID: <46893A09.1060009@analog.com> I found this post from a few months back, and was wondering if anyone knew when this fix would make its way into RHEL5 if ever? In the mean time, does anyone know what I could change that would allow me to have larger than 16GB image files for guest OS's? Thanks, Jason Daniel P. Berrange wrote: On Fri, Mar 16, 2007 at 06:09:15PM +0900, Atsushi SAKAI wrote: Hi, Guest OS disk Image size is limited to 16GB in case we are using virt-manager. Is this any reason to limit this value? No, it seems bogus. It should be possible to create files as large as the underlying filesystem supports (typically 2TB) This information is written in following file. virt-manager-0.2.6 virt-manager.glade virt-manager-0.3.1 vmm-create.glade I have fixed this in the tree. The upper limit on file size is now ~4 TB, which "should be enough for anybody". --Hugh From rjones at redhat.com Mon Jul 2 18:25:09 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 02 Jul 2007 19:25:09 +0100 Subject: [et-mgmt-tools] Question about Guest disk image size limit In-Reply-To: <46893A09.1060009@analog.com> References: <46893A09.1060009@analog.com> Message-ID: <46894305.5040206@redhat.com> Jason Dunn wrote: > I found this post from a few months back, and was wondering if anyone > knew when this fix would make its way into RHEL5 if ever? In the mean > time, does anyone know what I could change that would allow me to have > larger than 16GB image files for guest OS's? The problem is literally just in the virt-manager UI (and it's been fixed there since virt-manager 0.4.0). So there are several things you could do in the meantime, including upgrading to a recent virt-manager using the FC6/F7 src RPM, or using /usr/sbin/virt-install directly, or (I think this will work?) creating the disk image first by hand. 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 Mon Jul 2 18:28:20 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 2 Jul 2007 19:28:20 +0100 Subject: [et-mgmt-tools] Question about Guest disk image size limit In-Reply-To: <46894305.5040206@redhat.com> References: <46893A09.1060009@analog.com> <46894305.5040206@redhat.com> Message-ID: <20070702182820.GC1926@redhat.com> On Mon, Jul 02, 2007 at 07:25:09PM +0100, Richard W.M. Jones wrote: > Jason Dunn wrote: > >I found this post from a few months back, and was wondering if anyone > >knew when this fix would make its way into RHEL5 if ever? In the mean > >time, does anyone know what I could change that would allow me to have > >larger than 16GB image files for guest OS's? > > The problem is literally just in the virt-manager UI (and it's been > fixed there since virt-manager 0.4.0). So there are several things you > could do in the meantime, including upgrading to a recent virt-manager > using the FC6/F7 src RPM, or using /usr/sbin/virt-install directly, or > (I think this will work?) creating the disk image first by hand. Actually, since you're very unlikely to need > 16 GB for the initial install, by far the simplest option is to just extend the image once you've completed the initial install. dd can do it trivially with dd if=/dev/zero of=/var/lib/xen/images/blah.img bs=1M count=0 seek=102400 Will extend the image to 100 GB for example. NB count=0 so it never actually writes any data to your disk - it is merely seek'ing to the new desired size, creating a sparse extension. It is possible you may want to extend it non-sparse - this is a little trickier. You have to make set 'seek' to match the current size, and then count to specify the additional size. 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 Mon Jul 2 19:32:19 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 02 Jul 2007 15:32:19 -0400 Subject: [et-mgmt-tools] [RFC] Approach to installing a localized virtinst In-Reply-To: <20070629125955.GA25518@redhat.com> References: <4684018D.3090309@redhat.com> <20070629125955.GA25518@redhat.com> Message-ID: <468952C3.3010903@redhat.com> Daniel P. Berrange wrote: > On Thu, Jun 28, 2007 at 02:44:29PM -0400, Cole Robinson wrote: >> Hello all, >> >> I've recently undertaken adding localization support to virtinst. Since >> currently build and install from source is done using a typical setup.py >> script, I've encountered several issues involving how to handle >> installing the locale files, and making virtinst aware of where they are. >> >> The attached patch handles the first issue: I added custom functionality >> to to the build and install_data commands as invoked in the setup >> script. The build command searchs po/ for any .po files and invokes >> msgfmt to compile them. The install_data additions have to do some silly >> things to name the files correctly as distutils cannot rename extra >> install files on the fly (ex. moves po/es.mo to build/es/virtinst.mo). >> >> The second problem is a bit more perplexing. The path to the locale >> files has to be placed into a virtinst header so that the library knows >> where to look for them. Possible solutions I see: >> >> 1) Extracting the install root from setup.py mid run. This has to happen >> after build but before actual install. The locale path could then be >> formed and sed'd or some equivalent into a virtinst header file, which >> would than have to be (re)compiled and moved to the build directory. >> Ugly way to do it, but the user can still use setup.py as normal and all >> should work. > > I think since your example for installing .po files is already overriding > the install_data class, we might as well override the install_lib class > and substitute in the local directory path at that point. > >> Thoughts? I'm not too familiar with this stuff so I may be overlooking a >> simpler solution, or oversimplifying a complex one! > > Python's distutils is pretty horribly limited compared to comparable > tools, so I think overloading the install_lib is easiest option, unless > we were to throw out distutils completely which isn't exactly easy either. > > Dan. Yeah install_lib definitely seems like the way to go. I didn't realize the python byte-code compiling was done during the install and not the build, so its a pretty clean fix this way. I'll be sending the patches out shortly. Thanks, Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Mon Jul 2 20:09:51 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 02 Jul 2007 16:09:51 -0400 Subject: [et-mgmt-tools] [PATCH 0/2] Add i18n support to virtinst Message-ID: <46895B8F.3010905@redhat.com> Hello all, The following 2 patches add internationalization support to virtinst, virt-install and virt-clone. The first patch updates the install and autobuild process so that required localization files are built and installed appropriately whether by hand or via an rpm. The second patch is the grunt work gettext'ing all the appropriate strings. Comments welcome! Thanks, Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Mon Jul 2 20:26:37 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 02 Jul 2007 16:26:37 -0400 Subject: [et-mgmt-tools] [PATCH 1/2] Build and install locale files if present. In-Reply-To: <46895B8F.3010905@redhat.com> References: <46895B8F.3010905@redhat.com> Message-ID: <46895F7D.3020709@redhat.com> This patch contains the necessary changes to the build/install process to accommodate locale files. The main changes are in the setup.py script where several operations were overloaded to 1) Build any .po files it finds in the po directory to .mo 2) Place these files in INSTALLROOT/share/locale as appropriate 3) Do appropriate locale path replacement in __init__.py so virtinst knows where to find the locale files. I'm not sure if their is a better place for the gettext includes than __init__.py, but it seems to work for the library and the scripts that use it (virt-install and virt-clone). Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-i18n-install.patch Type: text/x-patch Size: 24668 bytes Desc: not available URL: From crobinso at redhat.com Mon Jul 2 20:32:37 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 02 Jul 2007 16:32:37 -0400 Subject: [et-mgmt-tools] [PATCH 2/2] Internationalize all appropriate strings In-Reply-To: <46895B8F.3010905@redhat.com> References: <46895B8F.3010905@redhat.com> Message-ID: <468960E5.8090806@redhat.com> Cole Robinson wrote: > Hello all, > > The following 2 patches add internationalization support to virtinst, > virt-install and virt-clone. > This is the grunt work of the internationalization: adding gettext support to all relevant strings, and touching up wording to be more translation friendly. Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-i18n-formatting.patch Type: text/x-patch Size: 68530 bytes Desc: not available URL: From fj0873gn at aa.jp.fujitsu.com Tue Jul 3 02:56:57 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Tue, 3 Jul 2007 11:56:57 +0900 Subject: [et-mgmt-tools] Why does not virt-install use the tap driver in HVM? Message-ID: <200707031156.AHE39565.84KO0H9G@aa.jp.fujitsu.com> Hi, I have a question. There is the following codes in virt-install. def get_disk(disk, size, sparse, guest, hvm, conn): : : if d.type == virtinst.VirtualDisk.TYPE_FILE and not(hvm) and virtinst.util.is_blktap_capable(): d.driver_name = virtinst.VirtualDisk.DRIVER_TAP Why "not(hvm)"? Thanks, Nobuhiro Itou. From jason.dunn at analog.com Tue Jul 3 13:14:25 2007 From: jason.dunn at analog.com (Jason Dunn) Date: Tue, 03 Jul 2007 09:14:25 -0400 Subject: [et-mgmt-tools] Question about Guest disk image size limit In-Reply-To: <46893A09.1060009@analog.com> References: <46893A09.1060009@analog.com> Message-ID: <468A4BB1.60501@analog.com> Thanks for the great suggestions, but as I'd like to manage the disk space through the gui, (and I'm sure other do as well): I did a little digging and it looks like in virt-manager-0.2.6-7.0.2.el5 you can change line 7849 of /usr/share/virt-manager/virt-manager.glade FROM: 500 100 16000 100 500 500 TO: 500 100 [larger number] 100 500 500 Replacing the 16000 with whatever you want the max to be. Jason changing line 7849 in /usr/share/virt-manager/virt-manager.glade of version Jason Dunn wrote: > I found this post from a few months back, and was wondering if anyone > knew when this fix would make its way into RHEL5 if ever? In the mean > time, does anyone know what I could change that would allow me to have > larger than 16GB image files for guest OS's? > > Thanks, > Jason > > > Daniel P. Berrange wrote: > > On Fri, Mar 16, 2007 at 06:09:15PM +0900, Atsushi SAKAI wrote: > > Hi, > > > Guest OS disk Image size is limited to 16GB in case we are using > virt-manager. > > Is this any reason to limit this value? > > No, it seems bogus. It should be possible to create files as large > as the > underlying filesystem supports (typically 2TB) > > > This information is written in following file. > virt-manager-0.2.6 virt-manager.glade > virt-manager-0.3.1 vmm-create.glade > > I have fixed this in the tree. The upper limit on file size is now ~4 > TB, which "should be enough for anybody". > > --Hugh > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From Daniel.Hennessey at aah.co.uk Tue Jul 3 13:14:46 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Tue, 3 Jul 2007 14:14:46 +0100 Subject: [et-mgmt-tools] cobbler broken with python < 2.4 Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C5C@GBW607SC0054.GB-WS.net> Hey, just upgraded cobbler to 0.5 and now it doesn't work. I get; cobbler Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 719, in main BootCLI(sys.argv).run() File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 42, in __init__ self.api = api.BootAPI() File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 40, in __init__ self.deserialize() File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 170, in deserialize return self._config.deserialize() File "/usr/lib/python2.3/site-packages/cobbler/config.py", line 169, in deserialize if not serializer.deserialize(x,topological=True): File "/usr/lib/python2.3/site-packages/cobbler/serializer.py", line 79, in deserialize datastruct.sort(cmp=__depth_cmp) TypeError: sort() takes no keyword arguments I assume that this is because the sort() function in older versions of python does not expect parameters. Cheers Dan ************************************************************************ DISCLAIMER The information contained in this e-mail is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply e-mail and then delete it from your system. Please do not copy it or use it for any other purposes, or disclose the content of the e-mail to any other person or store or copy the information in any medium. The views contained in this e-mail are those of the author and not necessarily those of Admenta UK Group. Admenta UK plc is a company incorporated in England and Wales under company number 3011757 and whose registered office is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX ************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Hennessey at aah.co.uk Tue Jul 3 13:42:22 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Tue, 3 Jul 2007 14:42:22 +0100 Subject: [et-mgmt-tools] cobbler import arch problem Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C5D@GBW607SC0054.GB-WS.net> using cobbler to import an existing x86-64 distro tree but when I do a "cobbler distro report" it says the distro's arch is x86. I can use "cobbler distro add" and explicitly state the arch but this leaves the distro tree in place and I was hoping to import all my kickstart trees to be managed by cobbler. Any clues? Cheers Dan ************************************************************************ DISCLAIMER The information contained in this e-mail is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply e-mail and then delete it from your system. Please do not copy it or use it for any other purposes, or disclose the content of the e-mail to any other person or store or copy the information in any medium. The views contained in this e-mail are those of the author and not necessarily those of Admenta UK Group. Admenta UK plc is a company incorporated in England and Wales under company number 3011757 and whose registered office is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX ************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From drew.einhorn at gmail.com Tue Jul 3 14:13:34 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 3 Jul 2007 08:13:34 -0600 Subject: [et-mgmt-tools] VMware? In-Reply-To: <46891AC7.6000002@redhat.com> References: <46891AC7.6000002@redhat.com> Message-ID: Things are working well on the ESX box now that I'm past the cobbler and kickstart misconfigurations. Every time I create an new vm I need to take a trip though VMware's Virtual Infrastructure Client, that I'd really like to avoid. VMware has a few more options to besides ram and disk space to configure before creating a VM. Haven't taken a close enough look to know either how difficult it will be to live without being able to set them when the VM is created, or how difficult it would be to extend cobbler to handle more VM attributes, or how this maps into all the other virtualization toolsets. On 7/2/07, Michael DeHaan wrote: > > drew einhorn wrote: > > Cobbler / Koan supports Xen virtualization. > > > > Has anyone looked at what it would take to get koan working > > on other virtualization platforms? I have a VMware ESX box > > I'd like to be able to use it on. > > > > Not to my knowledge -- though I like the idea. > > As far as I'm aware, vmware does understand PXE installation, so koan > would just need a way to create an "empty" guest > that would PXE itself. I know this is the plan for how we're going to > support fully automatic installs for other > virtualization types like KVM, Xen hardware virt, etc. > > If there are any VMware experts on the list, patches would be great :) > > It seems like the syntax needed would not need to even access the > cobbler server the way --virt does today, ex: > > koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF --virt-name=foo > [...other options...] > > --virt-type could default to "xenparavirt" and current behavior. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Tue Jul 3 14:19:47 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 3 Jul 2007 15:19:47 +0100 Subject: [et-mgmt-tools] Why does not virt-install use the tap driver in HVM? In-Reply-To: <200707031156.AHE39565.84KO0H9G@aa.jp.fujitsu.com> References: <200707031156.AHE39565.84KO0H9G@aa.jp.fujitsu.com> Message-ID: <20070703141947.GC8410@redhat.com> On Tue, Jul 03, 2007 at 11:56:57AM +0900, Nobuhiro Itou wrote: > Hi, > > I have a question. > > There is the following codes in virt-install. > > def get_disk(disk, size, sparse, guest, hvm, conn): > : > : > if d.type == virtinst.VirtualDisk.TYPE_FILE and not(hvm) and virtinst.util.is_blktap_capable(): > d.driver_name = virtinst.VirtualDisk.DRIVER_TAP > > Why "not(hvm)"? QEMU is incapable of using blktap disks :-( I'm trying to work on fixes to QEMU to make it work - obviously we want to be able to use blktap if the HVM guest has paravirt drivers... 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 Jul 3 14:38:20 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 10:38:20 -0400 Subject: [et-mgmt-tools] cobbler broken with python < 2.4 In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C5C@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C5C@GBW607SC0054.GB-WS.net> Message-ID: <468A5F5C.3000006@redhat.com> Hennessey Daniel wrote: > Hey, > > just upgraded cobbler to 0.5 and now it doesn't work. I get; > > cobbler > Traceback (most recent call last): > File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line > 719, in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 42, > in __init__ > self.api = api.BootAPI() > File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 40, in > __init__ > self.deserialize() > File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 170, in > deserialize > return self._config.deserialize() > File "/usr/lib/python2.3/site-packages/cobbler/config.py", line 169, > in deserialize > if not serializer.deserialize(x,topological=True): > File "/usr/lib/python2.3/site-packages/cobbler/serializer.py", line > 79, in deserialize > datastruct.sort(cmp=__depth_cmp) > TypeError: sort() takes no keyword arguments > I assume that this is because the sort() function in older versions of > python does not expect parameters. Sorry about that. If you're using git, do a "git pull", and I've already pushed the fix... diff --git a/cobbler/serializer.py b/cobbler/serializer.py index d35bdb1..b1161d1 100644 --- a/cobbler/serializer.py +++ b/cobbler/serializer.py @@ -76,7 +76,7 @@ def deserialize(obj,topological=False): # if the depth were 0. It will be assigned a proper depth at serializat # time. This is a bit cleaner implementation wise than a topological so # though that would make a shiny upgrade. - datastruct.sort(cmp=__depth_cmp) + datastruct.sort(__depth_cmp) obj.from_datastruct(datastruct) return True --Michael From mdehaan at redhat.com Tue Jul 3 14:42:27 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 10:42:27 -0400 Subject: [et-mgmt-tools] cobbler import arch problem In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C5D@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C5D@GBW607SC0054.GB-WS.net> Message-ID: <468A6053.306@redhat.com> Hennessey Daniel wrote: > using cobbler to import an existing x86-64 distro tree but when I do a > "cobbler distro report" it says the distro's arch is x86. > > I can use "cobbler distro add" and explicitly state the arch but this > leaves the distro tree in place and I was hoping to import all my > kickstart trees to be managed by cobbler. > > Any clues? > This shouldn't happen, but it won't cause any adverse results... what distro source were you using for the import? (i.e. RHEL 4 DVD? rsync mirror?). If you can give me further info I'll take a look at see what's wrong with the auto-detection. Cobbler uses the arch field to decide when to set up for different bootloaders, such as "ia64" implying elilo. It doesn't pay attention to the difference between x86 and x86_64 as it uses syslinux either way. If you want to fix it, you can run: cobbler distro edit --name=foo --arch=x86_64 --Michael > Cheers > > Dan > > ************************************************************************ > > DISCLAIMER > > The information contained in this e-mail is confidential and is intended > > for the recipient only. > > If you have received it in error, please notify us immediately by reply > > e-mail and then delete it from your system. Please do not copy it or > > use it for any other purposes, or disclose the content of the e-mail > > to any other person or store or copy the information in any medium. > > The views contained in this e-mail are those of the author and not > > necessarily those of Admenta UK Group. > > Admenta UK plc is a company incorporated in England and Wales > > under company number 3011757 and whose registered office > > is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX > > ************************************************************************ > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From drew.einhorn at gmail.com Tue Jul 3 14:42:37 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 3 Jul 2007 08:42:37 -0600 Subject: [et-mgmt-tools] Protect Base Repositories Message-ID: When mirroring repositories, is there way to get ProtectBase installed and configured before the third party repositories run amok? -- Drew Einhorn From mdehaan at redhat.com Tue Jul 3 14:44:52 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 10:44:52 -0400 Subject: [et-mgmt-tools] VMware? In-Reply-To: References: <46891AC7.6000002@redhat.com> Message-ID: <468A60E4.7000503@redhat.com> drew einhorn wrote: > Things are working well on the ESX box now that I'm past the cobbler > and kickstart misconfigurations. > > Every time I create an new vm I need to take a trip though VMware's > Virtual Infrastructure Client, that I'd really like to avoid. VMware > has a few more options to besides ram and disk space to configure > before creating a VM. Haven't taken a close enough look to know > either how difficult it will be to live without being able to set them > when the VM is created, or how difficult it would be to extend cobbler > to handle more VM attributes, or how this maps into all the other > virtualization toolsets. > Can you see if VMware has any docs for command line creation of guests? If so, those attributes could be added in koan fairly easily. I don't have a test platform, but would be more than happy to code something up in koan if someone wanted to test the proof of concept. Tracking a few additional attributes in cobbler wouldn't be a problem. > On 7/2/07, *Michael DeHaan* < mdehaan at redhat.com > > wrote: > > drew einhorn wrote: > > Cobbler / Koan supports Xen virtualization. > > > > Has anyone looked at what it would take to get koan working > > on other virtualization platforms? I have a VMware ESX box > > I'd like to be able to use it on. > > > > Not to my knowledge -- though I like the idea. > > As far as I'm aware, vmware does understand PXE installation, so koan > would just need a way to create an "empty" guest > that would PXE itself. I know this is the plan for how we're > going to > support fully automatic installs for other > virtualization types like KVM, Xen hardware virt, etc. > > If there are any VMware experts on the list, patches would be great :) > > It seems like the syntax needed would not need to even access the > cobbler server the way --virt does today, ex: > > koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF --virt-name=foo > [...other options...] > > --virt-type could default to "xenparavirt" and current behavior. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Daniel.Hennessey at aah.co.uk Tue Jul 3 14:54:16 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Tue, 3 Jul 2007 15:54:16 +0100 Subject: [et-mgmt-tools] cobbler import arch problem Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C5F@GBW607SC0054.GB-WS.net> Michael, I was importing from an existing local tree (copied from the CD set) using; cobbler import --name=RHEL44-x86-64 --mirror=/var/www/html/pub/yum/4AS/x86-64/up4 Where "/var/www/html/pub/yum/4AS/x86-64/up4" is the root directory of the installation tree. Thanks for the help, cobbler still rules. Dan. -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: 03 July 2007 3:42 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] cobbler import arch problem Hennessey Daniel wrote: > using cobbler to import an existing x86-64 distro tree but when I do a > "cobbler distro report" it says the distro's arch is x86. > > I can use "cobbler distro add" and explicitly state the arch but this > leaves the distro tree in place and I was hoping to import all my > kickstart trees to be managed by cobbler. > > Any clues? > This shouldn't happen, but it won't cause any adverse results... what distro source were you using for the import? (i.e. RHEL 4 DVD? rsync mirror?). If you can give me further info I'll take a look at see what's wrong with the auto-detection. Cobbler uses the arch field to decide when to set up for different bootloaders, such as "ia64" implying elilo. It doesn't pay attention to the difference between x86 and x86_64 as it uses syslinux either way. If you want to fix it, you can run: cobbler distro edit --name=foo --arch=x86_64 --Michael > Cheers > > Dan > > ********************************************************************** > ** > > DISCLAIMER > > The information contained in this e-mail is confidential and is > intended > > for the recipient only. > > If you have received it in error, please notify us immediately by > reply > > e-mail and then delete it from your system. Please do not copy it or > > use it for any other purposes, or disclose the content of the e-mail > > to any other person or store or copy the information in any medium. > > The views contained in this e-mail are those of the author and not > > necessarily those of Admenta UK Group. > > Admenta UK plc is a company incorporated in England and Wales > > under company number 3011757 and whose registered office > > is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX > > ********************************************************************** > ** > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > 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 Jul 3 15:20:23 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 11:20:23 -0400 Subject: [et-mgmt-tools] Cobbler/koan & EPEL Message-ID: <468A6937.8010108@redhat.com> I've just submitted Cobbler and koan to EPEL for EL-4 and EL-5. This will make Cobbler and koan easier to install on those platforms and eliminate the need to build it (and dependencies) yourself for stable releases. Read more about EPEL here: http://fedoraproject.org/wiki/EPEL These will stay in sync with the versions pushed to FC-6, FC-7, etc (aka "stable versions"). --Michael From mdehaan at redhat.com Tue Jul 3 15:24:38 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 11:24:38 -0400 Subject: [et-mgmt-tools] Protect Base Repositories In-Reply-To: References: Message-ID: <468A6A36.6060404@redhat.com> drew einhorn wrote: > When mirroring repositories, is there way to get ProtectBase installed > and configured before the third party repositories run amok? > Putting the bare minimum packages in the packages section of the kickstart and then installing the might-conflict-RPMs in post or with a config management system (that also configures protect-base) might be an answer. If you're using the "repo" entries in kickstart, then the latest package will be pulled from any repository, regardless of what repository that is. (Example: package foo has a version 1.23 in updates, but is 1.00 in the base tree -- Anaconda will pick 1.23). --Michael From mdehaan at redhat.com Tue Jul 3 15:31:41 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 11:31:41 -0400 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <46891673.30407@redhat.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> Message-ID: <468A6BDD.6020709@redhat.com> Michael DeHaan wrote: > Aaron Lippold wrote: >> Hi Mike, >> >> I just wanted to let you know that the Revisor folks are very >> interested in an integration / partnership with Cobbler. They said, >> "we well * definitely * be putting cobbler integration into Revisor >> 2.1.x..." . Just as an update, I was talking with Jereon van Meeuwen and Jonathan Steffan on #cobbler yesterday, and we bounced around a few ideas. One idea is a LiveCD that invokes koan. This would allow for PXEing in environments that have a cobbler server, but can't have a PXE server. They have an early test build, though it has some trouble detecting hard drives (apparently due to something with libata). As this also could be accomplished with a hacked up syslinux PXE boot image and a standard /tftpboot tree, there may be other ways to accomplish this worth exploring. Another idea is importing a cobbler profile and making a (non-networked) installable Live CD out of it -- pulling the needed packages from the various local cobbler repos onto the CD. --Michael From mdehaan at redhat.com Tue Jul 3 15:41:32 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 11:41:32 -0400 Subject: [et-mgmt-tools] VMware? In-Reply-To: <468A60E4.7000503@redhat.com> References: <46891AC7.6000002@redhat.com> <468A60E4.7000503@redhat.com> Message-ID: <468A6E2C.8010300@redhat.com> Michael DeHaan wrote: > drew einhorn wrote: >> Things are working well on the ESX box now that I'm past the cobbler >> and kickstart misconfigurations. >> >> Every time I create an new vm I need to take a trip though VMware's >> Virtual Infrastructure Client, that I'd really like to avoid. VMware >> has a few more options to besides ram and disk space to configure >> before creating a VM. Haven't taken a close enough look to know >> either how difficult it will be to live without being able to set them >> when the VM is created, or how difficult it would be to extend cobbler >> to handle more VM attributes, or how this maps into all the other >> virtualization toolsets. >> > > Can you see if VMware has any docs for command line creation of guests? > > If so, those attributes could be added in koan fairly easily. I > don't have a test platform, > but would be more than happy to code something up in koan if someone > wanted to test the proof > of concept. Tracking a few additional attributes in cobbler wouldn't > be a problem. > > > >> On 7/2/07, *Michael DeHaan* < mdehaan at redhat.com >> > wrote: >> >> drew einhorn wrote: >> > Cobbler / Koan supports Xen virtualization. >> > >> > Has anyone looked at what it would take to get koan working >> > on other virtualization platforms? I have a VMware ESX box >> > I'd like to be able to use it on. >> > >> >> Not to my knowledge -- though I like the idea. >> >> As far as I'm aware, vmware does understand PXE installation, so >> koan >> would just need a way to create an "empty" guest >> that would PXE itself. I know this is the plan for how we're >> going to >> support fully automatic installs for other >> virtualization types like KVM, Xen hardware virt, etc. >> >> If there are any VMware experts on the list, patches would be >> great :) >> >> It seems like the syntax needed would not need to even access the >> cobbler server the way --virt does today, ex: >> >> koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF >> --virt-name=foo >> [...other options...] >> >> --virt-type could default to "xenparavirt" and current behavior. >> >> --Michael >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> >> >> >> -- >> Drew Einhorn >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 If someone with a VMware install wants to try to get some basic PXE guest creation functionality scripted, I did find some command line info that would be useful. Search for "Command Line Here" ... http://www.vmware.com/vmtn/vmworld/ Starting out shouldn't require any modifications to koan. Basically all it would take is coming up with a script (any language is ok) that took various parameters for setting the MAC, ram, etc, and then initiating PXE (set up through cobbler) and I can see about incorporating that into koan (in other words, koan could invoke that script and foward the parameters it recieved from cobbler along, including any new parameters we would need to create). There are probably other good docs available elsewhere too... --Michael From drew.einhorn at gmail.com Tue Jul 3 15:26:54 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 3 Jul 2007 09:26:54 -0600 Subject: [et-mgmt-tools] VMware? In-Reply-To: <468A60E4.7000503@redhat.com> References: <46891AC7.6000002@redhat.com> <468A60E4.7000503@redhat.com> Message-ID: I just asked over on a VMware list. And got the following link. It's an example command for creating VMware ESX VMs. The book it comes from looks very interesting. http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1243494,00.html On 7/3/07, Michael DeHaan wrote: > > drew einhorn wrote: > > Things are working well on the ESX box now that I'm past the cobbler > > and kickstart misconfigurations. > > > > Every time I create an new vm I need to take a trip though VMware's > > Virtual Infrastructure Client, that I'd really like to avoid. VMware > > has a few more options to besides ram and disk space to configure > > before creating a VM. Haven't taken a close enough look to know > > either how difficult it will be to live without being able to set them > > when the VM is created, or how difficult it would be to extend cobbler > > to handle more VM attributes, or how this maps into all the other > > virtualization toolsets. > > > > Can you see if VMware has any docs for command line creation of guests? > > If so, those attributes could be added in koan fairly easily. I don't > have a test platform, > but would be more than happy to code something up in koan if someone > wanted to test the proof > of concept. Tracking a few additional attributes in cobbler wouldn't > be a problem. > > > > > On 7/2/07, *Michael DeHaan* < mdehaan at redhat.com > > > wrote: > > > > drew einhorn wrote: > > > Cobbler / Koan supports Xen virtualization. > > > > > > Has anyone looked at what it would take to get koan working > > > on other virtualization platforms? I have a VMware ESX box > > > I'd like to be able to use it on. > > > > > > > Not to my knowledge -- though I like the idea. > > > > As far as I'm aware, vmware does understand PXE installation, so > koan > > would just need a way to create an "empty" guest > > that would PXE itself. I know this is the plan for how we're > > going to > > support fully automatic installs for other > > virtualization types like KVM, Xen hardware virt, etc. > > > > If there are any VMware experts on the list, patches would be great > :) > > > > It seems like the syntax needed would not need to even access the > > cobbler server the way --virt does today, ex: > > > > koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF > --virt-name=foo > > [...other options...] > > > > --virt-type could default to "xenparavirt" and current behavior. > > > > --Michael > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > > > > -- > > Drew Einhorn > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Tue Jul 3 16:33:12 2007 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 03 Jul 2007 12:33:12 -0400 Subject: [et-mgmt-tools] [PATCH] Fix virt-manager pause menuitem bug Message-ID: <468A7A48.6040506@redhat.com> Hello, Currently upstream virt-manager has a bug where the pause and resume options disappear from a vm's right-click menu. This can be seen by pausing a machine in the manager, then resuming that machine; the 'pause' option will not be present in the right-click menu for the now active machine. The patch makes the pause button visible if the vm is in any state that isn't VIR_DOMAIN_PAUSED. Signed-off-by: Cole Robinson Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-pause-menuitem.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: From mdehaan at redhat.com Tue Jul 3 16:40:37 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 12:40:37 -0400 Subject: [et-mgmt-tools] VMware? In-Reply-To: References: <46891AC7.6000002@redhat.com> <468A60E4.7000503@redhat.com> Message-ID: <468A7C05.3080408@redhat.com> drew einhorn wrote: > I just asked over on a VMware list. > > And got the following link. It's an example command for creating > VMware ESX VMs. The book it comes from looks very interesting. > > http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1243494,00.html Nice -- even if it is a Windows example :) If you can get one tested that works with a cobbler server (or any /tftpboot tree based on a MAC address), we can probably get something integrated. I am a bit concerned about someone not knowing what to fill in for all of the $values, or when they change. --Michael > > On 7/3/07, *Michael DeHaan* < mdehaan at redhat.com > > wrote: > > drew einhorn wrote: > > Things are working well on the ESX box now that I'm past the > cobbler > > and kickstart misconfigurations. > > > > Every time I create an new vm I need to take a trip though VMware's > > Virtual Infrastructure Client, that I'd really like to > avoid. VMware > > has a few more options to besides ram and disk space to configure > > before creating a VM. Haven't taken a close enough look to know > > either how difficult it will be to live without being able to > set them > > when the VM is created, or how difficult it would be to extend > cobbler > > to handle more VM attributes, or how this maps into all the other > > virtualization toolsets. > > > > Can you see if VMware has any docs for command line creation of > guests? > > If so, those attributes could be added in koan fairly easily. I > don't > have a test platform, > but would be more than happy to code something up in koan if someone > wanted to test the proof > of concept. Tracking a few additional attributes in cobbler wouldn't > be a problem. > > > > > On 7/2/07, *Michael DeHaan* < mdehaan at redhat.com > > > >> wrote: > > > > drew einhorn wrote: > > > Cobbler / Koan supports Xen virtualization. > > > > > > Has anyone looked at what it would take to get koan working > > > on other virtualization platforms? I have a VMware ESX box > > > I'd like to be able to use it on. > > > > > > > Not to my knowledge -- though I like the idea. > > > > As far as I'm aware, vmware does understand PXE > installation, so koan > > would just need a way to create an "empty" guest > > that would PXE itself. I know this is the plan for how we're > > going to > > support fully automatic installs for other > > virtualization types like KVM, Xen hardware virt, etc. > > > > If there are any VMware experts on the list, patches would > be great :) > > > > It seems like the syntax needed would not need to even > access the > > cobbler server the way --virt does today, ex: > > > > koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF > --virt-name=foo > > [...other options...] > > > > --virt-type could default to "xenparavirt" and current > behavior. > > > > --Michael > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > > > > -- > > Drew Einhorn > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > > > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Daniel.Hennessey at aah.co.uk Tue Jul 3 16:42:48 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Tue, 3 Jul 2007 17:42:48 +0100 Subject: [et-mgmt-tools] VMware? Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C60@GBW607SC0054.GB-WS.net> For GSX server (the freely available one) the process is pretty much the same. 1 create the vmx file (well documented format) 2 create the disk image (using vmdiskmanager on GSX) 3 register the VM using "vmware-cmd -s register " Cheers Dan -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of drew einhorn Sent: 03 July 2007 4:27 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] VMware? I just asked over on a VMware list. And got the following link. It's an example command for creating VMware ESX VMs. The book it comes from looks very interesting. http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci124 3494,00.html On 7/3/07, Michael DeHaan < mdehaan at redhat.com > wrote: drew einhorn wrote: > Things are working well on the ESX box now that I'm past the cobbler > and kickstart misconfigurations. > > Every time I create an new vm I need to take a trip though VMware's > Virtual Infrastructure Client, that I'd really like to avoid. VMware > has a few more options to besides ram and disk space to configure > before creating a VM. Haven't taken a close enough look to know > either how difficult it will be to live without being able to set them > when the VM is created, or how difficult it would be to extend cobbler > to handle more VM attributes, or how this maps into all the other > virtualization toolsets. > Can you see if VMware has any docs for command line creation of guests? If so, those attributes could be added in koan fairly easily. I don't have a test platform, but would be more than happy to code something up in koan if someone wanted to test the proof of concept. Tracking a few additional attributes in cobbler wouldn't be a problem. > On 7/2/07, *Michael DeHaan* < mdehaan at redhat.com > > wrote: > > drew einhorn wrote: > > Cobbler / Koan supports Xen virtualization. > > > > Has anyone looked at what it would take to get koan working > > on other virtualization platforms? I have a VMware ESX box > > I'd like to be able to use it on. > > > > Not to my knowledge -- though I like the idea. > > As far as I'm aware, vmware does understand PXE installation, so koan > would just need a way to create an "empty" guest > that would PXE itself. I know this is the plan for how we're > going to > support fully automatic installs for other > virtualization types like KVM, Xen hardware virt, etc. > > If there are any VMware experts on the list, patches would be great :) > > It seems like the syntax needed would not need to even access the > cobbler server the way --virt does today, ex: > > koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF --virt-name=foo > [...other options...] > > --virt-type could default to "xenparavirt" and current behavior. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Drew Einhorn ************************************************************************ DISCLAIMER The information contained in this e-mail is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply e-mail and then delete it from your system. Please do not copy it or use it for any other purposes, or disclose the content of the e-mail to any other person or store or copy the information in any medium. The views contained in this e-mail are those of the author and not necessarily those of Admenta UK Group. Admenta UK plc is a company incorporated in England and Wales under company number 3011757 and whose registered office is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX ************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Jul 3 18:31:26 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 14:31:26 -0400 Subject: [et-mgmt-tools] cobbler import arch problem In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C5F@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C5F@GBW607SC0054.GB-WS.net> Message-ID: <468A95FE.3060100@redhat.com> Hennessey Daniel wrote: > Michael, > > I was importing from an existing local tree (copied from the CD set) > using; > > cobbler import --name=RHEL44-x86-64 > --mirror=/var/www/html/pub/yum/4AS/x86-64/up4 > > Where "/var/www/html/pub/yum/4AS/x86-64/up4" is the root directory of > the installation tree. > > Looks like you didn't need to take as many steps. cobbler import --name=RHEL4u4 --mirror=/mnt/cdrom or ... losetup /dev/loop0 /path/to/rhel4u4.iso mount /dev/loop0 /tmp/loop0 cobbler import --name=RHEL4u4 /tmp/loop0 umount /dev/loop0 losetup -d /dev/loop0 Cobbler will add in the arch information to the name of the distro object automatically, so leaving off the x86_64 is ok. If you've copied it yourself, cobbler probably can't automagically figure out the directory structure. > Thanks for the help, cobbler still rules. > > Dan. > > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com > [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: 03 July 2007 3:42 PM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] cobbler import arch problem > > > Hennessey Daniel wrote: > >> using cobbler to import an existing x86-64 distro tree but when I do a >> "cobbler distro report" it says the distro's arch is x86. >> >> I can use "cobbler distro add" and explicitly state the arch but this >> leaves the distro tree in place and I was hoping to import all my >> kickstart trees to be managed by cobbler. >> >> Any clues? >> >> > > This shouldn't happen, but it won't cause any adverse results... what > distro source were you using for the import? (i.e. RHEL 4 DVD? rsync > mirror?). If you can > give me further info I'll take a look at see what's wrong with the > auto-detection. > > Cobbler uses the arch field to decide when to set up for different > bootloaders, such as "ia64" implying elilo. It doesn't pay attention > to the difference between > x86 and x86_64 as it uses syslinux either way. > > If you want to fix it, you can run: > > cobbler distro edit --name=foo --arch=x86_64 > > --Michael > > > >> Cheers >> >> Dan >> >> ********************************************************************** >> ** >> >> DISCLAIMER >> >> The information contained in this e-mail is confidential and is >> intended >> >> for the recipient only. >> >> If you have received it in error, please notify us immediately by >> reply >> >> e-mail and then delete it from your system. Please do not copy it or >> >> use it for any other purposes, or disclose the content of the e-mail >> >> to any other person or store or copy the information in any medium. >> >> The views contained in this e-mail are those of the author and not >> >> necessarily those of Admenta UK Group. >> >> Admenta UK plc is a company incorporated in England and Wales >> >> under company number 3011757 and whose registered office >> >> is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX >> >> ********************************************************************** >> ** >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> 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 adamwolf at feelslikeburning.com Tue Jul 3 19:27:09 2007 From: adamwolf at feelslikeburning.com (adamwolf at feelslikeburning.com) Date: Tue, 3 Jul 2007 12:27:09 -0700 (PDT) Subject: [et-mgmt-tools] Detect System from MAC Address Koan Patch Message-ID: <63255.128.101.154.21.1183490829.squirrel@webmail.feelslikeburning.com> This patch enables a --autodetect-system argument to koan. It's for use with --replace-self. When --autodetect-system is used, koan gets the local mac address, compares it to the listed mac addresses it got from xmlrpc information. If there is a single match, that system is set, and the --replace-self process goes on as usual. The patch is off the 0.5.0 release. Currently, it grabs the mac address through some parsing of the output of ifconfig. This is non-ideal and is marked as such in the comments. I was pointed to some code that used rhpl, but that would require a new import in koan. Adam Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: autodetect-systems.patch Type: application/octet-stream Size: 3288 bytes Desc: not available URL: From mdehaan at redhat.com Tue Jul 3 19:38:24 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 03 Jul 2007 15:38:24 -0400 Subject: [et-mgmt-tools] Detect System from MAC Address Koan Patch In-Reply-To: <63255.128.101.154.21.1183490829.squirrel@webmail.feelslikeburning.com> References: <63255.128.101.154.21.1183490829.squirrel@webmail.feelslikeburning.com> Message-ID: <468AA5B0.5040403@redhat.com> adamwolf at feelslikeburning.com wrote: > This patch enables a --autodetect-system argument to koan. It's for use > with --replace-self. When --autodetect-system is used, koan gets the > local mac address, compares it to the listed mac addresses it got from > xmlrpc information. If there is a single match, that system is set, and > the --replace-self process goes on as usual. > > The patch is off the 0.5.0 release. > > Currently, it grabs the mac address through some parsing of the output of > ifconfig. This is non-ideal and is marked as such in the comments. I was > pointed to some code that used rhpl, but that would require a new import > in koan. > > Adam Wolf > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I really like this idea for doing re-imaging -- a good use case would be for a lot of public terminal setups that do nightly reinstalls, etc -- but for whatever reason didn't want to just use --profile ... or want the abstraction capability to change what profile a system is pointed to. I may tweak this slightly to make the argument duplication checks a bit simpler, but otherwise, a good patch. I'll include this shortly. Thanks! --Michael From jim at rossberry.com Tue Jul 3 22:12:46 2007 From: jim at rossberry.com (Jim Wildman) Date: Tue, 3 Jul 2007 18:12:46 -0400 (EDT) Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <468A6BDD.6020709@redhat.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> Message-ID: On Tue, 3 Jul 2007, Michael DeHaan wrote: > Just as an update, I was talking with Jereon van Meeuwen and Jonathan Steffan > on #cobbler yesterday, and we bounced around a few ideas. > > One idea is a LiveCD that invokes koan. This would allow for PXEing in > environments that have a cobbler server, but can't have a PXE server. They > have an early test build, though it has some trouble detecting hard drives > (apparently due to something with libata). As this also could be > accomplished with a hacked up syslinux PXE boot image and a standard > /tftpboot tree, there may be other ways to accomplish this worth exploring. > > Another idea is importing a cobbler profile and making a (non-networked) > installable Live CD out of it -- pulling the needed packages from the various > local cobbler repos onto the CD. > This would be extremely useful to us. +100 :-) ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine From berrange at redhat.com Wed Jul 4 04:36:59 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Jul 2007 05:36:59 +0100 Subject: [et-mgmt-tools] [PATCH 1/2] Build and install locale files if present. In-Reply-To: <46895F7D.3020709@redhat.com> References: <46895B8F.3010905@redhat.com> <46895F7D.3020709@redhat.com> Message-ID: <20070704043659.GH29093@redhat.com> On Mon, Jul 02, 2007 at 04:26:37PM -0400, Cole Robinson wrote: > This patch contains the necessary changes to the build/install process > to accommodate locale files. The main changes are in the setup.py script > where several operations were overloaded to > > 1) Build any .po files it finds in the po directory to .mo > 2) Place these files in INSTALLROOT/share/locale as appropriate > 3) Do appropriate locale path replacement in __init__.py so > virtinst knows where to find the locale files. > > I'm not sure if their is a better place for the gettext includes than > __init__.py, but it seems to work for the library and the scripts that > use it (virt-install and virt-clone). Its a bit of a problem because it will clash with the translation catalog installed by virt-manager. So the combo of gettext.install(gettext_app, gettext_dir) Along with the use of '_' will end up trying to pull translations from virt-manager's catalog. What you need to do is not call gettext.intsall or locale.setlocal at all - simple have the bindtextdomain call in the __init__ file. Then you need to define a convenience wrapper using dgettext def _virtinst(msg): return gettext.dgettext(getext_app, msg) And finally, in each of the virtinst .py files I think you need: from virtinst import _virtinst as _ Finally, the virt-install, and virt-clone commands also need to have the locale.setlocale, and gettext.install commands in them. This all basically is to make sure that if used from virt-install/virt-clone the global message catalog is install, but if used from virt-manager it is not installed. If you see what i mean. Its a little hairy :-) 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 Jul 4 04:38:08 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Jul 2007 05:38:08 +0100 Subject: [et-mgmt-tools] [PATCH 2/2] Internationalize all appropriate strings In-Reply-To: <468960E5.8090806@redhat.com> References: <46895B8F.3010905@redhat.com> <468960E5.8090806@redhat.com> Message-ID: <20070704043808.GI29093@redhat.com> On Mon, Jul 02, 2007 at 04:32:37PM -0400, Cole Robinson wrote: > Cole Robinson wrote: > >Hello all, > > > >The following 2 patches add internationalization support to virtinst, > >virt-install and virt-clone. > > > > This is the grunt work of the internationalization: adding gettext > support to all relevant strings, and touching up wording to be more > translation friendly. This all looks correct to me. 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 Jul 4 04:38:52 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Jul 2007 05:38:52 +0100 Subject: [et-mgmt-tools] [PATCH] Fix virt-manager pause menuitem bug In-Reply-To: <468A7A48.6040506@redhat.com> References: <468A7A48.6040506@redhat.com> Message-ID: <20070704043852.GJ29093@redhat.com> On Tue, Jul 03, 2007 at 12:33:12PM -0400, Cole Robinson wrote: > Hello, > > Currently upstream virt-manager has a bug where the pause and resume > options disappear from a vm's right-click menu. This can be seen by > pausing a machine in the manager, then resuming that machine; the > 'pause' option will not be present in the right-click menu for the now > active machine. > > The patch makes the pause button visible if the vm is in any > state that isn't VIR_DOMAIN_PAUSED. Yikes, nice catch. 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 sakaia at jp.fujitsu.com Wed Jul 4 08:36:43 2007 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Wed, 04 Jul 2007 17:36:43 +0900 Subject: [et-mgmt-tools] [PATCH] Fix typo in virt-clone manual Message-ID: <200707040836.l648arNr032454@fjmscan503.ms.jp.fujitsu.com> Hi, This patch fixes typo in virt-clone manual. (checked by ispell) Signed-off-by: Atsushi SAKAI Thanks Atsushi SAKAI -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone-typo.patch Type: application/octet-stream Size: 3847 bytes Desc: not available URL: From lippold at gmail.com Wed Jul 4 10:39:32 2007 From: lippold at gmail.com (Aaron Lippold) Date: Wed, 4 Jul 2007 12:39:32 +0200 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <468A6BDD.6020709@redhat.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> Message-ID: <39d2723b0707040339j6e438d58n7b351e61f8aa408e@mail.gmail.com> Very cool. I am happy that you guys were able to pick out a way ahead. I am also very happy to see that the new features will make it into the 2.0.x branch. I am going to work on the RHEL5 builds of Revisor today and see how that goes, but first I have to build and install a non-PAE kernel for my Pen. M stupidity of a laptop that I have at the moment from work. Let me know if I can help, sell, pitch, etc. Aaron On 7/3/07, Michael DeHaan wrote: > Michael DeHaan wrote: > > Aaron Lippold wrote: > >> Hi Mike, > >> > >> I just wanted to let you know that the Revisor folks are very > >> interested in an integration / partnership with Cobbler. They said, > >> "we well * definitely * be putting cobbler integration into Revisor > >> 2.1.x..." . > > Just as an update, I was talking with Jereon van Meeuwen and Jonathan > Steffan on #cobbler yesterday, and we bounced around a few ideas. > > One idea is a LiveCD that invokes koan. This would allow for PXEing in > environments that have a cobbler server, but can't have a PXE server. > They have an early test build, though it has some trouble detecting hard > drives (apparently due to something with libata). As this also could > be accomplished with a hacked up syslinux PXE boot image and a standard > /tftpboot tree, there may be other ways to accomplish this worth exploring. > > Another idea is importing a cobbler profile and making a (non-networked) > installable Live CD out of it -- pulling the needed packages from the > various local cobbler repos onto the CD. > > --Michael > > > > _______________________________________________ > 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 Jul 4 14:10:28 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 04 Jul 2007 10:10:28 -0400 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> Message-ID: <468BAA54.40908@redhat.com> Jim Wildman wrote: > On Tue, 3 Jul 2007, Michael DeHaan wrote: > >> Just as an update, I was talking with Jereon van Meeuwen and Jonathan >> Steffan on #cobbler yesterday, and we bounced around a few ideas. >> >> One idea is a LiveCD that invokes koan. This would allow for PXEing >> in environments that have a cobbler server, but can't have a PXE >> server. They have an early test build, though it has some trouble >> detecting hard drives (apparently due to something with libata). As >> this also could be accomplished with a hacked up syslinux PXE boot >> image and a standard /tftpboot tree, there may be other ways to >> accomplish this worth exploring. >> >> Another idea is importing a cobbler profile and making a >> (non-networked) installable Live CD out of it -- pulling the needed >> packages from the various local cobbler repos onto the CD. >> > > This would be extremely useful to us. +100 :-) Revisor currently has some issues detecting hard drives in computers (which I hope can be resolved), though I've also had some suggestions on how to do this with Live CD creator -- the syslinux idea may also work. We'll get it one way or the other :) > > ------------------------------------------------------------------------ > Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com > "Society in every state is a blessing, but Government, even in its best > state, is a necessary evil; in its worst state, an intolerable one." > Thomas Paine > > _______________________________________________ > 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 Jul 4 14:16:09 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 04 Jul 2007 10:16:09 -0400 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <39d2723b0707040339j6e438d58n7b351e61f8aa408e@mail.gmail.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> <39d2723b0707040339j6e438d58n7b351e61f8aa408e@mail.gmail.com> Message-ID: <468BABA9.30402@redhat.com> Aaron Lippold wrote: > Very cool. I am happy that you guys were able to pick out a way ahead. > I am also very happy to see that the new features will make it into > the 2.0.x branch. > > I am going to work on the RHEL5 builds of Revisor today and see how > that goes, but first I have to build and install a non-PAE kernel for > my Pen. M stupidity of a laptop that I have at the moment from work. > > Let me know if I can help, sell, pitch, etc. Stability is my main concern with using a Revisor based CD at this point. Either way, I want to persue solutions like this. I was pointed towards checking out Live CD creator, which, for what we want to do, may also do the job. --Michael From berrange at redhat.com Wed Jul 4 14:40:24 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Jul 2007 15:40:24 +0100 Subject: [et-mgmt-tools] [PATCH] Fix typo in virt-clone manual In-Reply-To: <200707040836.l648arNr032454@fjmscan503.ms.jp.fujitsu.com> References: <200707040836.l648arNr032454@fjmscan503.ms.jp.fujitsu.com> Message-ID: <20070704144024.GB12174@redhat.com> On Wed, Jul 04, 2007 at 05:36:43PM +0900, Atsushi SAKAI wrote: > This patch fixes typo in virt-clone manual. > (checked by ispell) Thanks, I've applied this. 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 fj0588di at aa.jp.fujitsu.com Thu Jul 5 04:42:54 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Thu, 5 Jul 2007 13:42:54 +0900 Subject: [et-mgmt-tools] [PATCH] Unify the checking of the MAC addressconfliction between virtmanager and virtinstall In-Reply-To: <200706271616.BCJ05296.K99GEJ60@aa.jp.fujitsu.com> References: <200706271351.IIC90127.69E0GKJ9@aa.jp.fujitsu.com> <200706271411.CCE43276.K96J0E9G@aa.jp.fujitsu.com> <200706271616.BCJ05296.K99GEJ60@aa.jp.fujitsu.com> Message-ID: <200707051342.HJG51017.99EJ06GK@aa.jp.fujitsu.com> Hi Would you give me a comment on this patch? If not, please apply it. Thanks, Shigeki Sakamoto. > Hi, > > Behavior after the check of the repetition of the MAC address of virt-manager(create guest) > is different from virt-install. > > *** virt-manager *** > After having output warning message "Do you really want to use the MAC address ?", > let a user choose behavior with "Yes" or "No". > > *** virt-install *** > In the case of repetition with the MAC address of the host: > -> It becomes the error and lets a user input it MAC address again. > In the case of repetition with the MAC address of the another active guest: > -> It becomes the error and lets a user input it MAC address again. > In the case of repetition with the MAC address of the another inactive guest: > -> After having output warning message, Installation continues. > > Therefore I made the patch which adjusted behavior of virt-manager to virt-install. > (Because add_hardware is similar Wizard, I make it the same behavior.) > > Incidentally, because items in NIC setting wizard is not initialized, I initialize it. > > > Signed-off-by: Shigeki Sakamoto > > Thanks, > Shigeki Sakamoto. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From kanarip at kanarip.com Thu Jul 5 09:34:37 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 05 Jul 2007 11:34:37 +0200 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <468BAA54.40908@redhat.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> <468BAA54.40908@redhat.com> Message-ID: <468CBB2D.70705@kanarip.com> Michael DeHaan wrote: > Revisor currently has some issues detecting hard drives in computers That would be the stock F7 kernel including the updated F7 kernel having trouble with detecting hard drives in computers, not Revisor ;-) Kind regards, Jeroen van Meeuwen -kanarip From mdehaan at redhat.com Thu Jul 5 14:38:15 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 05 Jul 2007 10:38:15 -0400 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <468CBB2D.70705@kanarip.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> <468BAA54.40908@redhat.com> <468CBB2D.70705@kanarip.com> Message-ID: <468D0257.6030001@redhat.com> Jeroen van Meeuwen wrote: > Michael DeHaan wrote: > >> Revisor currently has some issues detecting hard drives in computers >> > > That would be the stock F7 kernel including the updated F7 kernel having > trouble with detecting hard drives in computers, not Revisor ;-) > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > s/Revisor/Revisor output/... From thestrider at gmail.com Thu Jul 5 19:28:53 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Thu, 05 Jul 2007 15:28:53 -0400 Subject: [et-mgmt-tools] [PATCH] Redundant checks in Koan's app.py In-Reply-To: <200707040836.l648arNr032454@fjmscan503.ms.jp.fujitsu.com> References: <200707040836.l648arNr032454@fjmscan503.ms.jp.fujitsu.com> Message-ID: <468D4675.3080900@gmail.com> The run() method for Koan starts off by checking to see if the server attribute is defined. Later on, in the same method, the same check occurs. Patch attached to save a clock tick or two... :) -Adam --- app.py.orig 2007-07-04 21:56:10.000000000 -0400 +++ app.py 2007-07-05 15:23:03.000000000 -0400 @@ -160,8 +160,6 @@ raise InfoException, "must use either --virt or --replace-self" if self.is_virt and self.is_auto_kickstart: raise InfoException, "must use either --virt or --replace-self" - if not self.server: - raise InfoException, "no server specified" if self.verbose is None: self.verbose = True if (not self.profile and not self.system): From mdehaan at redhat.com Thu Jul 5 20:08:36 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 05 Jul 2007 16:08:36 -0400 Subject: [et-mgmt-tools] [PATCH] Redundant checks in Koan's app.py In-Reply-To: <468D4675.3080900@gmail.com> References: <200707040836.l648arNr032454@fjmscan503.ms.jp.fujitsu.com> <468D4675.3080900@gmail.com> Message-ID: <468D4FC4.60907@redhat.com> Adam Rosenwald wrote: > The run() method for Koan starts off by checking to see if the server > attribute is defined. Later on, in the same method, the same check > occurs. Patch attached to save a clock tick or two... :) > > -Adam > > --- app.py.orig 2007-07-04 21:56:10.000000000 -0400 > +++ app.py 2007-07-05 15:23:03.000000000 -0400 > @@ -160,8 +160,6 @@ > raise InfoException, "must use either --virt or > --replace-self" > if self.is_virt and self.is_auto_kickstart: > raise InfoException, "must use either --virt or > --replace-self" > - if not self.server: > - raise InfoException, "no server specified" > if self.verbose is None: > self.verbose = True > if (not self.profile and not self.system): > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Applied, thanks! From kanarip at kanarip.com Thu Jul 5 22:25:09 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 06 Jul 2007 00:25:09 +0200 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <468D0257.6030001@redhat.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> <468BAA54.40908@redhat.com> <468CBB2D.70705@kanarip.com> <468D0257.6030001@redhat.com> Message-ID: <468D6FC5.5030302@kanarip.com> Michael DeHaan wrote: > Jeroen van Meeuwen wrote: >> Michael DeHaan wrote: >> >>> Revisor currently has some issues detecting hard drives in computers >>> >> >> That would be the stock F7 kernel including the updated F7 kernel having >> trouble with detecting hard drives in computers, not Revisor ;-) >> >> Kind regards, >> >> Jeroen van Meeuwen >> -kanarip >> >> > s/Revisor/Revisor output/... > Let's not play that game; it's not Revisor (nor it's output) rather then we just spun you /a/ disc that showed you how koan /could be/ a livecd. We could have done so on CentOS 4.0-5, 5, Fedora Core 6 and/or Fedora 7. The latter being the buggy one not recognizing some drives. Again, *not* Revisor (and *not* it's output either). It seems we shouldn't have done that, just so that we could keep up appearances. If that all doesn't sound "enterprisey" enough, download the kickstart and build a CentOS based Koan LiveCD, or let me know and I'll build you one. Kind regards, Jeroen van Meeuwen -kanarip From mdehaan at redhat.com Thu Jul 5 23:19:18 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 05 Jul 2007 19:19:18 -0400 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <468D6FC5.5030302@kanarip.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> <468BAA54.40908@redhat.com> <468CBB2D.70705@kanarip.com> <468D0257.6030001@redhat.com> <468D6FC5.5030302@kanarip.com> Message-ID: <468D7C76.90605@redhat.com> Jeroen van Meeuwen wrote: > Michael DeHaan wrote: > >> Jeroen van Meeuwen wrote: >> >>> Michael DeHaan wrote: >>> >>> >>>> Revisor currently has some issues detecting hard drives in computers >>>> >>>> >>> That would be the stock F7 kernel including the updated F7 kernel having >>> trouble with detecting hard drives in computers, not Revisor ;-) >>> >>> Kind regards, >>> >>> Jeroen van Meeuwen >>> -kanarip >>> >>> >>> >> s/Revisor/Revisor output/... >> >> > > Let's not play that game; it's not Revisor (nor it's output) rather then > we just spun you /a/ disc that showed you how koan /could be/ a livecd. > We could have done so on CentOS 4.0-5, 5, Fedora Core 6 and/or Fedora 7. > The latter being the buggy one not recognizing some drives. Again, *not* > Revisor (and *not* it's output either). It seems we shouldn't have done > that, just so that we could keep up appearances. If that all doesn't > sound "enterprisey" enough, download the kickstart and build a CentOS > based Koan LiveCD, or let me know and I'll build you one. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > Jerowen, There's no game. That's great if Revisor Live CD output for other distros would not have this problem. I believe Jon indicated on IRC that Revisor had issues about detecting drives because of it's usage of a newer-than-normal libata (or somesuch) and that you were seeing frequent issues with SATA and ATA drives on sda not showing up. I do know that F7's installer on this particular machine does accurately detect the drives in question, so it doesn't seem to be a kernel problem. I asked if this was being looked at, and was told I would need to fix it myself. Fair enough. I'd prefer to not debug that if I don't have to. I'm currently looking at livecd-creator because Fedora uses it and it's really all I need. LiveCD creator appears to do what I want, and if Revisor wants to build koan Live CD's, that's great too. In the end, the tool doesn't matter, as long as it gets the job done for the people who use it. --Michael From sakaia at jp.fujitsu.com Fri Jul 6 06:55:14 2007 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Fri, 06 Jul 2007 15:55:14 +0900 Subject: [et-mgmt-tools] When next release is available? Message-ID: <200707060655.l666tOMe029845@fjmscan503.ms.jp.fujitsu.com> Hi, I have a question about virtinst release schedule. When does the next release available? Thanks Atsushi SAKAI From kanarip at kanarip.com Fri Jul 6 10:09:51 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 06 Jul 2007 12:09:51 +0200 Subject: [et-mgmt-tools] Revisor / Cobbler and Revisor for CentOS5/RHEL5 In-Reply-To: <468D7C76.90605@redhat.com> References: <39d2723b0707011456s29e1af48mcc240ea217846f2@mail.gmail.com> <46891673.30407@redhat.com> <468A6BDD.6020709@redhat.com> <468BAA54.40908@redhat.com> <468CBB2D.70705@kanarip.com> <468D0257.6030001@redhat.com> <468D6FC5.5030302@kanarip.com> <468D7C76.90605@redhat.com> Message-ID: <468E14EF.1000909@kanarip.com> Michael DeHaan wrote: > I believe Jon indicated on IRC that Revisor had issues about detecting > drives because of it's usage of a newer-than-normal libata (or somesuch) > and that you were seeing frequent issues with SATA and ATA drives on > sda not showing up. I do know that F7's installer on this particular > machine does accurately detect the drives in question, so it doesn't > seem to be a kernel problem. I asked if this was being looked at, and > was told I would need to fix it myself. Fair enough. I'd prefer to > not debug that if I don't have to. > Luckily the F7 installer doesn't use mayflower to compose initrd's, but (upstream!) livecd-tools does. I'm not sure if that actually contributes in creating the issue but it sure is one difference. > I'm currently looking at livecd-creator because Fedora uses it and it's > really all I need. LiveCD creator appears to do what I want, and if > Revisor > wants to build koan Live CD's, that's great too. In the end, the tool > doesn't matter, as long as it gets the job done for the people who use it. > Frankly, Revisor uses that same livecd-tools. We're as close to upstream as we can be, given that we have to clone their codebase to be able to create a file that does allow python to import it, and allow further customization by importing that and extending it where we need to. If someone can hand us a case where the same media created with livecd-tools does work, and the media created with livecd-tools via Revisor doesn't, then I'll be the first to admit it's my mistake after all and Revisor is to blame. Kind regards, Jeroen van Meeuwen -kanarip From fukuta.saori at jp.fujitsu.com Fri Jul 6 10:19:44 2007 From: fukuta.saori at jp.fujitsu.com (Saori Fukuta) Date: Fri, 06 Jul 2007 19:19:44 +0900 Subject: [et-mgmt-tools] [PATCH] can not specify the type of driver device In-Reply-To: <20070702181447.CBBA.FUKUTA.SAORI@jp.fujitsu.com> References: <20070702181447.CBBA.FUKUTA.SAORI@jp.fujitsu.com> Message-ID: <20070706191937.C72B.FUKUTA.SAORI@jp.fujitsu.com> Hi, Would you give me a comment on this patch ? If everything is OK, please apply it. Thanks, Saori Fukuta On Mon, 02 Jul 2007 18:29:03 +0900 Saori Fukuta wrote: > Hi, > > I opened the new bugzilla: > Bugzilla Bug 246441: can not specify the type of driver device > URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246441 > > And I attached the patch to fix this problem. > > Thanks, > Saori Fukuta > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From adamwolf at feelslikeburning.com Fri Jul 6 16:23:19 2007 From: adamwolf at feelslikeburning.com (adamwolf at feelslikeburning.com) Date: Fri, 6 Jul 2007 09:23:19 -0700 (PDT) Subject: [et-mgmt-tools] LiveCD installs Message-ID: <62392.128.101.154.21.1183738999.squirrel@webmail.feelslikeburning.com> I've written a CGI script and documented a process for making live CDs that works with Cobbler. My script simply returns the appropriate kickstart file. The kickstart can be specified manually, with parameters appended to the url??profile=foo or ?system=baz?or with no parameters, the script will look the requesting IP address up through an XML-RPC call to Cobbler to find the appropriate system, and use that kickstart. The main idea behind the live CD is simple?append ks=http://path/to/the/cgi/script.py to the isolinux.cfg file on a live CD with Anaconda. I use the Fedora rescue disks. They?re fairly small, under 100 megs, and have some useful things built in. However, you can do some cool stuff beyond adding the kickstart url. I've put together a cobbler splash, and changed the menu. I have pictures and a little more detail on modifying the livecd on my web site: http://feelslikeburning.com/projects/live-cd-restoring-with-cobbler/ I figure most everyone on the list is already familiar with the process, so I won't paste it all in here. Adam Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: install-from-cobbler.py Type: application/octet-stream Size: 1664 bytes Desc: not available URL: From adamwolf at feelslikeburning.com Fri Jul 6 16:33:28 2007 From: adamwolf at feelslikeburning.com (adamwolf at feelslikeburning.com) Date: Fri, 6 Jul 2007 09:33:28 -0700 (PDT) Subject: [et-mgmt-tools] Re: LiveCD installs Message-ID: <62817.128.101.154.21.1183739608.squirrel@webmail.feelslikeburning.com> Silly me. Sending the wrong script out. Attached is the proper script. Adam Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: install-from-cobbler.py Type: application/octet-stream Size: 1769 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Jul 8 11:21:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 8 Jul 2007 13:21:17 +0200 Subject: [et-mgmt-tools] Re: "Could not communicate with" error In-Reply-To: <465DBEB3.8090500@redhat.com> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> <465DBEB3.8090500@redhat.com> Message-ID: <20070708112117.GA4177@puariko.nirvana> On Wed, May 30, 2007 at 02:13:07PM -0400, Michael DeHaan wrote: > Bill McGonigle wrote: > > > >On May 30, 2007, at 10:43, Michael DeHaan wrote: > > > >> > >>If this is a fresh install, most likely you haven't rebooted so > >>cobblerd didn't come on automatically. > >> > >>/sbin/service cobblerd start > >> > >>Otherwise it might be a firewall issue, in which case you want to > >>unblock TCP port 25151. > > > >Thanks, for the response, Michael. As I mentioned, cobblerd is > >running, I can telnet to the port, and I tried turning off iptables. > My apologies on my reading comprehension. Judging from the system name, > you've found a bug with system names not being something I ordinarily > expect them to be. Thankfully, there is an easy workaround that will do > what you want. > > Explanation -- What's going on is Cobbler system objects ("cobbler > system add --name=$name") really like to be IP's or hostnames, because > these are things that bootloaders understand. PXE, for instance, can't > key off of a hostname. In most places, if a hostname is given, cobbler > internally maps it to it's resolved IP when setting up a PXE tree. This > is really needless because it causes a bunch of dns lookups in an area > of the code that shouldn't have to be doing this. So, best practices > should state that cobbler system objects, as currently implemented, > should be keyed off of MAC addresses, not hostnames. Now, this > restriction really shouldn't apply to virt, so what we'll have > eventually is allowing any value for --name and have a seperate > parameter for specifying the --mac-address (and we already have > --ip-address upstream). If --mac-address isn't specified, you'll still > be able to create system objects, they just won't be PXE-able. > > It would look something like this: > > cobbler system add --name=this_is_just_a_description > [--mac-address=AA:BB:CC:DD:EE:FF] [--ip-address=192.168.1.50] > > So, how to get around the above problem? > > Unless you need system specific kickstart templating, you can install > koan using profiles, and it's much simpler. You won't have to create > cobbler system objects for the machines unless you want cobbler to > manage your DHCP and/or DNS features for these systems -- and in which > case, you should be creating a system object that is keyed off a MAC > address. I'm in need of system specific kickstart templating & xen. Is there any way to apply some workaround for this case? Or maybe I need to use the testing version of cobbler and koan? I'm currently using 0.4.8/0.4.0 respectively and server and client are both RHEL5. > So, how to run koan with profiles? > [...] -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Jul 8 12:08:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 8 Jul 2007 14:08:30 +0200 Subject: [et-mgmt-tools] Re: "Could not communicate with" error In-Reply-To: <20070708112117.GA4177@puariko.nirvana> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> <465DBEB3.8090500@redhat.com> <20070708112117.GA4177@puariko.nirvana> Message-ID: <20070708120830.GB4177@puariko.nirvana> On Sun, Jul 08, 2007 at 01:21:17PM +0200, Axel Thimm wrote: > On Wed, May 30, 2007 at 02:13:07PM -0400, Michael DeHaan wrote: > > Bill McGonigle wrote: > > > > > >On May 30, 2007, at 10:43, Michael DeHaan wrote: > > > > > >> > > >>If this is a fresh install, most likely you haven't rebooted so > > >>cobblerd didn't come on automatically. > > >> > > >>/sbin/service cobblerd start > > >> > > >>Otherwise it might be a firewall issue, in which case you want to > > >>unblock TCP port 25151. > > > > > >Thanks, for the response, Michael. As I mentioned, cobblerd is > > >running, I can telnet to the port, and I tried turning off iptables. > > > My apologies on my reading comprehension. Judging from the system name, > > you've found a bug with system names not being something I ordinarily > > expect them to be. Thankfully, there is an easy workaround that will do > > what you want. > > > > Explanation -- What's going on is Cobbler system objects ("cobbler > > system add --name=$name") really like to be IP's or hostnames, because > > these are things that bootloaders understand. PXE, for instance, can't > > key off of a hostname. In most places, if a hostname is given, cobbler > > internally maps it to it's resolved IP when setting up a PXE tree. This > > is really needless because it causes a bunch of dns lookups in an area > > of the code that shouldn't have to be doing this. So, best practices > > should state that cobbler system objects, as currently implemented, > > should be keyed off of MAC addresses, not hostnames. Now, this > > restriction really shouldn't apply to virt, so what we'll have > > eventually is allowing any value for --name and have a seperate > > parameter for specifying the --mac-address (and we already have > > --ip-address upstream). If --mac-address isn't specified, you'll still > > be able to create system objects, they just won't be PXE-able. > > > > It would look something like this: > > > > cobbler system add --name=this_is_just_a_description > > [--mac-address=AA:BB:CC:DD:EE:FF] [--ip-address=192.168.1.50] > > > > So, how to get around the above problem? > > > > Unless you need system specific kickstart templating, you can install > > koan using profiles, and it's much simpler. You won't have to create > > cobbler system objects for the machines unless you want cobbler to > > manage your DHCP and/or DNS features for these systems -- and in which > > case, you should be creating a system object that is keyed off a MAC > > address. > > I'm in need of system specific kickstart templating & xen. Is there > any way to apply some workaround for this case? > > Or maybe I need to use the testing version of cobbler and koan? I'm > currently using 0.4.8/0.4.0 respectively and server and client are > both RHEL5. > > > So, how to run koan with profiles? > > [...] To answer my own question: cobbler & koan 0.5.x fixes this, thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mdehaan at redhat.com Mon Jul 9 14:39:47 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 09 Jul 2007 10:39:47 -0400 Subject: [et-mgmt-tools] Re: LiveCD installs In-Reply-To: <62817.128.101.154.21.1183739608.squirrel@webmail.feelslikeburning.com> References: <62817.128.101.154.21.1183739608.squirrel@webmail.feelslikeburning.com> Message-ID: <469248B3.1000806@redhat.com> adamwolf at feelslikeburning.com wrote: > Silly me. Sending the wrong script out. > > Attached is the proper script. > > Adam Wolf > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools This is a neat trick... while you could just serve up the kickstart in question over http:// already, the IP address autodetection allows for having one boot image for multiple cobbler system entries, and have them discovered automatically. In Cobbler 0.5.0, for those unfamiliar, you can do: cobbler system add --name=xyz1234--mac=AA:BB:CC:DD:EE:FF --ip=192.168.5.10 --profile=foo1 cobbler system add --name=xyz1235 --mac=AA:BB:CC:DD:EE:EE --ip=192.168.5.11 --profile=foo2 and in this case, the same modified rescue disk image could reinstall the system appropriately depending on the recognized IP. 192.168.5.10 when booted would get "foo1" and 192.168.5.11 could get "foo2". Nice. This gets us to most of where we want to be going with the full-on Live CD -- which would probably additionally offer: (A) automatic MAC address detection in addition to IP detection (B) having one boot image for all distributions (the above requires a distribution-specific image) I'll include this in 0.5.1 ... if the full-on Live CD makes some of this redundant, it won't hurt anything -- and more importantly, it's already available :) --Michael From mdehaan at redhat.com Mon Jul 9 14:43:59 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 09 Jul 2007 10:43:59 -0400 Subject: [et-mgmt-tools] Re: "Could not communicate with" error In-Reply-To: <20070708112117.GA4177@puariko.nirvana> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> <465DBEB3.8090500@redhat.com> <20070708112117.GA4177@puariko.nirvana> Message-ID: <469249AF.1090800@redhat.com> Axel Thimm wrote: > On Wed, May 30, 2007 at 02:13:07PM -0400, Michael DeHaan wrote: > > > I'm in need of system specific kickstart templating & xen. Is there > any way to apply some workaround for this case? > > Or maybe I need to use the testing version of cobbler and koan? I'm > currently using 0.4.8/0.4.0 respectively and server and client are > both RHEL5. > > Two options: (a) the old way: name your system objects after MAC addresses in the Xen reserved space ... counting up from 00:16:3E:00:00:00 and provision with "koan --virt --system= --server=cobbler.example.com" (a) use cobbler/koan 0.5.0, where systems can be named anything ... From adamwolf at feelslikeburning.com Mon Jul 9 16:17:24 2007 From: adamwolf at feelslikeburning.com (adamwolf at feelslikeburning.com) Date: Mon, 9 Jul 2007 09:17:24 -0700 (PDT) Subject: [et-mgmt-tools] Re: Boot CD Installs (was LiveCD Installs) In-Reply-To: <20070709160021.2FC1B735A3@hormel.redhat.com> References: <20070709160021.2FC1B735A3@hormel.redhat.com> Message-ID: <55268.128.101.154.21.1183997844.squirrel@webmail.feelslikeburning.com> > adamwolf at feelslikeburning.com wrote: >> Silly me. Sending the wrong script out. >> >> Attached is the proper script. >> >> Adam Wolf >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > This is a neat trick... while you could just serve up the kickstart in > question over http:// already, the IP address autodetection allows for > having one boot image for multiple cobbler system entries, and have them > discovered automatically. > > In Cobbler 0.5.0, for those unfamiliar, you can do: > > cobbler system add --name=xyz1234--mac=AA:BB:CC:DD:EE:FF > --ip=192.168.5.10 --profile=foo1 > cobbler system add --name=xyz1235 --mac=AA:BB:CC:DD:EE:EE > --ip=192.168.5.11 --profile=foo2 > > and in this case, the same modified rescue disk image could reinstall > the system appropriately depending on the recognized IP. > 192.168.5.10 when booted would get "foo1" and 192.168.5.11 could get > "foo2". Nice. > > This gets us to most of where we want to be going with the full-on Live > CD -- which would probably additionally offer: > (A) automatic MAC address detection in addition to IP detection > (B) having one boot image for all distributions (the above requires a > distribution-specific image) > > I'll include this in 0.5.1 ... if the full-on Live CD makes some of this > redundant, it won't hurt anything -- and more importantly, it's already > available :) > > --Michael We can append kssendmac to the parameters where ks=http://cobbler.example.org/findks.py is currently, and the mac address is made available through headers. Or something. Supposedly it provides environment variables that can be tested from the CGI to determine the mac address. It would be good to have mac detection in findks.py as well. If the mac resolves with one system, and the IP resolves to another, the mac should have precedence, like in PXE. I'll do this later this week if no one gets to it by then. That should bring this rescue CD solution up to speed and sufficient for a fair amount of real-world scenarios. Adam Wolf From mdehaan at redhat.com Mon Jul 9 16:28:36 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 09 Jul 2007 12:28:36 -0400 Subject: [et-mgmt-tools] [Fwd: Kickstart Tips and Tricks] Message-ID: <46926234.6000301@redhat.com> This post from kickstart list contains some interesting items related to Kickstart Fu that would probably be of interest to most people here who are interested in provisioning. Cobbler has a cameo. Thanks, Chip! If you are not already on kickstart-list, it's http://www.redhat.com/mailman/listinfo/kickstart-list --Michael -------------- next part -------------- An embedded message was scrubbed... From: "Shabazian, Chip" Subject: Kickstart Tips and Tricks Date: Fri, 06 Jul 2007 11:13:13 -0700 Size: 7238 URL: From Axel.Thimm at ATrpms.net Mon Jul 9 17:11:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 9 Jul 2007 19:11:07 +0200 Subject: [et-mgmt-tools] Re: "Could not communicate with" error In-Reply-To: <469249AF.1090800@redhat.com> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> <465DBEB3.8090500@redhat.com> <20070708112117.GA4177@puariko.nirvana> <469249AF.1090800@redhat.com> Message-ID: <20070709171107.GB13014@puariko.nirvana> On Mon, Jul 09, 2007 at 10:43:59AM -0400, Michael DeHaan wrote: > Axel Thimm wrote: > >On Wed, May 30, 2007 at 02:13:07PM -0400, Michael DeHaan wrote: > > > > > >I'm in need of system specific kickstart templating & xen. Is there > >any way to apply some workaround for this case? > > > >Or maybe I need to use the testing version of cobbler and koan? I'm > >currently using 0.4.8/0.4.0 respectively and server and client are > >both RHEL5. > > > > > Two options: > > (a) the old way: name your system objects after MAC addresses in the > Xen reserved space ... counting up from 00:16:3E:00:00:00 > and provision with "koan --virt --system= --server=cobbler.example.com" But that's a catch22 in xen-land > (a) use cobbler/koan 0.5.0, where systems can be named anything ... Of both options, (a) is clearly the preferred one ;) 0.5.0 works fine, thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From crobinso at redhat.com Mon Jul 9 19:49:12 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 09 Jul 2007 15:49:12 -0400 Subject: [et-mgmt-tools] [PATCH 1/2] Build and install locale files if present. In-Reply-To: <20070704043659.GH29093@redhat.com> References: <46895B8F.3010905@redhat.com> <46895F7D.3020709@redhat.com> <20070704043659.GH29093@redhat.com> Message-ID: <46929138.1070405@redhat.com> Daniel P. Berrange wrote: > On Mon, Jul 02, 2007 at 04:26:37PM -0400, Cole Robinson wrote: >> This patch contains the necessary changes to the build/install process >> to accommodate locale files. The main changes are in the setup.py script >> where several operations were overloaded to >> >> 1) Build any .po files it finds in the po directory to .mo >> 2) Place these files in INSTALLROOT/share/locale as appropriate >> 3) Do appropriate locale path replacement in __init__.py so >> virtinst knows where to find the locale files. >> >> I'm not sure if their is a better place for the gettext includes than >> __init__.py, but it seems to work for the library and the scripts that >> use it (virt-install and virt-clone). > > Its a bit of a problem because it will clash with the translation catalog > installed by virt-manager. So the combo of > > gettext.install(gettext_app, gettext_dir) > > Along with the use of '_' will end up trying to pull translations from > virt-manager's catalog. What you need to do is not call gettext.intsall > or locale.setlocal at all - simple have the bindtextdomain call in the > __init__ file. Then you need to define a convenience wrapper using > dgettext > > def _virtinst(msg): > return gettext.dgettext(getext_app, msg) > > And finally, in each of the virtinst .py files I think you need: > > from virtinst import _virtinst as _ > > Finally, the virt-install, and virt-clone commands also need to have the > locale.setlocale, and gettext.install commands in them. > Updated patch is attached. > This all basically is to make sure that if used from virt-install/virt-clone > the global message catalog is install, but if used from virt-manager it is > not installed. If you see what i mean. Its a little hairy :-) Yeah it's definitely confusing, but I think I understand it now :) Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-i18n-install-02.patch Type: text/x-patch Size: 23656 bytes Desc: not available URL: From crobinso at redhat.com Mon Jul 9 19:52:58 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 09 Jul 2007 15:52:58 -0400 Subject: [et-mgmt-tools] [PATCH 2/2] Internationalize all appropriate strings In-Reply-To: <20070704043808.GI29093@redhat.com> References: <46895B8F.3010905@redhat.com> <468960E5.8090806@redhat.com> <20070704043808.GI29093@redhat.com> Message-ID: <4692921A.5040909@redhat.com> Daniel P. Berrange wrote: > > This all looks correct to me. > > Dan. This patch had to be updated as well to accommodate the previous gettext changes. Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-i18n-formatting-02.patch Type: text/x-patch Size: 71105 bytes Desc: not available URL: From drew.einhorn at gmail.com Mon Jul 9 21:37:16 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Mon, 9 Jul 2007 15:37:16 -0600 Subject: [et-mgmt-tools] [Fwd: Kickstart Tips and Tricks] In-Reply-To: <46926234.6000301@redhat.com> References: <46926234.6000301@redhat.com> Message-ID: This paper suggests considering Kickstart Configurator (KC). This was one of the first tools I tried. I found it unsatisfactory. It choked on reading a network configuration with a secondary dns server. I don't like the way it writes it's kickstart files. I write my kickstart files with the commands in a logical order that makes more sense to me. After I make changes using KC the order of the commands is scrambled. And lines I have commented out because I don't want them in the current config, but may change my mind and reinstate them later just disappear. Think there was one more issue but I can't remember it right now. Anyway I decided it way more trouble that it was worth, and stopped using it. On 7/9/07, Michael DeHaan < mdehaan at redhat.com> wrote: > > This post from kickstart list contains some interesting items related to > Kickstart Fu that would probably be of interest to most people here who > are > interested in provisioning. Cobbler has a cameo. Thanks, Chip! > > If you are not already on kickstart-list, it's > http://www.redhat.com/mailman/listinfo/kickstart-list > > --Michael > > All, > > As promised, I have finally completed the presentation for LinuxWorld and > welcome feedback and corrections: > > http://www.shabazian.com/lw2007.pdf > > Thanks, and I hope it's useful to someone. > > Chip > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Mon Jul 9 21:43:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 09 Jul 2007 17:43:05 -0400 Subject: [et-mgmt-tools] [Fwd: Kickstart Tips and Tricks] In-Reply-To: References: <46926234.6000301@redhat.com> Message-ID: <4692ABE9.4060903@redhat.com> drew einhorn wrote: > This paper suggests considering Kickstart Configurator (KC). > > This was one of the first tools I tried. I found it unsatisfactory. > > It choked on reading a network configuration with a secondary dns server. > > I don't like the way it writes it's kickstart files. I write my > kickstart files > with the commands in a logical order that makes more sense to me. > After I make changes using KC the order of the commands is > scrambled. And lines I have commented out because I don't want them > in the current config, but may change my mind and reinstate them > later just disappear. > > Think there was one more issue but I can't remember it right now. > > Anyway I decided it way more trouble that it was worth, and > stopped using it. system-config-kickstart is quite useful for exploring choices in kickstart options. It is true that pykickstart can choke on loading some variations of kickstart files, however. In which case, it's still a nice starting point for building something from scratch, and you can refine the results later. Anyhow, this is more on-topic for kickstart-list :) > > On 7/9/07, *Michael DeHaan* < mdehaan at redhat.com > > wrote: > > This post from kickstart list contains some interesting items > related to > Kickstart Fu that would probably be of interest to most people > here who are > interested in provisioning. Cobbler has a cameo. Thanks, Chip! > > If you are not already on kickstart-list, it's > http://www.redhat.com/mailman/listinfo/kickstart-list > > > --Michael > > All, > > As promised, I have finally completed the presentation for > LinuxWorld and welcome feedback and corrections: > > http://www.shabazian.com/lw2007.pdf > > > Thanks, and I hope it's useful to someone. > > Chip > > _______________________________________________ > Kickstart-list mailing list > [send email to Kickstart-list at redhat.com via gmail] > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > > _______________________________________________ > et-mgmt-tools mailing list > [send email to et-mgmt-tools at redhat.com via gmail] > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From dlutter at redhat.com Mon Jul 9 22:43:42 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 09 Jul 2007 15:43:42 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <20070628225955.GF12711@redhat.com> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> <1182482730.32115.8.camel@galia.watzmann.net> <1182937902.2778.11.camel@blaa> <1183055484.4013.1.camel@galia.watzmann.net> <20070628225955.GF12711@redhat.com> Message-ID: <1184021022.18439.3.camel@galia.watzmann.net> On Thu, 2007-06-28 at 23:59 +0100, Daniel P. Berrange wrote: > On Thu, Jun 28, 2007 at 11:31:24AM -0700, David Lutterkort wrote: > > > > My intention was to have that all in the image tag: > > > > > > > > > > ... > > > > > > > > > > That way, the relative position of existing tags doesn't change, though > > it's really not much of a difference. (Though I find having all the > > storage in one place a little cleaner) > > So is a single top level grouping for multiple elements, > while and are multiple top level elements with no > grouping. > > For consistentency perhaps we should either > > - Kill and have at top level > > Or > > - Add and for grouping the multiple machine > and network elements. I don't follow this - yes, in the abstract it makes sense; but when I look at an actual image.xml, having the storage element there seems to make the XML clearer. I'd change it if that is seen as the crucial issue keeping these patches from being committed. Otherwise, I'd prefer leaving as it is. > BTW, I thing is better called for consistency with the > libvirt naming of . The and elements already > match the libvirt terminology. Heh ;) I had that at some point and somebody objected to calling that .. I'll change the code to use David From thestrider at gmail.com Mon Jul 9 23:13:27 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Mon, 09 Jul 2007 19:13:27 -0400 Subject: [et-mgmt-tools] Virt-disk-path selection patch and other virt. attributes... Message-ID: <4692C117.8080304@gmail.com> Hey Michael et al. The following is an (unpolished) method for virt-path (and a few other discussed virt-attribute methods) in koan's app.py. I've tested it in parts; it appears to work. :) More extensive testing will ensue next week. I also have a comment or two on Michael's last response (inline). Thanks. --- /usr/lib/python2.4/site-packages/koan/app.py.orig 2007-07-04 21:56:10.000000000 -0400 +++ /usr/lib/python2.4/site-packages/koan/app.py 2007-07-06 18:09:41.000000000 -0400 @@ -30,6 +30,8 @@ import xmlrpclib import string +from stat import * + """ koan --virt [--profile=webserver|--system=name] --server=hostname koan --replace-self --profile=foo --server=hostname @@ -160,8 +162,6 @@ raise InfoException, "must use either --virt or --replace-self" if self.is_virt and self.is_auto_kickstart: raise InfoException, "must use either --virt or --replace-self" - if not self.server: - raise InfoException, "no server specified" if self.verbose is None: self.verbose = True if (not self.profile and not self.system): @@ -572,8 +572,10 @@ results = virtcreate.start_paravirt_install( name=name, ram=self.calc_virt_ram(pd), - disk= self.calc_virt_filesize(pd), + disk=self.calc_virt_filesize(pd), + vcpus=self.calc_virt_cpus(pd), mac=virtcreate.get_mac(self.calc_virt_mac(pd)), + path=self.set_virt_path(pd, name, mac), uuid=virtcreate.get_uuid(self.calc_virt_uuid(pd)), kernel=self.safe_load(pd,'kernel_local'), initrd=self.safe_load(pd,'initrd_local'), @@ -583,11 +585,24 @@ print results def calc_virt_uuid(self,data): - # TODO: eventually we may want to allow some koan CLI - # option for passing in the UUID. Until then, it's random. - return None + """ + Assign a UUID if none/invalid is given in the profile. + """ + id = self.safe_load(data,'virt_uuid','xen_uuid',0) + uuid_re = re.compile('[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}') + err = False + try: + str(id) + except: + err = True + if id is None or id == '' or not uuid_re.match(id): + err = True + if err: + self.debug("invalid UUID specified. randomizing...") + return None + return id - def calc_virt_filesize(self,data): + def calc_virt_filesize(self,data,default_filesize=1): """ Assign a virt filesize if none is given in the profile. """ @@ -597,14 +612,14 @@ int(size) except: err = True + if size is None or size == '' or int(size)= int(lv_size): + # Sufficient space + lvs_str=sub_process.Popen(["lvs", "--noheadings", "-o", "lv_name", blk_id], stdout=subprocess.PIPE).communicate()[0] + if name == None: + if not lvs_str.find(mac): + lv_create = sub_process.Popen(["lvcreate", "-L", "%sG" % lv_size, "-n", mac, blk_id], stdout=sub_process.PIPE).communicate()[0] + path="/dev/%s/%s" % (blk_id,mac) + else: + if not lvs_str.find(name): + lv_create = sub_process.Popen(["lvcreate", "-L", "%sG" % lv_size, "-n", name, blk_id], stdout=sub_process.PIPE).communicate()[0] + path="/dev/%s/%s" % (blk_id,name) + else: + raise InfoException, "The volume group [%s] does not have at least %sGB free space." % lv_size + return path + if __name__ == "__main__": main() Michael DeHaan wrote: > Adam Rosenwald wrote: >> Michael, >> >> Here are some starter patches for koan in preparation for a >> proposed migration of virtual attributes to cobbler. The uuid and >> vcpu methods can be used directly with only trivial adjustments to >> virtcreate.py. > > Cool. Some comments below... >> >> This is just some practice for migrating koan virtual attribute >> checking and default assignment over to cobbler profiles. I don't >> know whether you would like this as default behavior, but I was >> thinking that if the user specifies "path" for --virt-path (a >> proposed CL argument for passing the location of a prespecified >> virtual disk file), the following behavior could be taken: >> >> # Since block IO is superior to file IO, check to see if --virt-path >> corresponds to block devices > > I like these ideas. I've revised the following has been revised a > bit... mainly I prefer my arguments to be a bit more predictable in > what they do, and this makes it clearer to to understand (for the > user). It also makes documenting what to specify for --virt-path a > lot simpler. I didn't think of the Volume Group creation idea before, > and if reasonable simple to implement, that would be a great feature. > > Anyhow, for disambigution, let's have the following syntax: > > --virt-path=foo --virt-path=volume-group:foo > --virt-path=partition:foo Full disambiguation would be --virt-path=file:foo --virt-path=vg:foo --virt-path=partition:foo ... but I've stuck with your reasoning, letting --virt-path=foo default to loopback files. > > (And also let's assume that we can override the cobbler value for > --virt-path in koan, if needed.) > >> * For volume groups >> o Does a volume_group exist named --virt_path? >> > Question: what if system.name already > exists in the volume group? Reuse it. The assumption is that the user knows what (s)he's doing. This is already implemented as a check near the end of the set_virt_path method >> >> + If so >> # Calculate how much space is left in VG >> "virt_path" >> # If enough space to create LV with --virt-disk >> size >> * Create new LV named after system.name, >> unless overriden with --virt-name. >> Note that system names in 0.5.0 can be >> arbitrary and are >> > not necessarily > MAC addresses. >> >> * If not enough, FAIL >> >> * For --virt-paths >> > pass %PATH/%virtname into XenDisk , if not in > /var/lib/xen/images and SELinux is enabled, adjust security context > appropriately (chcon). You or someone else will have to implement the SELinux context adjustments. This is a little beyond me for the moment... > > For explicit partitions: > use the LVM partition as entered, if it does not > exist, fail. > Example of koan value being overridden by koan: > > cobbler profile add --name=foo --distro=bar > --virt-path=/mnt/storage/diskimages > koan --virt --server=bootserver.example.com > --virt-path=/var/lib/xen/images #override > > >> ------- >> >> Just some thoughts. The additional virt-attributes: bridge, vnc, >> nographics, etc. should be customizable as well. The 'size' >> attributes (vcpu,vram,vdisksize) are inheritable by child profiles. > >> Also (and you may dispute this), the vpath (virtual disk path) is > inheritable by the above program logic. The benefit of inheritance > here allows systems that use the same profile to make use of the same > VG. This way, LVM is simplified (and, errm, added) with cobbler > profiles. I have yet to begin migrating things over to cobbler (so that we may experience virtual attribute inheritance!). This would require changing core profile collection data structures and the like. I will play around with this if you want, but given the fact that these data structures are key to so many other functions of cobbler, I would feel better if I didn't do this alone. > > Yes, all values should be inheritable unless there's a reason for them > to not be. (Example: currently the --distro parameter on the cobbler > profile object is not inheritable) >> >> In general, what is your recommended strategy for the actual >> migration of virtual attributes from koan to cobbler? I think the >> checks should be done on the cobbler side, so that end users don't >> waste time creating child profiles with genetic flaws (i.e. children >> who inherit bad attributes). It's a bit of work, but it's worth doing. > The way cobbler currently deals with arguments can be used here with > no changes and can still give you want you want. Storage locations > themselves can't be totally validated server side, and should be > accepted as little more than strings. If the value given is > specified as a path, we can check to see that it starts with "/", but > not much more. > > "It's a bit of work, but it's worth doing." > > Cobbler's existing validation system prevents the assigning of a value > that doesn't pass validation, so that won't trickle down -- I don't > think this is a concern. Can you give an example? > >> >> BTW, I'm sorry for not getting back to you sooner with more patches. >> I've been busy with job-related stuff. :) >> >> > np ... given there is already quite a lot (too much) in 0.5.0, I'll > probably wait until 0.5.0 is out to begin rolling this in. > > The main thing I would pay attention to with the path logic is making > things as explicit as possible. Having storage decisions be > unpredictable based on the > local storage configuration would be bad IMHO ... I would rather > things fail than store data at a location that wasn't exactly what the > cobbler admin requested, > or otherwise provide some way of specifying a list of criteria. > > Thanks! > > --Michael > > >> >> >> ## BEGIN PATCH ## >> --- app.py.orig 2007-06-21 22:09:15.000000000 +0000 >> +++ app.py 2007-06-21 23:58:09.000000000 +0000 >> @@ -630,9 +630,45 @@ >> print results >> >> def calc_virt_uuid(self,data): >> - # TODO: eventually we may want to allow some koan CLI >> - # option for passing in the UUID. Until then, it's random. >> - return None >> + """ >> + Assign a UUID if none/invalid is given in the profile. >> + """ >> + id = self.safe_load(data,'virt_uuid','xen_uuid',0) >> + uuid_re = >> re.compile('[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}') >> >> + err = False >> + try: >> + str(id) >> + except: >> + err = True >> + if id is None or id == '' or ! uuid_re.match(id): >> + err = True >> + if err: >> + self.debug("invalid UUID specified. randomizing...") >> + return None >> + return id >> + >> + def calc_virt_path(self,data): >> + """ >> + Assign a virt file path if none is given in the profile. >> + """ >> + # Determine if path is string >> + # Determine if path is file >> + # Determine if path is symlink >> + # Determine if path/symlink is block device or valid FS >> + # VG checks/allocation, loopback file checks, or default file >> assignment >> + >> + >> + # TODO >> + >> + def non_sparse(self,data): >> + """ >> + TODO -- Is nonsparse specified? If not, provide default >> + """ >> + >> + def additional(self,data): >> + """ >> + TODO -- More checks, default assignments for additional virt >> attributes >> + """ >> >> def calc_virt_filesize(self,data): >> """ >> @@ -669,6 +705,23 @@ >> return int(size) >> >> >> + def calc_virt_cpus(self,data): >> + """ >> + Assign virtual CPUs if none is given in the profile. >> + """ >> + size = self.safe_load(data,'virt_cpus','xen_cpus',0) >> + err = False >> + try: >> + int(size) >> + except: >> + err = True >> + if size is None or size == '' or int(size) < 1: >> + err = True >> + if err: >> + self.debug("invalid number of VCPUS specified, >> defaulting to 1 VCPU") >> + return 1 >> + return int(size) >> + >> def calc_virt_mac(self,data): >> """ >> For now, we have no preference. >> ### END PATCH ### >> >> >> --A. > > From berrange at redhat.com Tue Jul 10 00:12:28 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 10 Jul 2007 01:12:28 +0100 Subject: [et-mgmt-tools] When next release is available? In-Reply-To: <200707060655.l666tOMe029845@fjmscan503.ms.jp.fujitsu.com> References: <200707060655.l666tOMe029845@fjmscan503.ms.jp.fujitsu.com> Message-ID: <20070710001228.GB16501@redhat.com> On Fri, Jul 06, 2007 at 03:55:14PM +0900, Atsushi SAKAI wrote: > I have a question about virtinst release schedule. > When does the next release available? I'd like to get Cole's patch for translations included, so we can get the i18n stuff working. There's a couple of other outstanding patches posted to the list that I need to review - Hugh Brock is on vacation currently so not there's abit of a backlog. Once that's done I think it'd be a good opportunity to do a release of the code - so hopefully by the end of the week. Immediately following this release I want to get the virt-image stuff from David Lutterkort merged into the tree for testing / wider use. 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 Tue Jul 10 00:26:24 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 10 Jul 2007 01:26:24 +0100 Subject: [et-mgmt-tools] [PATCH] can not specify the type of driver device In-Reply-To: <20070702181447.CBBA.FUKUTA.SAORI@jp.fujitsu.com> References: <20070702181447.CBBA.FUKUTA.SAORI@jp.fujitsu.com> Message-ID: <20070710002624.GC16501@redhat.com> On Mon, Jul 02, 2007 at 06:29:03PM +0900, Saori Fukuta wrote: > Hi, > > I opened the new bugzilla: > Bugzilla Bug 246441: can not specify the type of driver device > URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246441 > > And I attached the patch to fix this problem. There seems to be two different use cases for the driver type, and I'm not sure which one you are trying to address. The patch seems to be just giving the user the ability to specify a sub-type for blktap based files. The code which actually creates the disk image though will always simply create raw disks - so it doesn't make much sense to specify a custom driver type there. It explicitly doesn't deal with HVM, even though QEMU is quite happy dealing with the various disk formats. Rather than directly specifying a driver type, I think what would be more useful is to have an option called --disk-format=TYPE Which accepts TYPE being one of: raw vmdk qcow vpc cow cloop dmg And then - Makes sure the disk image we create is using appropriate file format - Automatically choose the best driver type to match the disk type. One question I wonder is how to best create the actual disk image - with raw disks its easy - we're either seeking to the end (sparse), or just writing lots of zeros (non-sparse). The other formats like vmdk, qcow, etc have some special file structure that needs writing out. We could add code for doing this in python in virt-install, or we could simply run the 'qemu-img' command to create the file in non-raw case. The latter would probably be easiest to do, although we'd explicitly need to add a dependancy on the QEMU rpm, since qemu-img isn't part of the Xen RPMs, or part of libvirt. 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 Tue Jul 10 00:43:06 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 10 Jul 2007 01:43:06 +0100 Subject: [et-mgmt-tools] [PATCH] Unify the checking of the MAC address confliction between virtmanager and virtinstall In-Reply-To: <200706271616.BCJ05296.K99GEJ60@aa.jp.fujitsu.com> References: <200706271351.IIC90127.69E0GKJ9@aa.jp.fujitsu.com> <200706271411.CCE43276.K96J0E9G@aa.jp.fujitsu.com> <200706271616.BCJ05296.K99GEJ60@aa.jp.fujitsu.com> Message-ID: <20070710004306.GD16501@redhat.com> On Wed, Jun 27, 2007 at 04:16:53PM +0900, S.Sakamoto wrote: > Hi, > > Behavior after the check of the repetition of the MAC address of virt-manager(create guest) > is different from virt-install. > > *** virt-manager *** > After having output warning message "Do you really want to use the MAC address ?", > let a user choose behavior with "Yes" or "No". > > *** virt-install *** > In the case of repetition with the MAC address of the host: > -> It becomes the error and lets a user input it MAC address again. > In the case of repetition with the MAC address of the another active guest: > -> It becomes the error and lets a user input it MAC address again. > In the case of repetition with the MAC address of the another inactive guest: > -> After having output warning message, Installation continues. > > Therefore I made the patch which adjusted behavior of virt-manager to virt-install. > (Because add_hardware is similar Wizard, I make it the same behavior.) > > Incidentally, because items in NIC setting wizard is not initialized, I initialize it. > > Signed-off-by: Shigeki Sakamoto Looks good to me, I'll apply 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 berrange at redhat.com Tue Jul 10 01:54:45 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 10 Jul 2007 02:54:45 +0100 Subject: [et-mgmt-tools] [PATCH 1/2] Build and install locale files if present. In-Reply-To: <46929138.1070405@redhat.com> References: <46895B8F.3010905@redhat.com> <46895F7D.3020709@redhat.com> <20070704043659.GH29093@redhat.com> <46929138.1070405@redhat.com> Message-ID: <20070710015445.GG16501@redhat.com> On Mon, Jul 09, 2007 at 03:49:12PM -0400, Cole Robinson wrote: > > Its a bit of a problem because it will clash with the translation catalog > > installed by virt-manager. So the combo of > > > > gettext.install(gettext_app, gettext_dir) > > > > Along with the use of '_' will end up trying to pull translations from > > virt-manager's catalog. What you need to do is not call gettext.intsall > > or locale.setlocal at all - simple have the bindtextdomain call in the > > __init__ file. Then you need to define a convenience wrapper using > > dgettext > > > > def _virtinst(msg): > > return gettext.dgettext(getext_app, msg) > > > > And finally, in each of the virtinst .py files I think you need: > > > > from virtinst import _virtinst as _ > > > > Finally, the virt-install, and virt-clone commands also need to have the > > locale.setlocale, and gettext.install commands in them. > > > > Updated patch is attached. Ok I tested with both virt-install, and virt-manager and confirmed it is doing the right thing. So I've committed this & the other patch. The only change I made was to build the .mo files in build/po, instead of building then in po, and then moving to build/po-rename. This avoids generated files in the main source dir. 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 Tue Jul 10 02:49:06 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 10 Jul 2007 03:49:06 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1184021022.18439.3.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> <1182482730.32115.8.camel@galia.watzmann.net> <1182937902.2778.11.camel@blaa> <1183055484.4013.1.camel@galia.watzmann.net> <20070628225955.GF12711@redhat.com> <1184021022.18439.3.camel@galia.watzmann.net> Message-ID: <20070710024906.GE16016@redhat.com> On Mon, Jul 09, 2007 at 03:43:42PM -0700, David Lutterkort wrote: > On Thu, 2007-06-28 at 23:59 +0100, Daniel P. Berrange wrote: > > On Thu, Jun 28, 2007 at 11:31:24AM -0700, David Lutterkort wrote: > > > > > > My intention was to have that all in the image tag: > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > That way, the relative position of existing tags doesn't change, though > > > it's really not much of a difference. (Though I find having all the > > > storage in one place a little cleaner) > > > > So is a single top level grouping for multiple elements, > > while and are multiple top level elements with no > > grouping. > > > > For consistentency perhaps we should either > > > > - Kill and have at top level > > > > Or > > > > - Add and for grouping the multiple machine > > and network elements. > > I don't follow this - yes, in the abstract it makes sense; but when I > look at an actual image.xml, having the storage element there seems to > make the XML clearer. I'd change it if that is seen as the crucial issue > keeping these patches from being committed. Otherwise, I'd prefer > leaving as it is. I actually agree that having the storage element for grouping the invidual disks makes it a little clearer. What about the alternative of having a grouping element for and too ? > > > BTW, I thing is better called for consistency with the > > libvirt naming of . The and elements already > > match the libvirt terminology. > > Heh ;) I had that at some point and somebody objected to calling that > .. I'll change the code to use Hmm, I hope it wasn't me who objected - that'd be embarassing to be changing my mind every few emails ;-) 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 dlutter at redhat.com Tue Jul 10 05:02:49 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 09 Jul 2007 22:02:49 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <20070710024906.GE16016@redhat.com> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> <1182482730.32115.8.camel@galia.watzmann.net> <1182937902.2778.11.camel@blaa> <1183055484.4013.1.camel@galia.watzmann.net> <20070628225955.GF12711@redhat.com> <1184021022.18439.3.camel@galia.watzmann.net> <20070710024906.GE16016@redhat.com> Message-ID: <1184043769.22101.15.camel@galia.watzmann.net> On Tue, 2007-07-10 at 03:49 +0100, Daniel P. Berrange wrote: > On Mon, Jul 09, 2007 at 03:43:42PM -0700, David Lutterkort wrote: > > On Thu, 2007-06-28 at 23:59 +0100, Daniel P. Berrange wrote: > > > > > So is a single top level grouping for multiple elements, > > > while and are multiple top level elements with no > > > grouping. > > > > > > For consistentency perhaps we should either > > > > > > - Kill and have at top level > > > > > > Or > > > > > > - Add and for grouping the multiple machine > > > and network elements. > > > > I don't follow this - yes, in the abstract it makes sense; but when I > > look at an actual image.xml, having the storage element there seems to > > make the XML clearer. I'd change it if that is seen as the crucial issue > > keeping these patches from being committed. Otherwise, I'd prefer > > leaving as it is. > > I actually agree that having the storage element for grouping the invidual > disks makes it a little clearer. What about the alternative of having a > grouping element for and too ? Since the degenerate case (one machine/domain) will be the most common one, those wrappers would only add unnecessary typing (as the storage tag does, but we agree it increases readability) So I am a little hesitant to add those grouping tags. The main reason to add them would be if we needed to express something that applies to all machines/networks ... and I can't think of any. The bigger issue I am struggling with is how to express features. I think the way the metadata does that currently stinks. From a virt-image pov, all features are tri-state, since for running an image either (a) the feature must be present (b) must not be present or (c) doesn't matter. So the user needs to be able to express two sets of features, those in (a) and those in (b). For suppressing ACPI and enabling PAE, for example, that could be written as Kinda silly since we'll need for each feature X a tag X and a tag noX; or we could write or finally I like the second and third option; for the third option though, I am not even sure we should have an 'acpi' tag ... that could just be text content (acpi) I'll mull over this some tomorrow. Besides markup fun, of course, there's the question of how to detect that ACPI can be turned off; virt-install currently assumes that that can be done for all fv guests. Ultimately, that info should come from libvirt's capabilities. David From dlutter at redhat.com Tue Jul 10 05:05:42 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 09 Jul 2007 22:05:42 -0700 Subject: [et-mgmt-tools] When next release is available? In-Reply-To: <20070710001228.GB16501@redhat.com> References: <200707060655.l666tOMe029845@fjmscan503.ms.jp.fujitsu.com> <20070710001228.GB16501@redhat.com> Message-ID: <1184043942.22101.18.camel@galia.watzmann.net> On Tue, 2007-07-10 at 01:12 +0100, Daniel P. Berrange wrote: > Immediately following this release I want to get the virt-image stuff from > David Lutterkort merged into the tree for testing / wider use. Sounds good. If there is a lot of change to the virt-install/virt-clone executables, it might be good to merge the refactoring patch (first one in my patch series) - that's the one that's kind of a pain to keep up-to-date with hg tip. David From drew.einhorn at gmail.com Tue Jul 10 17:46:17 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 10 Jul 2007 11:46:17 -0600 Subject: [et-mgmt-tools] Provisioning VMs on VMware ESX Server Message-ID: Hi, I'm using cobbler on an ESX 3.01 Server. Koan does not at this time support creating VMs with the desired config on this platform. I have not yet dug into: http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1243494,00.html and attempted to write a script that creates a VM configured the way I need it. A friend took a brief look at it, and thought this was for an older vintage of ESX, so there may be problems getting things to work on 3.01. In the meantime, I am creating VMs by hand using VMware's Virtual Infrastructure Client, powering them up, and PXE boot takes me to the Menu where I choose a profile and an appropriate VM gets built. The problem with this approach is that so far is dealing with MAC address. If VMware allocates the MAC address, I won't know what it is till after the VM is created. Then I have to dig around on the ESX server to find out what MAC was assigned and manually issue a cobbler system command, or I can manually assign a MAC address and force VMware to use it, then manually issue the system command. But that's even more tedious. In the recent Kickstart Tips and Tricks document I found a way to get kickstart to statically assign the ip address it got from pxe via dhcp using %pre. I've got most of the embellisment to this tip necessary to issue a cobbler system command to pin the ip to the mac address. I need a way to easily find the name of the currently running profile to use in the --profile option. Fortunately I can get away with hardcoding the profile name in the kickstart, but sooner or later I will add another profile that uses the same kickstart and this work around will break down. Thanks, -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Jul 10 18:12:22 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 10 Jul 2007 14:12:22 -0400 Subject: [et-mgmt-tools] Virt-disk-path selection patch and other virt. attributes... In-Reply-To: <4692C117.8080304@gmail.com> References: <4692C117.8080304@gmail.com> Message-ID: <4693CC06.8020202@redhat.com> Adam Rosenwald wrote: > Hey Michael et al. > > The following is an (unpolished) method for virt-path (and a few other > discussed virt-attribute methods) in koan's app.py. I've tested it in > parts; it appears to work. :) More extensive testing will ensue next > week. I also have a comment or two on Michael's last response > (inline). Thanks. Ok, great ... I'll have to do some testing on this to see how it all works, but I'm glad to see this. If anyone else has comments on the virt-path handling (especially the volume group and LVM parts), please say so -- more eyes on this would be useful. Basically the idea here is to allow the following attributes to cobbler profile/system add: --virt-path=/path/to/disk/image --virt-path=partition:/dev/device --virt-path=volume-group:name This is rather useful -- Currently guests are installed exclusively to /var/lib/xen/images -- which is a good default, but isn't aware of external storage, SANs, and other nice shiny things. Also profile/system add would get the option --virt-cpus=number and the following attributes to "cobbler system add" (not profile add) --uiid=foo Possibly koan should also get an override parameter for --virt-path in the event that the admin of a server has set up a particular path for their config, but a one-off deployment is warranted (say, for testing) without needing the creation of yet another profile/system. This also raises the question of whether we want other parameters overridable in koan, though in general I'd say we want to keep that to a minimum. --Michael > > --- /usr/lib/python2.4/site-packages/koan/app.py.orig 2007-07-04 > 21:56:10.000000000 -0400 > +++ /usr/lib/python2.4/site-packages/koan/app.py 2007-07-06 > 18:09:41.000000000 -0400 > @@ -30,6 +30,8 @@ > import xmlrpclib > import string > > +from stat import * > + > """ > koan --virt [--profile=webserver|--system=name] --server=hostname > koan --replace-self --profile=foo --server=hostname > @@ -160,8 +162,6 @@ > raise InfoException, "must use either --virt or > --replace-self" > if self.is_virt and self.is_auto_kickstart: > raise InfoException, "must use either --virt or > --replace-self" > - if not self.server: > - raise InfoException, "no server specified" > if self.verbose is None: > self.verbose = True > if (not self.profile and not self.system): > @@ -572,8 +572,10 @@ > results = virtcreate.start_paravirt_install( > name=name, > ram=self.calc_virt_ram(pd), > - disk= self.calc_virt_filesize(pd), > + disk=self.calc_virt_filesize(pd), > + vcpus=self.calc_virt_cpus(pd), > mac=virtcreate.get_mac(self.calc_virt_mac(pd)), > + path=self.set_virt_path(pd, name, mac), > uuid=virtcreate.get_uuid(self.calc_virt_uuid(pd)), > kernel=self.safe_load(pd,'kernel_local'), > initrd=self.safe_load(pd,'initrd_local'), > @@ -583,11 +585,24 @@ > print results > > def calc_virt_uuid(self,data): > - # TODO: eventually we may want to allow some koan CLI > - # option for passing in the UUID. Until then, it's random. > - return None > + """ > + Assign a UUID if none/invalid is given in the profile. > + """ > + id = self.safe_load(data,'virt_uuid','xen_uuid',0) > + uuid_re = > re.compile('[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}') > > + err = False > + try: > + str(id) > + except: > + err = True > + if id is None or id == '' or not uuid_re.match(id): > + err = True > + if err: > + self.debug("invalid UUID specified. randomizing...") > + return None > + return id > > - def calc_virt_filesize(self,data): > + def calc_virt_filesize(self,data,default_filesize=1): > """ > Assign a virt filesize if none is given in the profile. > """ > @@ -597,14 +612,14 @@ > int(size) > except: > err = True > + if size is None or size == '' or int(size) err = True > if err: > - self.debug("invalid file size specified, defaulting to 1 > GB") > - return 1 > + self.debug("invalid file size specified, defaulting to %s > GB" % default_filesize) > + return default_filesize > return int(size) > > - def calc_virt_ram(self,data): > + def calc_virt_ram(self,data,default_ram=256): > """ > Assign a virt ram size if none is given in the profile. > """ > @@ -617,8 +632,26 @@ > if size is None or size == '' or int(size) < 128: > err = True > if err: > - self.debug("invalid RAM size specified, defaulting to 256 > MB") > - return 256 > + self.debug("invalid RAM size specified, defaulting to %s > MB" % default_ram) > + return default_ram > + return int(size) > + > + > + def calc_virt_cpus(self,data,default_cpus=1): > + """ > + Assign virtual CPUs if none is given in the profile. > + """ > + size = self.safe_load(data,'virt_cpus','xen_cpus',0) > + err = False > + try: > + int(size) > + except: > + err = True > + if size is None or size == '' or int(size) < default_cpus: > + err = True > + if err: > + self.debug("invalid number of VCPUS specified, defaulting > to % VCPU" % default_cpus) > + return default_cpus > return int(size) > > > @@ -632,5 +665,69 @@ > return self.system.upper() > return None > > + def set_virt_path(self,data,name,mac): > + """ > + Assign virtual disk location. > + """ > + location = self.safe_load(data,'virt_path','xen_path',0) > + if location.find(':') == -1: > + # LOOPBACK FILE > + if os.path.isabs(location): > + # Location is absolute path > + if location.endswith("/"): > + if name == None: > + path="%s%s" % (location,mac) > + else: > + path="%s%s" % (location,name) > + else: > + path=location > + else: > + # Location is relative path > + if location.endswith("/"): > + if name == None: > + path="/var/lib/xen/images/%s%s" % (location,mac) > + else: > + path="/var/lib/xen/images/%s%s" % > (location,name) > + else: > + path="/var/lib/xen/images/%s" % location > + else: > + # PARTITION or VG > + count = location.count(':') > + # Dangerous since pathname may legally include ':' > + if count == 1: > + (type,blk_id)=location.split(':') > + else: > + self.debug("Please enter one, two, or three delimited > entries in your virt_path file. %s has %d entries which exceeds the > maximum" % (location, count)) > + return None > + > + # FOR PARTITIONS > + if type == "partition" or type == "part": > + if os.path.exists(blk_id) and > S_ISBLK(os.stat(blk_id)[ST_MODE]): > + # virtinst takes care of freespace checks > + path=blk_id > + else: > + raise InfoException, "Either virt_path [%s] does > not exist or [%s] is not a block device." % (blk_id,blk_id) > + > + # FOR VG/LV > + if type == "vg" or type == "volume-group": > + vgnames = sub_process.Popen(["vgs", "-o", "vg_name", > "--noheadings" ], stdout=sub_process.PIPE).communicate()[0] > + if vgnames.find(blk_id) == -1: > + raise InfoException, "The volume group [%s] does > not exist. Please respecify virt_path" % blk_id > + # check free space > + lv_freespace_str = sub_process.Popen(["lvs", > "--noheadings", "-o", "vg_free", "--units", "g", blk_id2], > stdout=sub_process.PIPE).communicate()[0] > + vg_freespace = > int(float(vg_freespace_str.strip()[0:-1])) > + lv_size = > self.safe_load(data,'virt_file_size','xen_file_size',0) > + if vg_freespace >= int(lv_size): > + # Sufficient space > + lvs_str=sub_process.Popen(["lvs", "--noheadings", > "-o", "lv_name", blk_id], stdout=subprocess.PIPE).communicate()[0] > + if name == None: > + if not lvs_str.find(mac): > + lv_create = > sub_process.Popen(["lvcreate", "-L", "%sG" % lv_size, "-n", mac, > blk_id], stdout=sub_process.PIPE).communicate()[0] > + path="/dev/%s/%s" % (blk_id,mac) > + else: > + if not lvs_str.find(name): > + lv_create = > sub_process.Popen(["lvcreate", "-L", "%sG" % lv_size, "-n", name, > blk_id], stdout=sub_process.PIPE).communicate()[0] > + path="/dev/%s/%s" % (blk_id,name) > + else: > + raise InfoException, "The volume group [%s] does > not have at least %sGB free space." % lv_size > + return path > + > if __name__ == "__main__": > main() > > Michael DeHaan wrote: >> Adam Rosenwald wrote: >>> Michael, >>> >>> Here are some starter patches for koan in preparation for a >>> proposed migration of virtual attributes to cobbler. The uuid and >>> vcpu methods can be used directly with only trivial adjustments to >>> virtcreate.py. >> >> Cool. Some comments below... >>> >>> This is just some practice for migrating koan virtual attribute >>> checking and default assignment over to cobbler profiles. I don't >>> know whether you would like this as default behavior, but I was >>> thinking that if the user specifies "path" for --virt-path (a >>> proposed CL argument for passing the location of a prespecified >>> virtual disk file), the following behavior could be taken: >>> >>> # Since block IO is superior to file IO, check to see if --virt-path >>> corresponds to block devices >> >> I like these ideas. I've revised the following has been revised a >> bit... mainly I prefer my arguments to be a bit more predictable in >> what they do, and this makes it clearer to to understand (for the >> user). It also makes documenting what to specify for --virt-path a >> lot simpler. I didn't think of the Volume Group creation idea >> before, and if reasonable simple to implement, that would be a great >> feature. >> >> Anyhow, for disambigution, let's have the following syntax: >> >> --virt-path=foo --virt-path=volume-group:foo >> --virt-path=partition:foo > Full disambiguation would be > --virt-path=file:foo --virt-path=vg:foo > --virt-path=partition:foo > > ... but I've stuck with your reasoning, letting --virt-path=foo > default to loopback files. >> >> (And also let's assume that we can override the cobbler value for >> --virt-path in koan, if needed.) >> >>> * For volume groups >>> o Does a volume_group exist named --virt_path? >>> >> Question: what if system.name already >> exists in the volume group? > Reuse it. The assumption is that the user knows what (s)he's doing. > This is already implemented as a check near the end of the > set_virt_path method >>> >>> + If so >>> # Calculate how much space is left in VG >>> "virt_path" >>> # If enough space to create LV with >>> --virt-disk size >>> * Create new LV named after system.name, >>> unless overriden with --virt-name. >>> Note that system names in 0.5.0 can be >>> arbitrary and are >>> >> not >> necessarily MAC addresses. >>> >>> * If not enough, FAIL >>> >>> * For --virt-paths >>> >> pass %PATH/%virtname into XenDisk , if not in >> /var/lib/xen/images and SELinux is enabled, adjust security context >> appropriately (chcon). > You or someone else will have to implement the SELinux context > adjustments. This is a little beyond me for the moment... >> >> For explicit partitions: >> use the LVM partition as entered, if it does not >> exist, fail. >> Example of koan value being overridden by koan: >> >> cobbler profile add --name=foo --distro=bar >> --virt-path=/mnt/storage/diskimages >> koan --virt --server=bootserver.example.com >> --virt-path=/var/lib/xen/images #override >> >> >>> ------- >>> >>> Just some thoughts. The additional virt-attributes: bridge, vnc, >>> nographics, etc. should be customizable as well. The 'size' >>> attributes (vcpu,vram,vdisksize) are inheritable by child profiles. >> >> Also (and you may dispute this), the vpath (virtual disk path) is >> inheritable by the above program logic. The benefit of inheritance >> here allows systems that use the same profile to make use of the same >> VG. This way, LVM is simplified (and, errm, added) with cobbler >> profiles. > I have yet to begin migrating things over to cobbler (so that we may > experience virtual attribute inheritance!). This would require > changing core profile collection data structures and the like. I will > play around with this if you want, but given the fact that these data > structures are key to so many other functions of cobbler, I would feel > better if I didn't do this alone. >> >> Yes, all values should be inheritable unless there's a reason for >> them to not be. (Example: currently the --distro parameter on the >> cobbler profile object is not inheritable) >>> >>> In general, what is your recommended strategy for the actual >>> migration of virtual attributes from koan to cobbler? I think the >>> checks should be done on the cobbler side, so that end users don't >>> waste time creating child profiles with genetic flaws (i.e. children >>> who inherit bad attributes). It's a bit of work, but it's worth doing. >> The way cobbler currently deals with arguments can be used here with >> no changes and can still give you want you want. Storage locations >> themselves can't be totally validated server side, and should be >> accepted as little more than strings. If the value given is >> specified as a path, we can check to see that it starts with "/", but >> not much more. >> >> "It's a bit of work, but it's worth doing." >> >> Cobbler's existing validation system prevents the assigning of a >> value that doesn't pass validation, so that won't trickle down -- I >> don't think this is a concern. Can you give an example? >> >>> >>> BTW, I'm sorry for not getting back to you sooner with more >>> patches. I've been busy with job-related stuff. :) >>> >>> >> np ... given there is already quite a lot (too much) in 0.5.0, I'll >> probably wait until 0.5.0 is out to begin rolling this in. >> >> The main thing I would pay attention to with the path logic is making >> things as explicit as possible. Having storage decisions be >> unpredictable based on the >> local storage configuration would be bad IMHO ... I would rather >> things fail than store data at a location that wasn't exactly what >> the cobbler admin requested, >> or otherwise provide some way of specifying a list of criteria. >> >> Thanks! >> >> --Michael >> >> >>> >>> >>> ## BEGIN PATCH ## >>> --- app.py.orig 2007-06-21 22:09:15.000000000 +0000 >>> +++ app.py 2007-06-21 23:58:09.000000000 +0000 >>> @@ -630,9 +630,45 @@ >>> print results >>> >>> def calc_virt_uuid(self,data): >>> - # TODO: eventually we may want to allow some koan CLI >>> - # option for passing in the UUID. Until then, it's random. >>> - return None >>> + """ >>> + Assign a UUID if none/invalid is given in the profile. >>> + """ >>> + id = self.safe_load(data,'virt_uuid','xen_uuid',0) >>> + uuid_re = >>> re.compile('[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}') >>> >>> + err = False >>> + try: >>> + str(id) >>> + except: >>> + err = True >>> + if id is None or id == '' or ! uuid_re.match(id): >>> + err = True >>> + if err: >>> + self.debug("invalid UUID specified. randomizing...") >>> + return None >>> + return id >>> + >>> + def calc_virt_path(self,data): >>> + """ >>> + Assign a virt file path if none is given in the profile. >>> + """ >>> + # Determine if path is string >>> + # Determine if path is file >>> + # Determine if path is symlink >>> + # Determine if path/symlink is block device or valid FS >>> + # VG checks/allocation, loopback file checks, or default >>> file assignment >>> + >>> + >>> + # TODO >>> + >>> + def non_sparse(self,data): >>> + """ >>> + TODO -- Is nonsparse specified? If not, provide default >>> + """ >>> + >>> + def additional(self,data): >>> + """ >>> + TODO -- More checks, default assignments for additional virt >>> attributes >>> + """ >>> >>> def calc_virt_filesize(self,data): >>> """ >>> @@ -669,6 +705,23 @@ >>> return int(size) >>> >>> >>> + def calc_virt_cpus(self,data): >>> + """ >>> + Assign virtual CPUs if none is given in the profile. >>> + """ >>> + size = self.safe_load(data,'virt_cpus','xen_cpus',0) >>> + err = False >>> + try: >>> + int(size) >>> + except: >>> + err = True >>> + if size is None or size == '' or int(size) < 1: >>> + err = True >>> + if err: >>> + self.debug("invalid number of VCPUS specified, >>> defaulting to 1 VCPU") >>> + return 1 >>> + return int(size) >>> + >>> def calc_virt_mac(self,data): >>> """ >>> For now, we have no preference. >>> ### END PATCH ### >>> >>> >>> --A. >> >> > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From drew.einhorn at gmail.com Tue Jul 10 18:34:44 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 10 Jul 2007 12:34:44 -0600 Subject: [et-mgmt-tools] [Fwd: Kickstart Tips and Tricks] In-Reply-To: <4692ABE9.4060903@redhat.com> References: <46926234.6000301@redhat.com> <4692ABE9.4060903@redhat.com> Message-ID: On 7/9/07, Michael DeHaan wrote: > > drew einhorn wrote: > > This paper suggests considering Kickstart Configurator (KC). > > ... Anyhow, this is more on-topic for kickstart-list :) Oops, sorry about that. Think my current problem with a tool suggested in this paper needs a note in the cobbler docs, assuming I am not completey misunderstanding the problem and barking up the wrong tree. I this paper I learned about ksvalidator and decided to give it a try. The only thing it complained about was the $yum_repo_stanza lines. I had copied them from the sample configs without really understanding them. ksvalidator suckered me into deleteing them an breaking the repo stuff that was working without any real thought on my part. I believe cobbler expands the $yum_repo_stanza before kickstart ever sees it. And all complaints about it from ksvalidator should be ignored. Are there any similar situations that the naive user should be warned about? -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Jul 10 19:24:37 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 10 Jul 2007 15:24:37 -0400 Subject: [et-mgmt-tools] [Fwd: Kickstart Tips and Tricks] In-Reply-To: References: <46926234.6000301@redhat.com> <4692ABE9.4060903@redhat.com> Message-ID: <4693DCF5.7070307@redhat.com> drew einhorn wrote: > > > On 7/9/07, *Michael DeHaan* > wrote: > > drew einhorn wrote: > > This paper suggests considering Kickstart Configurator (KC). > > > > > ... > > Anyhow, this is more on-topic for kickstart-list :) > > > Oops, sorry about that. > > Think my current problem with a tool suggested in this paper needs > a note in the cobbler docs, assuming I am not completey > misunderstanding the problem and barking up the wrong tree. > > I this paper I learned about ksvalidator and decided to give it a try. > > The only thing it complained about was the $yum_repo_stanza lines. > I had copied them from the sample configs without really understanding > them. ksvalidator suckered me into deleteing them an breaking the > repo stuff that was working without any real thought on my part. > > I believe cobbler expands the $yum_repo_stanza before kickstart > ever sees it. And all complaints about it from ksvalidator should > be ignored. Are there any similar situations that the naive user > should be warned about? ksvalidator (which I've never used, FWIW) should be run on kickstarts -- the files in /etc/cobbler are kickstart templates, which are "proto-kickstarts", not yet kickstarts. The actual kickstarts end up in /var/www/cobbler/kickstarts and /var/www/cobbler/kickstarts_sys ... and since these are output from cobbler, don't give those paths as arguments to cobbler's --kickstart. They are for viewing and for use by kickstarting systems only, and as you rename or delete things, they may go away. Since ksvalidator appears based on pykickstart, it's likely that embedded shell scripts and other %pre magic might still confuse it. I still have yet to file some examples of things that break pykickstart as bugs, but will do so. The multi-drive setup in cobbler's sample scripts are one such example. --Michael > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jul 10 20:30:06 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 10 Jul 2007 16:30:06 -0400 Subject: [et-mgmt-tools] Cobbler Live CD -- success! Message-ID: <4693EC4E.10404@redhat.com> Eureka! I have build and tested a working Cobbler/koan LiveCD. This CD allows for baremetal installation in a PXE-manner, without needing a PXE server setup. So, if you have machines to install/reinstall and can't run PXE due to either (A) some software in the way, or (B) an evil network admin, this is for you. This CD also works for any distribution, meaning if you have a CD defined to install profile "foo", and foo is one day "Fedora 7" and the next day the cobbler server changes to Centos 5, it all works, without having to reburn the CD. This also works with Adam Wolf's recent "autodetect-system" patch. So imagine a lab full of machines where you know the MAC addresses. You stick a CD in one, it finds out the MAC address, and then installs (from cobbler) the proper distro for that machine. You no longer need media that matches the target distribution -- one CD works for everything. - install livecd-tools (I built my CD on Fedora 7) git clone git://git.fedoraproject.org/git/hosted/livecd make install - check out the latest koan and build it, as we're going to build that into the CD cd /path/to/koan make - build a LiveCD with the koan parameters of your choice cd /path/to/koanlive build.py --server=bootserver.example.com --koan="--profile=foo" # takes a few minutes # use nautilus, k3b, or your favorite app to burn the koan-live-cd.iso -- done This produces a CD that, when inserted into any machine, will provision that machine to "foo". You can pass in any additional arguments you like to koan. By default, it will add the value you gave for "--server" and "--replace-self". You'll notice that I don't have any CD images up for download. Why? You'll want to pick the koan parameters yourself -- especially the server address -- at least until we add some zeroconf detection to koan. Things that should be eventually fixed: The output image needs to be pared down. Right now it's around 200 MB. I think that can be cut in half. CD should run from RAM by default, have a low grub timeout, and eject when done to prevent boot-looping. (Right now, log in with root/cobbler, and manually eject/reboot ... or just cycle the power and hit the drive button) Third party hardware support could be better (drive discovery) Would be nice to have koan's autodetect-system support be modified to also check for known IP's Note that you should also be able to build a USB-key image of the above using "/usr/bin/livecd-iso-to-disk" -- which is better than burning coasters and also more pocketable :) Comments/questions/ideas? Fire away. --Michael DeHaan From drew.einhorn at gmail.com Tue Jul 10 21:19:16 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 10 Jul 2007 15:19:16 -0600 Subject: [et-mgmt-tools] ports not listening Message-ID: I've noticed things trying to talk to my cobbler server, but it's not listening 25150 for syslog 25151 for koan --replace-self -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Jul 10 21:34:55 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 10 Jul 2007 17:34:55 -0400 Subject: [et-mgmt-tools] ports not listening In-Reply-To: References: Message-ID: <4693FB7F.4040809@redhat.com> drew einhorn wrote: > I've noticed things trying to talk to my cobbler server, but it's not > listening > > 25150 for syslog > 25151 for koan --replace-self > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools (1) /sbin/service cobblerd restart (2) configure or stop iptables as needed (both ends!) and yes, I do need to clean up the cobblerd init scripts some :) From fukuta.saori at jp.fujitsu.com Wed Jul 11 06:01:10 2007 From: fukuta.saori at jp.fujitsu.com (Saori Fukuta) Date: Wed, 11 Jul 2007 15:01:10 +0900 Subject: [et-mgmt-tools] [PATCH] can not specify the type of driver device In-Reply-To: <20070710002624.GC16501@redhat.com> References: <20070702181447.CBBA.FUKUTA.SAORI@jp.fujitsu.com> <20070710002624.GC16501@redhat.com> Message-ID: <20070711150052.B24A.FUKUTA.SAORI@jp.fujitsu.com> Hi Dan, On Tue, 10 Jul 2007 01:26:24 +0100 "Daniel P. Berrange" wrote: > On Mon, Jul 02, 2007 at 06:29:03PM +0900, Saori Fukuta wrote: > > Hi, > > > > I opened the new bugzilla: > > Bugzilla Bug 246441: can not specify the type of driver device > > URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246441 > > > > And I attached the patch to fix this problem. > > There seems to be two different use cases for the driver type, and I'm > not sure which one you are trying to address. The patch seems to be just > giving the user the ability to specify a sub-type for blktap based files. I found out my mistake by your comment. Thank you. There are two kinds of the meaning for the "driver type" now. The one of the kind is using for operating the disk, and another is using for creating the disk. Is that right? So do we need following two options ? 1) --sub-type = SUBTYPE 2) --disk-format = DISKFMT And I am trying to address the former (--sub-type). 1) --sub-type The "--sub-type" option that actually I wanted to add is choosing the mode for operating the disk. As you said, this is just giving the user the ability to specify a sub-type for blktap based files. For example, I meant that was "driver type" of XML configuration: <---"driver type" So we have to prepare the name of sub type: SUB_TYPE_AIO = "aio" SUB_TYPE_SYNC = "sync" and add "--sub-type" option. 2) --disk-format The "--disk-format" option that you offered is choosing the format type for creating disk. If we want to choose the format type, we have to prepare following name of format type: DRIVER_TAP_RAW = "raw" # change the name. before this was "aio" DRIVER_TAP_QCOW2 = "qcow2" # add. DRIVER_TAP_QCOW = "qcow" DRIVER_TAP_COW = "cow" # add. DRIVER_TAP_VMDK = "vmdk" DRIVER_TAP_CLOOP = "cloop" # add. DRIVER_TAP_DMG = "dmg" # add. DRIVER_TAP_VPC = "vpc" # add. > - Makes sure the disk image we create is using appropriate file format > - Automatically choose the best driver type to match the disk type. But I'm still not sure that how to choose the best driver format automatically. Is it possible to choose that by the virtualization type (i.e. xen, qemu, kvm, or kqemu) ? > writing lots of zeros (non-sparse). The other formats like vmdk, qcow, > etc have some special file structure that needs writing out. We could add > code for doing this in python in virt-install, or we could simply run the > 'qemu-img' command to create the file in non-raw case. Well, I prefer using the "qemu-img" command. Thanks, Saori. From rjones at redhat.com Wed Jul 11 13:39:16 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Jul 2007 14:39:16 +0100 Subject: [et-mgmt-tools] [PATCH] Details & console window Pause button calls virDomainSuspend twice Message-ID: <4694DD84.10301@redhat.com> This bug gives a bit more details about the problem: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247755 The patch attached below fixes it. 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-double-pause-fix-20070711.patch Type: text/x-patch Size: 1298 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 berrange at redhat.com Wed Jul 11 15:29:31 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 11 Jul 2007 16:29:31 +0100 Subject: [et-mgmt-tools] [PATCH] Details & console window Pause button calls virDomainSuspend twice In-Reply-To: <4694DD84.10301@redhat.com> References: <4694DD84.10301@redhat.com> Message-ID: <20070711152931.GG915@redhat.com> On Wed, Jul 11, 2007 at 02:39:16PM +0100, Richard W.M. Jones wrote: > This bug gives a bit more details about the problem: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247755 > > The patch attached below fixes it. Thanks, have pushed it to the repo. 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 Jul 11 21:55:38 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 11 Jul 2007 22:55:38 +0100 Subject: [et-mgmt-tools] [PATCH] can not specify the type of driver device In-Reply-To: <20070711150052.B24A.FUKUTA.SAORI@jp.fujitsu.com> References: <20070702181447.CBBA.FUKUTA.SAORI@jp.fujitsu.com> <20070710002624.GC16501@redhat.com> <20070711150052.B24A.FUKUTA.SAORI@jp.fujitsu.com> Message-ID: <20070711215537.GB15470@redhat.com> On Wed, Jul 11, 2007 at 03:01:10PM +0900, Saori Fukuta wrote: > There are two kinds of the meaning for the "driver type" now. The one > of the kind is using for operating the disk, and another is using for > creating the disk. Is that right? > > So do we need following two options ? > 1) --sub-type = SUBTYPE > 2) --disk-format = DISKFMT > > And I am trying to address the former (--sub-type). > > 1) --sub-type > The "--sub-type" option that actually I wanted to add is choosing the > mode for operating the disk. As you said, this is just giving the user > the ability to specify a sub-type for blktap based files. > For example, I meant that was "driver type" of XML configuration: > > <---"driver type" > > > > So we have to prepare the name of sub type: > SUB_TYPE_AIO = "aio" > SUB_TYPE_SYNC = "sync" > and add "--sub-type" option. I don't think we want a --sub-type argument - it will almost never be used - its not even neccessary for Xen HVM, or QEMU/KVM - its only Xen paravirt which ever use it. We should be picking the sub-type automatically based on the disk format given with the --disk-format arg. > > 2) --disk-format > The "--disk-format" option that you offered is choosing the format type > for creating disk. If we want to choose the format type, we have to > prepare following name of format type: > DRIVER_TAP_RAW = "raw" # change the name. before this was "aio" > DRIVER_TAP_QCOW2 = "qcow2" # add. > DRIVER_TAP_QCOW = "qcow" > DRIVER_TAP_COW = "cow" # add. > DRIVER_TAP_VMDK = "vmdk" > DRIVER_TAP_CLOOP = "cloop" # add. > DRIVER_TAP_DMG = "dmg" # add. > DRIVER_TAP_VPC = "vpc" # add. We need two sets of constants - DRIVER_TAP_nnn as shown here, but also a seprate set of DISK_FORMAT_nnn constants. There will be pretty much the same, except for the DISK_FORMAT_RAW vs DRIVER_TAP_AIO. > > > - Makes sure the disk image we create is using appropriate file format > > - Automatically choose the best driver type to match the disk type. > > But I'm still not sure that how to choose the best driver format > automatically. Is it possible to choose that by the virtualization type > (i.e. xen, qemu, kvm, or kqemu) ? For QEMU / KVM, there's no need to specify a disk driver type - QEMU will probe & determine the disk format automatically. So this is only ever going to be needed for Xen. We can have a simple lookup table mapping disk formats to blktap driver type. diskFormatDriverTapSubtype = ( DISK_FORMAT_RAW: DRIVER_TAP_AIO, DISK_FORMAT_QCOW: DRIVER_TAP_QCOW, ... ) > > > writing lots of zeros (non-sparse). The other formats like vmdk, qcow, > > etc have some special file structure that needs writing out. We could add > > code for doing this in python in virt-install, or we could simply run the > > 'qemu-img' command to create the file in non-raw case. > > Well, I prefer using the "qemu-img" command. Ok, that's fine with me. 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 Thu Jul 12 02:29:38 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 11 Jul 2007 22:29:38 -0400 Subject: [et-mgmt-tools] Cobbler/Koan get QEMU/KVM support Message-ID: <46959212.1040803@redhat.com> I've committed some changes to koan to allow for provisioning of kemu/qemu guests. To try this out: yum install kvm qemu (Guests will use hardware support if you have it, if not, they'll be emulated) koan --server=bootserver.example.org --profile=foo --virt --virttype="qemu" You do not need to do any thing special in cobbler -- your existing 0.5.0 profiles/trees will work without modification. In my testing, I installed a Centos 5 guest inside of F7 -- and as long as you have sufficient RAM, it seems to work well. This commit includes the new --virtpath parameter, which is useful if you would like to specify a location for the images to go. Right now the default -- which is /really/ temporary, is "/opt/qemu". I can do better. I also need to test out the partitioning and volume group management bits with Xen (this parameter supports things like --virt-path=partition:/dev/sdb1). The qemu code pays attention to cobbler attributes such as memory size, kernel parameters, and disk size. The new parameters such as --virtpath and --virttype will be able to be set in cobbler, though I intend to keep the overrides available in koan for at least those parameters. --virttype will default to "xen" as shipped because that's what we support officially in RHEL, though I think I'll let the cobbler system default be changeable in /var/lib/cobbler/settings so you don't have to specify it with each profile created. I still need to customize the qemu support a bit more, clean up the code, and improve the options some, but I just wanted to pass along that it's there now for those that want to play with it. --Michael From fukuta.saori at jp.fujitsu.com Thu Jul 12 08:46:39 2007 From: fukuta.saori at jp.fujitsu.com (Saori Fukuta) Date: Thu, 12 Jul 2007 17:46:39 +0900 Subject: [et-mgmt-tools] [PATCH] can not specify the type of driver device In-Reply-To: <20070711215537.GB15470@redhat.com> References: <20070711150052.B24A.FUKUTA.SAORI@jp.fujitsu.com> <20070711215537.GB15470@redhat.com> Message-ID: <20070712171644.D1EE.FUKUTA.SAORI@jp.fujitsu.com> On Wed, 11 Jul 2007 22:55:38 +0100 "Daniel P. Berrange" wrote: > > 1) --sub-type > > The "--sub-type" option that actually I wanted to add is choosing the > > mode for operating the disk. As you said, this is just giving the user > > the ability to specify a sub-type for blktap based files. > > I don't think we want a --sub-type argument - it will almost never be > used - its not even neccessary for Xen HVM, or QEMU/KVM - its only Xen > paravirt which ever use it. We should be picking the sub-type automatically > based on the disk format given with the --disk-format arg. Okey, I understand and thank you for your comment. So could you close this bugzilla ? Bugzilla Bug 246441: can not specify the type of driver device URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246441 > > 2) --disk-format > > We need two sets of constants - DRIVER_TAP_nnn as shown here, but also > a seprate set of DISK_FORMAT_nnn constants. There will be pretty much the > same, except for the DISK_FORMAT_RAW vs DRIVER_TAP_AIO. > > For QEMU / KVM, there's no need to specify a disk driver type - QEMU will > probe & determine the disk format automatically. So this is only ever going > to be needed for Xen. We can have a simple lookup table mapping disk formats > to blktap driver type. > > diskFormatDriverTapSubtype = ( > DISK_FORMAT_RAW: DRIVER_TAP_AIO, > DISK_FORMAT_QCOW: DRIVER_TAP_QCOW, > ... > ) I can not get to work on adding the above argument immediately, but I will try to do as early as possible. thanks a lot ! Saori. From lippold at gmail.com Thu Jul 12 13:39:09 2007 From: lippold at gmail.com (Aaron Lippold) Date: Thu, 12 Jul 2007 15:39:09 +0200 Subject: [et-mgmt-tools] Cobbler Live CD -- success! In-Reply-To: <4693EC4E.10404@redhat.com> References: <4693EC4E.10404@redhat.com> Message-ID: <39d2723b0707120639p6d5dbe44ke87d33b048b61242@mail.gmail.com> Hello, Very cool. So is this outside the Revisor effort or begining results of it? Aaron On 7/10/07, Michael DeHaan wrote: > Eureka! I have build and tested a working Cobbler/koan LiveCD. This > CD allows for baremetal installation in a PXE-manner, without needing a > PXE server setup. So, if you have machines to install/reinstall and > can't run PXE due to either (A) some software in the way, or (B) an evil > network admin, this is for you. This CD also works for any > distribution, meaning if you have a CD defined to install profile "foo", > and foo is one day "Fedora 7" and the next day the cobbler server changes > to Centos 5, it all works, without having to reburn the CD. > > This also works with Adam Wolf's recent "autodetect-system" patch. So > imagine a lab full of machines where you know the MAC addresses. You > stick a CD in one, it finds out the MAC address, and then installs (from > cobbler) the proper distro for that machine. You no longer need > media that matches the target distribution -- one CD works for everything. > > - install livecd-tools (I built my CD on Fedora 7) > git clone git://git.fedoraproject.org/git/hosted/livecd > make install > > - check out the latest koan and build it, as we're going to build that > into the CD > cd /path/to/koan > make > > - build a LiveCD with the koan parameters of your choice > cd /path/to/koanlive > build.py --server=bootserver.example.com --koan="--profile=foo" # > takes a few minutes > # use nautilus, k3b, or your favorite app to burn the koan-live-cd.iso > > -- done > > This produces a CD that, when inserted into any machine, will provision > that machine to "foo". You can pass in any additional arguments you > like to koan. > By default, it will add the value you gave for "--server" and > "--replace-self". > > You'll notice that I don't have any CD images up for download. Why? > You'll want to pick the koan parameters yourself -- especially the > server address -- at least > until we add some zeroconf detection to koan. > > Things that should be eventually fixed: > The output image needs to be pared down. Right now it's around 200 > MB. I think that can be cut in half. > CD should run from RAM by default, have a low grub timeout, and > eject when done to prevent boot-looping. > (Right now, log in with root/cobbler, and manually > eject/reboot ... or just cycle the power and hit the drive button) > Third party hardware support could be better (drive discovery) > Would be nice to have koan's autodetect-system support be modified > to also check for known IP's > > Note that you should also be able to build a USB-key image of the above > using "/usr/bin/livecd-iso-to-disk" -- which is better than burning > coasters and also more pocketable :) > > Comments/questions/ideas? Fire away. > > --Michael DeHaan > > > _______________________________________________ > 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 Jul 12 20:53:54 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 12 Jul 2007 21:53:54 +0100 Subject: [et-mgmt-tools] Re: About keeping the cdrom in the permanent XMLfor a guest after install In-Reply-To: <200707021958.CJF00097.O9HG08K4@aa.jp.fujitsu.com> References: <20070628225530.GE12711@redhat.com> <200707021958.CJF00097.O9HG08K4@aa.jp.fujitsu.com> Message-ID: <20070712205354.GJ20008@redhat.com> On Mon, Jul 02, 2007 at 07:58:53PM +0900, Nobuhiro Itou wrote: > Hi, Hugh and Dan > > > > Hi there. > > > > > > I still prefer the idea of leaving the CDROM mounted because the > > > heuristic we use to determine if a Windows guest is being installed is a > > > big hack, and because we don't use that code at all in virt-manager and > > > I would like the cdrom to stay mounted by default in virt-manager > > > installs as well. > > > > > > However, if the earlier behavior is useful to anyone, I'd be happy to > > > take a patch for a virtinst argument that would direct virtinst not to > > > include the cdrom device in the post-install guest description. > > > > How about leaving the CDROM device itself always attached, but not having > > any file (media) associated with it. That would keep the simplicity of > > always doing the same config for all OS, while still allowing people to > > use 'xm block-configure' for Windows guests to add the CDROM again. > > The above-mentioned idea just corresponds to the state before correction. > Although Windows may be unique compared with other OS's, > the user can enough continue installation by using xm block-configure. Ok, I put this change back to the way it was before. So all guests get a CDROM device permanently attached, but with no media loaded after install. The Windows exception is of course still there. 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 Thu Jul 12 21:36:56 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 12 Jul 2007 17:36:56 -0400 Subject: [et-mgmt-tools] Cobbler Live CD -- success! In-Reply-To: <39d2723b0707120639p6d5dbe44ke87d33b048b61242@mail.gmail.com> References: <4693EC4E.10404@redhat.com> <39d2723b0707120639p6d5dbe44ke87d33b048b61242@mail.gmail.com> Message-ID: <46969EF8.7000108@redhat.com> Aaron Lippold wrote: > Hello, > > Very cool. So is this outside the Revisor effort or begining results > of it? > > Aaron This is using upstream livecd-creator, not Revisor, which is based on livecd-creator. I do not intend to move to Revisor for this. http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo That being said, the base.cfg in koan's tree may be compatible with Revisor if they want to use it for something -- however there's not much need for it being created with a different tool as I can see. The reason for this is that koan only needs the live CD for a temporary runtime -- enough to prepare a disk as scratch space for a forthcoming running of koan, a reboot, and installation from there via grub and anaconda -- just like replace-self works on a existing linux system without the Live CD. livecd-creator already allows us to pull that content from repos of our choice -- and we already know what kickstart we want to use. So, it serves as something to bootstrap a "PXE like" configuration -- and unlike the aforementioned rescue-disk-kickstart solution (which is also cool) -- this provides a universal installer that can be distro agnostic. So, from that one F7 CD, you might install RHEL3 or Fedora 6 ... it doesn't matter ... cobbler can decide based on the system info. It may be interesting to explore other uses of Live CDs/disks from livecd-creator -- There may be some use for creating a boot image that serves as a minimal diskless virtual host, provisioned with guests automagically from cobbler (cobbler itself needs to evolve to serve existing images), with the guests pointing towards network storage. This would allow turning various hardware into Linux boxes when, say, booted from USB keys or just regular (non-install) PXE images. However that's kind of far out there. If there are existing use cases that folks use today, or would like to follow up on, please share... If you want to build this, just follow the instructions in the previous email and you should be good to go. I am guessing that the tool probably builds best on F7, but the output CD will be usable for any distro you would want to provision. > > On 7/10/07, Michael DeHaan wrote: >> Eureka! I have build and tested a working Cobbler/koan LiveCD. This >> CD allows for baremetal installation in a PXE-manner, without needing a >> PXE server setup. So, if you have machines to install/reinstall and >> can't run PXE due to either (A) some software in the way, or (B) an evil >> network admin, this is for you. This CD also works for any >> distribution, meaning if you have a CD defined to install profile "foo", >> and foo is one day "Fedora 7" and the next day the cobbler server >> changes >> to Centos 5, it all works, without having to reburn the CD. >> >> This also works with Adam Wolf's recent "autodetect-system" patch. So >> imagine a lab full of machines where you know the MAC addresses. You >> stick a CD in one, it finds out the MAC address, and then installs (from >> cobbler) the proper distro for that machine. You no longer need >> media that matches the target distribution -- one CD works for >> everything. >> >> - install livecd-tools (I built my CD on Fedora 7) >> git clone git://git.fedoraproject.org/git/hosted/livecd >> make install >> >> - check out the latest koan and build it, as we're going to build that >> into the CD >> cd /path/to/koan >> make >> >> - build a LiveCD with the koan parameters of your choice >> cd /path/to/koanlive >> build.py --server=bootserver.example.com --koan="--profile=foo" # >> takes a few minutes >> # use nautilus, k3b, or your favorite app to burn the >> koan-live-cd.iso >> >> -- done >> >> This produces a CD that, when inserted into any machine, will provision >> that machine to "foo". You can pass in any additional arguments you >> like to koan. >> By default, it will add the value you gave for "--server" and >> "--replace-self". >> >> You'll notice that I don't have any CD images up for download. Why? >> You'll want to pick the koan parameters yourself -- especially the >> server address -- at least >> until we add some zeroconf detection to koan. >> >> Things that should be eventually fixed: >> The output image needs to be pared down. Right now it's around 200 >> MB. I think that can be cut in half. >> CD should run from RAM by default, have a low grub timeout, and >> eject when done to prevent boot-looping. >> (Right now, log in with root/cobbler, and manually >> eject/reboot ... or just cycle the power and hit the drive button) >> Third party hardware support could be better (drive discovery) >> Would be nice to have koan's autodetect-system support be modified >> to also check for known IP's >> >> Note that you should also be able to build a USB-key image of the above >> using "/usr/bin/livecd-iso-to-disk" -- which is better than burning >> coasters and also more pocketable :) >> >> Comments/questions/ideas? Fire away. >> >> --Michael DeHaan >> >> >> _______________________________________________ >> 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 berrange at redhat.com Sat Jul 14 18:48:58 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 14 Jul 2007 19:48:58 +0100 Subject: [et-mgmt-tools] FYI: adding disks in virt manager Message-ID: <20070714184857.GA14547@redhat.com> FYI, I've just extended the 'add hardware' wizard so that when adding a disk device to a guest, you can choose between adding an IDE cdrom, IDE disk, Floppy disk, SCSI disk, or paravirt disk. Obviously it only shows appropriate types based on the guest. So, now although there's still no UI for changing the CDROM media on the fly yet, you can at least remove & re-add the CDROM device while the guest is inactive. 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 pasik at iki.fi Mon Jul 16 07:44:48 2007 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 16 Jul 2007 10:44:48 +0300 Subject: [et-mgmt-tools] FYI: adding disks in virt manager In-Reply-To: <20070714184857.GA14547@redhat.com> References: <20070714184857.GA14547@redhat.com> Message-ID: <20070716074448.GT4106@edu.joroinen.fi> On Sat, Jul 14, 2007 at 07:48:58PM +0100, Daniel P. Berrange wrote: > FYI, I've just extended the 'add hardware' wizard so that when adding a disk > device to a guest, you can choose between adding an IDE cdrom, IDE disk, > Floppy disk, SCSI disk, or paravirt disk. Obviously it only shows appropriate > types based on the guest. So, now although there's still no UI for changing > the CDROM media on the fly yet, you can at least remove & re-add the CDROM > device while the guest is inactive. > Hmm.. so CDROM can be changed only when the guest is inactive? Any idea when changing on-the-fly will be supported? -- Pasi From berrange at redhat.com Mon Jul 16 13:34:00 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 16 Jul 2007 14:34:00 +0100 Subject: [et-mgmt-tools] FYI: adding disks in virt manager In-Reply-To: <20070716074448.GT4106@edu.joroinen.fi> References: <20070714184857.GA14547@redhat.com> <20070716074448.GT4106@edu.joroinen.fi> Message-ID: <20070716133400.GB19538@redhat.com> On Mon, Jul 16, 2007 at 10:44:48AM +0300, Pasi K?rkk?inen wrote: > On Sat, Jul 14, 2007 at 07:48:58PM +0100, Daniel P. Berrange wrote: > > FYI, I've just extended the 'add hardware' wizard so that when adding a disk > > device to a guest, you can choose between adding an IDE cdrom, IDE disk, > > Floppy disk, SCSI disk, or paravirt disk. Obviously it only shows appropriate > > types based on the guest. So, now although there's still no UI for changing > > the CDROM media on the fly yet, you can at least remove & re-add the CDROM > > device while the guest is inactive. > > > > Hmm.. so CDROM can be changed only when the guest is inactive? That is correct. Its an incremental step better from not being able to change it at all, but obviously still not ideal. > Any idea when changing on-the-fly will be supported? I'll go out on a limb here & suggest Fedora 8 - eg sometime in the next month or two I hope. The key is deciding on the API to use in libvirt, then we'll be able to implement it for Xen and QEMU and expose it in virt-manager 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 Mon Jul 16 16:30:08 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 16 Jul 2007 12:30:08 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst validation testing Message-ID: <469B9D10.4010401@redhat.com> The attached patch adds unit tests for virtinst validation. The matrix of test values isn't completely exhaustive, but it will be easy to update in the future, and the coverage tool indicates it is touching every applicable exception. Signed-off-by: Cole Robinson -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-validation-testing-setup.patch Type: text/x-patch Size: 12041 bytes Desc: not available URL: From crobinso at redhat.com Mon Jul 16 16:33:46 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 16 Jul 2007 12:33:46 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst validation fixes Message-ID: <469B9DEA.6010207@redhat.com> The attached patch fixes some validation errors in virtinst uncovered by the recently submitted validation tests. Signed-off-by: Cole Robinson Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-validation-testing-fixs.patch Type: text/x-patch Size: 8540 bytes Desc: not available URL: From mdehaan at redhat.com Mon Jul 16 23:21:46 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 16 Jul 2007 19:21:46 -0400 Subject: [et-mgmt-tools] Virt-disk-path selection patch and other virt. attributes... In-Reply-To: <4693CC06.8020202@redhat.com> References: <4692C117.8080304@gmail.com> <4693CC06.8020202@redhat.com> Message-ID: <469BFD8A.8080206@redhat.com> I've checked in some modifications to the --virt-path code and rearranged it somewhat. To use a standard disk image with koan: leave --virt-path off and assume defaults (like /var/lib/xen/images) or specify --virt-path=/path/to/directory or specify --virt-path=/path/to/directory/filename To use an existing partition: specify --virt-path=/dev/sda4, or equivalent To carve out of a chunk of a volume group, of the requested --virt-size, using the name cobbler would ordinarily choose: have an existing LVM volume group named something, such as VolGroup00, with some free space on it specify --virt-path=VolGroup00, or equivalent or be more specific: --virt-path=VolGroup00 --virt-name=asdf (this creates /dev/mapper/VolGroup00/asdf) Sidenote -- I've tested the above with qemu-kvm and they perform quite well. When virt-manager's next-release supports installing these via kickstart locations (like Xen), I'll move the kvm bits over to use virtinst -- until then, qemu-kvm systems created with koan do not show up in virt-manager and you have to use the standard KVM tools for basic management. That should change very shortly. Additionally I've added a --virt-graphics flag to koan which enables VNC in both virt types ("qemu", "xenpv"). virt-graphics is currently not read as a default value from cobbler, but it probably should be. --virt-path and --virt-type can be passed to both koan and cobbler (profile add and system add). --Michael From thestrider at gmail.com Tue Jul 17 00:46:45 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Mon, 16 Jul 2007 20:46:45 -0400 Subject: [et-mgmt-tools] Virt-disk-path selection patch and other virt. attributes... In-Reply-To: <469BFD8A.8080206@redhat.com> References: <4692C117.8080304@gmail.com> <4693CC06.8020202@redhat.com> <469BFD8A.8080206@redhat.com> Message-ID: <469C1175.3060005@gmail.com> Thanks, Michael! See inline for comments... Michael DeHaan wrote: > I've checked in some modifications to the --virt-path code and > rearranged it somewhat. > > To use a standard disk image with koan: > leave --virt-path off and assume defaults (like /var/lib/xen/images) While observing this (reasonable -- although should be documented in Koan (if not already)) default, I think a free-space check is in order for the filesystem that contains /var/lib/xen/images. If there is not enough free space to accommodate --virt-size, then an error message should be printed out. The current (virtinst?) reaction is to let the filesystem fill up to 100% and /then* */alert the user about free space. This doesn't make sense, and either cobbler/koan or dependency libraries should show awareness of this problem. > or specify --virt-path=/path/to/directory What will the full virtual path be then? /path/to/directory/? /path/to/directory/? > or specify --virt-path=/path/to/directory/filename > > To use an existing partition: > specify --virt-path=/dev/sda4, or equivalent > > To carve out of a chunk of a volume group, of the requested > --virt-size, using the name cobbler would ordinarily choose: > have an existing LVM volume group named something, such as > VolGroup00, with some free space on it > specify --virt-path=VolGroup00, or equivalent > or be more specific: --virt-path=VolGroup00 --virt-name=asdf > (this creates /dev/mapper/VolGroup00/asdf) The --virt-name can be confusing with --name. What's wrong with --virt-vg=VolGroup00 --virt-lv=asdf? Or --virt-path=VG:[LV]? To make the second form clearer, '--virt-path=VolGroup00:' (notice the trailing colon) or '--virt-path=VolGroup00:asdf'. If you were concerned about the rare case where VolGroup or LogVol included a colon in the name (e.g. "VolGroup\:" or "Log\:Vol00"), the colon-checking could check for the existence of colons in the actual filename and ignore them. Honestly, I don't think anyone would ever consciously put a colon in their device name, unless (s)he were mad! And this is a reasonable assumption! > > Sidenote -- I've tested the above with qemu-kvm and they perform quite > well. When virt-manager's next-release supports installing these > via kickstart locations (like Xen), I'll move the kvm bits over to use > virtinst -- until then, qemu-kvm systems created with koan do not show up > in virt-manager and you have to use the standard KVM tools for basic > management. That should change very shortly. > > Additionally I've added a --virt-graphics flag to koan which enables > VNC in both virt types ("qemu", "xenpv"). virt-graphics is > currently not read as a default Cool! Should --virt-graphics check for the existence of vnc? Or are you satisfied with xenlibs' awkward stack tracing output? > value from cobbler, but it probably should be. --virt-path and > --virt-type can be passed to both koan and cobbler (profile add and > system add). Awesome! Would you like me to follow your example in implementing the other koan virt attributes? Or do you have these covered? -A. > > --Michael > > > > > > _______________________________________________ > 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 hsingtsu at gmail.com Tue Jul 17 05:23:00 2007 From: hsingtsu at gmail.com (Hsing-Tsu Lai) Date: Mon, 16 Jul 2007 22:23:00 -0700 Subject: [et-mgmt-tools] Has any one managed to get cobblerandrhn toplaynice? Message-ID: <66d2fab00707162223w3f1d892awfe58455a60f4477e@mail.gmail.com> > # cobbler reposync - /usr/bin/reposync -r rhel-i386-server-5 > > --download_path=/var/www/cobbler/repo_mirror> > No Repositories Available to Set Up > - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo > - scanning: repo_mirror > createrepo /var/www/cobbler/repo_mirror/rh5basex86 > > Saving Primary metadata > Saving file lists metadata > Saving other metadata > - creating: /var/www/cobbler/repo_mirror/rh5basex86/config.repo Did Greg really get files downloaded, even with the message showing "No Repositories Available to Set Up"? I got this far by following Greg's posts but nothing copied to the directory. My host is entitled for the base channel rhel-x86_64-server-5. This host has been saving the downloaded packages into /var/cache/yum/rhel-x86_64-server-5/ via "yum update" or "yum install ...". ----- # du -sk /var/cache/yum/* 370604 /var/cache/yum/rhel-x86_64-server-5 5972 /var/cache/yum/rhel-x86_64-server-fastrack-5 276 /var/cache/yum/rhel-x86_64-server-supplementary-5 2684 /var/cache/yum/rhel-x86_64-server-vt-5 536 /var/cache/yum/rhn-tools-rhel-x86_64-server-5 32728 /var/cache/yum/rpmforge ---- Thanks, Hsing-Tsu Lai From hsingtsu at gmail.com Tue Jul 17 06:13:24 2007 From: hsingtsu at gmail.com (Hsing-Tsu Lai) Date: Mon, 16 Jul 2007 23:13:24 -0700 Subject: [et-mgmt-tools] keyError while attempting "repo remove" and "repo rename" Message-ID: <66d2fab00707162313p5661f316wf2e6bdb1a31404c0@mail.gmail.com> Hi, I'm trying out cobbler in hoping to use it to manage the rhel5 packages locally. In my experiments, I added a repo then tried to remove or rename it both failed with "KeyError". For example: # cobbler repo remove --name=rhel5 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 719, in main BootCLI(sys.argv).run() File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 115, in run self.relay_args(self.args[1:], self.commands['toplevel']) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 545, in relay_args commands[args[0]](args[1:]) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 699, in repo return self.relay_args(args, self.commands['repo']) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 545, in relay_args commands[args[0]](args[1:]) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 320, in repo_remove return self.__generic_remove(args,"repo","name",self.api.repos) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 305, in __generic_remove return self.apply_args(args,commands,on_ok) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 530, in apply_args input_routines[key](value) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 302, in "--%s" % alias2 : lambda(a): collection_fn().remove(a, with_delete=self.api.sync_flag) File "/usr/lib/python2.4/site-packages/cobbler/collection_repos.py", line 59, in remove self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/repo/post/*") KeyError: 'rhel5' The repo was added by "cobbler repo add --name=rhel5 --mirror=rhn://rhel-x86_64-server-5". Later, I managed to clean it up by "rpm -e cobbler" and removed all the residue files. any pointers why I am getting such errors are much appreciated. Thanks, Hsing-Tsu From mdehaan at redhat.com Tue Jul 17 14:37:23 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 17 Jul 2007 10:37:23 -0400 Subject: [et-mgmt-tools] Virt-disk-path selection patch and other virt. attributes... In-Reply-To: <469C1175.3060005@gmail.com> References: <4692C117.8080304@gmail.com> <4693CC06.8020202@redhat.com> <469BFD8A.8080206@redhat.com> <469C1175.3060005@gmail.com> Message-ID: <469CD423.6050908@redhat.com> Adam Rosenwald wrote: > Thanks, Michael! See inline for comments... > > Michael DeHaan wrote: >> I've checked in some modifications to the --virt-path code and >> rearranged it somewhat. >> >> To use a standard disk image with koan: >> leave --virt-path off and assume defaults (like /var/lib/xen/images) > While observing this (reasonable -- although should be documented in > Koan (if not already)) default, I think a free-space check is in order > for the filesystem that contains /var/lib/xen/images. If there is not > enough free space to accommodate --virt-size, then an error message > should be printed out. The current (virtinst?) reaction is to let the > filesystem fill up to 100% and /then* */alert the user about free > space. This doesn't make sense, and either cobbler/koan or dependency > libraries should show awareness of this problem. Patches accepted -- though this should probably this should go in virtinst as it wouldn't apply just to koan. >> or specify --virt-path=/path/to/directory > What will the full virtual path be then? /path/to/directory/? > /path/to/directory/? If there is a specified name chosen on the client with --virt-name=bar, /path/to/directory/$bar If not... For a profile: /path/to/directory/$macaddress For a system: /path/to/directory/$nameofsystemobject >> or specify --virt-path=/path/to/directory/filename >> >> To use an existing partition: >> specify --virt-path=/dev/sda4, or equivalent >> >> To carve out of a chunk of a volume group, of the requested >> --virt-size, using the name cobbler would ordinarily choose: >> have an existing LVM volume group named something, such as >> VolGroup00, with some free space on it >> specify --virt-path=VolGroup00, or equivalent >> or be more specific: --virt-path=VolGroup00 --virt-name=asdf >> (this creates /dev/mapper/VolGroup00/asdf) > The --virt-name can be confusing with --name. What's wrong with > --virt-vg=VolGroup00 --virt-lv=asdf? Or --virt-path=VG:[LV]? To make > the second form clearer, '--virt-path=VolGroup00:' (notice the > trailing colon) or '--virt-path=VolGroup00:asdf'. Those arguments are, IMHO, slightly confusing. Partitions start with "/dev" (example: /dev/sda4), paths start with "/", so it's clear from the path what the user is intending -- and much easier to document/understand. It also helps keep koan/cobbler from getting too many new arguments. > > If you were concerned about the rare case where VolGroup or LogVol > included a colon in the name (e.g. "VolGroup\:" or "Log\:Vol00"), the > colon-checking could check for the existence of colons in the actual > filename and ignore them. Honestly, I don't think anyone would ever > consciously put a colon in their device name, unless (s)he were mad! > And this is a reasonable assumption! While I'm not concerned with that, it also would not cause problems with the current implementation. >> >> Sidenote -- I've tested the above with qemu-kvm and they perform >> quite well. When virt-manager's next-release supports installing >> these >> via kickstart locations (like Xen), I'll move the kvm bits over to >> use virtinst -- until then, qemu-kvm systems created with koan do not >> show up >> in virt-manager and you have to use the standard KVM tools for basic >> management. That should change very shortly. >> >> Additionally I've added a --virt-graphics flag to koan which enables >> VNC in both virt types ("qemu", "xenpv"). virt-graphics is >> currently not read as a default > Cool! Should --virt-graphics check for the existence of vnc? Or are > you satisfied with xenlibs' awkward stack tracing output? Koan is set to not-require a lot of optional things -- kvm, qemu, xen, virtinst -- because the user might just be using --replace-self and we do not want to pull in those dependencies. >> value from cobbler, but it probably should be. --virt-path and >> --virt-type can be passed to both koan and cobbler (profile add and >> system add). > Awesome! Would you like me to follow your example in implementing the > other koan virt attributes? Or do you have these covered? They are already implemented -- see upstream source. > > -A. >> >> --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 mdehaan at redhat.com Tue Jul 17 14:40:29 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 17 Jul 2007 10:40:29 -0400 Subject: [et-mgmt-tools] keyError while attempting "repo remove" and "repo rename" In-Reply-To: <66d2fab00707162313p5661f316wf2e6bdb1a31404c0@mail.gmail.com> References: <66d2fab00707162313p5661f316wf2e6bdb1a31404c0@mail.gmail.com> Message-ID: <469CD4DD.4010105@redhat.com> Hsing-Tsu Lai wrote: > Hi, > > I'm trying out cobbler in hoping to use it to manage the rhel5 > packages locally. > > In my experiments, I added a repo then tried to remove or rename it > both failed with "KeyError". For example: What version of cobbler are you using? > > > # cobbler repo remove --name=rhel5 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 719, > in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 115, > in run > self.relay_args(self.args[1:], self.commands['toplevel']) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 545, in relay_args > commands[args[0]](args[1:]) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 699, > in repo > return self.relay_args(args, self.commands['repo']) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 545, in relay_args > commands[args[0]](args[1:]) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 320, in repo_remove > return self.__generic_remove(args,"repo","name",self.api.repos) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 305, in __generic_remove > return self.apply_args(args,commands,on_ok) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 530, in apply_args > input_routines[key](value) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 302, in > "--%s" % alias2 : lambda(a): collection_fn().remove(a, > with_delete=self.api.sync_flag) > File "/usr/lib/python2.4/site-packages/cobbler/collection_repos.py", > line 59, in remove > self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/repo/post/*") > KeyError: 'rhel5' > > > The repo was added by "cobbler repo add --name=rhel5 > --mirror=rhn://rhel-x86_64-server-5". Later, I managed to clean it up > by "rpm -e cobbler" and removed all the residue files. That's a bit overkill. You could have removed the definition from /var/lib/cobbler/repos even with the above error. > > any pointers why I am getting such errors are much appreciated. > > > Thanks, > Hsing-Tsu > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From hsingtsu at gmail.com Tue Jul 17 15:52:54 2007 From: hsingtsu at gmail.com (Hsing-Tsu Lai) Date: Tue, 17 Jul 2007 08:52:54 -0700 Subject: [et-mgmt-tools] keyError while attempting "repo remove" and "repo rename" In-Reply-To: <469CD4DD.4010105@redhat.com> References: <66d2fab00707162313p5661f316wf2e6bdb1a31404c0@mail.gmail.com> <469CD4DD.4010105@redhat.com> Message-ID: <66d2fab00707170852ic1ee8b5h970240995d28bc45@mail.gmail.com> > > What version of cobbler are you using? > 0.5.0-1 I tried rebuilding from the source rpm myself and the one from DAG and both gave the same results. BTW, this host is running the xen kernel. Linux XXX 2.6.18-8.1.8.el5xen #1 SMP Mon Jun 25 17:19:38 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux > That's a bit overkill. You could have removed the definition from > /var/lib/cobbler/repos even > with the above error. Good to know. From mdehaan at redhat.com Tue Jul 17 16:52:51 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 17 Jul 2007 12:52:51 -0400 Subject: [et-mgmt-tools] keyError while attempting "repo remove" and "repo rename" In-Reply-To: <66d2fab00707170852ic1ee8b5h970240995d28bc45@mail.gmail.com> References: <66d2fab00707162313p5661f316wf2e6bdb1a31404c0@mail.gmail.com> <469CD4DD.4010105@redhat.com> <66d2fab00707170852ic1ee8b5h970240995d28bc45@mail.gmail.com> Message-ID: <469CF3E3.3060102@redhat.com> Hsing-Tsu Lai wrote: >> >> What version of cobbler are you using? >> > > 0.5.0-1 Ok, I've committed the fix. The problem was related to the new pre/post triggers reorganization. Thanks! --Michael From mdehaan at redhat.com Tue Jul 17 17:33:52 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 17 Jul 2007 13:33:52 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobblerandrhn toplaynice? In-Reply-To: <66d2fab00707162223w3f1d892awfe58455a60f4477e@mail.gmail.com> References: <66d2fab00707162223w3f1d892awfe58455a60f4477e@mail.gmail.com> Message-ID: <469CFD80.70209@redhat.com> Hsing-Tsu Lai wrote: >> # cobbler reposync - /usr/bin/reposync -r rhel-i386-server-5 >> >> --download_path=/var/www/cobbler/repo_mirror> >> No Repositories Available to Set Up >> - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo >> - scanning: repo_mirror >> createrepo /var/www/cobbler/repo_mirror/rh5basex86 >> >> Saving Primary metadata >> Saving file lists metadata >> Saving other metadata >> - creating: /var/www/cobbler/repo_mirror/rh5basex86/config.repo > > Did Greg really get files downloaded, even with the message showing > "No Repositories Available to Set Up"? > > I got this far by following Greg's posts but nothing copied to the > directory. My host is entitled for the base channel > rhel-x86_64-server-5. This host has been saving the downloaded > packages into /var/cache/yum/rhel-x86_64-server-5/ via "yum update" or > "yum install ...". > > ----- > # du -sk /var/cache/yum/* > 370604 /var/cache/yum/rhel-x86_64-server-5 > 5972 /var/cache/yum/rhel-x86_64-server-fastrack-5 > 276 /var/cache/yum/rhel-x86_64-server-supplementary-5 > 2684 /var/cache/yum/rhel-x86_64-server-vt-5 > 536 /var/cache/yum/rhn-tools-rhel-x86_64-server-5 > 32728 /var/cache/yum/rpmforge > ---- > > Thanks, > Hsing-Tsu Lai > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Hmm, interesting. This basically revolves around yum-utils' reposync (as you can see from the output), so if you have the entitled bits for the channels, it should work. That being said, you're not the only one who has reported some problems getting content to download. I'll do some more testing on this to see if it still works for me. In the meantime, any input from folks that did get this working and what they had to do to make it work would be much appreciated. --Michael From hsingtsu at gmail.com Tue Jul 17 21:11:15 2007 From: hsingtsu at gmail.com (Hsing-Tsu Lai) Date: Tue, 17 Jul 2007 14:11:15 -0700 Subject: [et-mgmt-tools] Has any one managed to get cobblerandrhn toplaynice? In-Reply-To: <469CFD80.70209@redhat.com> References: <66d2fab00707162223w3f1d892awfe58455a60f4477e@mail.gmail.com> <469CFD80.70209@redhat.com> Message-ID: <66d2fab00707171411y1671ad7fqf523b04a914adb3e@mail.gmail.com> > This basically revolves around yum-utils' reposync (as you can see from > the output), so if you have the entitled bits for the channels, it > should work. That being said, you're not the only one who has reported > some problems getting content to download. BTW, the yum-utils on this host was rebuilt from yum-utils-1.0.3-1.fc6.src.rpm # rpm -qip yum-utils-1.0.3-1.fc6.src.rpm warning: yum-utils-1.0.3-1.fc6.src.rpm: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 Name : yum-utils Relocations: (not relocatable) Version : 1.0.3 Vendor: Fedora Project Release : 1.fc6 Build Date: Mon 19 Feb 2007 10:19:00 AM UTC Install Date: (not installed) Build Host: ppc3.fedora.redhat.com From Hua.Zhang at Sun.COM Wed Jul 18 14:05:55 2007 From: Hua.Zhang at Sun.COM (Henry Zhang) Date: Wed, 18 Jul 2007 22:05:55 +0800 Subject: [et-mgmt-tools] On HVM in virt-manager Message-ID: <469E1E43.5030209@sun.com> Hi there, When I run virt-manger 0.4, and try to create the HVM guest, I noticed there is option for OS Type, if I want to install Solaris, I think I should select UNIX, then in OS Variant, I can see only Solairs 10 and Solaris 9. And in fact Solaris have Nevada, it's the developing HEAD Solaris, if I would like to install it, which I should select? My understanding to HVM is that we can install any OS without any change, if this machine have special CPU, so why we need to select the OS Type/Variant? If I don't select both OS Type and variant, is it ok? :) Regards, Henry -- From berrange at redhat.com Wed Jul 18 14:27:29 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 18 Jul 2007 15:27:29 +0100 Subject: [et-mgmt-tools] On HVM in virt-manager In-Reply-To: <469E1E43.5030209@sun.com> References: <469E1E43.5030209@sun.com> Message-ID: <20070718142729.GG15465@redhat.com> On Wed, Jul 18, 2007 at 10:05:55PM +0800, Henry Zhang wrote: > Hi there, > > When I run virt-manger 0.4, and try to create the HVM guest, I noticed > there is option for OS Type, if I want to install Solaris, I think I > should select UNIX, then in OS Variant, I can see only Solairs 10 and > Solaris 9. And in fact Solaris have Nevada, it's the developing HEAD > Solaris, if I would like to install it, which I should select? It doesn't particularly matter - pick the closest match - or none at all. Its merely a install hint. > My understanding to HVM is that we can install any OS without any > change, if this machine have special CPU, so why we need to select the > OS Type/Variant? If I don't select both OS Type and variant, is it ok? :) These values are optional - they merely a hint to let us set up the virtual hardware in a slightly more optimal way for a particular OS. eg, with Windows we will set the BIOS clock to 'localtime' instead of 'utc'. 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 hbrock at redhat.com Wed Jul 18 14:31:49 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 18 Jul 2007 10:31:49 -0400 Subject: [et-mgmt-tools] On HVM in virt-manager In-Reply-To: <469E1E43.5030209@sun.com> References: <469E1E43.5030209@sun.com> Message-ID: <469E2455.80401@redhat.com> Henry Zhang wrote: > Hi there, > > When I run virt-manger 0.4, and try to create the HVM guest, I noticed > there is option for OS Type, if I want to install Solaris, I think I > should select UNIX, then in OS Variant, I can see only Solairs 10 and > Solaris 9. And in fact Solaris have Nevada, it's the developing HEAD > Solaris, if I would like to install it, which I should select? > > My understanding to HVM is that we can install any OS without any > change, if this machine have special CPU, so why we need to select the > OS Type/Variant? If I don't select both OS Type and variant, is it ok? :) > > Hi Henry. We added the os-type/os-variant parameters primarily to let us do tricky things that certain OSes need to boot fully-virt. For example, Win2k will only boot with acpi=off and apic=off in the guest config. There is a dictionary in python-virtinst/virtinst/FullVirtGuest.py which has the rather arbitrary os-type/os-version parameters we included, along with a few flags. Selecting "Generic" or "Unix/Solaris 10" will work fine for you, but we would happily take a patch that adds whatever variants are appropriate for Solaris right now. Take care, --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 arik at funke.eu Thu Jul 19 00:20:07 2007 From: arik at funke.eu (Arik Raffael Funke) Date: Thu, 19 Jul 2007 02:20:07 +0200 Subject: [et-mgmt-tools] pci delegation and virt-manager Message-ID: Hi, I gather it is not possible to delegate pci devices using virt-manager. Is this correct? If so, is it possible to "export" the settings from domains existing in virt-manager to the traditional xm configuration file format in /etc/xen to modify them manually? How does virt-manager treat xm config files in /etc/xen that define domU's with identical names as those already existing in virt-manager? Thanks for the help, Arik From berrange at redhat.com Thu Jul 19 02:16:56 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 19 Jul 2007 03:16:56 +0100 Subject: [et-mgmt-tools] Release 0.200.0 of virtinst Message-ID: <20070719021656.GF22907@redhat.com> I'm happy to announce the release of virtinst version 0.200.0 This release introduces the virt-clone tool which provides the ability to clone an existing inactive guest. The disk images will be copied, new MAC address, UUID and name will be given to the guest. Documentation is improved with the addition of manual pages for both virt-install and virt-clone. Validation of input parameters has been further enhanced, and re-factored to allow sharing with virt-manager. The virt-install tool can be used to boot live CD images, with or without underlying storage. It is available for download from the usual place: http://virt-manager.org/download.html Or directly: http://virt-manager.org/download/sources/virtinst/virtinst-0.200.0.tar.gz Thanks to everyone who has participated in development & testing of the code in this new release! 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 Christian.Smith at Sun.COM Thu Jul 19 09:05:37 2007 From: Christian.Smith at Sun.COM (Christian Smith - Sun Microsystems - Dublin Ireland) Date: Thu, 19 Jul 2007 10:05:37 +0100 Subject: [et-mgmt-tools] Virtual Machine Manager, No cdrom after reboot Message-ID: <469F2961.5040401@sun.com> Hi All, Ive just installed Fedora 7 and im using Virtual Machine Manager to install windows XP guests. The initial install works fine until it reboots the machine into the graphical setup part. Firstly, the machine doesnt reboot, it just shuts down and needs to be manually started. Secondly, it appears that the cdrom drive/iso is not mount as the setup cannot find files on the cdrom drive. I tried looking at /var/lib/xend/domains//config.sxp but cannot find a cdrom reference in it anywhere. Any help is greatly appreciated :-) -Christian From Daniel.Hennessey at aah.co.uk Thu Jul 19 16:04:38 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Thu, 19 Jul 2007 17:04:38 +0100 Subject: [et-mgmt-tools] passing list/dictionary in ksmeta Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C76@GBW607SC0054.GB-WS.net> Hey people, I am trying to use the ksmeta="" construct to pass a list of dictionaries through to the kickstart file where I am using a cheetah "#for $var in $vars" loop to unravel them. Is this possible? TIA Dan PS this is what I am trying to do; cobbler profile edit --name=RHEL44-ORACLE10G-i386 --ksmeta="nics=[{ 'dev': 'eth0', 'bootproto': 'dhcp'},{ 'dev': 'eth1', 'bootproto': 'dhcp'}]" and the kickstart file has the following snippet in it; #for $nic in $nics $nic_string = "network" #for $key, $value in $nic.items() $nic_string = $nic_string + " --%s %s" % ( $key, $value ) #end for #end for ************************************************************************ DISCLAIMER The information contained in this e-mail is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply e-mail and then delete it from your system. Please do not copy it or use it for any other purposes, or disclose the content of the e-mail to any other person or store or copy the information in any medium. The views contained in this e-mail are those of the author and not necessarily those of Admenta UK Group. Admenta UK plc is a company incorporated in England and Wales under company number 3011757 and whose registered office is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX ************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Thu Jul 19 16:19:11 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 19 Jul 2007 12:19:11 -0400 Subject: [et-mgmt-tools] passing list/dictionary in ksmeta In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C76@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C76@GBW607SC0054.GB-WS.net> Message-ID: <469F8EFF.8030308@redhat.com> Hennessey Daniel wrote: > Hey people, > > I am trying to use the ksmeta="" construct to pass a list of > dictionaries through to the kickstart file where I am using a cheetah > "#for $var in $vars" loop to unravel them. > > Is this possible? Achieving that result is possible, though as you've entered it, the variable will just be a string, not a data structure. --ksmeta in the command line allows for "key=value key=value" ... key/value pairs seperated by spaces. Those values aren't evaluated to be Python data structures. I have not really used Cheetah for ultra-advanced templating usage, though it does allow executing arbitrary python code, so in theory, you could pass in arbitrary strings and work on them in Python, including evaling them to create real data structures. Whether this works as advertised I don't know... though I could definitely use some more advanced templating examples for the Wiki. I'd be inclined to take a simpler approach though, and pass in simple variables like --ksmeta="eth0=dhcp eth1=dhcp", and then check for the values of those expressions, possibly in conjunction with "#if" templating #if defined $eth0 # syntax for this is probably wrong :) some line containing value for $eth0 #end etc > > TIA > > Dan > > > PS this is what I am trying to do; > > cobbler profile edit --name=RHEL44-ORACLE10G-i386 --ksmeta="nics=[{ > 'dev': 'eth0', 'bootproto': 'dhcp'},{ 'dev': 'eth1', 'bootproto': > 'dhcp'}]" > > and the kickstart file has the following snippet in it; > > #for $nic in $nics > $nic_string = "network" > #for $key, $value in $nic.items() > $nic_string = $nic_string + " --%s %s" % ( $key, $value ) > #end for > #end for > > ************************************************************************ > > DISCLAIMER > > The information contained in this e-mail is confidential and is intended > > for the recipient only. > > If you have received it in error, please notify us immediately by reply > > e-mail and then delete it from your system. Please do not copy it or > > use it for any other purposes, or disclose the content of the e-mail > > to any other person or store or copy the information in any medium. > > The views contained in this e-mail are those of the author and not > > necessarily those of Admenta UK Group. > > Admenta UK plc is a company incorporated in England and Wales > > under company number 3011757 and whose registered office > > is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX > > ************************************************************************ > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Jul 19 17:27:11 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 19 Jul 2007 13:27:11 -0400 Subject: [et-mgmt-tools] new cobbler/koan Wiki and Tracker Message-ID: <469F9EEF.3080508@redhat.com> There's been a lot of interest in having a Wiki people can submit examples to, regarding things like cobbler setup, kickstart-templating, interesting use cases, and other HOW TO kinds of articles. I'm really quite interested myself in how people are using things and think this could be a really nice resource. So, that being said, we now have (drumroll?) ... http://hosted.fedoraproject.org/projects/cobbler/ http://hosted.fedoraproject.org/projects/koan/ In addition to the main page of static content: http://cobbler.et.redhat.com On hosted.fedoraproject.org we now have -- a place for folks to add their own content and read content submitted by other cobbler users -- a bug/RFE tracker, not tied to any particular distro/release -- externally hosted git repos So, about the source control repos -- the new locations for pulling code from are: git clone git://et.redhat.com/cobbler git clone git://et.redhat.com/koan The old git URLs are currently active, though will probably go away in the near future. If anyone has problems accessing these, let us know. While the above URLs do say "fedoraproject", we obviously are continuing Enterprise distro support just as before. Fedora Accounts are required to post to the Wiki and Tracker ... though they are easy enough to get -- and should hopefully becoming simpler to create in the near future. See https://admin.fedoraproject.org/accounts/ for more information. --Michael DeHaan From mdehaan at redhat.com Thu Jul 19 17:51:09 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 19 Jul 2007 13:51:09 -0400 Subject: [et-mgmt-tools] new cobbler/koan Wiki and Tracker In-Reply-To: <469F9EEF.3080508@redhat.com> References: <469F9EEF.3080508@redhat.com> Message-ID: <469FA48D.7040406@redhat.com> Michael DeHaan wrote: > There's been a lot of interest in having a Wiki people can submit > examples to, regarding things like cobbler setup, > kickstart-templating, interesting use cases, and other HOW TO kinds of > articles. I'm really quite interested myself in how people are using > things and think this could be a really nice resource. > > So, that being said, we now have (drumroll?) ... > http://hosted.fedoraproject.org/projects/cobbler/ > http://hosted.fedoraproject.org/projects/koan/ > > In addition to the main page of static content: > http://cobbler.et.redhat.com > > On hosted.fedoraproject.org we now have > -- a place for folks to add their own content and read content > submitted by other cobbler users > -- a bug/RFE tracker, not tied to any particular distro/release > -- externally hosted git repos > > So, about the source control repos -- the new locations for pulling > code from are: > git clone git://et.redhat.com/cobbler > git clone git://et.redhat.com/koan Correction: git clone git://git.fedoraproject.org/git/hosted/cobbler git clone git://git.fedoraproject.org/git/hosted/koan http://cobbler.et.redhat.com has been updated to reflect this. > > The old git URLs are currently active, though will probably go away in > the near future. If anyone has problems accessing these, let us > know. While the above URLs do say "fedoraproject", we obviously are > continuing Enterprise distro support just as before. > > Fedora Accounts are required to post to the Wiki and Tracker ... > though they are easy enough to get -- and should hopefully becoming > simpler to create > in the near future. See https://admin.fedoraproject.org/accounts/ > for more information. > > --Michael DeHaan > > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From florian.heigl at gmail.com Fri Jul 20 04:13:45 2007 From: florian.heigl at gmail.com (Florian Heigl) Date: Fri, 20 Jul 2007 06:13:45 +0200 Subject: [et-mgmt-tools] new cobbler/koan Wiki and Tracker In-Reply-To: <469F9EEF.3080508@redhat.com> References: <469F9EEF.3080508@redhat.com> Message-ID: <77abe410707192113n6a9c7440w2f4101403846e120@mail.gmail.com> 2007/7/19, Michael DeHaan : > There's been a lot of interest in having a Wiki people can submit > examples to, regarding things like cobbler setup, kickstart-templating, > interesting use cases, and other HOW TO kinds of articles. I'm really > quite interested myself in how people are using things and think this > could be a really nice resource. Thank youuuuuuuuuu :) -- 'Sie brauchen sich um Ihre Zukunft keine Gedanken zu machen' From mdehaan at redhat.com Fri Jul 20 20:05:59 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 20 Jul 2007 16:05:59 -0400 Subject: [et-mgmt-tools] Cobbler 0.5.1 testing release -- KVM, --virt-path, other bits... Message-ID: <46A115A7.3060601@redhat.com> Today I ported cobbler's qemu/kvm support to use the virtinst library. This means that qemu/kvm guests created by koan now show up in virt-manager and virsh as one would expect. Testing of 0.5.1 is much appreciated and will help get 0.6.0 (stable) pushed out faster. I do not have any more features in mind for 0.6.0 at this point -- RFEs can go into a later release as this one is already pretty big for containing profile inheritance, an improved cobblerd. For the previous test release announcement, see http://www.redhat.com/archives/et-mgmt-tools/2007-June/msg00211.html Source RPMs are available at: http://cobbler.et.redhat.com/download/ As there hasn't been too much noise on the 0.5.0 release for cobbler/koan and other features, I'm assuming that it is fairly solid, so the main new things here are QEMU and some new --virt options. The koan manpage has also been greatly lengthened to mention the live CD and new display commands -- so eyes on that are welcome as well. Xen installation has not changed much. Should no major issues come up, this will be pretty close to what you'll see in 0.6.0. While also not technically part of this release, testing on the koan live installation CD (it's a way to install baremetal without needing a PXE server), and reports of what hardware it does/doesn't work with -- are also welcome. This was described in a previous list email, but is also included in the new koan manpage for convience. Thanks! --Michael From berrange at redhat.com Fri Jul 20 20:24:45 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 20 Jul 2007 21:24:45 +0100 Subject: [et-mgmt-tools] Announcing Virtual Machine Viewer - aka virt-viewer Message-ID: <20070720202445.GD12218@redhat.com> I've recently been working on a new VNC viewer widget for virt-manager which supports SSL extensions for VNC, and in the future will also be able to do things like tunnel audio & usb devices over the channel, scaling of desktop. It occurred to me that it would be useful to have access to this in a lighter weight application than virt-manager, as a 'vncviewer' replacement, while also adding in the convenience of not having to lookup the VNC port for a virtual machine each time. So I wrote Virtual Machine Viewer - aka virt-viewer. It has near zero UI around it, aside from a menu bar to let you send special key sequences like Ctrl+Alt+XXXX to the guest. At most I might add a start/stop/pause menu option, but I don't want this application to ever get any more complicted than a single window & a small (optional) tool/menu bar. Some example usage... To connect to the guest called ???demo??? running under Xen virt-viewer demo To connect to the guest with ID 7 running under QEMU virt-viewer --connect qemu:///system 7 To wait for the Xen guest with UUID 66ab33c0-6919-a3f7-e659-16c82d248521 to startup and then connect virt-viewer --wait 66ab33c0-6919-a3f7-e659-16c82d248521 In the future it will also accept libvirt 'remote' URIs, so it can connect to the VNC server over SSH, or SSL/TLS. I've litterally only written it this afternoon, so there's no formal release, but in the spirit of 'release early, release often', the GPL code is in mercurial at: http://hg.et.redhat.com/virt/applications/virt-viewer--devel As with virt-manager, the virt-viewer app is GPL licensed It uses the GTK-VNC widget for display, which is also not released yet, but will hopefully be in the near future. Meanwhile it LGPL and it's mercurial repo is at: http://gtk-vnc.codemonkey.ws/hg/outgoing.hg/ Once we've got formal release of both of these tools, I plan to adapt the virt-install code so that it uses virt-viewer instead of vncviewer. 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 adamwolf at feelslikeburning.com Fri Jul 20 21:24:47 2007 From: adamwolf at feelslikeburning.com (adamwolf at feelslikeburning.com) Date: Fri, 20 Jul 2007 14:24:47 -0700 (PDT) Subject: [et-mgmt-tools] passing list/dictionary in ksmeta In-Reply-To: <20070720160023.38AF473B2D@hormel.redhat.com> References: <20070720160023.38AF473B2D@hormel.redhat.com> Message-ID: <59473.216.243.177.33.1184966687.squirrel@webmail.feelslikeburning.com> > Hennessey Daniel wrote: >> Hey people, >> >> I am trying to use the ksmeta="" construct to pass a list of >> dictionaries through to the kickstart file where I am using a cheetah >> "#for $var in $vars" loop to unravel them. >> >> Is this possible? > > Achieving that result is possible, though as you've entered it, the > variable will just be a string, not a data structure. --ksmeta in the > command line allows for "key=value key=value" ... key/value pairs > seperated by spaces. Those values aren't evaluated to be Python data > structures. > > I have not really used Cheetah for ultra-advanced templating usage, > though it does allow executing arbitrary python code, so in theory, > you could pass in arbitrary strings and work on them in Python, > including evaling them to create real data structures. Whether this > works > as advertised I don't know... though I could definitely use some more > advanced templating examples for the Wiki. > > I'd be inclined to take a simpler approach though, and pass in simple > variables like --ksmeta="eth0=dhcp eth1=dhcp", and then check > for the values of those expressions, possibly in conjunction with "#if" > templating > > #if defined $eth0 # syntax for this is probably wrong :) > > some line containing value for $eth0 > #end > > etc I spent some time working with this today. Cheetah allows you to use #if $variable as a shortcut for "is the variable defined?" This shortcut will not work with Cobbler. If something like that is written in a kickstart template, and the profile with which it is associated doesn't have the variable in its ksmeta, cobbler sync will crash. There's a workaround. Instead of using the shortcut to see if the variable is defined, define it to "none" or something obviously wrong/null in the profile. For example, we have default printer information stored in Cobbler. If we set the profile to have the ksmeta pair of DefaultPrinter=none, our kickstart template can have the section #if $DefaultPrinter != "none" lpoptions -d $DefaultPrinter #end if It works, and is only slightly less elegant than the (not working) #if $DefaultPrinter lpoptions -d $DefaultPrinter #end if I'm running the git sources from 2 days ago, if it matters to anyone. Adam Wolf From florian.heigl at gmail.com Sun Jul 22 01:57:25 2007 From: florian.heigl at gmail.com (Florian Heigl) Date: Sun, 22 Jul 2007 03:57:25 +0200 Subject: [et-mgmt-tools] Missing link Message-ID: <77abe410707211857y247091cbp21e7f25a3d1bc5ec@mail.gmail.com> Hi just for your information, some document referred at the main wiki page http://cobbler.et.redhat.com/cobbler-import.php seems to be gone mssing: http://cobbler.et.redhat.com/docs/cobbler-dhcp.php I'm curious whats been there, otherwise I wouldn't have noticed. Florian -- 'Sie brauchen sich um Ihre Zukunft keine Gedanken zu machen' From mdehaan at redhat.com Mon Jul 23 14:06:58 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 23 Jul 2007 10:06:58 -0400 Subject: [et-mgmt-tools] passing list/dictionary in ksmeta In-Reply-To: <59473.216.243.177.33.1184966687.squirrel@webmail.feelslikeburning.com> References: <20070720160023.38AF473B2D@hormel.redhat.com> <59473.216.243.177.33.1184966687.squirrel@webmail.feelslikeburning.com> Message-ID: <46A4B602.6070701@redhat.com> adamwolf at feelslikeburning.com wrote: >> Hennessey Daniel wrote: >> >>> Hey people, >>> >>> I am trying to use the ksmeta="" construct to pass a list of >>> dictionaries through to the kickstart file where I am using a cheetah >>> "#for $var in $vars" loop to unravel them. >>> >>> Is this possible? >>> >> Achieving that result is possible, though as you've entered it, the >> variable will just be a string, not a data structure. --ksmeta in the >> command line allows for "key=value key=value" ... key/value pairs >> seperated by spaces. Those values aren't evaluated to be Python data >> structures. >> >> I have not really used Cheetah for ultra-advanced templating usage, >> though it does allow executing arbitrary python code, so in theory, >> you could pass in arbitrary strings and work on them in Python, >> including evaling them to create real data structures. Whether this >> works >> as advertised I don't know... though I could definitely use some more >> advanced templating examples for the Wiki. >> >> I'd be inclined to take a simpler approach though, and pass in simple >> variables like --ksmeta="eth0=dhcp eth1=dhcp", and then check >> for the values of those expressions, possibly in conjunction with "#if" >> templating >> >> #if defined $eth0 # syntax for this is probably wrong :) >> >> some line containing value for $eth0 >> #end >> >> etc >> > > I spent some time working with this today. > > Cheetah allows you to use #if $variable as a shortcut for "is the variable > defined?" > > This shortcut will not work with Cobbler. If something like that is > written in a kickstart template, and the profile with which it is > associated doesn't have the variable in its ksmeta, cobbler sync will > crash. > Interesting... I'll take a look at this. There may be a workaround in the way we are using the Cheetah API. > There's a workaround. > > Instead of using the shortcut to see if the variable is defined, define it > to "none" or something obviously wrong/null in the profile. > > For example, we have default printer information stored in Cobbler. If we > set the profile to have the ksmeta pair of DefaultPrinter=none, our > kickstart template can have the section > > #if $DefaultPrinter != "none" > lpoptions -d $DefaultPrinter > #end if > > It works, and is only slightly less elegant than the (not working) > > #if $DefaultPrinter > lpoptions -d $DefaultPrinter > #end if > > I'm running the git sources from 2 days ago, if it matters to anyone. > > Adam Wolf > > _______________________________________________ > 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 Jul 23 14:35:10 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 23 Jul 2007 10:35:10 -0400 Subject: [et-mgmt-tools] Missing link In-Reply-To: <77abe410707211857y247091cbp21e7f25a3d1bc5ec@mail.gmail.com> References: <77abe410707211857y247091cbp21e7f25a3d1bc5ec@mail.gmail.com> Message-ID: <46A4BC9E.7070708@redhat.com> Florian Heigl wrote: > Hi just for your information, > > some document referred at the main wiki page > http://cobbler.et.redhat.com/cobbler-import.php > seems to be gone mssing: > http://cobbler.et.redhat.com/docs/cobbler-dhcp.php > > I'm curious whats been there, otherwise I wouldn't have noticed. > > Florian > The correct link is http://cobbler.et.redhat.com/cobbler-dhcp.php I'll grep for the broken one and fix it. Thanks! --Michael From drew.einhorn at gmail.com Mon Jul 23 14:48:58 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Mon, 23 Jul 2007 08:48:58 -0600 Subject: [et-mgmt-tools] %include Message-ID: My kickstarts would be simpler and more readable if I could put stuff that's frequently used in many kickstarts in a separate file and use %include Where do I put the files so kickstart can find them when the time comes. -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From fj1826dm at aa.jp.fujitsu.com Mon Jul 23 23:42:18 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Tue, 24 Jul 2007 08:42:18 +0900 Subject: [et-mgmt-tools] [PATCH] check the existing file in virt-install Message-ID: <200707240842.FFB73428.NEKG9237@aa.jp.fujitsu.com> Hi When the existing file is specified with virt-install, the file is compulsorily overwrited. Therefore the important file may be overwrited when a user makes a typo. This patch fixes so that virt-install displays warning message when the existing file is specified. Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. ---------------------------------------------------------------------- diff -r 645217bda13b virt-install --- a/virt-install Sat Jul 21 13:03:07 2007 -0400 +++ b/virt-install Tue Jul 24 16:23:30 2007 +0900 @@ -48,6 +48,23 @@ 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): + while 1: + retryFlg = False + warnmsg = _("You are going to overwrite file '%s'!") % disk + res = cli.prompt_for_input(warnmsg + _(" Do you really want to use the disk (yes or no)? ")) + try: + if cli.yes_or_no(res) is True: + break + else: + retryFlg = True + break + except ValueError, e: + print _("ERROR: "), e + continue + if retryFlg is True: + disk = None + continue while 1: if os.path.exists(disk): break ---------------------------------------------------------------------- From mdehaan at redhat.com Tue Jul 24 14:44:08 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 24 Jul 2007 10:44:08 -0400 Subject: [et-mgmt-tools] Cobbler 0.5.1 testing release -- KVM, --virt-path, other bits... In-Reply-To: <46A115A7.3060601@redhat.com> References: <46A115A7.3060601@redhat.com> Message-ID: <46A61038.5070101@redhat.com> Michael DeHaan wrote: > Today I ported cobbler's qemu/kvm support to use the virtinst > library. This means that qemu/kvm guests created by koan now show up > in virt-manager and virsh as one would expect. > Testing of 0.5.1 is much appreciated and will help get 0.6.0 (stable) > pushed out faster. I do not have any more features in mind for 0.6.0 > at this point -- RFEs can go into a later > release as this one is already pretty big for containing profile > inheritance, an improved cobblerd. For the previous test release > announcement, see > http://www.redhat.com/archives/et-mgmt-tools/2007-June/msg00211.html > > Source RPMs are available at: > > http://cobbler.et.redhat.com/download/ > > As there hasn't been too much noise on the 0.5.0 release for > cobbler/koan and other features, I'm assuming that it is fairly solid, > so the main new things here are QEMU > and some new --virt options. The koan manpage has also been greatly > lengthened to mention the live CD and new display commands -- so eyes > on that are welcome as well. > Xen installation has not changed much. > > Should no major issues come up, this will be pretty close to what > you'll see in 0.6.0. > > While also not technically part of this release, testing on the koan > live installation CD (it's a way to install baremetal without needing > a PXE server), and reports of what hardware it does/doesn't work with > -- are also welcome. This was described in a previous list email, but > is also included in the new koan manpage for convience. > > Thanks! > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools If anyone is testing these files, I've updated the koan RPM's to take care of a few bugs -- or you can just build from the source checkout. Thanks! --Michael From drew.einhorn at gmail.com Tue Jul 24 15:18:07 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 24 Jul 2007 09:18:07 -0600 Subject: [et-mgmt-tools] create my own cobbler stanzas? Message-ID: I've been trying without success to use kickstart %includes to simplify and modularize my kickstart files. Haven't bee able to figure out where to put the files to be included so they can be found when the kickstart is running. Cobbler stanzas perform a similar function. Can I create my own and do it that way. -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyclak at math.ohiou.edu Tue Jul 24 15:27:44 2007 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Tue, 24 Jul 2007 11:27:44 -0400 Subject: [et-mgmt-tools] create my own cobbler stanzas? In-Reply-To: References: Message-ID: <20070724152744.GJ28659@math.ohiou.edu> On Tue, Jul 24, 2007 at 09:18:07AM -0600, drew einhorn enlightened us: > I've been trying without success to use kickstart %includes to simplify and > modularize > my kickstart files. Haven't bee able to figure out where to put the files > to be included > so they can be found when the kickstart is running. > They need to be visible to the system either by having them available on the local filesystem, or by mounting an NFS share or similar. I accomplish this by using wget in the %pre stanza. My cobbler template looks something like: %packages %include /tmp/packages_${hostname} %pre wget -P /tmp http://server/ks/packages_${hostname} Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 From drew.einhorn at gmail.com Tue Jul 24 15:43:00 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 24 Jul 2007 09:43:00 -0600 Subject: [et-mgmt-tools] create my own cobbler stanzas? In-Reply-To: <20070724152744.GJ28659@math.ohiou.edu> References: <20070724152744.GJ28659@math.ohiou.edu> Message-ID: Thanks, I should have thought of that, I have seen things that were similar. I was looking into a much more difficult solution. On 7/24/07, Matt Hyclak wrote: > > On Tue, Jul 24, 2007 at 09:18:07AM -0600, drew einhorn enlightened us: > > I've been trying without success to use kickstart %includes to simplify > and > > modularize > > my kickstart files. Haven't bee able to figure out where to put the > files > > to be included > > so they can be found when the kickstart is running. > > > > They need to be visible to the system either by having them available on > the > local filesystem, or by mounting an NFS share or similar. I accomplish > this > by using wget in the %pre stanza. My cobbler template looks something > like: > > %packages > %include /tmp/packages_${hostname} > > %pre > wget -P /tmp http://server/ks/packages_${hostname} > > 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 > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Jul 24 15:57:30 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 24 Jul 2007 11:57:30 -0400 Subject: [et-mgmt-tools] create my own cobbler stanzas? In-Reply-To: References: Message-ID: <46A6216A.602@redhat.com> drew einhorn wrote: > I've been trying without success to use kickstart %includes to > simplify and modularize > my kickstart files. Haven't bee able to figure out where to put the > files to be included > so they can be found when the kickstart is running. > > Cobbler stanzas perform a similar function. Can I create my own and > do it that way. > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Matt beat me to the post, but here's what I was typing.... I like this idea... especially considering that kickstart "%include" wouldn't allow for inclusion of Cobbler templating variables. I think it's a bit more transparent than having to copy stuff to http:// space and would also allow for templating variables to be substituted. So, I've filed it as an RFE here: https://hosted.fedoraproject.org/projects/cobbler/ticket/13 From drew.einhorn at gmail.com Tue Jul 24 18:15:01 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 24 Jul 2007 12:15:01 -0600 Subject: [et-mgmt-tools] cfengine chicken and egg problem Message-ID: Now that I've got %include working, on to the next problem. At least I think it's working. It's been running the post-install scripts for quite a while, but that's probably to be expected. Hmm. I've waited a long time and I'm beginning to get worried that the post install script may have run amok. Are there good techniques for debugging post install scripts? Maybe I'm not quite ready for the next problem. Putting cobbler and cfengine together, I have a bit of a which comes first problem. Ideally cfengine should take care of the configs in yum.repos.d But these configs need to be set up before I install cfengine from a 3rd Party repository. And before I do that I need to install and configure yum-priorities so the 3rd Party repos don't run amok and trash the system. I can see a way to break this vicious cycle of dependencies. But I'm not sure I've considered all the subtleties. How are folks who are using cobbler with cfengine getting things initially set up? -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlutter at redhat.com Tue Jul 24 18:19:36 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 24 Jul 2007 18:19:36 +0000 Subject: [et-mgmt-tools] cfengine chicken and egg problem In-Reply-To: References: Message-ID: <1185301176.17210.38.camel@galia.watzmann.net> On Tue, 2007-07-24 at 12:15 -0600, drew einhorn wrote: > Hmm. I've waited a long time and I'm beginning to get worried > that the post install script may have run amok. Are there good > techniques for debugging post install scripts? If you switch to tvirtual terminal 2 (Ctrl-Alt-2) on the machine you're installing you get a shell, vt 3 has log output; if there's a specific point in the post script you are worried about, put a 'sleep 10000' or a '/bin/bash' before it - in teh latter case, vt3 will give you a prompt, too, and continue installing once you exit that shell. > Putting cobbler and cfengine together, I have a bit of > a which comes first problem. > > Ideally cfengine should take care of the configs > in yum.repos.d You can specify additional repos in the kickstart file; for puppet, I described that in my blog in detail[1] - cfengine should be very similar. David [1] http://watzmann.net/blog/index.php/2006/12/05/kickstarting_into_puppet From Greg.Caetano at hp.com Tue Jul 24 19:05:37 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Tue, 24 Jul 2007 15:05:37 -0400 Subject: [et-mgmt-tools] Xen guest not receiving dhcp address Message-ID: I'm working with a RHEL5 AP system (kernel 2.6.18-8.1.8.el5xen, xen 3.0.3-25.0.3.el5) and am not able to get the Xen guest to receive a DHCP address from the Dom0 dhcpd server. I have defined the xen mac address in the dhcpd.conf file to assign it a fixed address. >From /var/log/messages on Dom0 I can see DHCPDISCOVER and DHCPOFFER entries with the appropriate mac and ip address being offered but the Xen guest does not accept the DHCPoffer and fails to start the network on eth0 Any suggestions? Thanks Greg Caetano greg.caetano at hp.com From berrange at redhat.com Tue Jul 24 19:14:40 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 24 Jul 2007 20:14:40 +0100 Subject: [et-mgmt-tools] Xen guest not receiving dhcp address In-Reply-To: References: Message-ID: <20070724191440.GH23597@redhat.com> On Tue, Jul 24, 2007 at 03:05:37PM -0400, Caetano, Greg wrote: > I'm working with a RHEL5 AP system (kernel 2.6.18-8.1.8.el5xen, xen > 3.0.3-25.0.3.el5) and am not able to get the Xen guest to receive a DHCP > address from the Dom0 dhcpd server. > > I have defined the xen mac address in the dhcpd.conf file to assign it a > fixed address. > > >From /var/log/messages on Dom0 I can see DHCPDISCOVER and DHCPOFFER > entries with the appropriate mac and ip address being offered but the > Xen guest does not accept the DHCPoffer and fails to start the network > on eth0 Try to turn off TCP checksum offload ethtool -K eth0 tx off In the Dom0. If that doesn't work, try the bridge device in Dom0 too 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 Greg.Caetano at hp.com Tue Jul 24 19:32:59 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Tue, 24 Jul 2007 15:32:59 -0400 Subject: [et-mgmt-tools] Xen guest not receiving dhcp address In-Reply-To: <20070724191440.GH23597@redhat.com> References: <20070724191440.GH23597@redhat.com> Message-ID: Dan... No change... Even if I also try the xenbr0 bridge as well Other devices in the network are receiving ip addresses with no problem. -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Daniel P. Berrange Sent: Tuesday, July 24, 2007 2:15 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Xen guest not receiving dhcp address On Tue, Jul 24, 2007 at 03:05:37PM -0400, Caetano, Greg wrote: > I'm working with a RHEL5 AP system (kernel 2.6.18-8.1.8.el5xen, xen > 3.0.3-25.0.3.el5) and am not able to get the Xen guest to receive a > DHCP address from the Dom0 dhcpd server. > > I have defined the xen mac address in the dhcpd.conf file to assign it > a fixed address. > > >From /var/log/messages on Dom0 I can see DHCPDISCOVER and DHCPOFFER > entries with the appropriate mac and ip address being offered but the > Xen guest does not accept the DHCPoffer and fails to start the network > on eth0 Try to turn off TCP checksum offload ethtool -K eth0 tx off In the Dom0. If that doesn't work, try the bridge device in Dom0 too 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 -=| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From dlutter at redhat.com Tue Jul 24 22:34:44 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 24 Jul 2007 15:34:44 -0700 Subject: [et-mgmt-tools] VM Images (take 2) Message-ID: <1185316484.10994.10.camel@galia.watzmann.net> Hi, I've updated the patches [1] for virt-inst that deal with machine images. The XML format has changed some since the inital patches. Main changes: * the os type/variant business has been removed from the XML. Instead, the features section now allows specifying acpi/apic directly, e.g. '' (right now, this requires some patches [2] to libvirt, too; without them, virt-image will complain that it can't find a suitable boot descriptor) * the section in the elements has been changed so that each disk mapping corresponds to a element instead of being in / * the various hardware info (vcpu, memory, interface, graphics) are in a devices section * the tag is now called For details of the format, look at the example image.xml, and the Relax-NG grammar, image.rng. David [1] http://people.redhat.com/dlutter/virt-image/ [2] https://www.redhat.com/archives/libvir-list/2007-July/msg00395.html From Greg.Caetano at hp.com Wed Jul 25 13:31:36 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Wed, 25 Jul 2007 09:31:36 -0400 Subject: [et-mgmt-tools] RESOLVED-Xen guest not receiving dhcp address In-Reply-To: References: <20070724191440.GH23597@redhat.com> Message-ID: FWIW The issue disappeared when we were able to resolve an issue with DNS. -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Caetano, Greg Sent: Tuesday, July 24, 2007 2:33 PM To: Fedora/Linux Management Tools Subject: RE: [et-mgmt-tools] Xen guest not receiving dhcp address Dan... No change... Even if I also try the xenbr0 bridge as well Other devices in the network are receiving ip addresses with no problem. -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Daniel P. Berrange Sent: Tuesday, July 24, 2007 2:15 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Xen guest not receiving dhcp address On Tue, Jul 24, 2007 at 03:05:37PM -0400, Caetano, Greg wrote: > I'm working with a RHEL5 AP system (kernel 2.6.18-8.1.8.el5xen, xen > 3.0.3-25.0.3.el5) and am not able to get the Xen guest to receive a > DHCP address from the Dom0 dhcpd server. > > I have defined the xen mac address in the dhcpd.conf file to assign it > a fixed address. > > >From /var/log/messages on Dom0 I can see DHCPDISCOVER and DHCPOFFER > entries with the appropriate mac and ip address being offered but the > Xen guest does not accept the DHCPoffer and fails to start the network > on eth0 Try to turn off TCP checksum offload ethtool -K eth0 tx off In the Dom0. If that doesn't work, try the bridge device in Dom0 too 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 -=| _______________________________________________ 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 crobinso at redhat.com Wed Jul 25 14:19:47 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 25 Jul 2007 10:19:47 -0400 Subject: [et-mgmt-tools] [PATCH] check the existing file in virt-install In-Reply-To: <200707240842.FFB73428.NEKG9237@aa.jp.fujitsu.com> References: <200707240842.FFB73428.NEKG9237@aa.jp.fujitsu.com> Message-ID: <46A75C03.8050404@redhat.com> Masayuki Sunou wrote: > Hi > > When the existing file is specified with virt-install, the file is > compulsorily overwrited. > Therefore the important file may be overwrited when a user makes a typo. > > This patch fixes so that virt-install displays warning message when > the existing file is specified. > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. Patch looks fine to me. A small nitpick though: I'd change "Do you really want to use the disk?" to "Do you really want to use this file?" and add a newline at the start of the line to prevent it from wrapping. - Cole -- Cole Robinson crobinso at redhat.com From jim at rossberry.com Wed Jul 25 19:45:13 2007 From: jim at rossberry.com (Jim Wildman) Date: Wed, 25 Jul 2007 15:45:13 -0400 (EDT) Subject: [et-mgmt-tools] Koan on a RHEL3 client Message-ID: I need/want to use koan to rebuild a rhel3 server. However it errors out like this. [root at ino0l073 root]# rpm -q koan koan-0.5.0-1.el3.rf [root at ino0l073 root]# cat /etc/redhat-release Red Hat Enterprise Linux ES release 3 (Taroon Update 6) [root at ino0l073 root]# koan -l --server=10.128.164.145 Traceback (most recent call last): File "/usr/bin/koan", line 38, in ? import koan.app as app File "/usr/lib/python2.2/site-packages/koan/app.py", line 22, in ? import optparse ImportError: No module named optparse [root at ino0l073 root]# koan run from a Centos 5 box (which happens to be the cobbler server) yields [root at mrdevjw1 pxelinux.cfg]# cat /etc/redhat-release CentOS release 5 (Final) [root at mrdevjw1 pxelinux.cfg]# koan -l --server=10.128.164.145 lrh4v4-i386-private lrh4v4-public [root at mrdevjw1 pxelinux.cfg]# rpm -q koan koan-0.5.0-1.el5.rf I don't see anything else in the wiki or by googling. suggestions? ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine From crobinso at redhat.com Wed Jul 25 21:55:14 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 25 Jul 2007 17:55:14 -0400 Subject: [et-mgmt-tools] virt-manager dogtail tests Message-ID: <46A7C6C2.4020106@redhat.com> Hi all, I just wanted to inform the list that I am putting together a suite of Dogtail tests for virt-manager. For those who don't know, Dogtail is a python based GUI testing framework. At the moment I just have proof of concept and testing infrastructure going as Dogtail didn't seem to want to cooperate very easily, but hopefully by the end of the week I should have some smoke tests built up, and can start looking at more interesting tests, as well as integrating them into the build process. Thanks, Cole -- Cole Robinson crobinso at redhat.com From mdehaan at redhat.com Wed Jul 25 22:05:42 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 25 Jul 2007 18:05:42 -0400 Subject: [et-mgmt-tools] Koan on a RHEL3 client In-Reply-To: References: Message-ID: <46A7C936.9040802@redhat.com> Jim Wildman wrote: > I need/want to use koan to rebuild a rhel3 server. However it errors > out like this. I thought that used to work on RHEL 3 -- apparently I must have switched to optparse in the last 6 months or so? optparse is new in Python 2.3, and is just there to parse the command line. Short term, I don't have a quick fix for this, but I'll remove the dependency as this is supposed to work. --Michael > > [root at ino0l073 root]# rpm -q koan > koan-0.5.0-1.el3.rf > [root at ino0l073 root]# cat /etc/redhat-release Red Hat Enterprise Linux > ES release 3 (Taroon Update 6) > [root at ino0l073 root]# koan -l --server=10.128.164.145 > Traceback (most recent call last): > File "/usr/bin/koan", line 38, in ? > import koan.app as app > File "/usr/lib/python2.2/site-packages/koan/app.py", line 22, in ? > import optparse > ImportError: No module named optparse > [root at ino0l073 root]# > > koan run from a Centos 5 box (which happens to be the cobbler server) > yields > [root at mrdevjw1 pxelinux.cfg]# cat /etc/redhat-release CentOS release 5 > (Final) > [root at mrdevjw1 pxelinux.cfg]# koan -l --server=10.128.164.145 > lrh4v4-i386-private > lrh4v4-public > [root at mrdevjw1 pxelinux.cfg]# rpm -q koan > koan-0.5.0-1.el5.rf > > I don't see anything else in the wiki or by googling. > > suggestions? > > ------------------------------------------------------------------------ > Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com > "Society in every state is a blessing, but Government, even in its best > state, is a necessary evil; in its worst state, an intolerable one." > Thomas Paine > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From fj1826dm at aa.jp.fujitsu.com Thu Jul 26 05:49:33 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Thu, 26 Jul 2007 14:49:33 +0900 Subject: [et-mgmt-tools] [PATCH] check the existing file in virt-install In-Reply-To: <46A75C03.8050404@redhat.com> References: <200707240842.FFB73428.NEKG9237@aa.jp.fujitsu.com> <46A75C03.8050404@redhat.com> Message-ID: <200707261449.CBI78177.37G2KEN9@aa.jp.fujitsu.com> Hi Cole Thank you for a review and suggestion. > Patch looks fine to me. A small nitpick though: I'd change "Do you > really want to use the disk?" to "Do you really want to use this file?" > and add a newline at the start of the line to prevent it from wrapping. > Because I think that your suggestion is reasonable, I remake this patch. And I find the another point that had better add a new line. So this patch adds a new line to there. Thanks, Masayuki Sunou. ---------------------------------------------------------------------- diff -r 645217bda13b virt-install --- a/virt-install Sat Jul 21 13:03:07 2007 -0400 +++ b/virt-install Fri Jul 27 10:01:20 2007 +0900 @@ -48,6 +48,23 @@ 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): + while 1: + retryFlg = False + warnmsg = _("You are going to overwrite file '%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: + break + else: + retryFlg = True + break + except ValueError, e: + print _("ERROR: "), e + continue + if retryFlg is True: + disk = None + continue while 1: if os.path.exists(disk): break @@ -64,8 +81,8 @@ def get_disk(disk, size, sparse, guest, if d.is_conflict_disk(conn) is True: while 1: retryFlg = False - warnmsg = _("Disk %s is already in use by another guest!") % disk - res = cli.prompt_for_input(warnmsg + _(" Do you really want to use the disk (yes or no)? ")) + warnmsg = _("Disk %s is already in use by another guest!\n") % disk + res = cli.prompt_for_input(warnmsg + _("Do you really want to use the disk (yes or no)? ")) try: if cli.yes_or_no(res) is True: break ---------------------------------------------------------------------- In message <46A75C03.8050404 at redhat.com> "Re: [et-mgmt-tools] [PATCH] check the existing file in virt-install" "Cole Robinson " wrote: > Masayuki Sunou wrote: > > Hi > > > > When the existing file is specified with virt-install, the file is > > compulsorily overwrited. > > Therefore the important file may be overwrited when a user makes a typo. > > > > This patch fixes so that virt-install displays warning message when > > the existing file is specified. > > > > Signed-off-by: Masayuki Sunou > > > > Thanks, > > Masayuki Sunou. > > Patch looks fine to me. A small nitpick though: I'd change "Do you > really want to use the disk?" to "Do you really want to use this file?" > and add a newline at the start of the line to prevent it from wrapping. > > - Cole > > -- > Cole Robinson > crobinso at redhat.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From fj1826dm at aa.jp.fujitsu.com Thu Jul 26 05:50:56 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Thu, 26 Jul 2007 14:50:56 +0900 Subject: [et-mgmt-tools] Question about two changesets of virt-manager Message-ID: <200707261450.GID07061.37GEN2K9@aa.jp.fujitsu.com> Hi I notice that the following two changesets were committed to the repository of virt-manager today. - changeset: Try and force GC of domain objects - changeset: Second attempt at forcing release of virDomainPtr objects Will you tell me whether these are the fixing for the following bug that I issued? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246198 --> This problem is not found when I test it today. Thanks Masayuki Sunou From veillard at redhat.com Thu Jul 26 07:36:08 2007 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 26 Jul 2007 03:36:08 -0400 Subject: [et-mgmt-tools] Question about two changesets of virt-manager In-Reply-To: <200707261450.GID07061.37GEN2K9@aa.jp.fujitsu.com> References: <200707261450.GID07061.37GEN2K9@aa.jp.fujitsu.com> Message-ID: <20070726073607.GN26366@redhat.com> On Thu, Jul 26, 2007 at 02:50:56PM +0900, Masayuki Sunou wrote: > Hi > > I notice that the following two changesets were committed to the > repository of virt-manager today. > > - changeset: Try and force GC of domain objects > - changeset: Second attempt at forcing release of virDomainPtr objects > > Will you tell me whether these are the fixing for the following bug > that I issued? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246198 > --> This problem is not found when I test it today. Yes, that could cause that kind of problem. Basically the deallocation within libvirt was dependant on Python garbage collector deallocation of the unreferenced Python object for the domain, and sometimes this wasn't done before a new domain with the same name was created again, leading to clash between libvirt internal cache for the old but still present domain object and the new one being created. I think this bug has been around nearly forever, taking different shape from an user perspective depending on the situation, and 246198 looks very much like one of those. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From berrange at redhat.com Thu Jul 26 13:23:15 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 26 Jul 2007 14:23:15 +0100 Subject: [et-mgmt-tools] Question about two changesets of virt-manager In-Reply-To: <200707261450.GID07061.37GEN2K9@aa.jp.fujitsu.com> References: <200707261450.GID07061.37GEN2K9@aa.jp.fujitsu.com> Message-ID: <20070726132315.GA20102@redhat.com> On Thu, Jul 26, 2007 at 02:50:56PM +0900, Masayuki Sunou wrote: > Hi > > I notice that the following two changesets were committed to the > repository of virt-manager today. > > - changeset: Try and force GC of domain objects > - changeset: Second attempt at forcing release of virDomainPtr objects > > Will you tell me whether these are the fixing for the following bug > that I issued? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246198 > --> This problem is not found when I test it today. Yes, those two fixes should resolve that problem. 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 Greg.Caetano at hp.com Thu Jul 26 13:56:27 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Thu, 26 Jul 2007 09:56:27 -0400 Subject: [et-mgmt-tools] Xen Guest installation using incorrect bridge Message-ID: This may be related to the issue I was having previously when the Xen guest was not receiving a DHCP address but the scenario now is: On a RHEL5 AP system (kernel 2.6.18-8.1.8.el5xen and xen 3.0.3-25.0.3.el5) during a "new machine" create using the Virtual Machine Manager, the guest starts and appears in the VMM window but is paused. A dialog box then appears stating: virDomainCreateLinux() failed If I used "virsh dumpxml" on the guest I see the "source bridge" as "xenbr1" for my network interface. How is the source bridge selected? I only have a xenbr0 defined on the system although I do have two functioning network interfaces: Local rack network: eth0 192.168.0.0 network External rack network: eth1 10.100.100.0 network and default gateway/route to the rest of the world I have one change in xend-config.sxp to have the guests only use eth0: #(network-script network-bridge) (network-script 'network-bridge bridge=xenbr0 netdev=eth0') # brctl show bridge name bridge id STP enabled interfaces xenbr0 8000.feffffffffff no peth0 vif0.1 I get the same results using virt-install as well. I can get around the issue if I pass the correct bridge to the virt-install program (virt-install -b xenbr0) Thanks greg Greg Caetano greg.caetano at hp.com From atodorov at redhat.com Thu Jul 26 14:05:05 2007 From: atodorov at redhat.com (Alexander Todorov) Date: Thu, 26 Jul 2007 16:05:05 +0200 Subject: [et-mgmt-tools] [patch] GUI for additional kernel parameters for Virtual Machine Manager Message-ID: <46A8AA11.9090309@redhat.com> Hello list, A couple of months ago I sent a patch to do %subject but it never was applied. Probably because I sent it to a wrong list (fedora-xen). The original message is here: http://www.redhat.com/archives/fedora-xen/2007-May/msg00037.html The patch is here: http://www.redhat.com/archives/fedora-xen/2007-May/binBR77mQtLEz.bin If need I can rework it a bit for HEAD. Greetings, Alexander. From berrange at redhat.com Thu Jul 26 14:08:17 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 26 Jul 2007 15:08:17 +0100 Subject: [et-mgmt-tools] [patch] GUI for additional kernel parameters for Virtual Machine Manager In-Reply-To: <46A8AA11.9090309@redhat.com> References: <46A8AA11.9090309@redhat.com> Message-ID: <20070726140817.GE20102@redhat.com> On Thu, Jul 26, 2007 at 04:05:05PM +0200, Alexander Todorov wrote: > Hello list, > A couple of months ago I sent a patch to do %subject but it never was > applied. Probably because I sent it to a wrong list (fedora-xen). > > The original message is here: > http://www.redhat.com/archives/fedora-xen/2007-May/msg00037.html > > The patch is here: > http://www.redhat.com/archives/fedora-xen/2007-May/binBR77mQtLEz.bin > > If need I can rework it a bit for HEAD. Opps, I thought we'd already merged this patch. I've no objections to including it based on the discussions in the previous thread . 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 atodorov at redhat.com Thu Jul 26 14:31:11 2007 From: atodorov at redhat.com (Alexander Todorov) Date: Thu, 26 Jul 2007 16:31:11 +0200 Subject: [et-mgmt-tools] [patch] GUI for additional kernel parameters for Virtual Machine Manager In-Reply-To: <20070726140817.GE20102@redhat.com> References: <46A8AA11.9090309@redhat.com> <20070726140817.GE20102@redhat.com> Message-ID: <46A8B02F.7070906@redhat.com> Daniel P. Berrange wrote: > Opps, I thought we'd already merged this patch. I've no objections to > including it based on the discussions in the previous thread . That was my impression. Probably it was forgotten. Greetings, Alexander. From mdehaan at redhat.com Thu Jul 26 16:16:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 26 Jul 2007 12:16:05 -0400 Subject: [et-mgmt-tools] Koan on a RHEL3 client In-Reply-To: <46A7C936.9040802@redhat.com> References: <46A7C936.9040802@redhat.com> Message-ID: <46A8C8C5.3000607@redhat.com> Michael DeHaan wrote: > Jim Wildman wrote: >> I need/want to use koan to rebuild a rhel3 server. However it errors >> out like this. > > I thought that used to work on RHEL 3 -- apparently I must have > switched to optparse in the last 6 months or so? > optparse is new in Python 2.3, and is just there to parse the command > line. > > Short term, I don't have a quick fix for this, but I'll remove the > dependency as this is supposed to work. > > --Michael > Rather than changing the option parsing, I've packaged optparse with koan so it should now work on Python 2.2 clients. If there are other compatibility issues, send email or ping me on IRC. git clone git://git.fedoraproject.org/git/hosted/koan Remember that koan 0.5.x+ does require a 0.5.x+ cobbler server. --Michael From fj1826dm at aa.jp.fujitsu.com Fri Jul 27 00:02:30 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Fri, 27 Jul 2007 09:02:30 +0900 Subject: [et-mgmt-tools] Question about two changesets of virt-manager In-Reply-To: <20070726132315.GA20102@redhat.com> References: <200707261450.GID07061.37GEN2K9@aa.jp.fujitsu.com> <20070726132315.GA20102@redhat.com> Message-ID: <200707270902.GIF43737.KNGE7923@aa.jp.fujitsu.com> Hi Daniel, Dan > Yes, those two fixes should resolve that problem. > Thanks for the reply and the fixing. Our team members wish this fixing is applied to RHEL5.1. thanks Masayuki Sunou In message <20070726132315.GA20102 at redhat.com> "Re: [et-mgmt-tools] Question about two changesets of virt-manager" ""Daniel P. Berrange" " wrote: > On Thu, Jul 26, 2007 at 02:50:56PM +0900, Masayuki Sunou wrote: > > Hi > > > > I notice that the following two changesets were committed to the > > repository of virt-manager today. > > > > - changeset: Try and force GC of domain objects > > - changeset: Second attempt at forcing release of virDomainPtr objects > > > > Will you tell me whether these are the fixing for the following bug > > that I issued? > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246198 > > --> This problem is not found when I test it today. > > Yes, those two fixes should resolve that problem. > > 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 > From fj1826dm at aa.jp.fujitsu.com Fri Jul 27 00:37:38 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Fri, 27 Jul 2007 09:37:38 +0900 Subject: [et-mgmt-tools] [PATCH] Check the physical network device regularly Message-ID: <200707270937.AHE34818.3ENK2G79@aa.jp.fujitsu.com> Hi Virt-manager gets the information of the shared physical network device only at the time of start. Therefore, "Not bridged" is displayed on the screen, even if the physical network device is bridged while virt-manager is working. (ex: # /etc/xen/scripts/network-bridge start bridge=xenbr1 vifnum=1 netdev=eth1) This patch fixes it by checking the state of the physical device regularly. Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. ---------------------------------------------------------------------- diff -r 8bd1b2ab7296 src/virtManager/connection.py --- a/src/virtManager/connection.py Sun Jul 15 17:02:52 2007 -0400 +++ b/src/virtManager/connection.py Thu Jul 26 11:27:41 2007 +0900 @@ -113,41 +113,45 @@ class vmmConnection(gobject.GObject): def _device_added(self, path): obj = self.bus.get_object("org.freedesktop.Hal", path) if obj.QueryCapability("net"): - if not self.netdevs.has_key(path): - name = obj.GetPropertyString("net.interface") - mac = obj.GetPropertyString("net.address") - - # Now magic to determine if the device is part of a bridge - shared = False - bridge = None - try: - # XXX Linux specific - needs porting for other OS - patches - # welcomed... - sysfspath = obj.GetPropertyString("linux.sysfs_path") - - # Sick, disgusting hack for Xen netloop crack which renames - # ethN -> pethN, but which HAL never sees - psysfspath = sysfspath[0:len(sysfspath)-len(name)] + "p" + name - if os.path.exists(psysfspath): - sysfspath = psysfspath - - brportpath = os.path.join(sysfspath, "brport") - - if os.path.exists(brportpath): - shared = True - brlinkpath = os.path.join(brportpath, "bridge") - dest = os.readlink(brlinkpath) - (head,tail) = os.path.split(dest) - bridge = tail - except: - (type, value, stacktrace) = sys.exc_info () - logging.error("Unable to determine if device is shared:" + - str(type) + " " + str(value) + "\n" + \ - traceback.format_exc (stacktrace)) - - dev = vmmNetDevice(self.config, self, name, mac, shared, bridge) - self.netdevs[path] = dev - self.emit("netdev-added", dev.get_name()) + name = obj.GetPropertyString("net.interface") + mac = obj.GetPropertyString("net.address") + + # Now magic to determine if the device is part of a bridge + shared = False + bridge = None + try: + # XXX Linux specific - needs porting for other OS - patches + # welcomed... + sysfspath = obj.GetPropertyString("linux.sysfs_path") + + # Sick, disgusting hack for Xen netloop crack which renames + # ethN -> pethN, but which HAL never sees + psysfspath = sysfspath[0:len(sysfspath)-len(name)] + "p" + name + if os.path.exists(psysfspath): + sysfspath = psysfspath + + brportpath = os.path.join(sysfspath, "brport") + + if os.path.exists(brportpath): + shared = True + brlinkpath = os.path.join(brportpath, "bridge") + dest = os.readlink(brlinkpath) + (head,tail) = os.path.split(dest) + bridge = tail + except: + (type, value, stacktrace) = sys.exc_info () + logging.error("Unable to determine if device is shared:" + + str(type) + " " + str(value) + "\n" + \ + traceback.format_exc (stacktrace)) + + if self.netdevs.has_key(path): + currDev = self.netdevs[path] + if currDev.get_info() == (name, mac, shared, bridge): + return + del self.netdevs[path] + dev = vmmNetDevice(self.config, self, name, mac, shared, bridge) + self.netdevs[path] = dev + self.emit("netdev-added", dev.get_name()) def _device_removed(self, path): if self.netdevs.has_key(path): @@ -321,6 +325,11 @@ class vmmConnection(gobject.GObject): newInactiveNetNames = self.vmm.listDefinedNetworks() except: logging.warn("Unable to list inactive networks") + + # check of net devices + newPaths = self.hal_iface.FindDeviceByCapability("net") + for newPath in newPaths: + self._device_added(newPath) for name in newActiveNetNames: net = self.vmm.networkLookupByName(name) diff -r 8bd1b2ab7296 src/virtManager/netdev.py --- a/src/virtManager/netdev.py Sun Jul 15 17:02:52 2007 -0400 +++ b/src/virtManager/netdev.py Thu Jul 26 10:36:39 2007 +0900 @@ -45,4 +45,7 @@ class vmmNetDevice(gobject.GObject): def get_mac(self): return self.mac + def get_info(self): + return (self.name, self.mac, self.shared, self.bridge) + gobject.type_register(vmmNetDevice) ---------------------------------------------------------------------- From jim at rossberry.com Fri Jul 27 01:57:02 2007 From: jim at rossberry.com (Jim Wildman) Date: Thu, 26 Jul 2007 21:57:02 -0400 (EDT) Subject: [et-mgmt-tools] Koan on a RHEL3 client In-Reply-To: <46A8C8C5.3000607@redhat.com> References: <46A7C936.9040802@redhat.com> <46A8C8C5.3000607@redhat.com> Message-ID: On Thu, 26 Jul 2007, Michael DeHaan wrote: > Rather than changing the option parsing, I've packaged optparse with koan so > it should now work on Python 2.2 clients. If there are other compatibility > issues, send email or ping me on IRC. > > git clone git://git.fedoraproject.org/git/hosted/koan > > Remember that koan 0.5.x+ does require a 0.5.x+ cobbler server. > > --Michael Thanks! I'll give it a shot tomorrow... ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine From tc.nuwal at gmail.com Fri Jul 27 07:15:49 2007 From: tc.nuwal at gmail.com (trilok nuwal) Date: Fri, 27 Jul 2007 12:45:49 +0530 Subject: [et-mgmt-tools] Fwd: Virt-install with CD In-Reply-To: References: Message-ID: Hi Xen Users, I am using virt-install for HVM domain instllation. Form DVD it is fine, but how I can use virt-install with cds. How i can give all CDs location to virt-install. #virt-install --debug --name=el5 --ram=400 --vcpus=8 -c /tmp/el5-dvd.iso --file=/tmp/el5 -s 10 --vnc --hvm 2>&1 | tee virt.log Anybody have idea. would be a great help. Thanks, Trilok -------------- next part -------------- An HTML attachment was scrubbed... URL: From atodorov at redhat.com Fri Jul 27 07:18:17 2007 From: atodorov at redhat.com (Alexander Todorov) Date: Fri, 27 Jul 2007 09:18:17 +0200 Subject: [et-mgmt-tools] Exception: Domain named %s already exists Message-ID: <46A99C39.2030708@redhat.com> Hello, I've just seen this error: Unable to complete install 'exceptions.RuntimeError Domain named tilix already exists! Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 681, in do_install dom = guest.start_install(False, meter = meter) 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 658, in _do_install raise RuntimeError, "Domain named %s already exists!" %(self.name,) RuntimeError: Domain named tilix already exists! ' Is this a bug or intentionally? I remember in older version of virtManager one can use the same name and the config file was overwritten. Greetings, Alexander. From berrange at redhat.com Fri Jul 27 11:57:28 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 27 Jul 2007 12:57:28 +0100 Subject: [et-mgmt-tools] Question about two changesets of virt-manager In-Reply-To: <200707270902.GIF43737.KNGE7923@aa.jp.fujitsu.com> References: <200707261450.GID07061.37GEN2K9@aa.jp.fujitsu.com> <20070726132315.GA20102@redhat.com> <200707270902.GIF43737.KNGE7923@aa.jp.fujitsu.com> Message-ID: <20070727115728.GC11416@redhat.com> On Fri, Jul 27, 2007 at 09:02:30AM +0900, Masayuki Sunou wrote: > Hi Daniel, Dan > > > Yes, those two fixes should resolve that problem. > > > Thanks for the reply and the fixing. > Our team members wish this fixing is applied to RHEL5.1. There is a BZ that is tracking this fix for RHEL-5.1 too https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249094 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 Fri Jul 27 12:07:38 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 27 Jul 2007 13:07:38 +0100 Subject: [et-mgmt-tools] Exception: Domain named %s already exists In-Reply-To: <46A99C39.2030708@redhat.com> References: <46A99C39.2030708@redhat.com> Message-ID: <20070727120738.GE11416@redhat.com> On Fri, Jul 27, 2007 at 09:18:17AM +0200, Alexander Todorov wrote: > Hello, > > I've just seen this error: > > Unable to complete install 'exceptions.RuntimeError Domain named tilix > already exists! > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/create.py", line 681, in > do_install > dom = guest.start_install(False, meter = meter) > 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 658, > in _do_install > raise RuntimeError, "Domain named %s already exists!" %(self.name,) > RuntimeError: Domain named tilix already exists! > ' > > Is this a bug or intentionally? I remember in older version of > virtManager one can use the same name and the config file was overwritten. Yep this is intentionale to protect people against typo which accidentally overwrite their VM. The main guest list window has a 'delete' button to let you remove existing VM & its config, at which point you'll get past this check. BTW, did you get a popup dialog box showing you the error, or was it merely logged to the console as this stack trace ? It should popup a dialog & its a bug if it doesn/t 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 atodorov at redhat.com Fri Jul 27 12:22:52 2007 From: atodorov at redhat.com (Alexander Todorov) Date: Fri, 27 Jul 2007 14:22:52 +0200 Subject: [et-mgmt-tools] Exception: Domain named %s already exists In-Reply-To: <20070727120738.GE11416@redhat.com> References: <46A99C39.2030708@redhat.com> <20070727120738.GE11416@redhat.com> Message-ID: <46A9E39C.6070408@redhat.com> Daniel P. Berrange wrote: > Yep this is intentionale to protect people against typo which accidentally > overwrite their VM. IMO there should not be an error dialog showing but something cooler like: A VM with name %s already exists. Do you want to overwrite? YES | NO The main guest list window has a 'delete' button to > let you remove existing VM & its config, at which point you'll get past > this check. > > BTW, did you get a popup dialog box showing you the error, or was it > merely logged to the console as this stack trace ? It should popup a > dialog & its a bug if it doesn/t Yes I got the popup dialog showing the error. > > Regards, > Dan. From mdehaan at redhat.com Fri Jul 27 17:49:46 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 27 Jul 2007 13:49:46 -0400 Subject: [et-mgmt-tools] %include In-Reply-To: References: Message-ID: <46AA303A.5010407@redhat.com> drew einhorn wrote: > My kickstarts would be simpler and more readable if I could put stuff > that's frequently used in many kickstarts in a separate file and use > %include > Where do I put the files so kickstart can find them when the time comes. > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I've just committed a neat feature to allow easy includes in kickstart templates without needing to do the host-on-http-server / wget-in-pre / %include trick. To do this, in a kickstart template, you can now say: SNIPPET::name_of_snippet and it will automatically include the contents of /var/lib/cobbler/snippets/name_of_snippet The interestingness here is that the snippet definition can also contain further Cobbler templating variables that are profile and/or system specific -- which is something you can't do in Anaconda without a lot of black magic. Currently Cobbler includes only one sample snippet as an example, and you will see SNIPPET::partition_select in the new default kickstarts. Folks can define as many more as they like by adding files to /var/lib/cobbler/snippets/, giving each file a descriptive name. --Michael From thestrider at gmail.com Sat Jul 28 00:43:46 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Fri, 27 Jul 2007 20:43:46 -0400 Subject: [et-mgmt-tools] %include In-Reply-To: <46AA303A.5010407@redhat.com> References: <46AA303A.5010407@redhat.com> Message-ID: <46AA9142.8020900@gmail.com> Nice!!! Will make use of this! Examples should fit nicely in the KickstartTemplating WiKi page. :) -A. Michael DeHaan wrote: > drew einhorn wrote: >> My kickstarts would be simpler and more readable if I could put stuff >> that's frequently used in many kickstarts in a separate file and use >> %include >> Where do I put the files so kickstart can find them when the time comes. >> >> -- >> Drew Einhorn >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > I've just committed a neat feature to allow easy includes in kickstart > templates without needing to do the host-on-http-server / wget-in-pre > / %include trick. > > To do this, in a kickstart template, you can now say: > > SNIPPET::name_of_snippet > > and it will automatically include the contents of > /var/lib/cobbler/snippets/name_of_snippet > > The interestingness here is that the snippet definition can also > contain further Cobbler templating variables that are profile and/or > system specific -- which is something > you can't do in Anaconda without a lot of black magic. > > Currently Cobbler includes only one sample snippet as an example, and > you will see SNIPPET::partition_select in the new default > kickstarts. Folks can define as many more as they like by adding > files to /var/lib/cobbler/snippets/, giving each file a descriptive name. > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From thestrider at gmail.com Sat Jul 28 08:04:51 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Sat, 28 Jul 2007 04:04:51 -0400 Subject: [et-mgmt-tools] [PATCH] Koan virt-path bug Message-ID: <46AAF8A3.50202@gmail.com> With the convention of '--virt-path=Volume_Group', we should examine the free space on the 'volume group' -- not the 'logical volume'... Koan won't run with --virt-path specified as such... patch below. --A. """ Begin Patch """ --- app.py.orig 2007-07-28 03:25:52.000000000 -0400 +++ app.py 2007-07-28 04:01:17.000000000 -0400 @@ -985,7 +985,7 @@ raise InfoException, "The volume group [%s] does not exist." % location # check free space - args = "/usr/sbin/lvs --noheadings -o vg_free --units g %s" % location + args = "/usr/sbin/vgs --noheadings -o vg_free --units g %s" % location print args cmd = sub_process.Popen(args, stdout=sub_process.PIPE, shell=True) freespace_str = cmd.communicate()[0] """ End Patch """ From fj0588di at aa.jp.fujitsu.com Mon Jul 30 00:54:01 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Mon, 30 Jul 2007 09:54:01 +0900 Subject: [et-mgmt-tools] [PATCH] check if the specified disk using virt-clone is already used in another guests. Message-ID: <200707300954.AFB05251.9EKJ60G9@aa.jp.fujitsu.com> Hi Current virt-clone does not confirm if the specified disk is already used in another guests or not. So, I create the patch to check if the specified disk using virt-clone is already used in another guests. Signed-off-by: Shigeki Sakamoto Thanks, Shigeki Sakamoto. ---------------------------------------------------------------------- diff -r 645217bda13b virtinst/CloneManager.py --- a/virtinst/CloneManager.py Sat Jul 21 13:03:07 2007 -0400 +++ b/virtinst/CloneManager.py Fri Jul 27 17:38:47 2007 +0900 @@ -29,6 +29,7 @@ import commands import commands import libvirt import Guest +import cli from virtinst import _virtinst as _ # @@ -106,6 +107,13 @@ class CloneDesign(object): def set_clone_devices(self, devices): if len(devices) == 0: raise ValueError, _("New file to use for disk image is required") + cdev = [] + cdev_size = [] + cdev_type = [] + cdev.append(devices) + cdev_size,\ + cdev_type = self._get_clone_devices_info(cdev) + devices = self._check_file(self._hyper_conn, devices, cdev_size) self._clone_devices.append(devices) def get_clone_devices(self): return self._clone_devices @@ -320,6 +328,45 @@ class CloneDesign(object): except libvirt.libvirtError, e: pass return check + + # + # check used file func + # ret : Use File Path + # + def _check_file(self, conn, disk, size): + retryFlg = False + while 1: + if disk == None: + msg = _("What would you like to use as the disk (path)?") + disk = cli.prompt_for_input(msg, disk) + + try: + d = Guest.VirtualDisk(disk, size) + if d.is_conflict_disk(conn) is True: + while 1: + retryFlg = False + warnmsg = _("Disk %s is already in use by another guest!\n") % disk + res = cli.prompt_for_input(warnmsg + _("Do you really want to use the disk (yes or no)? ")) + try: + if cli.yes_or_no(res) is True: + break + else: + retryFlg = True + break + except ValueError, e: + print _("ERROR: "), e + continue + if retryFlg is True: + disk = None + continue + except ValueError, e: + print _("ERROR: "), e + disk = None + continue + + break + + return disk # # check used mac func From hbrock at redhat.com Mon Jul 30 13:43:46 2007 From: hbrock at redhat.com (Hugh Brock) Date: Mon, 30 Jul 2007 09:43:46 -0400 Subject: [et-mgmt-tools] [patch] GUI for additional kernel parameters for Virtual Machine Manager In-Reply-To: <46A8B02F.7070906@redhat.com> References: <46A8AA11.9090309@redhat.com> <20070726140817.GE20102@redhat.com> <46A8B02F.7070906@redhat.com> Message-ID: <46ADEB12.4090501@redhat.com> Alexander Todorov wrote: > Daniel P. Berrange wrote: >> Opps, I thought we'd already merged this patch. I've no objections to >> including it based on the discussions in the previous thread . > > That was my impression. Probably it was forgotten. > Yes, sorry, it fell through the cracks. Would you mind reworking it for HEAD and we'll apply it? Thanks, --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 hbrock at redhat.com Mon Jul 30 14:05:12 2007 From: hbrock at redhat.com (Hugh Brock) Date: Mon, 30 Jul 2007 10:05:12 -0400 Subject: [et-mgmt-tools] [PATCH] check the existing file in virt-install In-Reply-To: <200707261449.CBI78177.37G2KEN9@aa.jp.fujitsu.com> References: <200707240842.FFB73428.NEKG9237@aa.jp.fujitsu.com> <46A75C03.8050404@redhat.com> <200707261449.CBI78177.37G2KEN9@aa.jp.fujitsu.com> Message-ID: <46ADF018.7000102@redhat.com> Masayuki Sunou wrote: > Hi Cole > > Thank you for a review and suggestion. > >> Patch looks fine to me. A small nitpick though: I'd change "Do you >> really want to use the disk?" to "Do you really want to use this file?" >> and add a newline at the start of the line to prevent it from wrapping. >> > Because I think that your suggestion is reasonable, I remake this patch. > And I find the another point that had better add a new line. > So this patch adds a new line to there. > I have committed this, thanks very much! --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 hbrock at redhat.com Mon Jul 30 14:05:36 2007 From: hbrock at redhat.com (Hugh Brock) Date: Mon, 30 Jul 2007 10:05:36 -0400 Subject: [et-mgmt-tools] [PATCH] Check the physical network device regularly In-Reply-To: <200707270937.AHE34818.3ENK2G79@aa.jp.fujitsu.com> References: <200707270937.AHE34818.3ENK2G79@aa.jp.fujitsu.com> Message-ID: <46ADF030.1060803@redhat.com> Masayuki Sunou wrote: > Hi > > Virt-manager gets the information of the shared physical network device > only at the time of start. > Therefore, "Not bridged" is displayed on the screen, > even if the physical network device is bridged while virt-manager is working. > (ex: # /etc/xen/scripts/network-bridge start bridge=xenbr1 vifnum=1 netdev=eth1) > > This patch fixes it by checking the state of the physical device regularly. > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. > Committed, thanks! --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 mdehaan at redhat.com Mon Jul 30 14:39:31 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 30 Jul 2007 10:39:31 -0400 Subject: [et-mgmt-tools] [PATCH] Koan virt-path bug In-Reply-To: <46AAF8A3.50202@gmail.com> References: <46AAF8A3.50202@gmail.com> Message-ID: <46ADF823.9080800@redhat.com> Adam Rosenwald wrote: > With the convention of '--virt-path=Volume_Group', we should examine > the free space on the 'volume group' -- not the 'logical volume'... > Koan won't run with --virt-path specified as such... patch below. --A. > > """ Begin Patch """ > > --- app.py.orig 2007-07-28 03:25:52.000000000 -0400 > +++ app.py 2007-07-28 04:01:17.000000000 -0400 > @@ -985,7 +985,7 @@ > raise InfoException, "The volume group [%s] does not > exist." % location > # check free space > - args = "/usr/sbin/lvs --noheadings -o vg_free --units g > %s" % location > + args = "/usr/sbin/vgs --noheadings -o vg_free --units g > %s" % location > print args > cmd = sub_process.Popen(args, stdout=sub_process.PIPE, > shell=True) > freespace_str = cmd.communicate()[0] > > """ End Patch """ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Committed, thanks! --Michael From mdehaan at redhat.com Mon Jul 30 15:34:24 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 30 Jul 2007 11:34:24 -0400 Subject: [et-mgmt-tools] %include In-Reply-To: <46AA9142.8020900@gmail.com> References: <46AA303A.5010407@redhat.com> <46AA9142.8020900@gmail.com> Message-ID: <46AE0500.2080001@redhat.com> Adam Rosenwald wrote: > Nice!!! Will make use of this! > > Examples should fit nicely in the KickstartTemplating WiKi page. :) It's a public wiki ... so community generated examples are always welcome anytime. You'll need to create a Fedora Account System account to get started: https://admin.fedoraproject.org/accounts/ However, just to get folks started, I've written some things up: https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating Probably more than most want to know :) > > -A. > > Michael DeHaan wrote: >> drew einhorn wrote: >>> My kickstarts would be simpler and more readable if I could put >>> stuff that's frequently used in many kickstarts in a separate file >>> and use %include >>> Where do I put the files so kickstart can find them when the time >>> comes. >>> >>> -- >>> Drew Einhorn >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> I've just committed a neat feature to allow easy includes in >> kickstart templates without needing to do the host-on-http-server / >> wget-in-pre / %include trick. >> >> To do this, in a kickstart template, you can now say: >> >> SNIPPET::name_of_snippet >> >> and it will automatically include the contents of >> /var/lib/cobbler/snippets/name_of_snippet >> >> The interestingness here is that the snippet definition can also >> contain further Cobbler templating variables that are profile and/or >> system specific -- which is something >> you can't do in Anaconda without a lot of black magic. >> >> Currently Cobbler includes only one sample snippet as an example, and >> you will see SNIPPET::partition_select in the new default >> kickstarts. Folks can define as many more as they like by adding >> files to /var/lib/cobbler/snippets/, giving each file a descriptive >> name. >> >> --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 drew.einhorn at gmail.com Mon Jul 30 16:52:49 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Mon, 30 Jul 2007 10:52:49 -0600 Subject: [et-mgmt-tools] %include In-Reply-To: <46AE0500.2080001@redhat.com> References: <46AA303A.5010407@redhat.com> <46AA9142.8020900@gmail.com> <46AE0500.2080001@redhat.com> Message-ID: When is 0.5.2 due to hit the repositories? I've cobbled together my own .rpm packages using the latest source from git I think they have some minor problems bad %files section but I think they are close enough for now and I think they will automatically be updated when 0.5.2 hits the repositories. But I'm not 100% sure I haven't made some mistakes that are bigger than I realize, since I have not really built any rpms for years. I'll be happy when my funky rpms are replaced. On 7/30/07, Michael DeHaan wrote: > > Adam Rosenwald wrote: > > Nice!!! Will make use of this! > > > > Examples should fit nicely in the KickstartTemplating WiKi page. :) > > It's a public wiki ... so community generated examples are always > welcome anytime. You'll need to create a Fedora Account System account > to get > started: https://admin.fedoraproject.org/accounts/ > > However, just to get folks started, I've written some things up: > https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating > > Probably more than most want to know :) > > > > > > -A. > > > > Michael DeHaan wrote: > >> drew einhorn wrote: > >>> My kickstarts would be simpler and more readable if I could put > >>> stuff that's frequently used in many kickstarts in a separate file > >>> and use %include > >>> Where do I put the files so kickstart can find them when the time > >>> comes. > >>> > >>> -- > >>> Drew Einhorn > >>> > ------------------------------------------------------------------------ > >>> > >>> > >>> _______________________________________________ > >>> et-mgmt-tools mailing list > >>> et-mgmt-tools at redhat.com > >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > >> > >> I've just committed a neat feature to allow easy includes in > >> kickstart templates without needing to do the host-on-http-server / > >> wget-in-pre / %include trick. > >> > >> To do this, in a kickstart template, you can now say: > >> > >> SNIPPET::name_of_snippet > >> > >> and it will automatically include the contents of > >> /var/lib/cobbler/snippets/name_of_snippet > >> > >> The interestingness here is that the snippet definition can also > >> contain further Cobbler templating variables that are profile and/or > >> system specific -- which is something > >> you can't do in Anaconda without a lot of black magic. > >> > >> Currently Cobbler includes only one sample snippet as an example, and > >> you will see SNIPPET::partition_select in the new default > >> kickstarts. Folks can define as many more as they like by adding > >> files to /var/lib/cobbler/snippets/, giving each file a descriptive > >> name. > >> > >> --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 > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From drew.einhorn at gmail.com Mon Jul 30 17:50:59 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Mon, 30 Jul 2007 11:50:59 -0600 Subject: [et-mgmt-tools] static ip network snippet Message-ID: I have this in %pre ETH=`grep DEVICE /tmp/netinfo | cut -d = -f 2` IP=`ifconfig $ETH | grep "inet " | cut -d : -f 2 | cut -d " " -f 1` NETMASK=`ifconfig $ETH | grep "inet " | cut -d : -f 4` GATEWAY=`route | grep default | cut -b 17-32 | cut -d " " -f 1` HOSTNAME=`grep HOSTNAME /tmp/netinfo | cut -d = -f 2 | cut -d . -f 1` cat << EOF > /tmp/buildnet network --device $ETH --bootproto static --ip=$IP --netmask=$NETMASK --gateway=$GATEWAY --hostname=$HOSTNAME EOF That code setting shell variables is really ugly and I had to fix it. ipv6 info from ifconfig caused problems, and possibly something else I have forgotten According to the wiki: $ip_address and $mac_address are kickstart variables But I still need values for $ETH, $NETMASK, and $GATEWAY A snippet one liner would be nice. -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From drew.einhorn at gmail.com Mon Jul 30 17:58:26 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Mon, 30 Jul 2007 11:58:26 -0600 Subject: [et-mgmt-tools] cobbler system add Message-ID: Near the end of %post I issued a cobbler system add command to bind the dynamically assigned ip to the mac address. After trying it and seeing that it was not working, I said: Duhhhh!!!! It needs to run on the cobbler host, not the box being provisioned. Is there an easy way to do this? I can think of some that are not easy. -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Mon Jul 30 19:35:02 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 30 Jul 2007 15:35:02 -0400 Subject: [et-mgmt-tools] %include In-Reply-To: References: <46AA303A.5010407@redhat.com> <46AA9142.8020900@gmail.com> <46AE0500.2080001@redhat.com> Message-ID: <46AE3D66.80706@redhat.com> drew einhorn wrote: > When is 0.5.2 due to hit the repositories? 0.5.2 won't. 0.5.0 is a development/testing "branch". Given a sufficient period of testing and questions on IRC, if there are no problems, I'll push it to the mirrors as 0.6.0 (stable). Failing any additional feeback, I'll rely on what I've tested and will push in a couple of weeks. > > I've cobbled together my own .rpm packages > using the latest source from git > > I think they have some minor problems > bad %files section This may already be corrected upstream. Depends when your checkout was. > > but I think they are close enough for now > and I think they will automatically be updated when 0.5.2 > hits the repositories. Yes... > > But I'm not 100% sure I haven't made some mistakes that > are bigger than I realize, since I have not really built any > rpms for years. > > I'll be happy when my funky rpms are replaced. Hopefully they aren't any more funky than the specfile already included with Cobbler in the source checkout. ("make", "cd rpm-build", "rpm -i cobbler-something.rpm") > > On 7/30/07, *Michael DeHaan* > wrote: > > Adam Rosenwald wrote: > > Nice!!! Will make use of this! > > > > Examples should fit nicely in the KickstartTemplating WiKi page. :) > > It's a public wiki ... so community generated examples are always > welcome anytime. You'll need to create a Fedora Account System > account > to get > started: https://admin.fedoraproject.org/accounts/ > > However, just to get folks started, I've written some things up: > https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating > > Probably more than most want to know :) > > > > > > -A. > > > > Michael DeHaan wrote: > >> drew einhorn wrote: > >>> My kickstarts would be simpler and more readable if I could put > >>> stuff that's frequently used in many kickstarts in a separate file > >>> and use %include > >>> Where do I put the files so kickstart can find them when the time > >>> comes. > >>> > >>> -- > >>> Drew Einhorn > >>> > ------------------------------------------------------------------------ > >>> > >>> > >>> _______________________________________________ > >>> et-mgmt-tools mailing list > >>> et-mgmt-tools at redhat.com > >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > >> > >> I've just committed a neat feature to allow easy includes in > >> kickstart templates without needing to do the host-on-http-server / > >> wget-in-pre / %include trick. > >> > >> To do this, in a kickstart template, you can now say: > >> > >> SNIPPET::name_of_snippet > >> > >> and it will automatically include the contents of > >> /var/lib/cobbler/snippets/name_of_snippet > >> > >> The interestingness here is that the snippet definition can also > >> contain further Cobbler templating variables that are profile > and/or > >> system specific -- which is something > >> you can't do in Anaconda without a lot of black magic. > >> > >> Currently Cobbler includes only one sample snippet as an > example, and > >> you will see SNIPPET::partition_select in the new default > >> kickstarts. Folks can define as many more as they like by > adding > >> files to /var/lib/cobbler/snippets/, giving each file a descriptive > >> name. > >> > >> --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 > > > > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jul 30 19:35:57 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 30 Jul 2007 15:35:57 -0400 Subject: [et-mgmt-tools] static ip network snippet In-Reply-To: References: Message-ID: <46AE3D9D.9080604@redhat.com> drew einhorn wrote: > I have this in %pre > > ETH=`grep DEVICE /tmp/netinfo | cut -d = -f 2` > IP=`ifconfig $ETH | grep "inet " | cut -d : -f 2 | cut -d " " -f 1` > NETMASK=`ifconfig $ETH | grep "inet " | cut -d : -f 4` > GATEWAY=`route | grep default | cut -b 17-32 | cut -d " " -f 1` > HOSTNAME=`grep HOSTNAME /tmp/netinfo | cut -d = -f 2 | cut -d . -f 1` > > cat << EOF > /tmp/buildnet > network --device $ETH --bootproto static --ip=$IP --netmask=$NETMASK > --gateway=$GATEWAY --hostname=$HOSTNAME > EOF > > That code setting shell variables is really ugly and I had to fix it. > > ipv6 info from ifconfig caused problems, > and possibly something else I have forgotten > > According to the wiki: > > $ip_address and $mac_address are kickstart variables > > But I still need values for $ETH, $NETMASK, and $GATEWAY cobbler system edit --name=foo --ksmeta="eth=eth0 netmask=255.255.255.0 gateway=192.168.1.5" this will give your template three new variables: $eth, $netmask, and $gateway > > A snippet one liner would be nice. > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jul 30 19:47:21 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 30 Jul 2007 15:47:21 -0400 Subject: [et-mgmt-tools] cobbler system add In-Reply-To: References: Message-ID: <46AE4049.8020503@redhat.com> drew einhorn wrote: > Near the end of %post I issued a cobbler system add command > to bind the dynamically assigned ip to the mac address. DHCP reservations work exceedingly well. If you have manage_dhcp turned on in your /var/lib/cobbler/settings it will write your dhcp.conf for you. dnsmasq works even better as you can also pin the hostname from cobbler (dnsmasq does both DHCP and DNS, and cobbler can auto-configure it). Example: vi /var/lib/cobbler/settings manage_dhcp : 1 manage_dhcp_mode : dnsmasq # cobbler system add --name=foo --mac=AA:BB:CC:DD:EE:FF --ip=192.168.1.50 --hostname="foo.example.com" This will ensure that when MAC address AA:BB:CC:DD:EE:FF boots it will automatically get the designed IP and (if using dnsmasq) the given hostname. if you leave manage_dhcp mode to "isc" (the default), you still get the variable $hostname accessible in your kickstart templates, so you can still set hostname/etc, but you will have other hoops to jump through to make it actually use it. Which is what I think you are alluding to below: > > After trying it and seeing that it was not working, I said: > > Duhhhh!!!! > > It needs to run on the cobbler host, not the box being provisioned. > > Is there an easy way to do this? > I can think of some that are not easy. Possibly including... (A) just-once-single-command-authorized-root-ssh (kind of scary) (B) CGI script (still scary) ??? Both of which pose interesting security issues. DHCP reservations are the way to go, IMHO, because they can be done entirely server side -- but I'm not a network administrator and you might have valid reasons for not doing things that way. > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From drew.einhorn at gmail.com Mon Jul 30 20:06:28 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Mon, 30 Jul 2007 14:06:28 -0600 Subject: [et-mgmt-tools] %include In-Reply-To: <46AE3D66.80706@redhat.com> References: <46AA303A.5010407@redhat.com> <46AA9142.8020900@gmail.com> <46AE0500.2080001@redhat.com> <46AE3D66.80706@redhat.com> Message-ID: On 7/30/07, Michael DeHaan wrote: > > drew einhorn wrote: > > When is 0.5.2 due to hit the repositories? > > 0.5.2 won't. 0.5.0 is a development/testing "branch". Given a > sufficient period of testing and questions on IRC, if there are no > problems, I'll push it to the mirrors as 0.6.0 (stable). > > Failing any additional feeback, I'll rely on what I've tested and will > push in a couple of weeks. If 0.6.0 is likely in a couple weeks, I have no need for an 0.5.2 > > > I've cobbled together my own .rpm packages > > using the latest source from git > > > > I think they have some minor problems > > bad %files section > This may already be corrected upstream. Depends when your checkout was. > > You don't realize what I did. I expanded the latest source rpms I could find, 0.5.1 think .spec file in the download directory was a bit newer took the source code from git mashed it all together and built an rpm Think to get it right all I would need to fix the %files section There may be other more subtle problems. I don't know! I'll be glad when I have something I have a bit more faith in. > but I think they are close enough for now > > and I think they will automatically be updated when 0.5.2 > > hits the repositories. > Yes... > > > > But I'm not 100% sure I haven't made some mistakes that > > are bigger than I realize, since I have not really built any > > rpms for years. > > > > I'll be happy when my funky rpms are replaced. > Hopefully they aren't any more funky than the specfile already included > with Cobbler in the source checkout. > > ("make", "cd rpm-build", "rpm -i cobbler-something.rpm") > > > > On 7/30/07, *Michael DeHaan* > > wrote: > > > > Adam Rosenwald wrote: > > > Nice!!! Will make use of this! > > > > > > Examples should fit nicely in the KickstartTemplating WiKi page. > :) > > > > It's a public wiki ... so community generated examples are always > > welcome anytime. You'll need to create a Fedora Account System > > account > > to get > > started: https://admin.fedoraproject.org/accounts/ > > > > However, just to get folks started, I've written some things up: > > > https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating > > > > Probably more than most want to know :) > > > > > > > > > > -A. > > > > > > Michael DeHaan wrote: > > >> drew einhorn wrote: > > >>> My kickstarts would be simpler and more readable if I could put > > >>> stuff that's frequently used in many kickstarts in a separate > file > > >>> and use %include > > >>> Where do I put the files so kickstart can find them when the > time > > >>> comes. > > >>> > > >>> -- > > >>> Drew Einhorn > > >>> > > > ------------------------------------------------------------------------ > > >>> > > >>> > > >>> _______________________________________________ > > >>> et-mgmt-tools mailing list > > >>> et-mgmt-tools at redhat.com > > >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > >> > > >> I've just committed a neat feature to allow easy includes in > > >> kickstart templates without needing to do the host-on-http-server > / > > >> wget-in-pre / %include trick. > > >> > > >> To do this, in a kickstart template, you can now say: > > >> > > >> SNIPPET::name_of_snippet > > >> > > >> and it will automatically include the contents of > > >> /var/lib/cobbler/snippets/name_of_snippet > > >> > > >> The interestingness here is that the snippet definition can also > > >> contain further Cobbler templating variables that are profile > > and/or > > >> system specific -- which is something > > >> you can't do in Anaconda without a lot of black magic. > > >> > > >> Currently Cobbler includes only one sample snippet as an > > example, and > > >> you will see SNIPPET::partition_select in the new default > > >> kickstarts. Folks can define as many more as they like by > > adding > > >> files to /var/lib/cobbler/snippets/, giving each file a > descriptive > > >> name. > > >> > > >> --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 > > > > > > > > > > -- > > Drew Einhorn > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Mon Jul 30 20:14:15 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 30 Jul 2007 16:14:15 -0400 Subject: [et-mgmt-tools] %include In-Reply-To: References: <46AA303A.5010407@redhat.com> <46AA9142.8020900@gmail.com> <46AE0500.2080001@redhat.com> <46AE3D66.80706@redhat.com> Message-ID: <46AE4697.9060203@redhat.com> drew einhorn wrote: > > > If 0.6.0 is likely in a couple weeks, I have no need for an 0.5.2 There's definitely a need for the 0.5 branch. Testing. Bug reports. Helping 0.6.0 be a better release. If no one uses source/testing releases, releases will go a lot slower. If you're willing to try out 0.5.x/source now, you should continue to use it, and the changes coming in 0.6.0 will be very very slight. You'll have a leg up, even. > > > > > I've cobbled together my own .rpm packages > > using the latest source from git > > > > I think they have some minor problems > > bad %files section > This may already be corrected upstream. Depends when your > checkout was. > > > > > You don't realize what I did. > I expanded the latest source rpms I could find, 0.5.1 > think .spec file in the download directory was a bit newer > took the source code from git > mashed it all together and built an rpm yeah, the spec file is in git and "make" is set to use that automagically. > > Think to get it right all I would need to fix the %files section > > There may be other more subtle problems. > I don't know! > > I'll be glad when I have something I have a bit more faith in. "make" straight out of the source checkout builds RPMs. They will build just like they do on anyone else's box. From hbrock at redhat.com Mon Jul 30 20:37:38 2007 From: hbrock at redhat.com (Hugh Brock) Date: Mon, 30 Jul 2007 16:37:38 -0400 Subject: [et-mgmt-tools] VM Images (take 2) In-Reply-To: <1185316484.10994.10.camel@galia.watzmann.net> References: <1185316484.10994.10.camel@galia.watzmann.net> Message-ID: <46AE4C12.309@redhat.com> David Lutterkort wrote: > Hi, > > I've updated the patches [1] for virt-inst that deal with machine > images. The XML format has changed some since the inital patches. Main > changes: > > * the os type/variant business has been removed from the XML. > Instead, the features section now allows specifying acpi/apic > directly, e.g. '' (right now, this requires > some patches [2] to libvirt, too; without them, virt-image will > complain that it can't find a suitable boot descriptor) > * the section in the elements has been changed so > that each disk mapping corresponds to a element instead > of being in / > * the various hardware info (vcpu, memory, interface, graphics) > are in a devices section > * the tag is now called > > For details of the format, look at the example image.xml, and the > Relax-NG grammar, image.rng. > > David > > [1] http://people.redhat.com/dlutter/virt-image/ > [2] https://www.redhat.com/archives/libvir-list/2007-July/msg00395.html > > +1, this all looks good. I will commit it unless anyone objects? --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 drew.einhorn at gmail.com Mon Jul 30 20:52:53 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Mon, 30 Jul 2007 14:52:53 -0600 Subject: [et-mgmt-tools] cobbler system add In-Reply-To: <46AE4049.8020503@redhat.com> References: <46AE4049.8020503@redhat.com> Message-ID: I'm using cobbler on a VMware ESX server. For now, I'm creating VMs by hand using the vmware gui client. When I power them up they PXE boot, I type menu and choose a profile. Was hoping I could nail down the ip to the mac in %post I have been reluctant to manually dig into PM to find mac address and manually make a dhcp reservation. I'm looking into the VMperl API. VMware is calling it a legacy API. Don't know how much longer they will support it. I think it won't be too difficult to use VMperl to create scripts to make an appropriate dhcp reservations, or create a VM to order. Will let you know when I have something more concrete than plans. There's a new VI Perl SDK Beta. Haven't looked at the .exe I downloaded. Haven't found a Linux version. Have a vague recollection of a version issue with dnsmasq on my platform, CentOS5, but that could be my imagination, need to look at this again. Drew On 7/30/07, Michael DeHaan wrote: > > drew einhorn wrote: > > Near the end of %post I issued a cobbler system add command > > to bind the dynamically assigned ip to the mac address. > > DHCP reservations work exceedingly well. If you have manage_dhcp > turned on in your /var/lib/cobbler/settings it will write your dhcp.conf > for you. > dnsmasq works even better as you can also pin the hostname from cobbler > (dnsmasq does both DHCP and DNS, and cobbler can auto-configure it). > > Example: > > vi /var/lib/cobbler/settings > manage_dhcp : 1 > manage_dhcp_mode : dnsmasq > > # cobbler system add --name=foo --mac=AA:BB:CC:DD:EE:FF > --ip=192.168.1.50 --hostname="foo.example.com" > > This will ensure that when MAC address AA:BB:CC:DD:EE:FF boots it will > automatically get the designed IP and (if using dnsmasq) the given > hostname. > > if you leave manage_dhcp mode to "isc" (the default), you still get the > variable $hostname accessible in your kickstart templates, so you can > still set hostname/etc, but you will > have other hoops to jump through to make it actually use it. Which is > what I think you are alluding to below: > > > > > > > > After trying it and seeing that it was not working, I said: > > > > Duhhhh!!!! > > > > It needs to run on the cobbler host, not the box being provisioned. > > > > Is there an easy way to do this? > > I can think of some that are not easy. > > Possibly including... > > (A) just-once-single-command-authorized-root-ssh (kind of scary) > (B) CGI script (still scary) > > ??? > > Both of which pose interesting security issues. DHCP reservations are > the way to go, IMHO, because they can be done entirely server side -- > but I'm not a network administrator and you might have valid reasons for > not doing things that way. > > > > > -- > > Drew Einhorn > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Mon Jul 30 20:56:44 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 30 Jul 2007 21:56:44 +0100 Subject: [et-mgmt-tools] VM Images (take 2) In-Reply-To: <46AE4C12.309@redhat.com> References: <1185316484.10994.10.camel@galia.watzmann.net> <46AE4C12.309@redhat.com> Message-ID: <20070730205644.GK10092@redhat.com> On Mon, Jul 30, 2007 at 04:37:38PM -0400, Hugh Brock wrote: > David Lutterkort wrote: > >Hi, > > > >I've updated the patches [1] for virt-inst that deal with machine > >images. The XML format has changed some since the inital patches. Main > >changes: > > > > * the os type/variant business has been removed from the XML. > > Instead, the features section now allows specifying acpi/apic > > directly, e.g. '' (right now, this requires > > some patches [2] to libvirt, too; without them, virt-image will > > complain that it can't find a suitable boot descriptor) > > * the section in the elements has been changed so > > that each disk mapping corresponds to a element instead > > of being in / > > * the various hardware info (vcpu, memory, interface, graphics) > > are in a devices section > > * the tag is now called > > > >For details of the format, look at the example image.xml, and the > >Relax-NG grammar, image.rng. > > > >David > > > >[1] http://people.redhat.com/dlutter/virt-image/ > >[2] https://www.redhat.com/archives/libvir-list/2007-July/msg00395.html > > > > +1, this all looks good. I will commit it unless anyone objects? The patches are all fine by me - we've reviewed them many times over now so we should commit this. The only additional thing we need to think about now the code is in, is documentation. Of course I'm sure David is on the verge of submitting the additional patch to add two man pages 'virt-image.pod' (describing the command) and 'virt-image.xml.pod' (describing the XML format).. ;-P 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 Mon Jul 30 21:02:01 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 30 Jul 2007 17:02:01 -0400 Subject: [et-mgmt-tools] cobbler system add In-Reply-To: References: <46AE4049.8020503@redhat.com> Message-ID: <46AE51C9.3000706@redhat.com> drew einhorn wrote: > I'm using cobbler on a VMware ESX server. > > For now, I'm creating VMs by hand using the vmware gui client. > > When I power them up they PXE boot, I type menu and choose a profile. > Was hoping I could nail down the ip to the mac in %post > > I have been reluctant to manually dig into PM to find mac > address and manually make a dhcp reservation. This wouldn't be required to pick the MAC and avoid the menu altogether. All that requires is a cobbler system entry for the new machine with the right mac addr and profile assignment. This creates an entry in /tftpboot that the machine would find. Though maybe I'm misunderstanding the problem... > > I'm looking into the VMperl API. VMware is calling it a legacy API. > Don't know how much longer they will support it. > > I think it won't be too difficult to use VMperl to create scripts to > make an appropriate dhcp reservations, or create a VM to order. > Will let you know when I have something more concrete than plans. Excellent. > > There's a new VI Perl SDK Beta. Haven't looked at the .exe > I downloaded. Haven't found a Linux version. Hopefully that is just an installer and it's all web services driven. AFAIK, VMware is supposed to have a WSDL interface. SOAP isn't as clean (or simple) as XMLRPC, but it'll work better than nothing :) > > Have a vague recollection of a version issue with dnsmasq > on my platform, CentOS5, but that could be my imagination, > need to look at this again. > > Drew > > On 7/30/07, *Michael DeHaan* > wrote: > > drew einhorn wrote: > > Near the end of %post I issued a cobbler system add command > > to bind the dynamically assigned ip to the mac address. > > DHCP reservations work exceedingly well. If you have manage_dhcp > turned on in your /var/lib/cobbler/settings it will write your > dhcp.conf > for you. > dnsmasq works even better as you can also pin the hostname from > cobbler > (dnsmasq does both DHCP and DNS, and cobbler can auto-configure it). > > Example: > > vi /var/lib/cobbler/settings > manage_dhcp : 1 > manage_dhcp_mode : dnsmasq > > # cobbler system add --name=foo --mac=AA:BB:CC:DD:EE:FF > --ip=192.168.1.50 --hostname=" > foo.example.com " > > This will ensure that when MAC address AA:BB:CC:DD:EE:FF boots it will > automatically get the designed IP and (if using dnsmasq) the given > hostname. > > if you leave manage_dhcp mode to "isc" (the default), you still > get the > variable $hostname accessible in your kickstart templates, so you can > still set hostname/etc, but you will > have other hoops to jump through to make it actually use it. > Which is > what I think you are alluding to below: > > > > > > > > After trying it and seeing that it was not working, I said: > > > > Duhhhh!!!! > > > > It needs to run on the cobbler host, not the box being provisioned. > > > > Is there an easy way to do this? > > I can think of some that are not easy. > > Possibly including... > > (A) just-once-single-command-authorized-root-ssh (kind of scary) > (B) CGI script (still scary) > > ??? > > Both of which pose interesting security issues. DHCP > reservations are > the way to go, IMHO, because they can be done entirely server side -- > but I'm not a network administrator and you might have valid > reasons for > not doing things that way. > > > > > -- > > Drew Einhorn > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > > > -- > Drew Einhorn > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From atodorov at redhat.com Tue Jul 31 07:20:32 2007 From: atodorov at redhat.com (Alexander Todorov) Date: Tue, 31 Jul 2007 09:20:32 +0200 Subject: [et-mgmt-tools] [patch] GUI for additional kernel parameters for Virtual Machine Manager In-Reply-To: <46ADEB12.4090501@redhat.com> References: <46A8AA11.9090309@redhat.com> <20070726140817.GE20102@redhat.com> <46A8B02F.7070906@redhat.com> <46ADEB12.4090501@redhat.com> Message-ID: <46AEE2C0.4060304@redhat.com> Hugh Brock wrote: > Yes, sorry, it fell through the cracks. Would you mind reworking it for > HEAD and we'll apply it? Sure I will. Just need to find some free time. Greetings, Alexander. From atodorov at redhat.com Tue Jul 31 08:08:51 2007 From: atodorov at redhat.com (Alexander Todorov) Date: Tue, 31 Jul 2007 10:08:51 +0200 Subject: [et-mgmt-tools] [patch] GUI for additional kernel parameters for Virtual Machine Manager In-Reply-To: <46ADEB12.4090501@redhat.com> References: <46A8AA11.9090309@redhat.com> <20070726140817.GE20102@redhat.com> <46A8B02F.7070906@redhat.com> <46ADEB12.4090501@redhat.com> Message-ID: <46AEEE13.5000902@redhat.com> Hugh Brock wrote: > Would you mind reworking it for HEAD and we'll apply it? Changes from original patch: * vmm-create.glade - no changes, merged without conflicts * virtManager/create.py - conflicts resolved. setting guest.extraargs is now in function validate() not finish(). So is processing of kernel params. It should be fine now. Please review. Greetings, Alexander. -------------- next part -------------- A non-text attachment was scrubbed... Name: gui_kernel_params.hg Type: application/octet-stream Size: 9245 bytes Desc: not available URL: