From fj1826dm at aa.jp.fujitsu.com Fri Jun 1 01:08:40 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Fri, 1 Jun 2007 10:08:40 +0900 Subject: [et-mgmt-tools] [PATCH] Fix memory check in interactive mode Message-ID: <200706011008.FEF69245.K9GE7N32@aa.jp.fujitsu.com> Hi When memory is interactively input to virt-install, memory is not checked. ------------------------------------------------------------ # virt-install --name TEST --hvm How much RAM should be allocated (in megabytes)? 1 What would you like to use as the disk (path)? ------------------------------------------------------------ This patch fixes it. Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. ------------------------------------------------------------------------------- diff -r 7fd35e3303c6 virt-install --- a/virt-install Fri May 25 10:49:47 2007 -0400 +++ b/virt-install Thu May 31 10:49:20 2007 +0900 @@ -87,14 +87,14 @@ def get_name(name, guest): def get_memory(memory, guest): while 1: - memory = prompt_for_input("How much RAM should be allocated (in megabytes)?", memory) - if memory < MIN_RAM: - print "ERROR: Installs currently require %d megs of RAM." %(MIN_RAM,) - print "" - memory = None - continue - try: - guest.memory = int(memory) + try: + memory = int(prompt_for_input("How much RAM should be allocated (in megabytes)?", memory)) + if memory < MIN_RAM: + print "ERROR: Installs currently require %d megs of RAM." %(MIN_RAM,) + print "" + memory = None + continue + guest.memory = memory break except ValueError, e: print "ERROR: ", e ------------------------------------------------------------------------------- From fj0873gn at aa.jp.fujitsu.com Fri Jun 1 02:05:05 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Fri, 1 Jun 2007 11:05:05 +0900 Subject: [et-mgmt-tools] [PATCH] [RESEND] Fix continue to install Windows In-Reply-To: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> References: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> Message-ID: <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> Hi, Would you give me a comment on this patch? If not, please apply it. > I can't continue to install Windows HVM domain after first restart. > After the restarting, /dev/cdrom (or ISO path) has not been attached to the domain. > The attached patch solves this problem. > > Signed-off-by: Nobuhiro Itou Thanks, Nobuhiro Itou. diff -r 797e92fd5e0d virtinst/FullVirtGuest.py --- a/virtinst/FullVirtGuest.py Thu May 31 14:20:33 2007 -0400 +++ b/virtinst/FullVirtGuest.py Fri Jun 01 10:57:49 2007 +0900 @@ -227,8 +227,10 @@ class FullVirtGuest(Guest.XenGuest): ret = "" count = 0 for d in self.disks: + backup_path = None if d.transient and not install: if d.device == Guest.VirtualDisk.DEVICE_CDROM: + backup_path = d.path d.path = None else: continue @@ -242,5 +244,7 @@ class FullVirtGuest(Guest.XenGuest): count += 1 disknode = "%(disknode)s%(dev)c" % { "disknode": self.disknode, "dev": ord('a') + count } ret += d.get_xml_config(disknode) + if backup_path: + d.path = backup_path count += 1 return ret diff -r 797e92fd5e0d virtinst/Guest.py --- a/virtinst/Guest.py Thu May 31 14:20:33 2007 -0400 +++ b/virtinst/Guest.py Fri Jun 01 10:59:08 2007 +0900 @@ -625,10 +625,11 @@ class Guest(object): else: action = "restart" + osblob_install = install if disk_boot: - install = False - - osblob = self._get_osblob(install) + osblob_install = False + + osblob = self._get_osblob(osblob_install) if not osblob: return None From kraxel at redhat.com Fri Jun 1 08:57:49 2007 From: kraxel at redhat.com (Gerd Hoffmann) Date: Fri, 01 Jun 2007 10:57:49 +0200 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting when virt-managercreates VM In-Reply-To: <20070530031136.GA15129@redhat.com> References: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> <20070524014100.GC21564@redhat.com> <200705291644.JHC35443.96JEGK09@aa.jp.fujitsu.com> <20070530031136.GA15129@redhat.com> Message-ID: <465FDF8D.4080706@redhat.com> Hi, > b. The admin of the Dom0 only opens specific ports for short periods of time. In this > case the admin will have to lookup what port corresponds to a VM, so it doesn't matter > whether we're using fixed or dynamic ports, the admin still has same amount of work > to lookup a port. Sorry for jumping in here, but the "lookup port" thingy rings a bell ;) A IMHO useful feature would be mdns announcements via avahi for vnc screens and text consoles (assuming they are not bound to 127.0.0.1, so they are actually reachable from other machines). I've hacked up a mdns announce utility. Works using xenstore watches. Has the drawback of announcing everything (because xenstore doesn't tell you whenever it is bound to localhost or not) and is obviously limited to xen. libvirt should be able to do that in a better way. Or maybe qemu should do that directly? cheers, Gerd From hbrock at redhat.com Fri Jun 1 13:16:16 2007 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 01 Jun 2007 09:16:16 -0400 Subject: [et-mgmt-tools] [PATCH] [RESEND] Fix continue to install Windows In-Reply-To: <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> References: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> Message-ID: <46601C20.8000305@redhat.com> Nobuhiro Itou wrote: > Hi, > > Would you give me a comment on this patch? > If not, please apply it. > >> I can't continue to install Windows HVM domain after first restart. >> After the restarting, /dev/cdrom (or ISO path) has not been attached to the domain. >> The attached patch solves this problem. >> >> Signed-off-by: Nobuhiro Itou > > > Thanks, > Nobuhiro Itou. > Oops, sorry, I did apply it but forgot to post. 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 Daniel.Hennessey at aah.co.uk Fri Jun 1 14:28:41 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Fri, 1 Jun 2007 15:28:41 +0100 Subject: [et-mgmt-tools] koan --virt error Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C20@GBW607SC0054.GB-WS.net> Michael, Thanks for your prompt reply, you were spot on. I set the selinux policy to "permissive" in "system-config-security" and now all proceeds as expected. No reboot required. I can now install xen guests using koan. One problem I have now is that the install fails if I include the "xconfig" in the kickstart file as the xen instance doesn't have a graphical display. Does koan call virt-install to do the actual install? If it does then it is just a matter of including the "--vnc" switch in the command line. What do you suggest? TIA and FYI I am really excited about the potential of using cobbler to provision our real and virtual servers. I am also trying to work in puppet for centralised configuration. This could be the answer to all my (and my employers) prayers. Exciting times indeed thanks to you and all the other OSS workers out there Cheers 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: 31 May 2007 3:47 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] koan --virt error hennesd wrote: > Hey guys, > > I am trying to use "koan" to provision a xen guest instance but it is > failing and I can't work out why. > > I have imported my distros, created my profiles and that side of > things all seems to be fine. > > I have cobbler installed on a RHEL4 system and I am trying to create > the guest instance on a CentOS5.0 system. I can create a guest > instance using "virt-install" using the same config that koan uses and > it all works fine. > > The output from koan follows: > > [root at gbw607su1041 ~]# koan -s 221.206.29.50 -x -p CentOS5.0-xen-i386 > -V testy2 > - {'kickstart': > 'http://221.206.29.50/cblr/kickstarts/CentOS5.0-xen-i386/ks.cfg', > 'name': 'CentOS5.0-xen-i386', 'virt_ram': 256, 'repos': [], > 'kernel_options': 'ksdevice=eth0 lang=uk syslog=221.206.29.50:25150 > text ', 'ks_meta': '', 'virt_file_size': 1, 'virt_paravirt': 'True', > 'distro': 'CentOS5.0-xen-i386'} > - fetching configuration for distro: CentOS5.0-xen-i386 > - {'kernel': > '/var/www/cobbler/ks_mirror/CentOS5.0/images/xen/vmlinuz', > 'ks_meta': 'tree=http://221.206.29.50/cblr/links/CentOS5.0-xen-i386 ', > 'breed': 'redhat', 'source_repos': > [['http://221.206.29.50/cobbler/ks_mirror/config/CentOS5.0-xen-i386-0.re po', 'http://221.206.29.50/cobbler/ks_mirror/CentOS5.0'], ['http://221.206.29.50/cobbler/ks_mirror/config/CentOS5.0-xen-i386-1.rep o', 'http://221.206.29.50/cobbler/ks_mirror/CentOS5.0']], 'kernel_options': 'ksdevice=eth0 lang=uk syslog=221.206.29.50:25150 text ', 'initrd': '/var/www/cobbler/ks_mirror/CentOS5.0/images/xen/initrd.img', 'arch': 'x86', 'name': 'CentOS5.0-xen-i386'} > - downloading initrd initrd.img to /tmp/initrd.img > - url=http://221.206.29.50/cobbler/images/CentOS5.0-xen-i386/initrd.img > - downloading kernel vmlinuz to /tmp/vmlinuz > - url=http://221.206.29.50/cobbler/images/CentOS5.0-xen-i386/vmlinuz > - kernel saved = /tmp/vmlinuz > - initrd saved = /tmp/initrd.img > libvir: Xen Daemon error : POST operation failed: (xend.err 'Error > creating domain: Kernel image does not exist: /tmp/vmlinuz') > Failed to create domain testy2 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/koan/app.py", line 108, in main > k.run() > File "/usr/lib/python2.4/site-packages/koan/app.py", line 174, in run > self.do_virt() > File "/usr/lib/python2.4/site-packages/koan/app.py", line 306, in > do_virt > return self.do_net_install("/tmp",after_download) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 275, in > do_net_install > after_download(self, distro_data, profile_data) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 305, in > after_download > self.do_virt_net_install(profile_data, distro_data) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 629, in > do_virt_net_install > nameoverride=self.virtname > File "/usr/lib/python2.4/site-packages/koan/virtcreate.py", line 106, > in start_paravirt_install > guest.start_install() > File "/usr/lib/python2.4/site-packages/virtinst/ParaVirtGuest.py", > line 220, in start_install > return XenGuest.XenGuest.start_install(self, consolecb) > File "/usr/lib/python2.4/site-packages/virtinst/XenGuest.py", line > 367, in start_install > self.domain = self.conn.createLinux(cxml, 0) > File "/usr/lib/python2.4/site-packages/libvirt.py", line 251, in > createLinux > if ret is None:raise libvirtError('virDomainCreateLinux() failed') > libvirtError: virDomainCreateLinux() failed > > > As you may see, it says that "/tmp/vmlinuz" doesn't exist but I can > confirm that it does by inserting an "os.listdir( '/tmp' )" into the > code. > > Any clues? > > TIA > > Dan > If SELinux is enabled, that's likely it. You can temporarily disable it if you like, though I'm working on fixing that now -- was going to hit that yesterday but I got sidetracked by some other cobbler features. If that's not it, let me know. --Michael _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools ************************************************************************ 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 ************************************************************************ From mdehaan at redhat.com Fri Jun 1 14:48:13 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 10:48:13 -0400 Subject: [et-mgmt-tools] koan --virt error In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C20@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C20@GBW607SC0054.GB-WS.net> Message-ID: <466031AD.4000603@redhat.com> Hennessey Daniel wrote: > Michael, > > Thanks for your prompt reply, you were spot on. I set the selinux policy > to "permissive" in "system-config-security" and now all proceeds as > expected. No reboot required. > > I can now install xen guests using koan. > Sure, this will be fixed and released shortly so you'll be able to leave SELinux on. I'll send an email to the list once that's done. I obviously don't want to imply everyone should run with SELinux off just to get koan to work :) > One problem I have now is that the install fails if I include the > "xconfig" in the kickstart file as the xen instance doesn't have a > graphical display. > > Does koan call virt-install to do the actual install? If it does then it > is just a matter of including the "--vnc" switch in the command line. > It's using virtinst, which is the library behind the virt-install app. > What do you suggest? > > I'll see about adding a graphics option to koan. As I was primarily targetting servers/datacenters, this was left out originally, but it's easy to add and ought to be there. > TIA and FYI I am really excited about the potential of using cobbler to > provision our real and virtual servers. I am also trying to work in > puppet for centralised configuration. This could be the answer to all my > (and my employers) prayers. > > Exciting times indeed thanks to you and all the other OSS workers out > there > You're welcome, thanks for the feedback. > Cheers > > Dan From Daniel.Hennessey at aah.co.uk Fri Jun 1 15:03:40 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Fri, 1 Jun 2007 16:03:40 +0100 Subject: [et-mgmt-tools] koan --virt error Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C21@GBW607SC0054.GB-WS.net> Michael, Maybe I should just tell you the symptoms and let you tell me what the problem is. >From virt-manager I can access the the two guests that I installed through virt-install with a nice terminal that works perfectly. These are both in run level 3 (no X). The ones that I created using koan I have to use the serial console option from virt-manager which is painful to use. The line that I have to comment out in the kickstart file for koan is: "xconfig --driver "fbdev" --resolution 800x600 --depth 24" So I assume that for the non-koan installed guests, we are using the frame buffer console (which is v nice). I know that I am not being unix hardcore by eschewing the serial option and it is only a cosmetic thing but if it could be sorted I would be a very happy hacker. Cheers 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: 01 June 2007 3:48 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] koan --virt error Hennessey Daniel wrote: > Michael, > > Thanks for your prompt reply, you were spot on. I set the selinux > policy to "permissive" in "system-config-security" and now all > proceeds as expected. No reboot required. > > I can now install xen guests using koan. > Sure, this will be fixed and released shortly so you'll be able to leave SELinux on. I'll send an email to the list once that's done. I obviously don't want to imply everyone should run with SELinux off just to get koan to work :) > One problem I have now is that the install fails if I include the > "xconfig" in the kickstart file as the xen instance doesn't have a > graphical display. > > Does koan call virt-install to do the actual install? If it does then > it is just a matter of including the "--vnc" switch in the command > line. > It's using virtinst, which is the library behind the virt-install app. > What do you suggest? > > I'll see about adding a graphics option to koan. As I was primarily targetting servers/datacenters, this was left out originally, but it's easy to add and ought to be there. > TIA and FYI I am really excited about the potential of using cobbler > to provision our real and virtual servers. I am also trying to work in > puppet for centralised configuration. This could be the answer to all > my (and my employers) prayers. > > Exciting times indeed thanks to you and all the other OSS workers out > there > You're welcome, thanks for the feedback. > Cheers > > Dan _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools ************************************************************************ 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 ************************************************************************ From mdehaan at redhat.com Fri Jun 1 15:10:27 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 11:10:27 -0400 Subject: [et-mgmt-tools] koan --virt error In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C21@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C21@GBW607SC0054.GB-WS.net> Message-ID: <466036E3.4080103@redhat.com> Hennessey Daniel wrote: > Michael, > > Maybe I should just tell you the symptoms and let you tell me what the > problem is. > > >From virt-manager I can access the the two guests that I installed > through virt-install with a nice terminal that works perfectly. These > are both in run level 3 (no X). The ones that I created using koan I > have to use the serial console option from virt-manager which is painful > to use. > > The line that I have to comment out in the kickstart file for koan is: > > "xconfig --driver "fbdev" --resolution 800x600 --depth 24" > > So I assume that for the non-koan installed guests, we are using the > frame buffer console (which is v nice). > > I know that I am not being unix hardcore by eschewing the serial option > and it is only a cosmetic thing but if it could be sorted I would be a > very happy hacker. > > Cheers > > Dan Basically virt-install allows creation of "graphics" settings for the virt guests, though koan isn't creating any at the moment, assuming you'll only be using xm console and SSH. I can get your VNC added to koan, not a problem... though it will require a small software change in koan (work pending) to do it. From Daniel.Hennessey at aah.co.uk Fri Jun 1 15:31:29 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Fri, 1 Jun 2007 16:31:29 +0100 Subject: [et-mgmt-tools] koan --virt error Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C22@GBW607SC0054.GB-WS.net> Michael, If I can be of any assistance with testing or anything, I would be happy to help. Cheers 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: 01 June 2007 4:10 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] koan --virt error Hennessey Daniel wrote: > Michael, > > Maybe I should just tell you the symptoms and let you tell me what the > problem is. > > >From virt-manager I can access the the two guests that I installed > through virt-install with a nice terminal that works perfectly. These > are both in run level 3 (no X). The ones that I created using koan I > have to use the serial console option from virt-manager which is > painful to use. > > The line that I have to comment out in the kickstart file for koan is: > > "xconfig --driver "fbdev" --resolution 800x600 --depth 24" > > So I assume that for the non-koan installed guests, we are using the > frame buffer console (which is v nice). > > I know that I am not being unix hardcore by eschewing the serial > option and it is only a cosmetic thing but if it could be sorted I > would be a very happy hacker. > > Cheers > > Dan Basically virt-install allows creation of "graphics" settings for the virt guests, though koan isn't creating any at the moment, assuming you'll only be using xm console and SSH. I can get your VNC added to koan, not a problem... though it will require a small software change in koan (work pending) to do it. _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools ************************************************************************ 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 ************************************************************************ From mdehaan at redhat.com Fri Jun 1 15:37:33 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 11:37:33 -0400 Subject: [et-mgmt-tools] koan --virt error In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C22@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C22@GBW607SC0054.GB-WS.net> Message-ID: <46603D3D.7000905@redhat.com> Hennessey Daniel wrote: > Michael, > > If I can be of any assistance with testing or anything, I would be happy > to help. > > Cheers > > Dan > Much appreciated. I'll let you know when the code for the above is available. From Daniel.Hennessey at aah.co.uk Fri Jun 1 15:45:37 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Fri, 1 Jun 2007 16:45:37 +0100 Subject: [et-mgmt-tools] koan --virt error Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C23@GBW607SC0054.GB-WS.net> Michael, Working round the problem with "guest.set_graphics('vnc')" in "/usr/lib/python2.4/site-packages/koan/virtcreate.py" for the moment. Looking forward to a more well thought out solution from you. Cheers 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: 01 June 2007 4:38 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] koan --virt error Hennessey Daniel wrote: > Michael, > > If I can be of any assistance with testing or anything, I would be > happy to help. > > Cheers > > Dan > Much appreciated. I'll let you know when the code for the above is available. _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools ************************************************************************ 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 ************************************************************************ From mdehaan at redhat.com Fri Jun 1 15:52:12 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 11:52:12 -0400 Subject: [et-mgmt-tools] koan --virt error In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C23@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C23@GBW607SC0054.GB-WS.net> Message-ID: <466040AC.1030804@redhat.com> Hennessey Daniel wrote: > Michael, > > Working round the problem with "guest.set_graphics('vnc')" in > "/usr/lib/python2.4/site-packages/koan/virtcreate.py" for the moment. > > Looking forward to a more well thought out solution from you. > > Cheers > > Dan > That's probably not going to be far from my solution :) Most likely what will happen is cobbler profiles will get a new setting --virt-graphics=enabled|disabled (default: disabled), so that info can be distributed with the profile versus having to be fed to koan each time. --Michael From Daniel.Hennessey at aah.co.uk Fri Jun 1 16:06:04 2007 From: Daniel.Hennessey at aah.co.uk (Hennessey Daniel) Date: Fri, 1 Jun 2007 17:06:04 +0100 Subject: [et-mgmt-tools] koan --virt error Message-ID: <03BB5BD4CF43594B9542DCCD4E7989900B046C24@GBW607SC0054.GB-WS.net> Is it not safe to assume that all xen installs will need this? In which case there's no need for any extra config switches, just check for the "--virt" switch. If users are using virt-manager to manage their xen instances then this is a big win in terms of usability and I don't think there's any overhead for those who don't. I could be wrong. Cheers 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: 01 June 2007 4:52 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] koan --virt error Hennessey Daniel wrote: > Michael, > > Working round the problem with "guest.set_graphics('vnc')" in > "/usr/lib/python2.4/site-packages/koan/virtcreate.py" for the moment. > > Looking forward to a more well thought out solution from you. > > Cheers > > Dan > That's probably not going to be far from my solution :) Most likely what will happen is cobbler profiles will get a new setting --virt-graphics=enabled|disabled (default: disabled), so that info can be distributed with the profile versus having to be fed to koan each time. --Michael _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools ************************************************************************ 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 ************************************************************************ From mdehaan at redhat.com Fri Jun 1 16:15:30 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 12:15:30 -0400 Subject: [et-mgmt-tools] koan --virt error In-Reply-To: <03BB5BD4CF43594B9542DCCD4E7989900B046C24@GBW607SC0054.GB-WS.net> References: <03BB5BD4CF43594B9542DCCD4E7989900B046C24@GBW607SC0054.GB-WS.net> Message-ID: <46604622.7090602@redhat.com> Hennessey Daniel wrote: > Is it not safe to assume that all xen installs will need this? In which > case there's no need for any extra config switches, just check for the > "--virt" switch. > > If users are using virt-manager to manage their xen instances then this > is a big win in terms of usability and I don't think there's any > overhead for those who don't. > For those running headless I don't want to make that mandatory. There's also the VNC security aspect for those that are concerned about it. From bill at bfccomputing.com Fri Jun 1 16:19:47 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Fri, 1 Jun 2007 12:19:47 -0400 Subject: [et-mgmt-tools] "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: <1DE4F19E-5B1B-4BB0-B5AE-CBE36D5A5180@bfccomputing.com> On May 30, 2007, at 14:13, Michael DeHaan wrote: > koan --virt --profile=foo --server=bootserver.example.com -- > virtname=what-to-call-it Cool, this worked for me. This project looks quite fun so far. :) So, now that I realized that: yum_core_mirror_from_server: 0 was the default setting (the man page makes it sound like '1' is the default, FWIW), and just because I can (I realize it's probably overkill) I'd like to now destroy that instance and re-make it. Should I expect to use cobbler to do that, or just the standard xen tools? I guess I'm hinting at the bigger question of 'management' vs. 'deploy and redeploy', which I realize may be beyond the defined scope. Thanks, -Bill ----- Bill McGonigle, Owner Work: 603.667.4000 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From mdehaan at redhat.com Fri Jun 1 16:34:21 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 12:34:21 -0400 Subject: [et-mgmt-tools] "Could not communicate with" error In-Reply-To: <1DE4F19E-5B1B-4BB0-B5AE-CBE36D5A5180@bfccomputing.com> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> <465DBEB3.8090500@redhat.com> <1DE4F19E-5B1B-4BB0-B5AE-CBE36D5A5180@bfccomputing.com> Message-ID: <46604A8D.2070108@redhat.com> Bill McGonigle wrote: > > > So, now that I realized that: > > yum_core_mirror_from_server: 0 > > was the default setting (the man page makes it sound like '1' is the > default, FWIW), and just because I can (I realize it's probably > overkill) I'd like to now destroy that instance and re-make it. I'll see what's up with the docs... > > Should I expect to use cobbler to do that, or just the standard xen > tools? I guess I'm hinting at the bigger question of 'management' vs. > 'deploy and redeploy', which I realize may be beyond the defined scope. Cobbler definitely isn't a config management system -- which is why we're building virt-factory (http://virt-factory.et.redhat.com) which will combine both cobbler, new mirroring tools ("surfr"), and config management systems (puppet). There's not a whole lot there yet (still very alpha-level), but it's ramping up quickly. We'll have more on that shortly. You could possibly put your yum configuration under control of a config management system, yes... Ok, back to cobbler ... The yum_core_mirror_from_server stuff is just intended to help set up /etc/yum.repos.d on the provisioned machine, so you can just modify the yum config on the provisioned box to point to the server mirrored repositories if you like ... though if you haven't done anything else with the system yet re-provisioning will only take a few minutes. The reason that setting is off by default now is a lot of users provision on a different network or install machines and move them to other places, where configuring them to use the boot server for yum installable packages no longer makes sense. > > Thanks, > -Bill > > ----- > Bill McGonigle, Owner Work: 603.667.4000 > BFC Computing, LLC Home: 603.448.1668 > bill at bfccomputing.com Cell: 603.252.2606 > http://www.bfccomputing.com/ Page: 603.442.1833 > Blog: http://blog.bfccomputing.com/ > VCard: http://bfccomputing.com/vcard/bill.vcf > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From bill at bfccomputing.com Fri Jun 1 20:33:48 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Fri, 1 Jun 2007 16:33:48 -0400 Subject: [et-mgmt-tools] "Could not communicate with" error In-Reply-To: <46604A8D.2070108@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> <1DE4F19E-5B1B-4BB0-B5AE-CBE36D5A5180@bfccomputing.com> <46604A8D.2070108@redhat.com> Message-ID: On Jun 1, 2007, at 12:34, Michael DeHaan wrote: > I'll see what's up with the docs... Sorry, I should have just included what I was talking about: "Note that if a cobbler import provides enough information to use the boot server as a yum mirror for core packages, cobbler will set up kickstarts to use the cobbler server as a mirror instead of the outside world. If this feature is undesirable, it can be turned off by setting yum_core_mirror_from_server to 0 in /var/lib/cobbler/settings (and rerunning ``cobbler sync''). You may want to disable this feature if machines are provisioned on a different VLAN/network than production." I'm also starting to understand the wisdom of setting up using MAC addresses, even under Xen. Are there 'best practices' for this? I just made up a prefix (BF:CC in my case, so we can remember that my company set it up) and for the remainder I used the IP address, in hex, human order. If there's a better way that might sync up later with virt-factory I'd be happy to change over. Thanks, -Bill ----- Bill McGonigle, Owner Work: 603.667.4000 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From mdehaan at redhat.com Fri Jun 1 21:49:53 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 17:49:53 -0400 Subject: [et-mgmt-tools] "Could not communicate with" error In-Reply-To: References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> <465DBEB3.8090500@redhat.com> <1DE4F19E-5B1B-4BB0-B5AE-CBE36D5A5180@bfccomputing.com> <46604A8D.2070108@redhat.com> Message-ID: <46609481.5040208@redhat.com> Bill McGonigle wrote: > On Jun 1, 2007, at 12:34, Michael DeHaan wrote: > > > I'm also starting to understand the wisdom of setting up using MAC > addresses, even under Xen. Are there 'best practices' for this? I just > made up a prefix (BF:CC in my case, so we can remember that my company > set it up) and for the remainder I used the IP address, in hex, human > order. If there's a better way that might sync up later with > virt-factory I'd be happy to change over. I'll try to not be too confusing here as there are a lot of different ways one could manage a lot of Xen machines running in a datacenter environment. Since you asked about virt-factory, currently virtfactory allocates Xen MAC addresses in the reserved space starting with 00:16:3E from 00:16:3E:00:00:00 upwards, one at a time, using the last three digits. This is a MAC address space reserved for Xen that will not clash with other NICs. So, if dealing with cobbler system objects, keeping track of the MACs might make sense. We will presumably have a way to register existing virtual machines to the collective, so that whatever you name them now won't cause a problem. Should you not want to manage MAC addresses, you can just provision by profile, and you'll get random MAC addresses from koan in the aforementioned range. However, this means you'll have to use DHCP (because you have no way to feed in static IP info with just the profile being specified) or you will not know the hostname until after you are done installing. For this reason, if you do this, you should at least assign a specific virtual system name: koan --virt --server=bootserver.example.com --profile=foo-xen-86_64 --virtname=testconfig7 So, in the above, you at least know that in "xm", "virsh", and "virt-manager", you can refer to the system as testconfig7. But yes, if you're in a DHCP environment, the hostname is TBD, and you can't do the "--profile" trick for static IP configurations. Does this mean making cobbler "system" objects for your virtual machines makes sense? Yes, it's a very good idea for a datacenter. If you just need a few virtual machines for developer use, it's not that critical. So, about MAC addresses ... In Cobbler 0.4.9 (already pushed to the upstream git repo, not yet released), you can name systems arbitrarily. It is still nice to specify a MAC address versus taking a random one, so that things like DHCP (and in turn, DNS) can be better controlled. You will be able to do things like: cobbler system add --name=fido --mac=00:16:3E:00:00:01 --ip=192.168.1.50 --hostname=fido.example.com In Cobbler 0.4.8, the best you can do is: cobbler system add --name=00:16:3E:00:00:01 --pxe-address=192.168.1.50, and doesn't offer the --hostname If using the dnsmasq features (cobbler defaults to 'isc', and even then 'manage_dhcp' must be enabled) in 0.49, that would ensure that the new Xen machine both recieved the designed IP and the desired hostname. This means you know a lot about the virtual machine even before you provision it. If you're using Cobbler to manage ISC, you can leave off the hostname, as it will be ignored. cobbler system add --name=fido --mac=00:16:3E:00:00:01 --ip=192.168.1.50 If you are using 0.4.8, syntax must be: cobbler system add --name=00:16:3E:00:00:01 --pxe-address=192.168.1.50, which is a bit confusing If you're not letting Cobbler manage your DNS (this is fine), it still makes sense to set the MAC in the Cobbler config, so that you can manually at least pick an IP for that MAC address. This way you'll be able to SSH into the machine later. Alternatively, you can do things like set up a static IP configuration, using the kickstart templating features. You would, in the kickstart file, set template variables such as $ip and $hostname, and do something like this... cobbler system add --name=fido --ksmeta="ip=192.168.1.50 hostname=fido.example.com" So, anywhere in your kickstart, you could have a variable "$ip" that would be substituted automatically with the IP. Since it's a good idea, I'm also going to make all of the variables used when constructing the system object automatically available to the kickstart templates. This way it will be easier to deal with cobbler with static IP configurations and will require less usage of the "--ksmeta" option to feed arbitrary variables into the kickstart. Hopefully I didn't get too offtrack, this probably warrants a new Wiki article "DHCP, Static IPs, & how to keep track of your machines". In conclusion, I'd say that keeping track of MAC addresses for virtual systems now is a very very good idea, as it will open up other options later even if you don't need them now. Either that, or go the static route, ignore the DHCP options, and investigate kickstart templating to feed in those additional parameters. Both options are equally good. > > Thanks, > -Bill > > ----- > Bill McGonigle, Owner Work: 603.667.4000 > BFC Computing, LLC Home: 603.448.1668 > bill at bfccomputing.com Cell: 603.252.2606 > http://www.bfccomputing.com/ Page: 603.442.1833 > Blog: http://blog.bfccomputing.com/ > VCard: http://bfccomputing.com/vcard/bill.vcf > > _______________________________________________ > 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 Fri Jun 1 23:02:12 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Jun 2007 19:02:12 -0400 Subject: [et-mgmt-tools] Koan 0.4.0 -- plays nice with SELinux Message-ID: <4660A574.2070704@redhat.com> Hi folks, koan 0.4.0 fixes a small SELinux problem (and only that), so it will now run happily with SELinux set to enforcing mode. A few people have reported this problem, and I hate to see the need to turn off SELinux just for this one small (and easily correctable) glitch. Regarding the release number bump, at the suggestion of a few others, I'm going to be adopting the "even=stable, odd=testing" convention for Cobbler and koan. Before, I've just been bumping things by 0.01 -- and things are getting much more stable now so it seems like a good time to do this. This probably makes Cobbler's next release 0.5.0. So ... koan 0.4.0 is out on et.redhat.com now. The RPMs are also pushed to FC-6 and F-7. If you're using SELinux + virtualization, these are for you .... Thanks! --Michael From fj0873gn at aa.jp.fujitsu.com Mon Jun 4 05:29:02 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Mon, 4 Jun 2007 14:29:02 +0900 Subject: [et-mgmt-tools] [PATCH] [RESEND] Fix continue to install Windows In-Reply-To: <46601C20.8000305@redhat.com> References: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> <46601C20.8000305@redhat.com> Message-ID: <200706041429.EJE48436.K04HO8G9@aa.jp.fujitsu.com> Hi, Hugh > > Would you give me a comment on this patch? > > If not, please apply it. > > > >> I can't continue to install Windows HVM domain after first restart. > >> After the restarting, /dev/cdrom (or ISO path) has not been attached to the domain. > >> The attached patch solves this problem. > >> > >> Signed-off-by: Nobuhiro Itou > > > > > > Thanks, > > Nobuhiro Itou. > > > Oops, sorry, I did apply it but forgot to post. Thanks! This patch seems not to have been committed in source repository yet. http://hg.et.redhat.com/virt/applications/virtinst--devel Could you commit this patch? Thanks, Nobuhiro Itou. From mark.bidewell at alumni.clemson.edu Mon Jun 4 16:53:58 2007 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Mon, 4 Jun 2007 12:53:58 -0400 Subject: [et-mgmt-tools] virt-manager questions Message-ID: I am experimenting with KVM and virt-manager on FC7 and I have a few questions: 1) Can virt-manager support audio devices? 2) Can I setup a bridged network with virt-manager ( it seem like only NAT was available). 3) Is qemu-kvm valid or is virt-manager the only way to use kvm? Thanks Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From hbrock at redhat.com Mon Jun 4 18:06:56 2007 From: hbrock at redhat.com (Hugh Brock) Date: Mon, 04 Jun 2007 14:06:56 -0400 Subject: [et-mgmt-tools] virt-manager questions In-Reply-To: References: Message-ID: <466454C0.7060902@redhat.com> Mark Bidewell wrote: > I am experimenting with KVM and virt-manager on FC7 and I have a few > questions: > > 1) Can virt-manager support audio devices? > 2) Can I setup a bridged network with virt-manager ( it seem like only > NAT was available). > 3) Is qemu-kvm valid or is virt-manager the only way to use kvm? > > > Thanks > Mark Bidewell > Hi! 1. Audio devices are on the radar but there's no support yet. For the moment you'll have to manually modify the guest config. 2. If you're using Xen, it will attempt to automatically set up a bridge attached to a physical NIC, but this isn't terribly reliable. If you manually set up a bridge on a machine, virt-manager will detect it and allow you to connect a guest to it. Virt-manager will not however set up a bridge for you... not really its line of work, per se. 3. Not sure I understand, can you be more specific? 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 mark.bidewell at alumni.clemson.edu Mon Jun 4 18:40:32 2007 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Mon, 4 Jun 2007 14:40:32 -0400 Subject: [et-mgmt-tools] virt-manager questions In-Reply-To: <466454C0.7060902@redhat.com> References: <466454C0.7060902@redhat.com> Message-ID: Thank you very much. What I meant by the question of qemu-kvm was that qemu allows you to specify sound parameters on the command-line. However when I attempted to use the virt-manager disk with qemu-kvm I got a kernel panic (CentOS5 guest). BTW where are the guest configs located? Mark Bidewell On 6/4/07, Hugh Brock wrote: > > Mark Bidewell wrote: > > I am experimenting with KVM and virt-manager on FC7 and I have a few > > questions: > > > > 1) Can virt-manager support audio devices? > > 2) Can I setup a bridged network with virt-manager ( it seem like only > > NAT was available). > > 3) Is qemu-kvm valid or is virt-manager the only way to use kvm? > > > > > > Thanks > > Mark Bidewell > > > > Hi! > > 1. Audio devices are on the radar but there's no support yet. For the > moment you'll have to manually modify the guest config. > > 2. If you're using Xen, it will attempt to automatically set up a bridge > attached to a physical NIC, but this isn't terribly reliable. If you > manually set up a bridge on a machine, virt-manager will detect it and > allow you to connect a guest to it. Virt-manager will not however set up > a bridge for you... not really its line of work, per se. > > 3. Not sure I understand, can you be more specific? > > 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 > > _______________________________________________ > 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 bill at bfccomputing.com Mon Jun 4 23:42:54 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Mon, 4 Jun 2007 19:42:54 -0400 Subject: [et-mgmt-tools] no network with koan --virt vm? Message-ID: Hi, list, I'm wondering if anyone has hit this snag before - I don't seem to be getting a network in my --virt machines as koan is deploying them. This is the script I'm running to deploy the VM (yeah, I've tried enough times I scripted it ;) ): cobbler sync cobbler profile add --name=souffle --distro=FC-6-xen-i386 --kick- start=/etc/cobbler/kickstart_souffle.ks --virt-file-size=20 --virt- ram=1024 cobbler system add --name=BF:CC:AC:10:00:65 --profile=souffle -- pxe-address=172.16.0.101 cobbler sync koan --virt --server=bread --system=BF:CC:AC:10:00:65 /usr/sbin/xm console BF_CC_AC_10_00_65 What I see is anaconda in interactive mode, trying to get a DHCP request. Cobbler makes this DHCP entry for me: host label1 { hardware ethernet BF:CC:AC:10:00:65; fixed-address 172.16.0.101; next-server bread; } I've also tried adding a static IP to the kickstart file: network --bootproto=static --ip=172.16.0.101 -- netmask=255.255.255.0 --gateway=172.16.0.1 --nameserver=172.16.0.204 but that didn't help. I also tried entering a static IP config into anaconda interactively - no dice. *Something* is getting some networking, because that is pulling down the kernel for boot from apache: 127.0.0.1 - - [04/Jun/2007:19:29:03 -0400] "GET /cobbler/ kickstarts_sys/01-bf-cc-ac-10-00-65/ks.cfg HTTP/1.1" 200 1845 "-" "Python-urllib/2.4" 127.0.0.1 - - [04/Jun/2007:19:29:03 -0400] "GET /cobbler/images/ FC-6-xen-i386/initrd.img HTTP/1.1" 200 5949162 "-" "Python-urllib/2.4" 127.0.0.1 - - [04/Jun/2007:19:29:03 -0400] "GET /cobbler/images/ FC-6-xen-i386/vmlinuz HTTP/1.1" 200 1728127 "-" "Python-urllib/2.4" but I assume that's xen running on the dom0 being successful (there are no hits subsequent to these). I'd really like to hear a, "hey stupid, you forgot to ____". :) Failing that, does anybody know how to suspend anaconda so I could see what, say, ifconfig has to say about the situation? Virtual Consoles work at the real console, but I'm not figuring it out in xm console. Thanks for any insight, -Bill ----- Bill McGonigle, Owner Work: 603.667.4000 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From thestrider at gmail.com Tue Jun 5 02:14:11 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Mon, 4 Jun 2007 22:14:11 -0400 Subject: [et-mgmt-tools] [PATCH] Cobbler: recommendation for pre/post synchronization trigger implementation Message-ID: <658267190706041914u7c6204cej6c0467e56eb8bb25@mail.gmail.com> I spoke with Michael somewhat on IRC regarding my desire to implement a DNS zone-related trigger mechanism. My main problem was that cobbler "core" (as opposed to "triggers") enforced a policy on trigger writers. When adding a new system (generically speaking, "cobbler system add --name= --profile=", where --name=hostname, and hostname != , cobbler prevents the system addition. This presented much difficulty in adding zone entries to systems that didn't yet exist in DNS (chicken and egg). If that were not enough trouble, if I would then remove the checking mechanism (as seen in action_sync.py:get_pxe_filename() method), the sync occurs regardless whether my own 'valid hostname' checks could be utilized. I asked Michael if there were a way to push such policy mechanisms (there really is only one -- the system.name check) to the trigger writers, so I might have a way to enforce my checks. Rather than to rewrite the control of the add method (whose utility outweighs its rarely-seen limitations), Michael recommended some options including the solution I'm offering. With the following minor patch and the addition of ../trigger/system/{add,remove}/{pre,post} directories, triggers that either make use of custom checks (which conflict with those in get_pxe_filename()) and/or need to be executed prior to syncs, can then be placed in the .../pre/... directories. Those triggers which may be executed without these requirements can be placed in the .../post/... directories. I am able to refer to "sys.argv[1]" within my trigger, and this will refer to the --name. Then, I can make use of --name within my pre_trigger and perform custom checks, dns zone instantiation, etc. before returning control to cobbler core, where the core name checks are then performed. Normal triggers would be called after sync as they currently are, but they are to be found in the .../post/... directory. There are other ways of implementing the mechanism. Perhaps only one trigger directory is needed with checked filename prefixes or suffixes for pre/post. I am only following the existing mechanism in adding the directories. If there are more elegant or efficient mechanisms, it will likely be part of a complete trigger system rehaul, as Michael has alluded to... If you would like to use this patch, you will have to rebuild with the following changes to the specfile and setup.py: --- cobbler.spec.orig 2007-04-26 22:03:04.000000000 +0000 +++ cobbler.spec 2007-06-04 23:35:23.000000000 +0000 @@ -105,14 +105,22 @@ %dir /var/log/cobbler/syslog %defattr(2550,root,root) %dir /var/lib/cobbler -%dir /var/lib/cobbler/triggers/add/distro -%dir /var/lib/cobbler/triggers/add/profile -%dir /var/lib/cobbler/triggers/add/system -%dir /var/lib/cobbler/triggers/add/repo -%dir /var/lib/cobbler/triggers/delete/distro -%dir /var/lib/cobbler/triggers/delete/profile -%dir /var/lib/cobbler/triggers/delete/system -%dir /var/lib/cobbler/triggers/delete/repo +%dir /var/lib/cobbler/triggers/add/distro/pre +%dir /var/lib/cobbler/triggers/add/distro/post +%dir /var/lib/cobbler/triggers/add/profile/pre +%dir /var/lib/cobbler/triggers/add/profile/post +%dir /var/lib/cobbler/triggers/add/system/pre +%dir /var/lib/cobbler/triggers/add/system/post +%dir /var/lib/cobbler/triggers/add/repo/pre +%dir /var/lib/cobbler/triggers/add/repo/post +%dir /var/lib/cobbler/triggers/delete/distro/pre +%dir /var/lib/cobbler/triggers/delete/distro/post +%dir /var/lib/cobbler/triggers/delete/profile/pre +%dir /var/lib/cobbler/triggers/delete/profile/post +%dir /var/lib/cobbler/triggers/delete/system/pre +%dir /var/lib/cobbler/triggers/delete/system/post +%dir /var/lib/cobbler/triggers/delete/repo/pre +%dir /var/lib/cobbler/triggers/delete/repo/post /var/lib/cobbler/elilo-3.6-ia64.efi /var/lib/cobbler/menu.c32 %defattr(-,root,root) --- setup.py.orig 2007-04-26 18:03:12.000000000 -0400 +++ setup.py 2007-06-04 22:05:22.000000000 -0400 @@ -78,14 +78,22 @@ (vw_links, []), (tftp_cfg, []), (tftp_images, []), - ("/var/lib/cobbler/triggers/add/distro", []), - ("/var/lib/cobbler/triggers/add/profile", []), - ("/var/lib/cobbler/triggers/add/system", []), - ("/var/lib/cobbler/triggers/add/repo", []), - ("/var/lib/cobbler/triggers/delete/distro", []), - ("/var/lib/cobbler/triggers/delete/profile", []), - ("/var/lib/cobbler/triggers/delete/system", []), - ("/var/lib/cobbler/triggers/delete/repo", []) + ("/var/lib/cobbler/triggers/add/distro/pre", []), + ("/var/lib/cobbler/triggers/add/distro/post", []), + ("/var/lib/cobbler/triggers/add/profile/pre", []), + ("/var/lib/cobbler/triggers/add/profile/post", []), + ("/var/lib/cobbler/triggers/add/system/pre", []), + ("/var/lib/cobbler/triggers/add/system/post", []), + ("/var/lib/cobbler/triggers/add/repo/pre", []), + ("/var/lib/cobbler/triggers/add/repo/post", []), + ("/var/lib/cobbler/triggers/delete/distro/pre", []), + ("/var/lib/cobbler/triggers/delete/distro/post", []), + ("/var/lib/cobbler/triggers/delete/profile/pre", []), + ("/var/lib/cobbler/triggers/delete/profile/post", []), + ("/var/lib/cobbler/triggers/delete/system/pre", []), + ("/var/lib/cobbler/triggers/delete/system/post", []), + ("/var/lib/cobbler/triggers/delete/repo/pre", []) + ("/var/lib/cobbler/triggers/delete/repo/post", []) ], description = SHORT_DESC, long_description = LONG_DESC The actual core patches are listed below --- cobbler/collection_distros.py.orig 2007-04-16 15:57:29.000000000 -0400 +++ cobbler/collection_distros.py 2007-06-04 21:38:33.000000000 -0400 @@ -51,9 +51,10 @@ raise cexceptions.CobblerException("orphan_profile",v.name) if self.find(name): if with_delete: + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/distro/pre/*") lite_sync = action_litesync.BootLiteSync(self.config) lite_sync.remove_single_profile(name) - self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/distro/*") + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/distro/post/*") del self.listing[name] return True raise cexceptions.CobblerException("delete_nothing") --- cobbler/collection_profiles.py.orig 2007-04-16 15:07:37.000000000 -0400 +++ cobbler/collection_profiles.py 2007-06-04 21:39:01.000000000 -0400 @@ -48,9 +48,10 @@ raise cexceptions.CobblerException("orphan_system",v.name) if self.find(name): if with_delete: + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/profile/pre/*") lite_sync = action_litesync.BootLiteSync(self.config) lite_sync.remove_single_profile(name) - self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/profile/*") + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/profile/post/*") del self.listing[name] return True raise cexceptions.CobblerException("delete_nothing") --- cobbler/collection_systems.py.orig 2007-04-16 15:07:47.000000000 -0400 +++ cobbler/collection_systems.py 2007-06-04 21:41:11.000000000 -0400 @@ -49,9 +49,10 @@ """ if self.find(name): if with_delete: + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/system/pre/*") lite_sync = action_litesync.BootLiteSync(self.config) lite_sync.remove_single_system(name) - self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/system/*") + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/system/post/*") del self.listing[name] return True raise cexceptions.CobblerException("delete_nothing") --- cobbler/collection_repos.py.orig 2007-04-20 18:54:24.000000000 -0400 +++ cobbler/collection_repos.py 2007-06-04 21:40:25.000000000 -0400 @@ -52,8 +52,9 @@ # but is left in for consistancy in the API. if self.find(name): - self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/repo/*") + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/repo/pre/*") del self.listing[name] + self._run_triggers(self.listing[name], "/var/lib/cobbler/triggers/delete/repo/post/*") return True raise cexceptions.CobblerException("delete_nothing") --- cobbler/collection.py.orig 2007-04-20 16:14:52.000000000 -0400 +++ cobbler/collection.py 2007-06-04 21:35:46.000000000 -0400 @@ -91,6 +91,7 @@ # perform filesystem operations if with_copy: + self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/pre/*" % self.collection_type()) lite_sync = action_litesync.BootLiteSync(self.config) if isinstance(ref, item_system.System): lite_sync.add_single_system(ref.name) @@ -103,8 +104,8 @@ # save the tree, so if neccessary, scripts can examine it. self.config.api.serialize() - - self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/*" % self.collection_type()) + + self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/post/*" % self.collection_type()) return True --Adam. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcmo at foxriver.com Tue Jun 5 12:38:30 2007 From: marcmo at foxriver.com (Marc Mondragon) Date: Tue, 5 Jun 2007 07:38:30 -0500 Subject: [et-mgmt-tools] Has any one managed to get cobbler and rhn to play nice? Message-ID: A month or so ago I tried to get this working (w/ Michael's help btw) for my RHEL 5 subscriptions but I was unable to. Has anyone managed to get this to work in the interim? Thanks, Marc Mondragon Fox River Financial Resources/Ritchie Capital Investments, Ltd. 2100 Enterprise Avenue Geneva, IL 60134 marcmo at foxriver.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Jun 5 15:16:22 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 05 Jun 2007 11:16:22 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobbler and rhn to play nice? In-Reply-To: References: Message-ID: <46657E46.80800@redhat.com> Marc Mondragon wrote: > > A month or so ago I tried to get this working (w/ Michael?s help btw) > for my RHEL 5 subscriptions but I was unable to. Has anyone managed to > get this to work in the interim? > > Thanks, > > Marc Mondragon > > Fox River Financial Resources/Ritchie Capital Investments, Ltd. > 2100 Enterprise Avenue > Geneva, IL 60134 > marcmo at foxriver.com > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I didn't see it in his attachment, but Marc's referring to ... cobbler repo add --name=foo --mirror=rhn://name-of-rhel5-channel cobbler reposync Which worked for me on several different machines, but not for Marc. Other reports welcome... From mdehaan at redhat.com Tue Jun 5 15:23:34 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 05 Jun 2007 11:23:34 -0400 Subject: [et-mgmt-tools] [PATCH] Cobbler: recommendation for pre/post synchronization trigger implementation In-Reply-To: <658267190706041914u7c6204cej6c0467e56eb8bb25@mail.gmail.com> References: <658267190706041914u7c6204cej6c0467e56eb8bb25@mail.gmail.com> Message-ID: <46657FF6.5060708@redhat.com> Adam Rosenwald wrote: I'll check this patch out shortly... It looks pretty good to me. Thanks! > I spoke with Michael somewhat on IRC regarding my desire to implement > a DNS zone-related trigger mechanism. My main problem was that cobbler > "core" (as opposed to "triggers") enforced a policy on trigger > writers. When adding a new system (generically speaking, "cobbler > system add --name= --profile=", > where --name=hostname, and hostname != , cobbler > prevents the system addition. FYI -- This is already removed in upstream. (Cobbler system add --name=foo --mac=AA:BB:CC:DD:EE:FF) is now legal, and things work appropriately. If you leave off the --mac and the --ip, the system can't PXE, but it can still live in the config. Implict adds such as "cobbler system add --name=AA:BB:CC:DD:EE:FF" will automatically set the mac address, as before. > > This presented much difficulty in adding zone entries to systems that > didn't yet exist in DNS (chicken and egg). If that were not enough > trouble, if I would then remove the checking mechanism (as seen in > action_sync.py:get_pxe_filename() method), the sync occurs regardless > whether my own 'valid hostname' checks could be utilized. > > I asked Michael if there were a way to push such policy mechanisms > (there really is only one -- the system.name > check) to the trigger writers, so I might have a way to enforce my > checks. Rather than to rewrite the control of the add method (whose > utility outweighs its rarely-seen limitations), Michael recommended > some options including the solution I'm offering. > > With the following minor patch and the addition of > ../trigger/system/{add,remove}/{pre,post} directories, triggers that > either make use of custom checks (which conflict with those in > get_pxe_filename()) and/or need to be executed prior to syncs, can > then be placed in the .../pre/... directories. Those triggers which > may be executed without these requirements can be placed in the > .../post/... directories. > > I am able to refer to "sys.argv[1]" within my trigger, and this will > refer to the --name. Then, I can make use of --name within my > pre_trigger and perform custom checks, dns zone instantiation, etc. > before returning control to cobbler core, where the core name checks > are then performed. Normal triggers would be called after sync as they > currently are, but they are to be found in the .../post/... directory. Yup... > > There are other ways of implementing the mechanism. Perhaps only one > trigger directory is needed with checked filename prefixes or suffixes > for pre/post. I am only following the existing mechanism in adding the > directories. If there are more elegant or efficient mechanisms, it > will likely be part of a complete trigger system rehaul, as Michael > has alluded to... The main thing I want to see is pre-triggers filtering checking return codes, so as to reject additions to the config if any of the pre-triggers fail. This is pretty simple. Post-return codes also need to be paid attention to, which is something the current cobbler system doesn't do either :) ... > > If you would like to use this patch, you will have to rebuild with the > following changes to the specfile and setup.py: > > --- cobbler.spec.orig 2007-04-26 22:03:04.000000000 +0000 > +++ cobbler.spec 2007-06-04 23:35:23.000000000 +0000 > @@ -105,14 +105,22 @@ > %dir /var/log/cobbler/syslog > %defattr(2550,root,root) > %dir /var/lib/cobbler > -%dir /var/lib/cobbler/triggers/add/distro > -%dir /var/lib/cobbler/triggers/add/profile > -%dir /var/lib/cobbler/triggers/add/system > -%dir /var/lib/cobbler/triggers/add/repo > -%dir /var/lib/cobbler/triggers/delete/distro > -%dir /var/lib/cobbler/triggers/delete/profile > -%dir /var/lib/cobbler/triggers/delete/system > -%dir /var/lib/cobbler/triggers/delete/repo > +%dir /var/lib/cobbler/triggers/add/distro/pre > +%dir /var/lib/cobbler/triggers/add/distro/post > +%dir /var/lib/cobbler/triggers/add/profile/pre > +%dir /var/lib/cobbler/triggers/add/profile/post > +%dir /var/lib/cobbler/triggers/add/system/pre > +%dir /var/lib/cobbler/triggers/add/system/post > +%dir /var/lib/cobbler/triggers/add/repo/pre > +%dir /var/lib/cobbler/triggers/add/repo/post > +%dir /var/lib/cobbler/triggers/delete/distro/pre > +%dir /var/lib/cobbler/triggers/delete/distro/post > +%dir /var/lib/cobbler/triggers/delete/profile/pre > +%dir /var/lib/cobbler/triggers/delete/profile/post > +%dir /var/lib/cobbler/triggers/delete/system/pre > +%dir /var/lib/cobbler/triggers/delete/system/post > +%dir /var/lib/cobbler/triggers/delete/repo/pre > +%dir /var/lib/cobbler/triggers/delete/repo/post > /var/lib/cobbler/elilo-3.6-ia64.efi > /var/lib/cobbler/menu.c32 > %defattr(-,root,root) > > --- setup.py.orig 2007-04-26 18:03:12.000000000 -0400 > +++ setup.py 2007-06-04 22:05:22.000000000 -0400 > @@ -78,14 +78,22 @@ > (vw_links, []), > (tftp_cfg, []), > (tftp_images, []), > - ("/var/lib/cobbler/triggers/add/distro", []), > - ("/var/lib/cobbler/triggers/add/profile", []), > - ("/var/lib/cobbler/triggers/add/system", []), > - ("/var/lib/cobbler/triggers/add/repo", []), > - ("/var/lib/cobbler/triggers/delete/distro", []), > - ("/var/lib/cobbler/triggers/delete/profile", []), > - ("/var/lib/cobbler/triggers/delete/system", []), > - ("/var/lib/cobbler/triggers/delete/repo", []) > + ("/var/lib/cobbler/triggers/add/distro/pre", []), > + ("/var/lib/cobbler/triggers/add/distro/post", []), > + ("/var/lib/cobbler/triggers/add/profile/pre", []), > + ("/var/lib/cobbler/triggers/add/profile/post", []), > + ("/var/lib/cobbler/triggers/add/system/pre", []), > + ("/var/lib/cobbler/triggers/add/system/post", []), > + ("/var/lib/cobbler/triggers/add/repo/pre", []), > + ("/var/lib/cobbler/triggers/add/repo/post", []), > + ("/var/lib/cobbler/triggers/delete/distro/pre", []), > + ("/var/lib/cobbler/triggers/delete/distro/post", []), > + ("/var/lib/cobbler/triggers/delete/profile/pre", []), > + ("/var/lib/cobbler/triggers/delete/profile/post", []), > + ("/var/lib/cobbler/triggers/delete/system/pre", []), > + ("/var/lib/cobbler/triggers/delete/system/post", []), > + ("/var/lib/cobbler/triggers/delete/repo/pre", []) > + ("/var/lib/cobbler/triggers/delete/repo/post", []) > ], > description = SHORT_DESC, > long_description = LONG_DESC > > > The actual core patches are listed below > > --- cobbler/collection_distros.py.orig 2007-04-16 15:57:29.000000000 -0400 > +++ cobbler/collection_distros.py 2007-06-04 21:38:33.000000000 -0400 > @@ -51,9 +51,10 @@ > raise cexceptions.CobblerException("orphan_profile",v.name > ) > if self.find(name): > if with_delete: > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/distro/pre/*") > lite_sync = action_litesync.BootLiteSync(self.config) > lite_sync.remove_single_profile(name) > - self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/distro/*") > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/distro/post/*") > del self.listing[name] > return True > raise cexceptions.CobblerException("delete_nothing") > --- cobbler/collection_profiles.py.orig 2007-04-16 15:07:37.000000000 > -0400 > +++ cobbler/collection_profiles.py 2007-06-04 21:39:01.000000000 -0400 > @@ -48,9 +48,10 @@ > raise cexceptions.CobblerException("orphan_system",v.name ) > if self.find(name): > if with_delete: > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/profile/pre/*") > lite_sync = action_litesync.BootLiteSync(self.config) > lite_sync.remove_single_profile(name) > - self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/profile/*") > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/profile/post/*") > del self.listing[name] > return True > raise cexceptions.CobblerException("delete_nothing") > --- cobbler/collection_systems.py.orig 2007-04-16 15:07:47.000000000 -0400 > +++ cobbler/collection_systems.py 2007-06-04 21:41:11.000000000 -0400 > @@ -49,9 +49,10 @@ > """ > if self.find(name): > if with_delete: > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/system/pre/*") > lite_sync = action_litesync.BootLiteSync(self.config) > lite_sync.remove_single_system(name) > - self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/system/*") > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/system/post/*") > del self.listing[name] > return True > raise cexceptions.CobblerException("delete_nothing") > --- cobbler/collection_repos.py.orig 2007-04-20 18:54:24.000000000 -0400 > +++ cobbler/collection_repos.py 2007-06-04 21:40:25.000000000 -0400 > @@ -52,8 +52,9 @@ > # but is left in for consistancy in the API. > > if self.find(name): > - self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/repo/*") > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/repo/pre/*") > del self.listing[name] > + self._run_triggers(self.listing[name], > "/var/lib/cobbler/triggers/delete/repo/post/*") > return True > raise cexceptions.CobblerException("delete_nothing") > > --- cobbler/collection.py.orig 2007-04-20 16:14:52.000000000 -0400 > +++ cobbler/collection.py 2007-06-04 21:35:46.000000000 -0400 > @@ -91,6 +91,7 @@ > > # perform filesystem operations > if with_copy: > + self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/pre/*" % > self.collection_type()) > lite_sync = action_litesync.BootLiteSync(self.config) > if isinstance(ref, item_system.System): > lite_sync.add_single_system(ref.name ) > @@ -103,8 +104,8 @@ > > # save the tree, so if neccessary, scripts can examine it. > self.config.api.serialize() > - > - self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/*" % > self.collection_type()) > + > + self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/post/*" % > self.collection_type()) > > return True > > > --Adam. > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jun 5 15:29:25 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 05 Jun 2007 11:29:25 -0400 Subject: [et-mgmt-tools] no network with koan --virt vm? In-Reply-To: References: Message-ID: <46658155.2000208@redhat.com> Bill McGonigle wrote: > Hi, list, > > I'm wondering if anyone has hit this snag before - I don't seem to be > getting a network in my --virt machines as koan is deploying them. > > This is the script I'm running to deploy the VM (yeah, I've tried > enough times I scripted it ;) ): > > cobbler sync > cobbler profile add --name=souffle --distro=FC-6-xen-i386 > --kick-start=/etc/cobbler/kickstart_souffle.ks --virt-file-size=20 > --virt-ram=1024 > cobbler system add --name=BF:CC:AC:10:00:65 --profile=souffle > --pxe-address=172.16.0.101 > cobbler sync > koan --virt --server=bread --system=BF:CC:AC:10:00:65 > /usr/sbin/xm console BF_CC_AC_10_00_65 > > What I see is anaconda in interactive mode, trying to get a DHCP > request. Cobbler makes this DHCP entry for me: > > host label1 { > hardware ethernet BF:CC:AC:10:00:65; > fixed-address 172.16.0.101; > next-server bread; > } > > I've also tried adding a static IP to the kickstart file: > network --bootproto=static --ip=172.16.0.101 --netmask=255.255.255.0 > --gateway=172.16.0.1 --nameserver=172.16.0.204 > > but that didn't help. I also tried entering a static IP config into > anaconda interactively - no dice. > > *Something* is getting some networking, because that is pulling down > the kernel for boot from apache: > > 127.0.0.1 - - [04/Jun/2007:19:29:03 -0400] "GET > /cobbler/kickstarts_sys/01-bf-cc-ac-10-00-65/ks.cfg HTTP/1.1" 200 1845 > "-" "Python-urllib/2.4" > 127.0.0.1 - - [04/Jun/2007:19:29:03 -0400] "GET > /cobbler/images/FC-6-xen-i386/initrd.img HTTP/1.1" 200 5949162 "-" > "Python-urllib/2.4" > 127.0.0.1 - - [04/Jun/2007:19:29:03 -0400] "GET > /cobbler/images/FC-6-xen-i386/vmlinuz HTTP/1.1" 200 1728127 "-" > "Python-urllib/2.4" > > but I assume that's xen running on the dom0 being successful (there > are no hits subsequent to these). > > I'd really like to hear a, "hey stupid, you forgot to ____". :) > Failing that, does anybody know how to suspend anaconda so I could see > what, say, ifconfig has to say about the situation? Virtual Consoles > work at the real console, but I'm not figuring it out in xm console. > > Thanks for any insight, > -Bill I could use some more information on this one... What does your full /etc/dhcp.conf as generated by cobbler look like? How about /var/lib/cobbler/settings? Thanks, Michael From Greg.Caetano at hp.com Tue Jun 5 15:53:00 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Tue, 5 Jun 2007 11:53:00 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobbler and rhn toplay nice? In-Reply-To: <46657E46.80800@redhat.com> References: <46657E46.80800@redhat.com> Message-ID: I haven't had any luck.... How do you tell reposync the RHN user/password to check for entitlements? # cobbler repo add --name=rh5basex86 --mirror=rhn://rhel-i386-server-5 # cobbler report repo : rh5basex86 mirror : rhn://rhel-i386-server-5 keep updated : 1 local filename : rpm list : # cobbler reposync - /usr/bin/reposync -r rhel-i386-server-5 --download_path=/var/www/cobbler/repo_mirror - symlink: /var/www/cobbler/repo_mirror/rhel-i386-server-5 -> /var/www/cobbler/repo_mirror/rh5basex86 No Repositories Available to Set Up - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 636, in main BootCLI(sys.argv).run() File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 110, in run self.curry_args(self.args[1:], self.commands['toplevel']) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 465, in curry_args commands[args[0]](args[1:]) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 495, in reposync self.api.reposync() File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in reposync return reposync.run() File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 65, in run self.do_reposync(repo) File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 176, in do_reposync temp_file = self.create_local_file(repo, temp_path, output=False) File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 231, in create_local_file config_file = open(fname, "w+") IOError: [Errno 2] No such file or directory: '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' # # rpm -qa | grep -i cobbler cobbler-0.4.8-1 Greg Caetano HP TSG Linux Solutions Alliances Engineering Chicago, IL 773-281-8129 greg.caetano at hp.com Red Hat Certified Engineer RHCE#803004972711193 -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Tuesday, June 05, 2007 10:16 AM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Has any one managed to get cobbler and rhn toplay nice? Marc Mondragon wrote: > > A month or so ago I tried to get this working (w/ Michael's help btw) > for my RHEL 5 subscriptions but I was unable to. Has anyone managed to > get this to work in the interim? > > Thanks, > > Marc Mondragon > > Fox River Financial Resources/Ritchie Capital Investments, Ltd. > 2100 Enterprise Avenue > Geneva, IL 60134 > marcmo at foxriver.com > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I didn't see it in his attachment, but Marc's referring to ... cobbler repo add --name=foo --mirror=rhn://name-of-rhel5-channel cobbler reposync Which worked for me on several different machines, but not for Marc. Other reports welcome... _______________________________________________ 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 Jun 5 16:22:19 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 05 Jun 2007 12:22:19 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobbler and rhn toplay nice? In-Reply-To: References: <46657E46.80800@redhat.com> Message-ID: <46658DBB.8050301@redhat.com> Caetano, Greg wrote: > I haven't had any luck.... How do you tell reposync the RHN > user/password to check for entitlements? > The server in question has to be entitled for the given channel. The cobbler server must also be RHEL5 (so it can use yum_rhn_plugin). You'll see the core of this is essentially just /usr/bin/reposync -r rhel-i386-server-5 --download_path=/tmp/foo So that may prove easier for testing. Perhaps the server isn't entitled for that channel? Better tools need to exist -- no doubt -- surfr should be providing a more comprehensive solution soon -- shortly after we get virt-factory 0.0.3 out of the way. > # cobbler repo add --name=rh5basex86 --mirror=rhn://rhel-i386-server-5 > # cobbler report > repo : rh5basex86 > mirror : rhn://rhel-i386-server-5 > keep updated : 1 > local filename : > rpm list : > # cobbler reposync > - /usr/bin/reposync -r rhel-i386-server-5 > --download_path=/var/www/cobbler/repo_mirror > - symlink: /var/www/cobbler/repo_mirror/rhel-i386-server-5 -> > /var/www/cobbler/repo_mirror/rh5basex86 > No Repositories Available to Set Up > - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 636, > in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 110, > in run > self.curry_args(self.args[1:], self.commands['toplevel']) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 465, > in curry_args > commands[args[0]](args[1:]) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 495, > in reposync > self.api.reposync() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in > reposync > return reposync.run() > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 65, in run > self.do_reposync(repo) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 176, in do_reposync > temp_file = self.create_local_file(repo, temp_path, output=False) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 231, in create_local_file > config_file = open(fname, "w+") > IOError: [Errno 2] No such file or directory: > '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' > # > # rpm -qa | grep -i cobbler > cobbler-0.4.8-1 > > Greg Caetano > HP TSG Linux Solutions Alliances Engineering > Chicago, IL > 773-281-8129 > greg.caetano at hp.com > Red Hat Certified Engineer > RHCE#803004972711193 > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com > [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Tuesday, June 05, 2007 10:16 AM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Has any one managed to get cobbler and rhn > toplay nice? > > Marc Mondragon wrote: > >> A month or so ago I tried to get this working (w/ Michael's help btw) >> for my RHEL 5 subscriptions but I was unable to. Has anyone managed to >> > > >> get this to work in the interim? >> >> Thanks, >> >> Marc Mondragon >> >> Fox River Financial Resources/Ritchie Capital Investments, Ltd. >> 2100 Enterprise Avenue >> Geneva, IL 60134 >> marcmo at foxriver.com >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > > I didn't see it in his attachment, but Marc's referring to ... > > cobbler repo add --name=foo --mirror=rhn://name-of-rhel5-channel > cobbler reposync > > Which worked for me on several different machines, but not for Marc. > Other reports welcome... > > _______________________________________________ > 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 Greg.Caetano at hp.com Tue Jun 5 16:31:43 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Tue, 5 Jun 2007 12:31:43 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobbler and rhn toplaynice? In-Reply-To: <46658DBB.8050301@redhat.com> References: <46657E46.80800@redhat.com> <46658DBB.8050301@redhat.com> Message-ID: Michael Here is some additional testing on the same server # yum update Loading "installonlyn" plugin Loading "rhnplugin" plugin Setting up Update Process Setting up repositories rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 Reading repository metadata in from local files No Packages marked for Update/Obsoletion # /usr/bin/reposync -r rhel-i386-server-5 --download_path=/var/www/cobbler/repo_mirror/rh5basex86 Error: Cannot create destination dir /var/www/cobbler/repo_mirror/rh5basex86 # /usr/bin/reposync -r rhel-i386-server-5 --download_path=/tmp/rh5basex86 No Repositories Available to Set Up # Greg Caetano HP TSG Linux Solutions Alliances Engineering Chicago, IL 773-281-8129 greg.caetano at hp.com Red Hat Certified Engineer RHCE#803004972711193 -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Tuesday, June 05, 2007 11:22 AM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Has any one managed to get cobbler and rhn toplaynice? Caetano, Greg wrote: > I haven't had any luck.... How do you tell reposync the RHN > user/password to check for entitlements? > The server in question has to be entitled for the given channel. The cobbler server must also be RHEL5 (so it can use yum_rhn_plugin). You'll see the core of this is essentially just /usr/bin/reposync -r rhel-i386-server-5 --download_path=/tmp/foo So that may prove easier for testing. Perhaps the server isn't entitled for that channel? Better tools need to exist -- no doubt -- surfr should be providing a more comprehensive solution soon -- shortly after we get virt-factory 0.0.3 out of the way. > # cobbler repo add --name=rh5basex86 --mirror=rhn://rhel-i386-server-5 > # cobbler report > repo : rh5basex86 > mirror : rhn://rhel-i386-server-5 > keep updated : 1 > local filename : > rpm list : > # cobbler reposync > - /usr/bin/reposync -r rhel-i386-server-5 > --download_path=/var/www/cobbler/repo_mirror > - symlink: /var/www/cobbler/repo_mirror/rhel-i386-server-5 -> > /var/www/cobbler/repo_mirror/rh5basex86 > No Repositories Available to Set Up > - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 636, in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 110, in run > self.curry_args(self.args[1:], self.commands['toplevel']) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 465, in curry_args > commands[args[0]](args[1:]) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 495, in reposync > self.api.reposync() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in > reposync > return reposync.run() > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 65, in run > self.do_reposync(repo) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 176, in do_reposync > temp_file = self.create_local_file(repo, temp_path, output=False) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 231, in create_local_file > config_file = open(fname, "w+") > IOError: [Errno 2] No such file or directory: > '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' > # > # rpm -qa | grep -i cobbler > cobbler-0.4.8-1 > > Greg Caetano > HP TSG Linux Solutions Alliances Engineering Chicago, IL > 773-281-8129 > greg.caetano at hp.com > Red Hat Certified Engineer > RHCE#803004972711193 > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com > [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Tuesday, June 05, 2007 10:16 AM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Has any one managed to get cobbler and > rhn toplay nice? > > Marc Mondragon wrote: > >> A month or so ago I tried to get this working (w/ Michael's help btw) >> for my RHEL 5 subscriptions but I was unable to. Has anyone managed >> to >> > > >> get this to work in the interim? >> >> Thanks, >> >> Marc Mondragon >> >> Fox River Financial Resources/Ritchie Capital Investments, Ltd. >> 2100 Enterprise Avenue >> Geneva, IL 60134 >> marcmo at foxriver.com >> >> --------------------------------------------------------------------- >> - >> -- >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > > I didn't see it in his attachment, but Marc's referring to ... > > cobbler repo add --name=foo --mirror=rhn://name-of-rhel5-channel > cobbler reposync > > Which worked for me on several different machines, but not for Marc. > Other reports welcome... > > _______________________________________________ > 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 bill at bfccomputing.com Tue Jun 5 16:46:11 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Tue, 5 Jun 2007 12:46:11 -0400 Subject: [et-mgmt-tools] no network with koan --virt vm? In-Reply-To: <46658155.2000208@redhat.com> References: <46658155.2000208@redhat.com> Message-ID: On Jun 5, 2007, at 11:29, Michael DeHaan wrote: > What does your full /etc/dhcp.conf as generated by cobbler look > like? How about /var/lib/cobbler/settings? dhcpd.conf looks reasonable, at least to me: ------ ddns-update-style interim; allow booting; allow bootp; ignore client-updates; set vendorclass = option vendor-class-identifier; subnet 172.16.0.0 netmask 255.255.255.0 { option routers 172.16.0.1; option subnet-mask 255.255.255.0; # range dynamic-bootp 172.16.0.101 172.16.0.110; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server bread; } host label1 { hardware ethernet BF:CC:AC:10:00:65; fixed-address 172.16.0.101; next-server bread; } ------ The two changes I've made to cobbler/settings are manage_dhcp and yum_core_mirror_from_server. ------ bootloaders: ia64: /var/lib/cobbler/elilo-3.6-ia64.efi standard: /usr/lib/syslinux/pxelinux.0 default_kickstart: /etc/cobbler/default.ks dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf httpd_bin: /usr/sbin/httpd kernel_options: ksdevice: eth0 lang: ' ' text: ~ koan_path: '' manage_dhcp: 1 minimize_syncs: 1 next_server: bread server: bread syslog_port: 25150 tftpboot: /tftpboot tftpd_bin: /usr/sbin/in.tftpd tftpd_conf: /etc/xinetd.d/tftp webdir: /var/www/cobbler xmlrpc_port: 25151 yum_core_mirror_from_server: 1 ----- Is there something I'm supposed to be doing to the stock xen configuration to enable networking for cobbler? I ask because even specifying an IP manually to anaconda didn't get me anywhere. I also don't see something that looks like a network device in the kernel messages of the domU, though I admit to not knowing what to look for, or if it ought to be there under Xen. Thanks, -Bill ----- Bill McGonigle, Owner Work: 603.667.4000 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From mdehaan at redhat.com Tue Jun 5 16:59:09 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 05 Jun 2007 12:59:09 -0400 Subject: [et-mgmt-tools] no network with koan --virt vm? In-Reply-To: References: <46658155.2000208@redhat.com> Message-ID: <4665965D.1080300@redhat.com> Bill McGonigle wrote: > On Jun 5, 2007, at 11:29, Michael DeHaan wrote: > >> What does your full /etc/dhcp.conf as generated by cobbler look like? >> How about /var/lib/cobbler/settings? > > dhcpd.conf looks reasonable, at least to me: > > ------ > ddns-update-style interim; > > allow booting; > allow bootp; > > ignore client-updates; > set vendorclass = option vendor-class-identifier; > > subnet 172.16.0.0 netmask 255.255.255.0 { > option routers 172.16.0.1; > option subnet-mask 255.255.255.0; > # range dynamic-bootp 172.16.0.101 172.16.0.110; > filename "/pxelinux.0"; > default-lease-time 21600; > max-lease-time 43200; > next-server bread; > } > > > host label1 { > hardware ethernet BF:CC:AC:10:00:65; > fixed-address 172.16.0.101; > next-server bread; > } > ------ > > The two changes I've made to cobbler/settings are manage_dhcp and > yum_core_mirror_from_server. > > ------ > bootloaders: > ia64: /var/lib/cobbler/elilo-3.6-ia64.efi > standard: /usr/lib/syslinux/pxelinux.0 > default_kickstart: /etc/cobbler/default.ks > dhcpd_bin: /usr/sbin/dhcpd > dhcpd_conf: /etc/dhcpd.conf > httpd_bin: /usr/sbin/httpd > kernel_options: > ksdevice: eth0 > lang: ' ' > text: ~ > koan_path: '' > manage_dhcp: 1 > minimize_syncs: 1 > next_server: bread > server: bread > syslog_port: 25150 > tftpboot: /tftpboot > tftpd_bin: /usr/sbin/in.tftpd > tftpd_conf: /etc/xinetd.d/tftp > webdir: /var/www/cobbler > xmlrpc_port: 25151 > yum_core_mirror_from_server: 1 > > ----- > > Is there something I'm supposed to be doing to the stock xen > configuration to enable networking for cobbler? > I ask because even specifying an IP manually to anaconda didn't get me > anywhere. I also don't see something that looks like a network device > in the kernel messages of the domU, though I admit to not knowing what > to look for, or if it ought to be there under Xen. > > Thanks, > -Bill > > ----- > Bill McGonigle, Owner Work: 603.667.4000 > BFC Computing, LLC Home: 603.448.1668 > bill at bfccomputing.com Cell: 603.252.2606 > http://www.bfccomputing.com/ Page: 603.442.1833 > Blog: http://blog.bfccomputing.com/ > VCard: http://bfccomputing.com/vcard/bill.vcf > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I'm not immediately sure what's up, but networking does work with Xen installs through cobbler. This may be easier to explore over IRC (#cobbler / irc.freenode.net) if you don't have something blocking IRC in the way. --Michael From Greg.Caetano at hp.com Tue Jun 5 17:17:12 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Tue, 5 Jun 2007 13:17:12 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobbler andrhn toplaynice? In-Reply-To: References: <46657E46.80800@redhat.com><46658DBB.8050301@redhat.com> Message-ID: Progress..... # ls -l /var/www/cobbler/repo_mirror/ total 8 lrwxrwxrwx 1 root apache 47 Jun 5 09:10 rh5basex86 -> /var/www/cobbler/repo_mirror/rhel-i386-server-5 lrwxrwxrwx 1 root apache 49 May 23 13:17 rhel5x86_64 -> /var/www/cobbler/repo_mirror/rhel-x86_64-server-5 # mkdir /var/www/cobbler/repo_mirror/rhel-i386-server-5 # 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 # ls /var/www/cobbler/repo_mirror/rh5basex86/ config.repo repodata # Greg Caetano HP TSG Linux Solutions Alliances Engineering Chicago, IL 773-281-8129 greg.caetano at hp.com Red Hat Certified Engineer RHCE#803004972711193 -----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, June 05, 2007 11:32 AM To: Fedora/Linux Management Tools Subject: RE: [et-mgmt-tools] Has any one managed to get cobbler andrhn toplaynice? Michael Here is some additional testing on the same server # yum update Loading "installonlyn" plugin Loading "rhnplugin" plugin Setting up Update Process Setting up repositories rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 Reading repository metadata in from local files No Packages marked for Update/Obsoletion # /usr/bin/reposync -r rhel-i386-server-5 --download_path=/var/www/cobbler/repo_mirror/rh5basex86 Error: Cannot create destination dir /var/www/cobbler/repo_mirror/rh5basex86 # /usr/bin/reposync -r rhel-i386-server-5 --download_path=/tmp/rh5basex86 No Repositories Available to Set Up # Greg Caetano HP TSG Linux Solutions Alliances Engineering Chicago, IL 773-281-8129 greg.caetano at hp.com Red Hat Certified Engineer RHCE#803004972711193 -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Tuesday, June 05, 2007 11:22 AM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Has any one managed to get cobbler and rhn toplaynice? Caetano, Greg wrote: > I haven't had any luck.... How do you tell reposync the RHN > user/password to check for entitlements? > The server in question has to be entitled for the given channel. The cobbler server must also be RHEL5 (so it can use yum_rhn_plugin). You'll see the core of this is essentially just /usr/bin/reposync -r rhel-i386-server-5 --download_path=/tmp/foo So that may prove easier for testing. Perhaps the server isn't entitled for that channel? Better tools need to exist -- no doubt -- surfr should be providing a more comprehensive solution soon -- shortly after we get virt-factory 0.0.3 out of the way. > # cobbler repo add --name=rh5basex86 --mirror=rhn://rhel-i386-server-5 > # cobbler report > repo : rh5basex86 > mirror : rhn://rhel-i386-server-5 > keep updated : 1 > local filename : > rpm list : > # cobbler reposync > - /usr/bin/reposync -r rhel-i386-server-5 > --download_path=/var/www/cobbler/repo_mirror > - symlink: /var/www/cobbler/repo_mirror/rhel-i386-server-5 -> > /var/www/cobbler/repo_mirror/rh5basex86 > No Repositories Available to Set Up > - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 636, in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 110, in run > self.curry_args(self.args[1:], self.commands['toplevel']) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 465, in curry_args > commands[args[0]](args[1:]) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line > 495, in reposync > self.api.reposync() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in > reposync > return reposync.run() > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 65, in run > self.do_reposync(repo) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 176, in do_reposync > temp_file = self.create_local_file(repo, temp_path, output=False) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 231, in create_local_file > config_file = open(fname, "w+") > IOError: [Errno 2] No such file or directory: > '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' > # > # rpm -qa | grep -i cobbler > cobbler-0.4.8-1 > > Greg Caetano > HP TSG Linux Solutions Alliances Engineering Chicago, IL > 773-281-8129 > greg.caetano at hp.com > Red Hat Certified Engineer > RHCE#803004972711193 > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com > [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Tuesday, June 05, 2007 10:16 AM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Has any one managed to get cobbler and > rhn toplay nice? > > Marc Mondragon wrote: > >> A month or so ago I tried to get this working (w/ Michael's help btw) >> for my RHEL 5 subscriptions but I was unable to. Has anyone managed >> to >> > > >> get this to work in the interim? >> >> Thanks, >> >> Marc Mondragon >> >> Fox River Financial Resources/Ritchie Capital Investments, Ltd. >> 2100 Enterprise Avenue >> Geneva, IL 60134 >> marcmo at foxriver.com >> >> --------------------------------------------------------------------- >> - >> -- >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > > I didn't see it in his attachment, but Marc's referring to ... > > cobbler repo add --name=foo --mirror=rhn://name-of-rhel5-channel > cobbler reposync > > Which worked for me on several different machines, but not for Marc. > Other reports welcome... > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From hbrock at redhat.com Tue Jun 5 17:27:29 2007 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 05 Jun 2007 13:27:29 -0400 Subject: [et-mgmt-tools] [PATCH] [RESEND] Fix continue to install Windows In-Reply-To: <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> References: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> Message-ID: <46659D01.2010503@redhat.com> Nobuhiro Itou wrote: > Hi, > > Would you give me a comment on this patch? > If not, please apply it. > >> I can't continue to install Windows HVM domain after first restart. >> After the restarting, /dev/cdrom (or ISO path) has not been attached to the domain. >> The attached patch solves this problem. >> >> Signed-off-by: Nobuhiro Itou > > > Thanks, > Nobuhiro Itou. > > Wow, I have no idea what happened there. Yes, I have now applied and committed the patch, sorry for the delay! --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 useofweapons at gmail.com Tue Jun 5 17:30:37 2007 From: useofweapons at gmail.com (Richard Shaw) Date: Tue, 5 Jun 2007 18:30:37 +0100 Subject: [et-mgmt-tools] Creating new VM, 404 install iso cannot be found Message-ID: Hi, When creating a new VM under Virtual Machine Manager 0.2.6 I'm getting this error Guest Install Error ERROR Invalid URL location given :[Errno 14] HTTP Error 404: Not Found The path i'm pointing it to is http://localhost/iso/2003.iso Apache is configured correctly Perms are correct I can browse to that url through firefox correctly I can wget the file The wizard just refuses to access it. I can't see what i've missed, any suggestions? Thanks in advance Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From hbrock at redhat.com Tue Jun 5 17:37:01 2007 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 05 Jun 2007 13:37:01 -0400 Subject: [et-mgmt-tools] Creating new VM, 404 install iso cannot be found In-Reply-To: References: Message-ID: <46659F3D.1060602@redhat.com> Richard Shaw wrote: > Hi, > > When creating a new VM under Virtual Machine Manager 0.2.6 I'm getting > this error > > Guest Install Error > ERROR Invalid URL location given :[Errno 14] > HTTP Error 404: Not Found > > The path i'm pointing it to is http://localhost/iso/2003.iso > > Apache is configured correctly > Perms are correct > I can browse to that url through firefox correctly > I can wget the file > > The wizard just refuses to access it. I can't see what i've missed, > any suggestions? > > Thanks in advance > > Richard > It looks like you're trying to install a paravirt guest from an iso image. Unfortunately this won't work -- for paravirt guests, you need to point the installer to a yum repository that has the paravirt kernel and initrd in the place the installer expects. If you're trying to install a fully virt guest, you need to either use the CD, or select the ISO from a readable filesystem. If you can provide more details, we may be able to help more... --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock at redhat.com | virtualization library http://libvirt.org From berrange at redhat.com Tue Jun 5 17:37:23 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 5 Jun 2007 18:37:23 +0100 Subject: [et-mgmt-tools] Creating new VM, 404 install iso cannot be found In-Reply-To: References: Message-ID: <20070605173723.GN15012@redhat.com> On Tue, Jun 05, 2007 at 06:30:37PM +0100, Richard Shaw wrote: > Hi, > > When creating a new VM under Virtual Machine Manager 0.2.6 I'm getting this > error > > Guest Install Error > ERROR Invalid URL location given :[Errno 14] > HTTP Error 404: Not Found > > The path i'm pointing it to is http://localhost/iso/2003.iso > > Apache is configured correctly > Perms are correct > I can browse to that url through firefox correctly > I can wget the file > > The wizard just refuses to access it. I can't see what i've missed, any > suggestions? You can't do paravirt installs from an ISO image, and you can't do fully virt installs from the network. So not sure what you're trying do here ? Either need to have the ISO locally for fullyvirt, or point to a HTTP distro tree for paravirt 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 marcmo at foxriver.com Tue Jun 5 17:44:18 2007 From: marcmo at foxriver.com (Marc Mondragon) Date: Tue, 5 Jun 2007 12:44:18 -0500 Subject: [et-mgmt-tools] RE: et-mgmt-tools Digest, Vol 10, Issue 7 In-Reply-To: <20070605171837.D43D97393B@hormel.redhat.com> References: <20070605171837.D43D97393B@hormel.redhat.com> Message-ID: > > # yum update > Loading "installonlyn" plugin > Loading "rhnplugin" plugin > Setting up Update Process > Setting up repositories > rhel-i386-server-5 100% |=========================| 1.4 kB > 00:00 > Reading repository metadata in from local files No Packages marked for > Update/Obsoletion # /usr/bin/reposync -r rhel-i386-server-5 > --download_path=/var/www/cobbler/repo_mirror/rh5basex86 > Error: Cannot create destination dir > /var/www/cobbler/repo_mirror/rh5basex86 > # /usr/bin/reposync -r rhel-i386-server-5 > --download_path=/tmp/rh5basex86 > No Repositories Available to Set Up > # > That's what I get as well ... [root at lagavulin ~]# /usr/bin/reposync -r rhel-i386-server-5 --download_path=/tmp No Repositories Available to Set Up Marc Mondragon Fox River Financial Resources/Ritchie Capital Investments, Ltd. 2100 Enterprise Avenue Geneva, IL 60134 marcmo at foxriver.com From useofweapons at gmail.com Tue Jun 5 17:50:48 2007 From: useofweapons at gmail.com (Richard Shaw) Date: Tue, 5 Jun 2007 18:50:48 +0100 Subject: [et-mgmt-tools] Creating new VM, 404 install iso cannot be found In-Reply-To: <20070605173723.GN15012@redhat.com> References: <20070605173723.GN15012@redhat.com> Message-ID: At this point i'd tell myself to RFTM, spot the new to xen person. I'm trying to install windows 2003 under paravirt, when I'm going to need full virt. Thanks for the quick responses Regards Richard On 6/5/07, Daniel P. Berrange wrote: > > On Tue, Jun 05, 2007 at 06:30:37PM +0100, Richard Shaw wrote: > > Hi, > > > > When creating a new VM under Virtual Machine Manager 0.2.6 I'm getting > this > > error > > > > Guest Install Error > > ERROR Invalid URL location given :[Errno 14] > > HTTP Error 404: Not Found > > > > The path i'm pointing it to is http://localhost/iso/2003.iso > > > > Apache is configured correctly > > Perms are correct > > I can browse to that url through firefox correctly > > I can wget the file > > > > The wizard just refuses to access it. I can't see what i've missed, > any > > suggestions? > > You can't do paravirt installs from an ISO image, and you can't do fully > virt installs from the network. So not sure what you're trying do here ? > Either need to have the ISO locally for fullyvirt, or point to a HTTP > distro tree for paravirt > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Caetano at hp.com Tue Jun 5 20:04:43 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Tue, 5 Jun 2007 16:04:43 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobblerandrhn toplaynice? In-Reply-To: References: <46657E46.80800@redhat.com><46658DBB.8050301@redhat.com> Message-ID: In a nutshell, I needed to manually create two directories, (.origin and repo-channel-name) in order to make this reposync to complete. Here it is from start to finish. # rpm -qa | grep -i cobbler cobbler-0.4.8-1 # rpm -qa | grep -i yum-utils yum-utils-1.0.3-1 # cobbler repo add --name=rh5basex86 --mirror=rhn://rhel-i386-server-5 # cobbler sync sync distro: rhel5x86_64-xen-x86_64 sync distro: rhel5x86_64-x86_64 sync distro: rhel5x86-xen-i386 sync distro: toolkit sync distro: rhel5x86-i386 sync profile: rhel5x86_64-xen-x86_64 sync profile: rhel5x86-i386 sync profile: toolkitbash sync profile: rhel5x86_64xenhost sync profile: rhel5x86_64-x86_64 sync profile: toolkitfw sync profile: rhel5x86-xen-i386 sync profile: rhel5x86_64base sync profile: rhel5x86base # cobbler reposync - /usr/bin/reposync -r rhel-i386-server-5 --download_path=/var/www/cobbler/repo_mirror - symlink: /var/www/cobbler/repo_mirror/rhel-i386-server-5 -> /var/www/cobbler/repo_mirror/rh5basex86 No Repositories Available to Set Up - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 636, in main BootCLI(sys.argv).run() File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 110, in run self.curry_args(self.args[1:], self.commands['toplevel']) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 465, in curry_args commands[args[0]](args[1:]) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 495, in reposync self.api.reposync() File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in reposync return reposync.run() File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 65, in run self.do_reposync(repo) File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 176, in do_reposync temp_file = self.create_local_file(repo, temp_path, output=False) File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 231, in create_local_file config_file = open(fname, "w+") IOError: [Errno 2] No such file or directory: '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' # ls -l /var/www/cobbler/repo_mirror total 4 lrwxrwxrwx 1 root apache 47 Jun 5 11:49 rh5basex86 -> /var/www/cobbler/repo_mirror/rhel-i386-server-5 # mkdir /var/www/cobbler/repo_mirror/rhel-i386-server-5 # 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 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 636, in main BootCLI(sys.argv).run() File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 110, in run self.curry_args(self.args[1:], self.commands['toplevel']) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 465, in curry_args commands[args[0]](args[1:]) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 495, in reposync self.api.reposync() File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in reposync return reposync.run() File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 65, in run self.do_reposync(repo) File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 176, in do_reposync temp_file = self.create_local_file(repo, temp_path, output=False) File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", line 231, in create_local_file config_file = open(fname, "w+") IOError: [Errno 2] No such file or directory: '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' # ls -la /var/www/cobbler/repo_mirror total 28 drwxr-sr-x 3 apache apache 4096 Jun 5 11:50 . drwxr-sr-x 12 apache apache 4096 Jun 5 11:49 .. lrwxrwxrwx 1 root apache 47 Jun 5 11:49 rh5basex86 -> /var/www/cobbler/repo_mirror/rhel-i386-server-5 drwxr-sr-x 2 root apache 4096 Jun 5 11:50 rhel-i386-server-5 # mkdir /var/www/cobbler/repo_mirror/.origin # ls -la /var/www/cobbler/repo_mirror total 36 drwxr-sr-x 4 apache apache 4096 Jun 5 11:51 . drwxr-sr-x 12 apache apache 4096 Jun 5 11:49 .. drwxr-sr-x 2 root apache 4096 Jun 5 11:51 .origin lrwxrwxrwx 1 root apache 47 Jun 5 11:49 rh5basex86 -> /var/www/cobbler/repo_mirror/rhel-i386-server-5 drwxr-sr-x 2 root apache 4096 Jun 5 11:50 rhel-i386-server-5 # 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 # Greg Caetano HP TSG Linux Solutions Alliances Engineering Chicago, IL 773-281-8129 greg.caetano at hp.com Red Hat Certified Engineer RHCE#803004972711193 From mdehaan at redhat.com Tue Jun 5 20:54:47 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 05 Jun 2007 16:54:47 -0400 Subject: [et-mgmt-tools] Has any one managed to get cobblerandrhn toplaynice? In-Reply-To: References: <46657E46.80800@redhat.com><46658DBB.8050301@redhat.com> Message-ID: <4665CD97.2010409@redhat.com> Caetano, Greg wrote: > In a nutshell, > > I needed to manually create two directories, (.origin and > repo-channel-name) in order to make this reposync to complete. > > Here it is from start to finish. > > # rpm -qa | grep -i cobbler > cobbler-0.4.8-1 > # rpm -qa | grep -i yum-utils > yum-utils-1.0.3-1 > > # cobbler repo add --name=rh5basex86 --mirror=rhn://rhel-i386-server-5 > # cobbler sync > sync distro: rhel5x86_64-xen-x86_64 > sync distro: rhel5x86_64-x86_64 > sync distro: rhel5x86-xen-i386 > sync distro: toolkit > sync distro: rhel5x86-i386 > sync profile: rhel5x86_64-xen-x86_64 > sync profile: rhel5x86-i386 > sync profile: toolkitbash > sync profile: rhel5x86_64xenhost > sync profile: rhel5x86_64-x86_64 > sync profile: toolkitfw > sync profile: rhel5x86-xen-i386 > sync profile: rhel5x86_64base > sync profile: rhel5x86base > # cobbler reposync > - /usr/bin/reposync -r rhel-i386-server-5 > --download_path=/var/www/cobbler/repo_mirror > - symlink: /var/www/cobbler/repo_mirror/rhel-i386-server-5 -> > /var/www/cobbler/repo_mirror/rh5basex86 > No Repositories Available to Set Up > - creating: /var/www/cobbler/repo_mirror/.origin/rh5basex86.repo > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 636, > in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 110, > in run > self.curry_args(self.args[1:], self.commands['toplevel']) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 465, > in curry_args > commands[args[0]](args[1:]) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 495, > in reposync > self.api.reposync() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in > reposync > return reposync.run() > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 65, in run > self.do_reposync(repo) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 176, in do_reposync > temp_file = self.create_local_file(repo, temp_path, output=False) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 231, in create_local_file > config_file = open(fname, "w+") > IOError: [Errno 2] No such file or directory: > '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' > # ls -l /var/www/cobbler/repo_mirror > total 4 > lrwxrwxrwx 1 root apache 47 Jun 5 11:49 rh5basex86 -> > /var/www/cobbler/repo_mirror/rhel-i386-server-5 > # mkdir /var/www/cobbler/repo_mirror/rhel-i386-server-5 > # 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 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 636, > in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 110, > in run > self.curry_args(self.args[1:], self.commands['toplevel']) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 465, > in curry_args > commands[args[0]](args[1:]) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 495, > in reposync > self.api.reposync() > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 137, in > reposync > return reposync.run() > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 65, in run > self.do_reposync(repo) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 176, in do_reposync > temp_file = self.create_local_file(repo, temp_path, output=False) > File "/usr/lib/python2.4/site-packages/cobbler/action_reposync.py", > line 231, in create_local_file > config_file = open(fname, "w+") > IOError: [Errno 2] No such file or directory: > '/var/www/cobbler/repo_mirror/.origin/rh5basex86.repo' > # ls -la /var/www/cobbler/repo_mirror > total 28 > drwxr-sr-x 3 apache apache 4096 Jun 5 11:50 . > drwxr-sr-x 12 apache apache 4096 Jun 5 11:49 .. > lrwxrwxrwx 1 root apache 47 Jun 5 11:49 rh5basex86 -> > /var/www/cobbler/repo_mirror/rhel-i386-server-5 > drwxr-sr-x 2 root apache 4096 Jun 5 11:50 rhel-i386-server-5 > # mkdir /var/www/cobbler/repo_mirror/.origin > # ls -la /var/www/cobbler/repo_mirror > total 36 > drwxr-sr-x 4 apache apache 4096 Jun 5 11:51 . > drwxr-sr-x 12 apache apache 4096 Jun 5 11:49 .. > drwxr-sr-x 2 root apache 4096 Jun 5 11:51 .origin > lrwxrwxrwx 1 root apache 47 Jun 5 11:49 rh5basex86 -> > /var/www/cobbler/repo_mirror/rhel-i386-server-5 > drwxr-sr-x 2 root apache 4096 Jun 5 11:50 rhel-i386-server-5 > # 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 > # > > > Greg Caetano > HP TSG Linux Solutions Alliances Engineering > Chicago, IL > 773-281-8129 > greg.caetano at hp.com > Red Hat Certified Engineer > RHCE#803004972711193 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > I'll tweak the app appropriately... generally I would have expected yum to create the dest directory, but that appears to not be consistant. The missing file in .origin would explain much. I already had the origin dir on my machines from other testing, apparently. Thanks! --Michael From bill at bfccomputing.com Wed Jun 6 00:27:53 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Tue, 5 Jun 2007 20:27:53 -0400 Subject: [et-mgmt-tools] no network with koan --virt vm? In-Reply-To: References: Message-ID: <3CB66338-8752-4F4C-8C18-3FF4D52B9DE3@bfccomputing.com> On Jun 4, 2007, at 19:42, Bill McGonigle wrote: > koan --virt --server=bread --system=BF:CC:AC:10:00:65 > ... > I'd really like to hear a, "hey stupid, you forgot to ____". :) > Failing that, does anybody know how to suspend anaconda so I could > see what, say, ifconfig has to say about the situation? Virtual > Consoles work at the real console, but I'm not figuring it out in > xm console. OK, at least part of the _____ was "Learn how MAC addresses are structured". By using BF as the most significant byte, my MAC started with 10111111, *with an LSB of 1*. This makes it a multicast address. Doh. So my determination that I didn't have networking was correct, only more correct was that I didn't have unicast networking (obviously what's useful here) and I shot myself in the foot to boot. I've switched to 02 (00000010) as my first byte which both makes it a unicast address and follows the proper form for a locally-assigned MAC. I still don't have DHCP working yet, but I can now at least see the network, and am on to other errors. -Bill ----- Bill McGonigle, Owner Work: 603.667.4000 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From fukuta.saori at jp.fujitsu.com Wed Jun 6 04:40:24 2007 From: fukuta.saori at jp.fujitsu.com (Saori Fukuta) Date: Wed, 06 Jun 2007 13:40:24 +0900 Subject: [et-mgmt-tools] [PATCH] checking for busy disk Message-ID: <20070606134018.E8D3.FUKUTA.SAORI@jp.fujitsu.com> Hi, The virt-install & virt-manager are checking if the physical device has been using by other domain. But they does not check, when the device is file or tap. So I add to check it. Signed-off-by: Saori Fukuta Thanks, Saori Fukuta diff -r 797e92fd5e0d virtinst/Guest.py --- a/virtinst/Guest.py Thu May 31 14:20:33 2007 -0400 +++ b/virtinst/Guest.py Wed Jun 06 11:34:33 2007 +0900 @@ -163,6 +163,7 @@ class VirtualDisk: try: try: count += ctx.xpathEval("count(/domain/devices/disk/source[@dev='%s'])" % self.path) + count += ctx.xpathEval("count(/domain/devices/disk/source[@file='%s'])" % self.path) except: continue finally: From drovalev at kaluga-gov.ru Wed Jun 6 06:07:49 2007 From: drovalev at kaluga-gov.ru (drovalev at kaluga-gov.ru) Date: Wed, 6 Jun 2007 10:07:49 +0400 Subject: [et-mgmt-tools] libvir: error : library call virConnectNumOfNetworks failed, possibly not supported Message-ID: Hi, 1.) Don`t work in virt-manager create nets. start virt-manager in xterm: libvir: error : library call virConnectNumOfNetworks failed, possibly not supported libvir: error : library call virConnectNumOfDefinedNetworks failed, possibly not supported but virt-manager work! Why??? What install more? 2.) Where config files for vm? Start install vm Windows2003 from iso image. After reboot windows not find cdrom! Why? where indicate him? where config file? 3.) Why not work button "delete" in "Virtual machin details"-> "Hardware" My system: CentOS_5, Xen 3.1 (from source), libvirt-0.2.2, virtinst-0.103.0, virt-manager-0.4.0, xen-libs-3.1 Please help! How install continue windows2003 after reboot???!!! Drovalev Roman Nikolaevich. From fj1826dm at aa.jp.fujitsu.com Wed Jun 6 08:51:25 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Wed, 6 Jun 2007 17:51:25 +0900 Subject: [et-mgmt-tools] [PATCH] Fixes the error when Windows is installedwith "-- os-variant" option In-Reply-To: <200705310829.GAI18261.73KNE29G@aa.jp.fujitsu.com> References: <200705310829.GAI18261.73KNE29G@aa.jp.fujitsu.com> Message-ID: <200706061751.GBG00570.293G7NKE@aa.jp.fujitsu.com> Hi Would you give me a comment on this patch? If not, please apply it. Thanks, Masayuki Sunou. In message <200705310829.GAI18261.73KNE29G at aa.jp.fujitsu.com> "[et-mgmt-tools] [PATCH] Fixes the error when Windows is installedwith "-- os-variant" option" "Masayuki Sunou " wrote: > Hi > > When I install Windows with "-- os-variant" option, virt-install outputs the > following errors. > > -------------------------------------------------------------------------------- > # virt-install --name TEST --ram 256 --vnc --hvm --cdrom /mnt/WinSrv2k3sp1/Win2003_Sp1.iso > --os-type="windows" --os-variant="win2k" --file /dev/sda8 > > Starting install... > libvir: Xen Daemon error : GET operation failed: > Domain installation may not have been > successful. If it was, you can restart your domain > by running 'virsh start TEST'; otherwise, please > restart your installation. > Wed, 30 May 2007 13:05:57 ERROR 'distro' > Traceback (most recent call last): > File "/usr/bin/virt-install", line 647, in > main() > File "/usr/bin/virt-install", line 607, in main > dom = guest.start_install(conscb,progresscb) > File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 668, in start_install > self._prepare_install(meter) > File "/usr/lib/python2.5/site-packages/virtinst/FullVirtGuest.py", line 195, in _prepare_install > distro = self.os_distro) > File "/usr/lib/python2.5/site-packages/virtinst/FullVirtGuest.py", line 148, in get_os_distro > return FullVirtGuest.OS_TYPES[self.os_type]["variants"][self.os_variant]["distro""] > KeyError: 'distro' > -------------------------------------------------------------------------------- > > This patch fixes it. > > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. > > ------------------------------------------------------------------------------- > diff -r 7fd35e3303c6 virtinst/FullVirtGuest.py > --- a/virtinst/FullVirtGuest.py Fri May 25 10:49:47 2007 -0400 > +++ b/virtinst/FullVirtGuest.py Wed May 30 13:23:48 2007 +0900 > @@ -144,7 +144,7 @@ class FullVirtGuest(Guest.XenGuest): > self.features["apic"] = FullVirtGuest.OS_TYPES[os_type]["apic"] > > def get_os_distro(self): > - if self.os_type is not None and self.os_variant is not None: > + if self.os_type is not None and self.os_variant is not None and "distro" in FullVirtGuest.OS_TYPES[self.os_type]["variants"][self.os_variant]: > return FullVirtGuest.OS_TYPES[self.os_type]["variants"][self.os_variant]["distro"] > return None > os_distro = property(get_os_distro) > ------------------------------------------------------------------------------- > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From Hua.Zhang at Sun.COM Thu Jun 7 03:47:55 2007 From: Hua.Zhang at Sun.COM (Henry Zhang) Date: Thu, 07 Jun 2007 11:47:55 +0800 Subject: [et-mgmt-tools] error when create full-virt DomU in virt-manager v0.4 at Solaris In-Reply-To: <20070601160022.885FC73C9E@hormel.redhat.com> References: <20070601160022.885FC73C9E@hormel.redhat.com> Message-ID: <46677FEB.3030601@sun.com> Hi there, I am running virt-manager v0.4 at Solaris, and I have one problem, any comments and help is welcome, thanks.. When I run create full-virt domU by using v0.4, I got a error message: Error creating domain: vncpasswd is not set up in VMconfig and xend-config. Anyone met the same problem? what's the reason and where should I dig to fix it? Thanks, Henry From fj1826dm at aa.jp.fujitsu.com Thu Jun 7 06:00:58 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Thu, 7 Jun 2007 15:00:58 +0900 Subject: [et-mgmt-tools] [PATCH] Fix connection with the console when the domain is created Message-ID: <200706071500.ECC64042.K23EN9G7@aa.jp.fujitsu.com> Hi When virt-mangager is set the following configuration and VM is created, the console is not displayed automatically long time. (it displays "The console is currently unavailable") 1. Set "Status monitoring" to long time.(ex: 60 seconds). 2. Set "Automatically open consoles" to "For new domains". This patch fixes it by waiting start of the console.(like virt-install) Note: # 5 seconds, .25 second sleeps --> 5 : Virt-manager waits only for short time.(5 seconds) Because virt-manager have a means to connect with a console easily again. (unlike virt-install) .25 : Virt-manager matches with virt-install Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- diff -r 27ad8c7fbc3e src/virtManager/create.py --- a/src/virtManager/create.py Thu May 24 16:49:13 2007 -0400 +++ b/src/virtManager/create.py Wed Jun 06 16:17:15 2007 +0900 @@ -637,13 +637,22 @@ class vmmCreate(gobject.GObject): self.connection.tick(noStatsUpdate=True) if self.config.get_console_popup() == 1: - # user has requested console on new created vms only - vm = self.connection.get_vm(guest.uuid) - (gtype, host, port) = vm.get_graphics_console() - if gtype == "vnc": - self.emit("action-show-console", self.connection.get_uri(), guest.uuid) - else: - self.emit("action-show-terminal", self.connection.get_uri(), guest.uuid) + import time + num = 0 + while num < ( 5 / 0.25 ): # 5 seconds, .25 second sleeps + # user has requested console on new created vms only + vm = self.connection.get_vm(guest.uuid) + (gtype, host, port) = vm.get_graphics_console() + if gtype == "vnc": + if port == -1: + num += 1 + time.sleep(0.25) + continue + self.emit("action-show-console", self.connection.get_uri(), guest.uuid) + break + else: + self.emit("action-show-terminal", self.connection.get_uri(), guest.uuid) + break self.close() def do_install(self, guest, asyncjob): diff -r 27ad8c7fbc3e src/virtManager/domain.py --- a/src/virtManager/domain.py Thu May 24 16:49:13 2007 -0400 +++ b/src/virtManager/domain.py Wed Jun 06 16:17:15 2007 +0900 @@ -430,6 +430,7 @@ class vmmDomain(gobject.GObject): return os.access(tty, os.R_OK | os.W_OK) def get_graphics_console(self): + self.xml = None; type = self.get_xml_string("/domain/devices/graphics/@type") port = None if type == "vnc": From fukuta.saori at jp.fujitsu.com Thu Jun 7 06:14:52 2007 From: fukuta.saori at jp.fujitsu.com (Saori Fukuta) Date: Thu, 07 Jun 2007 15:14:52 +0900 Subject: [et-mgmt-tools] [PATCH] checking for file-size Message-ID: <20070607151404.1496.FUKUTA.SAORI@jp.fujitsu.com> Hi, I add to check for the file-size of the disk. If the file-size is less than or equal to 0, it will show the following message: ERROR: Size of the disk image must be greater than 0 and ask again. Signed-off-by: Saori Fukuta Thanks, Saori Fukuta diff -r 797e92fd5e0d virtinst/Guest.py --- a/virtinst/Guest.py Thu May 31 14:20:33 2007 -0400 +++ b/virtinst/Guest.py Thu Jun 07 14:19:54 2007 +0900 @@ -57,6 +57,8 @@ class VirtualDisk: if not os.path.exists(self.path): if size is None: raise ValueError, "Must provide a size for non-existent disks" + if size <= 0: + raise ValueError, "Size of the disk image must be greater than 0" self._type = VirtualDisk.TYPE_FILE else: if stat.S_ISBLK(os.stat(self.path)[stat.ST_MODE]): From fj1826dm at aa.jp.fujitsu.com Thu Jun 7 08:39:00 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Thu, 7 Jun 2007 17:39:00 +0900 Subject: [et-mgmt-tools] [PATCH] Fix memory check in interactive mode In-Reply-To: <200706011008.FEF69245.K9GE7N32@aa.jp.fujitsu.com> References: <200706011008.FEF69245.K9GE7N32@aa.jp.fujitsu.com> Message-ID: <200706071738.HBE00550.9G7EK3N2@aa.jp.fujitsu.com> Hi Would you give me a comment on this patch? If not, please apply it. Thanks, Masayuki Sunou. In message <200706011008.FEF69245.K9GE7N32 at aa.jp.fujitsu.com> "[et-mgmt-tools] [PATCH] Fix memory check in interactive mode" "Masayuki Sunou " wrote: > Hi > > When memory is interactively input to virt-install, memory is not checked. > > ------------------------------------------------------------ > # virt-install --name TEST --hvm > How much RAM should be allocated (in megabytes)? 1 > What would you like to use as the disk (path)? > ------------------------------------------------------------ > > This patch fixes it. > > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. > > ------------------------------------------------------------------------------- > diff -r 7fd35e3303c6 virt-install > --- a/virt-install Fri May 25 10:49:47 2007 -0400 > +++ b/virt-install Thu May 31 10:49:20 2007 +0900 > @@ -87,14 +87,14 @@ def get_name(name, guest): > > def get_memory(memory, guest): > while 1: > - memory = prompt_for_input("How much RAM should be allocated (in megabytes)?", memory) > - if memory < MIN_RAM: > - print "ERROR: Installs currently require %d megs of RAM." %(MIN_RAM,) > - print "" > - memory = None > - continue > - try: > - guest.memory = int(memory) > + try: > + memory = int(prompt_for_input("How much RAM should be allocated (in megabytes)?", memory)) > + if memory < MIN_RAM: > + print "ERROR: Installs currently require %d megs of RAM." %(MIN_RAM,) > + print "" > + memory = None > + continue > + guest.memory = memory > break > except ValueError, e: > print "ERROR: ", e > ------------------------------------------------------------------------------- > > _______________________________________________ > 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 Jun 7 11:15:44 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 7 Jun 2007 12:15:44 +0100 Subject: [et-mgmt-tools] error when create full-virt DomU in virt-manager v0.4 at Solaris In-Reply-To: <46677FEB.3030601@sun.com> References: <20070601160022.885FC73C9E@hormel.redhat.com> <46677FEB.3030601@sun.com> Message-ID: <20070607111544.GB12398@redhat.com> On Thu, Jun 07, 2007 at 11:47:55AM +0800, Henry Zhang wrote: > Hi there, > > I am running virt-manager v0.4 at Solaris, and I have one problem, any > comments and help is welcome, thanks.. > > When I run create full-virt domU by using v0.4, I got a error message: > Error creating domain: vncpasswd is not set up in VMconfig and > xend-config. Anyone met the same problem? what's the reason and where > should I dig to fix it? Sounds like your /etc/xen/xend-config.sxp is missing the entry for the vnc password. It should have a line like # The default password for VNC console on HVM domain. # Empty string is no authentication. (vncpasswd '') 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 Thu Jun 7 12:35:54 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 7 Jun 2007 13:35:54 +0100 Subject: [et-mgmt-tools] [PATCH] checking for file-size In-Reply-To: <20070607151404.1496.FUKUTA.SAORI@jp.fujitsu.com> References: <20070607151404.1496.FUKUTA.SAORI@jp.fujitsu.com> Message-ID: <20070607123553.GA2119@redhat.com> On Thu, Jun 07, 2007 at 03:14:52PM +0900, Saori Fukuta wrote: > Hi, > > I add to check for the file-size of the disk. > If the file-size is less than or equal to 0, it will show the following > message: > ERROR: Size of the disk image must be greater than 0 > and ask again. Looks good to me, thnaks. 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 Thu Jun 7 12:48:57 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 7 Jun 2007 13:48:57 +0100 Subject: [et-mgmt-tools] [PATCH] Fix connection with the console when the domain is created In-Reply-To: <200706071500.ECC64042.K23EN9G7@aa.jp.fujitsu.com> References: <200706071500.ECC64042.K23EN9G7@aa.jp.fujitsu.com> Message-ID: <20070607124857.GB2119@redhat.com> On Thu, Jun 07, 2007 at 03:00:58PM +0900, Masayuki Sunou wrote: > Hi > > When virt-mangager is set the following configuration and VM is created, > the console is not displayed automatically long time. > (it displays "The console is currently unavailable") > > 1. Set "Status monitoring" to long time.(ex: 60 seconds). > 2. Set "Automatically open consoles" to "For new domains". > > This patch fixes it by waiting start of the console.(like virt-install) This is bad - you can't have a while loop which sits for 5 seconds in an even handler in GTK because it will block all UI events from running. > Note: > # 5 seconds, .25 second sleeps > --> 5 : Virt-manager waits only for short time.(5 seconds) > Because virt-manager have a means to connect with a console > easily again. (unlike virt-install) The console code already has support for auto-connecting to the console with retries. When popping up the console it will retry after 125 ms, 250ms, 500ms, 1s, 2s and then every 2s upto 10 times. I'm interested to know what this isn't working for you ? Check the log file /root/.virt-manager/virt-manager.log which should show you messages every time it tries to open the console. The code for re-trying the console connection is in src/virtManager/console.py in the try_login() method. 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 Thu Jun 7 12:51:20 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 7 Jun 2007 13:51:20 +0100 Subject: [et-mgmt-tools] [PATCH] Fix memory check in interactive mode In-Reply-To: <200706071738.HBE00550.9G7EK3N2@aa.jp.fujitsu.com> References: <200706011008.FEF69245.K9GE7N32@aa.jp.fujitsu.com> <200706071738.HBE00550.9G7EK3N2@aa.jp.fujitsu.com> Message-ID: <20070607125120.GC2119@redhat.com> On Thu, Jun 07, 2007 at 05:39:00PM +0900, Masayuki Sunou wrote: > Hi > > Would you give me a comment on this patch? Looks good to me. 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 pmyers at redhat.com Thu Jun 7 14:14:35 2007 From: pmyers at redhat.com (Perry Myers) Date: Thu, 07 Jun 2007 10:14:35 -0400 Subject: [et-mgmt-tools] [PATCH] cobbler reposync/createrepo bugfixes and enhancements Message-ID: <466812CB.8080701@redhat.com> Patch to some of the python scripts in cobbler to do the following: 1. There was a bug in action_reposync.py:createrepo_walker that caused createrepo to be run on every subdirectory of the repository being synced. The core problem was fnames = [] which creates a new list instead of del fnames [:] which modifies the list in place. 2. Added a new parameter to repos (--createrepo-flags) to be used for passing useful flags like "-c cache -C -g repodata/comps.xml" when createrepo is called. This touched a few of the python scripts. 3. Modified createrepo in action_import to use the -c cache flag so that future syncs using this repo don't have to regenerate everything. Please let me know if you have any comments on any of the above changes. Signed-off-by: Perry Myers (pmyers at redhat.com) Thanks, Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 703 362 9622 -=| diff -Naur cobbler/cobbler/action_import.py cobbler-mod/cobbler/action_import.py --- cobbler/cobbler/action_import.py 2007-06-06 16:33:33.000000000 -0400 +++ cobbler-mod/cobbler/action_import.py 2007-06-07 09:36:02.000000000 -0400 @@ -339,7 +339,7 @@ if not self.processed_repos.has_key(comps_path): utils.remove_yum_olddata(comps_path) #cmd = "createrepo --basedir / --groupfile %s %s" % (os.path.join(comps_path, masterdir, comps_file), comps_path) - cmd = "createrepo --groupfile %s %s" % (os.path.join(comps_path, masterdir, comps_file), comps_path) + cmd = "createrepo -c cache --groupfile %s %s" % (os.path.join(comps_path, masterdir, comps_file), comps_path) print _("- %s") % cmd sub_process.call(cmd,shell=True) self.processed_repos[comps_path] = 1 diff -Naur cobbler/cobbler/action_reposync.py cobbler-mod/cobbler/action_reposync.py --- cobbler/cobbler/action_reposync.py 2007-06-06 16:33:33.000000000 -0400 +++ cobbler-mod/cobbler/action_reposync.py 2007-06-07 09:43:40.000000000 -0400 @@ -45,7 +45,7 @@ self.systems = config.systems() self.settings = config.settings() self.repos = config.repos() - + # ================================================================================== def run(self,verbose=True): @@ -59,13 +59,11 @@ mirror = repo.mirror if not os.path.isdir(repo_path) and not repo.mirror.lower().startswith("rhn://"): os.makedirs(repo_path) - # if path contains http:// or ftp://, use with yum's reposync. - # else do rsync - lower = mirror.lower() - if lower.startswith("http://") or lower.startswith("ftp://") or lower.startswith("rhn://"): - self.do_reposync(repo) - else: + + if repo.is_rsync_mirror(): self.do_rsync(repo) + else: + self.do_reposync(repo) return True @@ -178,8 +176,7 @@ # now run createrepo to rebuild the index - arg = None - os.path.walk(dest_path, self.createrepo_walker, arg) + os.path.walk(dest_path, self.createrepo_walker, repo) # create the config file the hosts will use to access the repository. @@ -210,9 +207,8 @@ rc = sub_process.call(cmd, shell=True) if rc !=0: raise CX(_("cobbler reposync failed")) - arg = {} print _("- walking: %s") % dest_path - os.path.walk(dest_path, self.createrepo_walker, arg) + os.path.walk(dest_path, self.createrepo_walker, repo) self.create_local_file(repo, dest_path) # ================================================================================== @@ -243,19 +239,19 @@ # ================================================================================== - def createrepo_walker(self, arg, dirname, fname): + def createrepo_walker(self, repo, dirname, fnames): """ Used to run createrepo on a copied mirror. """ target_dir = os.path.dirname(dirname).split("/")[-1] - print _("- scanning: %s") % target_dir - if target_dir.lower() in [ "i386", "x86_64", "ia64" ] or (arg is None): + if target_dir.lower() in [ "i386", "x86_64", "ia64" ] or not repo.is_rsync_mirror(): utils.remove_yum_olddata(dirname) try: - cmd = "createrepo %s" % dirname + cmd = "createrepo %s %s" % (repo.createrepo_flags, dirname) print _("- %s") % cmd sub_process.call(cmd, shell=True) except: print _("- createrepo failed. Is it installed?") - fnames = [] # we're in the right place + del fnames[:] # we're in the right place + diff -Naur cobbler/cobbler/cobbler.py cobbler-mod/cobbler/cobbler.py --- cobbler/cobbler/cobbler.py 2007-06-06 16:33:33.000000000 -0400 +++ cobbler-mod/cobbler/cobbler.py 2007-06-07 09:36:02.000000000 -0400 @@ -432,7 +432,8 @@ '--mirror' : lambda(a): repo.set_mirror(a), '--keep-updated' : lambda(a): repo.set_keep_updated(a), '--local-filename' : lambda(a): repo.set_local_filename(a), - '--rpm-list' : lambda(a): repo.set_rpm_list(a) + '--rpm-list' : lambda(a): repo.set_rpm_list(a), + '--createrepo-flags' : lambda(a): repo.set_createrepo_flags(a), } def on_ok(): if newname is not None: diff -Naur cobbler/cobbler/item_repo.py cobbler-mod/cobbler/item_repo.py --- cobbler/cobbler/item_repo.py 2007-06-06 16:33:33.000000000 -0400 +++ cobbler-mod/cobbler/item_repo.py 2007-06-07 09:36:02.000000000 -0400 @@ -30,14 +30,16 @@ self.mirror = None # is required self.keep_updated = 1 # has reasonable defaults self.local_filename = "" # off by default - self.rpm_list = "" # just get selected RPMs + deps + self.rpm_list = "" # just get selected RPMs + deps + self.createrepo_flags = "" # none by default def from_datastruct(self,seed_data): - self.name = self.load_item(seed_data, 'name') - self.mirror = self.load_item(seed_data, 'mirror') - self.keep_updated = self.load_item(seed_data, 'keep_updated') - self.local_filename = self.load_item(seed_data, 'local_filename') - self.rpm_list = self.load_item(seed_data, 'rpm_list') + self.name = self.load_item(seed_data, 'name') + self.mirror = self.load_item(seed_data, 'mirror') + self.keep_updated = self.load_item(seed_data, 'keep_updated') + self.local_filename = self.load_item(seed_data, 'local_filename') + self.rpm_list = self.load_item(seed_data, 'rpm_list') + self.createrepo_flags = self.load_item(seed_data, 'createrepo_flags') return self def set_name(self,name): @@ -98,6 +100,14 @@ pass self.rpm_list = rpmlist + def set_createrepo_flags(self,createrepo_flags): + """ + Flags passed to createrepo when it is called. Common flags to use would be + -c cache or -g comps.xml to generate group information. + """ + self.createrepo_flags = createrepo_flags + return True + def is_valid(self): """ A repo is valid if it has a name and a mirror URL @@ -110,18 +120,30 @@ def to_datastruct(self): return { - 'name' : self.name, - 'mirror' : self.mirror, - 'keep_updated' : self.keep_updated, - 'local_filename' : self.local_filename, - 'rpm_list' : self.rpm_list + 'name' : self.name, + 'mirror' : self.mirror, + 'keep_updated' : self.keep_updated, + 'local_filename' : self.local_filename, + 'rpm_list' : self.rpm_list, + 'createrepo_flags' : self.createrepo_flags } def printable(self): - buf = _("repo : %s\n") % self.name - buf = buf + _("mirror : %s\n") % self.mirror - buf = buf + _("keep updated : %s\n") % self.keep_updated - buf = buf + _("local filename : %s\n") % self.local_filename - buf = buf + _("rpm list : %s\n") % self.rpm_list + buf = _("repo : %s\n") % self.name + buf = buf + _("mirror : %s\n") % self.mirror + buf = buf + _("keep updated : %s\n") % self.keep_updated + buf = buf + _("local filename : %s\n") % self.local_filename + buf = buf + _("rpm list : %s\n") % self.rpm_list + buf = buf + _("createrepo_flags : %s\n") % self.createrepo_flags return buf + def is_rsync_mirror(self): + """ + Returns True if this mirror is synchronized using rsync, False otherwise + """ + lower = self.mirror.lower() + if lower.startswith("http://") or lower.startswith("ftp://") or lower.startswith("rhn://"): + return False + else: + return True + From mdehaan at redhat.com Thu Jun 7 15:20:26 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 07 Jun 2007 11:20:26 -0400 Subject: [et-mgmt-tools] [PATCH] cobbler reposync/createrepo bugfixes and enhancements In-Reply-To: <466812CB.8080701@redhat.com> References: <466812CB.8080701@redhat.com> Message-ID: <4668223A.8030501@redhat.com> Perry Myers wrote: > Patch to some of the python scripts in cobbler to do the following: > > 1. There was a bug in action_reposync.py:createrepo_walker that caused createrepo to be run on every subdirectory of the repository being synced. The core problem was fnames = [] which creates a new list instead of del fnames [:] which modifies the list in place. > 2. Added a new parameter to repos (--createrepo-flags) to be used for passing useful flags like "-c cache -C -g repodata/comps.xml" when createrepo is called. This touched a few of the python scripts. > 3. Modified createrepo in action_import to use the -c cache flag so that future syncs using this repo don't have to regenerate everything. > > Please let me know if you have any comments on any of the above changes. > > Signed-off-by: Perry Myers (pmyers at redhat.com) > > Thanks, > > Perry > > Applied, thanks! I've also added "-c cache" as a default for the --createrepo-flags option, and have updated the manpage. --Michael From pmyers at redhat.com Thu Jun 7 18:35:27 2007 From: pmyers at redhat.com (Perry Myers) Date: Thu, 07 Jun 2007 14:35:27 -0400 Subject: [et-mgmt-tools] [PATCH] cobbler - add arch to repo definition to override default arch for reposync Message-ID: <46684FEF.3020303@redhat.com> For using cobbler to synchronize repositories via reposync, the default arch is always used which makes syncing with multiple arches not possible. (For example to grab the src repos) To change this I added a --arch flag that can be used to override the default reposync arch. If yumdownloader is used (in the case of using rpm_list to restrict the packages downloaded) --source is passed on the command line if --arch==src. This allows source packages to be retrieved, but I don't know how to override yumdownloader to do architectures other than the current system arch. Comments on this appreciated... Signed-off-by: Perry Myers (pmyers at redhat.com) Thanks, Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 703 362 9622 -=| diff --git a/cobbler/action_reposync.py b/cobbler/action_reposync.py index 76e673f..fdcf270 100644 --- a/cobbler/action_reposync.py +++ b/cobbler/action_reposync.py @@ -119,9 +119,11 @@ class RepoSync: temp_file = self.create_local_file(repo, temp_path, output=False) if not has_rpm_list: - # if we have not requested only certain RPMs, use reposync cmd = "/usr/bin/reposync --config=%s --repoid=%s --download_path=%s" % (temp_file, repo.name, store_path) + if repo.arch != "": + cmd = "%s -a %s" % (cmd, repo.arch) + print _("- %s") % cmd cmds.append(cmd) @@ -131,10 +133,14 @@ class RepoSync: if not os.path.exists(dest_path): os.makedirs(dest_path) + use_source = "" + if repo.arch == "src": + use_source = "--source" + # if we only want certain RPMs, use yumdownloader (likely more than once) # FIXME: yumdownloader has a current bug where --resolve blows up # removing --resolve until I get the email from bugzilla saying it's fixed. - cmd = "/usr/bin/yumdownloader -c %s --destdir=%s %s" %(temp_file, dest_path, " ".join(repo.rpm_list)) + cmd = "/usr/bin/yumdownloader %s -c %s --destdir=%s %s" % (use_source, temp_file, dest_path, " ".join(repo.rpm_list)) print _("- %s") % cmd cmds.append(cmd) else: @@ -146,6 +152,10 @@ class RepoSync: print _("- warning: --rpm-list is not supported for RHN content") rest = repo.mirror[6:] # everything after rhn:// cmd = "/usr/bin/reposync -r %s --download_path=%s" % (rest, store_path) + + if repo.arch != "": + cmd = "%s -a %s" % (cmd, repo.arch) + print _("- %s") % cmd cmds.append(cmd) diff --git a/cobbler/cobbler.py b/cobbler/cobbler.py index e999d2d..e275f39 100755 --- a/cobbler/cobbler.py +++ b/cobbler/cobbler.py @@ -433,7 +433,8 @@ class BootCLI: '--keep-updated' : lambda(a): repo.set_keep_updated(a), '--local-filename' : lambda(a): repo.set_local_filename(a), '--rpm-list' : lambda(a): repo.set_rpm_list(a), - '--createrepo-flags' : lambda(a): repo.set_createrepo_flags(a) + '--createrepo-flags' : lambda(a): repo.set_createrepo_flags(a), + '--arch' : lambda(a): repo.set_arch(a) } def on_ok(): if newname is not None: diff --git a/cobbler/item_repo.py b/cobbler/item_repo.py index f58cd1b..bdd1a48 100644 --- a/cobbler/item_repo.py +++ b/cobbler/item_repo.py @@ -31,7 +31,8 @@ class Repo(item.Item): self.keep_updated = 1 # has reasonable defaults self.local_filename = "" # off by default self.rpm_list = "" # just get selected RPMs + deps - self.createrepo_flags = "-c cache" # none by default + self.createrepo_flags = "-c cache" # turn on cache by default for performance + self.arch = "" # use default arch def from_datastruct(self,seed_data): self.name = self.load_item(seed_data, 'name') @@ -40,6 +41,7 @@ class Repo(item.Item): self.local_filename = self.load_item(seed_data, 'local_filename') self.rpm_list = self.load_item(seed_data, 'rpm_list') self.createrepo_flags = self.load_item(seed_data, 'createrepo_flags', '-c cache') + self.arch = self.load_item(seed_data, 'arch') return self def set_name(self,name): @@ -108,6 +110,13 @@ class Repo(item.Item): self.createrepo_flags = createrepo_flags return True + def set_arch(self,arch): + """ + Override the arch used for reposync + """ + self.arch = arch + return True + def is_valid(self): """ A repo is valid if it has a name and a mirror URL @@ -125,7 +134,8 @@ class Repo(item.Item): 'keep_updated' : self.keep_updated, 'local_filename' : self.local_filename, 'rpm_list' : self.rpm_list, - 'createrepo_flags' : self.createrepo_flags + 'createrepo_flags' : self.createrepo_flags, + 'arch' : self.arch } def printable(self): @@ -135,6 +145,7 @@ class Repo(item.Item): buf = buf + _("local filename : %s\n") % self.local_filename buf = buf + _("rpm list : %s\n") % self.rpm_list buf = buf + _("createrepo_flags : %s\n") % self.createrepo_flags + buf = buf + _("arch : %s\n") % self.arch return buf def is_rsync_mirror(self): From mdehaan at redhat.com Thu Jun 7 18:50:00 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 07 Jun 2007 14:50:00 -0400 Subject: [et-mgmt-tools] [PATCH] cobbler - add arch to repo definition to override default arch for reposync In-Reply-To: <46684FEF.3020303@redhat.com> References: <46684FEF.3020303@redhat.com> Message-ID: <46685358.4010906@redhat.com> Perry Myers wrote: > For using cobbler to synchronize repositories via reposync, the default arch is always used which makes syncing with multiple arches not possible. (For example to grab the src repos) > > To change this I added a --arch flag that can be used to override the default reposync arch. If yumdownloader is used (in the case of using rpm_list to restrict the packages downloaded) --source is passed on the command line if --arch==src. This allows source packages to be retrieved, but I don't know how to override yumdownloader to do architectures other than the current system arch. Comments on this appreciated... > > Signed-off-by: Perry Myers (pmyers at redhat.com) > > Thanks, > > Perry > > This looks good to me (thanks again) ... can you also submit a patch for docs/cobbler.pod (which is the manpage src) that describes when to use --arch (see the place where I've added docs for --createrepo-flags)? It may be possible to control yumdownloader by editing the configuration files for the repos (stored in the ".origin" directory), ex: /var/www/cobbler/repo_mirror/.origin/fc6i386extras.repo ... I'm not entirely sure. --Michael From pmyers at redhat.com Thu Jun 7 19:17:42 2007 From: pmyers at redhat.com (Perry Myers) Date: Thu, 07 Jun 2007 15:17:42 -0400 Subject: [et-mgmt-tools] [PATCH] cobbler - add arch to repo definition to override default arch for reposync In-Reply-To: <46685358.4010906@redhat.com> References: <46684FEF.3020303@redhat.com> <46685358.4010906@redhat.com> Message-ID: <466859D6.6010008@redhat.com> Michael DeHaan wrote: > This looks good to me (thanks again) ... can you also submit a patch for > docs/cobbler.pod (which is the manpage src) that describes when to use > --arch (see the place where I've added docs for --createrepo-flags)? Here is the additional patch to update the pod. Let me know if I did that wrong. Never worked with pod files before... :) Signed-off-by: Perry Myers (pmyers at redhat.com) Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 703 362 9622 -=| diff --git a/docs/cobbler.pod b/docs/cobbler.pod index 4192c19..5826710 100644 --- a/docs/cobbler.pod +++ b/docs/cobbler.pod @@ -263,6 +263,12 @@ mirror types, such as local paths and rsync:// mirrors. Specifies optional flags to feed into the createrepo tool, which is called when "cobbler reposync" is run for the given repository. The defaults are '-c cache'. +=item arch + +Specifies what architecture the repository should use. By default the current system arch is used when +"cobbler reposync" is called. Using this to override the default arch allows mirroring of source +repositories (using --arch=src) + =back =head2 DISPLAYING CONFIGURATION ENTRIES From berrange at redhat.com Thu Jun 7 19:24:04 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 7 Jun 2007 20:24:04 +0100 Subject: [et-mgmt-tools] [PATCH] cobbler - add arch to repo definition to override default arch for reposync In-Reply-To: <466859D6.6010008@redhat.com> References: <46684FEF.3020303@redhat.com> <46685358.4010906@redhat.com> <466859D6.6010008@redhat.com> Message-ID: <20070607192403.GK2119@redhat.com> On Thu, Jun 07, 2007 at 03:17:42PM -0400, Perry Myers wrote: > Michael DeHaan wrote: > > This looks good to me (thanks again) ... can you also submit a patch for > > docs/cobbler.pod (which is the manpage src) that describes when to use > > --arch (see the place where I've added docs for --createrepo-flags)? > > Here is the additional patch to update the pod. Let me know if I > did that wrong. Never worked with pod files before... :) 'man perlpod' will tell you all you need to know - it generally pretty good and simple for DWIM formatting. > diff --git a/docs/cobbler.pod b/docs/cobbler.pod > index 4192c19..5826710 100644 > --- a/docs/cobbler.pod > +++ b/docs/cobbler.pod > @@ -263,6 +263,12 @@ mirror types, such as local paths and rsync:// mirrors. > Specifies optional flags to feed into the createrepo tool, which is called when "cobbler reposync" is run for the > given repository. The defaults are '-c cache'. > > +=item arch > + > +Specifies what architecture the repository should use. By default the current system arch is used when > +"cobbler reposync" is called. Using this to override the default arch allows mirroring of source > +repositories (using --arch=src) Typically wrap command lines in 'C<..>' eg C to make them monospaced font when POD is convereted to HTML 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 pmyers at redhat.com Thu Jun 7 19:51:18 2007 From: pmyers at redhat.com (Perry Myers) Date: Thu, 07 Jun 2007 15:51:18 -0400 Subject: [et-mgmt-tools] [PATCH] cobbler - add arch to repo definition to override default arch for reposync In-Reply-To: <20070607192403.GK2119@redhat.com> References: <46684FEF.3020303@redhat.com> <46685358.4010906@redhat.com> <466859D6.6010008@redhat.com> <20070607192403.GK2119@redhat.com> Message-ID: <466861B6.2090907@redhat.com> Dan and Michael: Daniel P. Berrange wrote: > Typically wrap command lines in 'C<..>' eg C to make > them monospaced font when POD is convereted to HTML Thanks for the info. Let me know if this is what you're talking about. The HTML pages generated did have monospaced fonts in the places that I wanted. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 703 362 9622 -=| diff --git a/docs/cobbler.pod b/docs/cobbler.pod index 4192c19..7cb7ba8 100644 --- a/docs/cobbler.pod +++ b/docs/cobbler.pod @@ -199,7 +199,7 @@ on your network will result in faster, more up-to-date installations and faster are only provisioning a home setup, this will probably be overkill, though it can be very useful for larger setups (labs, datacenters, etc). -B +B =over @@ -260,8 +260,14 @@ mirror types, such as local paths and rsync:// mirrors. =item createrepo-flags -Specifies optional flags to feed into the createrepo tool, which is called when "cobbler reposync" is run for the -given repository. The defaults are '-c cache'. +Specifies optional flags to feed into the createrepo tool, which is called when C is run for the +given repository. The defaults are C<-c cache>. + +=item arch + +Specifies what architecture the repository should use. By default the current system arch is used when +C is called. Using this to override the default arch allows mirroring of source +repositories (using C<--arch=src>) =back From rick.vinyard at gmail.com Thu Jun 7 20:00:12 2007 From: rick.vinyard at gmail.com (Rick Vinyard) Date: Thu, 7 Jun 2007 14:00:12 -0600 Subject: [et-mgmt-tools] cobbler Message-ID: Is there currently a bug in cobbler? Trying a cobbler import on F7-i386 results in a python type error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Thu Jun 7 20:06:02 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 07 Jun 2007 16:06:02 -0400 Subject: [et-mgmt-tools] cobbler In-Reply-To: References: Message-ID: <4668652A.9010808@redhat.com> Rick Vinyard wrote: > Is there currently a bug in cobbler? > > Trying a cobbler import on F7-i386 results in a python type error. > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Please post the full command line used and the traceback, plus what cobbler version you are using. Thanks, Michael From rick.vinyard at gmail.com Thu Jun 7 20:17:55 2007 From: rick.vinyard at gmail.com (Rick Vinyard) Date: Thu, 7 Jun 2007 14:17:55 -0600 Subject: [et-mgmt-tools] cobbler In-Reply-To: <4668652A.9010808@redhat.com> References: <4668652A.9010808@redhat.com> Message-ID: Tried cobbler rpms 0.4.8-1 and 0.4.7-5 with identical results. $ mount -o loop F-7-x86_64-DVD.iso tmpmount $ cobbler import --name=F-7-x86_64 --mirror=tmpmount Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line 636, in main BootCLI(sys.argv).run() File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line 37, in __init__ self.api = api.BootAPI() File "/usr/lib/python2.5/site-packages/cobbler/api.py", line 41, in __init__ self.deserialize() File "/usr/lib/python2.5/site-packages/cobbler/api.py", line 171, in deserialize return self._config.deserialize() File "/usr/lib/python2.5/site-packages/cobbler/config.py", line 158, in deserialize if not serializer.deserialize(x): File "/usr/lib/python2.5/site-packages/cobbler/serializer.py", line 69, in deserialize datastruct = yaml.load(data).next() # first record File "/usr/lib/python2.5/site-packages/cobbler/yaml/load.py", line 83, in next self.nestedDocs.nestToNextLine() File "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line 131, in nestToNextLine indentation = indentLevel(line) File "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line 6, in indentLevel while n < len(line) and line[n] == ' ': TypeError: object of type 'NoneType' has no len() $ On 6/7/07, Michael DeHaan wrote: > > Rick Vinyard wrote: > > Is there currently a bug in cobbler? > > > > Trying a cobbler import on F7-i386 results in a python type error. > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > Please post the full command line used and the traceback, plus what > cobbler version you are using. > > Thanks, > > 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 mdehaan at redhat.com Thu Jun 7 20:27:48 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 07 Jun 2007 16:27:48 -0400 Subject: [et-mgmt-tools] cobbler In-Reply-To: References: <4668652A.9010808@redhat.com> Message-ID: <46686A44.7030009@redhat.com> Rick Vinyard wrote: > Tried cobbler rpms 0.4.8-1 and 0.4.7-5 with identical results. > > $ mount -o loop F-7-x86_64-DVD.iso tmpmount > $ cobbler import --name=F-7-x86_64 --mirror=tmpmount > Traceback (most recent call last): > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line > 636, in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line 37, > in __init__ > self.api = api.BootAPI() > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line 41, in > __init__ > self.deserialize() > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line 171, in > deserialize > return self._config.deserialize() > File "/usr/lib/python2.5/site-packages/cobbler/config.py", line 158, > in deserialize > if not serializer.deserialize(x): > File "/usr/lib/python2.5/site-packages/cobbler/serializer.py", line > 69, in deserialize > datastruct = yaml.load(data).next() # first record > File "/usr/lib/python2.5/site-packages/cobbler/yaml/load.py", line > 83, in next > self.nestedDocs.nestToNextLine() > File "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > 131, in nestToNextLine > indentation = indentLevel(line) > File "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > 6, in indentLevel > while n < len(line) and line[n] == ' ': > TypeError: object of type 'NoneType' has no len() > $ > > On 6/7/07, *Michael DeHaan* > wrote: > > Rick Vinyard wrote: > > Is there currently a bug in cobbler? > > > > Trying a cobbler import on F7-i386 results in a python type error. > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > Please post the full command line used and the traceback, plus what > cobbler version you are using. > > Thanks, > > Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools This error appears to be due to something in the config files themselves confusing the YAML deserializer. If you can tar up and send me /var/lib/cobbler/* off list, I'll check it out. I actually only need /var/lib/cobbler/{settings|repos|profiles|distros|systems} so you can skip the other files if you like. Also it would be helpful to know if this was a clean install or an upgrade. --Michael From rick.vinyard at gmail.com Thu Jun 7 20:44:43 2007 From: rick.vinyard at gmail.com (Rick Vinyard) Date: Thu, 7 Jun 2007 14:44:43 -0600 Subject: [et-mgmt-tools] cobbler In-Reply-To: <46686A44.7030009@redhat.com> References: <4668652A.9010808@redhat.com> <46686A44.7030009@redhat.com> Message-ID: Upgrade from FC-6 to F-7. On 6/7/07, Michael DeHaan wrote: > > Rick Vinyard wrote: > > Tried cobbler rpms 0.4.8-1 and 0.4.7-5 with identical results. > > > > $ mount -o loop F-7-x86_64-DVD.iso tmpmount > > $ cobbler import --name=F-7-x86_64 --mirror=tmpmount > > Traceback (most recent call last): > > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line > > 636, in main > > BootCLI(sys.argv).run() > > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line 37, > > in __init__ > > self.api = api.BootAPI() > > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line 41, in > > __init__ > > self.deserialize() > > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line 171, in > > deserialize > > return self._config.deserialize() > > File "/usr/lib/python2.5/site-packages/cobbler/config.py", line 158, > > in deserialize > > if not serializer.deserialize(x): > > File "/usr/lib/python2.5/site-packages/cobbler/serializer.py", line > > 69, in deserialize > > datastruct = yaml.load(data).next() # first record > > File "/usr/lib/python2.5/site-packages/cobbler/yaml/load.py", line > > 83, in next > > self.nestedDocs.nestToNextLine() > > File "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > > 131, in nestToNextLine > > indentation = indentLevel(line) > > File "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > > 6, in indentLevel > > while n < len(line) and line[n] == ' ': > > TypeError: object of type 'NoneType' has no len() > > $ > > > > On 6/7/07, *Michael DeHaan* > > wrote: > > > > Rick Vinyard wrote: > > > Is there currently a bug in cobbler? > > > > > > Trying a cobbler import on F7-i386 results in a python type error. > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > et-mgmt-tools mailing list > > > et-mgmt-tools at redhat.com > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > Please post the full command line used and the traceback, plus what > > cobbler version you are using. > > > > Thanks, > > > > Michael > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > This error appears to be due to something in the config files themselves > confusing the YAML deserializer. If you can tar up and send me > /var/lib/cobbler/* off list, I'll check it out. I actually only need > /var/lib/cobbler/{settings|repos|profiles|distros|systems} so you can > skip the other files if you like. > > Also it would be helpful to know if this was a clean install or an > upgrade. > > --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 fj1826dm at aa.jp.fujitsu.com Fri Jun 8 05:16:22 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Fri, 8 Jun 2007 14:16:22 +0900 Subject: [et-mgmt-tools] [PATCH] Fix connection with the console when thedomain is created In-Reply-To: <20070607124857.GB2119@redhat.com> References: <200706071500.ECC64042.K23EN9G7@aa.jp.fujitsu.com> <20070607124857.GB2119@redhat.com> Message-ID: <200706081416.IIE65182.2G7KNE39@aa.jp.fujitsu.com> Hi, Dan Thank you for reviewing. > The console code already has support for auto-connecting to the console > with retries. When popping up the console it will retry after 125 ms, > 250ms, 500ms, 1s, 2s and then every 2s upto 10 times. > Oops, I forgot that the connection to the console is retried in "console.py". > I'm interested to know what this isn't working for you ? Check the log > file /root/.virt-manager/virt-manager.log which should show you messages > every time it tries to open the console. The code for re-trying the console > connection is in src/virtManager/console.py in the try_login() method. > I thought that the following is the problem. ---------------------------------------------------------------------- In finish() of "create.py", the port number of VNC become -1. When "Status monitoring" is short, the port number of VNC is updated in a short time, but, when "Status monitoring" is long, the port number of VNC is not updated for a long time. Because the XML data cached in "domain.py" is updated only in tick(). ---------------------------------------------------------------------- And, I forgot retrying in "console.py". Therefore, I adopted updating the port number of VNC in "cerate.py". I remake the patch. This patch only clears XML in get_graphics_console(), and the connection to the console is not retried in "create.py". So, by applying this patch, the XML data is cleared by retrying in "console.py" even when "Status monitoring" is long, and the port number of VNC is updated. (Because retrying in "console.py" calls get_graphics_console()) Thanks, Masayuki Sunou. ---------------------------------------------------------------------- diff -r 27ad8c7fbc3e src/virtManager/domain.py --- a/src/virtManager/domain.py Thu May 24 16:49:13 2007 -0400 +++ b/src/virtManager/domain.py Sat Jun 09 11:44:54 2007 +0900 @@ -430,6 +430,7 @@ class vmmDomain(gobject.GObject): return os.access(tty, os.R_OK | os.W_OK) def get_graphics_console(self): + self.xml = None type = self.get_xml_string("/domain/devices/graphics/@type") port = None if type == "vnc": ---------------------------------------------------------------------- In message <20070607124857.GB2119 at redhat.com> "Re: [et-mgmt-tools] [PATCH] Fix connection with the console when thedomain is created" ""Daniel P. Berrange" " wrote: > On Thu, Jun 07, 2007 at 03:00:58PM +0900, Masayuki Sunou wrote: > > Hi > > > > When virt-mangager is set the following configuration and VM is created, > > the console is not displayed automatically long time. > > (it displays "The console is currently unavailable") > > > > 1. Set "Status monitoring" to long time.(ex: 60 seconds). > > 2. Set "Automatically open consoles" to "For new domains". > > > > This patch fixes it by waiting start of the console.(like virt-install) > > This is bad - you can't have a while loop which sits for 5 seconds in an > even handler in GTK because it will block all UI events from running. > > > Note: > > # 5 seconds, .25 second sleeps > > --> 5 : Virt-manager waits only for short time.(5 seconds) > > Because virt-manager have a means to connect with a console > > easily again. (unlike virt-install) > > The console code already has support for auto-connecting to the console > with retries. When popping up the console it will retry after 125 ms, > 250ms, 500ms, 1s, 2s and then every 2s upto 10 times. > > I'm interested to know what this isn't working for you ? Check the log > file /root/.virt-manager/virt-manager.log which should show you messages > every time it tries to open the console. The code for re-trying the console > connection is in src/virtManager/console.py in the try_login() method. > > 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 fj0588di at aa.jp.fujitsu.com Fri Jun 8 05:41:23 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Fri, 8 Jun 2007 14:41:23 +0900 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting whenvirt-managercreates VM In-Reply-To: <200705311822.JEJ86930.0JK9G96E@aa.jp.fujitsu.com> References: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> <20070524014100.GC21564@redhat.com> <200705291644.JHC35443.96JEGK09@aa.jp.fujitsu.com> <20070530031136.GA15129@redhat.com> <200705311822.JEJ86930.0JK9G96E@aa.jp.fujitsu.com> Message-ID: <200706081441.GID09350.90EGJK69@aa.jp.fujitsu.com> Hi, Dan Would you give me a comment? --- The summary of last time --- The user who wants to manage GUEST from port number 9000 does not use the virt-manager if it cannot choose a port at the time of use when he introduce GUEST. Even if the virt-manager is no matter how convenient, this user will avoid use of the virt-manager because it forces him to allocate from 5600- . How do you think about this problem? I think that this user is not niche! -------------------------------- thanks, Shigeki Sakamoto. <200705311822.JEJ86930.0JK9G96E at aa.jp.fujitsu.com> ?? "Re: [et-mgmt-tools] [PATCH] Add VNC-Port setting whenvirt-managercreates VM" ????? ""S.Sakamoto" "????????? > Hi > > An advantage of the fixed port which I want to insist on is "A user can choose an arbitrary port.". > Neither remote-connection nor authentication matters particularly. It is a story before it. > The reason why this user comes to need choice of a fixed port is as follows. > > > If an user absolutely use the port number from 5900, either does not surely matter. > But, > for example, > when the port number 5900-5920 is used by other uses, > when there is a user hoping that I manage a port number by use to assign from 9000, > > A fxed port selection mode is necessary, because there is these situation. > (The person who does not need a fixed port should choose an auto selection mode.) > Any users will not hope to change other designs to use it for auto selection. > > > Thanks, > Shigeki Sakamoto. > > > > > On Tue, May 29, 2007 at 04:44:15PM +0900, S.Sakamoto wrote: > > > Hi, Dan > > > > > > Thanks for your comment. > > > > > > > It will prove unreliable in practice, because even if you > > > > fix a particular guest on port 5905, any other guest doing dynamic VNC port > > > > assignment may choose this port before the hardcoded guest starts. > > > This situation is surely thought. > > > But, I think that problem is solved > > > if it performs a repetition check of a port number in virt-inst. > > > When it is this situation, at first, > > > examine the port number that all other guests use when it starts a guest. > > > Next, If the port number is fixed and repetition, > > > output a message. [e.g."Repetition. Set a different port number."] > > > (However, there is not a function setting a port for an existing guest now. > > > If it is necessary at the same time, > > > I make 'check of repetition' and 'function setting a port for an existing guest'.) > > > > > > > It is not going to be easy for virt-manager to do validation of this port number > > > > either, since in the near future virt-manager may well be running remotely > > > > from the host. > > > If it adds a revision to libvirt side to get a port number from the information that acquired from xend, > > > the acquisition of a port number will be easy. > > > > > > > this is a very small niche usecase > > > I do not think so. and I think that there is a person to need surely. > > > Because, I think that it can perform the prevention / maintenance > > > by the pair of guest and port-number are managed. > > > For example, The person who thinks about maintenance for the port which opened out > > > had better be a fixed port number. > > > If it does't know whether it has already opened or it will open out from now on, > > > it will become difficult to deal with possibility of attack to an opening port. > > > Therefore, > > > the user who wants to open only a specific port for a firewall needs to fixed port number. > > > And, even if it can get a dynamic port from remote connection in the future, > > > he needs a fixed port number at the time of remote connection too, > > > because he wants to connection with only a specific port. > > > > There's two possibilities to consider: > > > > a. The admin of the Dom0 permanently opens up a range of ports (eg 5900->5920) to allow > > upto 20 vms to have their console accessed at any time. In this case, whether you > > use fixed or dynamic ports per VM, you still need 20 ports open, to run 20 consoles. > > > > b. The admin of the Dom0 only opens specific ports for short periods of time. In this > > case the admin will have to lookup what port corresponds to a VM, so it doesn't matter > > whether we're using fixed or dynamic ports, the admin still has same amount of work > > to lookup a port. > > > > So, I still don't see that using fixed ports in virt-manager has any benefit for the > > administration POV. > > > > Neither of these two options are entirely satisfactory though - it would be desirable > > to only open up a port when explicitly needed, and not require the admin to do any > > work. One might even suggest that libvirt should have some form of API to let the > > remote user request access to the cosnole - authenticated of course > > > > > > virDomainAllowConsole(virDomainPtr, const char *ipaddr); > > virDomainDisallowConsole(virDomainPtr, const char *ipaddr); > > > > Calling either of these functions would add neccessary iptables rule to allow > > access to the console for that particular domain, from the specified ip address. > > When the virConnectPtr object was closed, then any rules would also automatically > > be removed. > > > > This would allow virt-manager to securely request access to the console without > > needing permanent iptables rules. > > > > These's probably quite a bit more to think about wrt to iptables, consoles > > and seecure authentication. In the very near future libvirt will have the > > support for remote management merged and we'll be in a position to experiment > > with these ideas for real. So I don't think we want to add support for fixed > > port numbers in the virt-manager wizard until we've tried out some of these > > ideas. > > > > 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 fj1826dm at aa.jp.fujitsu.com Fri Jun 8 07:57:37 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Fri, 8 Jun 2007 16:57:37 +0900 Subject: [et-mgmt-tools] [PATCH] In virt-manager GUI, when the disk is added, VM cannot be started. Message-ID: <200706081657.EBD09820.N73KGE29@aa.jp.fujitsu.com> Hi When the disk is added to active VM by virt-manager, VM cannot be restarted after VM is stopped. --> Bugzilla Bug 239763 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239763 This patch fixes it. When the device is attached to active VM, virt-manager adds the device twice in add_device() of "domain.py". 1. Call attachDevice() 2. Call define_domain() after the XML is updated Therefore, the same device is doubly attached. (So, when the device is disk, VM cannot be started) This patch fixes "domain.py" as follows so that the same device is not doubly attached. VM is active : Call attachDevice() only VM is inactive : Call define_domain() after the XML is updated Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. ---------------------------------------------------------------------- diff -r 27ad8c7fbc3e src/virtManager/domain.py --- a/src/virtManager/domain.py Thu May 24 16:49:13 2007 -0400 +++ b/src/virtManager/domain.py Sat Jun 09 14:45:20 2007 +0900 @@ -540,15 +540,15 @@ class vmmDomain(gobject.GObject): if self.is_active(): self.vm.attachDevice(xml) - - vmxml = self.vm.XMLDesc(0) - - index = vmxml.find("") - newxml = vmxml[0:index] + xml + vmxml[index:] - - logging.debug("Redefine with " + newxml) - - self.get_connection().define_domain(newxml) + else: + vmxml = self.vm.XMLDesc(0) + + index = vmxml.find("") + newxml = vmxml[0:index] + xml + vmxml[index:] + + logging.debug("Redefine with " + newxml) + + self.get_connection().define_domain(newxml) def remove_device(self, dev_xml): logging.debug("Removing device " + dev_xml) From berrange at redhat.com Fri Jun 8 11:25:05 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 8 Jun 2007 12:25:05 +0100 Subject: [et-mgmt-tools] [PATCH] Fix connection with the console when thedomain is created In-Reply-To: <200706081416.IIE65182.2G7KNE39@aa.jp.fujitsu.com> References: <200706071500.ECC64042.K23EN9G7@aa.jp.fujitsu.com> <20070607124857.GB2119@redhat.com> <200706081416.IIE65182.2G7KNE39@aa.jp.fujitsu.com> Message-ID: <20070608112505.GB2473@redhat.com> On Fri, Jun 08, 2007 at 02:16:22PM +0900, Masayuki Sunou wrote: > Hi, Dan > > Thank you for reviewing. > > > The console code already has support for auto-connecting to the console > > with retries. When popping up the console it will retry after 125 ms, > > 250ms, 500ms, 1s, 2s and then every 2s upto 10 times. > > > Oops, I forgot that the connection to the console is retried in "console.py". > > > > I'm interested to know what this isn't working for you ? Check the log > > file /root/.virt-manager/virt-manager.log which should show you messages > > every time it tries to open the console. The code for re-trying the console > > connection is in src/virtManager/console.py in the try_login() method. > > > I thought that the following is the problem. > > ---------------------------------------------------------------------- > In finish() of "create.py", the port number of VNC become -1. > When "Status monitoring" is short, the port number of VNC is updated > in a short time, but, when "Status monitoring" is long, the port number > of VNC is not updated for a long time. > Because the XML data cached in "domain.py" is updated only in tick(). > ---------------------------------------------------------------------- Ahh that does make sense now. > I remake the patch. > This patch only clears XML in get_graphics_console(), and the connection > to the console is not retried in "create.py". > So, by applying this patch, the XML data is cleared by retrying in "console.py" > even when "Status monitoring" is long, and the port number of VNC is updated. > (Because retrying in "console.py" calls get_graphics_console()) A bit of a hack clearing the cache XML here, but probably the best way to do it anyway. 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 Jun 8 11:33:04 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 8 Jun 2007 12:33:04 +0100 Subject: [et-mgmt-tools] [PATCH] In virt-manager GUI, when the disk is added, VM cannot be started. In-Reply-To: <200706081657.EBD09820.N73KGE29@aa.jp.fujitsu.com> References: <200706081657.EBD09820.N73KGE29@aa.jp.fujitsu.com> Message-ID: <20070608113304.GC2473@redhat.com> On Fri, Jun 08, 2007 at 04:57:37PM +0900, Masayuki Sunou wrote: > Hi > > When the disk is added to active VM by virt-manager, VM cannot be > restarted after VM is stopped. > --> Bugzilla Bug 239763 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239763 > > This patch fixes it. > > When the device is attached to active VM, virt-manager adds the device > twice in add_device() of "domain.py". > 1. Call attachDevice() > 2. Call define_domain() after the XML is updated > Therefore, the same device is doubly attached. > (So, when the device is disk, VM cannot be started) > > This patch fixes "domain.py" as follows so that the same device is not > doubly attached. > VM is active : Call attachDevice() only It is implementation defined whether attachDevice() persists te changes it makes. In Xen 3.1.0 it happens to persist them, but in earlier Xen it does not. So we still need to use define_domain as well. > VM is inactive : Call define_domain() after the XML is updated > > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. > > ---------------------------------------------------------------------- > diff -r 27ad8c7fbc3e src/virtManager/domain.py > --- a/src/virtManager/domain.py Thu May 24 16:49:13 2007 -0400 > +++ b/src/virtManager/domain.py Sat Jun 09 14:45:20 2007 +0900 > @@ -540,15 +540,15 @@ class vmmDomain(gobject.GObject): > > if self.is_active(): > self.vm.attachDevice(xml) > - > - vmxml = self.vm.XMLDesc(0) The key is that we should be calling vm.XMLDesc(0) before the call to attachDevice() so we get the original XML prior to any device addition. I'll add such a fix. 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 lippold at gmail.com Fri Jun 8 12:22:20 2007 From: lippold at gmail.com (Aaron Lippold) Date: Fri, 8 Jun 2007 14:22:20 +0200 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files Message-ID: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> Hi All, I am having issues with cobbler and importing a ks file of mine. All is well with the simple parts of the %post section, but when I get to a bit of scripting, the Cheetah parser complains at '" \/home " ${FSTAB} ' etc. How can I escape this section or something? Thanks, Aaron ----- code below ---- # GEN002420 FSTAB=/etc/fstab SED=/bin/sed # nosuid on /home if [ $(grep " \/home " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} fi # nosuid on /sys if [ $(grep " \/sys " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then MNT_OPTS=$(grep " \/sys " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/sys.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} fi # nosuid on /boot if [ $(grep " \/boot " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then MNT_OPTS=$(grep " \/boot " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/boot.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} fi # nodev on /usr if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi #nodev on /home if [ $(grep " \/home " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /usr if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /usr/local if [ $(grep " \/usr\/local " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/usr\/local " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/usr\/local.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /tmp if [ $(grep " \/tmp " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/tmp " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /var if [ $(grep " \/var " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/var " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/var.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # GEN003080 From lippold at gmail.com Fri Jun 8 14:07:46 2007 From: lippold at gmail.com (Aaron Lippold) Date: Fri, 8 Jun 2007 16:07:46 +0200 Subject: [et-mgmt-tools] Re: Cobbler, Cheetah and scripts in KS files In-Reply-To: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> Message-ID: <39d2723b0706080707v150410d5g6fa19bf20029bea6@mail.gmail.com> Hello, I attached the error output I am getting as well when I totally removed the above ( previous mail in thread ) section. So I am not sure where the problem is. Thanks, Aaron On 6/8/07, Aaron Lippold wrote: > Hi All, > > I am having issues with cobbler and importing a ks file of mine. All > is well with the simple parts of the %post section, but when I get to > a bit of scripting, the Cheetah parser complains at '" \/home " > ${FSTAB} ' etc. > > How can I escape this section or something? > > Thanks, > > Aaron > > ----- code below ---- > > # GEN002420 > > FSTAB=/etc/fstab > SED=/bin/sed > # nosuid on /home > if [ $(grep " \/home " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > fi > > # nosuid on /sys > if [ $(grep " \/sys " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > MNT_OPTS=$(grep " \/sys " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/sys.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > fi > > # nosuid on /boot > if [ $(grep " \/boot " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > MNT_OPTS=$(grep " \/boot " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/boot.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > fi > > # nodev on /usr > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > #nodev on /home > if [ $(grep " \/home " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /usr > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /usr/local > if [ $(grep " \/usr\/local " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/usr\/local " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/usr\/local.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /tmp > if [ $(grep " \/tmp " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/tmp " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /var > if [ $(grep " \/var " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/var " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/var.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > # GEN003080 > -------------- next part -------------- [root at localhost work]# cobbler profile add --distro=RHEL5.0-Desktop-i386 --name=x --kickstart=/work/rhel5-baseline-2.txt Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 279, in validate_kickstart_for_specific_profile self.apply_template(kfile, meta, dest) File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 406, in apply_template t = Template(source=data, searchList=[metadata]) File "/usr/lib/python2.4/site-packages/Cheetah/Template.py", line 1200, in __init__ self._compile(source, file, compilerSettings=compilerSettings) File "/usr/lib/python2.4/site-packages/Cheetah/Template.py", line 1488, in _compile keepRefToGeneratedCode=True) File "/usr/lib/python2.4/site-packages/Cheetah/Template.py", line 716, in compile compiler.compile() File "/usr/lib/python2.4/site-packages/Cheetah/Compiler.py", line 1643, in compile self._parser.parse() File "/usr/lib/python2.4/site-packages/Cheetah/Parser.py", line 1445, in parse self.assertEmptyOpenDirectivesStack() File "/usr/lib/python2.4/site-packages/Cheetah/Parser.py", line 2554, in assertEmptyOpenDirectivesStack raise ParseError(self, msg=errorMsg) ParseError: Some #directives are missing their corresponding #end ___ tag: for, for Line 755, column 65 Line|Cheetah Code ----|------------------------------------------------------------- 752 |find /var/log/ -type f -not -perm 644 -exec chmod 644 {} \; 753 | 754 |# GEN001280 755 |find /usr/share/man -type f -not -perm 644 -exec chmod 644 {} \; From mdehaan at redhat.com Fri Jun 8 14:41:26 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 08 Jun 2007 10:41:26 -0400 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files In-Reply-To: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> Message-ID: <46696A96.5050902@redhat.com> Aaron Lippold wrote: > Hi All, > > I am having issues with cobbler and importing a ks file of mine. All > is well with the simple parts of the %post section, but when I get to > a bit of scripting, the Cheetah parser complains at '" \/home " > ${FSTAB} ' etc. > > How can I escape this section or something? > > Thanks, > > Aaron Dollar signs need to be escaped with \$ since Cheetah is viewing the shell invocations as Cheetah code. This is not true of something like $foosball, where it will just say as "$foosball" if there is no key, but for something like ${foosball}, then yes, it must be escaped. Unfortunate, I agree. If anyone has any suggestions on better templating libraries that don't require something heinous like Kid's XML, I'm all ears. Templating systems all appear to have their ups and downs, which is apparently why everyone seems to write their own. That's an option too, but I'm trying to not go there :) --Michael From mdehaan at redhat.com Fri Jun 8 16:15:51 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 08 Jun 2007 12:15:51 -0400 Subject: [et-mgmt-tools] cobbler In-Reply-To: References: <4668652A.9010808@redhat.com> <46686A44.7030009@redhat.com> Message-ID: <466980B7.9080403@redhat.com> Rick Vinyard wrote: > Upgrade from FC-6 to F-7. > > On 6/7/07, *Michael DeHaan* > wrote: > > Rick Vinyard wrote: > > Tried cobbler rpms 0.4.8-1 and 0.4.7-5 with identical results. > > > > $ mount -o loop F-7-x86_64-DVD.iso tmpmount > > $ cobbler import --name=F-7-x86_64 --mirror=tmpmount > > Traceback (most recent call last): > > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line > > 636, in main > > BootCLI(sys.argv).run() > > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", > line 37, > > in __init__ > > self.api = api.BootAPI() > > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line > 41, in > > __init__ > > self.deserialize() > > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line > 171, in > > deserialize > > return self._config.deserialize() > > File "/usr/lib/python2.5/site-packages/cobbler/config.py", > line 158, > > in deserialize > > if not serializer.deserialize(x): > > File "/usr/lib/python2.5/site-packages/cobbler/serializer.py", > line > > 69, in deserialize > > datastruct = yaml.load(data).next() # first record > > File "/usr/lib/python2.5/site-packages/cobbler/yaml/load.py", > line > > 83, in next > > self.nestedDocs.nestToNextLine() > > File > "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > > 131, in nestToNextLine > > indentation = indentLevel(line) > > File > "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > > 6, in indentLevel > > while n < len(line) and line[n] == ' ': > > TypeError: object of type 'NoneType' has no len() > > $ > > > For some reason your /var/lib/cobbler/settings is completely blank -- that's probably where the parse error was. I'm not sure how something could get into the settings object that couldn't be serialized back... /var/lib/cobbler/settings is created when you first run "cobbler check" after install. To put this file back: # rm /var/lib/cobbler/settings # cobbler check and then edit the file again. I just ran a F7 import again as a sanity check and it worked fine for me. And yes, (to preempt the question) this settings file (unlike the other data files in /var/lib/cobbler) is something that really should be packaged in the RPM as config/noreplace and put under /etc/cobbler. This will be dealt with in a future release. --Michael From dlutter at redhat.com Fri Jun 8 23:22:10 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 08 Jun 2007 23:22:10 +0000 Subject: [et-mgmt-tools] VM images Message-ID: <1181344930.24324.198.camel@galia.watzmann.net> Hi, I wrote some patches against virt-install that make it possible to run virtual machines from VM images (aka appliances) Patches and additional docs are at http://people.redhat.com/dlutter/virt-image/ I'd appreciate comments/suggestions, both on the XML metadata format used to describe images and on the actual patches. David The README from the above URL: VM Image Support for virt-install ================================= This set of patches adds support for creating image-based virtual machines to virt-install. Image-based virtual machines make it possible to distribute VM images and allow users of such images to create VM's safely and with minimal understanding of the image. A VM image consists of an XML metadata file 'image.xml' and the disk images that back the VM's storage. The metadata format is described in detail in the file image.rng Some important points: * The metadata format allows specifying alternative ways of booting the VM, depending on the host platform. The code tries to find a matching boot descriptor using libvirt's capabilities; that matching code probably needs some love * Disk images can either be raw disk images or ISO images * Files referenced in the metadata (disk files, kernel, initrd etc.) are relative to the location of the metadata file. As a convention, they should be in the same directory as the metadata file. Trying it out ------------- To try out these patches you need to (a) apply the patches to virtinst and (b) create a metadata file for an existing VM image. To apply the patches: (1) Checkout virt-inst from mercurial: hg clone http://hg.et.redhat.com/virt/applications/virtinst--devel virt-install (2) Put the patches into that directory: cd virt-install rsync -av http://people.redhat.com/virt-image/patches . (3) Apply them with quilt: quilt push -a (4) Run virt-image: chmod a+x ./virt-image ./virt-image --help The easiest way to create a VM image is to use your favorite existing VM with file-backed disks, and write an image.xml description file. Once you have that, you can look at the libvirt XML that would be used to start the VM with virt-image --image image.xml --print -name test --vnc and start it with virt-image --image image.xml -name test --vnc From markmc at redhat.com Sat Jun 9 13:51:53 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Sat, 09 Jun 2007 14:51:53 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181344930.24324.198.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> Message-ID: <1181397113.3536.116.camel@blaa> Hi David, Looks pretty cool, some comments in now particular order: - At first I thought the pygrub thing isn't needed - but you're right, for PV it's not enough to say "boot this image from its MBR", you need to say "the assumptions that pygrub makes about there being a grub config file etc. will hold true" - Including vcpu, memory, graphics and nic in this metadata is mixing up two things - the things the image need in order to boot and the defaults recommended when instantiating a guest with the image. Perhaps put them in a different toplevel element e.g. ... ... ... - The disk -> target mapping thing is pretty strange - I'd suggest that the order the disks are listed in just specifies the target. I think I see your problem, though, you've got 2 boot disks and you need to make sure the HVM disk is first under HVM. How about if you could just specify the filename of the disk image to boot from in ... the logic to get the libvirt XML right is a bit hairy, but should be doable. Is it hd/cdrom, make sure the boot disk is the first disk etc. - You don't have a human readable name for a UI that allows people to choose from a number of images. - From what I can see, you still have the ability to create a disk at instantiation time, but not format it? - If you added ImageInstaller support to virt-install, couldn't virt-image almost just run virt-install rather than re-implementing a lot of it? i.e. at a glance, it looks like you've forked virt-install in order to have a version with a simpler command line. I don't have a problem with virt-image, and the simpler command line, it's the copied and pasted code I don't like. - This looks odd: + order = [ "xen", "kvm", "kqemu", "qemu" ] + for o in order: + if types.count(o) > 0: i.e. it'd be better not to have to keep that list updated. How about you just pick the first type? If libvirt doesn't order the list of available types in a useful order, maybe it should? - You don't have a way of specifying the disk image should be read-only. - Shouldn't we be copying even system disk images, unless they're read-only, on instantiation - i.e. you should be able to run virt-image multiple times. Cheers, Mark. From berrange at redhat.com Sat Jun 9 14:47:53 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 9 Jun 2007 15:47:53 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181397113.3536.116.camel@blaa> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> Message-ID: <20070609144753.GA15591@redhat.com> On Sat, Jun 09, 2007 at 02:51:53PM +0100, Mark McLoughlin wrote: > - If you added ImageInstaller support to virt-install, couldn't > virt-image almost just run virt-install rather than re-implementing > a lot of it? i.e. at a glance, it looks like you've forked > virt-install in order to have a version with a simpler command > line. I don't have a problem with virt-image, and the simpler > command line, it's the copied and pasted code I don't like. Yes I explicitly asked that David do a separate virt-image tool to get us a simpler command line interface. There is a reasonable amount of duplicate code - likewise in virt-clone - which we could pull out into the util.py module, or perhaps another module. > - Shouldn't we be copying even system disk images, unless they're > read-only, on instantiation - i.e. you should be able to run > virt-image multiple times. That's probably a good idea. 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 prime.provogue at gmail.com Sun Jun 10 11:14:05 2007 From: prime.provogue at gmail.com (Source) Date: Sun, 10 Jun 2007 16:44:05 +0530 Subject: [et-mgmt-tools] [PATCH] [RESEND] Fix continue to install Windows In-Reply-To: <46659D01.2010503@redhat.com> References: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> <46659D01.2010503@redhat.com> Message-ID: <3293c1d10706100414p62741b00h3ed85feb3c6ff224@mail.gmail.com> When will this be available in fedora 7. any ideas ? On 6/5/07, Hugh Brock wrote: > > Nobuhiro Itou wrote: > > Hi, > > > > Would you give me a comment on this patch? > > If not, please apply it. > > > >> I can't continue to install Windows HVM domain after first restart. > >> After the restarting, /dev/cdrom (or ISO path) has not been attached to > the domain. > >> The attached patch solves this problem. > >> > >> Signed-off-by: Nobuhiro Itou > > > > > > Thanks, > > Nobuhiro Itou. > > > > > > Wow, I have no idea what happened there. Yes, I have now applied and > committed the patch, sorry for the delay! > > --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 > > _______________________________________________ > 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 fj0588di at aa.jp.fujitsu.com Mon Jun 11 06:32:49 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Mon, 11 Jun 2007 15:32:49 +0900 Subject: [et-mgmt-tools] [Q] It cannot get a qemu console. Message-ID: <200706111532.HDJ65120.E6KJ099G@aa.jp.fujitsu.com> Hi, In xen-devel-3.1.0-0.rc7.1.fc7, It cannot get a qemu console... Could you apply xen-3.1.0-rc8 or later to Feror7's xen packages to be able to get a qemu console? Thanks, Shigeki Sakamoto. From prime.provogue at gmail.com Mon Jun 11 08:47:50 2007 From: prime.provogue at gmail.com (Source) Date: Mon, 11 Jun 2007 14:17:50 +0530 Subject: [et-mgmt-tools] Re: error while creating rhel5fv with cdrom support (qemu-kvm) In-Reply-To: <3293c1d10704271917j226fd521n720adafd66214088@mail.gmail.com> References: <3293c1d10704271917j226fd521n720adafd66214088@mail.gmail.com> Message-ID: <3293c1d10706110147h7ae2f7fqb4c0cdad554a7a6a@mail.gmail.com> This bug is registered on bugzilla #240127. It is in Fedora7 too. Fedora 7 host having latest updated libvirt and virt-manager can't install another Fedora 7 based virtual machine via KVM. ANy comments ? Thanks On 4/28/07, Source wrote: > > Hi, > > I installed a brand new system with RHEL5. In that system I installed > virt-manager, virtinst, libvirt, libvirt-python, kvm > and qemu latest. Build via src.rpm. > Now I tried to install a RHEL5 guest with the following configurations: > > http://img404.imageshack.us/img404/5869/screenshotcreateanewvirlm6.png > > And when I clicked on Finish I got this error message: > > Unable to complete install 'libvirt.libvirtError virDomainCreateLinux() > failed internal error End-of-file while reading PTY startup output > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/create.py", line 677, 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 666, in > _do_install > self.domain = self.conn.createLinux(install_xml, 0) > File "/usr/lib/python2.4/site-packages/libvirt.py", line 480, in > createLinux > if ret is None:raise libvirtError('virDomainCreateLinux() failed', > conn=self) > libvirtError: virDomainCreateLinux() failed internal error End-of-file > while reading PTY startup output > ' > > Now does this means I can't install fully virtualized guest (hypervisor > qemu-kvm) with bootable cdrom support? Same thing happens If I try to > install ubuntu from CD. It's full virtualization then why is it failing like > this. Also I want to give output of "ps aux | grep libvirt" > > [root at server ~]# ps aux | grep libvirt > root 2516 0.0 0.2 3344 1300 ? S 07:30 0:00 > libvirt_qemud --system --daemon > nobody 2627 0.0 0.1 1772 764 ? S 07:30 0:00 dnsmasq > --keep-in-foreground --bind-interfaces --pid-file --conf-file > --listen-address 192.168.122.1 --except-interface lo > --dhcp-leasefile=/var/lib/libvirt/dhcp-default.leases --dhcp-range > 192.168.122.2,192.168.122.254 > root 7398 0.0 0.1 3888 708 pts/1 S+ 07:43 0:00 grep > libvirt > > > > Thanks > Deependra -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Mon Jun 11 11:11:08 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 11 Jun 2007 12:11:08 +0100 Subject: [et-mgmt-tools] Re: [Q] It cannot get a qemu console. In-Reply-To: <200706111532.HDJ65120.E6KJ099G@aa.jp.fujitsu.com> References: <200706111532.HDJ65120.E6KJ099G@aa.jp.fujitsu.com> Message-ID: <20070611111108.GA9817@redhat.com> On Mon, Jun 11, 2007 at 03:32:49PM +0900, S.Sakamoto wrote: > Hi, > > In xen-devel-3.1.0-0.rc7.1.fc7, It cannot get a qemu console... > Could you apply xen-3.1.0-rc8 or later to Feror7's xen packages to be able to get a qemu console? We will be pushing out an update to the sync up to the official 3.1.0 release in the near future. 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 Mon Jun 11 11:18:33 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 11 Jun 2007 12:18:33 +0100 Subject: [et-mgmt-tools] Re: error while creating rhel5fv with cdrom support (qemu-kvm) In-Reply-To: <3293c1d10706110147h7ae2f7fqb4c0cdad554a7a6a@mail.gmail.com> References: <3293c1d10704271917j226fd521n720adafd66214088@mail.gmail.com> <3293c1d10706110147h7ae2f7fqb4c0cdad554a7a6a@mail.gmail.com> Message-ID: <20070611111833.GB9817@redhat.com> On Mon, Jun 11, 2007 at 02:17:50PM +0530, Source wrote: > This bug is registered on bugzilla #240127. > > It is in Fedora7 too. Fedora 7 host having latest updated libvirt and > virt-manager can't install another Fedora 7 based virtual machine via KVM. > > ANy comments ? libvirt 0.2.3 will likely solve the problem, and at the very least provide much more detailed problem error reporting & logging. It will be pushed to Fedora 7 updates in the near future. 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 Mon Jun 11 11:20:55 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Mon, 11 Jun 2007 20:20:55 +0900 Subject: [et-mgmt-tools] Re: [Q] It cannot get a qemu console. In-Reply-To: <20070611111108.GA9817@redhat.com> References: <200706111532.HDJ65120.E6KJ099G@aa.jp.fujitsu.com> <20070611111108.GA9817@redhat.com> Message-ID: <200706112020.GEI39539.9GK9E6J0@aa.jp.fujitsu.com> Hi, Dan > We will be pushing out an update to the sync up to the official 3.1.0 > release in the near future. All right! Thank you for answering! Thanks, Shigeki Sakamoto. > > Hi, > > > > In xen-devel-3.1.0-0.rc7.1.fc7, It cannot get a qemu console... > > Could you apply xen-3.1.0-rc8 or later to Feror7's xen packages to be able to get a qemu console? > > We will be pushing out an update to the sync up to the official 3.1.0 > release in the near future. > > 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 veillard at redhat.com Mon Jun 11 12:19:28 2007 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 11 Jun 2007 08:19:28 -0400 Subject: [et-mgmt-tools] Re: error while creating rhel5fv with cdrom support (qemu-kvm) In-Reply-To: <20070611111833.GB9817@redhat.com> References: <3293c1d10704271917j226fd521n720adafd66214088@mail.gmail.com> <3293c1d10706110147h7ae2f7fqb4c0cdad554a7a6a@mail.gmail.com> <20070611111833.GB9817@redhat.com> Message-ID: <20070611121928.GD23154@redhat.com> On Mon, Jun 11, 2007 at 12:18:33PM +0100, Daniel P. Berrange wrote: > On Mon, Jun 11, 2007 at 02:17:50PM +0530, Source wrote: > > This bug is registered on bugzilla #240127. > > > > It is in Fedora7 too. Fedora 7 host having latest updated libvirt and > > virt-manager can't install another Fedora 7 based virtual machine via KVM. > > > > ANy comments ? > > libvirt 0.2.3 will likely solve the problem, and at the very least provide > much more detailed problem error reporting & logging. It will be pushed to > Fedora 7 updates in the near future. I built it and requested the push to Testing, hopefully this will be available publicly today or tomorrow, 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 Mon Jun 11 12:46:55 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 11 Jun 2007 13:46:55 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181344930.24324.198.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> Message-ID: <20070611124655.GA19642@redhat.com> On Fri, Jun 08, 2007 at 11:22:10PM +0000, David Lutterkort wrote: > * The metadata format allows specifying alternative ways of booting the VM, > depending on the host platform. The code tries to find a matching boot > descriptor using libvirt's capabilities; that matching code probably > needs some love I'm finding this matchup between guest type and files a little wierd and wondering how well it will work in practice. In the example there you are basically distributing a single root filesystem, and then separate /boot filesystems which are then matched up depending on whether todo HVM vs paravirt. A couple of points 1. Yuk 2. Linux specific ? Does Solaris have a concept of /boot which can be easily separated out for HVM vs Paravirt booting ? Is this even possible under Linux in the general case ? eg different Xorg configs - Cirrus vs fbdev, different filesystem names in /etc/fstab ? Different kernel modules listed in /etc/sysconfig/ 3. Yuk ! 4. How do you generate the filesystems? If I'm using the Fedora live CD creation tools to do a chroot based install and image generation, I can choose to install kernel, or kernel-xen, or both. So I'll end up with a /boot containing a HVM suitable kernel, or a paravirt kernel. Most image generation tools won't even generate a separate image file for /boot, just having one main rootfs. 5. Yuk ;-) I can see we have a use case for the image description format to be able to describe a image requiring HVM or PV, but is there really a compelling case for a single distributed image to be able todo both ? Seems like adding a lot of complexity for not all that much gain. Particuarly if we look forward to 12 months hence when Xen paravirt opts is merged upstream LKML and there is only a single kernel image capable of doing both. Looking at the other view, there is going to be increased use of paravirt drivers within HVM guests, further reducing the use cases for separate paravirt kernels. IMHO we'd be better off just saying there's a single filesystem image,and removing the funky mapping between FS & boot types. Then element would then merely describe what this filesystem is capable of booting, beit HVM, or paravirt or both (once paravirt_ops Xen is available). If people really want the ability to provide images in short term which do both HVM and paravirt, then effort is better focused on making it easy for the image creation tools to spit out two separate sets of image. 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 lippold at gmail.com Mon Jun 11 13:26:15 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 11 Jun 2007 15:26:15 +0200 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files In-Reply-To: <46696A96.5050902@redhat.com> References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> <46696A96.5050902@redhat.com> Message-ID: <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> Hi, When I tried that I got an 'end of line expected' now. Here is the code that I am trying to use in my ks file. FSTAB=/etc/fstab SED=/bin/sed # nosuid on /home if [ $(grep " \/home " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} fi # nosuid on /sys if [ $(grep " \/sys " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then MNT_OPTS=$(grep " \/sys " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/sys.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} fi # nosuid on /boot if [ $(grep " \/boot " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then MNT_OPTS=$(grep " \/boot " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/boot.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} fi # nodev on /usr if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi #nodev on /home if [ $(grep " \/home " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /usr if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /usr/local if [ $(grep " \/usr\/local " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/usr\/local " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/usr\/local.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /tmp if [ $(grep " \/tmp " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/tmp " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi # nodev on /var if [ $(grep " \/var " ${FSTAB} | grep -c "nodev") -eq 0 ]; then MNT_OPTS=$(grep " \/var " ${FSTAB} | awk '{print $4}') ${SED} -i "s/\( \/var.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} fi Thanks, Aaron On 6/8/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > Hi All, > > > > I am having issues with cobbler and importing a ks file of mine. All > > is well with the simple parts of the %post section, but when I get to > > a bit of scripting, the Cheetah parser complains at '" \/home " > > ${FSTAB} ' etc. > > > > How can I escape this section or something? > > > > Thanks, > > > > Aaron > > Dollar signs need to be escaped with \$ since Cheetah is viewing the > shell invocations as Cheetah code. > > This is not true of something like $foosball, where it will just say as > "$foosball" if there is no key, but for something like ${foosball}, then > yes, it must be escaped. > > Unfortunate, I agree. If anyone has any suggestions on better > templating libraries that don't require something heinous like Kid's > XML, I'm all ears. Templating systems > all appear to have their ups and downs, which is apparently why everyone > seems to write their own. That's an option too, but I'm trying to not > go there :) > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From lippold at gmail.com Mon Jun 11 13:30:41 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 11 Jun 2007 15:30:41 +0200 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files In-Reply-To: <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> <46696A96.5050902@redhat.com> <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> Message-ID: <39d2723b0706110630y534c5736sf1e83b84852c4332@mail.gmail.com> Actually, the error is 'Line ending expected' Aaron On 6/11/07, Aaron Lippold wrote: > Hi, > > When I tried that I got an 'end of line expected' now. > > Here is the code that I am trying to use in my ks file. > > FSTAB=/etc/fstab > SED=/bin/sed > # nosuid on /home > if [ $(grep " \/home " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > fi > > # nosuid on /sys > if [ $(grep " \/sys " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > MNT_OPTS=$(grep " \/sys " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/sys.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > fi > > # nosuid on /boot > if [ $(grep " \/boot " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > MNT_OPTS=$(grep " \/boot " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/boot.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > fi > > # nodev on /usr > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > #nodev on /home > if [ $(grep " \/home " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /usr > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /usr/local > if [ $(grep " \/usr\/local " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/usr\/local " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/usr\/local.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /tmp > if [ $(grep " \/tmp " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/tmp " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > # nodev on /var > if [ $(grep " \/var " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > MNT_OPTS=$(grep " \/var " ${FSTAB} | awk '{print $4}') > ${SED} -i "s/\( \/var.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > fi > > Thanks, > > Aaron > > On 6/8/07, Michael DeHaan wrote: > > Aaron Lippold wrote: > > > Hi All, > > > > > > I am having issues with cobbler and importing a ks file of mine. All > > > is well with the simple parts of the %post section, but when I get to > > > a bit of scripting, the Cheetah parser complains at '" \/home " > > > ${FSTAB} ' etc. > > > > > > How can I escape this section or something? > > > > > > Thanks, > > > > > > Aaron > > > > Dollar signs need to be escaped with \$ since Cheetah is viewing the > > shell invocations as Cheetah code. > > > > This is not true of something like $foosball, where it will just say as > > "$foosball" if there is no key, but for something like ${foosball}, then > > yes, it must be escaped. > > > > Unfortunate, I agree. If anyone has any suggestions on better > > templating libraries that don't require something heinous like Kid's > > XML, I'm all ears. Templating systems > > all appear to have their ups and downs, which is apparently why everyone > > seems to write their own. That's an option too, but I'm trying to not > > go there :) > > > > --Michael > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > From rick.vinyard at gmail.com Mon Jun 11 14:36:10 2007 From: rick.vinyard at gmail.com (Rick Vinyard) Date: Mon, 11 Jun 2007 08:36:10 -0600 Subject: [et-mgmt-tools] cobbler In-Reply-To: <466980B7.9080403@redhat.com> References: <4668652A.9010808@redhat.com> <46686A44.7030009@redhat.com> <466980B7.9080403@redhat.com> Message-ID: That was it, and it's fixed. Thanks. On 6/8/07, Michael DeHaan wrote: > > Rick Vinyard wrote: > > Upgrade from FC-6 to F-7. > > > > On 6/7/07, *Michael DeHaan* > > wrote: > > > > Rick Vinyard wrote: > > > Tried cobbler rpms 0.4.8-1 and 0.4.7-5 with identical results. > > > > > > $ mount -o loop F-7-x86_64-DVD.iso tmpmount > > > $ cobbler import --name=F-7-x86_64 --mirror=tmpmount > > > Traceback (most recent call last): > > > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", line > > > 636, in main > > > BootCLI(sys.argv).run() > > > File "/usr/lib/python2.5/site-packages/cobbler/cobbler.py", > > line 37, > > > in __init__ > > > self.api = api.BootAPI() > > > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line > > 41, in > > > __init__ > > > self.deserialize() > > > File "/usr/lib/python2.5/site-packages/cobbler/api.py", line > > 171, in > > > deserialize > > > return self._config.deserialize() > > > File "/usr/lib/python2.5/site-packages/cobbler/config.py", > > line 158, > > > in deserialize > > > if not serializer.deserialize(x): > > > File "/usr/lib/python2.5/site-packages/cobbler/serializer.py", > > line > > > 69, in deserialize > > > datastruct = yaml.load(data).next() # first record > > > File "/usr/lib/python2.5/site-packages/cobbler/yaml/load.py", > > line > > > 83, in next > > > self.nestedDocs.nestToNextLine() > > > File > > "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > > > 131, in nestToNextLine > > > indentation = indentLevel(line) > > > File > > "/usr/lib/python2.5/site-packages/cobbler/yaml/stream.py", line > > > 6, in indentLevel > > > while n < len(line) and line[n] == ' ': > > > TypeError: object of type 'NoneType' has no len() > > > $ > > > > > > > For some reason your /var/lib/cobbler/settings is completely blank -- > that's probably where the parse error was. I'm not sure how something > could get into the > settings object that couldn't be serialized back... > > /var/lib/cobbler/settings is created when you first run "cobbler check" > after install. > > To put this file back: > > # rm /var/lib/cobbler/settings > # cobbler check > > and then edit the file again. > > I just ran a F7 import again as a sanity check and it worked fine for me. > > And yes, (to preempt the question) this settings file (unlike the other > data files in /var/lib/cobbler) is something that really should be > packaged in the RPM as config/noreplace and put under /etc/cobbler. > This will be dealt with in a future release. > > --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 gledesma at gmail.com Mon Jun 11 15:56:40 2007 From: gledesma at gmail.com (Gino LV. Ledesma) Date: Mon, 11 Jun 2007 08:56:40 -0700 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files In-Reply-To: <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> <46696A96.5050902@redhat.com> <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> Message-ID: > Unfortunate, I agree. If anyone has any suggestions on better > templating libraries that don't require something heinous like Kid's > XML, I'm all ears. Templating systems > all appear to have their ups and downs, which is apparently why everyone > seems to write their own. That's an option too, but I'm trying to not > go there :) You've probably considered this before, but not sure of your opinion, but what about YAML? - gino From mdehaan at redhat.com Mon Jun 11 16:11:06 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 11 Jun 2007 12:11:06 -0400 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files In-Reply-To: References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> <46696A96.5050902@redhat.com> <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> Message-ID: <466D741A.7090905@redhat.com> Gino LV. Ledesma wrote: >> Unfortunate, I agree. If anyone has any suggestions on better >> templating libraries that don't require something heinous like Kid's >> XML, I'm all ears. Templating systems >> all appear to have their ups and downs, which is apparently why everyone >> seems to write their own. That's an option too, but I'm trying to not >> go there :) > > You've probably considered this before, but not sure of your opinion, > but what about YAML? > How so? YAML is good for doing data serialization in a human readable/writable way, not sure how that relates to templating... > - gino > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From gledesma at gmail.com Mon Jun 11 16:22:16 2007 From: gledesma at gmail.com (Gino LV. Ledesma) Date: Mon, 11 Jun 2007 09:22:16 -0700 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files In-Reply-To: <466D741A.7090905@redhat.com> References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> <46696A96.5050902@redhat.com> <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> <466D741A.7090905@redhat.com> Message-ID: > > You've probably considered this before, but not sure of your opinion, > > but what about YAML? > > How so? Whoops. I got confused. I meant Template Toolkit. I've been using YAML+TT a bit the past few weeks that they're almost one and the same thing in my mind. - gino From mdehaan at redhat.com Mon Jun 11 16:31:25 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 11 Jun 2007 12:31:25 -0400 Subject: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files In-Reply-To: References: <39d2723b0706080522y3ca998f8qdfeecb7e8a12d393@mail.gmail.com> <46696A96.5050902@redhat.com> <39d2723b0706110626u1ec7bd69ydee661b21dd94efe@mail.gmail.com> <466D741A.7090905@redhat.com> Message-ID: <466D78DD.4050207@redhat.com> Gino LV. Ledesma wrote: >> > You've probably considered this before, but not sure of your opinion, >> > but what about YAML? >> >> How so? > > Whoops. I got confused. I meant Template Toolkit. I've been using > YAML+TT a bit the past few weeks that they're almost one and the same > thing in my mind. > > - gino > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Yeah, it's Monday :) Cobbler's written in Python, so I'd like to keep it in the same process (for stacktraces) and not add Perl packaging dependencies if at all possible. --Michael From lippold at gmail.com Mon Jun 11 16:51:56 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 11 Jun 2007 18:51:56 +0200 Subject: [Fwd: Re: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files] In-Reply-To: <466D7AA9.5020605@redhat.com> References: <466D7AA9.5020605@redhat.com> Message-ID: <39d2723b0706110951m5a0d9608n85bb615e8db272b2@mail.gmail.com> Hi, Sorry I had to leave the desk for a bit. Ya it is suposed to be Bash. Which I am sure is the issue but a lot of my developers are bash folks not python. I posted the section that seems to be giving python / cheetah fits. When I escape the ${var} it says end line expected. When cheetah naturally complains because it does like the var defn. hmmmm. thoughts? Thanks, Aaron On 6/11/07, Michael DeHaan wrote: > IRC log... > > I found that if I just copy the file to the web sever and > reference it with kickstart=http://server/file then it doesn't parse the > ks file. This is a workaround but I would still like to know how to do > this correctly :) > * rharrison (i=rharriso at nat/cisco/x-a6ceb7953d81c5fc) has joined #cobbler > google doesn't seem to have an answer for why a X=bla and > then ref X with \${X} would make the cheetah parser is throwing a , > 'Line ending expected', exception. > throw an error ... sorry > * timverhoeven (i=timverho at nat/ibm/x-78684106c698f2d3) has left #cobbler > aaronlippold, hi > aaronlippold, yes, http:// kickstarts do not parse, there is > a reason for this > suppose you want to use a kickstart file straight out of RHN, > for instance, via URL... > or if the kickstart is a file another admin maintains > so they evaluate only when they are stored on the filesystem > as templates, not whole kickstart files > aaronlippold, hmm, perhaps you could post an example to the > Cheetah list > ah, > so is \${X} supposed to reference a Cheetah var? With > escaping the "X" you won't > I mean, the $ > The reason you escape \$ is to make sure they pass through to > the kickstart file as $ > Unless that's supposed to be bash code > aaronlippold, ping? > > > > > > ---------- Forwarded message ---------- > From: "Aaron Lippold" > To: "Fedora/Linux Management Tools" > Date: Mon, 11 Jun 2007 15:30:41 +0200 > Subject: Re: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files > Actually, the error is 'Line ending expected' > > Aaron > > On 6/11/07, Aaron Lippold wrote: > > Hi, > > > > When I tried that I got an 'end of line expected' now. > > > > Here is the code that I am trying to use in my ks file. > > > > FSTAB=/etc/fstab > > SED=/bin/sed > > # nosuid on /home > > if [ $(grep " \/home " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > > fi > > > > # nosuid on /sys > > if [ $(grep " \/sys " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > > MNT_OPTS=$(grep " \/sys " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/sys.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > > fi > > > > # nosuid on /boot > > if [ $(grep " \/boot " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > > MNT_OPTS=$(grep " \/boot " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/boot.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > > fi > > > > # nodev on /usr > > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > fi > > > > #nodev on /home > > if [ $(grep " \/home " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > fi > > > > # nodev on /usr > > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > fi > > > > # nodev on /usr/local > > if [ $(grep " \/usr\/local " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > MNT_OPTS=$(grep " \/usr\/local " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/usr\/local.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > fi > > > > # nodev on /tmp > > if [ $(grep " \/tmp " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > MNT_OPTS=$(grep " \/tmp " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > fi > > > > # nodev on /var > > if [ $(grep " \/var " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > MNT_OPTS=$(grep " \/var " ${FSTAB} | awk '{print $4}') > > ${SED} -i "s/\( \/var.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > fi > > > > Thanks, > > > > Aaron > > > > On 6/8/07, Michael DeHaan wrote: > > > Aaron Lippold wrote: > > > > Hi All, > > > > > > > > I am having issues with cobbler and importing a ks file of mine. All > > > > is well with the simple parts of the %post section, but when I get to > > > > a bit of scripting, the Cheetah parser complains at '" \/home " > > > > ${FSTAB} ' etc. > > > > > > > > How can I escape this section or something? > > > > > > > > Thanks, > > > > > > > > Aaron > > > > > > Dollar signs need to be escaped with \$ since Cheetah is viewing the > > > shell invocations as Cheetah code. > > > > > > This is not true of something like $foosball, where it will just say as > > > "$foosball" if there is no key, but for something like ${foosball}, then > > > yes, it must be escaped. > > > > > > Unfortunate, I agree. If anyone has any suggestions on better > > > templating libraries that don't require something heinous like Kid's > > > XML, I'm all ears. Templating systems > > > all appear to have their ups and downs, which is apparently why everyone > > > seems to write their own. That's an option too, but I'm trying to not > > > go there :) > > > > > > --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 lippold at gmail.com Mon Jun 11 16:54:37 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 11 Jun 2007 18:54:37 +0200 Subject: [Fwd: Re: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files] In-Reply-To: <39d2723b0706110951m5a0d9608n85bb615e8db272b2@mail.gmail.com> References: <466D7AA9.5020605@redhat.com> <39d2723b0706110951m5a0d9608n85bb615e8db272b2@mail.gmail.com> Message-ID: <39d2723b0706110954s44ab272asb049f55915cf42d6@mail.gmail.com> /s/When cheetah naturally/When I don't escape the ${var} cheetah/g :) On 6/11/07, Aaron Lippold wrote: > Hi, > > Sorry I had to leave the desk for a bit. > > Ya it is supposed to be Bash. Which I am sure is the issue but a lot of > my developers are bash folks not python. > > I posted the section that seems to be giving python / cheetah fits. > > When I escape the ${var} it says end line expected. When cheetah > naturally complains because it does like the var defn. > > hmmmm. > > thoughts? > > Thanks, > > Aaron > > On 6/11/07, Michael DeHaan wrote: > > IRC log... > > > > I found that if I just copy the file to the web sever and > > reference it with kickstart=http://server/file then it doesn't parse the > > ks file. This is a workaround but I would still like to know how to do > > this correctly :) > > * rharrison (i=rharriso at nat/cisco/x-a6ceb7953d81c5fc) has joined #cobbler > > google doesn't seem to have an answer for why a X=bla and > > then ref X with \${X} would make the cheetah parser is throwing a , > > 'Line ending expected', exception. > > throw an error ... sorry > > * timverhoeven (i=timverho at nat/ibm/x-78684106c698f2d3) has left #cobbler > > aaronlippold, hi > > aaronlippold, yes, http:// kickstarts do not parse, there is > > a reason for this > > suppose you want to use a kickstart file straight out of RHN, > > for instance, via URL... > > or if the kickstart is a file another admin maintains > > so they evaluate only when they are stored on the filesystem > > as templates, not whole kickstart files > > aaronlippold, hmm, perhaps you could post an example to the > > Cheetah list > > ah, > > so is \${X} supposed to reference a Cheetah var? With > > escaping the "X" you won't > > I mean, the $ > > The reason you escape \$ is to make sure they pass through to > > the kickstart file as $ > > Unless that's supposed to be bash code > > aaronlippold, ping? > > > > > > > > > > > > ---------- Forwarded message ---------- > > From: "Aaron Lippold" > > To: "Fedora/Linux Management Tools" > > Date: Mon, 11 Jun 2007 15:30:41 +0200 > > Subject: Re: [et-mgmt-tools] Cobbler, Cheetah and scripts in KS files > > Actually, the error is 'Line ending expected' > > > > Aaron > > > > On 6/11/07, Aaron Lippold wrote: > > > Hi, > > > > > > When I tried that I got an 'end of line expected' now. > > > > > > Here is the code that I am trying to use in my ks file. > > > > > > FSTAB=/etc/fstab > > > SED=/bin/sed > > > # nosuid on /home > > > if [ $(grep " \/home " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > > > fi > > > > > > # nosuid on /sys > > > if [ $(grep " \/sys " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/sys " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/sys.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > > > fi > > > > > > # nosuid on /boot > > > if [ $(grep " \/boot " ${FSTAB} | grep -c "nosuid") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/boot " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/boot.*${MNT_OPTS}\)/\1,nosuid/" ${FSTAB} > > > fi > > > > > > # nodev on /usr > > > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > > fi > > > > > > #nodev on /home > > > if [ $(grep " \/home " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/home " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/home.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > > fi > > > > > > # nodev on /usr > > > if [ $(grep " \/usr " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/usr " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/usr.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > > fi > > > > > > # nodev on /usr/local > > > if [ $(grep " \/usr\/local " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/usr\/local " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/usr\/local.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > > fi > > > > > > # nodev on /tmp > > > if [ $(grep " \/tmp " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/tmp " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > > fi > > > > > > # nodev on /var > > > if [ $(grep " \/var " ${FSTAB} | grep -c "nodev") -eq 0 ]; then > > > MNT_OPTS=$(grep " \/var " ${FSTAB} | awk '{print $4}') > > > ${SED} -i "s/\( \/var.*${MNT_OPTS}\)/\1,nodev/" ${FSTAB} > > > fi > > > > > > Thanks, > > > > > > Aaron > > > > > > On 6/8/07, Michael DeHaan wrote: > > > > Aaron Lippold wrote: > > > > > Hi All, > > > > > > > > > > I am having issues with cobbler and importing a ks file of mine. All > > > > > is well with the simple parts of the %post section, but when I get to > > > > > a bit of scripting, the Cheetah parser complains at '" \/home " > > > > > ${FSTAB} ' etc. > > > > > > > > > > How can I escape this section or something? > > > > > > > > > > Thanks, > > > > > > > > > > Aaron > > > > > > > > Dollar signs need to be escaped with \$ since Cheetah is viewing the > > > > shell invocations as Cheetah code. > > > > > > > > This is not true of something like $foosball, where it will just say as > > > > "$foosball" if there is no key, but for something like ${foosball}, then > > > > yes, it must be escaped. > > > > > > > > Unfortunate, I agree. If anyone has any suggestions on better > > > > templating libraries that don't require something heinous like Kid's > > > > XML, I'm all ears. Templating systems > > > > all appear to have their ups and downs, which is apparently why everyone > > > > seems to write their own. That's an option too, but I'm trying to not > > > > go there :) > > > > > > > > --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 dlutter at redhat.com Mon Jun 11 19:06:15 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 11 Jun 2007 12:06:15 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <20070611124655.GA19642@redhat.com> References: <1181344930.24324.198.camel@galia.watzmann.net> <20070611124655.GA19642@redhat.com> Message-ID: <1181588775.20651.60.camel@galia.watzmann.net> On Mon, 2007-06-11 at 13:46 +0100, Daniel P. Berrange wrote: > On Fri, Jun 08, 2007 at 11:22:10PM +0000, David Lutterkort wrote: > > * The metadata format allows specifying alternative ways of booting the VM, > > depending on the host platform. The code tries to find a matching boot > > descriptor using libvirt's capabilities; that matching code probably > > needs some love > > I'm finding this matchup between guest type and files a little wierd and > wondering how well it will work in practice. In the example there you are > basically distributing a single root filesystem, and then separate /boot > filesystems which are then matched up depending on whether todo HVM vs > paravirt. Look at it from the user's point of view: Are you interested in a 'app foo appliance' or in a 'app foo for paravirt Xen w/ PAE support' appliance ? If you want to keep users from appreciating the finer points of this, you'll need to capture it in metadata. And you'll either make the distinction what you run when you download (one image per host 'type') or when you are about to run the image (one image for all host types) Should users really d/l a few 100 MB of stuff to discover that they should have clicked on the 'Xen pv w/ PAE' link rather than the 'Xen pv w/o PAE' link ? > A couple of points > > 1. Yuk It's definitely a bit kludgey, but than any other way of achieving the same thing is even worse. On the upside this is something that's not appliance specific, i.e. you can create base images that do the yucky stuff regardless of the actual application your appliance runs. And it seems a tad less yucky than having the appliance boot hvm, ask an XML-RPC server if pv is ok, and then booting pv. > 2. Linux specific ? Does Solaris have a concept of /boot which can be > easily separated out for HVM vs Paravirt booting ? I don't know; but it does have a concept of mountpoints and symlinks, so you could fake this /boot business. > Is this even possible under Linux in the general case ? The first thing you run into when you have this setup is that inittab has an entry for xvc0 for pv, but that that entry gets in the way for fv. You can get around that by symlinking/bindmounting /etc/inittab into the /boot disk (which should probably not be called /boot disk anymore) > eg different Xorg configs - Cirrus vs fbdev, No idea; though I think not having to maintain n root images for n host types would be pretty attractive. > different filesystem names in /etc/fstab ? Mount-by-label or symlink/bindmount > Different kernel modules listed in /etc/sysconfig/ > 3. Yuk ! > 4. How do you generate the filesystems? If I'm using the Fedora live CD > creation tools to do a chroot based install and image generation, I > can choose to install kernel, or kernel-xen, or both. So I'll end up > with a /boot containing a HVM suitable kernel, or a paravirt kernel. I used a full virt-install. > Most image generation tools won't even generate a separate image file > for /boot, just having one main rootfs. We'd need that ability anyway, e.g. to separate system from data disks for image-based updates. > I can see we have a use case for the image description format to be able to > describe a image requiring HVM or PV, but is there really a compelling case > for a single distributed image to be able todo both ? Seems like adding a > lot of complexity for not all that much gain. Users will have to understand a lot less about virtualization with this than they'd have to without it. And they can change their mind about which host they want to deploy on w/o having to download a whole new image. > Particuarly if we look forward > to 12 months hence when Xen paravirt opts is merged upstream LKML and there > is only a single kernel image capable of doing both. Will that address PAE ? What about the other HW differences you mentioned above, like Xorg ? > Looking at the other > view, there is going to be increased use of paravirt drivers within HVM > guests, further reducing the use cases for separate paravirt kernels. And an even bigger need to express that cleanly (it's not like PV kernels are on the brink of extinction) - if the tool doesn't support expressing whether/what kind of PV drivers are needed, that complexity has to live in user's heads. The download pages for appliances (e.g. [1]) already make my head spin. > IMHO we'd be better off just saying there's a single filesystem image,and > removing the funky mapping between FS & boot types. Then element > would then merely describe what this filesystem is capable of booting, beit > HVM, or paravirt or both (once paravirt_ops Xen is available). One thing the metadata doesn't express well is the scenario of a unified pv/fv kernel. > If people really want the ability to provide images in short term which do > both HVM and paravirt, then effort is better focused on making it easy for > the image creation tools to spit out two separate sets of image. Will unified kernels really do away with all the differences between hv and pv from the guest's POV ? David [1] http://www.rpath.org/rbuilder/project/lochdns/ From mdehaan at redhat.com Mon Jun 11 19:16:50 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 11 Jun 2007 15:16:50 -0400 Subject: [et-mgmt-tools] Cheetah raw/endraw (was: Templating...) In-Reply-To: <39d2723b0706110954s44ab272asb049f55915cf42d6@mail.gmail.com> References: <466D7AA9.5020605@redhat.com> <39d2723b0706110951m5a0d9608n85bb615e8db272b2@mail.gmail.com> <39d2723b0706110954s44ab272asb049f55915cf42d6@mail.gmail.com> Message-ID: <466D9FA2.6080903@redhat.com> Aaron Lippold wrote: > /s/When cheetah naturally/When I don't escape the ${var} cheetah/g > ... snip ... If you have large blocks of shell in %pre and %post, rather than escaping them in Cheetah, I just discovered you can exclose them in #raw ... #endraw blocks. http://www.cheetahtemplate.org/docs/users_guide_html/users_guide.html#SECTION000850000000000000000 If you have template variables (--ksmeta) that you want to access from shell, you can assign them to shell variables in your %pre or %post sections and then use them from inside the raw sections. See example: === #!/usr/bin/python from Cheetah.Template import * # notice how I am setting foo and bar such that they'll be available in the raw section... data = """#errorCatcher Echo \$foo = $foo \$bar = $bar #raw if [ $(grep \" /home \" #echo "${FSTAB} | grep -c \"nosuid\") -eq 0 ]; then" # use $foo # use $bar #endraw """ search = { "foo" : "gleep", "bar" : "gloop" } t = Template(source=data, searchList=[search]) print str(t) === This seems to me a lot cleaner than doing the escaping or needing to understand the escaping rules. --Michael From dlutter at redhat.com Mon Jun 11 19:20:12 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 11 Jun 2007 12:20:12 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181397113.3536.116.camel@blaa> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> Message-ID: <1181589612.20651.74.camel@galia.watzmann.net> Hi Mark, On Sat, 2007-06-09 at 14:51 +0100, Mark McLoughlin wrote: > - Including vcpu, memory, graphics and nic in this metadata is mixing > up two things - the things the image need in order to boot and the > defaults recommended when instantiating a guest with the image. Agreed; that would be much cleaner. I'll revise the patches > - The disk -> target mapping thing is pretty strange - I'd suggest > that the order the disks are listed in just specifies the target. In the code, specifying a target is actually optional; it just seemed more understandable to me to allow explicit mappings. > Is it hd/cdrom, make sure the boot disk is the first disk etc. > > Doesn't the CDROM always need to be hdc ? (at least that's what the current virt-install code does) With that, you'd have some funky out-of-order mapping. > - You don't have a human readable name for a UI that allows people to > choose from a number of images. Oh, yeah; I'll add a label and description. > - From what I can see, you still have the ability to create a disk at > instantiation time, but not format it? The more I think about it, the less this whole notion of 'instantiate disk automatically' seems to make sense to me; will appliances really detect that they'd been given a blank disk and then partition and format it ? It'd probably make more sense if the metadata could express what partitions with what FS's should be on disks - then auto-creation of scratch or user disks could actually be useful for appliance builders. > - If you added ImageInstaller support to virt-install, couldn't > virt-image almost just run virt-install rather than re-implementing > a lot of it? i.e. at a glance, it looks like you've forked > virt-install in order to have a version with a simpler command > line. I don't have a problem with virt-image, and the simpler > command line, it's the copied and pasted code I don't like. Yeah, I had that same uneasy feeling; I'll go through and factor out as much as I can. > - This looks odd: > > + order = [ "xen", "kvm", "kqemu", "qemu" ] > + for o in order: > + if types.count(o) > 0: > > i.e. it'd be better not to have to keep that list updated. How > about you just pick the first type? If libvirt doesn't order the > list of available types in a useful order, maybe it should? Agreed; going just by the order in the metadata seems cleaner. If we do that, then there's no need for libvirt ordering the types. > - You don't have a way of specifying the disk image should be > read-only. Agreed, I'll try and stick that in there. > - Shouldn't we be copying even system disk images, unless they're > read-only, on instantiation - i.e. you should be able to run > virt-image multiple times. I kinda left the issue of multiple instantiations of images out on purpose, to keep the first cut simple, since they require a good deal of book-keeping, too, to make image-based updates possible. In any event, I think the user should still be able to override if copies are made or not; to make this really usable you'd probably also want ot support an image format that can do snapshot-based copies like qcow. At least on my LAN, copying a few hundred megs of disk images around is no fun :( David From berrange at redhat.com Mon Jun 11 19:27:50 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 11 Jun 2007 20:27:50 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181589612.20651.74.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> <1181589612.20651.74.camel@galia.watzmann.net> Message-ID: <20070611192750.GB15130@redhat.com> On Mon, Jun 11, 2007 at 12:20:12PM -0700, David Lutterkort wrote: > > Is it hd/cdrom, make sure the boot disk is the first disk etc. > > > > > > Doesn't the CDROM always need to be hdc ? (at least that's what the > current virt-install code does) With that, you'd have some funky > out-of-order mapping. For Xen no - it can be any IDE drive. We kept the hdc restriction though to simplify KVM / QEMU handling which do still have CDROM=hdc requirement. 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 Mon Jun 11 19:56:41 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 11 Jun 2007 20:56:41 +0100 Subject: [et-mgmt-tools] Re: [Q] It cannot get a qemu console. In-Reply-To: <20070611111108.GA9817@redhat.com> References: <200706111532.HDJ65120.E6KJ099G@aa.jp.fujitsu.com> <20070611111108.GA9817@redhat.com> Message-ID: <20070611195641.GC15130@redhat.com> On Mon, Jun 11, 2007 at 12:11:08PM +0100, Daniel P. Berrange wrote: > On Mon, Jun 11, 2007 at 03:32:49PM +0900, S.Sakamoto wrote: > > Hi, > > > > In xen-devel-3.1.0-0.rc7.1.fc7, It cannot get a qemu console... > > Could you apply xen-3.1.0-rc8 or later to Feror7's xen packages to be able to get a qemu console? > > We will be pushing out an update to the sync up to the official 3.1.0 > release in the near future. I just submitted the request for xen-3.1.0-2.fc7 To be pushed to Fedora 7 updates-testing - it should appear in the YUM repo within the next day. 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 Mon Jun 11 19:58:10 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 11 Jun 2007 12:58:10 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <20070611124655.GA19642@redhat.com> References: <1181344930.24324.198.camel@galia.watzmann.net> <20070611124655.GA19642@redhat.com> Message-ID: <1181591890.20651.90.camel@galia.watzmann.net> On Mon, 2007-06-11 at 13:46 +0100, Daniel P. Berrange wrote: > I'm finding this matchup between guest type and files a little wierd and > wondering how well it will work in practice. In the example there you are > basically distributing a single root filesystem, and then separate /boot > filesystems which are then matched up depending on whether todo HVM vs > paravirt. The other use case that this is working towards is that of matching an existing VM image to a (set of) hosts it can possibly run on. Think of this in the context of a big data center mgmt tool: you have a large number of hosts, with some variation on the exact virt platform they are running. You'd like your tool to be able to place a VM (image) intelligently on an appropriate host - and the first question you need to answer is 'Can this guest run on this host'; the virt-image code is of course only a small fraction of what you'll wind up needing, but it's a first small step in that direction. David From markmc at redhat.com Tue Jun 12 07:39:53 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 12 Jun 2007 08:39:53 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181589612.20651.74.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> <1181589612.20651.74.camel@galia.watzmann.net> Message-ID: <1181633993.3650.26.camel@blaa> Hi David, On Mon, 2007-06-11 at 12:20 -0700, David Lutterkort wrote: > On Sat, 2007-06-09 at 14:51 +0100, Mark McLoughlin wrote: > > - From what I can see, you still have the ability to create a disk at > > instantiation time, but not format it? > > The more I think about it, the less this whole notion of 'instantiate > disk automatically' seems to make sense to me; will appliances really > detect that they'd been given a blank disk and then partition and format > it ? > > It'd probably make more sense if the metadata could express what > partitions with what FS's should be on disks - then auto-creation of > scratch or user disks could actually be useful for appliance builders. You're confusing me now - my ImageInstaller had support for formatting auto-created disks and I thought you didn't like that idea. My point was going to be that auto-creating disks is useless without formatting support. Does that mean we agree now? :-) > > - This looks odd: > > > > + order = [ "xen", "kvm", "kqemu", "qemu" ] > > + for o in order: > > + if types.count(o) > 0: > > > > i.e. it'd be better not to have to keep that list updated. How > > about you just pick the first type? If libvirt doesn't order the > > list of available types in a useful order, maybe it should? > > Agreed; going just by the order in the metadata seems cleaner. If we do > that, then there's no need for libvirt ordering the types. Huh? You don't have the hypervisor type in the metadata. And rightly so. So, I'm suggesting that we go by libvirt's ordering rather than a hard-coded ordering. > > - Shouldn't we be copying even system disk images, unless they're > > read-only, on instantiation - i.e. you should be able to run > > virt-image multiple times. > > I kinda left the issue of multiple instantiations of images out on > purpose, to keep the first cut simple, since they require a good deal of > book-keeping, too, to make image-based updates possible. I think it's pretty natural to assume people will run virt-image more than once. Cheers, Mark. From dlutter at redhat.com Tue Jun 12 14:46:45 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 12 Jun 2007 07:46:45 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181633993.3650.26.camel@blaa> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> <1181589612.20651.74.camel@galia.watzmann.net> <1181633993.3650.26.camel@blaa> Message-ID: <1181659605.4234.26.camel@galia.watzmann.net> On Tue, 2007-06-12 at 08:39 +0100, Mark McLoughlin wrote: > > It'd probably make more sense if the metadata could express what > > partitions with what FS's should be on disks - then auto-creation of > > scratch or user disks could actually be useful for appliance builders. > > You're confusing me now - my ImageInstaller had support for formatting > auto-created disks and I thought you didn't like that idea. My point was > going to be that auto-creating disks is useless without formatting > support. > > Does that mean we agree now? :-) Definitely; the only thing that bothered me about the ImageInstaller was that it didn't export full disks to the VM, only partitions. I think it would be very useful to expand this code to take FS images and build disks from them (or create disks with formatted partitions) > > > - This looks odd: > > > > > > + order = [ "xen", "kvm", "kqemu", "qemu" ] > > > + for o in order: > > > + if types.count(o) > 0: > > > > > > i.e. it'd be better not to have to keep that list updated. How > > > about you just pick the first type? If libvirt doesn't order the > > > list of available types in a useful order, maybe it should? > > > > Agreed; going just by the order in the metadata seems cleaner. If we do > > that, then there's no need for libvirt ordering the types. > > Huh? You don't have the hypervisor type in the metadata. And rightly > so. I'll read my own code at some point ;) > So, I'm suggesting that we go by libvirt's ordering rather than a > hard-coded ordering. > > > > - Shouldn't we be copying even system disk images, unless they're > > > read-only, on instantiation - i.e. you should be able to run > > > virt-image multiple times. > > > > I kinda left the issue of multiple instantiations of images out on > > purpose, to keep the first cut simple, since they require a good deal of > > book-keeping, too, to make image-based updates possible. > > I think it's pretty natural to assume people will run virt-image more > than once. Absolutely, I just didn't want to deal with it in the first round. David From berrange at redhat.com Tue Jun 12 15:21:51 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 12 Jun 2007 16:21:51 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181588775.20651.60.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> <20070611124655.GA19642@redhat.com> <1181588775.20651.60.camel@galia.watzmann.net> Message-ID: <20070612152151.GJ3031@redhat.com> On Mon, Jun 11, 2007 at 12:06:15PM -0700, David Lutterkort wrote: > Look at it from the user's point of view: Are you interested in a 'app > foo appliance' or in a 'app foo for paravirt Xen w/ PAE support' > appliance ? If you want to keep users from appreciating the finer points > of this, you'll need to capture it in metadata. And you'll either make > the distinction what you run when you download (one image per host > 'type') or when you are about to run the image (one image for all host > types) Should users really d/l a few 100 MB of stuff to discover that > they should have clicked on the 'Xen pv w/ PAE' link rather than the > 'Xen pv w/o PAE' link ? So this really raises the question of exactly what problem we're trying to address here with the image tools. Are we a) Trying to come up with a way to build & describe a single image which can be deployed to Xen PV, Xen HVM, KVM, VMWare + VirtualBox b) Merely trying to come up with a consistent packaging & metadata scheme, allowing images to be built to target specific virt platforms a) is really the superset of b), but I'm not sure how far we'll be able to get with a) given the differences in the way all these different virt platforms work & the types of hardware they expose. I can't help thinking its gonna take more than just a different boot kernel fiel and initrd to be able to provide an image that works seemlessly on all different virt platforms. > > A couple of points > > > > 1. Yuk > > It's definitely a bit kludgey, but than any other way of achieving the > same thing is even worse. On the upside this is something that's not > appliance specific, i.e. you can create base images that do the yucky > stuff regardless of the actual application your appliance runs. > > And it seems a tad less yucky than having the appliance boot hvm, ask an > XML-RPC server if pv is ok, and then booting pv. I wouldn't suggest that as an approach either. First of all we need to realize that this whole problem space is basically just caused by the Xen paravirt boot process - I don't like the idea creating an overly complex metadata format to deal with the dumbassnmess of a particular HV, particularly if there is active work to address this weakness of Xen. Two alternatives I can think of. Basically assume a single filesystem image, which contains /boot as part of the main FS. - When building the guest install both kernel & kernel-xen inside the image. The /etc/grub.conf should contain the entries only for the baremetal kernel. The paravirt kernel lines should be in a separate /etc/pygrub.conf. Now adapt pygrub so that it first looks for an /etc/pyrub.conf in the guest image. That way if you boot under HVM, it automatically gets a baremetal kernel and if you boot PV, it automatically gets Xen kernel. No separate /boot required. - When building the guest install only provide a HVM kernel. In the bundle containing the image & metadata, provide a separate Xen kernel & initrd outside the context of the main filesystem. Boot these directly instead of using pygrub. My preference would be option 1, using a separate pyrub.conf inside the guest, so a single image can boot either. > > Is this even possible under Linux in the general case ? > > The first thing you run into when you have this setup is that inittab > has an entry for xvc0 for pv, but that that entry gets in the way for > fv. You can get around that by symlinking/bindmounting /etc/inittab into > the /boot disk (which should probably not be called /boot disk anymore) Or running kudzu on every boot, so it detects & re-writes inittab according to what console/serial lines are available. Actually I think it should do this already. > > eg different Xorg configs - Cirrus vs fbdev, > > No idea; though I think not having to maintain n root images for n host > types would be pretty attractive. > > > different filesystem names in /etc/fstab ? > > Mount-by-label or symlink/bindmount > > > Different kernel modules listed in /etc/sysconfig/ > > 3. Yuk ! > > 4. How do you generate the filesystems? If I'm using the Fedora live CD > > creation tools to do a chroot based install and image generation, I > > can choose to install kernel, or kernel-xen, or both. So I'll end up > > with a /boot containing a HVM suitable kernel, or a paravirt kernel. > > I used a full virt-install. That wasn't quite what i was getting at - virt-install will build you an image which does HVM or PV. It won't spit out a sepatrate 'boot' image for each option. The best you could do was have your kickstart script do an install of both kernel & kernel-xen inside the guest. That would give you an image with both types of kernel available in /boot, but that's still a single filesystem image you now have to take a chainsaw to, to create your boot-hvm.img and boot-pv.img. Now depending on which you boot, your guest will fail an RPM verify on either kernel, or kernel-xen because you had to rip it apart. > > Most image generation tools won't even generate a separate image file > > for /boot, just having one main rootfs. > > We'd need that ability anyway, e.g. to separate system from data disks > for image-based updates. Data disks are a little easier to deal with - you simply splice in a data disk at the approach part of the FS tree. The /boot thing is nasty becasue you're taking a single directory & trying to munge it into 2 different disks. > > IMHO we'd be better off just saying there's a single filesystem image,and > > removing the funky mapping between FS & boot types. Then element > > would then merely describe what this filesystem is capable of booting, beit > > HVM, or paravirt or both (once paravirt_ops Xen is available). > > One thing the metadata doesn't express well is the scenario of a unified > pv/fv kernel. We definitely need to figure out how to do this, because single unified kernel is how Xen will be merged in LKML. Likewise for LGuest, or VMWare paravirtops. Separate kernels are going the way of the dodo > > > If people really want the ability to provide images in short term which do > > both HVM and paravirt, then effort is better focused on making it easy for > > the image creation tools to spit out two separate sets of image. > > Will unified kernels really do away with all the differences between hv > and pv from the guest's POV ? Not immediately, but over time the core differences in the base kernel will be irrelevant. So you'll just be left with the issue of dynamically determining what hardware you're running on - which is a problem which already exists in HVM when you consider Xen vs KVM vs VMware vs VirtualBox. 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 Jun 12 17:44:38 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 12 Jun 2007 18:44:38 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <20070612152151.GJ3031@redhat.com> References: <1181344930.24324.198.camel@galia.watzmann.net> <20070611124655.GA19642@redhat.com> <1181588775.20651.60.camel@galia.watzmann.net> <20070612152151.GJ3031@redhat.com> Message-ID: <20070612174438.GP3031@redhat.com> On Tue, Jun 12, 2007 at 04:21:51PM +0100, Daniel P. Berrange wrote: > On Mon, Jun 11, 2007 at 12:06:15PM -0700, David Lutterkort wrote: > > > > And it seems a tad less yucky than having the appliance boot hvm, ask an > > XML-RPC server if pv is ok, and then booting pv. > > I wouldn't suggest that as an approach either. First of all we need to > realize that this whole problem space is basically just caused by the > Xen paravirt boot process - I don't like the idea creating an overly > complex metadata format to deal with the dumbassnmess of a particular > HV, particularly if there is active work to address this weakness of > Xen. > > Two alternatives I can think of. Basically assume a single filesystem > image, which contains /boot as part of the main FS. > > - When building the guest install both kernel & kernel-xen inside > the image. The /etc/grub.conf should contain the entries only > for the baremetal kernel. The paravirt kernel lines should be > in a separate /etc/pygrub.conf. Now adapt pygrub so that it > first looks for an /etc/pyrub.conf in the guest image. That way > if you boot under HVM, it automatically gets a baremetal kernel > and if you boot PV, it automatically gets Xen kernel. No separate > /boot required. > > - When building the guest install only provide a HVM kernel. In the > bundle containing the image & metadata, provide a separate Xen > kernel & initrd outside the context of the main filesystem. Boot > these directly instead of using pygrub. > > My preference would be option 1, using a separate pyrub.conf inside > the guest, so a single image can boot either. I've thought of a 3rd optio. - When building the guest install both kernel & kernel-xen inside the image. Have a regular /etc/grub.conf containing entries for both sets of kernels. Add some extra metadata flag against each entry indicating whether its a baremetal, or a paravirt image. Or perhaps have a 'default-xen=5' line to point to the Xenified kernel, while 'default=3' points to the baremetal kernel. So pygrub would look for the former in paravirt boot case, while regular grub would still look for the latter. Basically we just need some way to locate the paravirt kernel from the single main filesystem image 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 Jun 12 18:19:14 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 12 Jun 2007 11:19:14 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <20070612152151.GJ3031@redhat.com> References: <1181344930.24324.198.camel@galia.watzmann.net> <20070611124655.GA19642@redhat.com> <1181588775.20651.60.camel@galia.watzmann.net> <20070612152151.GJ3031@redhat.com> Message-ID: <1181672354.4234.59.camel@galia.watzmann.net> On Tue, 2007-06-12 at 16:21 +0100, Daniel P. Berrange wrote: > On Mon, Jun 11, 2007 at 12:06:15PM -0700, David Lutterkort wrote: > > Look at it from the user's point of view: Are you interested in a 'app > > foo appliance' or in a 'app foo for paravirt Xen w/ PAE support' > > appliance ? If you want to keep users from appreciating the finer points > > of this, you'll need to capture it in metadata. And you'll either make > > the distinction what you run when you download (one image per host > > 'type') or when you are about to run the image (one image for all host > > types) Should users really d/l a few 100 MB of stuff to discover that > > they should have clicked on the 'Xen pv w/ PAE' link rather than the > > 'Xen pv w/o PAE' link ? > > So this really raises the question of exactly what problem we're trying > to address here with the image tools. Are we > > a) Trying to come up with a way to build & describe a single image > which can be deployed to Xen PV, Xen HVM, KVM, VMWare + VirtualBox > > b) Merely trying to come up with a consistent packaging & metadata > scheme, allowing images to be built to target specific virt > platforms > > a) is really the superset of b), but I'm not sure how far we'll be able > to get with a) given the differences in the way all these different > virt platforms work & the types of hardware they expose. I would rephrase (a) as "How can we hide as many of the virt technology-specific details for running a VM image from the user as possible" ... ideally users would only need to know that they are running on a libvirt host, and get that image for it. > I can't help thinking its gonna take more than just a different boot kernel fiel > and initrd to be able to provide an image that works seemlessly on > all different virt platforms. Switching out one of the disks for pv vs. hvm lets you do more than that, and calling that disk /boot is probably misleading. It's a little bit like stateless, where almost all files come from one image, but a few select files are bind mounted into that image (for stateless, to make them writable, for virt images, to gloss over the differences between pv and fv, or other subtle differences in the future like whether pv drivers are available or not) > > And it seems a tad less yucky than having the appliance boot hvm, ask an > > XML-RPC server if pv is ok, and then booting pv. > > I wouldn't suggest that as an approach either. Nobody should ;) > First of all we need to > realize that this whole problem space is basically just caused by the > Xen paravirt boot process What about things like PAE vs. non-PAE ? Outside of pv Xen, can you always assume that your host can support both kinds of guests ? > - I don't like the idea creating an overly > complex metadata format to deal with the dumbassnmess of a particular > HV, particularly if there is active work to address this weakness of > Xen. To be clear: the complexity that would go away is (a) having multiple elements instead of just one and (possibly) (b) separating the description of disks into the section and how they are to be mapped into the guest, though I like this split, since there are certain things that are attributes of the disks, and others that are attributes of how those disks are mapped into the guest. The code that checks whether the image can be run on the host is valuable in itself, as that allows much better UI's than 'try to run it and see what happens' - unless we can always assume that any image can be run on any virtual host. > Two alternatives I can think of. Basically assume a single filesystem > image, which contains /boot as part of the main FS. > > - When building the guest install both kernel & kernel-xen inside > the image. The /etc/grub.conf should contain the entries only > for the baremetal kernel. The paravirt kernel lines should be > in a separate /etc/pygrub.conf. Now adapt pygrub so that it > first looks for an /etc/pyrub.conf in the guest image. That way > if you boot under HVM, it automatically gets a baremetal kernel > and if you boot PV, it automatically gets Xen kernel. No separate > /boot required. How do you deal with xvc0 ? You want an entry for it in /etc/inittab for pv Xen, but don't want it for hvm. Similarly, you mentioned that there may be driver/config differences ... if they can all be autodetected, that would of course be ideal. > - When building the guest install only provide a HVM kernel. In the > bundle containing the image & metadata, provide a separate Xen > kernel & initrd outside the context of the main filesystem. Boot > these directly instead of using pygrub. Although the image metadata allows it right now, I am not so fond of having the kernel/intird outside of the image, since you won't pick up updates that are done inside the image. > > > Is this even possible under Linux in the general case ? > > > > The first thing you run into when you have this setup is that inittab > > has an entry for xvc0 for pv, but that that entry gets in the way for > > fv. You can get around that by symlinking/bindmounting /etc/inittab into > > the /boot disk (which should probably not be called /boot disk anymore) > > Or running kudzu on every boot, so it detects & re-writes inittab > according to what console/serial lines are available. Actually I > think it should do this already. kudzu runs after init read inittab. > > > eg different Xorg configs - Cirrus vs fbdev, > > > > No idea; though I think not having to maintain n root images for n host > > types would be pretty attractive. > > > > > different filesystem names in /etc/fstab ? > > > > Mount-by-label or symlink/bindmount > > > > > Different kernel modules listed in /etc/sysconfig/ > > > 3. Yuk ! > > > 4. How do you generate the filesystems? If I'm using the Fedora live CD > > > creation tools to do a chroot based install and image generation, I > > > can choose to install kernel, or kernel-xen, or both. So I'll end up > > > with a /boot containing a HVM suitable kernel, or a paravirt kernel. > > > > I used a full virt-install. > > That wasn't quite what i was getting at - virt-install will build you an > image which does HVM or PV. It won't spit out a sepatrate 'boot' image > for each option. The best you could do was have your kickstart script do > an install of both kernel & kernel-xen inside the guest. That would give > you an image with both types of kernel available in /boot, but that's still > a single filesystem image you now have to take a chainsaw to, to create > your boot-hvm.img and boot-pv.img. Pretty much what I did. > Now depending on which you boot, your guest will fail an RPM verify on > either kernel, or kernel-xen because you had to rip it apart. No; I copied the one boot disk, mounted it and edited /etc/grub.conf. rpm won't trip over it. To reduce the overall image size, you could remove the unused kernel/intird from the boot disk, but, as you said, at the price of surprising rpm. > > > Most image generation tools won't even generate a separate image file > > > for /boot, just having one main rootfs. > > > > We'd need that ability anyway, e.g. to separate system from data disks > > for image-based updates. > > Data disks are a little easier to deal with - you simply splice in a data > disk at the approach part of the FS tree. The /boot thing is nasty becasue > you're taking a single directory & trying to munge it into 2 different > disks. I was talking about image generation tools creating more than one image file/disk. > We definitely need to figure out how to do this, because single unified kernel > is how Xen will be merged in LKML. Likewise for LGuest, or VMWare paravirtops. > Separate kernels are going the way of the dodo When will they get there ? > > > If people really want the ability to provide images in short term which do > > > both HVM and paravirt, then effort is better focused on making it easy for > > > the image creation tools to spit out two separate sets of image. > > > > Will unified kernels really do away with all the differences between hv > > and pv from the guest's POV ? > > Not immediately, but over time the core differences in the base kernel will > be irrelevant. So you'll just be left with the issue of dynamically determining > what hardware you're running on - which is a problem which already exists in > HVM when you consider Xen vs KVM vs VMware vs VirtualBox. BTW, nobody forces an image builder to do this splitting of boot; think of it as a compression: we simply stick one instead of two identical root fs's into the image that the user downloads. What I really care about is reducing the number of permutations for an appliance that the user needs to understand; and I'd rather have something that works, even if it's kludgy, today. If those kludges go away, even better. David From mizushima.kazuk at jp.fujitsu.com Wed Jun 13 08:12:41 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Wed, 13 Jun 2007 17:12:41 +0900 Subject: [et-mgmt-tools] [RFC]The Collision of LVM UUID by Cloning Message-ID: <023301c7ad92$9d6b8bd0$a1ec830a@dirac> Hi, I'd been testing the cloning by virt-clone. The isuue that wanted to discuss was found. It's Collision of LVM UUID(PV/VG/LV) between original guest and clone guest. This state may occur frequently because default installation is LVM constitution. Cloning aims at creating a just duplication as it except informations that must not overlap as a virtual machine. And it is necessary for a user to edit peculiar information of the OS and Middlewares. I think that this isuue is OS. So, my opinion is that it is OK. And I'd been checking a virtual machine statup normally. But I understand that a user cannot easily renew it and be slightly anxious for the upper product judging by LVM uuids. (I do not at least know.) Had better virt-clone changes those uuid or are there any another easy way/idea for a user ? Any comments are welcome ! Thanks, Kazuki Mizushima From markmc at redhat.com Wed Jun 13 08:21:01 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 13 Jun 2007 09:21:01 +0100 Subject: [et-mgmt-tools] [RFC]The Collision of LVM UUID by Cloning In-Reply-To: <023301c7ad92$9d6b8bd0$a1ec830a@dirac> References: <023301c7ad92$9d6b8bd0$a1ec830a@dirac> Message-ID: <1181722861.3533.34.camel@blaa> On Wed, 2007-06-13 at 17:12 +0900, Kazuki Mizushima wrote: > Hi, > > I'd been testing the cloning by virt-clone. > The isuue that wanted to discuss was found. > > It's Collision of LVM UUID(PV/VG/LV) between original > guest and clone guest. How exactly are you seeing this collision? Are you trying to mount the two guest images in Dom0 or ... ? In that case, the VG names will collide too, not just the PV UUID. Cheers, Mark. From fj1826dm at aa.jp.fujitsu.com Wed Jun 13 08:43:34 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Wed, 13 Jun 2007 17:43:34 +0900 Subject: [et-mgmt-tools] [PATCH] Fixes the error when Windows is installedwith "-- os-variant" option In-Reply-To: <200705310829.GAI18261.73KNE29G@aa.jp.fujitsu.com> References: <200705310829.GAI18261.73KNE29G@aa.jp.fujitsu.com> Message-ID: <200706131743.ACA93073.237KN9GE@aa.jp.fujitsu.com> Hi Would you give me a comment on this patch? If not, please apply it. Thanks, Masayuki Sunou. In message <200705310829.GAI18261.73KNE29G at aa.jp.fujitsu.com> "[et-mgmt-tools] [PATCH] Fixes the error when Windows is installedwith "-- os-variant" option" "Masayuki Sunou " wrote: > Hi > > When I install Windows with "-- os-variant" option, virt-install outputs the > following errors. > > -------------------------------------------------------------------------------- > # virt-install --name TEST --ram 256 --vnc --hvm --cdrom /mnt/WinSrv2k3sp1/Win2003_Sp1.iso > --os-type="windows" --os-variant="win2k" --file /dev/sda8 > > Starting install... > libvir: Xen Daemon error : GET operation failed: > Domain installation may not have been > successful. If it was, you can restart your domain > by running 'virsh start TEST'; otherwise, please > restart your installation. > Wed, 30 May 2007 13:05:57 ERROR 'distro' > Traceback (most recent call last): > File "/usr/bin/virt-install", line 647, in > main() > File "/usr/bin/virt-install", line 607, in main > dom = guest.start_install(conscb,progresscb) > File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 668, in start_install > self._prepare_install(meter) > File "/usr/lib/python2.5/site-packages/virtinst/FullVirtGuest.py", line 195, in _prepare_install > distro = self.os_distro) > File "/usr/lib/python2.5/site-packages/virtinst/FullVirtGuest.py", line 148, in get_os_distro > return FullVirtGuest.OS_TYPES[self.os_type]["variants"][self.os_variant]["distro""] > KeyError: 'distro' > -------------------------------------------------------------------------------- > > This patch fixes it. > > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. > > ------------------------------------------------------------------------------- > diff -r 7fd35e3303c6 virtinst/FullVirtGuest.py > --- a/virtinst/FullVirtGuest.py Fri May 25 10:49:47 2007 -0400 > +++ b/virtinst/FullVirtGuest.py Wed May 30 13:23:48 2007 +0900 > @@ -144,7 +144,7 @@ class FullVirtGuest(Guest.XenGuest): > self.features["apic"] = FullVirtGuest.OS_TYPES[os_type]["apic"] > > def get_os_distro(self): > - if self.os_type is not None and self.os_variant is not None: > + if self.os_type is not None and self.os_variant is not None and "distro" in FullVirtGuest.OS_TYPES[self.os_type]["variants"][self.os_variant]: > return FullVirtGuest.OS_TYPES[self.os_type]["variants"][self.os_variant]["distro"] > return None > os_distro = property(get_os_distro) > ------------------------------------------------------------------------------- > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From lippold at gmail.com Wed Jun 13 08:49:48 2007 From: lippold at gmail.com (Aaron Lippold) Date: Wed, 13 Jun 2007 10:49:48 +0200 Subject: [et-mgmt-tools] Re: Cheetah raw/endraw (was: Templating...) In-Reply-To: <466D9FA2.6080903@redhat.com> References: <466D7AA9.5020605@redhat.com> <39d2723b0706110951m5a0d9608n85bb615e8db272b2@mail.gmail.com> <39d2723b0706110954s44ab272asb049f55915cf42d6@mail.gmail.com> <466D9FA2.6080903@redhat.com> Message-ID: <39d2723b0706130149s675b459al4772b79f27e16689@mail.gmail.com> Hi, This looks perfect, since, if I was going to use placeholders, it would most likely be before the post section, and if I do need to use them I can use them at the top of %post, like MYVAR=$myvar .... then use #raw and I can still access ${MYVAR} ... I am thinking paths for /usr/sbin/,/sbin/, etc.... although my guess is they won't move stuff again from RHEL5 -> RHEL6. Thanks again, Aaron On 6/11/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > /s/When cheetah naturally/When I don't escape the ${var} cheetah/g > > > ... snip ... > > If you have large blocks of shell in %pre and %post, rather than > escaping them in Cheetah, I just discovered you can exclose them in #raw > ... #endraw blocks. > > http://www.cheetahtemplate.org/docs/users_guide_html/users_guide.html#SECTION000850000000000000000 > > If you have template variables (--ksmeta) that you want to access from > shell, you can assign them to shell variables in your %pre or %post > sections and > then use them from inside the raw sections. > > See example: > > === > > #!/usr/bin/python > > from Cheetah.Template import * > > # notice how I am setting foo and bar such that they'll be available in > the raw section... > data = """#errorCatcher Echo > \$foo = $foo > \$bar = $bar > #raw > if [ $(grep \" /home \" #echo "${FSTAB} | grep -c \"nosuid\") -eq 0 ]; > then" > # use $foo > # use $bar > #endraw > > > """ > > search = { > "foo" : "gleep", > "bar" : "gloop" > } > > t = Template(source=data, searchList=[search]) > > > print str(t) > > === > > This seems to me a lot cleaner than doing the escaping or needing to > understand the escaping rules. > > --Michael > > From Tom at maxxian.com Wed Jun 13 14:11:44 2007 From: Tom at maxxian.com (Tom Priore) Date: Wed, 13 Jun 2007 10:11:44 -0400 Subject: [et-mgmt-tools] Virtual Machine Manager 0.4.0 on Centos 5 Problems Message-ID: I have built and installed 0.4.0 on a Centos 5 system, and I'm having some issues. When I select new machine, nothing happens. This occurs while logged in as root. When logged in as a regular user, for some reason gnome-sudo doesnt kick in, so I dont even have the option for a new machine. Thanks Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Caetano at hp.com Wed Jun 13 16:57:20 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Wed, 13 Jun 2007 12:57:20 -0400 Subject: [et-mgmt-tools] Cobbler profile pxelinux text Message-ID: Is it possible with cobbler to not have the "ks=" or "autoyast=" kernel parameters added to the pxelinux menu for a given profile? I'm trying have a pxelinux boot entry for a firmware update option and am running into too long of a line for the append parameters. Thanks Greg Greg Caetano HP TSG Linux Solutions Alliances Engineering Chicago, IL greg.caetano at hp.com Red Hat Certified Engineer RHCE#803004972711193 From mdehaan at redhat.com Wed Jun 13 18:06:17 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Jun 2007 14:06:17 -0400 Subject: [et-mgmt-tools] Cobbler profile pxelinux text In-Reply-To: References: Message-ID: <46703219.9070500@redhat.com> Caetano, Greg wrote: > Is it possible with cobbler to not have the "ks=" or "autoyast=" kernel > parameters added to the pxelinux menu for a given profile? I'm trying > have a pxelinux boot entry for a firmware update option and am running > into too long of a line for the append parameters. > > Thanks > Greg > > > Greg Caetano > HP TSG Linux Solutions Alliances Engineering > Chicago, IL > greg.caetano at hp.com > Red Hat Certified Engineer > RHCE#803004972711193 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > That defeats the purpose of fully automatic installation, doesn't it? For PXE, the "ks=" line cannot be removed. However, yes, I think I can help you with your problem. If you have an older cobbler install that you've upgraded, you probably have a few kernel options in /var/lib/cobbler/settings which are not required and can be removed, but in newer installs, there aren't many that can be removed to save space. Current cobbler defaults to "lang= ksdevice=eth0 text" as default options. Also, for the last several cobbler releases, the kickstart arguments are shortened a good bit. It would probably be helpful to see what arguments are on your kernel command line (you can obtain this by reading /var/www/cobbler/profiles/$filename or looking at /tftpboot/pxelinux.cfg -- without seeing what you have, I can't really suggest what I would remove or what might be specifiable in kickstart instead of the kernel command line. Aside: As I mentioned above, koan doesn't use the ks= parameter for --replace-self. Why? Because in a lot of situations, DHCP timeouts cause problems, and in this case, we can help avoid them. What koan's --replace-self does is download the intended initrd, crack it open, and insert a kickstart file back into the initrd. So, technically, yes, this could be done in cobbler for PXE cases as well. However, there is a disadvantage to doing this: diskspace and long sync times. Cobbler sync would take about 30 seconds for each profile and system as it cracked open the files, and every profile and system would require storage of a custom initrd on the filesystem. This is very undesirable especially when managing thousands of systems. So, if you need to do reinstalls, use --replace-self, but embedding the kickstart in the initrd is not a good thing to perform client side. However, if this is something you are really interested in, patching cobbler to allow initrd managling is doable -- and I'd consider a patch to allow this as an option. Using it would require that minimize_syncs be disabled, so that synchronization (which would be really lengthy) could be run in batch. Anyhow, this isn't a super-great way to solve the length problem, and is a bit weird, so that's not ideal. As I've said, as I really don't know what your kernel command line options are, I can't tell why they are so long ... but maybe I can help if you share them. FYI -- if you can, send questions to et-mgmt-tools at redhat.com so more people can benefit from answers. If it's to be not showing @hp.com on a public list, a lot of folks use gmail accounts for this kind of thing. --Michael From mdehaan at redhat.com Wed Jun 13 18:07:41 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Jun 2007 14:07:41 -0400 Subject: [et-mgmt-tools] Cobbler profile pxelinux text In-Reply-To: <46703219.9070500@redhat.com> References: <46703219.9070500@redhat.com> Message-ID: <4670326D.7020509@redhat.com> Michael DeHaan wrote: > Caetano, Greg wrote: > Please ignore my please "send this to list" comment, I can't read, as it was sent to the list :) --Michael From hbrock at redhat.com Wed Jun 13 19:07:06 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 13 Jun 2007 15:07:06 -0400 Subject: [et-mgmt-tools] [PATCH] Fixes the error when Windows is installedwith "-- os-variant" option In-Reply-To: <200706131743.ACA93073.237KN9GE@aa.jp.fujitsu.com> References: <200705310829.GAI18261.73KNE29G@aa.jp.fujitsu.com> <200706131743.ACA93073.237KN9GE@aa.jp.fujitsu.com> Message-ID: <4670405A.5020504@redhat.com> Masayuki Sunou wrote: > Hi > > Would you give me a comment on this patch? > If not, please apply it. > > Thanks, > Masayuki Sunou. > > In message <200705310829.GAI18261.73KNE29G at aa.jp.fujitsu.com> > "[et-mgmt-tools] [PATCH] Fixes the error when Windows is installedwith "-- os-variant" option" > "Masayuki Sunou " wrote: > >> Hi >> >> When I install Windows with "-- os-variant" option, virt-install outputs the >> following errors. >> >> -------------------------------------------------------------------------------- >> # virt-install --name TEST --ram 256 --vnc --hvm --cdrom /mnt/WinSrv2k3sp1/Win2003_Sp1.iso >> --os-type="windows" --os-variant="win2k" --file /dev/sda8 >> >> Starting install... >> libvir: Xen Daemon error : GET operation failed: >> Domain installation may not have been >> successful. If it was, you can restart your domain >> by running 'virsh start TEST'; otherwise, please >> restart your installation. >> Wed, 30 May 2007 13:05:57 ERROR 'distro' >> Traceback (most recent call last): >> File "/usr/bin/virt-install", line 647, in >> main() >> File "/usr/bin/virt-install", line 607, in main >> dom = guest.start_install(conscb,progresscb) >> File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 668, in start_install >> self._prepare_install(meter) >> File "/usr/lib/python2.5/site-packages/virtinst/FullVirtGuest.py", line 195, in _prepare_install >> distro = self.os_distro) >> File "/usr/lib/python2.5/site-packages/virtinst/FullVirtGuest.py", line 148, in get_os_distro >> return FullVirtGuest.OS_TYPES[self.os_type]["variants"][self.os_variant]["distro""] >> KeyError: 'distro' >> -------------------------------------------------------------------------------- >> >> This patch fixes it. >> >> >> Signed-off-by: Masayuki Sunou >> >> Thanks, >> Masayuki Sunou. >> Sorry for the delay. Patch looks good, I have applied it. --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 Greg.Caetano at hp.com Wed Jun 13 19:15:14 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Wed, 13 Jun 2007 15:15:14 -0400 Subject: [et-mgmt-tools] Cobbler profile pxelinux text In-Reply-To: <46703219.9070500@redhat.com> References: <46703219.9070500@redhat.com> Message-ID: Michael: I'm doing out of band hardware configuration with automatic chain to a RH installation for new bare metal or possible out of band firmware updates then reboot to local boot. The syslinux stanza for the out of band toolkit is: label toolkit kernel vmlinuz append noapic initrd=initrd.img root=/dev/ram0 rw ramdisk_size=102400 ide=nodma ide=noraid pnpbios=off network=1 sstk_mount=10.100.100.1:/SSSTK sstk_mount_type=nfs sstk_mount_options=ro,nolock sstk_script=/scripts/deploy.sh Now I just manually update the pxelinux.cfg to get what I'm looking for. Greg -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Wednesday, June 13, 2007 1:06 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Cobbler profile pxelinux text Caetano, Greg wrote: > Is it possible with cobbler to not have the "ks=" or "autoyast=" kernel > parameters added to the pxelinux menu for a given profile? I'm trying > have a pxelinux boot entry for a firmware update option and am running > into too long of a line for the append parameters. > > Thanks > Greg > > > Greg Caetano > HP TSG Linux Solutions Alliances Engineering > Chicago, IL > greg.caetano at hp.com > Red Hat Certified Engineer > RHCE#803004972711193 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > That defeats the purpose of fully automatic installation, doesn't it? For PXE, the "ks=" line cannot be removed. However, yes, I think I can help you with your problem. If you have an older cobbler install that you've upgraded, you probably have a few kernel options in /var/lib/cobbler/settings which are not required and can be removed, but in newer installs, there aren't many that can be removed to save space. Current cobbler defaults to "lang= ksdevice=eth0 text" as default options. Also, for the last several cobbler releases, the kickstart arguments are shortened a good bit. It would probably be helpful to see what arguments are on your kernel command line (you can obtain this by reading /var/www/cobbler/profiles/$filename or looking at /tftpboot/pxelinux.cfg -- without seeing what you have, I can't really suggest what I would remove or what might be specifiable in kickstart instead of the kernel command line. Aside: As I mentioned above, koan doesn't use the ks= parameter for --replace-self. Why? Because in a lot of situations, DHCP timeouts cause problems, and in this case, we can help avoid them. What koan's --replace-self does is download the intended initrd, crack it open, and insert a kickstart file back into the initrd. So, technically, yes, this could be done in cobbler for PXE cases as well. However, there is a disadvantage to doing this: diskspace and long sync times. Cobbler sync would take about 30 seconds for each profile and system as it cracked open the files, and every profile and system would require storage of a custom initrd on the filesystem. This is very undesirable especially when managing thousands of systems. So, if you need to do reinstalls, use --replace-self, but embedding the kickstart in the initrd is not a good thing to perform client side. However, if this is something you are really interested in, patching cobbler to allow initrd managling is doable -- and I'd consider a patch to allow this as an option. Using it would require that minimize_syncs be disabled, so that synchronization (which would be really lengthy) could be run in batch. Anyhow, this isn't a super-great way to solve the length problem, and is a bit weird, so that's not ideal. As I've said, as I really don't know what your kernel command line options are, I can't tell why they are so long ... but maybe I can help if you share them. FYI -- if you can, send questions to et-mgmt-tools at redhat.com so more people can benefit from answers. If it's to be not showing @hp.com on a public list, a lot of folks use gmail accounts for this kind of thing. --Michael _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From hbrock at redhat.com Wed Jun 13 19:21:53 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 13 Jun 2007 15:21:53 -0400 Subject: [et-mgmt-tools] [PATCH] In virt-manager GUI, when the disk is added, VM cannot be started. In-Reply-To: <20070608113304.GC2473@redhat.com> References: <200706081657.EBD09820.N73KGE29@aa.jp.fujitsu.com> <20070608113304.GC2473@redhat.com> Message-ID: <467043D1.8000306@redhat.com> Daniel P. Berrange wrote: > On Fri, Jun 08, 2007 at 04:57:37PM +0900, Masayuki Sunou wrote: >> Hi >> >> When the disk is added to active VM by virt-manager, VM cannot be >> restarted after VM is stopped. >> --> Bugzilla Bug 239763 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239763 >> >> This patch fixes it. >> >> When the device is attached to active VM, virt-manager adds the device >> twice in add_device() of "domain.py". >> 1. Call attachDevice() >> 2. Call define_domain() after the XML is updated >> Therefore, the same device is doubly attached. >> (So, when the device is disk, VM cannot be started) >> >> This patch fixes "domain.py" as follows so that the same device is not >> doubly attached. >> VM is active : Call attachDevice() only > > It is implementation defined whether attachDevice() persists te changes > it makes. In Xen 3.1.0 it happens to persist them, but in earlier Xen > it does not. So we still need to use define_domain as well. > >> VM is inactive : Call define_domain() after the XML is updated >> >> >> Signed-off-by: Masayuki Sunou >> >> Thanks, >> Masayuki Sunou. >> >> ---------------------------------------------------------------------- >> diff -r 27ad8c7fbc3e src/virtManager/domain.py >> --- a/src/virtManager/domain.py Thu May 24 16:49:13 2007 -0400 >> +++ b/src/virtManager/domain.py Sat Jun 09 14:45:20 2007 +0900 >> @@ -540,15 +540,15 @@ class vmmDomain(gobject.GObject): >> >> if self.is_active(): >> self.vm.attachDevice(xml) >> - >> - vmxml = self.vm.XMLDesc(0) > > The key is that we should be calling vm.XMLDesc(0) before the call > to attachDevice() so we get the original XML prior to any device > addition. I'll add such a fix. > I have made this change, see http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=643e8d92e3cf --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 Wed Jun 13 19:26:58 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 13 Jun 2007 15:26:58 -0400 Subject: [et-mgmt-tools] [PATCH] [RESEND] Fix continue to install Windows In-Reply-To: <3293c1d10706100414p62741b00h3ed85feb3c6ff224@mail.gmail.com> References: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> <200706011105.EDI90101.H0O49K8G@aa.jp.fujitsu.com> <46659D01.2010503@redhat.com> <3293c1d10706100414p62741b00h3ed85feb3c6ff224@mail.gmail.com> Message-ID: <46704502.1060009@redhat.com> Source wrote: > When will this be available in fedora 7. any ideas ? > Couldn't tell you for sure, but we'll have at least a bug-fix release of virt-manager in the next few weeks and we'll push that to f7 as soon at it comes out. --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 Wed Jun 13 19:43:44 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 13 Jun 2007 15:43:44 -0400 Subject: [et-mgmt-tools] [PATCH] checking for file-size In-Reply-To: <20070607151404.1496.FUKUTA.SAORI@jp.fujitsu.com> References: <20070607151404.1496.FUKUTA.SAORI@jp.fujitsu.com> Message-ID: <467048F0.2080709@redhat.com> Saori Fukuta wrote: > Hi, > > I add to check for the file-size of the disk. > If the file-size is less than or equal to 0, it will show the following > message: > ERROR: Size of the disk image must be greater than 0 > and ask again. > > Signed-off-by: Saori Fukuta > > Thanks, > Saori Fukuta > > Applied, thanks! -- 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 steve at atc-nycorp.com Wed Jun 13 20:03:49 2007 From: steve at atc-nycorp.com (Steve Brueckner) Date: Wed, 13 Jun 2007 16:03:49 -0400 Subject: [et-mgmt-tools] Virt-manager won't connect to Xen hypervisor Message-ID: <60D45469A1AAD311A04C009027B6BF68061E5716@SERVER20> I've installed Fedora 7, Xen 3.1 (from source), and virt-manager 0.4 (from rpms). The machine is VMX/VT-x capable. I have managed to build and run a paravirtualized Linux guest just fine. Now I want to build an HVM Linux guest, but virt-manager tells me "unable to open a connection to the Xen hypervisor/daemon." I've confirmed that both xend and libvirtd are running. Here are the error details: ------------------->8------------------ Unable to open connection to hypervisor URI 'xen': virConnectOpenReadOnly() failed Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 68, in _connect_to_uri conn = self.get_connection(uri, readOnly) File "/usr/share/virt-manager/virtManager/engine.py", line 309, in get_connection conn = vmmConnection(self.get_config(), uri, readOnly) File "/usr/share/virt-manager/virtManager/connection.py", line 74, in __init__ self.vmm = libvirt.openReadOnly(openURI) File "/usr/lib/python2.5/site-packages/libvirt.py", line 109, in openReadOnly if ret is None:raise libvirtError('virConnectOpenReadOnly() failed') libvirtError: virConnectOpenReadOnly() failed -------------------8<------------------ Can anyone see what I'm missing or what's broken? If not, what should I do next to debug or fix this? Thanks, Steve Brueckner, ATC-NY From mdehaan at redhat.com Wed Jun 13 20:08:00 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Jun 2007 16:08:00 -0400 Subject: [et-mgmt-tools] Cobbler profile pxelinux text In-Reply-To: References: <46703219.9070500@redhat.com> Message-ID: <46704EA0.7000000@redhat.com> Caetano, Greg wrote: > Michael: > > I'm doing out of band hardware configuration with automatic chain to a > RH installation for new bare metal or possible out of band firmware > updates then reboot to local boot. > > The syslinux stanza for the out of band toolkit is: > > label toolkit > kernel vmlinuz > append noapic initrd=initrd.img root=/dev/ram0 rw ramdisk_size=102400 > ide=nodma ide=noraid pnpbios=off network=1 > sstk_mount=10.100.100.1:/SSSTK sstk_mount_type=nfs > sstk_mount_options=ro,nolock sstk_script=/scripts/deploy.sh > > Now I just manually update the pxelinux.cfg to get what I'm looking for. > > Greg Excellent, thanks for the explanation and I understand. So, basically this is a custom upgrade initrd? I can see what it would take to leave that option off --- it's not difficult. Perhaps the syntax would be "--kickstart=off" ... This makes sense when supporting things like memtest too.. --Michael From crobinso at redhat.com Wed Jun 13 20:59:04 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 13 Jun 2007 16:59:04 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager error msg fixup Message-ID: <46705A98.4030205@redhat.com> The error message that pops up when the user tries to enter an invalid guest name doesn't correctly list valid name characters (it was missing the '-'). Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: errmsg-cleanup1.patch Type: text/x-patch Size: 650 bytes Desc: not available URL: From hbrock at redhat.com Wed Jun 13 21:18:05 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 13 Jun 2007 17:18:05 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager error msg fixup In-Reply-To: <46705A98.4030205@redhat.com> References: <46705A98.4030205@redhat.com> Message-ID: <46705F0D.4010503@redhat.com> Cole Robinson wrote: > The error message that pops up when the user tries to enter an invalid > guest name doesn't correctly list valid name characters (it was missing > the '-'). > > Thanks, > Cole > > Applied, thanks! However: What we really want to do here is stop validating this stuff in virt-manager at all. We have validation both in virt-manager and virtinst and in a couple of places it disagrees... grr... What we should really do is abstract this kind of validation into virtinst/util.py I think, that way we have only one regex. If you want to have a crack at that, please be my guest... --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 Wed Jun 13 21:56:08 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 13 Jun 2007 17:56:08 -0400 Subject: [et-mgmt-tools] cdrom connect change Message-ID: <467067F8.1060302@redhat.com> I have just committed a change to python-virtinst that keeps the cdrom in the permanent XML for a guest after you install it. This solves the numerous "Why can't I get to the cdrom when windows asks for it for the 3rd time" issues that we have been working around. We have held off doing this up to now because it was not all that easy to get a guest to give up the cdrom once you had given it to the guest. Now, however, you can easily add and remove disks and network interface cards from virt-manager; you can do the same using virsh attach-device and remove-device commands. So it seems silly not to let a guest have the cdrom drive as long as it needs it and let the operator disconnect it once it is no longer needed. Enjoy, --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 Wed Jun 13 22:27:29 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Jun 2007 18:27:29 -0400 Subject: [et-mgmt-tools] Cobbler & inherited profiles Message-ID: <46706F51.8060804@redhat.com> I figured I would share a bit on what's been going on with upstream Cobbler lately. As Euclid suggested on IRC a while back, I'm moving Cobbler to a "even=stable, odd=unstable" release convention. This makes the current cobbler release 0.4.8 stable, and in a week or so, I'll push Cobbler 0.5.0 out to F7-testing (but not FC6, as it has no "testing" yet). There will be RPMs, but no Fedora-7 or FC-6 push. Not immediately, anyway. Why split off a testing release? Lots of new cool stuff coming in. The most notable feature is support for profile inheritance. A lot of the ideas for this suggestion came in from Adam Rosenwald (thanks, Adam) -- I believe there were some earlier discussions about this too, sorry I forget who was involved. Anyhow, this feature is illustrated as follows: cobbler profile add --name=xyz --virt-ram=512 --virt-size=5 --distro=distro_name --kickstart=/path cobbler profile add --name=xyz2 --inherit=xyz --virt-size=6 In the above example, cobbler profile p2 is going to be the same as p1, even when p1 changes, except for an override in the --virt-size parameter. This can be seen by looking at the saved cobbler profile files, where you'll see a lot of parameters are stored as "<>" which means, I don't have a setting, ask my parent. And yes, there can be any number of levels of inheritance. A further example: cobbler import --path=/mnt/dvdiso --name=FC-6 cobbler profile add --name=FC-6-xen-i386-webserver --inherit=FC-6-xen-i386 --kickstart=/path/to/special/kickstart cobbler profile add --name=FC-6-xen-i386-dbserver --inherit=FC-6-xen-i386 --kickstart=/path/to/another/kickstart cobbler profile edit --name=FC-6-xen-i386 --virt-ram=6 cobbler profile add --name=FC-6-xen-i386-webserver-more-disk --inherit=FC-6-xen-i386-webserver --virt-disk=10 cobbler sync In the above example, I've derived two profiles from the profile I get for free from the "cobbler import". I have assigned different kickstarts to both of them. Then, I go and edit their parent kickstart, and have, effectively, changed the --virt-ram value for both of them. A quick way to see what actually happens to the "calculated" values of FC-6-xen-i386-webserver-moredisk is to look at the file in /var/www/cobbler/profiles/$name ... you'll see all the values -- and the cool thing is, that in 0.5.0, every single one of these values is available in Cheetah templating -- which is fairly cool. This inheritance blending also works for ks_meta (templating) variables and kernel options. In those cases, you can add additional kernel options to existing options part of a parent profile, or you can override existing ones with new values. cobbler profile add --name=p1 ... cobbler profile add --name=p2 --inherit=p2 --ksmeta="moose=lodge" The above example would use all of the templating metadata values of p1, but would set the additional value of "moose" to the value "lodge". The implementation of the above is available now in git -- with only a bit of polishing still needed. Namely, awareness of cascade updates so running sync on the entire cobbler tree is not required after an edit to a parent node. When is this useful? The example Adam gave, and I think it's a good one, is if a site had multiple locations, with different policy rules between them, and one also wanted to have system roles (webserver, dbserver) underneath of each of these policies. An inheritance system makes something like this possible. Right now, only profiles are inheritable (not distros or systems), and it's only single inheritance. No, you should never need an OOP textbook to understand Cobbler. That would be wrong :) Questions? Comments? Fire away. (Note that Cobbler 0.5.0 also contains dnsmasq support (including DNS!), edit/copy/rename commands, and being able to name systems after things that aren't MAC addresses -- so, if you're interested in any of the above, check out the git repo) Thanks! --Michael From berrange at redhat.com Wed Jun 13 23:09:59 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 14 Jun 2007 00:09:59 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager error msg fixup In-Reply-To: <46705F0D.4010503@redhat.com> References: <46705A98.4030205@redhat.com> <46705F0D.4010503@redhat.com> Message-ID: <20070613230959.GC19779@redhat.com> On Wed, Jun 13, 2007 at 05:18:05PM -0400, Hugh Brock wrote: > Cole Robinson wrote: > >The error message that pops up when the user tries to enter an invalid > >guest name doesn't correctly list valid name characters (it was missing > >the '-'). > > > >Thanks, > >Cole > > > > > Applied, thanks! > > However: What we really want to do here is stop validating this stuff in > virt-manager at all. We have validation both in virt-manager and > virtinst and in a couple of places it disagrees... grr... What we should > really do is abstract this kind of validation into virtinst/util.py I > think, that way we have only one regex. Yes, we shoiuld have a 'virtinst/validation.py' module with functions for validating all the common things we check - virt-install is probably the best source for taking the validation code from - Fujitsu folks have put alot of effort into making sure the command line tools do full validation. 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 prime.provogue at gmail.com Thu Jun 14 00:15:21 2007 From: prime.provogue at gmail.com (Source) Date: Thu, 14 Jun 2007 05:45:21 +0530 Subject: [et-mgmt-tools] cdrom connect change In-Reply-To: <467067F8.1060302@redhat.com> References: <467067F8.1060302@redhat.com> Message-ID: <3293c1d10706131715q54c90faft6784597ca4fd6af2@mail.gmail.com> That's cool. Does that means that I can add or delete cd-rom device from within edit virtual machine within virt-manager. I saw that I can add storage devices from there. Thanks On 6/14/07, Hugh Brock wrote: > > I have just committed a change to python-virtinst that keeps the cdrom > in the permanent XML for a guest after you install it. This solves the > numerous "Why can't I get to the cdrom when windows asks for it for the > 3rd time" issues that we have been working around. > > We have held off doing this up to now because it was not all that easy > to get a guest to give up the cdrom once you had given it to the guest. > Now, however, you can easily add and remove disks and network interface > cards from virt-manager; you can do the same using virsh attach-device > and remove-device commands. So it seems silly not to let a guest have > the cdrom drive as long as it needs it and let the operator disconnect > it once it is no longer needed. > > Enjoy, > --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 > > _______________________________________________ > 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 fukuta.saori at jp.fujitsu.com Thu Jun 14 01:08:29 2007 From: fukuta.saori at jp.fujitsu.com (Saori Fukuta) Date: Thu, 14 Jun 2007 10:08:29 +0900 Subject: [et-mgmt-tools] [PATCH] checking for busy disk In-Reply-To: <20070606134018.E8D3.FUKUTA.SAORI@jp.fujitsu.com> References: <20070606134018.E8D3.FUKUTA.SAORI@jp.fujitsu.com> Message-ID: <20070614100556.301C.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 Wed, 06 Jun 2007 13:40:24 +0900 Saori Fukuta wrote: > Hi, > > The virt-install & virt-manager are checking if the physical device has > been using by other domain. But they does not check, when the device is > file or tap. > > So I add to check it. > > Signed-off-by: Saori Fukuta > > Thanks, > Saori Fukuta > > > diff -r 797e92fd5e0d virtinst/Guest.py > --- a/virtinst/Guest.py Thu May 31 14:20:33 2007 -0400 > +++ b/virtinst/Guest.py Wed Jun 06 11:34:33 2007 +0900 > @@ -163,6 +163,7 @@ class VirtualDisk: > try: > try: > count += ctx.xpathEval("count(/domain/devices/disk/source[@dev='%s'])" % self.path) > + count += ctx.xpathEval("count(/domain/devices/disk/source[@file='%s'])" % self.path) > except: > continue > finally: > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From fj0588di at aa.jp.fujitsu.com Thu Jun 14 05:23:03 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Thu, 14 Jun 2007 14:23:03 +0900 Subject: [et-mgmt-tools] An advantage to add VNC-Port setting when virt-manager creates VM In-Reply-To: <200706081441.GID09350.90EGJK69@aa.jp.fujitsu.com> References: <20070524014100.GC21564@redhat.com> <200705291644.JHC35443.96JEGK09@aa.jp.fujitsu.com> <20070530031136.GA15129@redhat.com> <200705311822.JEJ86930.0JK9G96E@aa.jp.fujitsu.com> <200706081441.GID09350.90EGJK69@aa.jp.fujitsu.com> Message-ID: <200706141423.HDH95893.JE9GK609@aa.jp.fujitsu.com> I compile my opinion simply. - Same as virt-install, I want to give a user the right that can select auto or fix in virt-manager. - At first, the authentication has nothing to do with a function that fix port number. Reason: > it would be desirable to only open up a port when explicitly needed, > and not require the admin to do any work. I think so too. but, as follows, I think that need to fix a port necessarily comes out. For example, When I have already used 5900-5920 about a port number (Use except vnc or use in vnc except virt-manager), Need to review a system using 5900 for comes out, when I install a guest with auto selection newly. With it, a review of the whole system may occur. In the case of an example, a manager will assign it to a new guest anything other than 5900-5920. Because a user can do operation & management that include setting of a port with virt-install, I think that we should give a user the right to be able to do operation & management with virt-manager. After having stood on these, Which thinks it to be big with an advantage when there is a function of fixed port selection and an advantage when there is not it? Thanks, Shigeki Sakamoto. <200706081441.GID09350.90EGJK69 at aa.jp.fujitsu.com> ?? "Re: [et-mgmt-tools] [PATCH] Add VNC-Port settingwhenvirt-managercreates VM" ????? ""S.Sakamoto" "????????? > Hi, Dan > > Would you give me a comment? > > > --- The summary of last time --- > The user who wants to manage GUEST from port number 9000 does not use the virt-manager > if it cannot choose a port at the time of use when he introduce GUEST. > > Even if the virt-manager is no matter how convenient, > this user will avoid use of the virt-manager because it forces him to allocate from 5600- . > > How do you think about this problem? > > I think that this user is not niche! > -------------------------------- > > thanks, > Shigeki Sakamoto. > > > <200705311822.JEJ86930.0JK9G96E at aa.jp.fujitsu.com> ?? > "Re: [et-mgmt-tools] [PATCH] Add VNC-Port setting whenvirt-managercreates VM" ????? > ""S.Sakamoto" "????????? > > > Hi > > > > An advantage of the fixed port which I want to insist on is "A user can choose an arbitrary port.". > > Neither remote-connection nor authentication matters particularly. It is a story before it. > > The reason why this user comes to need choice of a fixed port is as follows. > > > > > > If an user absolutely use the port number from 5900, either does not surely matter. > > But, > > for example, > > when the port number 5900-5920 is used by other uses, > > when there is a user hoping that I manage a port number by use to assign from 9000, > > > > A fxed port selection mode is necessary, because there is these situation. > > (The person who does not need a fixed port should choose an auto selection mode.) > > Any users will not hope to change other designs to use it for auto selection. > > > > > > Thanks, > > Shigeki Sakamoto. > > > > > > > > > On Tue, May 29, 2007 at 04:44:15PM +0900, S.Sakamoto wrote: > > > > Hi, Dan > > > > > > > > Thanks for your comment. > > > > > > > > > It will prove unreliable in practice, because even if you > > > > > fix a particular guest on port 5905, any other guest doing dynamic VNC port > > > > > assignment may choose this port before the hardcoded guest starts. > > > > This situation is surely thought. > > > > But, I think that problem is solved > > > > if it performs a repetition check of a port number in virt-inst. > > > > When it is this situation, at first, > > > > examine the port number that all other guests use when it starts a guest. > > > > Next, If the port number is fixed and repetition, > > > > output a message. [e.g."Repetition. Set a different port number."] > > > > (However, there is not a function setting a port for an existing guest now. > > > > If it is necessary at the same time, > > > > I make 'check of repetition' and 'function setting a port for an existing guest'.) > > > > > > > > > It is not going to be easy for virt-manager to do validation of this port number > > > > > either, since in the near future virt-manager may well be running remotely > > > > > from the host. > > > > If it adds a revision to libvirt side to get a port number from the information that acquired from xend, > > > > the acquisition of a port number will be easy. > > > > > > > > > this is a very small niche usecase > > > > I do not think so. and I think that there is a person to need surely. > > > > Because, I think that it can perform the prevention / maintenance > > > > by the pair of guest and port-number are managed. > > > > For example, The person who thinks about maintenance for the port which opened out > > > > had better be a fixed port number. > > > > If it does't know whether it has already opened or it will open out from now on, > > > > it will become difficult to deal with possibility of attack to an opening port. > > > > Therefore, > > > > the user who wants to open only a specific port for a firewall needs to fixed port number. > > > > And, even if it can get a dynamic port from remote connection in the future, > > > > he needs a fixed port number at the time of remote connection too, > > > > because he wants to connection with only a specific port. > > > > > > There's two possibilities to consider: > > > > > > a. The admin of the Dom0 permanently opens up a range of ports (eg 5900->5920) to allow > > > upto 20 vms to have their console accessed at any time. In this case, whether you > > > use fixed or dynamic ports per VM, you still need 20 ports open, to run 20 consoles. > > > > > > b. The admin of the Dom0 only opens specific ports for short periods of time. In this > > > case the admin will have to lookup what port corresponds to a VM, so it doesn't matter > > > whether we're using fixed or dynamic ports, the admin still has same amount of work > > > to lookup a port. > > > > > > So, I still don't see that using fixed ports in virt-manager has any benefit for the > > > administration POV. > > > > > > Neither of these two options are entirely satisfactory though - it would be desirable > > > to only open up a port when explicitly needed, and not require the admin to do any > > > work. One might even suggest that libvirt should have some form of API to let the > > > remote user request access to the cosnole - authenticated of course > > > > > > > > > virDomainAllowConsole(virDomainPtr, const char *ipaddr); > > > virDomainDisallowConsole(virDomainPtr, const char *ipaddr); > > > > > > Calling either of these functions would add neccessary iptables rule to allow > > > access to the console for that particular domain, from the specified ip address. > > > When the virConnectPtr object was closed, then any rules would also automatically > > > be removed. > > > > > > This would allow virt-manager to securely request access to the console without > > > needing permanent iptables rules. > > > > > > These's probably quite a bit more to think about wrt to iptables, consoles > > > and seecure authentication. In the very near future libvirt will have the > > > support for remote management merged and we'll be in a position to experiment > > > with these ideas for real. So I don't think we want to add support for fixed > > > port numbers in the virt-manager wizard until we've tried out some of these > > > ideas. > > > > > > 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 thestrider at gmail.com Thu Jun 14 07:23:24 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Thu, 14 Jun 2007 03:23:24 -0400 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <46706F51.8060804@redhat.com> References: <46706F51.8060804@redhat.com> Message-ID: <4670ECEC.4080304@gmail.com> Two questions: Question: What count as inheritable attributes? Naturally, --name is not inheritable. But what about --uuid or --disk-location (when these are later moved from koan to cobbler :) )? --disk-location might be unique on a given physical system X; i.e. once I provision virtual system Y on physical system X with --disk-location=Z, Z cannot be used as a disk location for any other virtual system on physical system X. But when the context shifts to more than one physical system, --disk-location can suddenly be an attribute worth inheriting, say, if all web servers (implemented as virtual systems) hosted on all physical systems use --disk-location=Z. Question: What are "reasonable defaults"? For instance, in the case of --vcpus, the default is currently set to "1" in koan. This isn't that great of an example, as --vcpus is not currently customizable without modifying koan code (BTW, an effort is being made to move virt attributes from koan to cobbler profiles, to address this issue). In some cases, perhaps the default attributes can be set to "DYNAMIC", where information gathered from proc or sysfs can fill in the values later on koan's end. In the --vcpus example, if the physical system only has one physical CPU (no hyperthreading, additional cores for the sake of argument), --vcpus should be one. If the physical system has multiple CPUs, cores, and/or hyperthreading, the dynamically-generated value can be computed on Koan's end. Disk size and RAM are other potential candidates for dynamic default values. The benefit of profile inheritance within the context of these questions is enormous, as entire data center provisioning topologies can be gotten from a simple "cobbler list". With profile inheritance, it may be beneficial to change the cobbler list functionality (or at least to provide an command-line argument) to provide a tree structure. This could, in essence, show something like the following crude picture (P being profiles without systems yet provisioned; S being systems): Data Center --------------- + | +-----------+subnet2+---------+functional group1+ | / \ | / \ | + + | P1 P2 + subnet1+--------+functional group2+----------+ + /|\ | / | \ | / | \ | / | \ | + + + | S1 S2 S3 + functional group3+-------+S4 ...where each branch is a profile and each leaf is either a system or a profile. As the number of profiles and systems grows, some organizational tool like the above (although much better than the above :) ) can help traverse the inheritance tree. Just a thought, - A. --- Great work, BTW, Michael. :) Can't wait for 0.6! Michael DeHaan wrote: > I figured I would share a bit on what's been going on with upstream > Cobbler lately. > > As Euclid suggested on IRC a while back, I'm moving Cobbler to a > "even=stable, odd=unstable" release convention. This makes the > current cobbler release 0.4.8 stable, and in a week or so, I'll push > Cobbler 0.5.0 out to F7-testing (but not FC6, as it has no "testing" > yet). There will be RPMs, but no Fedora-7 or FC-6 push. Not > immediately, anyway. > > Why split off a testing release? Lots of new cool stuff coming in. > The most notable feature is support for profile inheritance. A lot > of the ideas for this suggestion came in from Adam Rosenwald (thanks, > Adam) -- I believe there were some earlier discussions about this too, > sorry I forget who was involved. Anyhow, this feature is > illustrated as follows: > > cobbler profile add --name=xyz --virt-ram=512 --virt-size=5 > --distro=distro_name --kickstart=/path > cobbler profile add --name=xyz2 --inherit=xyz --virt-size=6 > > In the above example, cobbler profile p2 is going to be the same as > p1, even when p1 changes, except for an override in the --virt-size > parameter. This can be seen by looking at the saved cobbler profile > files, where you'll see a lot of parameters are stored as > "<>" which means, I don't have a setting, ask my parent. And > yes, there can be any number of levels of inheritance. > > A further example: > > cobbler import --path=/mnt/dvdiso --name=FC-6 > cobbler profile add --name=FC-6-xen-i386-webserver > --inherit=FC-6-xen-i386 --kickstart=/path/to/special/kickstart > cobbler profile add --name=FC-6-xen-i386-dbserver > --inherit=FC-6-xen-i386 --kickstart=/path/to/another/kickstart > cobbler profile edit --name=FC-6-xen-i386 --virt-ram=6 > cobbler profile add --name=FC-6-xen-i386-webserver-more-disk > --inherit=FC-6-xen-i386-webserver --virt-disk=10 > cobbler sync > > In the above example, I've derived two profiles from the profile I get > for free from the "cobbler import". I have assigned different > kickstarts to both of them. > Then, I go and edit their parent kickstart, and have, effectively, > changed the --virt-ram value for both of them. A quick way to see > what actually happens to the > "calculated" values of FC-6-xen-i386-webserver-moredisk is to look at > the file in /var/www/cobbler/profiles/$name ... you'll see all the > values -- and the cool thing is, > that in 0.5.0, every single one of these values is available in > Cheetah templating -- which is fairly cool. > > This inheritance blending also works for ks_meta (templating) > variables and kernel options. In those cases, you can add additional > kernel options to existing options part of a parent profile, or you > can override existing ones with new values. > > cobbler profile add --name=p1 ... > cobbler profile add --name=p2 --inherit=p2 --ksmeta="moose=lodge" > > The above example would use all of the templating metadata values of > p1, but would set the additional value of "moose" to the value "lodge". > > The implementation of the above is available now in git -- with only a > bit of polishing still needed. Namely, awareness of cascade updates > so running sync on the entire > cobbler tree is not required after an edit to a parent node. > > When is this useful? The example Adam gave, and I think it's a good > one, is if a site had multiple locations, with different policy rules > between them, and one also wanted to have system roles (webserver, > dbserver) underneath of each of these policies. An inheritance > system makes something like this possible. > > Right now, only profiles are inheritable (not distros or systems), and > it's only single inheritance. No, you should never need an OOP > textbook to understand Cobbler. That would be wrong :) > > Questions? Comments? Fire away. > > (Note that Cobbler 0.5.0 also contains dnsmasq support (including > DNS!), edit/copy/rename commands, and being able to name systems after > things that aren't MAC addresses -- so, if you're interested in any of > the above, check out the git repo) > > Thanks! > > --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 Thu Jun 14 07:32:39 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Thu, 14 Jun 2007 03:32:39 -0400 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <46706F51.8060804@redhat.com> References: <46706F51.8060804@redhat.com> Message-ID: <4670EF17.9080503@gmail.com> I should have known better than to draw a diagram on a mailing list. :) Please imagine what that /might/ have looked like if it made any sense. :) Michael DeHaan wrote: > I figured I would share a bit on what's been going on with upstream > Cobbler lately. > > As Euclid suggested on IRC a while back, I'm moving Cobbler to a > "even=stable, odd=unstable" release convention. This makes the > current cobbler release 0.4.8 stable, and in a week or so, I'll push > Cobbler 0.5.0 out to F7-testing (but not FC6, as it has no "testing" > yet). There will be RPMs, but no Fedora-7 or FC-6 push. Not > immediately, anyway. > > Why split off a testing release? Lots of new cool stuff coming in. > The most notable feature is support for profile inheritance. A lot > of the ideas for this suggestion came in from Adam Rosenwald (thanks, > Adam) -- I believe there were some earlier discussions about this too, > sorry I forget who was involved. Anyhow, this feature is > illustrated as follows: > > cobbler profile add --name=xyz --virt-ram=512 --virt-size=5 > --distro=distro_name --kickstart=/path > cobbler profile add --name=xyz2 --inherit=xyz --virt-size=6 > > In the above example, cobbler profile p2 is going to be the same as > p1, even when p1 changes, except for an override in the --virt-size > parameter. This can be seen by looking at the saved cobbler profile > files, where you'll see a lot of parameters are stored as > "<>" which means, I don't have a setting, ask my parent. And > yes, there can be any number of levels of inheritance. > > A further example: > > cobbler import --path=/mnt/dvdiso --name=FC-6 > cobbler profile add --name=FC-6-xen-i386-webserver > --inherit=FC-6-xen-i386 --kickstart=/path/to/special/kickstart > cobbler profile add --name=FC-6-xen-i386-dbserver > --inherit=FC-6-xen-i386 --kickstart=/path/to/another/kickstart > cobbler profile edit --name=FC-6-xen-i386 --virt-ram=6 > cobbler profile add --name=FC-6-xen-i386-webserver-more-disk > --inherit=FC-6-xen-i386-webserver --virt-disk=10 > cobbler sync > > In the above example, I've derived two profiles from the profile I get > for free from the "cobbler import". I have assigned different > kickstarts to both of them. > Then, I go and edit their parent kickstart, and have, effectively, > changed the --virt-ram value for both of them. A quick way to see > what actually happens to the > "calculated" values of FC-6-xen-i386-webserver-moredisk is to look at > the file in /var/www/cobbler/profiles/$name ... you'll see all the > values -- and the cool thing is, > that in 0.5.0, every single one of these values is available in > Cheetah templating -- which is fairly cool. > > This inheritance blending also works for ks_meta (templating) > variables and kernel options. In those cases, you can add additional > kernel options to existing options part of a parent profile, or you > can override existing ones with new values. > > cobbler profile add --name=p1 ... > cobbler profile add --name=p2 --inherit=p2 --ksmeta="moose=lodge" > > The above example would use all of the templating metadata values of > p1, but would set the additional value of "moose" to the value "lodge". > > The implementation of the above is available now in git -- with only a > bit of polishing still needed. Namely, awareness of cascade updates > so running sync on the entire > cobbler tree is not required after an edit to a parent node. > > When is this useful? The example Adam gave, and I think it's a good > one, is if a site had multiple locations, with different policy rules > between them, and one also wanted to have system roles (webserver, > dbserver) underneath of each of these policies. An inheritance > system makes something like this possible. > > Right now, only profiles are inheritable (not distros or systems), and > it's only single inheritance. No, you should never need an OOP > textbook to understand Cobbler. That would be wrong :) > > Questions? Comments? Fire away. > > (Note that Cobbler 0.5.0 also contains dnsmasq support (including > DNS!), edit/copy/rename commands, and being able to name systems after > things that aren't MAC addresses -- so, if you're interested in any of > the above, check out the git repo) > > Thanks! > > --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 hbrock at redhat.com Thu Jun 14 12:53:37 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 14 Jun 2007 08:53:37 -0400 Subject: [et-mgmt-tools] [PATCH] checking for busy disk In-Reply-To: <20070614100556.301C.FUKUTA.SAORI@jp.fujitsu.com> References: <20070606134018.E8D3.FUKUTA.SAORI@jp.fujitsu.com> <20070614100556.301C.FUKUTA.SAORI@jp.fujitsu.com> Message-ID: <46713A51.9050004@redhat.com> Saori Fukuta wrote: > Hi, > > Would you give me a comment on this patch ? > If everything is OK, please apply it. > > Thanks, > Saori Fukuta > > On Wed, 06 Jun 2007 13:40:24 +0900 Saori Fukuta wrote: >> Hi, >> >> The virt-install & virt-manager are checking if the physical device has >> been using by other domain. But they does not check, when the device is >> file or tap. >> >> So I add to check it. >> >> Signed-off-by: Saori Fukuta >> >> Thanks, >> Saori Fukuta >> >> Ahh, yes, thank you, I have applied it! --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 mizushima.kazuk at jp.fujitsu.com Thu Jun 14 13:14:51 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Thu, 14 Jun 2007 22:14:51 +0900 Subject: [et-mgmt-tools] [RFC]The Collision of LVM UUID by Cloning References: <023301c7ad92$9d6b8bd0$a1ec830a@dirac> <1181722861.3533.34.camel@blaa> Message-ID: <00f501c7ae85$fe0fcc00$a1ec830a@dirac> Hi, Mark Thanks for comments. > How exactly are you seeing this collision? Are you trying to mount the > two guest images in Dom0 or ... ? In that case, the VG names will > collide too, not just the PV UUID. Ahh, I might have made a mistake in the usage of "Collision". It means that a machine which has same Universally Unique IDentifier exits in the world. So, I checked by the command, pvdispay/vgdisplay/lvdisplay, on both original guest and clone guest. Surely, when mount(kpartx) the images form Dom-0, the VG names is collide, which is for a user op. In case of cloning the original guest used LVM which is one disk wholly, Domain-0 automatically notices the cloning guest disk of header(LVM), which I think the problem. Thanks, Kazuki Mizushima From crobinso at redhat.com Thu Jun 14 13:19:08 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 14 Jun 2007 09:19:08 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager error msg fixup In-Reply-To: <20070613230959.GC19779@redhat.com> References: <46705A98.4030205@redhat.com> <46705F0D.4010503@redhat.com> <20070613230959.GC19779@redhat.com> Message-ID: <4671404C.8060104@redhat.com> Daniel P. Berrange wrote: > On Wed, Jun 13, 2007 at 05:18:05PM -0400, Hugh Brock wrote: >> Cole Robinson wrote: >>> The error message that pops up when the user tries to enter an invalid >>> guest name doesn't correctly list valid name characters (it was missing >>> the '-'). >>> >>> Thanks, >>> Cole >>> >>> >> Applied, thanks! >> >> However: What we really want to do here is stop validating this stuff in >> virt-manager at all. We have validation both in virt-manager and >> virtinst and in a couple of places it disagrees... grr... What we should >> really do is abstract this kind of validation into virtinst/util.py I >> think, that way we have only one regex. > > Yes, we shoiuld have a 'virtinst/validation.py' module with functions > for validating all the common things we check - virt-install is probably > the best source for taking the validation code from - Fujitsu folks > have put alot of effort into making sure the command line tools do > full validation. > > Dan. Agreed. I'll start taking a look at it. - Cole -- Cole Robinson crobinso at redhat.com From steve at atc-nycorp.com Thu Jun 14 13:55:35 2007 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 14 Jun 2007 09:55:35 -0400 Subject: [et-mgmt-tools] How to report bugs? Message-ID: <60D45469A1AAD311A04C009027B6BF68061E5745@SERVER20> I want to report a bug for virt-manager, but I don't see a bug report link on either the virt-manager page or the emerging technology wiki. How can I report bugs? Steve Brueckner, ATC-NY From hbrock at redhat.com Thu Jun 14 13:58:12 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 14 Jun 2007 09:58:12 -0400 Subject: [et-mgmt-tools] How to report bugs? In-Reply-To: <60D45469A1AAD311A04C009027B6BF68061E5745@SERVER20> References: <60D45469A1AAD311A04C009027B6BF68061E5745@SERVER20> Message-ID: <46714974.4010006@redhat.com> Steve Brueckner wrote: > I want to report a bug for virt-manager, but I don't see a bug report link > on either the virt-manager page or the emerging technology wiki. How can I > report bugs? > > Steve Brueckner, ATC-NY > bugzilla.redhat.com will do nicely. What distro/virt-manager version? --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 steve at atc-nycorp.com Thu Jun 14 14:20:11 2007 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 14 Jun 2007 10:20:11 -0400 Subject: [et-mgmt-tools] How to report bugs? Message-ID: <60D45469A1AAD311A04C009027B6BF68061E574F@SERVER20> Hugh Brock wrote: > Steve Brueckner wrote: >> I want to report a bug for virt-manager, but I don't see a bug report >> link on either the virt-manager page or the emerging technology >> wiki. How can I report bugs? >> >> Steve Brueckner, ATC-NY >> > bugzilla.redhat.com will do nicely. What distro/virt-manager version? > > --Hugh Thanks, I'll post there (unless you can easily spot my problem: this is in reference to a post I made to this list yesterday around 1600EDT). I'm using FC7 and virt-manager 0.4.0-2.fc7, and virt-manager won't connect to the xen hypervisor. Steve Brueckner, ATC-NY From hbrock at redhat.com Thu Jun 14 14:27:40 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 14 Jun 2007 10:27:40 -0400 Subject: [et-mgmt-tools] Virt-manager won't connect to Xen hypervisor In-Reply-To: <60D45469A1AAD311A04C009027B6BF68061E5716@SERVER20> References: <60D45469A1AAD311A04C009027B6BF68061E5716@SERVER20> Message-ID: <4671505C.5020301@redhat.com> Steve Brueckner wrote: > I've installed Fedora 7, Xen 3.1 (from source), and virt-manager 0.4 (from > rpms). The machine is VMX/VT-x capable. I have managed to build and run a > paravirtualized Linux guest just fine. Now I want to build an HVM Linux > guest, but virt-manager tells me "unable to open a connection to the Xen > hypervisor/daemon." I've confirmed that both xend and libvirtd are running. > > Here are the error details: > > ------------------->8------------------ > Unable to open connection to hypervisor URI 'xen': > virConnectOpenReadOnly() failed > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/engine.py", line 68, in > _connect_to_uri > conn = self.get_connection(uri, readOnly) > File "/usr/share/virt-manager/virtManager/engine.py", line 309, in > get_connection > conn = vmmConnection(self.get_config(), uri, readOnly) > File "/usr/share/virt-manager/virtManager/connection.py", line 74, in > __init__ > self.vmm = libvirt.openReadOnly(openURI) > File "/usr/lib/python2.5/site-packages/libvirt.py", line 109, in > openReadOnly > if ret is None:raise libvirtError('virConnectOpenReadOnly() failed') > libvirtError: virConnectOpenReadOnly() failed > -------------------8<------------------ > > Can anyone see what I'm missing or what's broken? If not, what should I do > next to debug or fix this? > > Thanks, > > Steve Brueckner, ATC-NY We're going to need some more information: /var/log/xend/xend.log, /root/.virt-manager/virt-manager.log, and the libvirt version you are using. Are you using our xen 3.1 package (from Fedora 7) or XenSource's? 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 Thu Jun 14 14:53:51 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 14 Jun 2007 10:53:51 -0400 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <4670ECEC.4080304@gmail.com> References: <46706F51.8060804@redhat.com> <4670ECEC.4080304@gmail.com> Message-ID: <4671567F.8030105@redhat.com> Adam Rosenwald wrote: > Two questions: > > Question: What count as inheritable attributes? Naturally, --name is > not inheritable. But what about --uuid or --disk-location (when these > are later moved from koan to cobbler :) )? --disk-location might be > unique on a given physical system X; i.e. once I provision virtual > system Y on physical system X with --disk-location=Z, Z cannot be used > as a disk location for any other virtual system on physical system X. > But when the context shifts to more than one physical system, > --disk-location can suddenly be an attribute worth inheriting, say, if > all web servers (implemented as virtual systems) hosted on all > physical systems use --disk-location=Z. Currently everything except --name is inheritable. Items that hold hash data merge, arrays concatenate, and scalars override. Disk location? Here's how I would do it. Have a parameter in the cobbler profile called --default-disk-location. This would default to the value koan uses today (koan, if using different values, has to pay attention to SELinux contexts). This would be a path on the filesystem, for example a SAN mount point. koan would, if this path exists and is writable, would use that for image creation, instead of the current path in /var/lib/xen. LVM locations don't really make sense to be migrated around in Cobbler (as cobbler does not -- and shouldn't -- maintain storage inventory of host storage layout), could be specified by using a parameter in koan to override the storage configuration. If koan is invoked with --lvm=partition (or equivalent) it would install the disk image there instead, though migration capability would be sacrificed. Picking a free partition by default wouldn't be sane, but --lvm=auto could potentially contain special automatic to try, allowing koan to be used to install guests using LVM partitions from within kickstart %post sections for the dom0 (host). I can see that being useful. I am not sure why you would want explicit UUID control. Can you give an example? > > Question: What are "reasonable defaults"? For instance, in the case > of --vcpus, the default is currently set to "1" in koan. This isn't > that great of an example, as --vcpus is not currently customizable > without modifying koan code (BTW, an effort is being made to move virt > attributes from koan to cobbler profiles, to address this issue). In > some cases, perhaps the default attributes can be set to "DYNAMIC", > where information gathered from proc or sysfs can fill in the values > later on koan's end. In the --vcpus example, if the physical system > only has one physical CPU (no hyperthreading, additional cores for the > sake of argument), --vcpus should be one. If the physical system has > multiple CPUs, cores, and/or hyperthreading, the dynamically-generated > value can be computed on Koan's end. Disk size and RAM are other > potential candidates for dynamic default values. Disagree. One of the purposes of virtualization is the creation of a predictable and repeatable environment -- hardware isolation. If a cobbler profile defines a particular profile, that profile should dictate the requirements of the installation. Having them change based on the host would be a bit hard to predict, and we also do not know how many virtual guests are going to be installed on a given host. It is true that this information can be scaled after the fact, so rebalancing is possible. However, at install time, koan doesn't know what else you want to do with the rest of the box, and we don't want to suck up all the free RAM and that might be needed to install more virtual guests. Ideally koan would have command line options to override or supplement any specifications in a cobbler profile for installations in those environments. Don't get me wrong though -- these are good suggestions. They are perhaps much apt to apply to where we're going with Virt-Factory (http://virt-factory.et.redhat.com) than Cobbler though -- one of our longer term goals for that is to be able to define a cloud of virtual systems and have the management software make suggestions about where to deploy virtual machines and how to migrate/scale resources intelligently. Hard problem, but a very fun problem just the same :) To get there though, we have to assemble a bit more supporting infrastructure in that project first. > > The benefit of profile inheritance within the context of these > questions is enormous, as entire data center provisioning topologies > can be gotten from a simple "cobbler list". With profile inheritance, > it may be beneficial to change the cobbler list functionality (or at > least to provide an command-line argument) to provide a tree > structure. This could, in essence, show something like the following > crude picture (P being profiles without systems yet provisioned; S > being systems): It kind of already does that, though not entirely how you suggest... "cobbler list" It looks something like... distro $name profile $name profile $name system $name profile $name system $name > > Data Center > --------------- > + > | > +-----------+subnet2+---------+functional group1+ > | > / \ > | > / \ > | > + + > | > P1 P2 > + > subnet1+--------+functional group2+----------+ > + /|\ > | / > | \ > | / > | \ > | / > | \ > | + > + + > | S1 S2 S3 > + > functional group3+-------+S4 > > > ...where each branch is a profile and each leaf is either a system or > a profile. As the number of profiles and systems grows, some > organizational tool like the above (although much better than the > above :) ) can help traverse the inheritance tree. Three words: "cobbler generate graphviz" :) And, as much as I like charts and graphs, I'll probably have to do it :) --Michael > > Just a thought, > > - A. > > > --- > > Great work, BTW, Michael. :) Can't wait for 0.6! > > Michael DeHaan wrote: >> I figured I would share a bit on what's been going on with upstream >> Cobbler lately. >> >> As Euclid suggested on IRC a while back, I'm moving Cobbler to a >> "even=stable, odd=unstable" release convention. This makes the >> current cobbler release 0.4.8 stable, and in a week or so, I'll push >> Cobbler 0.5.0 out to F7-testing (but not FC6, as it has no "testing" >> yet). There will be RPMs, but no Fedora-7 or FC-6 push. Not >> immediately, anyway. >> >> Why split off a testing release? Lots of new cool stuff coming in. >> The most notable feature is support for profile inheritance. A lot >> of the ideas for this suggestion came in from Adam Rosenwald (thanks, >> Adam) -- I believe there were some earlier discussions about this >> too, sorry I forget who was involved. Anyhow, this feature is >> illustrated as follows: >> >> cobbler profile add --name=xyz --virt-ram=512 --virt-size=5 >> --distro=distro_name --kickstart=/path >> cobbler profile add --name=xyz2 --inherit=xyz --virt-size=6 >> >> In the above example, cobbler profile p2 is going to be the same as >> p1, even when p1 changes, except for an override in the --virt-size >> parameter. This can be seen by looking at the saved cobbler profile >> files, where you'll see a lot of parameters are stored as >> "<>" which means, I don't have a setting, ask my parent. >> And yes, there can be any number of levels of inheritance. >> >> A further example: >> >> cobbler import --path=/mnt/dvdiso --name=FC-6 >> cobbler profile add --name=FC-6-xen-i386-webserver >> --inherit=FC-6-xen-i386 --kickstart=/path/to/special/kickstart >> cobbler profile add --name=FC-6-xen-i386-dbserver >> --inherit=FC-6-xen-i386 --kickstart=/path/to/another/kickstart >> cobbler profile edit --name=FC-6-xen-i386 --virt-ram=6 >> cobbler profile add --name=FC-6-xen-i386-webserver-more-disk >> --inherit=FC-6-xen-i386-webserver --virt-disk=10 >> cobbler sync >> >> In the above example, I've derived two profiles from the profile I >> get for free from the "cobbler import". I have assigned different >> kickstarts to both of them. >> Then, I go and edit their parent kickstart, and have, effectively, >> changed the --virt-ram value for both of them. A quick way to see >> what actually happens to the >> "calculated" values of FC-6-xen-i386-webserver-moredisk is to look at >> the file in /var/www/cobbler/profiles/$name ... you'll see all the >> values -- and the cool thing is, >> that in 0.5.0, every single one of these values is available in >> Cheetah templating -- which is fairly cool. >> >> This inheritance blending also works for ks_meta (templating) >> variables and kernel options. In those cases, you can add additional >> kernel options to existing options part of a parent profile, or you >> can override existing ones with new values. >> >> cobbler profile add --name=p1 ... >> cobbler profile add --name=p2 --inherit=p2 --ksmeta="moose=lodge" >> >> The above example would use all of the templating metadata values of >> p1, but would set the additional value of "moose" to the value "lodge". >> >> The implementation of the above is available now in git -- with only >> a bit of polishing still needed. Namely, awareness of cascade >> updates so running sync on the entire >> cobbler tree is not required after an edit to a parent node. >> >> When is this useful? The example Adam gave, and I think it's a good >> one, is if a site had multiple locations, with different policy rules >> between them, and one also wanted to have system roles (webserver, >> dbserver) underneath of each of these policies. An inheritance >> system makes something like this possible. >> >> Right now, only profiles are inheritable (not distros or systems), >> and it's only single inheritance. No, you should never need an OOP >> textbook to understand Cobbler. That would be wrong :) >> >> Questions? Comments? Fire away. >> >> (Note that Cobbler 0.5.0 also contains dnsmasq support (including >> DNS!), edit/copy/rename commands, and being able to name systems >> after things that aren't MAC addresses -- so, if you're interested in >> any of the above, check out the git repo) >> >> Thanks! >> >> --Michael >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From steve at atc-nycorp.com Thu Jun 14 17:04:51 2007 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 14 Jun 2007 13:04:51 -0400 Subject: [et-mgmt-tools] Virt-manager won't connect to Xen hypervisor Message-ID: <60D45469A1AAD311A04C009027B6BF68061E577F@SERVER20> Hugh Brock wrote: > Steve Brueckner wrote: >> I've installed Fedora 7, Xen 3.1 (from source), and virt-manager 0.4 >> (from rpms). The machine is VMX/VT-x capable. I have managed to >> build and run a paravirtualized Linux guest just fine. Now I want to >> build an HVM Linux guest, but virt-manager tells me "unable to open a >> connection to the Xen hypervisor/daemon." I've confirmed that both >> xend and libvirtd are running. >> > We're going to need some more information: /var/log/xend/xend.log, > /root/.virt-manager/virt-manager.log, and the libvirt version you are > using. Are you using our xen 3.1 package (from Fedora 7) or > XenSource's? > I've attached the logs you requested, plus 4 xen config files in case the problem lies there. I get no messages in /var/log/xend/xend.log when trying to use virt- manager (not on app startup, not when error occurs, not on app shutdown). But there are a whole lot of warnings about failed API calls during initial xend startup. Since my first message, I have yum-updated my machine and now get a warning when starting virt-manager on the command line. This warning seems unrelated to the connection problem, however: -------------------->8------------------ ***MEMORY-WARNING***: virt-manager.py[4554]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... --------------------8<------------------ Here is my configuration: Fedora 7 (fully updated) Xen 3.1 (installed from XenSource tarball using vanilla kernel) python-virtinst-0.103.0-3.fc7 (installed from Fedora 7 rpm) libvirt-0.2.3-1.fc8 (installed from Fedora 7 rpm) libvirt-python-0.2.3-1.fc8 (installed from Fedora 7 rpm) virt-manager-0.4.0-2.fc7 (installed from Fedora 7 rpm) I had to install Xen from source because the Fedora 7 rpms didn't work on my hardware: dom0 wouldn't boot. This isn't the usual misconfigured grub or missing initrd or anything...this is an early hardware detection error. I've been dealing with such errors for a while: Linux doesn't always play nicely with the new Intel 965 boards and also gets confused by sata optical drives. It occurs to me that xend used to have 2 different connection options. Does it still? Do I need to change a setting in one of the xend, xm, or xenapi config files? Thanks, Steve Brueckner, ATC-NY -------------- next part -------------- A non-text attachment was scrubbed... Name: xm-config-xenapi.xml Type: application/octet-stream Size: 1545 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xm-config.xml Type: application/octet-stream Size: 1559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xend-config-xenapi.sxp Type: application/octet-stream Size: 7001 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xend-config.sxp Type: application/octet-stream Size: 7028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager.log Type: application/octet-stream Size: 1562 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xend.log Type: application/octet-stream Size: 3823 bytes Desc: not available URL: From berrange at redhat.com Thu Jun 14 17:06:13 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 14 Jun 2007 18:06:13 +0100 Subject: [et-mgmt-tools] Virt-manager won't connect to Xen hypervisor In-Reply-To: <60D45469A1AAD311A04C009027B6BF68061E577F@SERVER20> References: <60D45469A1AAD311A04C009027B6BF68061E577F@SERVER20> Message-ID: <20070614170613.GI13819@redhat.com> On Thu, Jun 14, 2007 at 01:04:51PM -0400, Steve Brueckner wrote: > Hugh Brock wrote: > > Steve Brueckner wrote: > >> I've installed Fedora 7, Xen 3.1 (from source), and virt-manager 0.4 > >> (from rpms). The machine is VMX/VT-x capable. I have managed to > >> build and run a paravirtualized Linux guest just fine. Now I want to > >> build an HVM Linux guest, but virt-manager tells me "unable to open a > >> connection to the Xen hypervisor/daemon." I've confirmed that both > >> xend and libvirtd are running. > >> > > We're going to need some more information: /var/log/xend/xend.log, > > /root/.virt-manager/virt-manager.log, and the libvirt version you are > > using. Are you using our xen 3.1 package (from Fedora 7) or > > XenSource's? > > > I've attached the logs you requested, plus 4 xen config files in case > the problem lies there. Indeed it does. You need to edit xend-config.sxp and set (xend-unix-server yes) And then reboot or restart xend. 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 steve at atc-nycorp.com Thu Jun 14 17:21:20 2007 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 14 Jun 2007 13:21:20 -0400 Subject: [et-mgmt-tools] Virt-manager won't connect to Xen hypervisor Message-ID: <60D45469A1AAD311A04C009027B6BF68061E5784@SERVER20> Daniel P. Berrange wrote: > On Thu, Jun 14, 2007 at 01:04:51PM -0400, Steve Brueckner wrote: >> Hugh Brock wrote: >>> Steve Brueckner wrote: >>>> I've installed Fedora 7, Xen 3.1 (from source), and virt-manager >>>> 0.4 (from rpms). The machine is VMX/VT-x capable. I have managed >>>> to build and run a paravirtualized Linux guest just fine. Now I >>>> want to build an HVM Linux guest, but virt-manager tells me "unable >>>> to open a connection to the Xen hypervisor/daemon." I've confirmed >>>> that both xend and libvirtd are running. >>>> >>> We're going to need some more information: /var/log/xend/xend.log, >>> /root/.virt-manager/virt-manager.log, and the libvirt version you >>> are using. Are you using our xen 3.1 package (from Fedora 7) or >>> XenSource's? >>> >> I've attached the logs you requested, plus 4 xen config files in case >> the problem lies there. > > Indeed it does. You need to edit xend-config.sxp and set > > (xend-unix-server yes) > > And then reboot or restart xend. Yup, that's it, thanks. I began to suspect it was something like this, but couldn't find any documentation about virt-manager's needs for connecting to xend. Is the XenSource tarball's default out of date and should they use the unix server by default? Or is this interface used only by some apps like virt-manager? Also, I don't know if you're worried about the secondary warning I got: ***MEMORY-WARNING***: virt-manager.py[4554]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... Thanks again, Steve Brueckner, ATC-NY From fj1826dm at aa.jp.fujitsu.com Fri Jun 15 01:29:07 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Fri, 15 Jun 2007 10:29:07 +0900 Subject: [et-mgmt-tools] [PATCH] Fix the maximum number of VCPU in virt-manager Message-ID: <200706151029.CHG56252.3NGK927E@aa.jp.fujitsu.com> Hi Although the maximum number of VCPU is different in each architecture, the maximum number of VCPU is 32 in virt-manager. ex: x86 - the maximum number of VCPU is 32 IA64 - the maximum number of VCPU is 64 This patch fixes it. Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- diff -r 24729fe72d52 src/virtManager/create.py --- a/src/virtManager/create.py Wed Jun 13 17:15:51 2007 -0400 +++ b/src/virtManager/create.py Sat Jun 16 09:31:13 2007 +0900 @@ -213,11 +213,13 @@ class vmmCreate(gobject.GObject): # If we don't have full-virt support disable the choice, and # display a message telling the user why it is not working if self.connection.get_type() == "QEMU": + self.window.get_widget("create-vcpus").get_adjustment().upper = 32 self.window.get_widget("virt-method-pv").set_sensitive(False) self.window.get_widget("virt-method-fv").set_active(True) self.window.get_widget("virt-method-fv-unsupported").hide() self.window.get_widget("virt-method-fv-disabled").hide() else: + self.window.get_widget("create-vcpus").get_adjustment().upper = self.connection.vmm.getMaxVcpus("Xen") self.window.get_widget("virt-method-pv").set_sensitive(True) self.window.get_widget("virt-method-pv").set_active(True) if virtinst.util.is_hvm_capable(): diff -r 24729fe72d52 src/virtManager/details.py --- a/src/virtManager/details.py Wed Jun 13 17:15:51 2007 -0400 +++ b/src/virtManager/details.py Sat Jun 16 09:31:06 2007 +0900 @@ -364,8 +364,13 @@ class vmmDetails(gobject.GObject): self.window.get_widget("state-host-cpus").set_text("%d" % self.vm.get_connection().host_active_processor_count()) status = self.vm.status() if status in [ libvirt.VIR_DOMAIN_SHUTOFF, libvirt.VIR_DOMAIN_CRASHED ]: - self.window.get_widget("config-vcpus").get_adjustment().upper = 32 - self.window.get_widget("state-vm-maxvcpus").set_text("32") + if self.vm.get_connection().get_type() == "QEMU": + self.window.get_widget("config-vcpus").get_adjustment().upper = 32 + self.window.get_widget("state-vm-maxvcpus").set_text("32") + else: + cpu_max = self.vm.get_connection().vmm.getMaxVcpus("Xen") + self.window.get_widget("config-vcpus").get_adjustment().upper = cpu_max + self.window.get_widget("state-vm-maxvcpus").set_text(str(cpu_max)) else: self.window.get_widget("config-vcpus").get_adjustment().upper = self.vm.vcpu_max_count() self.window.get_widget("state-vm-maxvcpus").set_text("%d" % (self.vm.vcpu_max_count())) -------------------------------------------------------------------------------- From lippold at gmail.com Fri Jun 15 17:03:58 2007 From: lippold at gmail.com (Aaron Lippold) Date: Fri, 15 Jun 2007 19:03:58 +0200 Subject: [et-mgmt-tools] Cobbler profile pxelinux text In-Reply-To: <46704EA0.7000000@redhat.com> References: <46703219.9070500@redhat.com> <46704EA0.7000000@redhat.com> Message-ID: <39d2723b0706151003k72a93966od05fce780e01d722@mail.gmail.com> Hi, I like to understand the topic being discussed below. Can someone point me to some docs. Thanks, Aaron On 6/13/07, Michael DeHaan wrote: > Caetano, Greg wrote: > > Michael: > > > > I'm doing out of band hardware configuration with automatic chain to a > > RH installation for new bare metal or possible out of band firmware > > updates then reboot to local boot. > > > > The syslinux stanza for the out of band toolkit is: > > > > label toolkit > > kernel vmlinuz > > append noapic initrd=initrd.img root=/dev/ram0 rw ramdisk_size=102400 > > ide=nodma ide=noraid pnpbios=off network=1 > > sstk_mount=10.100.100.1:/SSSTK sstk_mount_type=nfs > > sstk_mount_options=ro,nolock sstk_script=/scripts/deploy.sh > > > > Now I just manually update the pxelinux.cfg to get what I'm looking for. > > > > Greg > > Excellent, thanks for the explanation and I understand. > > So, basically this is a custom upgrade initrd? I can see what it would > take to leave that option off --- it's not difficult. > Perhaps the syntax would be "--kickstart=off" ... This makes sense when > supporting things like memtest too.. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From lippold at gmail.com Fri Jun 15 17:07:11 2007 From: lippold at gmail.com (Aaron Lippold) Date: Fri, 15 Jun 2007 19:07:11 +0200 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <46706F51.8060804@redhat.com> References: <46706F51.8060804@redhat.com> Message-ID: <39d2723b0706151007m6c7e4f29u7e746f99d5a42a65@mail.gmail.com> Hello, Is anyone working on the cobbler buildcd profile=x for 0.5.0? I know that was talked about and if I can help then I'd like to. Aaron On 6/14/07, Michael DeHaan wrote: > I figured I would share a bit on what's been going on with upstream > Cobbler lately. > > As Euclid suggested on IRC a while back, I'm moving Cobbler to a > "even=stable, odd=unstable" release convention. This makes the current > cobbler release 0.4.8 stable, and in a week or so, I'll push Cobbler > 0.5.0 out to F7-testing (but not FC6, as it has no "testing" yet). > There will be RPMs, but no Fedora-7 or FC-6 push. Not immediately, anyway. > > Why split off a testing release? Lots of new cool stuff coming in. > The most notable feature is support for profile inheritance. A lot of > the ideas for this suggestion came in from Adam Rosenwald (thanks, Adam) > -- I believe there were some earlier discussions about this too, sorry I > forget who was involved. Anyhow, this feature is illustrated as follows: > > cobbler profile add --name=xyz --virt-ram=512 --virt-size=5 > --distro=distro_name --kickstart=/path > cobbler profile add --name=xyz2 --inherit=xyz --virt-size=6 > > In the above example, cobbler profile p2 is going to be the same as p1, > even when p1 changes, except for an override in the --virt-size > parameter. > This can be seen by looking at the saved cobbler profile files, where > you'll see a lot of parameters are stored as "<>" which means, > I don't have a setting, ask my parent. And yes, there can be any number > of levels of inheritance. > > A further example: > > cobbler import --path=/mnt/dvdiso --name=FC-6 > cobbler profile add --name=FC-6-xen-i386-webserver > --inherit=FC-6-xen-i386 --kickstart=/path/to/special/kickstart > cobbler profile add --name=FC-6-xen-i386-dbserver > --inherit=FC-6-xen-i386 --kickstart=/path/to/another/kickstart > cobbler profile edit --name=FC-6-xen-i386 --virt-ram=6 > cobbler profile add --name=FC-6-xen-i386-webserver-more-disk > --inherit=FC-6-xen-i386-webserver --virt-disk=10 > cobbler sync > > In the above example, I've derived two profiles from the profile I get > for free from the "cobbler import". I have assigned different > kickstarts to both of them. > Then, I go and edit their parent kickstart, and have, effectively, > changed the --virt-ram value for both of them. A quick way to see what > actually happens to the > "calculated" values of FC-6-xen-i386-webserver-moredisk is to look at > the file in /var/www/cobbler/profiles/$name ... you'll see all the > values -- and the cool thing is, > that in 0.5.0, every single one of these values is available in Cheetah > templating -- which is fairly cool. > > This inheritance blending also works for ks_meta (templating) variables > and kernel options. In those cases, you can add additional kernel > options to existing options part of a parent profile, or you can > override existing ones with new values. > > cobbler profile add --name=p1 ... > cobbler profile add --name=p2 --inherit=p2 --ksmeta="moose=lodge" > > The above example would use all of the templating metadata values of p1, > but would set the additional value of "moose" to the value "lodge". > > The implementation of the above is available now in git -- with only a > bit of polishing still needed. Namely, awareness of cascade updates so > running sync on the entire > cobbler tree is not required after an edit to a parent node. > > When is this useful? The example Adam gave, and I think it's a good > one, is if a site had multiple locations, with different policy rules > between them, and one also wanted to have system roles (webserver, > dbserver) underneath of each of these policies. An inheritance system > makes something like this possible. > > Right now, only profiles are inheritable (not distros or systems), and > it's only single inheritance. No, you should never need an OOP textbook > to understand Cobbler. That would be wrong :) > > Questions? Comments? Fire away. > > (Note that Cobbler 0.5.0 also contains dnsmasq support (including DNS!), > edit/copy/rename commands, and being able to name systems after things > that aren't MAC addresses -- so, if you're interested in any of the > above, check out the git repo) > > Thanks! > > --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 Fri Jun 15 17:29:47 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 15 Jun 2007 13:29:47 -0400 Subject: [et-mgmt-tools] Cobbler profile pxelinux text In-Reply-To: <39d2723b0706151003k72a93966od05fce780e01d722@mail.gmail.com> References: <46703219.9070500@redhat.com> <46704EA0.7000000@redhat.com> <39d2723b0706151003k72a93966od05fce780e01d722@mail.gmail.com> Message-ID: <4672CC8B.1030605@redhat.com> Aaron Lippold wrote: The Linux kernel has a 255 character limit on kernel options. I'm coming up a bit short on the google links to articles on this, though it's a fairly well known item. > Hi, > > I like to understand the topic being discussed below. Can someone > point me to some docs. > > Thanks, > > Aaron > > On 6/13/07, Michael DeHaan wrote: >> Caetano, Greg wrote: >> > Michael: >> > >> > I'm doing out of band hardware configuration with automatic chain to a >> > RH installation for new bare metal or possible out of band firmware >> > updates then reboot to local boot. >> > >> > The syslinux stanza for the out of band toolkit is: >> > >> > label toolkit >> > kernel vmlinuz >> > append noapic initrd=initrd.img root=/dev/ram0 rw >> ramdisk_size=102400 >> > ide=nodma ide=noraid pnpbios=off network=1 >> > sstk_mount=10.100.100.1:/SSSTK sstk_mount_type=nfs >> > sstk_mount_options=ro,nolock sstk_script=/scripts/deploy.sh >> > >> > Now I just manually update the pxelinux.cfg to get what I'm looking >> for. >> > >> > Greg >> >> Excellent, thanks for the explanation and I understand. >> >> So, basically this is a custom upgrade initrd? I can see what it would >> take to leave that option off --- it's not difficult. >> Perhaps the syntax would be "--kickstart=off" ... This makes sense when >> supporting things like memtest too.. >> >> --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 hhoffman at ip-solutions.net Fri Jun 15 17:37:29 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 15 Jun 2007 13:37:29 -0400 (EDT) Subject: [et-mgmt-tools] Cobbler profile pxelinux text In-Reply-To: <4672CC8B.1030605@redhat.com> References: <46703219.9070500@redhat.com> <46704EA0.7000000@redhat.com> <39d2723b0706151003k72a93966od05fce780e01d722@mail.gmail.com> <4672CC8B.1030605@redhat.com> Message-ID: <46799.207.106.111.3.1181929049.squirrel@www.ip-solutions.net> I can't verify (right now) that it's in the man page but: man bootparam > Aaron Lippold wrote: > > The Linux kernel has a 255 character limit on kernel options. I'm > coming up a bit short on the google links to articles on this, though > it's a fairly well > known item. > >> Hi, >> >> I like to understand the topic being discussed below. Can someone >> point me to some docs. >> >> Thanks, >> >> Aaron >> >> On 6/13/07, Michael DeHaan wrote: >>> Caetano, Greg wrote: >>> > Michael: >>> > >>> > I'm doing out of band hardware configuration with automatic chain to >>> a >>> > RH installation for new bare metal or possible out of band firmware >>> > updates then reboot to local boot. >>> > >>> > The syslinux stanza for the out of band toolkit is: >>> > >>> > label toolkit >>> > kernel vmlinuz >>> > append noapic initrd=initrd.img root=/dev/ram0 rw >>> ramdisk_size=102400 >>> > ide=nodma ide=noraid pnpbios=off network=1 >>> > sstk_mount=10.100.100.1:/SSSTK sstk_mount_type=nfs >>> > sstk_mount_options=ro,nolock sstk_script=/scripts/deploy.sh >>> > >>> > Now I just manually update the pxelinux.cfg to get what I'm looking >>> for. >>> > >>> > Greg >>> >>> Excellent, thanks for the explanation and I understand. >>> >>> So, basically this is a custom upgrade initrd? I can see what it would >>> take to leave that option off --- it's not difficult. >>> Perhaps the syntax would be "--kickstart=off" ... This makes sense when >>> supporting things like memtest too.. >>> >>> --Michael >>> >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From mdehaan at redhat.com Fri Jun 15 17:40:20 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 15 Jun 2007 13:40:20 -0400 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <39d2723b0706151007m6c7e4f29u7e746f99d5a42a65@mail.gmail.com> References: <46706F51.8060804@redhat.com> <39d2723b0706151007m6c7e4f29u7e746f99d5a42a65@mail.gmail.com> Message-ID: <4672CF04.6080203@redhat.com> Aaron Lippold wrote: > Hello, > > Is anyone working on the cobbler buildcd profile=x for 0.5.0? I know > that was talked about and if I can help then I'd like to. > > Aaron Not yet that I'm aware of. I still think this would be great and you're welcome to start something. Possibly some way to integrate with Revisor (though I'm not sure Revisor will be able to deal with RHEL4/5)? See http://revisor.fedoraunity.org/ On a related subject -- I did know of one person looking at making a CD that would allow syslinux type PXE behavior without the need for DHCP blessed next-server, but that effort has apparently stalled. I still think this would be great -- just build a CD image with a hard-coded value for the location of the TFTP server ("cobbler build-netboot-cd"), which would have the machine go out and PXE itself without the need for PXE BIOS or a DHCP next-server entry. For instance, if your company had a PXE server on your network you didn't like, usage of this CD would allow you to install baremetal (using full PXE menus) from your own internal cobbler server. If no one else picks this up, I'll take a look at it somewhere down the pipe. I see there are existing floppy disk images that do this with the DHCP portion (for NICs that can't netboot), so all that seems required is hacking the DHCP parts out and allowing a config file (or equivalent) to specify the /tftpboot server -- so if you're sitting in your lab and office, you can network install off of an arbitrary cobbler server from bare metal without having to have the Cobbler server be blessed by DHCP. This wouldn't even have to be something Cobbler specific but would be insanely useful. The non-network install CD/DVD thing is useful too. --Michael From hbrock at redhat.com Fri Jun 15 18:03:30 2007 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 15 Jun 2007 14:03:30 -0400 Subject: [et-mgmt-tools] [PATCH] Fix the maximum number of VCPU in virt-manager In-Reply-To: <200706151029.CHG56252.3NGK927E@aa.jp.fujitsu.com> References: <200706151029.CHG56252.3NGK927E@aa.jp.fujitsu.com> Message-ID: <4672D472.8010900@redhat.com> Masayuki Sunou wrote: > Hi > > Although the maximum number of VCPU is different in each architecture, the > maximum number of VCPU is 32 in virt-manager. > > ex: > x86 - the maximum number of VCPU is 32 > IA64 - the maximum number of VCPU is 64 > > This patch fixes it. > > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. > Hmm, this is good, but I'm inclined to think it would be better to put a getMaxVcpus() call in connection.py and isolate the "check the connection type and either call getMaxVcpus or arbitrarily return '32'" there (so we don't repeat the code in two places). Also, it looks to me like "Xen" is the default in xen_unified.c, at least in current libvirt code, so you shouldn't need to supply "Xen" to the getMaxVcpus call. Can you redo the patch along these lines? Thanks so 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 mdehaan at redhat.com Fri Jun 15 18:27:40 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 15 Jun 2007 14:27:40 -0400 Subject: [et-mgmt-tools] Optional override of kickstart on a per-system-basis Message-ID: <4672DA1C.1060000@redhat.com> The following use case suggestion just came in from mbarr on IRC... Suppose you have a bunch of existing kickstarts, perhaps owned by a RHN satellite. The use case is that you want to use Cobbler to manage your PXE tree, and (possibly) DHCP. However, cobbler currently requires that kickstarts be assigned to a profile, but they can't be assigned to a system object. Why? Because cobbler *wants* you to think about profiles. However, this means you can't use Cobbler for PXE. Seems broken to me. In 0.5.0, this has changed and I finally decided to be a bit more flexible after hearing this request a few times. The use case is a good one. I still maintain that cobbler profiles and kickstart templating are more powerful than having a kickstart for each existing system, but for those people converting an infrastructure that has a lot of existing kickstarts for specific servers, Cobbler should support those -- as a way to migrate to a system that has templates and profiles that really serve to define the roles that individual systems should perform ("webserver", "dbserver", "etc") So the following is now possible: cobbler profile add --name=fc6-webserver--distro=abcd [--kickstart=/path/to/kickstart] cobbler system add --name=label --mac=AA:BB:CC:DD:EE:FF --profile=fc6-webserver --kickstart=/path/to/kickstart So basically it works like you'd expect, though before you had to put the --kickstart on the profile object always, and had no way to do a system specific kickstart file without creating a profile for that specific system. Any values to --ksmeta or --kopts or any of the virtual settings still work as you would expect. You can pass in a http://, nfs://, or ftp:// URL for --kickstart (like before), though, like before, these network locations will be treated as raw kickstarts to use directly and not templates. For new users of cobbler, I still highly recommend using profiles as an abstraction layer -- though if you have some existing kickstarts and aren't able to templatize them right away, it's still important that you can be able to do this. So that's why this was added. So, there you go... This is checked into the git repository for those interested. --Michael From lippold at gmail.com Sat Jun 16 23:22:40 2007 From: lippold at gmail.com (Aaron Lippold) Date: Sun, 17 Jun 2007 01:22:40 +0200 Subject: [et-mgmt-tools] RHEL5 Package Publication Message-ID: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> Hi, I was just wondering if there was a political issue around not building RHEL5 packages of Cobbler and KOAN. I have been building them anyway and would happy send the final rpms to the list for public consumption. Saves folks the trouble of going and downloading stuff and having to do the rebuild. Aaron From haircut at gmail.com Sun Jun 17 00:57:09 2007 From: haircut at gmail.com (Adam Monsen) Date: Sat, 16 Jun 2007 17:57:09 -0700 Subject: [et-mgmt-tools] KVM: praise for F7 virt-manager, virsh, automatically starting guests Message-ID: <9ebd65110706161757n7213aae3ge1df3ca064e7d4f7@mail.gmail.com> First of all, the improved virt-manager that comes with Fedora 7 is awesome! By simply clicking through the UI and exploring a bit I was able to learn how to create a functional bridged network to the LAN my host is on. I know naught about networking and this has traditionally been the most painful aspect for me when I was playing with virtualization some time ago. 1. Should virsh work with KVM in Fedora 7? When I run virsh I get only "virsh: error: failed to connect to the hypervisor" 2. What is the canonical/"out of the box" way to start a KVM-based guest when the host system boots? I'm fine with "just use /etc/rc.local" or whatever if the infrastructure isn't in place yet (if so, what command should I run?). But it would be nice to be able to manage the guest from virt-manager after starting it up from a script somehow. Thank you, -Adam -- Adam Monsen From berrange at redhat.com Sun Jun 17 16:09:20 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 17 Jun 2007 17:09:20 +0100 Subject: [et-mgmt-tools] KVM: praise for F7 virt-manager, virsh, automatically starting guests In-Reply-To: <9ebd65110706161757n7213aae3ge1df3ca064e7d4f7@mail.gmail.com> References: <9ebd65110706161757n7213aae3ge1df3ca064e7d4f7@mail.gmail.com> Message-ID: <20070617160920.GA12121@redhat.com> On Sat, Jun 16, 2007 at 05:57:09PM -0700, Adam Monsen wrote: > First of all, the improved virt-manager that comes with Fedora 7 is > awesome! By simply clicking through the UI and exploring a bit I was > able to learn how to create a functional bridged network to the LAN my > host is on. I know naught about networking and this has traditionally > been the most painful aspect for me when I was playing with > virtualization some time ago. Great - glad its working well for you ! > 1. Should virsh work with KVM in Fedora 7? When I run virsh I get only > "virsh: error: failed to connect to the hypervisor" You need to explicitly tell virsh to connect to QEMU/KVM since it defaults to Xen. virsh --connect qemu:///system Or export VIRSH_DEFAULT_CONNECT_URI=qemu:///system virsh > 2. What is the canonical/"out of the box" way to start a KVM-based > guest when the host system boots? I'm fine with "just use > /etc/rc.local" or whatever if the infrastructure isn't in place yet > (if so, what command should I run?). But it would be nice to be able > to manage the guest from virt-manager after starting it up from a > script somehow. We've not hooked up autostart to the virt-manager UI yet, in the meantime you can use virsh like this: virsh autostart [vm name] Th VM will be started by the libvirt daemon at boot time. 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 prime.provogue at gmail.com Sun Jun 17 16:37:53 2007 From: prime.provogue at gmail.com (Source) Date: Sun, 17 Jun 2007 22:07:53 +0530 Subject: [et-mgmt-tools] KVM: praise for F7 virt-manager, virsh, automatically starting guests In-Reply-To: <20070617160920.GA12121@redhat.com> References: <9ebd65110706161757n7213aae3ge1df3ca064e7d4f7@mail.gmail.com> <20070617160920.GA12121@redhat.com> Message-ID: <3293c1d10706170937r6ce15407ue22ead548c1ed3b5@mail.gmail.com> That info from you was nice. Was thinking of how to start the vm automatically at boot. On 6/17/07, Daniel P. Berrange wrote: > > On Sat, Jun 16, 2007 at 05:57:09PM -0700, Adam Monsen wrote: > > First of all, the improved virt-manager that comes with Fedora 7 is > > awesome! By simply clicking through the UI and exploring a bit I was > > able to learn how to create a functional bridged network to the LAN my > > host is on. I know naught about networking and this has traditionally > > been the most painful aspect for me when I was playing with > > virtualization some time ago. > > Great - glad its working well for you ! > > > 1. Should virsh work with KVM in Fedora 7? When I run virsh I get only > > "virsh: error: failed to connect to the hypervisor" > > You need to explicitly tell virsh to connect to QEMU/KVM since it > defaults to Xen. > > virsh --connect qemu:///system > > Or > > export VIRSH_DEFAULT_CONNECT_URI=qemu:///system > virsh > > > 2. What is the canonical/"out of the box" way to start a KVM-based > > guest when the host system boots? I'm fine with "just use > > /etc/rc.local" or whatever if the infrastructure isn't in place yet > > (if so, what command should I run?). But it would be nice to be able > > to manage the guest from virt-manager after starting it up from a > > script somehow. > > We've not hooked up autostart to the virt-manager UI yet, in the meantime > you can use virsh like this: > > virsh autostart [vm name] > > Th VM will be started by the libvirt daemon at boot time. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prime.provogue at gmail.com Sun Jun 17 16:39:13 2007 From: prime.provogue at gmail.com (Source) Date: Sun, 17 Jun 2007 22:09:13 +0530 Subject: [et-mgmt-tools] KVM: praise for F7 virt-manager, virsh, automatically starting guests In-Reply-To: <20070617160920.GA12121@redhat.com> References: <9ebd65110706161757n7213aae3ge1df3ca064e7d4f7@mail.gmail.com> <20070617160920.GA12121@redhat.com> Message-ID: <3293c1d10706170939i3ec0242cjdd3fd4eca7cf93a5@mail.gmail.com> On 6/17/07, Daniel P. Berrange wrote: > > On Sat, Jun 16, 2007 at 05:57:09PM -0700, Adam Monsen wrote: > > First of all, the improved virt-manager that comes with Fedora 7 is > > awesome! By simply clicking through the UI and exploring a bit I was > > able to learn how to create a functional bridged network to the LAN my > > host is on. I know naught about networking and this has traditionally > > been the most painful aspect for me when I was playing with > > virtualization some time ago. > > Great - glad its working well for you ! > > > 1. Should virsh work with KVM in Fedora 7? When I run virsh I get only > > "virsh: error: failed to connect to the hypervisor" > > You need to explicitly tell virsh to connect to QEMU/KVM since it > defaults to Xen. > > virsh --connect qemu:///system Can you please edit the man page of virsh and put on some e.g --connect strings over there. I know there are not too much like only kvm and xen are there but that is usually the first place everyone looks for before going somewhere else. Or > > export VIRSH_DEFAULT_CONNECT_URI=qemu:///system > virsh > > > 2. What is the canonical/"out of the box" way to start a KVM-based > > guest when the host system boots? I'm fine with "just use > > /etc/rc.local" or whatever if the infrastructure isn't in place yet > > (if so, what command should I run?). But it would be nice to be able > > to manage the guest from virt-manager after starting it up from a > > script somehow. > > We've not hooked up autostart to the virt-manager UI yet, in the meantime > you can use virsh like this: > > virsh autostart [vm name] > > Th VM will be started by the libvirt daemon at boot time. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fj1826dm at aa.jp.fujitsu.com Mon Jun 18 07:07:53 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Mon, 18 Jun 2007 16:07:53 +0900 Subject: [et-mgmt-tools] [PATCH] Fix the maximum number of VCPUin virt-manager In-Reply-To: <4672D472.8010900@redhat.com> References: <200706151029.CHG56252.3NGK927E@aa.jp.fujitsu.com><4672D472.8010900@redhat.com> Message-ID: <200706181607.CIJ13063.32N7EK9G@aa.jp.fujitsu.com> Hi Hugh Thank you for reviewing. I remake this patch. > Hmm, this is good, but I'm inclined to think it would be better to put a > getMaxVcpus() call in connection.py and isolate the "check the > connection type and either call getMaxVcpus or arbitrarily return '32'" > there (so we don't repeat the code in two places). Also, it looks to me > like "Xen" is the default in xen_unified.c, at least in current libvirt > code, so you shouldn't need to supply "Xen" to the getMaxVcpus call. Can > you redo the patch along these lines? > This patch changes as follows. 1. getMaxVcpus() is executed from connection.py. 2. getMaxVcpus() is called with the result of get_type() not "Xen" Thanks, Masayuki Sunou. =============================================================================== diff -r 24729fe72d52 src/virtManager/connection.py --- a/src/virtManager/connection.py Wed Jun 13 17:15:51 2007 -0400 +++ b/src/virtManager/connection.py Tue Jun 19 09:17:17 2007 +0900 @@ -223,6 +223,13 @@ class vmmConnection(gobject.GObject): def get_host_info(self): return self.hostinfo + def get_max_vcpus(self): + try: + return self.vmm.getMaxVcpus(self.get_type()) + except Exception, e: + logging.debug('Unable to get max vcpu') + return 32; + def connect(self, name, callback): handle_id = gobject.GObject.connect(self, name, callback) diff -r 24729fe72d52 src/virtManager/create.py --- a/src/virtManager/create.py Wed Jun 13 17:15:51 2007 -0400 +++ b/src/virtManager/create.py Tue Jun 19 09:19:26 2007 +0900 @@ -253,6 +253,7 @@ class vmmCreate(gobject.GObject): self.window.get_widget("create-memory-max").set_value(500) self.window.get_widget("create-memory-startup").set_value(500) self.window.get_widget("create-vcpus").set_value(1) + self.window.get_widget("create-vcpus").get_adjustment().upper = self.connection.get_max_vcpus() self.window.get_widget("non-sparse").set_active(True) model = self.window.get_widget("pv-media-url").get_model() self.populate_url_model(model, self.config.get_media_urls()) diff -r 24729fe72d52 src/virtManager/details.py --- a/src/virtManager/details.py Wed Jun 13 17:15:51 2007 -0400 +++ b/src/virtManager/details.py Tue Jun 19 09:07:49 2007 +0900 @@ -364,8 +364,9 @@ class vmmDetails(gobject.GObject): self.window.get_widget("state-host-cpus").set_text("%d" % self.vm.get_connection().host_active_processor_count()) status = self.vm.status() if status in [ libvirt.VIR_DOMAIN_SHUTOFF, libvirt.VIR_DOMAIN_CRASHED ]: - self.window.get_widget("config-vcpus").get_adjustment().upper = 32 - self.window.get_widget("state-vm-maxvcpus").set_text("32") + cpu_max = self.vm.get_connection().get_max_vcpus() + self.window.get_widget("config-vcpus").get_adjustment().upper = cpu_max + self.window.get_widget("state-vm-maxvcpus").set_text(str(cpu_max)) else: self.window.get_widget("config-vcpus").get_adjustment().upper = self.vm.vcpu_max_count() self.window.get_widget("state-vm-maxvcpus").set_text("%d" % (self.vm.vcpu_max_count())) =============================================================================== In message <4672D472.8010900 at redhat.com> "Re: [et-mgmt-tools] [PATCH] Fix the maximum number of VCPUin virt-manager" "Hugh Brock " wrote: > Masayuki Sunou wrote: > > Hi > > > > Although the maximum number of VCPU is different in each architecture, the > > maximum number of VCPU is 32 in virt-manager. > > > > ex: > > x86 - the maximum number of VCPU is 32 > > IA64 - the maximum number of VCPU is 64 > > > > This patch fixes it. > > > > > > Signed-off-by: Masayuki Sunou > > > > Thanks, > > Masayuki Sunou. > > > Hmm, this is good, but I'm inclined to think it would be better to put a > getMaxVcpus() call in connection.py and isolate the "check the > connection type and either call getMaxVcpus or arbitrarily return '32'" > there (so we don't repeat the code in two places). Also, it looks to me > like "Xen" is the default in xen_unified.c, at least in current libvirt > code, so you shouldn't need to supply "Xen" to the getMaxVcpus call. Can > you redo the patch along these lines? > > Thanks so 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 > > _______________________________________________ > 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 Jun 18 14:01:29 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 18 Jun 2007 10:01:29 -0400 Subject: [et-mgmt-tools] RHEL5 Package Publication In-Reply-To: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> References: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> Message-ID: <46769039.70503@redhat.com> Aaron Lippold wrote: > Hi, > > I was just wondering if there was a political issue around not > building RHEL5 packages of Cobbler and KOAN. Nope :) > I have been building them > anyway and would happy send the final rpms to the list for public > consumption. Saves folks the trouble of going and downloading stuff > and having to do the rebuild. > > Aaron David Lutterkort has a yum repository here that contains RHEL5 packages: http://people.redhat.com/~dlutter/yum/rhel5/ You'll still need to build python-cheetah and the setuputils piece as per the instructions on http://cobbler.et.redhat.com/download.php We're also waiting to see what happens with EPEL -- http://fedoraproject.org/wiki/EPEL > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From lippold at gmail.com Mon Jun 18 15:05:57 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 18 Jun 2007 17:05:57 +0200 Subject: [et-mgmt-tools] RHEL5 Package Publication In-Reply-To: <46769039.70503@redhat.com> References: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> <46769039.70503@redhat.com> Message-ID: <39d2723b0706180805v4fb3f9d2k1b0960b6348a11c0@mail.gmail.com> I'd contribute to that. I wonder if we could get the folks doing the rebuild of the nvidia and ati linux packages to contribute to the RHEL4/5 package set. On 6/18/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > Hi, > > > > I was just wondering if there was a political issue around not > > building RHEL5 packages of Cobbler and KOAN. > > Nope :) > > > I have been building them > > anyway and would happy send the final rpms to the list for public > > consumption. Saves folks the trouble of going and downloading stuff > > and having to do the rebuild. > > > > Aaron > > David Lutterkort has a yum repository here that contains RHEL5 > packages: http://people.redhat.com/~dlutter/yum/rhel5/ > > You'll still need to build python-cheetah and the setuputils piece as > per the instructions on http://cobbler.et.redhat.com/download.php > > We're also waiting to see what happens with EPEL -- > http://fedoraproject.org/wiki/EPEL > > > > _______________________________________________ > > 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 Greg.Caetano at hp.com Mon Jun 18 15:05:20 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Mon, 18 Jun 2007 11:05:20 -0400 Subject: [et-mgmt-tools] Limit to PXE menu? Message-ID: Is there a limit to the number of choices in the PXE menu when working with cobbler? Thanks Greg Greg Caetano HP TSG Linux Solutions Alliances Engineering From mdehaan at redhat.com Mon Jun 18 15:31:58 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 18 Jun 2007 11:31:58 -0400 Subject: [et-mgmt-tools] Limit to PXE menu? In-Reply-To: References: Message-ID: <4676A56E.1050601@redhat.com> Caetano, Greg wrote: > Is there a limit to the number of choices in the PXE menu when working > with cobbler? > > Thanks > Greg > > > Greg Caetano > HP TSG Linux Solutions Alliances Engineering > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > I vaguely recall reading that menu.c32 did have a limit on the number of menu options, possibly in the 1000's range. This would mean a limit on the number of cobbler profiles -- not cobbler sytems -- as systems don't show up in the menu. I can't seem to find any reference of that now online or in /usr/share/doc/syslinux-3.11 so I could be imagining. Either way, no one has bumped against any limit yet and reported it -- if they do, we can work on partitioning things via submenus. --Michael From mdehaan at redhat.com Mon Jun 18 15:38:42 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 18 Jun 2007 11:38:42 -0400 Subject: [et-mgmt-tools] RHEL5 Package Publication In-Reply-To: <39d2723b0706180805v4fb3f9d2k1b0960b6348a11c0@mail.gmail.com> References: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> <46769039.70503@redhat.com> <39d2723b0706180805v4fb3f9d2k1b0960b6348a11c0@mail.gmail.com> Message-ID: <4676A702.3060309@redhat.com> Aaron Lippold wrote: > I wonder if we could get the folks doing the > rebuild of the nvidia and ati linux packages to contribute to the > RHEL4/5 package set. If they become open-source, they won't have to :) Here's the mailing list to join to discuss that: http://www.redhat.com/mailman/listinfo/epel-devel-list > > On 6/18/07, Michael DeHaan wrote: >> Aaron Lippold wrote: >> > Hi, >> > >> > I was just wondering if there was a political issue around not >> > building RHEL5 packages of Cobbler and KOAN. >> >> Nope :) >> >> > I have been building them >> > anyway and would happy send the final rpms to the list for public >> > consumption. Saves folks the trouble of going and downloading stuff >> > and having to do the rebuild. >> > >> > Aaron >> >> David Lutterkort has a yum repository here that contains RHEL5 >> packages: http://people.redhat.com/~dlutter/yum/rhel5/ >> >> You'll still need to build python-cheetah and the setuputils piece as >> per the instructions on http://cobbler.et.redhat.com/download.php >> >> We're also waiting to see what happens with EPEL -- >> http://fedoraproject.org/wiki/EPEL >> >> >> > _______________________________________________ >> > 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 berrange at redhat.com Mon Jun 18 15:43:15 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 Jun 2007 16:43:15 +0100 Subject: [et-mgmt-tools] RHEL5 Package Publication In-Reply-To: <39d2723b0706180805v4fb3f9d2k1b0960b6348a11c0@mail.gmail.com> References: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> <46769039.70503@redhat.com> <39d2723b0706180805v4fb3f9d2k1b0960b6348a11c0@mail.gmail.com> Message-ID: <20070618154315.GB31305@redhat.com> On Mon, Jun 18, 2007 at 05:05:57PM +0200, Aaron Lippold wrote: > I'd contribute to that. I wonder if we could get the folks doing the > rebuild of the nvidia and ati linux packages to contribute to the > RHEL4/5 package set. Proprietry, binary only kernel modules have no place in Fedora or RHEL, so not gonna happen here. There's 3rd parties without connection to Fedora or RHEL who provide add-on packages who may have them. The Fedora approach is to assist & encourage development of open source drivers for ATI (avivo driver) and NVIDIA (nouveau driver) 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 lippold at gmail.com Mon Jun 18 15:48:09 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 18 Jun 2007 17:48:09 +0200 Subject: [et-mgmt-tools] RHEL5 Package Publication In-Reply-To: <20070618154315.GB31305@redhat.com> References: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> <46769039.70503@redhat.com> <39d2723b0706180805v4fb3f9d2k1b0960b6348a11c0@mail.gmail.com> <20070618154315.GB31305@redhat.com> Message-ID: <39d2723b0706180848t5c87f7bqa3d7caf7f56a470b@mail.gmail.com> Check. I didn't know about those projects. I just found the ones that made the nice RPMs that make my graphics cards not a two day compile battle :). How are those efforts progressing by the way? Aaron On 6/18/07, Daniel P. Berrange wrote: > On Mon, Jun 18, 2007 at 05:05:57PM +0200, Aaron Lippold wrote: > > I'd contribute to that. I wonder if we could get the folks doing the > > rebuild of the nvidia and ati linux packages to contribute to the > > RHEL4/5 package set. > > Proprietry, binary only kernel modules have no place in Fedora or RHEL, so > not gonna happen here. There's 3rd parties without connection to Fedora or > RHEL who provide add-on packages who may have them. > > The Fedora approach is to assist & encourage development of open source > drivers for ATI (avivo driver) and NVIDIA (nouveau driver) > > 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 berrange at redhat.com Mon Jun 18 15:50:04 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 Jun 2007 16:50:04 +0100 Subject: [et-mgmt-tools] RHEL5 Package Publication In-Reply-To: <39d2723b0706180848t5c87f7bqa3d7caf7f56a470b@mail.gmail.com> References: <39d2723b0706161622n46d19cb6m1badbd2465865c89@mail.gmail.com> <46769039.70503@redhat.com> <39d2723b0706180805v4fb3f9d2k1b0960b6348a11c0@mail.gmail.com> <20070618154315.GB31305@redhat.com> <39d2723b0706180848t5c87f7bqa3d7caf7f56a470b@mail.gmail.com> Message-ID: <20070618155004.GC31305@redhat.com> On Mon, Jun 18, 2007 at 05:48:09PM +0200, Aaron Lippold wrote: > Check. I didn't know about those projects. I just found the ones that > made the nice RPMs that make my graphics cards not a two day compile > battle :). > > How are those efforts progressing by the way? Fedora 7 included nouveau as a experimental option. avivo was first announced to world about 5 days ago :-) So not imediately useful, but it will be in 6 months time Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From lippold at gmail.com Mon Jun 18 15:51:14 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 18 Jun 2007 17:51:14 +0200 Subject: [et-mgmt-tools] SVN / CVS intagration w/ profiles Message-ID: <39d2723b0706180851x5cb4e71er1cc104d4d7604f68@mail.gmail.com> Hello All, Just wondering if anyone else would find it nice to have the ability to link a profile's ks with a file in SVN or CVS. i.e. say that Box1-testing profile could be linked to the 'current' revision of a ks in RCS and webserver could be linked to a 'taged' version of a file. etc. Just a thought as I debug and commit, debug, commit. Aaron From lippold at gmail.com Mon Jun 18 15:58:17 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 18 Jun 2007 17:58:17 +0200 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <4672CF04.6080203@redhat.com> References: <46706F51.8060804@redhat.com> <39d2723b0706151007m6c7e4f29u7e746f99d5a42a65@mail.gmail.com> <4672CF04.6080203@redhat.com> Message-ID: <39d2723b0706180858p3d4f1095u99043dddbba75115@mail.gmail.com> I'll take a look at it. I think the largest issue is going to be my lack of python skills. Where in the code should I start? This is going to be more of an issue for me soon because I just got my ks file as perfect as I can until some bugs are fixed on code outside my control. I was told to make the testing 'caveman simple' so 'plug in the cd' seems simple. Aaron On 6/15/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > Hello, > > > > Is anyone working on the cobbler buildcd profile=x for 0.5.0? I know > > that was talked about and if I can help then I'd like to. > > > > Aaron > > Not yet that I'm aware of. I still think this would be great and > you're welcome to start something. Possibly some way to integrate with > Revisor (though I'm not sure Revisor will be able to deal with > RHEL4/5)? See http://revisor.fedoraunity.org/ > > On a related subject -- I did know of one person looking at making a CD > that would allow syslinux type PXE behavior without the need for DHCP > blessed next-server, but that effort has apparently stalled. I still > think this would be great -- just build a CD image with a hard-coded > value for the location of the TFTP server ("cobbler build-netboot-cd"), > which would have the machine go out and PXE itself without the need for > PXE BIOS or a DHCP next-server entry. For instance, if your company > had a PXE server on your network you didn't like, usage of this CD would > allow you to install baremetal (using full PXE menus) from your own > internal cobbler server. If no one else picks this up, I'll take a > look at it somewhere down the pipe. > > I see there are existing floppy disk images that do this with the DHCP > portion (for NICs that can't netboot), so all that seems required is > hacking the DHCP parts out and allowing a config file (or equivalent) to > specify the /tftpboot server -- so if you're sitting in your lab and > office, you can network install off of an arbitrary cobbler server from > bare metal without having to have the Cobbler server be blessed by > DHCP. This wouldn't even have to be something Cobbler specific but > would be insanely useful. > > The non-network install CD/DVD thing is useful too. > > --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 Mon Jun 18 16:00:18 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 18 Jun 2007 12:00:18 -0400 Subject: [et-mgmt-tools] SVN / CVS intagration w/ profiles In-Reply-To: <39d2723b0706180851x5cb4e71er1cc104d4d7604f68@mail.gmail.com> References: <39d2723b0706180851x5cb4e71er1cc104d4d7604f68@mail.gmail.com> Message-ID: <4676AC12.9070303@redhat.com> Aaron Lippold wrote: > Hello All, > > Just wondering if anyone else would find it nice to have the ability > to link a profile's ks with a file in SVN or CVS. > > i.e. say that Box1-testing profile could be linked to the 'current' > revision of a ks in RCS and webserver could be linked to a 'taged' > version of a file. etc. Given these are accessed with seperate filesystem paths in SVN (due to the fact that SVN tags aren't implemented in a sane way), can't you already do this without needing specific functionality in cobbler? cobbler profile add --name=xyz-testing ... --kickstart=path/to/checkout/tags/testing/.../foo.ks cobbler profile add --name=xyz ... --kickstart= /path/to/checkout/tags/stable/../foo.ks As I've been using Distributed VCS's for the last year and a half nearly-exclusively I probably butchered the syntax, but that seems to be what you're getting at, right? > > Just a thought as I debug and commit, debug, commit. > > 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 Jun 18 16:08:13 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 18 Jun 2007 12:08:13 -0400 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <39d2723b0706180858p3d4f1095u99043dddbba75115@mail.gmail.com> References: <46706F51.8060804@redhat.com> <39d2723b0706151007m6c7e4f29u7e746f99d5a42a65@mail.gmail.com> <4672CF04.6080203@redhat.com> <39d2723b0706180858p3d4f1095u99043dddbba75115@mail.gmail.com> Message-ID: <4676ADED.7020602@redhat.com> Aaron Lippold wrote: > I'll take a look at it. I think the largest issue is going to be my > lack of python skills. Where in the code should I start? I'd check out Revisor's source and see how they build CD images, build something based on that. Also https://hosted.fedoraproject.org/projects/pungi This seems like it will almost certainly require a distribution that is pulled in via a "cobbler import" so that all of the tree data is there. It should also look at the cobbler profile to determine what other repositories ("cobbler repo add") have been added to it, and also put a copy of packages used in those repositories on the CD. You'd probably have to use something like pykickstart to parse the package list out of the kickstart to keep the CD images small -- or otherwise just require DVD usage. However pykickstart won't run on the templates directly. Instead, look in /var/lib/cobbler/kickstarts/$name and use the rendered template out of there for parsing/inclusion. I'd try this as a stand alone program using the cobbler API at first, and if useful, it can be integrated into Cobbler later. > > This is going to be more of an issue for me soon because I just got my > ks file as perfect as I can until some bugs are fixed on code outside > my control. > > I was told to make the testing 'caveman simple' so 'plug in the cd' > seems simple. > Not as simple to implement, unfortunately :) > Aaron > > On 6/15/07, Michael DeHaan wrote: >> Aaron Lippold wrote: >> > Hello, >> > >> > Is anyone working on the cobbler buildcd profile=x for 0.5.0? I know >> > that was talked about and if I can help then I'd like to. >> > >> > Aaron >> >> Not yet that I'm aware of. I still think this would be great and >> you're welcome to start something. Possibly some way to integrate with >> Revisor (though I'm not sure Revisor will be able to deal with >> RHEL4/5)? See http://revisor.fedoraunity.org/ >> >> On a related subject -- I did know of one person looking at making a CD >> that would allow syslinux type PXE behavior without the need for DHCP >> blessed next-server, but that effort has apparently stalled. I still >> think this would be great -- just build a CD image with a hard-coded >> value for the location of the TFTP server ("cobbler build-netboot-cd"), >> which would have the machine go out and PXE itself without the need for >> PXE BIOS or a DHCP next-server entry. For instance, if your company >> had a PXE server on your network you didn't like, usage of this CD would >> allow you to install baremetal (using full PXE menus) from your own >> internal cobbler server. If no one else picks this up, I'll take a >> look at it somewhere down the pipe. >> >> I see there are existing floppy disk images that do this with the DHCP >> portion (for NICs that can't netboot), so all that seems required is >> hacking the DHCP parts out and allowing a config file (or equivalent) to >> specify the /tftpboot server -- so if you're sitting in your lab and >> office, you can network install off of an arbitrary cobbler server from >> bare metal without having to have the Cobbler server be blessed by >> DHCP. This wouldn't even have to be something Cobbler specific but >> would be insanely useful. >> >> The non-network install CD/DVD thing is useful too. >> >> --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 lippold at gmail.com Mon Jun 18 16:13:57 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 18 Jun 2007 18:13:57 +0200 Subject: [et-mgmt-tools] SVN / CVS intagration w/ profiles In-Reply-To: <4676AC12.9070303@redhat.com> References: <39d2723b0706180851x5cb4e71er1cc104d4d7604f68@mail.gmail.com> <4676AC12.9070303@redhat.com> Message-ID: <39d2723b0706180913l21684792w83da4eaa0e8fe776@mail.gmail.com> Yup. But I assume we can say svn://login at asdlfkjalsdfj:/x/y/z --password right? I would assume most places will have the RCS on a seperate server than the cobbler box. Aaron On 6/18/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > Hello All, > > > > Just wondering if anyone else would find it nice to have the ability > > to link a profile's ks with a file in SVN or CVS. > > > > i.e. say that Box1-testing profile could be linked to the 'current' > > revision of a ks in RCS and webserver could be linked to a 'taged' > > version of a file. etc. > Given these are accessed with seperate filesystem paths in SVN (due to > the fact that SVN tags aren't implemented in a sane way), can't you > already do this without needing > specific functionality in cobbler? > > cobbler profile add --name=xyz-testing ... > --kickstart=path/to/checkout/tags/testing/.../foo.ks > cobbler profile add --name=xyz ... --kickstart= > /path/to/checkout/tags/stable/../foo.ks > > As I've been using Distributed VCS's for the last year and a half > nearly-exclusively I probably butchered the syntax, but that seems to be > what you're getting at, right? > > > > > > Just a thought as I debug and commit, debug, commit. > > > > Aaron > > > > _______________________________________________ > > 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 Mon Jun 18 16:17:02 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 18 Jun 2007 12:17:02 -0400 Subject: [et-mgmt-tools] SVN / CVS intagration w/ profiles In-Reply-To: <39d2723b0706180913l21684792w83da4eaa0e8fe776@mail.gmail.com> References: <39d2723b0706180851x5cb4e71er1cc104d4d7604f68@mail.gmail.com> <4676AC12.9070303@redhat.com> <39d2723b0706180913l21684792w83da4eaa0e8fe776@mail.gmail.com> Message-ID: <4676AFFE.4010908@redhat.com> Aaron Lippold wrote: > Yup. But I assume we can say svn://login at asdlfkjalsdfj:/x/y/z > --password right? > You can with "svn checkout" > I would assume most places will have the RCS on a seperate server than > the cobbler box. Tags and branch directories show up on the client. > > Aaron > > On 6/18/07, Michael DeHaan wrote: >> Aaron Lippold wrote: >> > Hello All, >> > >> > Just wondering if anyone else would find it nice to have the ability >> > to link a profile's ks with a file in SVN or CVS. >> > >> > i.e. say that Box1-testing profile could be linked to the 'current' >> > revision of a ks in RCS and webserver could be linked to a 'taged' >> > version of a file. etc. >> Given these are accessed with seperate filesystem paths in SVN (due to >> the fact that SVN tags aren't implemented in a sane way), can't you >> already do this without needing >> specific functionality in cobbler? >> >> cobbler profile add --name=xyz-testing ... >> --kickstart=path/to/checkout/tags/testing/.../foo.ks >> cobbler profile add --name=xyz ... --kickstart= >> /path/to/checkout/tags/stable/../foo.ks >> >> As I've been using Distributed VCS's for the last year and a half >> nearly-exclusively I probably butchered the syntax, but that seems to be >> what you're getting at, right? >> >> >> > >> > Just a thought as I debug and commit, debug, commit. >> > >> > Aaron >> > >> > _______________________________________________ >> > 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 lippold at gmail.com Mon Jun 18 16:16:19 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 18 Jun 2007 18:16:19 +0200 Subject: [et-mgmt-tools] Cobbler & inherited profiles In-Reply-To: <4676ADED.7020602@redhat.com> References: <46706F51.8060804@redhat.com> <39d2723b0706151007m6c7e4f29u7e746f99d5a42a65@mail.gmail.com> <4672CF04.6080203@redhat.com> <39d2723b0706180858p3d4f1095u99043dddbba75115@mail.gmail.com> <4676ADED.7020602@redhat.com> Message-ID: <39d2723b0706180916m53df9266v7f396046cd159251@mail.gmail.com> This really should be easier in life sometimes... Dying is easy, why can't life be? On 6/18/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > I'll take a look at it. I think the largest issue is going to be my > > lack of python skills. Where in the code should I start? > > I'd check out Revisor's source and see how they build CD images, build > something based on that. Also > https://hosted.fedoraproject.org/projects/pungi > > This seems like it will almost certainly require a distribution that is > pulled in via a "cobbler import" so that all of the tree data is there. > It should also > look at the cobbler profile to determine what other repositories > ("cobbler repo add") have been added to it, and also put a copy of > packages used in those > repositories on the CD. > > You'd probably have to use something like pykickstart to parse the > package list out of the kickstart to keep the > CD images small -- or otherwise just require DVD usage. However > pykickstart won't run on the templates directly. Instead, look in > /var/lib/cobbler/kickstarts/$name and use the rendered template out of > there for parsing/inclusion. > > I'd try this as a stand alone program using the cobbler API at first, > and if useful, it can be integrated into Cobbler later. > > > > > This is going to be more of an issue for me soon because I just got my > > ks file as perfect as I can until some bugs are fixed on code outside > > my control. > > > > I was told to make the testing 'caveman simple' so 'plug in the cd' > > seems simple. > > > > Not as simple to implement, unfortunately :) > > > > Aaron > > > > On 6/15/07, Michael DeHaan wrote: > >> Aaron Lippold wrote: > >> > Hello, > >> > > >> > Is anyone working on the cobbler buildcd profile=x for 0.5.0? I know > >> > that was talked about and if I can help then I'd like to. > >> > > >> > Aaron > >> > >> Not yet that I'm aware of. I still think this would be great and > >> you're welcome to start something. Possibly some way to integrate with > >> Revisor (though I'm not sure Revisor will be able to deal with > >> RHEL4/5)? See http://revisor.fedoraunity.org/ > >> > >> On a related subject -- I did know of one person looking at making a CD > >> that would allow syslinux type PXE behavior without the need for DHCP > >> blessed next-server, but that effort has apparently stalled. I still > >> think this would be great -- just build a CD image with a hard-coded > >> value for the location of the TFTP server ("cobbler build-netboot-cd"), > >> which would have the machine go out and PXE itself without the need for > >> PXE BIOS or a DHCP next-server entry. For instance, if your company > >> had a PXE server on your network you didn't like, usage of this CD would > >> allow you to install baremetal (using full PXE menus) from your own > >> internal cobbler server. If no one else picks this up, I'll take a > >> look at it somewhere down the pipe. > >> > >> I see there are existing floppy disk images that do this with the DHCP > >> portion (for NICs that can't netboot), so all that seems required is > >> hacking the DHCP parts out and allowing a config file (or equivalent) to > >> specify the /tftpboot server -- so if you're sitting in your lab and > >> office, you can network install off of an arbitrary cobbler server from > >> bare metal without having to have the Cobbler server be blessed by > >> DHCP. This wouldn't even have to be something Cobbler specific but > >> would be insanely useful. > >> > >> The non-network install CD/DVD thing is useful too. > >> > >> --Michael > >> > >> _______________________________________________ > >> et-mgmt-tools mailing list > >> et-mgmt-tools at redhat.com > >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > >> > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From lippold at gmail.com Mon Jun 18 16:19:21 2007 From: lippold at gmail.com (Aaron Lippold) Date: Mon, 18 Jun 2007 18:19:21 +0200 Subject: [et-mgmt-tools] SVN / CVS intagration w/ profiles In-Reply-To: <4676AFFE.4010908@redhat.com> References: <39d2723b0706180851x5cb4e71er1cc104d4d7604f68@mail.gmail.com> <4676AC12.9070303@redhat.com> <39d2723b0706180913l21684792w83da4eaa0e8fe776@mail.gmail.com> <4676AFFE.4010908@redhat.com> Message-ID: <39d2723b0706180919r1225f59dl72ef014dda800236@mail.gmail.com> I meant to say can't say: cobbler profile add --name=x --distro=y --kickstart=svn://x at y:/my/file I agree its trivial if I do a checkout. Maybe that makes more sense anyway because you'd be making a local copy anyway in /cobbler/kickstarts//ks.cfg. So, six of one, half dozen of the other. A On 6/18/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > Yup. But I assume we can say svn://login at asdlfkjalsdfj:/x/y/z > > --password right? > > > You can with "svn checkout" > > I would assume most places will have the RCS on a seperate server than > > the cobbler box. > Tags and branch directories show up on the client. > > > > > Aaron > > > > On 6/18/07, Michael DeHaan wrote: > >> Aaron Lippold wrote: > >> > Hello All, > >> > > >> > Just wondering if anyone else would find it nice to have the ability > >> > to link a profile's ks with a file in SVN or CVS. > >> > > >> > i.e. say that Box1-testing profile could be linked to the 'current' > >> > revision of a ks in RCS and webserver could be linked to a 'taged' > >> > version of a file. etc. > >> Given these are accessed with seperate filesystem paths in SVN (due to > >> the fact that SVN tags aren't implemented in a sane way), can't you > >> already do this without needing > >> specific functionality in cobbler? > >> > >> cobbler profile add --name=xyz-testing ... > >> --kickstart=path/to/checkout/tags/testing/.../foo.ks > >> cobbler profile add --name=xyz ... --kickstart= > >> /path/to/checkout/tags/stable/../foo.ks > >> > >> As I've been using Distributed VCS's for the last year and a half > >> nearly-exclusively I probably butchered the syntax, but that seems to be > >> what you're getting at, right? > >> > >> > >> > > >> > Just a thought as I debug and commit, debug, commit. > >> > > >> > Aaron > >> > > >> > _______________________________________________ > >> > et-mgmt-tools mailing list > >> > et-mgmt-tools at redhat.com > >> > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > >> > >> _______________________________________________ > >> et-mgmt-tools mailing list > >> et-mgmt-tools at redhat.com > >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > >> > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From hbrock at redhat.com Mon Jun 18 19:17:10 2007 From: hbrock at redhat.com (Hugh Brock) Date: Mon, 18 Jun 2007 15:17:10 -0400 Subject: [et-mgmt-tools] [PATCH] Fix the maximum number of VCPUin virt-manager In-Reply-To: <200706181607.CIJ13063.32N7EK9G@aa.jp.fujitsu.com> References: <200706151029.CHG56252.3NGK927E@aa.jp.fujitsu.com><4672D472.8010900@redhat.com> <200706181607.CIJ13063.32N7EK9G@aa.jp.fujitsu.com> Message-ID: <4676DA36.5010902@redhat.com> Masayuki Sunou wrote: > Hi Hugh > > Thank you for reviewing. > I remake this patch. > >> Hmm, this is good, but I'm inclined to think it would be better to put a >> getMaxVcpus() call in connection.py and isolate the "check the >> connection type and either call getMaxVcpus or arbitrarily return '32'" >> there (so we don't repeat the code in two places). Also, it looks to me >> like "Xen" is the default in xen_unified.c, at least in current libvirt >> code, so you shouldn't need to supply "Xen" to the getMaxVcpus call. Can >> you redo the patch along these lines? >> > This patch changes as follows. > 1. getMaxVcpus() is executed from connection.py. > 2. getMaxVcpus() is called with the result of get_type() not "Xen" > > Thanks, > Masayuki Sunou. > Thanks, I have applied this! --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 John.Sanabria at ece.uprm.edu Mon Jun 18 22:29:35 2007 From: John.Sanabria at ece.uprm.edu (John Sanabria) Date: Mon, 18 Jun 2007 18:29:35 -0400 (AST) Subject: [et-mgmt-tools] problem doing provision... Message-ID: <35322.136.145.116.114.1182205775.squirrel@ece.uprm.edu> Hi, i have two systems with fc6: shutdown.ece.uprm.edu (with updates) -> Linux shutdown 2.6.20-1.2952.fc6xen #1 SMP Wed May 16 19:19:04 EDT 2007 i686 i686 i386 GNU/Linux init.ece.uprm.edu (no recent updates) -> Linux init 2.6.19-1.2911.6.5.fc6xen #1 SMP Sun Mar 4 16:59:41 EST 2007 i686 i686 i386 GNU/Linux my problems appear when i decide update packages in shutdown machine. When execute the next command: cobbler enchant --virt=yes --address=shutdown.ece.uprm.edu --profile="base-box" i got the message at the end of this e-mail. However, everything works properly when execute this command: cobbler enchant --virt=yes --address=init.ece.uprm.edu --profile="base-box" What probably udpate crash the shutdown system? Do you need some specific details of the system in order to give a suggestion? thanks a lot for your attention, regards. +-------------+ |message error| +-------------+ - url=http://136.145.116.11libvir: error : configuration file syntax error: expecting a name Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/koan/app.py", line 97, in main k.run() File "/usr/lib/python2.4/site-packages/koan/app.py", line 152, in run self.do_virt() File "/usr/lib/python2.4/site-packages/koan/app.py", line 297, in do_virt return self.do_net_install("/tmp",after_download) File "/usr/lib/python2.4/site-packages/koan/app.py", line 253, in do_net_install after_download(self, distro_data, profile_data) File "/usr/lib/python2.4/site-packages/koan/app.py", line 296, in after_download self.do_virt_net_install(profile_data, distro_data) File "/usr/lib/python2.4/site-packages/koan/app.py", line 600, in do_virt_net_install extra=kextra File "/usr/lib/python2.4/site-packages/koan/virtcreate.py", line 102, in start_paravirt_install guest.start_install() File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 643, in start_install meter = progress.BaseMeter() 4/cobbler/images/xentemplate/vmlinuz - kernel saved = /tmp/vmlinuz - initrd saved = /tmp/initrd.img NameError: global name 'progress' is not defined returns: 3 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", line 101, in run self.ssh_exec("koan %s --profile=%s --server=%s" % (operation, self.profile, self.settings.server)) File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", line 57, in ssh_exec raise cexceptions.CobblerException("enchant_failed","ssh failure") CobblerException: 'enchant failed (ssh failure)' enchant failed (exception) http://ece.uprm.edu/~s047267 http://del.icio.us/josanabr http://blog-grid.blogspot.com From sakaia at jp.fujitsu.com Tue Jun 19 10:05:26 2007 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Tue, 19 Jun 2007 19:05:26 +0900 Subject: [et-mgmt-tools] An advantage to add VNC-Port setting whenvirt-manager creates VM In-Reply-To: <200706141423.HDH95893.JE9GK609@aa.jp.fujitsu.com> References: <200706141423.HDH95893.JE9GK609@aa.jp.fujitsu.com> Message-ID: <200706191005.l5JA5RTZ008242@fjmscan502.ms.jp.fujitsu.com> Hi, Dan The following issue is not Authenication (and not Security) issue. Just for usability issue. Shigeki just want to add a option for fixed port allocation. (addition with your suggested dynamic port.) I would be appreciated if you consider this issue. Thanks Atsushi SAKAI "S.Sakamoto" wrote: > I compile my opinion simply. > - Same as virt-install, > I want to give a user the right that can select auto or fix in virt-manager. > - At first, the authentication has nothing to do with a function that fix port number. > > > Reason: > > it would be desirable to only open up a port when explicitly needed, > > and not require the admin to do any work. > I think so too. > but, as follows, > I think that need to fix a port necessarily comes out. > > For example, > When I have already used 5900-5920 about a port number > (Use except vnc or use in vnc except virt-manager), > > Need to review a system using 5900 for comes out, > when I install a guest with auto selection newly. > With it, a review of the whole system may occur. > In the case of an example, > a manager will assign it to a new guest anything other than 5900-5920. > > > Because a user can do operation & management that include setting of a port with virt-install, > I think that we should give a user the right to be able to do operation & management with virt-manager. > > > After having stood on these, > Which thinks it to be big with an advantage when there is a function of fixed port selection > and an advantage when there is not it? > > > Thanks, > Shigeki Sakamoto. > > <200706081441.GID09350.90EGJK69 at aa.jp.fujitsu.com> ?? > "Re: [et-mgmt-tools] [PATCH] Add VNC-Port settingwhenvirt-managercreates VM" ????? > ""S.Sakamoto" "????????? > > > Hi, Dan > > > > Would you give me a comment? > > > > > > --- The summary of last time --- > > The user who wants to manage GUEST from port number 9000 does not use the virt-manager > > if it cannot choose a port at the time of use when he introduce GUEST. > > > > Even if the virt-manager is no matter how convenient, > > this user will avoid use of the virt-manager because it forces him to allocate from 5600- . > > > > How do you think about this problem? > > > > I think that this user is not niche! > > -------------------------------- > > > > thanks, > > Shigeki Sakamoto. > > > > > > <200705311822.JEJ86930.0JK9G96E at aa.jp.fujitsu.com> ?? > > "Re: [et-mgmt-tools] [PATCH] Add VNC-Port setting whenvirt-managercreates VM" ????? > > ""S.Sakamoto" "????????? > > > > > Hi > > > > > > An advantage of the fixed port which I want to insist on is "A user can choose an arbitrary port.". > > > Neither remote-connection nor authentication matters particularly. It is a story before it. > > > The reason why this user comes to need choice of a fixed port is as follows. > > > > > > > > > If an user absolutely use the port number from 5900, either does not surely matter. > > > But, > > > for example, > > > when the port number 5900-5920 is used by other uses, > > > when there is a user hoping that I manage a port number by use to assign from 9000, > > > > > > A fxed port selection mode is necessary, because there is these situation. > > > (The person who does not need a fixed port should choose an auto selection mode.) > > > Any users will not hope to change other designs to use it for auto selection. > > > > > > > > > Thanks, > > > Shigeki Sakamoto. > > > > > > > > > > > > > On Tue, May 29, 2007 at 04:44:15PM +0900, S.Sakamoto wrote: > > > > > Hi, Dan > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > It will prove unreliable in practice, because even if you > > > > > > fix a particular guest on port 5905, any other guest doing dynamic VNC port > > > > > > assignment may choose this port before the hardcoded guest starts. > > > > > This situation is surely thought. > > > > > But, I think that problem is solved > > > > > if it performs a repetition check of a port number in virt-inst. > > > > > When it is this situation, at first, > > > > > examine the port number that all other guests use when it starts a guest. > > > > > Next, If the port number is fixed and repetition, > > > > > output a message. [e.g."Repetition. Set a different port number."] > > > > > (However, there is not a function setting a port for an existing guest now. > > > > > If it is necessary at the same time, > > > > > I make 'check of repetition' and 'function setting a port for an existing guest'.) > > > > > > > > > > > It is not going to be easy for virt-manager to do validation of this port number > > > > > > either, since in the near future virt-manager may well be running remotely > > > > > > from the host. > > > > > If it adds a revision to libvirt side to get a port number from the information that acquired from xend, > > > > > the acquisition of a port number will be easy. > > > > > > > > > > > this is a very small niche usecase > > > > > I do not think so. and I think that there is a person to need surely. > > > > > Because, I think that it can perform the prevention / maintenance > > > > > by the pair of guest and port-number are managed. > > > > > For example, The person who thinks about maintenance for the port which opened out > > > > > had better be a fixed port number. > > > > > If it does't know whether it has already opened or it will open out from now on, > > > > > it will become difficult to deal with possibility of attack to an opening port. > > > > > Therefore, > > > > > the user who wants to open only a specific port for a firewall needs to fixed port number. > > > > > And, even if it can get a dynamic port from remote connection in the future, > > > > > he needs a fixed port number at the time of remote connection too, > > > > > because he wants to connection with only a specific port. > > > > > > > > There's two possibilities to consider: > > > > > > > > a. The admin of the Dom0 permanently opens up a range of ports (eg 5900->5920) to allow > > > > upto 20 vms to have their console accessed at any time. In this case, whether you > > > > use fixed or dynamic ports per VM, you still need 20 ports open, to run 20 consoles. > > > > > > > > b. The admin of the Dom0 only opens specific ports for short periods of time. In this > > > > case the admin will have to lookup what port corresponds to a VM, so it doesn't matter > > > > whether we're using fixed or dynamic ports, the admin still has same amount of work > > > > to lookup a port. > > > > > > > > So, I still don't see that using fixed ports in virt-manager has any benefit for the > > > > administration POV. > > > > > > > > Neither of these two options are entirely satisfactory though - it would be desirable > > > > to only open up a port when explicitly needed, and not require the admin to do any > > > > work. One might even suggest that libvirt should have some form of API to let the > > > > remote user request access to the cosnole - authenticated of course > > > > > > > > > > > > virDomainAllowConsole(virDomainPtr, const char *ipaddr); > > > > virDomainDisallowConsole(virDomainPtr, const char *ipaddr); > > > > > > > > Calling either of these functions would add neccessary iptables rule to allow > > > > access to the console for that particular domain, from the specified ip address. > > > > When the virConnectPtr object was closed, then any rules would also automatically > > > > be removed. > > > > > > > > This would allow virt-manager to securely request access to the console without > > > > needing permanent iptables rules. > > > > > > > > These's probably quite a bit more to think about wrt to iptables, consoles > > > > and seecure authentication. In the very near future libvirt will have the > > > > support for remote management merged and we'll be in a position to experiment > > > > with these ideas for real. So I don't think we want to add support for fixed > > > > port numbers in the virt-manager wizard until we've tried out some of these > > > > ideas. > > > > > > > > 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 > > > > _______________________________________________ > 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 Jun 19 14:20:21 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 19 Jun 2007 10:20:21 -0400 Subject: [et-mgmt-tools] problem doing provision... In-Reply-To: <35322.136.145.116.114.1182205775.squirrel@ece.uprm.edu> References: <35322.136.145.116.114.1182205775.squirrel@ece.uprm.edu> Message-ID: <4677E625.7010006@redhat.com> "NameError: global name 'progress' is not defined" What versions of virtinst does this machine have? This was fixed in virtinst some time ago, as I recall. John Sanabria wrote: > Hi, > > i have two systems with fc6: > > shutdown.ece.uprm.edu (with updates) -> Linux shutdown > 2.6.20-1.2952.fc6xen #1 SMP Wed May 16 19:19:04 EDT 2007 i686 i686 i386 > GNU/Linux > > init.ece.uprm.edu (no recent updates) -> Linux init > 2.6.19-1.2911.6.5.fc6xen #1 SMP Sun Mar 4 16:59:41 EST 2007 i686 i686 i386 > GNU/Linux > > > my problems appear when i decide update packages in shutdown machine. When > execute the next command: > > cobbler enchant --virt=yes --address=shutdown.ece.uprm.edu > --profile="base-box" > > i got the message at the end of this e-mail. However, everything works > properly when execute this command: > > cobbler enchant --virt=yes --address=init.ece.uprm.edu --profile="base-box" > > What probably udpate crash the shutdown system? Do you need some specific > details of the system in order to give a suggestion? > > thanks a lot for your attention, regards. > > +-------------+ > |message error| > +-------------+ > - url=http://136.145.116.11libvir: error : configuration file syntax > error: expecting a name > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/koan/app.py", line 97, in main > k.run() > File "/usr/lib/python2.4/site-packages/koan/app.py", line 152, in run > self.do_virt() > File "/usr/lib/python2.4/site-packages/koan/app.py", line 297, in do_virt > return self.do_net_install("/tmp",after_download) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 253, in > do_net_install > after_download(self, distro_data, profile_data) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 296, in > after_download > self.do_virt_net_install(profile_data, distro_data) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 600, in > do_virt_net_install > extra=kextra > File "/usr/lib/python2.4/site-packages/koan/virtcreate.py", line 102, in > start_paravirt_install > guest.start_install() > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 643, in > start_install > meter = progress.BaseMeter() > 4/cobbler/images/xentemplate/vmlinuz > - kernel saved = /tmp/vmlinuz > - initrd saved = /tmp/initrd.img > NameError: global name 'progress' is not defined > returns: 3 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", line > 101, in run > self.ssh_exec("koan %s --profile=%s --server=%s" % (operation, > self.profile, self.settings.server)) > File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", line > 57, in ssh_exec > raise cexceptions.CobblerException("enchant_failed","ssh failure") > CobblerException: 'enchant failed (ssh failure)' > enchant failed (exception) > > > http://ece.uprm.edu/~s047267 > http://del.icio.us/josanabr > http://blog-grid.blogspot.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From John.Sanabria at ece.uprm.edu Tue Jun 19 14:23:19 2007 From: John.Sanabria at ece.uprm.edu (John Sanabria) Date: Tue, 19 Jun 2007 10:23:19 -0400 (AST) Subject: [et-mgmt-tools] problem doing provision... In-Reply-To: <4677E625.7010006@redhat.com> References: <35322.136.145.116.114.1182205775.squirrel@ece.uprm.edu> <4677E625.7010006@redhat.com> Message-ID: <59875.136.145.116.114.1182262999.squirrel@ece.uprm.edu> > "NameError: global name 'progress' is not defined" > > What versions of virtinst does this machine have? > > This was fixed in virtinst some time ago, as I recall. > sorry, is highly probably that i had create a mix of incompatible versions between virtualization components (xen, virtinst, libvirt, kernel with xen, and so on). however, thanks, i learn that is not convenient update the Dom0 machines :-D regards. > > > John Sanabria wrote: >> Hi, >> >> i have two systems with fc6: >> >> shutdown.ece.uprm.edu (with updates) -> Linux shutdown >> 2.6.20-1.2952.fc6xen #1 SMP Wed May 16 19:19:04 EDT 2007 i686 i686 i386 >> GNU/Linux >> >> init.ece.uprm.edu (no recent updates) -> Linux init >> 2.6.19-1.2911.6.5.fc6xen #1 SMP Sun Mar 4 16:59:41 EST 2007 i686 i686 >> i386 >> GNU/Linux >> >> >> my problems appear when i decide update packages in shutdown machine. >> When >> execute the next command: >> >> cobbler enchant --virt=yes --address=shutdown.ece.uprm.edu >> --profile="base-box" >> >> i got the message at the end of this e-mail. However, everything works >> properly when execute this command: >> >> cobbler enchant --virt=yes --address=init.ece.uprm.edu >> --profile="base-box" >> >> What probably udpate crash the shutdown system? Do you need some >> specific >> details of the system in order to give a suggestion? >> >> thanks a lot for your attention, regards. >> >> +-------------+ >> |message error| >> +-------------+ >> - url=http://136.145.116.11libvir: error : configuration file syntax >> error: expecting a name >> Traceback (most recent call last): >> File "/usr/lib/python2.4/site-packages/koan/app.py", line 97, in main >> k.run() >> File "/usr/lib/python2.4/site-packages/koan/app.py", line 152, in run >> self.do_virt() >> File "/usr/lib/python2.4/site-packages/koan/app.py", line 297, in >> do_virt >> return self.do_net_install("/tmp",after_download) >> File "/usr/lib/python2.4/site-packages/koan/app.py", line 253, in >> do_net_install >> after_download(self, distro_data, profile_data) >> File "/usr/lib/python2.4/site-packages/koan/app.py", line 296, in >> after_download >> self.do_virt_net_install(profile_data, distro_data) >> File "/usr/lib/python2.4/site-packages/koan/app.py", line 600, in >> do_virt_net_install >> extra=kextra >> File "/usr/lib/python2.4/site-packages/koan/virtcreate.py", line 102, >> in >> start_paravirt_install >> guest.start_install() >> File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 643, >> in >> start_install >> meter = progress.BaseMeter() >> 4/cobbler/images/xentemplate/vmlinuz >> - kernel saved = /tmp/vmlinuz >> - initrd saved = /tmp/initrd.img >> NameError: global name 'progress' is not defined >> returns: 3 >> Traceback (most recent call last): >> File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", >> line >> 101, in run >> self.ssh_exec("koan %s --profile=%s --server=%s" % (operation, >> self.profile, self.settings.server)) >> File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", >> line >> 57, in ssh_exec >> raise cexceptions.CobblerException("enchant_failed","ssh failure") >> CobblerException: 'enchant failed (ssh failure)' >> enchant failed (exception) >> >> >> http://ece.uprm.edu/~s047267 >> http://del.icio.us/josanabr >> http://blog-grid.blogspot.com >> >> _______________________________________________ >> 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 > http://ece.uprm.edu/~s047267 http://del.icio.us/josanabr http://blog-grid.blogspot.com From rjones at redhat.com Tue Jun 19 16:29:28 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 19 Jun 2007 17:29:28 +0100 Subject: [et-mgmt-tools] KVM: praise for F7 virt-manager, virsh, automatically starting guests In-Reply-To: <3293c1d10706170939i3ec0242cjdd3fd4eca7cf93a5@mail.gmail.com> References: <9ebd65110706161757n7213aae3ge1df3ca064e7d4f7@mail.gmail.com> <20070617160920.GA12121@redhat.com> <3293c1d10706170939i3ec0242cjdd3fd4eca7cf93a5@mail.gmail.com> Message-ID: <46780468.8070905@redhat.com> Source wrote: > On 6/17/07, *Daniel P. Berrange* > wrote: > You need to explicitly tell virsh to connect to QEMU/KVM since it > defaults to Xen. > > virsh --connect qemu:///system > > > Can you please edit the man page of virsh and put on some e.g --connect > strings over there. I know there are not too much like only kvm and xen > are there but that is usually the first place everyone looks for before > going somewhere else. I'm just producing some documentation for this, which will appear shortly here: http://libvirt.org/uri.html (If you just see the holding page, come back later). Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From crobinso at redhat.com Wed Jun 20 20:45:42 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 20 Jun 2007 16:45:42 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst error message improvements Message-ID: <467991F6.3020103@redhat.com> Hi all, Attached is a patch that cleans up and improves some error reporting in virtinst. Includes error checking for setting memory and vcpu, improved install location and disk location errors, and a couple other fixes. Signed-off-by: Cole Robinson Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-improve-error-reporting.patch Type: text/x-patch Size: 10458 bytes Desc: not available URL: From crobinso at redhat.com Wed Jun 20 21:09:03 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 20 Jun 2007 17:09:03 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager validation and error reporting improvements Message-ID: <4679976F.4090305@redhat.com> Hi All, Attached is a patch that adds validation and error reporting improvements to virt-manager's creation wizard. It removes redundant checking and places the burden solely on virtinst, by plugging the parameters into a virtinst Guest object as it goes to get the error reporting and validation for free. This also simplifies the final setup before beginning the install. Signed-off-by: Cole Robinson Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-validation.patch Type: text/x-patch Size: 19812 bytes Desc: not available URL: From bart.lists at whiteley.org Wed Jun 20 21:37:19 2007 From: bart.lists at whiteley.org (Bart Whiteley) Date: Wed, 20 Jun 2007 15:37:19 -0600 Subject: [et-mgmt-tools] Cimbiote methods In-Reply-To: References: <00042F5A391A1541AA939DEC06CEE7FF10CCCA@EX01.QNH.local> <46029F80.7030902@redhat.com> Message-ID: On 3/22/07, Bart Whiteley wrote: > > On 3/22/07, Michael DeHaan wrote: > > > > Wow, a post about Cimbiote :) I'm happy and sad at the same time. > > You're basically the first person who has asked about it. Cimbiote is > > now largely unmaintained, and I should update the web page to indicate > > we are looking for a new owner. I would really like to see someone > > who is well connected with CIM development help continue it. > > > I would like to take ownership of Cimbiote if you're looking for a new > owner. > We have finished our Python provider interface. Details can be found on the PyWBEM project wiki. http://pywbem.wiki.sourceforge.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Thu Jun 21 14:41:47 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 21 Jun 2007 10:41:47 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst error message improvements In-Reply-To: <467991F6.3020103@redhat.com> References: <467991F6.3020103@redhat.com> Message-ID: <467A8E2B.8030100@redhat.com> Cole Robinson wrote: > > Hi all, > > Attached is a patch that cleans up and improves some error reporting in > virtinst. Includes error checking for setting memory and vcpu, improved > install location and disk location errors, and a couple other fixes. > > Signed-off-by: Cole Robinson > > Thanks, > Cole > > I managed to slip in a small bug when tidying up the patch to send out. I thought I tested it but apparently not! Attached is the fixed patch. Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-improve-error-reporting-fix.patch Type: text/x-patch Size: 10453 bytes Desc: not available URL: From hbrock at redhat.com Thu Jun 21 17:25:51 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 21 Jun 2007 13:25:51 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst error message improvements In-Reply-To: <467A8E2B.8030100@redhat.com> References: <467991F6.3020103@redhat.com> <467A8E2B.8030100@redhat.com> Message-ID: <467AB49F.7030206@redhat.com> Cole Robinson wrote: > Cole Robinson wrote: >> >> Hi all, >> >> Attached is a patch that cleans up and improves some error reporting >> in virtinst. Includes error checking for setting memory and vcpu, >> improved install location and disk location errors, and a couple other >> fixes. >> >> Signed-off-by: Cole Robinson >> >> Thanks, >> Cole >> >> > > I managed to slip in a small bug when tidying up the patch to send out. > I thought I tested it but apparently not! Attached is the fixed patch. > > Thanks, Cole > This looks good on first glance; I'll test it this afternoon. One of the BZs we had on the guest name issue requested that we allow "." in guest names as well. Does anyone know if that is legal for Xen? If so, we should add that character to the regex as well. 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 crobinso at redhat.com Thu Jun 21 19:43:10 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 21 Jun 2007 15:43:10 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager validation and error reporting improvements In-Reply-To: <4679976F.4090305@redhat.com> References: <4679976F.4090305@redhat.com> Message-ID: <467AD4CE.2030802@redhat.com> Cole Robinson wrote: > Hi All, > > Attached is a patch that adds validation and error reporting > improvements to virt-manager's creation wizard. It removes redundant > checking and places the burden solely on virtinst, by plugging the > parameters into a virtinst Guest object as it goes to get the error > reporting and validation for free. This also simplifies the final setup > before beginning the install. > The patch didn't apply properly since my repo wasn't fully up to date. Here is the fixed patch. Signed-off-by: Cole Robinson Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-validation02.patch Type: text/x-patch Size: 19784 bytes Desc: not available URL: From hbrock at redhat.com Thu Jun 21 21:04:31 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 21 Jun 2007 17:04:31 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager validation and error reporting improvements In-Reply-To: <467AD4CE.2030802@redhat.com> References: <4679976F.4090305@redhat.com> <467AD4CE.2030802@redhat.com> Message-ID: <467AE7DF.3040706@redhat.com> Cole Robinson wrote: > Cole Robinson wrote: >> Hi All, >> >> Attached is a patch that adds validation and error reporting >> improvements to virt-manager's creation wizard. It removes redundant >> checking and places the burden solely on virtinst, by plugging the >> parameters into a virtinst Guest object as it goes to get the error >> reporting and validation for free. This also simplifies the final >> setup before beginning the install. >> > > The patch didn't apply properly since my repo wasn't fully up to date. > Here is the fixed patch. > > Signed-off-by: Cole Robinson > This seems to work fine now, with a couple of corrections (below). I do have one question about hanging onto the guest name, though, for which see below... > > ------------------------------------------------------------------------ > > diff -r 4df620fc9133 src/virtManager/create.py > --- a/src/virtManager/create.py Tue Jun 19 13:20:29 2007 -0400 > +++ b/src/virtManager/create.py Mon Jun 18 15:30:35 2007 -0400 > @@ -477,97 +482,28 @@ class vmmCreate(gobject.GObject): > return 0 > > def finish(self, ignore=None): > - # first things first, are we trying to create a fully virt guest? > - if self.get_config_method() == VM_FULLY_VIRT: > - guest = virtinst.FullVirtGuest(type=self.get_domain_type(), \ > - hypervisorURI=self.connection.get_uri(), \ > - arch=self.get_domain_arch()) > - try: > - guest.cdrom = self.get_config_install_source() > - except ValueError, e: > - self._validation_error_box(_("Invalid FV media address"),e.args[0]) > - try: > - if self.get_config_os_type() is not None and self.get_config_os_type() != "generic": > - logging.debug("OS Type: %s" % self.get_config_os_type()) > - guest.os_type = self.get_config_os_type() Needed to change "guest.os_type" to "self._guest.os_type" here and below, works fine with that change. > - except ValueError, e: > - self._validation_error_box(_("Invalid FV OS Type"),e.args[0]) > - try: > - if self.get_config_os_variant() is not None and self.get_config_os_type() != "generic": > - logging.debug("OS Variant: %s" % self.get_config_os_variant()) > - guest.os_variant = self.get_config_os_variant() > - except ValueError, e: > - self._validation_error_box(_("Invalid FV OS Variant"),e.args[0]) > - > - else: > - guest = virtinst.ParaVirtGuest(type=self.get_domain_type(), hypervisorURI=self.connection.get_uri()) > - try: > - guest.location = self.get_config_install_source() > - except ValueError, e: > - self._validation_error_box(_("Invalid PV media address"), e.args[0]) > - return > - ks = self.get_config_kickstart_source() > - if ks != None and len(ks) != 0: > - guest.extraargs = "ks=%s" % ks > - > - # set the name > + # Validation should have mostly set up out guest. We just need > + # to take care of a few pieces we didn't touch > + > + guest = self._guest > + guest.hypervisorURI = self.connection.get_uri() > + > + # UUID, append disk and nic > try: > - guest.name = self.get_config_name() > + guest.uuid = virtinst.util.uuidToString(virtinst.util.randomUUID()) > + except ValueError, E: > + self._validation_error_box(_("UUID Error"), str(e)) > + > + try: > + guest.disks.append(self._disk) > except ValueError, e: > - self._validation_error_box(_("Invalid system name"), e.args[0]) > - return > - > - # set the memory > + self._validation_error_box(_("Error Setting up Disk"), str(e)) > + > try: > - guest.memory = int(self.get_config_initial_memory()) > - except ValueError: > - self._validation_error_box(_("Invalid memory setting"), e.args[0]) > - return > - > - try: > - guest.maxmemory = int(self.get_config_maximum_memory()) > - except ValueError: > - self._validation_error_box(_("Invalid memory setting"), e.args[0]) > - return > - > - # set vcpus > - guest.vcpus = int(self.get_config_virtual_cpus()) > - > - # disks > - filesize = None > - if self.get_config_disk_size() != None: > - filesize = self.get_config_disk_size() / 1024.0 > - try: > - d = virtinst.VirtualDisk(self.get_config_disk_image(), filesize, sparse = self.is_sparse_file()) > - if d.type == virtinst.VirtualDisk.TYPE_FILE and \ > - self.get_config_method() == VM_PARA_VIRT \ > - and virtinst.util.is_blktap_capable(): > - d.driver_name = virtinst.VirtualDisk.DRIVER_TAP > - if d.type == virtinst.VirtualDisk.TYPE_FILE and not \ > - self.is_sparse_file(): > - self.non_sparse = True > - else: > - self.non_sparse = False > + guest.nics.append(self._net) > except ValueError, e: > - self._validation_error_box(_("Invalid storage address"), e.args[0]) > - return > - guest.disks.append(d) > - > - # uuid > - guest.uuid = virtinst.util.uuidToString(virtinst.util.randomUUID()) > - > - # network > - net = self.get_config_network() > - mac = self.get_config_macaddr() > - if net[0] == "bridge": > - guest.nics.append(virtinst.VirtualNetworkInterface(macaddr=mac, type=net[0], bridge=net[1])) > - elif net[0] == "network": > - guest.nics.append(virtinst.VirtualNetworkInterface(macaddr=mac, type=net[0], network=net[1])) > - elif net[0] == "user": > - guest.nics.append(virtinst.VirtualNetworkInterface(macaddr=mac, type=net[0])) > - else: > - raise ValueError, "Unsupported networking type " + net[0] > - > + self._validation_error_box(_("Error Setting up Network"), str(e)) > + > # set up the graphics to use SDL > import keytable > keymap = None > @@ -597,7 +533,7 @@ class vmmCreate(gobject.GObject): > "\n Memory: " + str(guest.memory) + \ > "\n Max Memory: " + str(guest.maxmemory) + \ > "\n # VCPUs: " + str(guest.vcpus) + \ > - "\n Filesize: " + str(filesize) + \ > + "\n Filesize: " + str(self._disk.size) + \ > "\n Disk image: " + str(self.get_config_disk_image()) +\ > "\n Non-sparse file: " + str(self.non_sparse)) > > @@ -787,8 +723,18 @@ class vmmCreate(gobject.GObject): > startup_mem_adjustment.upper = max_memory > > def validate(self, page_num): > + > + # Setting the values in the Guest/Disk/Network virtinst objects > + # provides a lot of error checking for free, we just have to catch > + # the messages > + > if page_num == PAGE_NAME: > name = self.window.get_widget("create-vm-name").get_text() > + try: > + self._guest.name = name > + except ValueError, e: > + self._validation_error_box(_("Invalid System Name"), str(e)) > + > if len(name) > 50 or len(name) == 0: > self._validation_error_box(_("Invalid System Name"), \ > _("System name must be non-blank and less than 50 characters")) > @@ -797,24 +743,30 @@ class vmmCreate(gobject.GObject): > self._validation_error_box(_("Invalid System Name"), \ > _("System name may contain alphanumeric, '_' and '-' characters only")) > return False > - > - > + > elif page_num == PAGE_TYPE: > - if self.get_config_method() == VM_FULLY_VIRT and self.connection.get_type().startswith("Xen") and not virtinst.util.is_hvm_capable(): > - self._validation_error_box(_("Hardware Support Required"), \ > - _("Your hardware does not appear to support full virtualization. Only paravirtualized guests will be available on this hardware.")) > - return False NIT: Seems silly to copy the entire self._guest object here merely so you can hang onto the name. Why not just "name = self._guest.get_name()" followed later by "self._guest.name = name"? > + > + # Set up appropriate guest object dependent on selected type > + tmpguest = self._guest > + if self.get_config_method() == VM_PARA_VIRT: > + self._guest = virtinst.ParaVirtGuest(\ > + type=self.get_domain_type()) > + else: > + self._guest = virtinst.FullVirtGuest(\ > + type=self.get_domain_type(), \ > + arch=self.get_domain_arch()) > + > + self._guest.name = tmpguest.get_name() # Transfer name over > Otherwise looks pretty good. If you agree to the changes above I will apply it. 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 dlutter at redhat.com Fri Jun 22 03:20:44 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 21 Jun 2007 20:20:44 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181344930.24324.198.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> Message-ID: <1182482444.32115.3.camel@galia.watzmann.net> On Fri, 2007-06-08 at 23:22 +0000, David Lutterkort wrote: > I wrote some patches against virt-install that make it possible to run > virtual machines from VM images (aka appliances) > > Patches and additional docs are at > http://people.redhat.com/dlutter/virt-image/ I updated the patches according to the discussions. Main changes: * Refactored virt-install, virt-image, and virt-clone so that common code now lives in virtinst.cli * Add label and description to metadata Any chance this can get committed soon ? David From dlutter at redhat.com Fri Jun 22 03:25:30 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 21 Jun 2007 20:25:30 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <1181397113.3536.116.camel@blaa> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> Message-ID: <1182482730.32115.8.camel@galia.watzmann.net> On Sat, 2007-06-09 at 14:51 +0100, Mark McLoughlin wrote: > - Including vcpu, memory, graphics and nic in this metadata is mixing > up two things - the things the image need in order to boot and the > defaults recommended when instantiating a guest with the image. > Perhaps put them in a different toplevel element e.g. > > > > > ... > > > > ... > > > > > ... > > After looking at this again, I realized that you think of the metadata slightly differently than I do: note that I don't have a tag, I rather have a tag, that describes the attributes of a virtual machine. The reason for structuring it this way is that if we ever need multi-VM appliances, it's at least obvious how the metadata format should be extended. Having a section at the level you suggest would make describing a multi-VM image kidna hairy. > - This looks odd: > > + order = [ "xen", "kvm", "kqemu", "qemu" ] > + for o in order: > + if types.count(o) > 0: > > i.e. it'd be better not to have to keep that list updated. How > about you just pick the first type? If libvirt doesn't order the > list of available types in a useful order, maybe it should? I've punted on this for now, and justed added a FIXME comment in the code :( David From fj0588di at aa.jp.fujitsu.com Fri Jun 22 05:22:29 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Fri, 22 Jun 2007 14:22:29 +0900 Subject: [et-mgmt-tools] [Q]about the authentication function for the remote user request access to the cosnole Message-ID: <200706221422.DAI65649.KE9G6J09@aa.jp.fujitsu.com> Hi, I have a question. When is API including the authentication function for the remote user request access to the cosnole added to libvirt ? Thanks, Shigeki Sakamoto. From crobinso at redhat.com Fri Jun 22 13:01:21 2007 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 22 Jun 2007 09:01:21 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager validation and error reporting improvements In-Reply-To: <467AE7DF.3040706@redhat.com> References: <4679976F.4090305@redhat.com> <467AD4CE.2030802@redhat.com> <467AE7DF.3040706@redhat.com> Message-ID: <467BC821.4060701@redhat.com> Hugh Brock wrote: > > Needed to change "guest.os_type" to "self._guest.os_type" here and > below, works fine with that change. > Your comment was actually at the removed portion of the code so I was confused for a minute, but yes, definitely change that. > > NIT: Seems silly to copy the entire self._guest object here merely so > you can hang onto the name. Why not just "name = self._guest.get_name()" > followed later by "self._guest.name = name"? > Whoops, good call. > > Otherwise looks pretty good. If you agree to the changes above I will > apply it. > I agree, apply at will. :) Thanks, Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Fri Jun 22 14:54:14 2007 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 22 Jun 2007 10:54:14 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager validation and error reporting improvements In-Reply-To: <467BC821.4060701@redhat.com> References: <4679976F.4090305@redhat.com> <467AD4CE.2030802@redhat.com> <467AE7DF.3040706@redhat.com> <467BC821.4060701@redhat.com> Message-ID: <467BE296.5070909@redhat.com> Cole Robinson wrote: > Hugh Brock wrote: >> >> Needed to change "guest.os_type" to "self._guest.os_type" here and >> below, works fine with that change. >> > > Your comment was actually at the removed portion of the code so I was > confused for a minute, but yes, definitely change that. > >> >> NIT: Seems silly to copy the entire self._guest object here merely so >> you can hang onto the name. Why not just "name = >> self._guest.get_name()" followed later by "self._guest.name = name"? >> > > Whoops, good call. > >> >> Otherwise looks pretty good. If you agree to the changes above I will >> apply it. >> > > I agree, apply at will. :) > > Thanks, > Cole > Since we found some other errors, here's the (hopefully) final incarnation of this patch. Signed-off-by: Cole Robinson Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-validation-03-patch URL: From crobinso at redhat.com Fri Jun 22 14:57:10 2007 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 22 Jun 2007 10:57:10 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst error message improvements In-Reply-To: <467AB49F.7030206@redhat.com> References: <467991F6.3020103@redhat.com> <467A8E2B.8030100@redhat.com> <467AB49F.7030206@redhat.com> Message-ID: <467BE346.2010701@redhat.com> Hugh Brock wrote: > Cole Robinson wrote: >> Cole Robinson wrote: >>> >>> Hi all, >>> >>> Attached is a patch that cleans up and improves some error reporting >>> in virtinst. Includes error checking for setting memory and vcpu, >>> improved install location and disk location errors, and a couple >>> other fixes. >>> >>> Signed-off-by: Cole Robinson >>> >>> Thanks, >>> Cole >>> >>> >> >> I managed to slip in a small bug when tidying up the patch to send >> out. I thought I tested it but apparently not! Attached is the fixed >> patch. >> >> Thanks, Cole >> > > This looks good on first glance; I'll test it this afternoon. > > One of the BZs we had on the guest name issue requested that we allow > "." in guest names as well. Does anyone know if that is legal for Xen? > If so, we should add that character to the regex as well. > > Thanks, > --Hugh > I verified that xen doesn't complain about a '.' in the guest name, so I added that to the patch and changed a few error messages to be more clear. Signed-off-by: Cole Robinson Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-validation-02.patch Type: text/x-patch Size: 10496 bytes Desc: not available URL: From hbrock at redhat.com Fri Jun 22 17:33:51 2007 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 22 Jun 2007 13:33:51 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager validation and error reporting improvements In-Reply-To: <467BE296.5070909@redhat.com> References: <4679976F.4090305@redhat.com> <467AD4CE.2030802@redhat.com> <467AE7DF.3040706@redhat.com> <467BC821.4060701@redhat.com> <467BE296.5070909@redhat.com> Message-ID: <467C07FF.8020201@redhat.com> Cole Robinson wrote: > Cole Robinson wrote: >> Hugh Brock wrote: >>> >>> Needed to change "guest.os_type" to "self._guest.os_type" here and >>> below, works fine with that change. >>> >> >> Your comment was actually at the removed portion of the code so I was >> confused for a minute, but yes, definitely change that. >> >>> >>> NIT: Seems silly to copy the entire self._guest object here merely so >>> you can hang onto the name. Why not just "name = >>> self._guest.get_name()" followed later by "self._guest.name = name"? >>> >> >> Whoops, good call. >> >>> >>> Otherwise looks pretty good. If you agree to the changes above I will >>> apply it. >>> >> >> I agree, apply at will. :) >> >> Thanks, >> Cole >> > > Since we found some other errors, here's the (hopefully) final > incarnation of this patch. > > Signed-off-by: Cole Robinson > > Thanks, > Cole > > I have applied this, thanks! However I think we could stand another small patch that tightens up the validation on the paravirt download URL. Right now it allows spaces and various other characters that are illegal in URLs... Next step: localize the validation messages... --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 Fri Jun 22 17:41:16 2007 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 22 Jun 2007 13:41:16 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst error message improvements In-Reply-To: <467BE346.2010701@redhat.com> References: <467991F6.3020103@redhat.com> <467A8E2B.8030100@redhat.com> <467AB49F.7030206@redhat.com> <467BE346.2010701@redhat.com> Message-ID: <467C09BC.6040605@redhat.com> Cole Robinson wrote: > Hugh Brock wrote: >> Cole Robinson wrote: >>> Cole Robinson wrote: >>>> >>>> Hi all, >>>> >>>> Attached is a patch that cleans up and improves some error reporting >>>> in virtinst. Includes error checking for setting memory and vcpu, >>>> improved install location and disk location errors, and a couple >>>> other fixes. >>>> >>>> Signed-off-by: Cole Robinson >>>> >>>> Thanks, >>>> Cole >>>> >>>> >>> >>> I managed to slip in a small bug when tidying up the patch to send >>> out. I thought I tested it but apparently not! Attached is the fixed >>> patch. >>> >>> Thanks, Cole >>> >> >> This looks good on first glance; I'll test it this afternoon. >> >> One of the BZs we had on the guest name issue requested that we allow >> "." in guest names as well. Does anyone know if that is legal for Xen? >> If so, we should add that character to the regex as well. >> >> Thanks, >> --Hugh >> > > I verified that xen doesn't complain about a '.' in the guest name, so I > added that to the patch and changed a few error messages to be more clear. > > Signed-off-by: Cole Robinson > > Thanks, > Cole > > Applied... --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 Fri Jun 22 20:52:13 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 22 Jun 2007 16:52:13 -0400 Subject: [et-mgmt-tools] problem doing provision... In-Reply-To: <59875.136.145.116.114.1182262999.squirrel@ece.uprm.edu> References: <35322.136.145.116.114.1182205775.squirrel@ece.uprm.edu> <4677E625.7010006@redhat.com> <59875.136.145.116.114.1182262999.squirrel@ece.uprm.edu> Message-ID: <467C367D.4060304@redhat.com> John, We've confirmed virtinst is currently broken in FC6 and we are going to push a fix next week (hopefully Monday). Until then, you can edit /usr/lib/python2.4/site-packages/virtinst/Guest.py and add "import urlgrabber.progress as progress" to the top of the file. --Michael John Sanabria wrote: >> "NameError: global name 'progress' is not defined" >> >> What versions of virtinst does this machine have? >> >> This was fixed in virtinst some time ago, as I recall. >> >> > > sorry, is highly probably that i had create a mix of incompatible versions > between virtualization components (xen, virtinst, libvirt, kernel with > xen, and so on). > > however, thanks, i learn that is not convenient update the Dom0 machines :-D > > regards. > > >> John Sanabria wrote: >> >>> Hi, >>> >>> i have two systems with fc6: >>> >>> shutdown.ece.uprm.edu (with updates) -> Linux shutdown >>> 2.6.20-1.2952.fc6xen #1 SMP Wed May 16 19:19:04 EDT 2007 i686 i686 i386 >>> GNU/Linux >>> >>> init.ece.uprm.edu (no recent updates) -> Linux init >>> 2.6.19-1.2911.6.5.fc6xen #1 SMP Sun Mar 4 16:59:41 EST 2007 i686 i686 >>> i386 >>> GNU/Linux >>> >>> >>> my problems appear when i decide update packages in shutdown machine. >>> When >>> execute the next command: >>> >>> cobbler enchant --virt=yes --address=shutdown.ece.uprm.edu >>> --profile="base-box" >>> >>> i got the message at the end of this e-mail. However, everything works >>> properly when execute this command: >>> >>> cobbler enchant --virt=yes --address=init.ece.uprm.edu >>> --profile="base-box" >>> >>> What probably udpate crash the shutdown system? Do you need some >>> specific >>> details of the system in order to give a suggestion? >>> >>> thanks a lot for your attention, regards. >>> >>> +-------------+ >>> |message error| >>> +-------------+ >>> - url=http://136.145.116.11libvir: error : configuration file syntax >>> error: expecting a name >>> Traceback (most recent call last): >>> File "/usr/lib/python2.4/site-packages/koan/app.py", line 97, in main >>> k.run() >>> File "/usr/lib/python2.4/site-packages/koan/app.py", line 152, in run >>> self.do_virt() >>> File "/usr/lib/python2.4/site-packages/koan/app.py", line 297, in >>> do_virt >>> return self.do_net_install("/tmp",after_download) >>> File "/usr/lib/python2.4/site-packages/koan/app.py", line 253, in >>> do_net_install >>> after_download(self, distro_data, profile_data) >>> File "/usr/lib/python2.4/site-packages/koan/app.py", line 296, in >>> after_download >>> self.do_virt_net_install(profile_data, distro_data) >>> File "/usr/lib/python2.4/site-packages/koan/app.py", line 600, in >>> do_virt_net_install >>> extra=kextra >>> File "/usr/lib/python2.4/site-packages/koan/virtcreate.py", line 102, >>> in >>> start_paravirt_install >>> guest.start_install() >>> File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 643, >>> in >>> start_install >>> meter = progress.BaseMeter() >>> 4/cobbler/images/xentemplate/vmlinuz >>> - kernel saved = /tmp/vmlinuz >>> - initrd saved = /tmp/initrd.img >>> NameError: global name 'progress' is not defined >>> returns: 3 >>> Traceback (most recent call last): >>> File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", >>> line >>> 101, in run >>> self.ssh_exec("koan %s --profile=%s --server=%s" % (operation, >>> self.profile, self.settings.server)) >>> File "/usr/lib/python2.4/site-packages/cobbler/action_enchant.py", >>> line >>> 57, in ssh_exec >>> raise cexceptions.CobblerException("enchant_failed","ssh failure") >>> CobblerException: 'enchant failed (ssh failure)' >>> enchant failed (exception) >>> >>> >>> http://ece.uprm.edu/~s047267 >>> http://del.icio.us/josanabr >>> http://blog-grid.blogspot.com >>> >>> _______________________________________________ >>> 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 >> >> > > > http://ece.uprm.edu/~s047267 > http://del.icio.us/josanabr > http://blog-grid.blogspot.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From Hua.Zhang at Sun.COM Mon Jun 25 02:46:14 2007 From: Hua.Zhang at Sun.COM (Henry Zhang) Date: Mon, 25 Jun 2007 10:46:14 +0800 Subject: [et-mgmt-tools] On virtual network in virt-manager In-Reply-To: <20070621160025.27F8773749@hormel.redhat.com> References: <20070621160025.27F8773749@hormel.redhat.com> Message-ID: <467F2C76.5000106@sun.com> Hi there, Seems virt-manager is changing so fast, :) when I looked at Virtual network wizard", I found they are not there in v0.4.0, and instead, in guest Details, there is Add for adding new virtual hardware, we can select Network card, my concern is that is this used for virtual network adding? if so, don't need user input network name, IPV4 address...? And when I try to create a new guest, I found I can't input dash in the System name? not sure is this a bug, or a decision that we don't allow to input dash here? Thanks, Henry From Hua.Zhang at Sun.COM Mon Jun 25 04:00:22 2007 From: Hua.Zhang at Sun.COM (Henry Zhang) Date: Mon, 25 Jun 2007 12:00:22 +0800 Subject: [et-mgmt-tools] Re: On virtual network in virt-manager In-Reply-To: <467F2C76.5000106@sun.com> References: <20070621160025.27F8773749@hormel.redhat.com> <467F2C76.5000106@sun.com> Message-ID: <467F3DD6.1040101@sun.com> Hi there, Please ignore this mail, because we don't support virtual network at Solaris at the moment, so I de-active that part, so I can't see that. :) I forgot it.. Thanks, Henry Henry Zhang ??: > Hi there, > > Seems virt-manager is changing so fast, :) when I looked at Virtual > network wizard", I found they are not there in v0.4.0, and instead, in > guest Details, there is Add for adding new virtual hardware, we can > select Network card, my concern is that is this used for virtual network > adding? if so, don't need user input network name, IPV4 address...? > > And when I try to create a new guest, I found I can't input dash in the > System name? not sure is this a bug, or a decision that we don't allow > to input dash here? > > Thanks, > Henry > From rob at vanoostveen.net Mon Jun 25 08:09:19 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Mon, 25 Jun 2007 10:09:19 +0200 Subject: [et-mgmt-tools] virt-manager on FC6 Message-ID: <20070625080333.M36130@dataregiocentre.com> Hi, I'm trying to install virt-manager 0.4.0 on a FC6 box but I seem to be missing something. Some setup details : * installed FC6 (without virtualization); * Build and installed Xen 3.1 from source succesfully on the box; * Build and installed virt-manager from source succesfully. When I start virt-manager after install it complains about not finding the libvirt module. I wonder how the directories are organised? Or I'm I missing something else here? Thank you for your help. Regards, Rob From berrange at redhat.com Mon Jun 25 11:14:57 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 25 Jun 2007 12:14:57 +0100 Subject: [et-mgmt-tools] virt-manager on FC6 In-Reply-To: <20070625080333.M36130@dataregiocentre.com> References: <20070625080333.M36130@dataregiocentre.com> Message-ID: <20070625111457.GA19154@redhat.com> On Mon, Jun 25, 2007 at 10:09:19AM +0200, Rob van Oostveen wrote: > I'm trying to install virt-manager 0.4.0 on a FC6 box but I seem to be > missing something. > > Some setup details : > > * installed FC6 (without virtualization); > * Build and installed Xen 3.1 from source succesfully on the box; > * Build and installed virt-manager from source succesfully. Urm, what's wrong with just 'yum install virt-manager' which gets you the correct dependancies in the first place. FC6 already has 0.4.0 release of virt-manager. If you want Xen 3.1 too, then F7 has that built in too 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 rob at vanoostveen.net Mon Jun 25 12:59:15 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Mon, 25 Jun 2007 14:59:15 +0200 Subject: [et-mgmt-tools] virt-manager on FC6 In-Reply-To: <20070625111457.GA19154@redhat.com> References: <20070625080333.M36130@dataregiocentre.com> <20070625111457.GA19154@redhat.com> Message-ID: <20070625125530.M75222@vanoostveen.net> Dan, Thank you for your reply. > Urm, what's wrong with just 'yum install virt-manager' which gets you the > correct dependancies in the first place. I don't have Internet access at the moment. The box is being installed and then placed in datacenter. > FC6 already has 0.4.0 release of virt-manager. If you want Xen 3.1 too, > then F7 has that built in too Hmm.. I'll check again with the FC6 CD's.. I don't have a DVD player in the machine so F7 is no option for me. Thanks again. Rob From fj0588di at aa.jp.fujitsu.com Wed Jun 27 07:16:53 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Wed, 27 Jun 2007 16:16:53 +0900 Subject: [et-mgmt-tools] [PATCH] Unify the checking of the MAC address confliction between virtmanager and virtinstall In-Reply-To: <200706271411.CCE43276.K96J0E9G@aa.jp.fujitsu.com> References: <200706271351.IIC90127.69E0GKJ9@aa.jp.fujitsu.com> <200706271411.CCE43276.K96J0E9G@aa.jp.fujitsu.com> Message-ID: <200706271616.BCJ05296.K99GEJ60@aa.jp.fujitsu.com> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: addhardware.patch Type: application/octet-stream Size: 2806 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: create.patch Type: application/octet-stream Size: 2711 bytes Desc: not available URL: From markmc at redhat.com Wed Jun 27 09:51:41 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 27 Jun 2007 10:51:41 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1182482730.32115.8.camel@galia.watzmann.net> References: <1181344930.24324.198.camel@galia.watzmann.net> <1181397113.3536.116.camel@blaa> <1182482730.32115.8.camel@galia.watzmann.net> Message-ID: <1182937902.2778.11.camel@blaa> On Thu, 2007-06-21 at 20:25 -0700, David Lutterkort wrote: > On Sat, 2007-06-09 at 14:51 +0100, Mark McLoughlin wrote: > > - Including vcpu, memory, graphics and nic in this metadata is mixing > > up two things - the things the image need in order to boot and the > > defaults recommended when instantiating a guest with the image. > > Perhaps put them in a different toplevel element e.g. > > > > > > > > > > ... > > > > > > > > ... > > > > > > > > > > ... > > > > > > After looking at this again, I realized that you think of the metadata > slightly differently than I do: note that I don't have a > tag, I rather have a tag, that describes the attributes of a > virtual machine. The reason for structuring it this way is that if we > ever need multi-VM appliances, it's at least obvious how the metadata > format should be extended. > > Having a section at the level you suggest would make > describing a multi-VM image kidna hairy. I don't imagine this multi-VM appliance thing will ever work out and be useful, but if we did want to do that surely we'd have multiple descriptions? The boot descriptions, disks and defaults are all distinct and unrelated ... the only metadata I can imagine to tie them all together would be some way for them to find each other on the network. (i.e. to allow for this, I'd just add an root element) Cheers, Mark. From rjones at redhat.com Wed Jun 27 13:43:18 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 27 Jun 2007 14:43:18 +0100 Subject: [et-mgmt-tools] Proposal: New virDomainLookup function to indicate Not found vs Error Message-ID: <46826976.2090903@redhat.com> virt-install has some code which waits for a domain to appear just after it has been created. It looks like the loop attached to the end of this email, and is functional but has two problems. Problem (1) is that self.conn.lookupByName doesn't distinguish between a "Not found" domain and an actual error. For example there is no way to tell the difference between being unable to contact xend (an actual error), and being able to contact xend, but xend not being able to find the domain (not found). As shown here: >>> import libvirt >>> conn = libvirt.open ("xen+tls:///") >>> d = conn.lookupByName ("Domain-0") >>> d = conn.lookupByName ("doesnotexist") [...] libvirt.libvirtError: virDomainLookupByName() failed then I deliberately kill the remote daemon: >>> d = conn.lookupByName ("doesnotexist") libvir: Remote error : Error in the push function. [...] The first exception is a Not found condition (not an error) whereas the second is an error. Problem (2) is that virterror is over anxious to print error messages to stderr, even if the caller can handle them and even if (as in the Not found case) they don't indicate errors. In practical terms this means that the virt-install loop attached below may print out 1 or 2 error messages even when it is functioning normally. You'll see an error like this appearing [sic]: libvir: Xen Daemon error : GET operation failed: Since it's difficult to change the LookupBy* functions without changing the ABI, I suspect that the best thing to do is going to be to add a new call with better semantics. Therefore I suggest: virDomainPtr * virDomainLookup (virConnectPtr conn, int flags, int id, char *str, int *error); where flags is one of: VIR_LOOKUP_BY_ID, VIR_LOOKUP_BY_NAME, VIR_LOOKUP_BY_UUID or VIR_LOOKUP_BY_UUID_STRING The return values are: ret = domain, *error = 0 => found it ret = NULL, *error = 0 => not found ret = NULL, *error = 1 => error (check virterror) Addition 1: There would be a similar function virNetworkLookup, but without needing the 'id' parameter because networks don't have IDs. Addition 2: Change the driver internals so that they don't call virterror in the not found case. (This requires quite a bit of rejigging in xend_internal, but is not too hard). Addition 3: Language bindings could be modified to detect this function and if present change their existing LookupBy* functions to use the new interface. Thoughts? Rich. ---------------------------------------------------- This is the troublesome loop: logging.debug("Created guest, looking to see if it is running") # sleep in .25 second increments until either a) we find # our domain or b) it's been 5 seconds. this is so that # we can try to gracefully handle domain creation failures num = 0 d = None while num < (5 / .25): # 5 seconds, .25 second sleeps try: d = self.conn.lookupByName(self.name) break except libvirt.libvirtError, e: logging.debug("No guest running yet " + str(e)) pass num += 1 time.sleep(0.25) -- 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 rob at vanoostveen.net Wed Jun 27 15:52:19 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Wed, 27 Jun 2007 17:52:19 +0200 Subject: [et-mgmt-tools] virt-manager on FC6 In-Reply-To: <20070625125530.M75222@vanoostveen.net> References: <20070625080333.M36130@dataregiocentre.com> <20070625111457.GA19154@redhat.com> <20070625125530.M75222@vanoostveen.net> Message-ID: <20070627154614.M53130@dataregiocentre.com> Dan, An update on this issue.. The reason why I don't install the rpm's is the dependency of Xen package when I try to install virt-manager. I build Xen 3.1 from source and need the latest virt-manager as well. When I build/install the libvirt-0.2.3.tar.gz from source, virt-manager complaints about not finding the virtinst module. I downloaded the virtinst-0.103.0.tar.gz as well, but don't know how to install/build that package. The readme isn't describing the installation. Can anyone hand me a rough guide through the setup for building virt-manager with any dependencies included? Or does a good howto exist? Thanks. Regards, Rob On Mon, 25 Jun 2007 14:59:15 +0200, Rob van Oostveen wrote > Dan, > > Thank you for your reply. > > > Urm, what's wrong with just 'yum install virt-manager' which gets you the > > correct dependancies in the first place. > > I don't have Internet access at the moment. The box is being installed and > then placed in datacenter. > > > FC6 already has 0.4.0 release of virt-manager. If you want Xen 3.1 too, > > then F7 has that built in too > > Hmm.. I'll check again with the FC6 CD's.. I don't have a DVD player in the > machine so F7 is no option for me. > > Thanks again. > > Rob > > _______________________________________________ > 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 Wed Jun 27 15:56:27 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 27 Jun 2007 16:56:27 +0100 Subject: [et-mgmt-tools] virt-manager on FC6 In-Reply-To: <20070627154614.M53130@dataregiocentre.com> References: <20070625080333.M36130@dataregiocentre.com> <20070625111457.GA19154@redhat.com> <20070625125530.M75222@vanoostveen.net> <20070627154614.M53130@dataregiocentre.com> Message-ID: <20070627155627.GH23350@redhat.com> On Wed, Jun 27, 2007 at 05:52:19PM +0200, Rob van Oostveen wrote: > Dan, > > An update on this issue.. > > The reason why I don't install the rpm's is the dependency of Xen package when > I try to install virt-manager. I build Xen 3.1 from source and need the latest > virt-manager as well. BTW if you want a Xen 3.1.0 RPM, you can take the xen-3.1.0-1.fc7.src.rpm and on your FC6 host just rebuild it by running rpmbuild --rebuild --define 'dist .fc6' xen-3.1.0-1.fc7.src.rpm And a short while later you'll have a nice binary RPM of Xen 3.1.0 capable of being installed on FC6 - assuming you've got the kernel & HV parts there already. > When I build/install the libvirt-0.2.3.tar.gz from source, virt-manager > complaints about not finding the virtinst module. I downloaded the > virtinst-0.103.0.tar.gz as well, but don't know how to install/build that > package. The readme isn't describing the installation. Doh, stupid readme. It is basically the standard python install procedure, so run: python setup.py install 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 rob at vanoostveen.net Wed Jun 27 16:23:21 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Wed, 27 Jun 2007 18:23:21 +0200 Subject: [et-mgmt-tools] virt-manager on FC6 In-Reply-To: <20070627155627.GH23350@redhat.com> References: <20070625080333.M36130@dataregiocentre.com> <20070625111457.GA19154@redhat.com> <20070625125530.M75222@vanoostveen.net> <20070627154614.M53130@dataregiocentre.com> <20070627155627.GH23350@redhat.com> Message-ID: <20070627161216.M10540@vanoostveen.net> Dan, > BTW if you want a Xen 3.1.0 RPM, you can take the xen-3.1.0-1.fc7.src.rpm > and on your FC6 host just rebuild it by running > > rpmbuild --rebuild --define 'dist .fc6' xen-3.1.0-1.fc7.src.rpm The rpm is not on the dvd. I will try to find it. On other thing, do I need depency packages as well? Or does this xen src package include all I need? > And a short while later you'll have a nice binary RPM of Xen 3.1.0 capable > of being installed on FC6 - assuming you've got the kernel & HV parts there > already. I will have a go. I'll report back in a while. > Doh, stupid readme. It is basically the standard python install procedure, > so run: > > python setup.py install That worked indeed, thank you. So finally virt-manager started. But the virt-manager complains about unable to connect to xen. It says: "Unable to open a connection to the Xen hypervisor/daemon". Both the Xen host is booted and the Xen service (xend) is started. I have the feeling when I fix this, I'm ok with this setup. Regards, Rob From rob at vanoostveen.net Wed Jun 27 17:08:24 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Wed, 27 Jun 2007 19:08:24 +0200 Subject: [et-mgmt-tools] Unable to open connection Message-ID: <20070627170359.M41317@dataregiocentre.com> Hi, I build virt-manager from source as well as the libvirt. When I try to run virt-manager I get the following: Unable to open connection to hypervisor URI 'xen': ..bunch of python lines.. I tried to run virt-manager --connect='..', but without any luck. On the libvirt website I read about connection URIs. I tried that, but again no luck. Can anyone give me any hints on this? Thanks in advance. Regards, Rob From pmyers at redhat.com Wed Jun 27 17:20:47 2007 From: pmyers at redhat.com (Perry Myers) Date: Wed, 27 Jun 2007 13:20:47 -0400 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <20070627170359.M41317@dataregiocentre.com> References: <20070627170359.M41317@dataregiocentre.com> Message-ID: <46829C6F.50400@redhat.com> Rob, Two quesitons: Are you booted into a Xen kernel? (run uname -a and see if xen is in the kernel name) Is xend running? Perry Rob van Oostveen wrote: > Hi, > > I build virt-manager from source as well as the libvirt. When I try to run > virt-manager I get the following: > > Unable to open connection to hypervisor URI 'xen': > ..bunch of python lines.. > > I tried to run virt-manager --connect='..', but without any luck. On the > libvirt website I read about connection URIs. I tried that, but again no luck. > > Can anyone give me any hints on this? > > Thanks in advance. > > Regards, > Rob > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 703 362 9622 -=| From rob at vanoostveen.net Wed Jun 27 17:28:00 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Wed, 27 Jun 2007 19:28:00 +0200 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <46829C6F.50400@redhat.com> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> Message-ID: <20070627172645.M78641@vanoostveen.net> Perry, > Are you booted into a Xen kernel? (run uname -a and see if xen is in the kernel name) Yes. Build from source. When I commit a 'xm list' it displays the domain-0. > Is xend running? Yes. Thanks. Rob From hbrock at redhat.com Wed Jun 27 17:32:38 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 27 Jun 2007 13:32:38 -0400 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <20070627172645.M78641@vanoostveen.net> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> Message-ID: <46829F36.9060208@redhat.com> Rob van Oostveen wrote: > Perry, > >> Are you booted into a Xen kernel? (run uname -a and see if xen is in the > kernel name) > > Yes. Build from source. When I commit a 'xm list' it displays the domain-0. > >> Is xend running? > > Yes. > Hi Rob. What version of libvirt are you using? Did you build it from source or install an RPM? virt-manager requires libvirt to talk to xen, and if you don't build libvirt with xen-devel installed on your machine as well, it will not build in xen support (which means virt-manager won't talk to the xen hypervisor even if it is present and running). Let me know, --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 smooge at gmail.com Wed Jun 27 17:38:45 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 27 Jun 2007 11:38:45 -0600 Subject: [et-mgmt-tools] virt-manager on FC6 In-Reply-To: <20070627155627.GH23350@redhat.com> References: <20070625080333.M36130@dataregiocentre.com> <20070625111457.GA19154@redhat.com> <20070625125530.M75222@vanoostveen.net> <20070627154614.M53130@dataregiocentre.com> <20070627155627.GH23350@redhat.com> Message-ID: <80d7e4090706271038k3e4bf383p21f9d376464f6a24@mail.gmail.com> On 6/27/07, Daniel P. Berrange wrote: > On Wed, Jun 27, 2007 at 05:52:19PM +0200, Rob van Oostveen wrote: > > Dan, > > > > An update on this issue.. > > > > The reason why I don't install the rpm's is the dependency of Xen package when > > I try to install virt-manager. I build Xen 3.1 from source and need the latest > > virt-manager as well. > > BTW if you want a Xen 3.1.0 RPM, you can take the xen-3.1.0-1.fc7.src.rpm and > on your FC6 host just rebuild it by running > > rpmbuild --rebuild --define 'dist .fc6' xen-3.1.0-1.fc7.src.rpm > Hmmmm sounds like something to do with my RHEL-5 systems :). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mdehaan at redhat.com Wed Jun 27 18:19:55 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 27 Jun 2007 14:19:55 -0400 Subject: [et-mgmt-tools] Cobbler 0.5.0 & koan 0.5.0 released (testing) Message-ID: <4682AA4B.40000@redhat.com> Hi folks, Cobbler 0.5.0 was building up in terms of features and it's time to do a release. This release is a testing release, as indicated by Cobbler having an odd number. Things are expected to work well, and I've done some testing, though caution when playing around on a production box is advisable -- there's a lot of new stuff here. (The biggest change is the support for inheritance in profiles and this affects the sync code a good bit). For this release, koan needs to be updated to take advantage of changes in cobbler. Basically, cobblerd is now written in Cobbler's own API, and we have less dependency on YAML. Removing this sort of thing required changes on both sides of the fence. I will push this to F7-testing's yum repository, shortly, and barring any major noise, F-7 stable and FC-6 will follow. --- The main changes in cobbler are: * Cobbler systems can be named anything. If you want to name them "blippy", this works. If using arbitrary labels, specify the mac with --mac or the ip with --ip. One or the other is required to make a PXE-able configuration, though koan doesn't need either. If you name a system the old way (after the MAC address), cobbler will fill in the value for --mac automatically, as you would expect. * You can now say things like "cobbler system report FOO" to get the properties of just that one system. * Optionally use dnsmasq for DHCP (and DNS!) instead of ISC dhcpd. You'll need to reload (SIGHUP) dnsmasq peridocally or run cobbler sync to make changes made in Cobbler apply to the outside world. This works very well and is quite easy to configure. See the manpage for more details. * Cobbler system add also takes a --hostname. If manage_dhcp is enabled, and using dnsmasq, this has real meaning. If not, it's just a metadata variable to use in templating. * Triggers are restructed. There are now "pre" and "post" triggers. /var/lib/cobbler/triggers/(add/delete)/(distro|profile|system|repo)/(pre|post)/*.sh Pre-triggers run before an object is added, post-triggers run afterwards. Triggers are also now validating. If a pre trigger returns non-zero, it can cancel the creation of a cobbler object. Older docs http://et.redhat.com/page/Cobbler_Triggers will be updated shortly. * Patch to allow --createrepo-flags and to cache on import. Multiple calls to createrepo have been removed. * Various modifications to allow for profile inheritance. See the manpage or my earlier email to the list for details. Basically: cobbler profile add --name=foo --distro=bar --param1=... cobbler profile add --name=foo2 --inherit=foo --param2=... - All variables in object tree now available for use in templating This means that if you pass in a value to --virt-ram, in the kickstart template, you can actually reference $virt-ram as a templating variable, automagically. This works for all variables. - Optional override of --kickstart in system object I'm not sure of a great reason for this, though there have been some requests. If you have a system object and want to use a slightly tweaked kickstart file, you can now do so. It's still recommended to use templating instead, however. Koan has only changed in order to support Cobbler 0.5.0, including the ability to name systems in cobbler after things that are not MAC addresses. --virt-name still works as an override in koan, though if you do a "cobbler system add --name=foo" and a "koan --virt --system=foo --server=...", the virtual system you install will be named, as expected, "foo". ----- Updates can be found here: http://cobbler.et.redhat.com/download Comments/questions welcome. Thanks! --Michael From steve at atc-nycorp.com Wed Jun 27 18:20:16 2007 From: steve at atc-nycorp.com (Steve Brueckner) Date: Wed, 27 Jun 2007 14:20:16 -0400 Subject: [et-mgmt-tools] virt-manager on FC6 Message-ID: <60D45469A1AAD311A04C009027B6BF6806225843@SERVER20> > That worked indeed, thank you. So finally virt-manager started. But > the virt-manager complains about unable to connect to xen. It says: > > "Unable to open a connection to the Xen hypervisor/daemon". Both the > Xen host is booted and the Xen service (xend) is started. > I have the feeling when I fix this, I'm ok with this setup. Daniel helped me with this about a couple of weeks ago on this very list, assuming it's the same problem. If you compiled Xen from source, I think the /etc/xen/xend-config.sxp configuration file needs to be edited to use the xend unix server. This would entail uncommenting the "xend-unix-server yes" line. Then reboot or restart xend. Steve Brueckner, ATC-NY From rob at vanoostveen.net Wed Jun 27 20:29:35 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Wed, 27 Jun 2007 22:29:35 +0200 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <46829F36.9060208@redhat.com> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> Message-ID: <20070627202535.M17351@dataregiocentre.com> Hugh, > Hi Rob. What version of libvirt are you using? The latest: libvirt-0.2.3.tar.gz > Did you build it from source or install an RPM? >From source. > virt-manager requires libvirt to talk to xen, > and if you don't build libvirt with xen-devel installed on your machine > as well, it will not build in xen support (which means virt-manager > won't talk to the xen hypervisor even if it is present and running). I suspect this is the key to my solution. I'm certain I don't have the xen- devel installed on my machine. This explains also why the 'make check' fails as well, I cant remember what the message was exactly, but it had something to do with 'no support'.. I will let you know. Thanks for the help. Best regards, Rob From hbrock at redhat.com Wed Jun 27 20:35:28 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 27 Jun 2007 16:35:28 -0400 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <20070627202535.M17351@dataregiocentre.com> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> Message-ID: <4682CA10.7040107@redhat.com> Rob van Oostveen wrote: > Hugh, > >> Hi Rob. What version of libvirt are you using? > > The latest: libvirt-0.2.3.tar.gz > >> Did you build it from source or install an RPM? > >>From source. > >> virt-manager requires libvirt to talk to xen, >> and if you don't build libvirt with xen-devel installed on your machine >> as well, it will not build in xen support (which means virt-manager >> won't talk to the xen hypervisor even if it is present and running). > > I suspect this is the key to my solution. I'm certain I don't have the xen- > devel installed on my machine. This explains also why the 'make check' fails > as well, I cant remember what the message was exactly, but it had something > to do with 'no support'.. I will let you know. > > Thanks for the help. > > Best regards, > > Rob Yes, I have had this same problem when building libvirt on machines where I had forgotten to install xen-devel. The build config for libvirt automatically sets WITH_XEN=no if it doesn't find xen-devel, without telling you it's doing it... we should probably fix that at some point... Best of luck, --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 rob at vanoostveen.net Wed Jun 27 21:16:33 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Wed, 27 Jun 2007 23:16:33 +0200 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <4682CA10.7040107@redhat.com> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> <4682CA10.7040107@redhat.com> Message-ID: <20070627211542.M19639@dataregiocentre.com> Hugh, > Yes, I have had this same problem when building libvirt on machines > where I had forgotten to install xen-devel. The build config for libvirt > automatically sets WITH_XEN=no if it doesn't find xen-devel, without > telling you it's doing it... we should probably fix that at some point... This is indeed tricky. Glad you helped me out on this one.. :) Anyway, I will go out and find the xen-devel package. Thanks again. Rob From fj0873gn at aa.jp.fujitsu.com Thu Jun 28 09:07:46 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Thu, 28 Jun 2007 18:07:46 +0900 Subject: [et-mgmt-tools] About keeping the cdrom in the permanent XML for a guest after install Message-ID: <200706281807.GBB35925.H08KGO49@aa.jp.fujitsu.com> Hi, Hugh I have an opinion about the following corrections. https://www.redhat.com/archives/et-mgmt-tools/2007-June/msg00124.html I think that this correction has added the procedure to the Linux guest user. In case of Linux, if installation is finished, the cdrom (/dev/cdrom) is not necessary. The user has to detach one by one. And, before correction, the cdrom with no source was attached after installation. Isn't it enough for Windows? xm block-configure exchange the cdrom when Windows asks for it, and since the cdrom with no source is positioning like the physics CD device with no media, it is not necessary to detach it after use. I recognize the problem of Windows had been already solved before correction. Cannot you retrieve to the state before this correction? Thanks, Nobuhiro Itou. From berrange at redhat.com Thu Jun 28 12:56:39 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 28 Jun 2007 13:56:39 +0100 Subject: [et-mgmt-tools] Re: [Libvir] Proposal: New virDomainLookup function to indicate Not found vs Error In-Reply-To: <46826976.2090903@redhat.com> References: <46826976.2090903@redhat.com> Message-ID: <20070628125639.GE16385@redhat.com> On Wed, Jun 27, 2007 at 02:43:18PM +0100, Richard W.M. Jones wrote: > virt-install has some code which waits for a domain to appear just after > it has been created. It looks like the loop attached to the end of this > email, and is functional but has two problems. > > Problem (1) is that self.conn.lookupByName doesn't distinguish between a > "Not found" domain and an actual error. For example there is no way to > tell the difference between being unable to contact xend (an actual > error), and being able to contact xend, but xend not being able to find > the domain (not found). It is possible to tell the difference, we just don't report it well. > As shown here: > > >>> import libvirt > >>> conn = libvirt.open ("xen+tls:///") > >>> d = conn.lookupByName ("Domain-0") > >>> d = conn.lookupByName ("doesnotexist") > [...] > libvirt.libvirtError: virDomainLookupByName() failed > > then I deliberately kill the remote daemon: > > >>> d = conn.lookupByName ("doesnotexist") > libvir: Remote error : Error in the push function. > [...] > > The first exception is a Not found condition (not an error) whereas the > second is an error. There is no explicit libvirt error code for 'no such domain' so it is basically impossible to catch this scenario in an app currently This problem is actually not just an issue with virLookup* group of functions. Basically any function which takes a virDomainPtr arg can have a 'no such domain' error, since a domain could have gone away in the time since the app got hold of a virDomainPtr object. The QEMU driver just throws a generic 'internal error', but I think its worth introducing an explicit 'no such domain' and 'no such network' error code and fixing all functions to report these correctly. > > Problem (2) is that virterror is over anxious to print error messages to > stderr, even if the caller can handle them and even if (as in the Not > found case) they don't indicate errors. In practical terms this means > that the virt-install loop attached below may print out 1 or 2 error > messages even when it is functioning normally. You'll see an error like > this appearing [sic]: > > libvir: Xen Daemon error : GET operation failed: In the python bindings all errors are converted into Exceptions, so the python binding really shouldn't be printing out anything to the console at all by default. It'll all be reported as exceptions. The default error reporting func in libvirt is doing this so perhaps we should register a no-op func. > Since it's difficult to change the LookupBy* functions without changing > the ABI, I suspect that the best thing to do is going to be to add a new > call with better semantics. Therefore I suggest: > > virDomainPtr * > virDomainLookup (virConnectPtr conn, int flags, > int id, char *str, int *error); > > where flags is one of: > VIR_LOOKUP_BY_ID, VIR_LOOKUP_BY_NAME, VIR_LOOKUP_BY_UUID > or VIR_LOOKUP_BY_UUID_STRING > > The return values are: > ret = domain, *error = 0 => found it > ret = NULL, *error = 0 => not found > ret = NULL, *error = 1 => error (check virterror) I'd do it the other way around, returning the error code, and putting the domain object into a parameter int virDomainLookup (virConnectPtr conn, int flags, int id, char *str, virDomainPtr *dom); That said, I'm not convinced we need this if we fix the error reporting of the original functions to allow the 'no such domain' error to be reliably caught & handled. 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 Thu Jun 28 17:14:13 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 28 Jun 2007 13:14:13 -0400 Subject: [et-mgmt-tools] Re: About keeping the cdrom in the permanent XML for a guest after install Message-ID: <4683EC65.7070601@redhat.com> Oops, meant to reply to the list, not just to Nobuhiro-san... Nobuhiro Itou wrote: > Hi, Hugh > > I have an opinion about the following corrections. > https://www.redhat.com/archives/et-mgmt-tools/2007-June/msg00124.html > > I think that this correction has added the procedure to the Linux guest user. > In case of Linux, if installation is finished, the cdrom (/dev/cdrom) is not necessary. > The user has to detach one by one. > > And, before correction, the cdrom with no source was attached after installation. Isn't it enough for Windows? xm block-configure exchange the cdrom when Windows asks for it, > and since the cdrom with no source is positioning like the physics CD device with no media, it is not necessary to detach it after use. > > I recognize the problem of Windows had been already solved before correction. > > Cannot you retrieve to the state before this correction? > > > Thanks, > Nobuhiro Itou. 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. 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 mail.baruchi at gmail.com Thu Jun 28 17:47:54 2007 From: mail.baruchi at gmail.com (Artur Baruchi) Date: Thu, 28 Jun 2007 14:47:54 -0300 Subject: [et-mgmt-tools] Where is the Configuration File? Message-ID: Hi Guys, Well.. I've installed a virtual machine using Xen and Virt-Manager but after a successfully installation I couldn't find the configuration file used to xen bring up the virtual machine (usually its located in /etc/xen/ path). I would like to know where OR how Virt-manager is getting the information to bring my virtual machines up? Software Versions: Fedora Core 7 Xen 3.1.0 Virt-Manager 0.4.0.2 Libvirt 0.2.3.1 Thanks in advance, Att. Artur Baruchi From hbrock at redhat.com Thu Jun 28 18:06:31 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 28 Jun 2007 14:06:31 -0400 Subject: [et-mgmt-tools] Where is the Configuration File? In-Reply-To: References: Message-ID: <4683F8A7.8010008@redhat.com> Artur Baruchi wrote: > Hi Guys, > > Well.. I've installed a virtual machine using Xen and Virt-Manager but > after a successfully installation I couldn't find the configuration > file used to xen bring up the virtual machine (usually its located in > /etc/xen/ path). I would like to know where OR how Virt-manager is > getting the information to bring my virtual machines up? > > Software Versions: > > Fedora Core 7 > Xen 3.1.0 > Virt-Manager 0.4.0.2 > Libvirt 0.2.3.1 > > Thanks in advance, > > Att. > Artur Baruchi > Hi. With xen 3.1, config information for guests is no longer in /etc/xen, nor is it modifiable by editing a config file. XenSource decided it was better to hide the config information. Virt-manager gets information about active and inactive guests by querying libvirt for them. libvirt then turns around and asks xend, or whatever hypervisor you are using, for the information and returns it. for You can do the same thing from the command line with "virsh dumpxml ". --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 dlutter at redhat.com Thu Jun 28 18:31:24 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 28 Jun 2007 11:31:24 -0700 Subject: [et-mgmt-tools] VM images In-Reply-To: <1182937902.2778.11.camel@blaa> 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> Message-ID: <1183055484.4013.1.camel@galia.watzmann.net> On Wed, 2007-06-27 at 10:51 +0100, Mark McLoughlin wrote: > I don't imagine this multi-VM appliance thing will ever work out and be > useful, but if we did want to do that surely we'd have multiple > descriptions? The boot descriptions, disks and defaults are all distinct > and unrelated ... the only metadata I can imagine to tie them all > together would be some way for them to find each other on the network. > > (i.e. to allow for this, I'd just add an root element) 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) David From crobinso at redhat.com Thu Jun 28 18:44:29 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 28 Jun 2007 14:44:29 -0400 Subject: [et-mgmt-tools] [RFC] Approach to installing a localized virtinst Message-ID: <4684018D.3090309@redhat.com> 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. 2) Force the user to use the autobuild.sh script and pass an environment variable to that if they want to specify a different install root. That way the sed'ing can be done prior to calling setup.py. Would be pretty simple and non-intrusive, but no good for a user who wants to pass other arguments to setup.py. 3) Use traditional autotools. Probably the 'right' solution, but a tad overkill :) The only real way at multiplatforming the install as well, since all other solutions would involve hardcoding share/locale/... among other things, which might not be the directory structure used by other platforms. Thoughts? I'm not too familiar with this stuff so I may be overlooking a simpler solution, or oversimplifying a complex one! Thanks, Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-build-install-l10n.patch Type: text/x-patch Size: 3001 bytes Desc: not available URL: From steve at atc-nycorp.com Thu Jun 28 21:00:53 2007 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 28 Jun 2007 17:00:53 -0400 Subject: [et-mgmt-tools] Where is the Configuration File? Message-ID: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> Hugh Brock wrote: > > With xen 3.1, config information for guests is no longer in /etc/xen, > nor is it modifiable by editing a config file. XenSource decided it > was better to hide the config information. > > Virt-manager gets information about active and inactive guests by > querying libvirt for them. libvirt then turns around and asks xend, > or whatever hypervisor you are using, for the information and returns > it. for You can do the same thing from the command line with "virsh > dumpxml ". > > --Hugh What is the new "Xen way" of creating VMs? That is, without using virt-manager, how do they recommend users do things? Their user manual is still stuck at version 3.0. Steve Brueckner, ATC-NY From hbrock at redhat.com Thu Jun 28 21:02:25 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 28 Jun 2007 17:02:25 -0400 Subject: [et-mgmt-tools] Where is the Configuration File? In-Reply-To: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> Message-ID: <468421E1.8020301@redhat.com> Steve Brueckner wrote: > Hugh Brock wrote: >> With xen 3.1, config information for guests is no longer in /etc/xen, >> nor is it modifiable by editing a config file. XenSource decided it >> was better to hide the config information. >> >> Virt-manager gets information about active and inactive guests by >> querying libvirt for them. libvirt then turns around and asks xend, >> or whatever hypervisor you are using, for the information and returns >> it. for You can do the same thing from the command line with "virsh >> dumpxml ". >> >> --Hugh > > What is the new "Xen way" of creating VMs? That is, without using > virt-manager, how do they recommend users do things? Their user > manual is still stuck at version 3.0. > > Steve Brueckner, ATC-NY > Hi. Well, if you don't want to do "virsh define " to define a guest, you can now do much the same thing with xm. "xm help" seems to be the best documentation for the 3.1 features. --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 Thu Jun 28 22:02:31 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 28 Jun 2007 18:02:31 -0400 Subject: [et-mgmt-tools] Virt-factory 0.0.3 Released Message-ID: <46842FF7.705@redhat.com> Virt-Factory? What's that? Basically, Virt-factory is our ongoing project to make better tools for managing a very large number (like a datacenter's worth) of Xen machines and virtual appliances. http://virt-factory.et.redhat.com For virt-factory to help command infrastructure, it has to have a pool of physical hosts assigned to it. You can either PXE new machines from the VF server, or register existing ones using a command line registration tool. From there, you can use the Web UI to add more virtual machines to any of your hosts and control the virtualization state of those machines. Currently it's not quite up to speed with virt-manager in terms of feature parity, but it does have start/stop/pause/shutdown/etc controls -- we're getting there. Supporting migration is on the roadmap. Virt-Factory is different from other management apps in a few key areas. We use the concept of Profiles to say what a machine does. This integrates systems management (Puppet) with the provisioning process (Cobbler) all in one easy step -- and all controlled with a very simple user interface. Administrators can create (or import) profiles, assign them to existing machines, and share them with other virt-factory users. ISVs could also create profiles for commercial software. Basically, profiles are a lightweight way of building software appliances. Future releases will also concentrate heavily on batch management, such as finding good candidates to migrate virtual machines to when taking a physical host offline, or doing interesting things with tagging and reporting. So, by integrating systems management tools in with good batch management solutions, we'll have a unique (and free) solution for doing a lot of interesting things around virtualization management. This particular release adds several new things: -- More streamlined setup process (http://virt-factory.et.redhat.com/vf-install-setup.php) -- User interface is now rethemed and improved -- (thanks to M?ir?n Duffy for help on this) -- The server now sets up and runs PostgreSQL automatically -- as opposed to sqlite -- Changes to work with newer builds of Puppet -- Localization framework (though no included translations yet) -- Lots of code/architectural cleanup and bugfixes Our plans for future releases are detailed here: http://virt-factory.et.redhat.com/vf-roadmap.php Keep in mind this project is still getting off the ground somewhat, so it's not quite ready for production use. The next release (0.0.4) will address a lot of those critical features. If you have comments, questions, or ideas ... as usual, we'd love to hear them. Check out http://virt-factory.et.redhat.com, email us here, or stop by on IRC. We have a channel #virt-factory on irc.freenode.net. Downloads are here: http://virt-factory.et.redhat.com/download.php Thanks! Michael DeHaan Adrian Likins Scott Seago From mdehaan at redhat.com Thu Jun 28 22:07:15 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 28 Jun 2007 18:07:15 -0400 Subject: [et-mgmt-tools] Where is the Configuration File? In-Reply-To: <468421E1.8020301@redhat.com> References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> <468421E1.8020301@redhat.com> Message-ID: <46843113.4060709@redhat.com> Hugh Brock wrote: > Steve Brueckner wrote: >> Hugh Brock wrote: >>> With xen 3.1, config information for guests is no longer in /etc/xen, >>> nor is it modifiable by editing a config file. XenSource decided it >>> was better to hide the config information. >>> Virt-manager gets information about active and inactive guests by >>> querying libvirt for them. libvirt then turns around and asks xend, >>> or whatever hypervisor you are using, for the information and returns >>> it. for You can do the same thing from the command line with "virsh >>> dumpxml ". >>> --Hugh >> >> What is the new "Xen way" of creating VMs? That is, without using >> virt-manager, how do they recommend users do things? Their user >> manual is still stuck at version 3.0. >> >> Steve Brueckner, ATC-NY >> > Hi. > > Well, if you don't want to do "virsh define " to define a > guest, you can now do much the same thing with xm. "xm help" seems to > be the best documentation for the 3.1 features. > > --Hugh > >> What is the new "Xen way" of creating VMs? That is, without using virt-manager, how do they recommend users do things? I'm not sure what prompted the question, but if you're looking for a good command line way of creating virtual machines, for paravirt, koan does this. See http://cobbler.et.redhat.com There's also virt-install, which also works Neither of those do parameter tweaking for post-install changes, so using virsh there is the way to go. --Michael From mdehaan at redhat.com Thu Jun 28 22:09:23 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 28 Jun 2007 18:09:23 -0400 Subject: [et-mgmt-tools] Virt-factory 0.0.3 Released In-Reply-To: <46842FF7.705@redhat.com> References: <46842FF7.705@redhat.com> Message-ID: <46843193.1060507@redhat.com> Michael DeHaan wrote: > Virt-Factory? What's that? > > Basically, Virt-factory is our ongoing project to make better tools > for managing a very large number (like a datacenter's worth) of Xen > machines and virtual appliances. > http://virt-factory.et.redhat.com > > For virt-factory to help command infrastructure, it has to have a pool > of physical hosts assigned to it. You can either PXE new machines > from the VF server, or register existing ones using a command line > registration tool. From there, you can use the Web UI to add more > virtual machines to any of your hosts and control the virtualization > state of those machines. Currently it's not quite up to speed with > virt-manager in terms of feature parity, but it does have > start/stop/pause/shutdown/etc controls -- we're getting there. > Supporting migration is on the roadmap. > > Virt-Factory is different from other management apps in a few key > areas. We use the concept of Profiles to say what a machine does. > This integrates systems management (Puppet) with the provisioning > process (Cobbler) all in one easy step -- and all controlled with a > very simple user interface. Administrators can create (or import) > profiles, assign them to existing machines, and share them with other > virt-factory users. ISVs could also create profiles for commercial > software. Basically, profiles are a lightweight way of building > software appliances. > Future releases will also concentrate heavily on batch management, > such as finding good candidates to migrate virtual machines to when > taking a physical host offline, or doing interesting things with > tagging and reporting. So, by integrating systems management tools > in with good batch management solutions, we'll have a unique (and > free) solution > for doing a lot of interesting things around virtualization management. > > This particular release adds several new things: > > -- More streamlined setup process > (http://virt-factory.et.redhat.com/vf-install-setup.php) > -- User interface is now rethemed and improved -- (thanks to M?ir?n > Duffy for help on this) > -- The server now sets up and runs PostgreSQL automatically -- as > opposed to sqlite > -- Changes to work with newer builds of Puppet > -- Localization framework (though no included translations yet) > -- Lots of code/architectural cleanup and bugfixes > > Our plans for future releases are detailed here: > http://virt-factory.et.redhat.com/vf-roadmap.php > > Keep in mind this project is still getting off the ground somewhat, so > it's not quite ready for production use. The next release (0.0.4) > will address a lot of those critical features. > If you have comments, questions, or ideas ... as usual, we'd love to > hear them. Check out http://virt-factory.et.redhat.com, email us > here, or stop by on IRC. We have a channel #virt-factory on > irc.freenode.net. > > Downloads are here: http://virt-factory.et.redhat.com/download.php > > Thanks! > > Michael DeHaan > Adrian Likins > Scott Seago > > > > > > > > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I also forgot to credit the following folks for help on 0.0.3: Thanks to... Kevin Smith Jeff Ortel Jesus Rodriguez Appreciate the help, guys :) From berrange at redhat.com Thu Jun 28 22:55:31 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 28 Jun 2007 23:55:31 +0100 Subject: [et-mgmt-tools] Re: About keeping the cdrom in the permanent XML for a guest after install In-Reply-To: <4683EC65.7070601@redhat.com> References: <4683EC65.7070601@redhat.com> Message-ID: <20070628225530.GE12711@redhat.com> On Thu, Jun 28, 2007 at 01:14:13PM -0400, Hugh Brock wrote: > Oops, meant to reply to the list, not just to Nobuhiro-san... > > Nobuhiro Itou wrote: > > Hi, Hugh > > > > I have an opinion about the following corrections. > > https://www.redhat.com/archives/et-mgmt-tools/2007-June/msg00124.html > > > > I think that this correction has added the procedure to the Linux > guest user. > > In case of Linux, if installation is finished, the cdrom (/dev/cdrom) > is not necessary. > > The user has to detach one by one. > > > > And, before correction, the cdrom with no source was attached after > installation. Isn't it enough for Windows? xm block-configure exchange > the cdrom when Windows asks for it, > > and since the cdrom with no source is positioning like the physics CD > device with no media, it is not necessary to detach it after use. > > > > I recognize the problem of Windows had been already solved before > correction. > > > > Cannot you retrieve to the state before this correction? > > > > > > Thanks, > > Nobuhiro Itou. > > 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. 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. 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 Thu Jun 28 22:59:55 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 28 Jun 2007 23:59:55 +0100 Subject: [et-mgmt-tools] VM images In-Reply-To: <1183055484.4013.1.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> Message-ID: <20070628225955.GF12711@redhat.com> On Thu, Jun 28, 2007 at 11:31:24AM -0700, David Lutterkort wrote: > On Wed, 2007-06-27 at 10:51 +0100, Mark McLoughlin wrote: > > I don't imagine this multi-VM appliance thing will ever work out and be > > useful, but if we did want to do that surely we'd have multiple > > descriptions? The boot descriptions, disks and defaults are all distinct > > and unrelated ... the only metadata I can imagine to tie them all > > together would be some way for them to find each other on the network. > > > > (i.e. to allow for this, I'd just add an root element) > > 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. BTW, I thing is better called for consistency with the libvirt naming of . The and elements already match the libvirt terminology. 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 Thu Jun 28 23:05:48 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 29 Jun 2007 00:05:48 +0100 Subject: [et-mgmt-tools] Where is the Configuration File? In-Reply-To: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> Message-ID: <20070628230548.GG12711@redhat.com> On Thu, Jun 28, 2007 at 05:00:53PM -0400, Steve Brueckner wrote: > Hugh Brock wrote: > > > > With xen 3.1, config information for guests is no longer in /etc/xen, > > nor is it modifiable by editing a config file. XenSource decided it > > was better to hide the config information. > > > > Virt-manager gets information about active and inactive guests by > > querying libvirt for them. libvirt then turns around and asks xend, > > or whatever hypervisor you are using, for the information and returns > > it. for You can do the same thing from the command line with "virsh > > dumpxml ". > > > > --Hugh > > What is the new "Xen way" of creating VMs? That is, without using > virt-manager, how do they recommend users do things? Their user > manual is still stuck at version 3.0. They provide a way to feed a config into XenD with 'xm new ' which takes a file in same format as those in /etc/xen. They don't provide any way to get the config back out in that format :-( So for Xen 3.0.4 or later we recommend either 1. Using virsh virsh dumpxml {guest} > guest.xml vi guest.xml virsh define guest.xml 2. Using virt-manager - the 'Details' dialog of a VM lets you alter a subset of the config options. Memory, max memory, vCPU count and addition/removal of disk & network devices. If you're requirements are satisfied by 2, that's the best, otherwise option 1 is more general purpose. We're trying to expand the coverage of config parameters in both cases. Of course both these methods work with Xen, KVM, QEMU & KQEMU guests 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 youhongyu at icst.pku.edu.cn Fri Jun 29 02:19:34 2007 From: youhongyu at icst.pku.edu.cn (youhongyu) Date: Fri, 29 Jun 2007 10:19:34 +0800 Subject: [et-mgmt-tools] kvm+virtmanager can't save machine state? References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> <468421E1.8020301@redhat.com> Message-ID: <00ab01c7b9f3$ef44bf40$64191fac@icstdom.icst.pku.edu.cn> hi all, i use: fc7, built in xen, kvm. i boot my machine into normal kernal and install a guest os by vir-manager, and i encounter a strange situation .... the "save" command from virtual menu failed! it pop out a small windows seem want to tell me something, but it quickly disappeared. what's thing happens? btw, the "save" function is ok when xen+virtmanager. regards. youhongyu 20070629 From youhongyu at icst.pku.edu.cn Fri Jun 29 02:54:25 2007 From: youhongyu at icst.pku.edu.cn (youhongyu) Date: Fri, 29 Jun 2007 10:54:25 +0800 Subject: [et-mgmt-tools] when and how to modify xen paravirtualized guest os kernel after install it by virt-manager? References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> <468421E1.8020301@redhat.com> Message-ID: <00bf01c7b9f8$cd9f36e0$64191fac@icstdom.icst.pku.edu.cn> hi all, it is said that paravirtualized virtual machine need a modified kernel, isn't this true? i install fc7 as a guest os by virtual-manager in xen mode, but no where have noticed me to do any modification with guest os kernel, why? thank to all youhongyu 20070629 From rjones at redhat.com Fri Jun 29 07:48:28 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 29 Jun 2007 08:48:28 +0100 Subject: [et-mgmt-tools] Re: [Libvir] Proposal: New virDomainLookup function to indicate Not found vs Error In-Reply-To: <20070628125639.GE16385@redhat.com> References: <46826976.2090903@redhat.com> <20070628125639.GE16385@redhat.com> Message-ID: <4684B94C.1060005@redhat.com> Daniel P. Berrange wrote: > That said, I'm not convinced we need this if we fix the error reporting > of the original functions to allow the 'no such domain' error to be > reliably caught & handled. OK, I tend to agree. I'll come up with a patch which adds the no-such-domain/network errors and make libvirt return them when appropriate. 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 rob at vanoostveen.net Fri Jun 29 12:12:12 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Fri, 29 Jun 2007 14:12:12 +0200 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <4682CA10.7040107@redhat.com> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> <4682CA10.7040107@redhat.com> Message-ID: <20070629120842.M91934@dataregiocentre.com> Hugh, > Yes, I have had this same problem when building libvirt on machines > where I had forgotten to install xen-devel. The build config for libvirt > automatically sets WITH_XEN=no if it doesn't find xen-devel, without > telling you it's doing it... we should probably fix that at some point... I downloaded the xen-devel-3.1.0-1.i386.rpm from the xensource download page. But libvirt doesnt compile with xen support. I installed the package with --nodeps cause I dont have de xen package installed by rpm, but instead by source. Can you tell me where to find the xen-devel files when I build the Xen environment with source? Thanks again. Regards, Rob From chris.sarginson at ukfast.net Fri Jun 29 12:51:40 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Fri, 29 Jun 2007 13:51:40 +0100 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <20070629120842.M91934@dataregiocentre.com> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> <4682CA10.7040107@redhat.com> <20070629120842.M91934@dataregiocentre.com> Message-ID: <4685005C.6070504@ukfast.net> Hi Rob, Depending on if you set a prefix when running ./configure I would recommend checking /usr/local/lib/ for the files you require. Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BD Registered in England. Number 384 5616 Rob van Oostveen wrote: > Hugh, > >> Yes, I have had this same problem when building libvirt on machines >> where I had forgotten to install xen-devel. The build config for libvirt >> automatically sets WITH_XEN=no if it doesn't find xen-devel, without >> telling you it's doing it... we should probably fix that at some point... > > I downloaded the xen-devel-3.1.0-1.i386.rpm from the xensource download page. > But libvirt doesnt compile with xen support. I installed the package with > --nodeps cause I dont have de xen package installed by rpm, but instead by source. > > Can you tell me where to find the xen-devel files when I build the Xen > environment with source? > > Thanks again. > > Regards, > Rob > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BD Registered in England. Number 384 5616 From berrange at redhat.com Fri Jun 29 12:59:56 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 29 Jun 2007 13:59:56 +0100 Subject: [et-mgmt-tools] [RFC] Approach to installing a localized virtinst In-Reply-To: <4684018D.3090309@redhat.com> References: <4684018D.3090309@redhat.com> Message-ID: <20070629125955.GA25518@redhat.com> 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. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From chris.sarginson at ukfast.net Fri Jun 29 13:15:50 2007 From: chris.sarginson at ukfast.net (Chris Sarginson) Date: Fri, 29 Jun 2007 14:15:50 +0100 Subject: [et-mgmt-tools] [Cobbler] Query/Recommendation regarding pxesystem.template Message-ID: <46850606.8000008@ukfast.net> Hi, A quick recommendation for cobbler when an architecture is not detected or specified: It currently uses /etc/cobbler/pxesystem.template when a system is added in using a profile with an unknown architecture. That file is as follows: default linux prompt 0 timeout 1 label linux kernel $kernel_path append $append_line Cobbler sync however adds in the "append" line automatically, so you end up with a dual append line. I'm not sure if this breaks anything, but just for the sake of tidiness the append $append_line should be abridged to just "$append_line". Can anyone see a problem with this? -- Kind regards Chris Sarginson Technical Support UKFast.Net Ltd (t) 0870 111 8866 (f) 0870 458 4545 "The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005 Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BD Registered in England. Number 384 5616 From mdehaan at redhat.com Fri Jun 29 13:50:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 29 Jun 2007 09:50:05 -0400 Subject: [et-mgmt-tools] when and how to modify xen paravirtualized guest os kernel after install it by virt-manager? In-Reply-To: <00bf01c7b9f8$cd9f36e0$64191fac@icstdom.icst.pku.edu.cn> References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> <468421E1.8020301@redhat.com> <00bf01c7b9f8$cd9f36e0$64191fac@icstdom.icst.pku.edu.cn> Message-ID: <46850E0D.8010000@redhat.com> youhongyu wrote: > hi all, > > it is said that paravirtualized virtual machine need a modified kernel, isn't this true? > i install fc7 as a guest os by virtual-manager in xen mode, but no where have noticed me to do any modification with guest os kernel, why? > > thank to all > > youhongyu > 20070629 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > Basically you just need to "yum install kernel-xen" as opposed to "kernel" and verify that the Xen kernel option is selected in grub when you boot. It sounds like you are already running the Xen kernel, so you're good to go. --Michael From mdehaan at redhat.com Fri Jun 29 13:51:33 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 29 Jun 2007 09:51:33 -0400 Subject: [et-mgmt-tools] [Cobbler] Query/Recommendation regarding pxesystem.template In-Reply-To: <46850606.8000008@ukfast.net> References: <46850606.8000008@ukfast.net> Message-ID: <46850E65.7050700@redhat.com> Chris Sarginson wrote: > Hi, > > A quick recommendation for cobbler when an architecture is not > detected or specified: > > It currently uses /etc/cobbler/pxesystem.template when a system is > added in using a profile with an unknown architecture. That file is > as follows: > > default linux > prompt 0 > timeout 1 > label linux > kernel $kernel_path > append $append_line > > Cobbler sync however adds in the "append" line automatically, so you > end up with a dual append line. I'm not sure if this breaks anything, > but just for the sake of tidiness the append $append_line should be > abridged to just "$append_line". > > Can anyone see a problem with this? > This was reported earlier, but I hadn't tracked down root cause yet -- Thanks! I'll fix this in upstream. --Michael From rob at vanoostveen.net Fri Jun 29 13:50:26 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Fri, 29 Jun 2007 15:50:26 +0200 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <4685005C.6070504@ukfast.net> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> <4682CA10.7040107@redhat.com> <20070629120842.M91934@dataregiocentre.com> <4685005C.6070504@ukfast.net> Message-ID: <20070629134358.M49374@vanoostveen.net> Chris, Thank you for your reply. > Depending on if you set a prefix when running ./configure I would > recommend checking /usr/local/lib/ for the files you require. I'm building the libvirt and virt-manager with ./configure --prefix=/usr And with libvirt I add --with-xen=yes. When finished building libvirt I do a make check and all tests are successful. Then I start virt-manager and it complains about not finding the network. Regards, Rob From hbrock at redhat.com Fri Jun 29 14:04:07 2007 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 29 Jun 2007 10:04:07 -0400 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <20070629134358.M49374@vanoostveen.net> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> <4682CA10.7040107@redhat.com> <20070629120842.M91934@dataregiocentre.com> <4685005C.6070504@ukfast.net> <20070629134358.M49374@vanoostveen.net> Message-ID: <46851157.3060303@redhat.com> Rob van Oostveen wrote: > Chris, > > Thank you for your reply. > >> Depending on if you set a prefix when running ./configure I would >> recommend checking /usr/local/lib/ for the files you require. > > I'm building the libvirt and virt-manager with > > ./configure --prefix=/usr > > And with libvirt I add --with-xen=yes. > > When finished building libvirt I do a make check and all tests are successful. > > Then I start virt-manager and it complains about not finding the network. > > Regards, > Rob > Sounds like you're getting somewhere, anyway. A few more things to try: 1. does "virsh list -c test:///default" return normally? 2. what about just "virsh list"? 3. Have you started or restarted libvirtd? 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 rob at vanoostveen.net Fri Jun 29 14:21:48 2007 From: rob at vanoostveen.net (Rob van Oostveen) Date: Fri, 29 Jun 2007 16:21:48 +0200 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <46851157.3060303@redhat.com> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> <4682CA10.7040107@redhat.com> <20070629120842.M91934@dataregiocentre.com> <4685005C.6070504@ukfast.net> <20070629134358.M49374@vanoostveen.net> <46851157.3060303@redhat.com> Message-ID: <20070629141453.M75396@vanoostveen.net> Hugh, > 1. does "virsh list -c test:///default" return normally? It complains about the -c param: error: unexpected data '-c' > 2. what about just "virsh list"? libvir: QEMU error: connect: /usr/var/libvirt/qemud-sock: no such file or directory libvir: failed to find the network: Is the daemon running? Id Name State -------------------------------------------- 0 Domain-0 Running > 3. Have you started or restarted libvirtd? The daemon is not running. Where can I find it? Do I have to build it seperately? Thanks, Rob From youhongyu at icst.pku.edu.cn Fri Jun 29 14:48:30 2007 From: youhongyu at icst.pku.edu.cn (youhongyu) Date: Fri, 29 Jun 2007 22:48:30 +0800 Subject: [et-mgmt-tools] when and how to modify xen paravirtualized guest os kernel after install it by virt-manager? In-Reply-To: <46850E0D.8010000@redhat.com> References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> <468421E1.8020301@redhat.com> <00bf01c7b9f8$cd9f36e0$64191fac@icstdom.icst.pku.edu.cn> <46850E0D.8010000@redhat.com> Message-ID: <46851BBE.8070407@icst.pku.edu.cn> Michael DeHaan ??: > youhongyu wrote: >> hi all, >> >> it is said that paravirtualized virtual machine need a modified >> kernel, isn't this true? >> i install fc7 as a guest os by virtual-manager in xen mode, but no >> where have noticed me to do any modification with guest os kernel, why? >> >> thank to all >> >> youhongyu >> 20070629 >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > Basically you just need to "yum install kernel-xen" as opposed to > "kernel" and verify that the Xen kernel option is selected in grub > when you boot. > > It sounds like you are already running the Xen kernel, so you're good > to go. > > --Michael > > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > You mean that only the host kernel need to be modified, and the guest os kernel need NOT to be modified? when with or without vt support? Thank you! youhongyu 20070629 From mdehaan at redhat.com Fri Jun 29 14:58:43 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 29 Jun 2007 10:58:43 -0400 Subject: [et-mgmt-tools] when and how to modify xen paravirtualized guest os kernel after install it by virt-manager? In-Reply-To: <46851BBE.8070407@icst.pku.edu.cn> References: <60D45469A1AAD311A04C009027B6BF6806225940@SERVER20> <468421E1.8020301@redhat.com> <00bf01c7b9f8$cd9f36e0$64191fac@icstdom.icst.pku.edu.cn> <46850E0D.8010000@redhat.com> <46851BBE.8070407@icst.pku.edu.cn> Message-ID: <46851E23.2030101@redhat.com> youhongyu wrote: > Michael DeHaan ??: >> youhongyu wrote: >>> hi all, >>> >>> it is said that paravirtualized virtual machine need a modified >>> kernel, isn't this true? >>> i install fc7 as a guest os by virtual-manager in xen mode, but no >>> where have noticed me to do any modification with guest os kernel, why? >>> >>> thank to all >>> >>> youhongyu >>> 20070629 >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> Basically you just need to "yum install kernel-xen" as opposed to >> "kernel" and verify that the Xen kernel option is selected in grub >> when you boot. >> >> It sounds like you are already running the Xen kernel, so you're good >> to go. >> >> --Michael >> >> >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > You mean that only the host kernel need to be modified, and the guest > os kernel need NOT to be modified? when with or without vt support? > Thank you! > > youhongyu > 20070629 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Both the host and guest have to use "kernel-xen" to have paravirtualized guests. For full virt, only the host needs the xen kernel. From rjones at redhat.com Fri Jun 29 19:26:11 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 29 Jun 2007 20:26:11 +0100 Subject: [et-mgmt-tools] Unable to open connection In-Reply-To: <20070629141453.M75396@vanoostveen.net> References: <20070627170359.M41317@dataregiocentre.com> <46829C6F.50400@redhat.com> <20070627172645.M78641@vanoostveen.net> <46829F36.9060208@redhat.com> <20070627202535.M17351@dataregiocentre.com> <4682CA10.7040107@redhat.com> <20070629120842.M91934@dataregiocentre.com> <4685005C.6070504@ukfast.net> <20070629134358.M49374@vanoostveen.net> <46851157.3060303@redhat.com> <20070629141453.M75396@vanoostveen.net> Message-ID: <46855CD3.5080105@redhat.com> Rob van Oostveen wrote: > Hugh, > >> 1. does "virsh list -c test:///default" return normally? > > It complains about the -c param: > error: unexpected data '-c' Try: virsh -c test:///default list I suspect that the ordering of the parameters is important. For me, this gives: $ virsh -c test:///default list libvir: Remote error : Connection refused libvir: warning : Failed to find the network: Is the daemon running ? Id Name State ---------------------------------- 1 test running (The "Remote error" is because I'm running a very recent libvirt without running the libvirtd daemon, but is otherwise harmless). 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 dlutter at redhat.com Fri Jun 29 19:36:55 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 29 Jun 2007 12:36:55 -0700 Subject: [et-mgmt-tools] Appliance example Message-ID: <1183145815.3924.1.camel@galia.watzmann.net> Hi, I posted the example kronolith appliance and instructions on creating an image/using a recipe and needed files at [1] David [1] http://people.redhat.com/dlutter/kronolith-appliance/index.html From drew.einhorn at gmail.com Fri Jun 29 22:18:23 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Fri, 29 Jun 2007 16:18:23 -0600 Subject: [et-mgmt-tools] Getting started with cobbler Message-ID: 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 drew.einhorn at gmail.com Fri Jun 29 22:22:37 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Fri, 29 Jun 2007 16:22:37 -0600 Subject: [et-mgmt-tools] VMware? Message-ID: 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. -- Drew Einhorn From drew.einhorn at gmail.com Fri Jun 29 23:51:30 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Fri, 29 Jun 2007 17:51:30 -0600 Subject: [et-mgmt-tools] Re: Getting started with cobbler In-Reply-To: References: Message-ID: 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 From drew.einhorn at gmail.com Sat Jun 30 00:10:28 2007 From: drew.einhorn at gmail.com (drew einhorn) Date: Fri, 29 Jun 2007 18:10:28 -0600 Subject: [et-mgmt-tools] Re: Getting started with cobbler In-Reply-To: References: Message-ID: 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. On 6/29/07, 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. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: