From tc.nuwal at gmail.com Wed May 2 06:35:58 2007 From: tc.nuwal at gmail.com (trilok nuwal) Date: Wed, 2 May 2007 12:05:58 +0530 Subject: [et-mgmt-tools] virt-install problem. Message-ID: Hi All, I am installing the RHEL PV through virt-install, #virt-install --name=dom1 --ram=500 --file=/home/disk --file-size=10 --mac=00:50:56:2d:31:6d --bridge=xenbr2 --nographics --noautoconsole --paravirt --location=nfs:server3.domain.com:/vol/vol1/tnuwal/rl5 --debug -x "ks=http://khost/ks.cfg ksdevice=eth2" Here eth2 is my public IP and xenbr2 is bridge over this. When i start the install then i got following message on console of this. Starting install... libvir: Xen Daemon error : GET operation failed: Domain installation still in progress. You can reconnect to the console to complete the installation process. Now when i tried to connect the console ...Then it started the instllation But this stuck that it could not download the kickstart file http://khost/ks.cfg. ks=http://khost.domain.com/ks.cfg. Why is it happening as i can download this file on dom0 using wget. Because khost and my machine are well pingable. +-------------+ Error downloading kickstart file +-------------+ | | | Unable to download the kickstart file. Please modify the | | kickstart parameter below or press Cancel to proceed as an | | interactive installation. | | | | http:///khost.domain.com/ks.cfg__________________ __ | | | | +----+ +--------+ | | | OK | | Cancel | | | +----+ +--------+ | | | | | +--------------------------------------------------------------+ # Contents of the file are lang en_US.UTF-8 langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us skipx network --device eth2 --bootproto static --ip 139.185.48.217 --netmask 255.255.252.0 --gateway 139.185.48.1 --nameserver 130.35.249.41 --hostname os217.domain.com rootpw root firewall --disabled selinux --disabled authconfig --enableshadow --enablemd5 timezone America/Los_Angeles text reboot .....Could u please tell me where i am doing wrong. Thanks, Trilok Nuwal -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Wed May 2 12:15:28 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:15:28 +0100 Subject: [et-mgmt-tools] [patch 0/8] [virtinst] Add installer concept and livecd installer example Message-ID: <20070502120733.362541000@redhat.com>> Hey, This set of patches explores the notion of allowing virtinst to have different installer types apart from the existing support for distribution installers. This notion can be used to e.g. support livecd or pre-built system images. Cheers, Mark. From markmc at redhat.com Wed May 2 12:15:43 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:15:43 +0100 Subject: [et-mgmt-tools] [patch 1/8] Add Installer and re-factor existing code into DistroInstaller References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120954.977767000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-distro-installer-refactor.patch URL: From markmc at redhat.com Wed May 2 12:16:01 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:16:01 +0100 Subject: [et-mgmt-tools] [patch 2/8] Make virt-install use DistroInstaller References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120955.062509000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-use-distro-installer.patch URL: From markmc at redhat.com Wed May 2 12:16:11 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:16:11 +0100 Subject: [et-mgmt-tools] [patch 3/8] Move post install check into DistroInstaller References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120955.144942000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-installer-post-install-check.patch URL: From markmc at redhat.com Wed May 2 12:16:23 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:16:23 +0100 Subject: [et-mgmt-tools] [patch 4/8] Re-factor virt-installs post-install checking code References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120955.227415000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-post-install-refactor.patch URL: From markmc at redhat.com Wed May 2 12:16:33 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:16:33 +0100 Subject: [et-mgmt-tools] [patch 5/8] Allow the installer to skip the first VM boot References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120955.309929000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-no-config-no-install.patch URL: From markmc at redhat.com Wed May 2 12:16:46 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:16:46 +0100 Subject: [et-mgmt-tools] [patch 6/8] This patch adds two new options to virt-install: References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120955.392315000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-installer-type-option.patch URL: From markmc at redhat.com Wed May 2 12:16:55 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:16:55 +0100 Subject: [et-mgmt-tools] [patch 7/8] Add CapabilitiesParser module References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120955.474768000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-capabilities-parser.patch URL: From markmc at redhat.com Wed May 2 12:17:06 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:17:06 +0100 Subject: [et-mgmt-tools] [patch 8/8] Add the livecd installer References: <20070502120733.362541000@redhat.com>> Message-ID: <20070502120955.557576000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: virtinst-livecd-installer.patch URL: From markmc at redhat.com Wed May 2 12:26:06 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 May 2007 13:26:06 +0100 Subject: [et-mgmt-tools] [PATCH] First-cut at livecd support in virt-manager Message-ID: <1178108766.14265.5.camel@blaa> Hey, The attached patch demos how we might add livecd support to virt-manager using the virtinst patches I just posted. The way I did in the patch isn't great, but the basic idea is that in order to boot a LiveCD you'd go through the create wizard as follows: - Intro - as normal - Name - choose a name for the VM - Type - choose LiveCD instead of fully-virt or paravirt - Location - choose the path of the LiveCD iso or device, choose OS type or variant - Disks - default it to create no disks, but you can choose to create a disk too - Network/CPU/Finish - as normal Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-populate-cd-list-refactor.patch Type: text/x-patch Size: 3185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-livecd.patch Type: text/x-patch Size: 92203 bytes Desc: not available URL: From mail.baruchi at gmail.com Wed May 2 14:22:01 2007 From: mail.baruchi at gmail.com (Artur Baruchi) Date: Wed, 2 May 2007 11:22:01 -0300 Subject: [et-mgmt-tools] Kernel / Hardware Acceleration Error Message-ID: Hi, I was using the virt-manager to install a Fully Virtualized System, and I checked the option "Enable kernel / hardware acceleration", but when Im at the end (when I click in Finish) appear the follow error: virDomainCreateLinux() failed internal error End-of-file while reading PTY startup output Details: 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/local/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 647, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 664, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/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 ' But when I dont check the option "Enable kernel / hardware acceleration", the installation goes normal. What would be this Kernel / Hardware Acceleration ? [root at athlonam2 FC6_64]# lsmod | grep kvm kvm_amd 25297 0 kvm 64421 1 kvm_amd [root at athlonam2 FC6_64]# grep svm /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy As u can see, KVM modules are running and my Processor has the flag SVM. Thanks, Att. Artur Baruchi From berrange at redhat.com Wed May 2 14:31:07 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 2 May 2007 15:31:07 +0100 Subject: [et-mgmt-tools] Kernel / Hardware Acceleration Error In-Reply-To: References: Message-ID: <20070502143107.GH9518@redhat.com> On Wed, May 02, 2007 at 11:22:01AM -0300, Artur Baruchi wrote: > Hi, > > I was using the virt-manager to install a Fully Virtualized System, > and I checked the option "Enable kernel / hardware acceleration", but > when Im at the end (when I click in Finish) appear the follow error: > virDomainCreateLinux() failed internal error End-of-file while reading > PTY startup output > > Details: > 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/local/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 647, > in start_install > return self._do_install(consolecb, meter) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 664, > in _do_install > self.domain = self.conn.createLinux(install_xml, 0) > File "/usr/lib64/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 > ' > > But when I dont check the option "Enable kernel / hardware > acceleration", the installation goes normal. Do you have the KVM userspace installed ? This is in the 'kvm' RPM and provides the '/usr/bin/qemu-kvm' binary needed to do acceleration. 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 Wed May 2 15:44:29 2007 From: marcmo at foxriver.com (Marc Mondragon) Date: Wed, 2 May 2007 10:44:29 -0500 Subject: [et-mgmt-tools] kernel_options in /var/lib/cobbler/settings Message-ID: <87C9906AAD26A24E8E0C2A31287031BE01053FDB@FREXGENEVA-01.frfr.foxriver.com> I know this area of cobbler has changed a bit and I'm trying to figure the best way to do the following: 1. Add serial console settings to this file in order to have them appended properly to the tftp boot files. 2. Have the serial console setting only apply to server installations, not workstation installations? Marc Mondragon ? Fox River Financial Resources/Ritchie Capital Investments, Ltd. 2100 Enterprise Avenue Geneva, IL? 60134 marcmo at foxriver.com From mail.baruchi at gmail.com Wed May 2 15:48:02 2007 From: mail.baruchi at gmail.com (Artur Baruchi) Date: Wed, 2 May 2007 12:48:02 -0300 Subject: [et-mgmt-tools] Kernel / Hardware Acceleration Error In-Reply-To: <20070502143107.GH9518@redhat.com> References: <20070502143107.GH9518@redhat.com> Message-ID: Yes, but I downloaded it from rpmfind.net and for fedora core 3. Do u know a url to download a rpm to FC6_x86_64 ? I guess that it isnt working fine... Thanks, Att. Artur Baruchi On 5/2/07, Daniel P. Berrange wrote: > On Wed, May 02, 2007 at 11:22:01AM -0300, Artur Baruchi wrote: > > Hi, > > > > I was using the virt-manager to install a Fully Virtualized System, > > and I checked the option "Enable kernel / hardware acceleration", but > > when Im at the end (when I click in Finish) appear the follow error: > > virDomainCreateLinux() failed internal error End-of-file while reading > > PTY startup output > > > > Details: > > 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/local/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 647, > > in start_install > > return self._do_install(consolecb, meter) > > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 664, > > in _do_install > > self.domain = self.conn.createLinux(install_xml, 0) > > File "/usr/lib64/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 > > ' > > > > But when I dont check the option "Enable kernel / hardware > > acceleration", the installation goes normal. > > Do you have the KVM userspace installed ? This is in the 'kvm' RPM > and provides the '/usr/bin/qemu-kvm' binary needed to do acceleration. > > 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 mdehaan at redhat.com Wed May 2 16:11:10 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 02 May 2007 12:11:10 -0400 Subject: [et-mgmt-tools] kernel_options in /var/lib/cobbler/settings In-Reply-To: <87C9906AAD26A24E8E0C2A31287031BE01053FDB@FREXGENEVA-01.frfr.foxriver.com> References: <87C9906AAD26A24E8E0C2A31287031BE01053FDB@FREXGENEVA-01.frfr.foxriver.com> Message-ID: <4638B81E.4090603@redhat.com> Marc Mondragon wrote: > I know this area of cobbler has changed a bit and I'm trying to figure the best way to do the following: > > 1. Add serial console settings to this file in order to have them appended properly to the tftp boot files. > 2. Have the serial console setting only apply to server installations, not workstation installations? > (1) To do this across the board, you just edit /var/lib/cobbler/settings ... though it sounds like you have something better in mind by (2). (2) To do this to just some machines, it looks something like this... When adding a cobbler profile, do something like this: cobbler profile add --name=serverprofilename --distro=distroname --kopts="console=ttyS0,57600" And for the workstation profile, don't add the same "--kopts"... cobbler profile add --name=workstationprofilename --distro=distroname If you already have profiles you like defined, cobbler allows for editing now, so you can tweak an existing profile to add the serial console magic... cobbler profile edit --name=serverprofilename --kopts="console=ttyS0,57600" So, any time you provision based on the "serverprofilename" profile, you'll get the serial console, and in other cases, you won't... Hope that helps... --Michael > Marc Mondragon > > Fox River Financial Resources/Ritchie Capital Investments, Ltd. > 2100 Enterprise Avenue > Geneva, IL 60134 > marcmo at foxriver.com > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From thestrider at gmail.com Wed May 2 16:12:42 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Wed, 2 May 2007 12:12:42 -0400 Subject: [et-mgmt-tools] kernel_options in /var/lib/cobbler/settings In-Reply-To: <87C9906AAD26A24E8E0C2A31287031BE01053FDB@FREXGENEVA-01.frfr.foxriver.com> References: <87C9906AAD26A24E8E0C2A31287031BE01053FDB@FREXGENEVA-01.frfr.foxriver.com> Message-ID: <658267190705020912n55d6a174p5ced5dbc4869e398@mail.gmail.com> Marc, You can have separate "workstation" and "server" profiles and, for each, you can specify different --kopts settings. For instance, to enable serial console redirection on server profile: cobbler profile add --name=servers ... --kopts=" console=ttyS0,9600n8" ... --A. On 5/2/07, Marc Mondragon wrote: > > I know this area of cobbler has changed a bit and I'm trying to figure the > best way to do the following: > > 1. Add serial console settings to this file in order to have them appended > properly to the tftp boot files. > 2. Have the serial console setting only apply to server installations, not > workstation installations? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoffing at novell.com Wed May 2 20:28:34 2007 From: ccoffing at novell.com (Charles Coffing) Date: Wed, 02 May 2007 14:28:34 -0600 Subject: [et-mgmt-tools] [PATCH] fix VNC connection errors in virt-manager Message-ID: <46389F13.D169.003C.0@novell.com> There is a nasty typo in virt manager, which is masked by a catch-all "except:" clause. This error could cause unnecessary VNC connection failures. The bad line is actually completely useless, since disconnect_from_host correctly sets self.client=None. The preceeding "if" is also useless, since disconnect_from_host handles the case where self.client is None. The attached patch deletes all this unnecessary junk. Signed-off-by: Charles Coffing -------------- next part -------------- A non-text attachment was scrubbed... Name: virtman-typo.diff Type: application/octet-stream Size: 672 bytes Desc: not available URL: From mdehaan at redhat.com Wed May 2 20:45:48 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 02 May 2007 16:45:48 -0400 Subject: [et-mgmt-tools] virt factory 0.0.2 released Message-ID: <4638F87C.1010605@redhat.com> Virt-factory 0.0.2 is out... If you're joining this list late and aren't sure what virt-factory is, Virt-Factory is a framework for managing a very large number of virtual machines on a network -- we're targetting datacenters and labs -- and it allows managing machines in an appliancey sort of way, assigning them to specific profiles that serve particular roles. You can provision a pool of host machines (or just register the ones you have) and then deploy virtual profiles out to them. It has a web interface for humans and we'll be working on a command line interface to match for remote scripting purposes. http://virt-factory.et.redhat.com/ This release mainly concentrates mainly on making virt-factory easier to install and bootstrap. It is still rather alpha-level in many ways, but we are always interested in hearing from those folks who want to manage a large number of virtual machines and deploy virtual appliances. Future-releases will concentrate mainly on the items here: http://et.redhat.com/page/VF_Planning, though these will probably be rearranged somewhat over time. As currently planned, the next release will concentrate on moving virt-factory to a real database (PostgreSQL and/or MySQL), bring in a professionally designed lickable WUI (shininess is important!), and streamlining the node communications using AMQP/QPid (http://cwiki.apache.org/qpid/). If you have questions or ideas that you'd like to share over IRC, stop by #virt-factory on irc.freenode.net... Michael DeHaan Adrian Likins Scott Seago From markmc at redhat.com Thu May 3 16:13:38 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 03 May 2007 17:13:38 +0100 Subject: [et-mgmt-tools] [patch 1/8] Add Installer and re-factor existing code into DistroInstaller In-Reply-To: <20070502120954.977767000@redhat.com>> References: <20070502120733.362541000@redhat.com> > <20070502120954.977767000@redhat.com>> Message-ID: <1178208818.3467.16.camel@blaa> Hey, Hugh points out that this patch was malformed. No idea what happened there, but fixed version attached. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-distro-installer-refactor.patch Type: text/x-patch Size: 24694 bytes Desc: not available URL: From mdehaan at redhat.com Thu May 3 16:58:52 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 03 May 2007 12:58:52 -0400 Subject: [et-mgmt-tools] Question regarding api.sync and the necessity of using MAC addresses as system.name in dhcp templating In-Reply-To: <658267190704252310v52d25ffal1fd3069af211e026@mail.gmail.com> References: <658267190704252310v52d25ffal1fd3069af211e026@mail.gmail.com> Message-ID: <463A14CC.5030405@redhat.com> IRC discussions today (thanks, Adam) made me realize I hadn't replied to this yet... Adam Rosenwald wrote: > Is the requirement of using MAC addresses as system.name > as a prerequisite for DHCP templating necessary? > I'm trying to understand the reason for the decision to enforce this > policy. Hardware addresses should all be considered 'unique', so the > problem lies with duplicate virtual MAC addresses (at least those > attached to the systems provisioned with cobbler), no? If this is the > reason, I would recommend a resolution as follows: It's a weird requirement that comes from needing to support PXE in a couple of different ways. "Normal" systems can PXE by IP or MAC address, Itanium boxes only do IP. Therefore to support the PXE piece (which is really not relevant for virt) cobbler system objects need to be named after an IP, MAC, or resolvable hostname (that maps to an IP). Now, this may seem overly complex, but fortunately it doesn't have to be. When provisioning virt, it's sufficient to just create a cobbler _profile_ and not create the cobbler system record. The system records are only really needed when a particular piece of hardware needs a PXE record (virt doesn't do PXE in our case), or when it requires specific kernel parameters for it's hardware. So you can just do: koan --virt --profile=nameofprofile --server=bootserver.example.com And you'll get a random MAC address. If you have a requirement to explicitly set the MAC address, however, you can provision using the system object. koan --virt --system=AA:BB:CC:DD:EE:FF --server=bootserver.example.com And the provisioned system will get "AA:BB:CC:DD:EE:FF". > > By default make virtual MAC addresses randomly assigned. The script > from > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Virtualization-en-US/ch19s21.html > > does the job. Maintain an array of cobbler-provisioned MACs and check > against the array before assigning a new, random MAC address to a > provisioned virtual system. The default behavior can be overridden by > the use of another (optional) command line argument to 'cobbler system > (add|edit)'. This frees up system.name to be any > valid hostname and mirrors the behavior of 'xm create'. A more robust > solution would be to have a /var/lib/cobbler/macs file (bound to the > array) which would allow users to manually provision virtual servers > and add the noncobbler-provisioned MACs to the list if they so desired. Something like this (making sure there is a record of systems that cobbler provisioned systems in the cobbler database) is an interesting idea. Currently we're doing things like that in higher level software (http://virt-factory.et.redhat.com) and cobbler is in charge of getting the bits out there, but not keeping track of where they live. There's a lot of different approaches about how that might work, so I've taken the approach to /not/ keep inventory and allow people to deploy by more flexible ways (PXE menus, koan with --profile) in many cases, without requiring the system record. Still, if a higher level app (say a Web app using the cobbler API) wants to create a database and have cobbler system records for every virtual machine, it can do so... in fact, that's what virt-factory does... > > If there is another reason for depriving dhcp templating (and tied-in > arguments; e.g. xen domU names) of anything other than MAC addresses, > I would be curious to understand why. Yeah, the above legacy PXE requirements are pretty much why the Cobbler system object works like it does. However if you want to name virtual machines after something other than their MAC's (something descriptive), you can do so... koan --virt --profile=... --server=... --virt-name=insertnamehere and the virtual machine will appear as something more logical than just the MAC address. > > Thanks, > > - Adam. > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From markmc at redhat.com Thu May 3 20:33:43 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 03 May 2007 21:33:43 +0100 Subject: [et-mgmt-tools] [PATCH] First-cut at livecd support in virt-manager In-Reply-To: <1178108766.14265.5.camel@blaa> References: <1178108766.14265.5.camel@blaa> Message-ID: <1178224423.14747.11.camel@blaa> Hey, Attached is an untested version of the second patch which applies to latest virt-manager. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-livecd.patch Type: text/x-patch Size: 91149 bytes Desc: not available URL: From marcmo at foxriver.com Fri May 4 13:56:10 2007 From: marcmo at foxriver.com (Marc Mondragon) Date: Fri, 4 May 2007 08:56:10 -0500 Subject: [et-mgmt-tools] RE: et-mgmt-tools Digest, Vol 9, Issue 6 In-Reply-To: <20070503160020.E00BB73627@hormel.redhat.com> Message-ID: <87C9906AAD26A24E8E0C2A31287031BE01053FE1@FREXGENEVA-01.frfr.foxriver.com> Thanks, I sort of knew this but wasn't sure completely sure when one can add the kopts/kmeta options (profile/system/??). The addition of the edit command is a nice touch btw. Marc Mondragon Fox River Financial Resources/Ritchie Capital Investments, Ltd. 2100 Enterprise Avenue Geneva, IL 60134 marcmo at foxriver.com > > Message: 1 > Date: Wed, 02 May 2007 12:11:10 -0400 > From: Michael DeHaan > Subject: Re: [et-mgmt-tools] kernel_options in > /var/lib/cobbler/settings > To: Fedora/Linux Management Tools > Message-ID: <4638B81E.4090603 at redhat.com> > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > Marc Mondragon wrote: > > I know this area of cobbler has changed a bit and I'm trying to figure > the best way to do the following: > > > > 1. Add serial console settings to this file in order to have them > appended properly to the tftp boot files. > > 2. Have the serial console setting only apply to server installations, > not workstation installations? > > > (1) To do this across the board, you just edit > /var/lib/cobbler/settings ... though it sounds like you have something > better in mind by (2). > > (2) To do this to just some machines, it looks something like this... > > When adding a cobbler profile, do something like this: > > cobbler profile add --name=serverprofilename --distro=distroname > --kopts="console=ttyS0,57600" > > And for the workstation profile, don't add the same "--kopts"... > > cobbler profile add --name=workstationprofilename > --distro=distroname > > If you already have profiles you like defined, cobbler allows for > editing now, so you can tweak an existing profile to add the serial > console magic... > > cobbler profile edit --name=serverprofilename > --kopts="console=ttyS0,57600" > > So, any time you provision based on the "serverprofilename" profile, > you'll get the serial console, and in other cases, you won't... > > Hope that helps... > > --Michael > > > 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 > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 2 May 2007 12:12:42 -0400 > From: "Adam Rosenwald" > Subject: Re: [et-mgmt-tools] kernel_options in > /var/lib/cobbler/settings > To: "Fedora/Linux Management Tools" > Message-ID: > <658267190705020912n55d6a174p5ced5dbc4869e398 at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Marc, > > You can have separate "workstation" and "server" profiles and, for each, > you can specify different --kopts settings. For instance, to enable > serial > console redirection on server profile: > > cobbler profile add --name=servers ... --kopts=" > console=ttyS0,9600n8" ... > > --A. > > On 5/2/07, Marc Mondragon wrote: > > > > I know this area of cobbler has changed a bit and I'm trying to figure > the > > best way to do the following: > > > > 1. Add serial console settings to this file in order to have them > appended > > properly to the tftp boot files. > > 2. Have the serial console setting only apply to server installations, > not > > workstation installations? > > > > Marc Mondragon > > > > Fox River Financial Resources/Ritchie Capital Investments, Ltd. > > 2100 Enterprise Avenue > > Geneva, IL 60134 > > marcmo at foxriver.com > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From fj1826dm at aa.jp.fujitsu.com Mon May 7 00:11:19 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Mon, 7 May 2007 09:11:19 +0900 Subject: [et-mgmt-tools] [PATCH][RESEND] Send [Ctrl+Alt+Del] and [F8] In-Reply-To: <200704261356.FJE18291.K793ENG2@aa.jp.fujitsu.com> References: <200704191813.ACB52102.NE7K2G39@aa.jp.fujitsu.com> <200704251734.DCC26529.97GEN23K@aa.jp.fujitsu.com> <462F95C1.5020707@redhat.com> <200704261356.FJE18291.K793ENG2@aa.jp.fujitsu.com> Message-ID: <200705070911.AIH17617.K23N9EG7@aa.jp.fujitsu.com> Hi Would you give me a comment on this? Thanks, Masayuki Sunou In message <200704261356.FJE18291.K793ENG2 at aa.jp.fujitsu.com> "Re: [et-mgmt-tools] [PATCH][RESEND] Send [Ctrl+Alt+Del] and [F8]" "Masayuki Sunou " wrote: "Hugh Brock " wrote: > Thanks for this, but I guess I still don't understand what the reasoning > for it is. > > In both RHEL 5 and Fedora 6, it is possible to pass Ctrl+Alt+Del to a > guest simply by pressing Ctrl Ctrl Ctrl Alt+Del, if the console has > keyboard grab in effect. Both the Ctrl and Alt keys can be made sticky > by pressing them three times. So there's really no need for a special > Ctrl+Alt+Del button. > > To send f8, it's not even necessary to use a sticky key; you just click > the console window and press f8. > > If this isn't working for you, it's a bug and we need to fix it. Please > let me know if it is! > Hi First, I think the next composition. Client Machine +--------------+ | +--------+ | | | VNC | | | | Viewer | | | +--------+ | +-------|------+ | Management Machine | +------------------|------------------+ | +--------+ | | | VNC | | | | Server | | | +--------+ | | | | | +--------------+ | | | virt-manager | | | +--------------+ | | | | | +----------+----------+ | | | | | | | +-------+ +-------+ +-------+ | | |Virtual| |Virtual| |Virtual| | | |machine| |machine| |machine| | | +-------+ +-------+ +-------+ | | | +-------------------------------------+ In this composition, when VNC Viewer of Client Machine can not send Ctrl+Alt+Del the user cannot send Ctrl+Atl+Del to Virtual Machine. However, when Virt-manager has the button which sends Ctrl+Alt+Del, the user can send Ctrl+Alt+Del to Virtual Machine. (Even if the user used any kind of VNC Viewer) Therefore, I think that virt-manager has better have the button which sends Ctrl+Alt+Del. Thanks, Masayuki Sunou. _______________________________________________ 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 May 7 12:02:04 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 07 May 2007 08:02:04 -0400 Subject: [et-mgmt-tools] Re: et-mgmt-tools Digest, Vol 9, Issue 6 In-Reply-To: <87C9906AAD26A24E8E0C2A31287031BE01053FE1@FREXGENEVA-01.frfr.foxriver.com> References: <87C9906AAD26A24E8E0C2A31287031BE01053FE1@FREXGENEVA-01.frfr.foxriver.com> Message-ID: <463F153C.2060802@redhat.com> Marc Mondragon wrote: > Thanks, > > I sort of knew this but wasn't sure completely sure when one can add the > kopts/kmeta options (profile/system/??). Any time. Should you hack the files in /var/lib/cobbler manually (not recommended now that "edit" exists) versus using the edit commands, you'd have to run "cobbler sync" to make updates. As it standards, "cobbler sync" still needs to be run after editing the kickstart files or changing /var/lib/cobbler/settings, but otherwise the needs for running that command have been greatly reduced. > The addition of the edit > command is a nice touch btw. > > Thanks! > Marc Mondragon > > Fox River Financial Resources/Ritchie Capital Investments, Ltd. > 2100 Enterprise Avenue > Geneva, IL 60134 > marcmo at foxriver.com > > > >> Message: 1 >> Date: Wed, 02 May 2007 12:11:10 -0400 >> From: Michael DeHaan >> Subject: Re: [et-mgmt-tools] kernel_options in >> /var/lib/cobbler/settings >> To: Fedora/Linux Management Tools >> Message-ID: <4638B81E.4090603 at redhat.com> >> Content-Type: text/plain; charset=iso-8859-1; format=flowed >> >> Marc Mondragon wrote: >> >>> I know this area of cobbler has changed a bit and I'm trying to >>> > figure > >> the best way to do the following: >> >>> 1. Add serial console settings to this file in order to have them >>> >> appended properly to the tftp boot files. >> >>> 2. Have the serial console setting only apply to server >>> > installations, > >> not workstation installations? >> >> (1) To do this across the board, you just edit >> /var/lib/cobbler/settings ... though it sounds like you have something >> better in mind by (2). >> >> (2) To do this to just some machines, it looks something like >> > this... > >> When adding a cobbler profile, do something like this: >> >> cobbler profile add --name=serverprofilename >> > --distro=distroname > >> --kopts="console=ttyS0,57600" >> >> And for the workstation profile, don't add the same "--kopts"... >> >> cobbler profile add --name=workstationprofilename >> --distro=distroname >> >> If you already have profiles you like defined, cobbler allows for >> editing now, so you can tweak an existing profile to add the serial >> console magic... >> >> cobbler profile edit --name=serverprofilename >> --kopts="console=ttyS0,57600" >> >> So, any time you provision based on the "serverprofilename" profile, >> you'll get the serial console, and in other cases, you won't... >> >> Hope that helps... >> >> --Michael >> >> >>> 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 >>> >>> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 2 May 2007 12:12:42 -0400 >> From: "Adam Rosenwald" >> Subject: Re: [et-mgmt-tools] kernel_options in >> /var/lib/cobbler/settings >> To: "Fedora/Linux Management Tools" >> Message-ID: >> <658267190705020912n55d6a174p5ced5dbc4869e398 at mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Marc, >> >> You can have separate "workstation" and "server" profiles and, for >> > each, > >> you can specify different --kopts settings. For instance, to enable >> serial >> console redirection on server profile: >> >> cobbler profile add --name=servers ... --kopts=" >> console=ttyS0,9600n8" ... >> >> --A. >> >> On 5/2/07, Marc Mondragon wrote: >> >>> I know this area of cobbler has changed a bit and I'm trying to >>> > figure > >> the >> >>> best way to do the following: >>> >>> 1. Add serial console settings to this file in order to have them >>> >> appended >> >>> properly to the tftp boot files. >>> 2. Have the serial console setting only apply to server >>> > installations, > >> not >> >>> workstation installations? >>> >>> Marc Mondragon >>> >>> Fox River Financial Resources/Ritchie Capital Investments, Ltd. >>> 2100 Enterprise Avenue >>> Geneva, IL 60134 >>> marcmo at foxriver.com >>> >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> >>> From bryan at ayesha.phys.virginia.edu Mon May 7 12:51:33 2007 From: bryan at ayesha.phys.virginia.edu (Bryan K. Wright) Date: Mon, 07 May 2007 08:51:33 -0400 Subject: [et-mgmt-tools] Re: Two cobbler feature suggestions (fwd) Message-ID: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> Hi folks, Here's a note I sent recently to Michael DeHaan, and his response. He suggested I forward it to the list. As he suggests, I'll take a look at Cobbler's trigger infrastructure and see what would be required to get Cobbler to play with dnsmasq. Bryan Wright ------- Forwarded Message Date: Mon, 07 May 2007 08:15:51 -0400 From: Michael DeHaan User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: bryan at Virginia.EDU Bryan K. Wright wrote: Bryan, > Hi Michael, > > Thanks for writing cobbler! I've been using it for a little > while now, and I'm loving it. > Glad you like it and thanks for the suggestions. Quick question -- Can this email be sent to et-mgmt-tools at redhat.com? Other folks might benefit from this discussion... > For what it's worth, here are a couple of feature suggestions > for future versions: > > 1. It would be nice to have a flag like "--pxe-name" when adding > systems. I'd like to be able to assign names to the hosts in > the dhcpd.conf, instead of the default "label1", "label2", etc. > > Agreed. I was having this discussion yesterday on IRC (#cobbler / irc.freenode.net) > 2. This would be a lot of work, but have you thought about supporting > dnsmasq as an alternative to the ISC dhcpd? Dnsmasq is nice since > it can draw its dhcpd information directly from /etc/hosts and > /etc/ethers, and it has a cacheing DNS built in. Right now, > I'm using cobbler for provisioning via dhcp/pxe, and maintaining > /etc/hosts by hand and running dnsmasq to serve up hostname resolution > from it (with dnsmasq's dhcp service turned off). It'd be great > to get rid of the duplication. > It's doable, although I am not super-familiar with dnsmasq. A couple of options: (1) You turn off manage_dhcp in /var/lib/cobbler/settings, and use the trigger script infrastructure (think "plugins", they're mentioned in the manpage) and write a quick extension using the cobbler API to update dnsmasq when new cobbler systems are added/removed. Trigger scripts are just executable scripts in /var/lib/cobbler/triggers that get called with the name of the object being added. If written in Python, using the cobbler API to mine the rest of the system info (such as the value for a --pxe-name parameter) is fairly easy. (2) You can submit a patch to cobbler's api_sync mode, to accept both modes of dealing with dhcp. I would probably have to tweak it just a little bit, but that would be a great start. Ideally the choice of servers would be in /var/lib/cobbler/settings, to switch between approaches. (3) You can send me an example script of how you are configuring dnsmasq today, and I can possibly incorporate something similar into cobbler. Some other folks are exploring dynamic DNS integration and possible tie-ins with omshell/OMAPI but I think this could be more interesting. I would like to do some exploration myself and see where this goes. Generally this looks like it would be best implemented as a trigger, and someone could choose whether or not to install it -- possibly something that could be shipped in a "contrib" directory. If you'd like to forward this to et-mgmt-tools at redhat.com that would be great -- I'm sure other users have input on this as well. Thanks, Michael > Bryan > > ------- End of Forwarded Message -- ======================================================================== Bryan Wright |"If you take cranberries and stew them like Physics Department | applesauce, they taste much more like prunes University of Virginia | than rhubarb does." -- Groucho Charlottesville, VA 22901| (434) 924-7218 | bryan at virginia.edu ======================================================================== From mdehaan at redhat.com Mon May 7 13:09:27 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 07 May 2007 09:09:27 -0400 Subject: [et-mgmt-tools] Re: Two cobbler feature suggestions (fwd) In-Reply-To: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> References: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> Message-ID: <463F2507.5070205@redhat.com> Bryan K. Wright wrote: > Hi folks, > > Here's a note I sent recently to Michael DeHaan, and his response. > He suggested I forward it to the list. As he suggests, I'll take a look > at Cobbler's trigger infrastructure and see what would be required > to get Cobbler to play with dnsmasq. > Great! Triggers are covered in this email: https://www.redhat.com/archives/et-mgmt-tools/2007-April/msg00069.html Basically you'll want to look around at "api.py" in the source checkout to see what methods are available, call cobbler_api.distros().find(name) on the first argument to the script, and retrieve the cobbler object for the system. From there, you can see what you want to manipulate for dnsmasq. Once you have a cobbler object, you can access all of the information in "item_system.py", which includes things like the --pxe-address values, what the name of it's profile is, and so forth. All of the above assumes something would be done in Python.... this doesn't have to be the case. If you want to write something in another language, that script will still be called with the system object name as the first argument. Other information about that system can then be gathered from /var/lib/cobbler/systems by parsing the YAML file ... Perl's YAML.pm, I believe Ruby has a yaml.rb, etc. Of course, using the cobbler API would be better/easier -- and would avoid the need to use a YAML module. Now there currently isn't a value for --pxe-hostname in the systems source code (item_system.py) to allow setting that parameter, but it can be added in the same way that pxe-address is already in the code. (A minor tweak will also need to be made to cobbler.py to allow that parameter to be used on the command line) I'd be glad to help out with this, though I'll be away giving a presentation at Red Hat Summit for the rest of this week. > Bryan Wright > ------- Forwarded Message > > Date: Mon, 07 May 2007 08:15:51 -0400 > From: Michael DeHaan > User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) > MIME-Version: 1.0 > To: bryan at Virginia.EDU > > Bryan K. Wright wrote: > > Bryan, > > > >> Hi Michael, >> >> Thanks for writing cobbler! I've been using it for a little >> while now, and I'm loving it. >> >> > > Glad you like it and thanks for the suggestions. Quick question -- Can > this email be sent to et-mgmt-tools at redhat.com? Other folks might > benefit from this discussion... > > >> For what it's worth, here are a couple of feature suggestions >> for future versions: >> >> 1. It would be nice to have a flag like "--pxe-name" when adding >> systems. I'd like to be able to assign names to the hosts in >> the dhcpd.conf, instead of the default "label1", "label2", etc. >> >> >> > Agreed. I was having this discussion yesterday on IRC (#cobbler / > irc.freenode.net) > >> 2. This would be a lot of work, but have you thought about supporting >> dnsmasq as an alternative to the ISC dhcpd? Dnsmasq is nice since >> it can draw its dhcpd information directly from /etc/hosts and >> /etc/ethers, and it has a cacheing DNS built in. Right now, >> I'm using cobbler for provisioning via dhcp/pxe, and maintaining >> /etc/hosts by hand and running dnsmasq to serve up hostname resolution >> from it (with dnsmasq's dhcp service turned off). It'd be great >> to get rid of the duplication. >> >> > > It's doable, although I am not super-familiar with dnsmasq. A couple > of options: > > (1) You turn off manage_dhcp in /var/lib/cobbler/settings, and use the > trigger script infrastructure (think "plugins", they're mentioned in > the manpage) and write a quick extension using the cobbler API to > update dnsmasq when new cobbler systems are added/removed. Trigger > scripts are just executable scripts in /var/lib/cobbler/triggers that > get called with the name of the object being added. If written in > Python, using the cobbler API to mine the rest of the system info (such > as the value for a --pxe-name parameter) is fairly easy. > > (2) You can submit a patch to cobbler's api_sync mode, to accept both > modes of dealing with dhcp. I would probably have to tweak it just a > little bit, but that would be a great start. Ideally the choice of > servers would be in /var/lib/cobbler/settings, to switch between approaches. > > (3) You can send me an example script of how you are configuring > dnsmasq today, and I can possibly incorporate something similar into > cobbler. > > Some other folks are exploring dynamic DNS integration and possible > tie-ins with omshell/OMAPI but I think this could be more interesting. > I would like to do some exploration myself and see where this goes. > Generally this looks like it would be best > implemented as a trigger, and someone could choose whether or not to > install it -- possibly something that could be shipped in a "contrib" > directory. > > If you'd like to forward this to et-mgmt-tools at redhat.com that would be > great -- I'm sure other users have input on this as well. > > Thanks, > > Michael > >> Bryan >> >> >> > > > ------- End of Forwarded Message > > > From timhughes at goldfish.me.uk Mon May 7 18:21:33 2007 From: timhughes at goldfish.me.uk (Tim Hughes) Date: Mon, 7 May 2007 19:21:33 +0100 Subject: [et-mgmt-tools] cobbler cheetah kickstart cfg - cant work out control structures (if statements and the like) Message-ID: <977a11430705071121l32fd3880t875a05b71d3a0d07@mail.gmail.com> Is it possable to put cheetah 'if' statements and loops into the /etc/cobbler/kickstart.cfg files and if so can someone send me an example. I am just feeling that i am running into a brickwall I have tried something like this if $ipaddress network --device eth0 --bootproto static --ip $ipaddress --netmask $netmask --gateway $gateway --nameserver $nameservers --hostname $hostname else network --bootproto=dhcp --device=eth0 --onboot=on end if but it doesnt work and i dont know where i am going wrong. The cheetah docs all appear to have #s before the 'if, else, end if' but i dont know how that would work as kickstart uses # as a comment opperator. -- Tim Hughes mailto:timhughes at goldfish.me.uk From mdehaan at redhat.com Mon May 7 19:33:17 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 07 May 2007 15:33:17 -0400 Subject: [et-mgmt-tools] cobbler cheetah kickstart cfg - cant work out control structures (if statements and the like) In-Reply-To: <977a11430705071121l32fd3880t875a05b71d3a0d07@mail.gmail.com> References: <977a11430705071121l32fd3880t875a05b71d3a0d07@mail.gmail.com> Message-ID: <463F7EFD.3090000@redhat.com> Tim Hughes wrote: > Is it possable to put cheetah 'if' statements and loops into the > /etc/cobbler/kickstart.cfg files and if so can someone send me an > example. I am just feeling that i am running into a brickwall > > I have tried something like this > > if $ipaddress > network --device eth0 --bootproto static --ip $ipaddress > --netmask $netmask --gateway $gateway --nameserver $nameservers > --hostname $hostname > else > network --bootproto=dhcp --device=eth0 --onboot=on > end if > > but it doesnt work and i dont know where i am going wrong. The cheetah > docs all appear to have #s before the 'if, else, end if' but i dont > know how that would work as kickstart uses # as a comment opperator. > Cheetah processes the # statements prior to them being used by kickstart, and they will disappear before being fed to kickstart. You do definitely need the "#"... --Michael From berrange at redhat.com Tue May 8 00:40:53 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 May 2007 01:40:53 +0100 Subject: [et-mgmt-tools] [PATCH] fix VNC connection errors in virt-manager In-Reply-To: <46389F13.D169.003C.0@novell.com> References: <46389F13.D169.003C.0@novell.com> Message-ID: <20070508004053.GB11353@redhat.com> On Wed, May 02, 2007 at 02:28:34PM -0600, Charles Coffing wrote: > There is a nasty typo in virt manager, which is masked by a catch-all > "except:" clause. This error could cause unnecessary VNC connection > failures. Hmm, surprised I've never noticed that error before. > The bad line is actually completely useless, since disconnect_from_host > correctly sets self.client=None. The preceeding "if" is also useless, > since disconnect_from_host handles the case where self.client is None. > The attached patch deletes all this unnecessary junk. Thanks, will apply shortly if Hugh's not already done so. 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 May 8 00:47:31 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 May 2007 01:47:31 +0100 Subject: [et-mgmt-tools] [PATCH][RESEND] Send [Ctrl+Alt+Del] and [F8] In-Reply-To: <200705070911.AIH17617.K23N9EG7@aa.jp.fujitsu.com> References: <200704191813.ACB52102.NE7K2G39@aa.jp.fujitsu.com> <200704251734.DCC26529.97GEN23K@aa.jp.fujitsu.com> <462F95C1.5020707@redhat.com> <200704261356.FJE18291.K793ENG2@aa.jp.fujitsu.com> <200705070911.AIH17617.K23N9EG7@aa.jp.fujitsu.com> Message-ID: <20070508004731.GC11353@redhat.com> On Mon, May 07, 2007 at 09:11:19AM +0900, Masayuki Sunou wrote: > > In message <200704261356.FJE18291.K793ENG2 at aa.jp.fujitsu.com> > "Re: [et-mgmt-tools] [PATCH][RESEND] Send [Ctrl+Alt+Del] and [F8]" > "Masayuki Sunou " wrote: > > "Hugh Brock " wrote: > > > Thanks for this, but I guess I still don't understand what the reasoning > > for it is. > > > > In both RHEL 5 and Fedora 6, it is possible to pass Ctrl+Alt+Del to a > > guest simply by pressing Ctrl Ctrl Ctrl Alt+Del, if the console has > > keyboard grab in effect. Both the Ctrl and Alt keys can be made sticky > > by pressing them three times. So there's really no need for a special > > Ctrl+Alt+Del button. > > > > To send f8, it's not even necessary to use a sticky key; you just click > > the console window and press f8. > > > > If this isn't working for you, it's a bug and we need to fix it. Please > > let me know if it is! > > > Hi > > First, I think the next composition. > > Client Machine > +--------------+ > | +--------+ | > | | VNC | | > | | Viewer | | > | +--------+ | > +-------|------+ > | > Management Machine | > +------------------|------------------+ > | +--------+ | > | | VNC | | > | | Server | | > | +--------+ | > | | | > | +--------------+ | > | | virt-manager | | > | +--------------+ | > | | | > | +----------+----------+ | > | | | | | > | +-------+ +-------+ +-------+ | > | |Virtual| |Virtual| |Virtual| | > | |machine| |machine| |machine| | > | +-------+ +-------+ +-------+ | > | | > +-------------------------------------+ > > In this composition, when VNC Viewer of Client Machine can not send > Ctrl+Alt+Del the user cannot send Ctrl+Atl+Del to Virtual Machine. I've just tested this configuration and using the 'sticky' keys I was able to pass Ctrl-Alt-Del to the guest simply by entering 'Ctrl Ctrl Ctrl Alt+Del' in the console window. I tested this both running virt-manager on my local machine, and remotely over VNC as you illustrate in the diagram above. I can't remember if I've mentioned it on the list before, but I've also got prototype code which will remove the need for sticky keys by changing the key local keyboard grab works. This will let us intercept even squences like Ctrl+Alt+Del and Ctrl+Alt+F1 > However, when Virt-manager has the button which sends Ctrl+Alt+Del, > the user can send Ctrl+Alt+Del to Virtual Machine. (Even if the user > used any kind of VNC Viewer) > > Therefore, I think that virt-manager has better have the button which > sends Ctrl+Alt+Del. Having buttons for certain special key sequences isn't a scale UI paradigm because every client has a different set of 'special' key sequences it cares about. The only viable solution really is to make sure that the local keyboard grab is working correctly. Currently we are able to grab the key board in such a way that makes sure we get every key sequence except for those beginning Ctrl+Alt. I can't remember if I've mentioned it on the list before, but I've also got prototype code which will remove the need for sticky keys by changing the key local keyboard grab works. This will let us intercept even squences like Ctrl+Alt+Del and Ctrl+Alt+F1. The addition of remote management capabilities in virt-manager will also remove the need to run virt-manager via VNC. 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 msinhore at gmail.com Tue May 8 14:03:28 2007 From: msinhore at gmail.com (Marco Sinhoreli) Date: Tue, 8 May 2007 11:03:28 -0300 Subject: [et-mgmt-tools] Problem to start a virtual machine Message-ID: <20fe3cf60705080703g627ffad3ofbc1fd349ade54e0@mail.gmail.com> When I try start a virtual machine via virt-manager graphical interface return it bellow: libvir: error : configuration file syntax error: expecting a name libvir: XML error : XML description not well formed or invalid Traceback (most recent call last): File "/usr/local/share/virt-manager/virtManager/manager.py", line 693, in start_vm vm.startup() File "/usr/local/share/virt-manager/virtManager/domain.py", line 361, in startup self.vm.create() File "/usr/local/lib/python2.4/site-packages/libvirt.py", line 194, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirt.libvirtError: virDomainCreate() failed XML description not well formed or invalid I'm using a xen 3.0.3 in Debian etch kernel 2.6.18 patched from Debian. regards -- Marco Sinhoreli -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcmo at foxriver.com Tue May 8 20:26:16 2007 From: marcmo at foxriver.com (Marc Mondragon) Date: Tue, 8 May 2007 15:26:16 -0500 Subject: [et-mgmt-tools] IPAPPEND Message-ID: <87C9906AAD26A24E8E0C2A31287031BE01053FFE@FREXGENEVA-01.frfr.foxriver.com> I know this was discussed on the mailing list but was there ever any resolution on how this would be handled? I saw that Michael offered a patch that would always add this but it appears it wasn't applied. Marc Mondragon Fox River Financial Resources/Ritchie Capital Investments, Ltd. 2100 Enterprise Avenue Geneva, IL 60134 marcmo at foxriver.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed May 9 00:29:55 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 08 May 2007 20:29:55 -0400 Subject: [et-mgmt-tools] IPAPPEND In-Reply-To: <87C9906AAD26A24E8E0C2A31287031BE01053FFE@FREXGENEVA-01.frfr.foxriver.com> References: <87C9906AAD26A24E8E0C2A31287031BE01053FFE@FREXGENEVA-01.frfr.foxriver.com> Message-ID: <46411603.7070608@redhat.com> Marc Mondragon wrote: > > I know this was discussed on the mailing list but was there ever any > resolution on how this would be handled? I saw that Michael offered a > patch that would always add this but it appears it wasn?t applied. > > 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 Right, I ended up not adding that because it probably doesn't make sense in all cases. We came up with a better solution -- making the PXE configuration files themselves templates (like cobbler already did with kickstarts). If you want to add this, just edit /etc/cobbler/pxesystem.template and /etc/cobbler/pxeprofile.template and add the IPAPPEND 2 (or whichever) at the right point in the file. Then run "cobbler sync" to make changes to update your configuration. You can also add anything else you might need to those files. It's all pretty much fair game. --Michael From rjones at redhat.com Wed May 9 10:07:34 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 09 May 2007 11:07:34 +0100 Subject: [et-mgmt-tools] [PATCH] python-virtinst: "Invalid install location" Message-ID: <46419D66.3020700@redhat.com> The opaque error in $SUBJECT is what you get if your networking is down or if you specified the wrong installation source path. The attached patch (*untested* - but it's very simple) changes the message. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: DistroManager.py.patch Type: text/x-patch Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Wed May 9 16:19:00 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 09 May 2007 17:19:00 +0100 Subject: [et-mgmt-tools] [PATCH] python-virtinst: "Invalid install location" In-Reply-To: <46419D66.3020700@redhat.com> References: <46419D66.3020700@redhat.com> Message-ID: <4641F474.5040908@redhat.com> Richard W.M. Jones wrote: > + raise RuntimeError, "Failed downloading kernel from %s. Check installation source and network available." % baseuri s/kernel/boot disk/ ... Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- 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 hbrock at redhat.com Wed May 9 20:26:40 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 09 May 2007 16:26:40 -0400 Subject: [et-mgmt-tools] [PATCH] python-virtinst: "Invalid install location" In-Reply-To: <4641F474.5040908@redhat.com> References: <46419D66.3020700@redhat.com> <4641F474.5040908@redhat.com> Message-ID: <46422E80.8040907@redhat.com> Richard W.M. Jones wrote: > Richard W.M. Jones wrote: >> + raise RuntimeError, "Failed downloading kernel from %s. >> Check installation source and network available." % baseuri > > s/kernel/boot disk/ ... > > Rich. > Committed -- thanks Rich. --H -- 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 May 10 11:00:38 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Thu, 10 May 2007 20:00:38 +0900 Subject: [et-mgmt-tools] [PATCH][RFC][virtinst] Adding Cloning Feature (changing from libvirtML) Message-ID: <01a401c792f2$71808ee0$a1ec830a@dirac> Hi, I've been planing to adding cloning feature. First, I tried to make the patch for libirt/virsh. As a result of having disscussed in libirtML, it followed that it is better to implement it in a higher module by suggestion of Daniel Veillard and Dan Berrange with the following reasons. https://www.redhat.com/archives/libvir-list/2007-April/msg00151.html I also agree. So I made patches again based on the opinion of two. There are two new files. 1)CloneManager.py (The same directory as DistroManager.py in virtinst) This module is Cloning a virtual machine. This has One class named "CloneDesign". The CloneDesign class is the design paper for cloning VM. ?clone_name ?clone_devices ?clone_mac ?guest_xml etc... CloneManager takes the CloneDesign Object and edits the XML acquired form source VM according to the object. The outline processing that CloneDesign does is the following. a)Check existing source VM used lookupByName() when source VM name is setted. b)Get the XML of source VM used XMLDesc() when source VM name is setted. c)Get source devices size used Python API(getsize or "fdisk -s") for displaying cloning progress when source VM name is setted. d)Check Shutoff status used dom.info()[0] when source VM name is setted. e)Check NOT existing VM used lookupByName() when clone VM name is setted The outline processing that CloneManager does is the following. a)Edit source VM XML according to taked CloneDesign object b)Copying devices used Python API(Now read() and write()) c)Define the XML used conn.defineXML() 2)virt-clone This is user I/F script file handling CloneManager module in virtinst. I also think it is simpler to have a separate tool for this purpose. This revision is not able to supported for diffrerent "disk type". (e.g. From "file" to "block" or From "block" to "file".) Now, I investigate sparse files copying. Attached patches shows outline below. --------------------------------------------------------- # ./virt-clone --help Usage: virt-clone [options] Options: -h, --help show this help message and exit -n NAME, --name=NAME Name of the source guest instance; The status must be shutoff -w CLONE_NAME, --new=CLONE_NAME Name of the clone guest instance; if none, adding fixed string _CLONE to source guest name -m CLONE_MAC, --mac=CLONE_MAC Fixed MAC address for the clone guest; if none or RANDOM is given a random address will be used -f CLONE_DISKFILE, --file=CLONE_DISKFILE File to use as the disk image for the clone guest instance # ./virt-clone -f /dev/sda13 -n PV_RH5 -w PV_RH5_CLONE Cloning from /dev/sda5 to /dev/sda13 Cloning domain... 19% |==== | 988 MB 05:11 ETA Has Many block devices # ./virt-clone -f /dev/sda12 -n PV_RH5_2 ERROR: Missing destination device for /dev/sda5 # ./virt-clone -f /dev/sda12 -f /dev/sda13 -n PV_RH5_2 Cloning from /dev/sda10 to /dev/sda12 Cloning domain... 100% |=========================| 5.0 GB 06:06 Cloning from /dev/sda5 to /dev/sda13 Cloning domain... 98% |======================== | 4.9 GB 00:07 ETA Turn interactive mode when "name" option is not setted # ./virt-clone -f /dev/sda12 -f /dev/sda13 What is the name of the source virtual machine? PV_RH ERROR: Domain PV_RH is not found What is the name of the source virtual machine? Report an Error ?Domain already exists # ./virt-clone -f /dev/sda13 -n PV_RH5_2 -w PV_RH5_2 ERROR: Domain PV_RH5_2 already exists ?Except Shutoff status # ./virt-clone -f /dev/sda13 -n Domain-0 ERROR: Domain status must be shutoff ?Missing destination devices # ./virt-clone -f /dev/sda12 -n PV_RH5_2 ERROR: Missing destination device for /dev/sda5 ?etc ... -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone.patch Type: application/octet-stream Size: 4176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.py.patch Type: application/octet-stream Size: 8554 bytes Desc: not available URL: From berrange at redhat.com Thu May 10 14:31:46 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2007 15:31:46 +0100 Subject: [et-mgmt-tools] [PATCH][RFC][virtinst] Adding Cloning Feature (changing from libvirtML) In-Reply-To: <01a401c792f2$71808ee0$a1ec830a@dirac> References: <01a401c792f2$71808ee0$a1ec830a@dirac> Message-ID: <20070510143146.GD31761@redhat.com> On Thu, May 10, 2007 at 08:00:38PM +0900, Kazuki Mizushima wrote: > Hi, > > I've been planing to adding cloning feature. > First, I tried to make the patch for libirt/virsh. > > As a result of having disscussed in libirtML, it followed > that it is better to implement it in a higher module by > suggestion of Daniel Veillard and Dan Berrange with the following reasons. > https://www.redhat.com/archives/libvir-list/2007-April/msg00151.html > > I also agree. So I made patches again based on the opinion of two. > There are two new files. > > 1)CloneManager.py (The same directory as DistroManager.py in virtinst) > This module is Cloning a virtual machine. This has One class named > "CloneDesign". > The CloneDesign class is the design paper for cloning VM. > ?$B!&clone_name > ?$B!&clone_devices > ?$B!&clone_mac > ?$B!&guest_xml etc... > CloneManager takes the CloneDesign Object and edits the XML acquired form > source VM according to the object. > > The outline processing that CloneDesign does is the following. > a)Check existing source VM used lookupByName() when source VM name is > setted. > b)Get the XML of source VM used XMLDesc() when source VM name is setted. > c)Get source devices size used Python API(getsize or "fdisk -s") for > displaying cloning progress when source VM name is setted. > d)Check Shutoff status used dom.info()[0] when source VM name is setted. > e)Check NOT existing VM used lookupByName() when clone VM name is setted > > The outline processing that CloneManager does is the following. > a)Edit source VM XML according to taked CloneDesign object > b)Copying devices used Python API(Now read() and write()) > c)Define the XML used conn.defineXML() That's a good way you've implemented the XML changes using the in memory nodes from libxml. It means that when we add extra info to the XML over time, the clone tool should (mostly) handle it without changes (unless the new info is some unique attribute to the VM). A couple more bits of XML (potentially) need changing: - In the tag, if the 'port' attribute is not already -1, then we need to set it to -1 - otherwise the VNC ports will clash. - In the tag, if there is a element present, we need to remove it completely. The element is very rarely used, but since it refers to the backend device name (ie to change from the default of vifN.M) we need to remove it otherwise backend devices will clash. - In the tag, if there is a 'pty' attribute we need to remove it. - In the tag, if there is a element that needs removing. That is basically all. Most important changes of MAC & UUID are already done. > 2)virt-clone > This is user I/F script file handling CloneManager module in virtinst. > I also think it is simpler to have a separate tool for this purpose. > > This revision is not able to supported for diffrerent "disk type". > (e.g. From "file" to "block" or From "block" to "file".) That's a reasonable limitation to start off with - should be easy enough to fix it later. > Now, I investigate sparse files copying. There's no easy way to detect if a file is sparse - particularly in python. I think the best option is to detect sequences of zeros. eg, if you are reading the source file 4096 bytes at a time, check to see if that 4096 set of bytes are all zeros. If they are, then seek() forward 4096 bytes instead of writing the set of zeros. > > Attached patches shows outline below. > --------------------------------------------------------- > # ./virt-clone --help > Usage: virt-clone [options] > > Options: > -h, --help show this help message and exit > -n NAME, --name=NAME Name of the source guest instance; The status must be > shutoff > -w CLONE_NAME, --new=CLONE_NAME > Name of the clone guest instance; if none, adding > fixed string _CLONE to source guest name I think I'd swap these 2 around. Have --name / -n refer to the name of the new VM to be created. And have a '--source NAME|UUID' arg to specify the original VM, based on its name or uuid. I'd also make --name compulsory rather than appending _CLONE to the original name. > -m CLONE_MAC, --mac=CLONE_MAC > Fixed MAC address for the clone guest; if none or > RANDOM is given a random address will be used > -f CLONE_DISKFILE, --file=CLONE_DISKFILE > File to use as the disk image for the clone guest > instance We should add a few more args here that we've already got with virt-install In particular the --debug flag is very useful for debugging problems -eg it will print out XML of new domain in virt-install. To support QEMU/KVM, we should also have the --connect URI flag, and pass it down into the libvirt.open() call, rather than hardcoding a Xen connection. Finally a --uuid arg too, to let people pre-define the UUID if needed. With the VNC port stripping & the --connect URI arg to let it work with QEMU+ KVM, I'd be happy to see this code included in the repo. 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 May 10 15:34:08 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2007 16:34:08 +0100 Subject: [et-mgmt-tools] [patch 0/8] [virtinst] Add installer concept and livecd installer example In-Reply-To: <20070502120733.362541000@redhat.com> References: <20070502120733.362541000@redhat.com> Message-ID: <20070510153408.GG31761@redhat.com> On Wed, May 02, 2007 at 01:15:28PM +0100, Mark McLoughlin wrote: > Hey, > This set of patches explores the notion of allowing virtinst > to have different installer types apart from the existing support > for distribution installers. > > This notion can be used to e.g. support livecd or pre-built > system images. Hmm, this might be a good way to support PXE based installs too, where we have neither a kernel/initrd or a boot ISO to worry about setting up. Just another Installer sub-class. 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 May 10 15:39:02 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2007 16:39:02 +0100 Subject: [et-mgmt-tools] [patch 1/8] Add Installer and re-factor existing code into DistroInstaller In-Reply-To: <20070502120954.977767000@redhat.com> References: <20070502120733.362541000@redhat.com>> <20070502120954.977767000@redhat.com> Message-ID: <20070510153902.GH31761@redhat.com> On Wed, May 02, 2007 at 01:15:43PM +0100, Mark McLoughlin wrote: > + # kernel + initrd pair to use for installing as opposed to using a location > + def get_boot(self): > + return self._boot > + def set_boot(self, val): > + if type(val) == tuple: > + if len(val) != 2: > + raise ValueError, "Must pass both a kernel and initrd" > + (k, i) = val > + self._boot = {"kernel": k, "initrd": i} > + elif type(val) == dict: > + if not val.has_key("kernel") or not val.has_key("initrd"): > + raise ValueError, "Must pass both a kernel and initrd" > + self._boot = val > + elif type(val) == list: > + if len(val) != 2: > + raise ValueError, "Must pass both a kernel and initrd" > + self._boot = {"kernel": val[0], "initrd": val[1]} > + boot = property(get_boot, set_boot) I realize you're just copying the existing code here which enforced use of both kernel + initrd, but it occurs to me forcing initrd is not a good idea. AFAICK, not every OS needs an initrd, so it might be worthwhile making initrd optional. There's a bunch of other places in the code which'd need cleaning up to deal with this. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Thu May 10 15:42:50 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2007 16:42:50 +0100 Subject: [et-mgmt-tools] [patch 3/8] Move post install check into DistroInstaller In-Reply-To: <20070502120955.144942000@redhat.com> References: <20070502120733.362541000@redhat.com>> <20070502120955.144942000@redhat.com> Message-ID: <20070510154250.GI31761@redhat.com> On Wed, May 02, 2007 at 01:16:11PM +0100, Mark McLoughlin wrote: > The existing heuristic we use in virt-install to detect whether > an install has completed successfully is dependant on the type > of installer being used - i.e. if you create a VM with a livecd > or a raw ext3 image, there may be no disk with an MBR at the end. > > This patch moves that logic into a new DistroInstaller method. > > Signed-off-by: Mark McLoughlin > > Index: virtinst--devel/virtinst/DistroManager.py > =================================================================== > --- virtinst--devel.orig/virtinst/DistroManager.py > +++ virtinst--devel/virtinst/DistroManager.py > @@ -18,6 +18,7 @@ import os > import gzip > import re > import stat > +import struct > import subprocess > import urlgrabber.grabber as grabber > import urlgrabber.progress as progress > @@ -698,3 +699,10 @@ class DistroInstaller(Guest.Installer): > osblob += " /usr/bin/pygrub" > > return osblob > + > + def post_install_check(self, guest): > + # Check for the 0xaa55 signature at the end of the MBR > + fd = os.open(guest.disks[0].path, os.O_RDONLY) > + buf = os.read(fd, 512) > + os.close(fd) > + return len(buf) == 512 and struct.unpack("H", buf[0x1fe: 0x200]) == (0xaa55,) We should really create a convenience method in virtinst/util.py for this stuff. This is definitely broken on ia64 which uses EFI / GPT instead of BIOS/MBR. We could have an def has_boot_record() if has_boot_record_mbr() return True if has_boot_record_gpt() return True return Fale def has_boot_record_mbr() ...existing code from above... def has_boot_record_gpt() ...figure something out :-) ... 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 May 10 15:49:28 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2007 16:49:28 +0100 Subject: [et-mgmt-tools] [patch 7/8] Add CapabilitiesParser module In-Reply-To: <20070502120955.474768000@redhat.com> References: <20070502120733.362541000@redhat.com>> <20070502120955.474768000@redhat.com> Message-ID: <20070510154928.GJ31761@redhat.com> On Wed, May 02, 2007 at 01:16:55PM +0100, Mark McLoughlin wrote: > This adds a simple module for parsing libvirt's getCapabilities() > XML. > > It might seem more straightforward to just use XPath for this, but > in the code to support arbitrary system images, you iterate over > the various ways that the image can be booted and the various ways > in which a hypervisor can boot a guest and find the best match. For > that kind of use, the API below is much easier to use. > > Note, this parser rejects things like architectures it doesn't > know about, which needs to be fixed in order to have forward > compatibility. I really don't like this. If we were using these APIs to construct new XML capabilities info I'd agree on the validation. In this case though we are merely using the APIs to keep an in-memory representation of data we parsed from libvirt. We should be trusting that data, since the prime reason for the capabilities info in the first place to was have a source apps could use & thus not have to hardcode anything in the apps themselves. > +class Host(object): > + ARCHES = [ "i686", "x86_64" ] ia64 & ppc guys will come after you with pitch forks :-) > +class Guest(object): > + OS_TYPES = [ "xen", "hvm" ] > + HYPERVISOR_TYPES = [ "xen", "qemu", "kqemu", "kvm" ] > + ARCHES = [ "i686", "x86_64", "mips", "mipsel", "sparc", "ppc" ] Again, I don't think we should be doing this kind of white listing here. If an application using the 'Guest' object only supports a certain subset, it can whitelist, but this object should jst be a pure representation of everything libvirt gives us in the XML. > + try: > + # > + # FIXME: when we can rely on python-2.5 and its support for > + # try ... except ... finally, remove this inner try Never ! Or to put it another way - how many years before Debian ends up with python 2.5. I think 2.4 needs to be supported pretty much indefinitely > +if __name__ == "__main__": > + import libvirt > + > + for uri in (None, "qemu:///system"): > + cnx = libvirt.open(uri) > + > + caps = parse(cnx.getCapabilities()) > + > + print "host arch: %s" % caps.host.arch > + if caps.host.features: > + print "host features:" > + for feature in features_map: > + if caps.host.features & features_map[feature]: > + print " " + feature > + > + for guest in caps.guests: > + print > + print "guest arch: %s" % guest.arch > + print "guest os type: %s" % guest.os_type > + print "guest hypervisor type: %s" % guest.hypervisor_type > + if guest.features: > + print "guest features:" > + for feature in features_map: > + if guest.features & features_map[feature]: > + print " " + feature > + > + print We have a formal test suite in virtinst for checking correctness. Could we have something added to tests/ to do sanity checking of the parsing routines. 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 May 10 15:54:44 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2007 16:54:44 +0100 Subject: [et-mgmt-tools] [patch 0/8] [virtinst] Add installer concept and livecd installer example In-Reply-To: <20070502120733.362541000@redhat.com> References: <20070502120733.362541000@redhat.com> Message-ID: <20070510155444.GK31761@redhat.com> On Wed, May 02, 2007 at 01:15:28PM +0100, Mark McLoughlin wrote: > Hey, > This set of patches explores the notion of allowing virtinst > to have different installer types apart from the existing support > for distribution installers. > > This notion can be used to e.g. support livecd or pre-built > system images. I've sent a few comments on respective patches, but in general I think this is all good work we should include. Any idea when you'll be doing an installer to deal with pre-built images :-) We've got a good lot of new ways of installing VMs - Distro installer - Live CD - Cloning - PXE booting distro installer - Pre-built system images (will keep debbootstrap fans happy) so it'd be advantageous to see it all come together to validate we've got the right flexibility in this new APIs. That said, from what I see it does look sane already 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 May 10 16:14:09 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2007 17:14:09 +0100 Subject: [et-mgmt-tools] [PATCH] First-cut at livecd support in virt-manager In-Reply-To: <1178108766.14265.5.camel@blaa> References: <1178108766.14265.5.camel@blaa> Message-ID: <20070510161409.GL31761@redhat.com> On Wed, May 02, 2007 at 01:26:06PM +0100, Mark McLoughlin wrote: > Hey, > The attached patch demos how we might add livecd support to > virt-manager using the virtinst patches I just posted. > > The way I did in the patch isn't great, but the basic idea is that in > order to boot a LiveCD you'd go through the create wizard as follows: > > - Intro - as normal > - Name - choose a name for the VM > - Type - choose LiveCD instead of fully-virt or paravirt I'm wondering how this would look when we come to dealing with install pre-built images. In that case the image may want to be either PV or FV depending on how the user created it. So adding an option here would not work too well. Perhaps we should be asking for the type of install upfront, distro vs lived, vs pre-built image. I've also been toying around with idea that instead of asking PV vs FV, we should just ask for the install location, and then probe that location to figure out whether it has PV or FV capabilities. eg If given a URL http://foo.example/dist/ - Probe for images/vmlinux -> Can do FV with QEMU - Probe for images/boot.iso -> Can do FV with QEMU or Xen - Probe for images/xen/vmlinux -> Can do PV with Xen We could choose FV or PV for the user, or at least give them the options of what installs are available, based on the media this pointed to & the host capabilities. This would suggest a sequence - Intro - Name - Media - Choice of FV/PV options relevant to their media It would be interesting to explore whether bsaed on Media we can figure out a simpler way to ask the user whether the ISO was a distro installer vs a LiveCD ? > - Location - choose the path of the LiveCD iso or device, choose > OS type or variant I'm not clear why you introduced a 3rd fork for the install media page when the widgets are identical to those on the FV page. It adds rather alot more code for no obvious benefit ? > - Disks - default it to create no disks, but you can choose to create > a disk too > - Network/CPU/Finish - as normal So anyway, interesting prototype - I think we need to play around with various ideas here.. 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 satyaakam at gmail.com Thu May 10 17:44:29 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Thu, 10 May 2007 23:14:29 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors Message-ID: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> installed xen-unstable , and xend is running # xm list Name ID Mem VCPUs State Time(s) Domain-0 0 0 4 r----- 985.9 when i try to run virt-install i get the following error Traceback (most recent call last): File "/usr/bin/virt-install", line 630, in ? main() File "/usr/bin/virt-install", line 489, in main conn = libvirt.open(options.connect) File "/usr/local/lib/python2.4/site-packages/libvirt.py", line 100, in open if ret is None:raise libvirtError('virConnectOpen() failed') libvirt.libvirtError: virConnectOpen() failed cheers Satya From prime.provogue at gmail.com Fri May 11 00:55:03 2007 From: prime.provogue at gmail.com (Source) Date: Fri, 11 May 2007 06:25:03 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> Message-ID: <3293c1d10705101755h43fa4e99mc02635157edc7bce@mail.gmail.com> Hi there, What error you have posted? It doesn't even help guys here to know what kind of problem you have. Post the complete log and error. Don't truncate things. Also look /var/log/xend.log and /var/log/xend-debug.log Thanks On 5/10/07, satyaakam goswami wrote: > > installed xen-unstable , and xend is running > > # xm list > Name ID Mem VCPUs State > Time(s) > Domain-0 0 0 4 r----- > 985.9 > > > when i try to run virt-install i get the following error > > Traceback (most recent call last): > File "/usr/bin/virt-install", line 630, in ? > main() > File "/usr/bin/virt-install", line 489, in main > conn = libvirt.open(options.connect) > File "/usr/local/lib/python2.4/site-packages/libvirt.py", line 100, in > open > if ret is None:raise libvirtError('virConnectOpen() failed') > libvirt.libvirtError: virConnectOpen() failed > > cheers > Satya > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Fri May 11 01:01:17 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 11 May 2007 02:01:17 +0100 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> Message-ID: <20070511010117.GA17988@redhat.com> On Thu, May 10, 2007 at 11:14:29PM +0530, satyaakam goswami wrote: > installed xen-unstable , and xend is running > > # xm list > Name ID Mem VCPUs State > Time(s) > Domain-0 0 0 4 r----- 985.9 > > > when i try to run virt-install i get the following error > > Traceback (most recent call last): > File "/usr/bin/virt-install", line 630, in ? > main() > File "/usr/bin/virt-install", line 489, in main > conn = libvirt.open(options.connect) > File "/usr/local/lib/python2.4/site-packages/libvirt.py", line 100, in open > if ret is None:raise libvirtError('virConnectOpen() failed') > libvirt.libvirtError: virConnectOpen() failed What user did you run it as ? Does 'virsh list' work ? What Xen version, kernel version & architecture. Finally what libvirt version 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 satyaakam at gmail.com Fri May 11 07:50:51 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Fri, 11 May 2007 13:20:51 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <3293c1d10705101755h43fa4e99mc02635157edc7bce@mail.gmail.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <3293c1d10705101755h43fa4e99mc02635157edc7bce@mail.gmail.com> Message-ID: <6491e1350705110050h63460536w9f4f353a6dc45521@mail.gmail.com> > Hi there, > > What error you have posted? It doesn't even help guys here to know what kind > of problem you have. Post the complete log and error. Don't truncate things. > Also look /var/log/xend.log and /var/log/xend- debug.log > sorry for being terse , but that's all i could see as errors on screen xend-debug.log has the following entries Xend started at Wed May 9 13:57:23 2007. Nothing to flush. Nothing to flush. Xend started at Wed May 9 14:56:58 2007. Nothing to flush. Nothing to flush. Xend started at Thu May 10 17:04:40 2007. attached is the xend.log , more environment details in next reply satya -------------- next part -------------- A non-text attachment was scrubbed... Name: xend.log Type: application/octet-stream Size: 78524 bytes Desc: not available URL: From satyaakam at gmail.com Fri May 11 07:53:19 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Fri, 11 May 2007 13:23:19 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <20070511010117.GA17988@redhat.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <20070511010117.GA17988@redhat.com> Message-ID: <6491e1350705110053w74f39a36g25c7309fbf1109ba@mail.gmail.com> On 5/11/07, Daniel P. Berrange wrote: > On Thu, May 10, 2007 at 11:14:29PM +0530, satyaakam goswami wrote: > > installed xen-unstable , and xend is running > > > > # xm list > > Name ID Mem VCPUs State > > Time(s) > > Domain-0 0 0 4 r----- 985.9 > > > > > > when i try to run virt-install i get the following error > > > > Traceback (most recent call last): > > File "/usr/bin/virt-install", line 630, in ? > > main() > > File "/usr/bin/virt-install", line 489, in main > > conn = libvirt.open(options.connect) > > File "/usr/local/lib/python2.4/site-packages/libvirt.py", line 100, in open > > if ret is None:raise libvirtError('virConnectOpen() failed') > > libvirt.libvirtError: virConnectOpen() failed > > > What user did you run it as ? Does 'virsh list' work ? What Xen version, > kernel version & architecture. Finally what libvirt version i ran it as root user, i cheked out xen-unstable tree and built , i am trying it on RHEL 5.0 , AMD x86_64, SUN x2200 . virsh list gives the following errors #virsh list virsh: error: failed to connect to the hypervisor satya From satyaakam at gmail.com Fri May 11 07:59:23 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Fri, 11 May 2007 13:29:23 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <20070511010117.GA17988@redhat.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <20070511010117.GA17988@redhat.com> Message-ID: <6491e1350705110059o6f3f5dcay7c7f0d8839fde387@mail.gmail.com> On 5/11/07, Daniel P. Berrange wrote: > On Thu, May 10, 2007 at 11:14:29PM +0530, satyaakam goswami wrote: > > installed xen-unstable , and xend is running > > > > # xm list > > Name ID Mem VCPUs State > > Time(s) > > Domain-0 0 0 4 r----- 985.9 > > > > > > when i try to run virt-install i get the following error > > > > Traceback (most recent call last): > > File "/usr/bin/virt-install", line 630, in ? > > main() > > File "/usr/bin/virt-install", line 489, in main > > conn = libvirt.open(options.connect) > > File "/usr/local/lib/python2.4/site-packages/libvirt.py", line 100, in open > > if ret is None:raise libvirtError('virConnectOpen() failed') > > libvirt.libvirtError: virConnectOpen() failed > > > What user did you run it as ? Does 'virsh list' work ? What Xen version, > kernel version & architecture. Finally what libvirt version libvirt version 0.2.2 #xm dmesg output xm dmesg __ __ _____ ___ _ _ _ \ \/ /___ _ __ |___ / / _ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ |_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |____(_)___/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___| http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0-unstable (root at xxxxyyy.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) Wed May 9 13:08:10 IST 2007 Latest ChangeSet: Sat May 05 13:48:05 2007 +0100 15011:e370c94bd6fd (XEN) Command line: /xen-3.0.gz console=vga (XEN) 0000000000000000 - 000000000009f000 (usable) (XEN) 000000000009fc00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000dfff0000 (usable) (XEN) 00000000dfff0000 - 00000000dfffe000 (ACPI data) (XEN) 00000000dfffe000 - 00000000e0000000 (ACPI NVS) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fee00000 - 00000000fef00000 (reserved) (XEN) 00000000ff780000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000120000000 (usable) (XEN) System RAM: 4095MB (4193852kB) (XEN) Xen heap: 13MB (14144kB) (XEN) Domain heap initialised: DMA width 32 bits (XEN) Processor #0 15:1 APIC version 16 (XEN) Processor #1 15:1 APIC version 16 (XEN) Processor #2 15:1 APIC version 16 (XEN) Processor #3 15:1 APIC version 16 (XEN) IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2613.453 MHz processor. (XEN) HVM: SVM enabled (XEN) CPU0: AMD Dual-Core AMD Opteron(tm) Processor 2218 stepping 02 (XEN) Mapping cpu 0 to node 255 (XEN) Booting processor 1/1 eip 90000 (XEN) Mapping cpu 1 to node 255 (XEN) AMD: Disabling C1 Clock Ramping Node #0 (XEN) AMD: Disabling C1 Clock Ramping Node #1 (XEN) CPU1: AMD Dual-Core AMD Opteron(tm) Processor 2218 stepping 02 (XEN) Booting processor 2/2 eip 90000 (XEN) Mapping cpu 2 to node 255 (XEN) CPU2: AMD Dual-Core AMD Opteron(tm) Processor 2218 stepping 02 (XEN) Booting processor 3/3 eip 90000 (XEN) Mapping cpu 3 to node 255 (XEN) CPU3: AMD Dual-Core AMD Opteron(tm) Processor 2218 stepping 02 (XEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 1.193MHz PIT (XEN) Brought up 4 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> 0xffffffff805a8e6c (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 000000011a000000->000000011c000000 (987869 pages to be allocated) (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff80200000->ffffffff805a8e6c (XEN) Init. ramdisk: ffffffff805a9000->ffffffff80b37400 (XEN) Phys-Mach map: ffffffff80b38000->ffffffff812d16e8 (XEN) Start info: ffffffff812d2000->ffffffff812d249c (XEN) Page tables: ffffffff812d3000->ffffffff812e0000 (XEN) Boot stack: ffffffff812e0000->ffffffff812e1000 (XEN) TOTAL: ffffffff80000000->ffffffff81400000 (XEN) ENTRY ADDRESS: ffffffff80200000 (XEN) Dom0 has maximum 4 VCPUs (XEN) Initrd len 0x58e400, start at 0xffffffff805a9000 (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen). (XEN) mtrr: type mismatch for fd000000,800000 old: write-back new: write-combining Satya From berrange at redhat.com Fri May 11 12:05:56 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 11 May 2007 13:05:56 +0100 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <6491e1350705110053w74f39a36g25c7309fbf1109ba@mail.gmail.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <20070511010117.GA17988@redhat.com> <6491e1350705110053w74f39a36g25c7309fbf1109ba@mail.gmail.com> Message-ID: <20070511120556.GD9058@redhat.com> On Fri, May 11, 2007 at 01:23:19PM +0530, satyaakam goswami wrote: > On 5/11/07, Daniel P. Berrange wrote: > >On Thu, May 10, 2007 at 11:14:29PM +0530, satyaakam goswami wrote: > >> installed xen-unstable , and xend is running > >> > >> # xm list > >> Name ID Mem VCPUs State > >> Time(s) > >> Domain-0 0 0 4 r----- > >985.9 > >> > >> > >> when i try to run virt-install i get the following error > >> > >> Traceback (most recent call last): > >> File "/usr/bin/virt-install", line 630, in ? > >> main() > >> File "/usr/bin/virt-install", line 489, in main > >> conn = libvirt.open(options.connect) > >> File "/usr/local/lib/python2.4/site-packages/libvirt.py", line 100, in > >open > >> if ret is None:raise libvirtError('virConnectOpen() failed') > >> libvirt.libvirtError: virConnectOpen() failed > > > > > >What user did you run it as ? Does 'virsh list' work ? What Xen version, > >kernel version & architecture. Finally what libvirt version > > i ran it as root user, i cheked out xen-unstable tree and built , i am > trying it on RHEL 5.0 , AMD x86_64, SUN x2200 . Hmm, did you remove the kernl-xen & xen RPMs that come with RHEL 5 before installing the custom xen-unstable code ? In general its neccessary to have perfectly matched versions of the hypervisor, kernel & userspace. Also, did you install xen-unstable into regular /usr, or into a different directory prefix ? libvirt assumes it is in /usr when looking for the various control sockets to xend, xenstored, etc > virsh list gives the following errors > #virsh list > virsh: error: failed to connect to the hypervisor strace virsh list would be useful info. I suspect its failing to open one of the Xen daemon sockets. Until virsh list works, virt-install definitely won't. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From satyaakam at gmail.com Fri May 11 18:14:55 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Fri, 11 May 2007 23:44:55 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <20070511175833.GB11727@redhat.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <20070511010117.GA17988@redhat.com> <6491e1350705110053w74f39a36g25c7309fbf1109ba@mail.gmail.com> <20070511120556.GD9058@redhat.com> <6491e1350705111054if99f08bv40b0e3d0911ec6eb@mail.gmail.com> <20070511175833.GB11727@redhat.com> Message-ID: <6491e1350705111114j17f42b3fka80a06a28af9b513@mail.gmail.com> > Shows XenD is not listening for connections: > > connect(4, {sa_family=AF_FILE, path="/var/lib/xend/xend-socket"}, 27) = -1 ENOENT (No such file or directory) > > Make sure /etc/xen/xend-config.sxp has > > (xend-unix-server yes) > > And then restart XenD & it should work i get the following error attached trace file libvir: QEMU error : connect: /usr/local/var/run/libvirt/qemud-sock: No such file or directory virsh: error: failed to connect to the hypervisor Satya -------------- next part -------------- A non-text attachment was scrubbed... Name: trace Type: application/octet-stream Size: 18986 bytes Desc: not available URL: From berrange at redhat.com Fri May 11 18:16:29 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 11 May 2007 19:16:29 +0100 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <6491e1350705111114j17f42b3fka80a06a28af9b513@mail.gmail.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <20070511010117.GA17988@redhat.com> <6491e1350705110053w74f39a36g25c7309fbf1109ba@mail.gmail.com> <20070511120556.GD9058@redhat.com> <6491e1350705111054if99f08bv40b0e3d0911ec6eb@mail.gmail.com> <20070511175833.GB11727@redhat.com> <6491e1350705111114j17f42b3fka80a06a28af9b513@mail.gmail.com> Message-ID: <20070511181629.GD11727@redhat.com> On Fri, May 11, 2007 at 11:44:55PM +0530, satyaakam goswami wrote: > >Shows XenD is not listening for connections: > > > >connect(4, {sa_family=AF_FILE, path="/var/lib/xend/xend-socket"}, 27) = -1 > >ENOENT (No such file or directory) > > > >Make sure /etc/xen/xend-config.sxp has > > > >(xend-unix-server yes) > > > >And then restart XenD & it should work > > i get the following error attached trace file > > libvir: QEMU error : connect: /usr/local/var/run/libvirt/qemud-sock: > No such file or directory > virsh: error: failed to connect to the hypervisor Make sure 'libvirt_qemud --system' is also running. This is needed for virtual networking (ignore the badly named daemon - this is neded for Xen 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 satyaakam at gmail.com Fri May 11 18:25:01 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Fri, 11 May 2007 23:55:01 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <20070511181629.GD11727@redhat.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <20070511010117.GA17988@redhat.com> <6491e1350705110053w74f39a36g25c7309fbf1109ba@mail.gmail.com> <20070511120556.GD9058@redhat.com> <6491e1350705111054if99f08bv40b0e3d0911ec6eb@mail.gmail.com> <20070511175833.GB11727@redhat.com> <6491e1350705111114j17f42b3fka80a06a28af9b513@mail.gmail.com> <20070511181629.GD11727@redhat.com> Message-ID: <6491e1350705111125k611bd0fegd4e0302563747d6@mail.gmail.com> > > i get the following error attached trace file > > > > libvir: QEMU error : connect: /usr/local/var/run/libvirt/qemud-sock: > > No such file or directory > > virsh: error: failed to connect to the hypervisor > > Make sure 'libvirt_qemud --system' is also running. This is needed > for virtual networking (ignore the badly named daemon - this is neded > for Xen too) ok it works now thanks , will try now virt-install Satya From satyaakam at gmail.com Fri May 11 18:30:30 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Sat, 12 May 2007 00:00:30 +0530 Subject: [et-mgmt-tools] virtinst-0.103.0 errors In-Reply-To: <6491e1350705111125k611bd0fegd4e0302563747d6@mail.gmail.com> References: <6491e1350705101044v35e09e1fl4cfd576dfcecdb5f@mail.gmail.com> <20070511010117.GA17988@redhat.com> <6491e1350705110053w74f39a36g25c7309fbf1109ba@mail.gmail.com> <20070511120556.GD9058@redhat.com> <6491e1350705111054if99f08bv40b0e3d0911ec6eb@mail.gmail.com> <20070511175833.GB11727@redhat.com> <6491e1350705111114j17f42b3fka80a06a28af9b513@mail.gmail.com> <20070511181629.GD11727@redhat.com> <6491e1350705111125k611bd0fegd4e0302563747d6@mail.gmail.com> Message-ID: <6491e1350705111130k3af86211n4366e9fc8e37534d@mail.gmail.com> On 5/11/07, satyaakam goswami wrote: > > > i get the following error attached trace file > > > > > > libvir: QEMU error : connect: /usr/local/var/run/libvirt/qemud-sock: > > > No such file or directory > > > virsh: error: failed to connect to the hypervisor > > > > Make sure 'libvirt_qemud --system' is also running. This is needed > > for virtual networking (ignore the badly named daemon - this is neded > > for Xen too) > > ok it works now thanks , will try now virt-install did not understand while using virt-install , What would you like to use for the virtual CD image? i am trying with boot.iso , do i need to get the full iso image satya From fj1826dm at aa.jp.fujitsu.com Mon May 14 07:43:45 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Mon, 14 May 2007 16:43:45 +0900 Subject: [et-mgmt-tools] [PATCH][RESEND] Send [Ctrl+Alt+Del] and [F8] In-Reply-To: <20070508004731.GC11353@redhat.com> References: <200704251734.DCC26529.97GEN23K@aa.jp.fujitsu.com> <462F95C1.5020707@redhat.com> <200704261356.FJE18291.K793ENG2@aa.jp.fujitsu.com> <200705070911.AIH17617.K23N9EG7@aa.jp.fujitsu.com> <20070508004731.GC11353@redhat.com> Message-ID: <200705141643.DGI12959.3NK2E97G@aa.jp.fujitsu.com> Hi When I tried "Ctrl Ctrl Ctrl Alt+Del" in this configuration, I was able to send "Ctrl+Alt+Del" without trouble. Therefore, I decline applying this patch. Thank you for advice. Thanks, Masayuki Sunou In message <20070508004731.GC11353 at redhat.com> "Re: [et-mgmt-tools] [PATCH][RESEND] Send [Ctrl+Alt+Del] and [F8]" ""Daniel P. Berrange" " wrote: > On Mon, May 07, 2007 at 09:11:19AM +0900, Masayuki Sunou wrote: > > > > In message <200704261356.FJE18291.K793ENG2 at aa.jp.fujitsu.com> > > "Re: [et-mgmt-tools] [PATCH][RESEND] Send [Ctrl+Alt+Del] and [F8]" > > "Masayuki Sunou " wrote: > > > > "Hugh Brock " wrote: > > > > > Thanks for this, but I guess I still don't understand what the reasoning > > > for it is. > > > > > > In both RHEL 5 and Fedora 6, it is possible to pass Ctrl+Alt+Del to a > > > guest simply by pressing Ctrl Ctrl Ctrl Alt+Del, if the console has > > > keyboard grab in effect. Both the Ctrl and Alt keys can be made sticky > > > by pressing them three times. So there's really no need for a special > > > Ctrl+Alt+Del button. > > > > > > To send f8, it's not even necessary to use a sticky key; you just click > > > the console window and press f8. > > > > > > If this isn't working for you, it's a bug and we need to fix it. Please > > > let me know if it is! > > > > > Hi > > > > First, I think the next composition. > > > > Client Machine > > +--------------+ > > | +--------+ | > > | | VNC | | > > | | Viewer | | > > | +--------+ | > > +-------|------+ > > | > > Management Machine | > > +------------------|------------------+ > > | +--------+ | > > | | VNC | | > > | | Server | | > > | +--------+ | > > | | | > > | +--------------+ | > > | | virt-manager | | > > | +--------------+ | > > | | | > > | +----------+----------+ | > > | | | | | > > | +-------+ +-------+ +-------+ | > > | |Virtual| |Virtual| |Virtual| | > > | |machine| |machine| |machine| | > > | +-------+ +-------+ +-------+ | > > | | > > +-------------------------------------+ > > > > In this composition, when VNC Viewer of Client Machine can not send > > Ctrl+Alt+Del the user cannot send Ctrl+Atl+Del to Virtual Machine. > > I've just tested this configuration and using the 'sticky' keys > I was able to pass Ctrl-Alt-Del to the guest simply by entering > 'Ctrl Ctrl Ctrl Alt+Del' in the console window. I tested this > both running virt-manager on my local machine, and remotely over > VNC as you illustrate in the diagram above. > > I can't remember if I've mentioned it on the list before, but I've > also got prototype code which will remove the need for sticky keys > by changing the key local keyboard grab works. This will let us > intercept even squences like Ctrl+Alt+Del and Ctrl+Alt+F1 > > > However, when Virt-manager has the button which sends Ctrl+Alt+Del, > > the user can send Ctrl+Alt+Del to Virtual Machine. (Even if the user > > used any kind of VNC Viewer) > > > > Therefore, I think that virt-manager has better have the button which > > sends Ctrl+Alt+Del. > > Having buttons for certain special key sequences isn't a scale UI paradigm > because every client has a different set of 'special' key sequences it > cares about. The only viable solution really is to make sure that the local > keyboard grab is working correctly. Currently we are able to grab the key > board in such a way that makes sure we get every key sequence except for > those beginning Ctrl+Alt. > > I can't remember if I've mentioned it on the list before, but I've > also got prototype code which will remove the need for sticky keys > by changing the key local keyboard grab works. This will let us > intercept even squences like Ctrl+Alt+Del and Ctrl+Alt+F1. > > The addition of remote management capabilities in virt-manager will also > remove the need to run virt-manager via VNC. > > 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 mdehaan at redhat.com Mon May 14 17:01:50 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 May 2007 13:01:50 -0400 Subject: [et-mgmt-tools] Cobbler Summit Slides Message-ID: <464895FE.90709@redhat.com> For those interested, I've uploaded the slides from my "Provisioning With Cobbler" talk to http://cobbler.et.redhat.com/cobbler_summit.odp If you attended Summit and have the presentation DVD, basically these are the same slides, with a couple of extra slides added on cobbler triggers and the Python API. --Michael -------------- next part -------------- An embedded message was scrubbed... From: Brian Stevens Subject: FY07 Final Assessment for Michael DeHaan Date: Mon, 14 May 2007 12:00:39 -0400 Size: 19550 URL: From mizushima.kazuk at jp.fujitsu.com Tue May 15 00:31:12 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Tue, 15 May 2007 09:31:12 +0900 Subject: [et-mgmt-tools] [PATCH][RFC][virtinst] Adding Cloning Feature(changing from libvirtML) Message-ID: <002c01c79688$57128a60$a1ec830a@dirac> > A couple more bits of XML (potentially) need changing: > > - In the tag, if the 'port' attribute is not already -1, then we > need to set it to -1 - otherwise the VNC ports will clash. > - In the tag, if there is a element present, we need > to remove it completely. The element is very rarely used, but > since it refers to the backend device name (ie to change from the default > of vifN.M) we need to remove it otherwise backend devices will clash. > - In the tag, if there is a 'pty' attribute we need to remove it. > - In the tag, if there is a element that needs removing. > > That is basically all. Most important changes of MAC & UUID are already done. Thank you for this information. The patch which I attached does not yet depend on this change. > That's a reasonable limitation to start off with - should be easy enough > to fix it later. O.K. I also think it is easy. > There's no easy way to detect if a file is sparse - particularly in python. > I think the best option is to detect sequences of zeros. eg, if you are > reading the source file 4096 bytes at a time, check to see if that 4096 > set of bytes are all zeros. If they are, then seek() forward 4096 bytes > instead of writing the set of zeros. This proposal is good for me. First of all, I will try by this way next development. Also how about is the below idea ? ? virt-clone has "--nonsparse" args as same as virt-install. A new sparse device file is made by lseek(os.path.getsize(soucefile or sourcedisk)) whenever the destination device that the user specified is not found and the option "-- nosparse" is NOT specified, then destination device is copied. A new normal device file that had all zeros is made by write('\x00') Only when the destination device that the user specified is not found and the option "-- nosparse" is specified, then destination device is copied. > I think I'd swap these 2 around. Have --name / -n refer to the name of the > new VM to be created. And have a '--source NAME|UUID' arg to specify > the original VM, based on its name or uuid. I'd also make --name compulsory > rather than appending _CLONE to the original name. Ohh, it is certainly confusing. I agree and define the below. Original guest -- source guest(domain) Clone guest -- destination guest(domain) So I take the '--original NAME| UUID' args and make '--name' compulsory. > We should add a few more args here that we've already got with virt-install > In particular the --debug flag is very useful for debugging problems -eg > it will print out XML of new domain in virt-install. > > To support QEMU/KVM, we should also have the --connect URI flag, and pass > it down into the libvirt.open() call, rather than hardcoding a Xen connection. > > Finally a --uuid arg too, to let people pre-define the UUID if needed. > > With the VNC port stripping & the --connect URI arg to let it work with > QEMU+ KVM, I'd be happy to see this code included in the repo. Thank you for commets. I made it again referring to virt-install and retested. Attached patches shows help below --------------------------------------------------------------------------- # ./virt-clone --help Usage: virt-clone [options] Options: -h, --help show this help message and exit -o ORIGINAL_GUEST, --original=ORIGINAL_GUEST Name or uuid for the original guest; The status must be shut off -n NEW_NAME, --name=NEW_NAME New name for the clone guest -u NEW_UUID, --uuid=NEW_UUID New UUID for the clone guest; if none is given a random UUID will be generated -m NEW_MAC, --mac=NEW_MAC New fixed MAC address for the clone guest; if none or RANDOM is given a random address will be used -f NEW_DISKFILE, --file=NEW_DISKFILE New file to use as the disk image for the clone guest -c CONNECT, --connect=CONNECT Connect to hypervisor with URI -d, --debug Print debugging information Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone.patch Type: application/octet-stream Size: 6075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.py.patch Type: application/octet-stream Size: 14912 bytes Desc: not available URL: From mizushima.kazuk at jp.fujitsu.com Tue May 15 09:05:28 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Tue, 15 May 2007 18:05:28 +0900 Subject: [et-mgmt-tools] [PATCH][RFC][virtinst] Adding CloningFeature(changing from libvirtML) References: <002c01c79688$57128a60$a1ec830a@dirac> Message-ID: <014701c796d0$2f236040$a1ec830a@dirac> > Thank you for commets. > I made it again referring to virt-install and retested. I missed and am sorry for sending my old revision patch. This attached patch is my current revision. Before patch was failed to read the XML in memory in the case of cloning from "file" to "file". Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.py Type: application/octet-stream Size: 15090 bytes Desc: not available URL: From satyaakam at gmail.com Tue May 15 10:56:17 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Tue, 15 May 2007 16:26:17 +0530 Subject: [et-mgmt-tools] virt-manager errors Message-ID: <6491e1350705150356l51de82f3xf5a25bfd1585c069@mail.gmail.com> Configuration is as follows Hardware Sun X2200 Xen-unstable virt-manager : 0.4.0 I am able to successfully run RHEL 3.0 update 5 as DomU in fully virtualized mode when i try creating a VM using virt-manager in paravirtualized mode i get the following errors Unable to complete install 'exceptions.OSError [Errno 2] No such file or directory: '/var/lib/xen/virtinstmnt.O_oVgK' Traceback (most recent call last): File "/usr/local/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 645, in start_install tmpfiles = self._prepare_install_location(meter) File "/usr/lib/python2.4/site-packages/virtinst/ParaVirtGuest.py", line 65, in _prepare_install_location (kernelfn,initrdfn,args) = DistroManager.acquireKernel(self.location, meter, scratchdir=self.scratchdir, type=self.type) File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 562, in acquireKernel if not fetcher.prepareLocation(progresscb): File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 106, in prepareLocation self.mntdir = tempfile.mkdtemp(prefix="virtinstmnt.", dir=self.scratchdir) File "/usr/lib64/python2.4/tempfile.py", line 328, in mkdtemp _os.mkdir(file, 0700) OSError: [Errno 2] No such file or directory: '/var/lib/xen/virtinstmnt.O_oVgK' i checked for directory /var/lib/xen it is missing i could see /var/lib/xend though regards Satya From berrange at redhat.com Tue May 15 11:58:44 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 15 May 2007 12:58:44 +0100 Subject: [et-mgmt-tools] virt-manager errors In-Reply-To: <6491e1350705150356l51de82f3xf5a25bfd1585c069@mail.gmail.com> References: <6491e1350705150356l51de82f3xf5a25bfd1585c069@mail.gmail.com> Message-ID: <20070515115844.GC22219@redhat.com> On Tue, May 15, 2007 at 04:26:17PM +0530, satyaakam goswami wrote: > Configuration is as follows > > Hardware Sun X2200 > Xen-unstable > virt-manager : 0.4.0 > > I am able to successfully run RHEL 3.0 update 5 as DomU in fully > virtualized mode when i try creating a VM using virt-manager in > paravirtualized mode i get the following errors > > Unable to complete install 'exceptions.OSError [Errno 2] No such file > or directory: '/var/lib/xen/virtinstmnt.O_oVgK' > Traceback (most recent call last): > File "/usr/local/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 645, > in start_install > tmpfiles = self._prepare_install_location(meter) > File "/usr/lib/python2.4/site-packages/virtinst/ParaVirtGuest.py", > line 65, in _prepare_install_location > (kernelfn,initrdfn,args) = > DistroManager.acquireKernel(self.location, meter, > scratchdir=self.scratchdir, type=self.type) > File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", > line 562, in acquireKernel > if not fetcher.prepareLocation(progresscb): > File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", > line 106, in prepareLocation > self.mntdir = tempfile.mkdtemp(prefix="virtinstmnt.", > dir=self.scratchdir) > File "/usr/lib64/python2.4/tempfile.py", line 328, in mkdtemp > _os.mkdir(file, 0700) > OSError: [Errno 2] No such file or directory: > '/var/lib/xen/virtinstmnt.O_oVgK' > > i checked for directory /var/lib/xen it is missing i could see > /var/lib/xend though Traditionally the directory /var/lib/xen is where pygrub spits out the boot files it extracts, so we made virt-install/virt-manager point to the same place. This dir should be created by the Xen makefiles during the make install process. 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 Tue May 15 12:50:03 2007 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 15 May 2007 08:50:03 -0400 Subject: [et-mgmt-tools] virt-manager errors In-Reply-To: <6491e1350705150356l51de82f3xf5a25bfd1585c069@mail.gmail.com> References: <6491e1350705150356l51de82f3xf5a25bfd1585c069@mail.gmail.com> Message-ID: <4649AC7B.30702@redhat.com> satyaakam goswami wrote: > Configuration is as follows > > Hardware Sun X2200 > Xen-unstable > virt-manager : 0.4.0 > > I am able to successfully run RHEL 3.0 update 5 as DomU in fully > virtualized mode when i try creating a VM using virt-manager in > paravirtualized mode i get the following errors > > Unable to complete install 'exceptions.OSError [Errno 2] No such file > or directory: '/var/lib/xen/virtinstmnt.O_oVgK' > Traceback (most recent call last): > File "/usr/local/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 645, > in start_install > tmpfiles = self._prepare_install_location(meter) > File "/usr/lib/python2.4/site-packages/virtinst/ParaVirtGuest.py", > line 65, in _prepare_install_location > (kernelfn,initrdfn,args) = > DistroManager.acquireKernel(self.location, meter, > scratchdir=self.scratchdir, type=self.type) > File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", > line 562, in acquireKernel > if not fetcher.prepareLocation(progresscb): > File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", > line 106, in prepareLocation > self.mntdir = tempfile.mkdtemp(prefix="virtinstmnt.", > dir=self.scratchdir) > File "/usr/lib64/python2.4/tempfile.py", line 328, in mkdtemp > _os.mkdir(file, 0700) > OSError: [Errno 2] No such file or directory: > '/var/lib/xen/virtinstmnt.O_oVgK' > > i checked for directory /var/lib/xen it is missing i could see > /var/lib/xend though > Did you say RHEL 3 update 5? There is no paravirtualized kernel for any RHEL 3 update. Fully virtualized is your only option. RHEL 4.5 (just released) is paravirtualizable, as well as RHEL 5.0. 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 Tue May 15 15:32:22 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 15 May 2007 15:32:22 +0000 Subject: [et-mgmt-tools] Summit Slides on appliances and on cft/puppet Message-ID: <1179243142.4286.71.camel@galia.watzmann.net> The slides from my talks at the summit are online. They are pretty much the same as what's on the DVD, with minor last-minute tweaks: http://people.redhat.com/dlutter/appliances.pdf http://people.redhat.com/dlutter/cft.pdf David From markmc at redhat.com Tue May 15 17:02:55 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 15 May 2007 18:02:55 +0100 Subject: [et-mgmt-tools] [patch 7/8] Add CapabilitiesParser module In-Reply-To: <20070510154928.GJ31761@redhat.com> References: <20070502120733.362541000@redhat.com> > <20070502120955.474768000@redhat.com> <20070510154928.GJ31761@redhat.com> Message-ID: <1179248575.3529.70.camel@blaa> Hey Dan, All good points. How does this look? I cut out the validation stuff, added tests and changed the comment about try/except/finally. (I'm ignoring the post-install-check and requiring-initrd comments for now ... as you say, they're problems with the existing code) Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-capabilities-parser.patch Type: text/x-patch Size: 11597 bytes Desc: not available URL: From satyaakam at gmail.com Tue May 15 17:20:23 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Tue, 15 May 2007 22:50:23 +0530 Subject: [et-mgmt-tools] virt-manager errors In-Reply-To: <20070515115844.GC22219@redhat.com> References: <6491e1350705150356l51de82f3xf5a25bfd1585c069@mail.gmail.com> <20070515115844.GC22219@redhat.com> Message-ID: <6491e1350705151020l6ca76ea3p48246a0fe5a46762@mail.gmail.com> > Traditionally the directory /var/lib/xen is where pygrub spits out the > boot files it extracts, so we made virt-install/virt-manager point to > the same place. This dir should be created by the Xen makefiles during > the make install process. > > Dan. ok let me see by touching this dir may be that will help or is there a way i can create these dir's without rebuilding xen , now that i have stablized the Environment for Benchmarking. regards Satya From satyaakam at gmail.com Tue May 15 17:22:43 2007 From: satyaakam at gmail.com (satyaakam goswami) Date: Tue, 15 May 2007 22:52:43 +0530 Subject: [et-mgmt-tools] virt-manager errors In-Reply-To: <4649AC7B.30702@redhat.com> References: <6491e1350705150356l51de82f3xf5a25bfd1585c069@mail.gmail.com> <4649AC7B.30702@redhat.com> Message-ID: <6491e1350705151022p79f1f587p2f4ce69097ab3e9d@mail.gmail.com> > Did you say RHEL 3 update 5? There is no paravirtualized kernel for any > RHEL 3 update. Fully virtualized is your only option. RHEL 4.5 (just > released) is paravirtualizable, as well as RHEL 5.0. Yes that is something which i want to try now that have early beta of that kernel , need to figure out how to make a vm out of that , any ideas regards Satya From markmc at redhat.com Tue May 15 17:25:07 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 15 May 2007 18:25:07 +0100 Subject: [et-mgmt-tools] [patch 1/8] Add Installer and re-factor existing code into DistroInstaller In-Reply-To: <20070502120954.977767000@redhat.com>> References: <20070502120733.362541000@redhat.com> > <20070502120954.977767000@redhat.com>> Message-ID: <1179249907.3529.72.camel@blaa> Hey, Here's a fixed version of this which passes the test suite. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-distro-installer-refactor.patch Type: text/x-patch Size: 25657 bytes Desc: not available URL: From herrold at owlriver.com Tue May 15 20:32:58 2007 From: herrold at owlriver.com (R P Herrold) Date: Tue, 15 May 2007 16:32:58 -0400 (EDT) Subject: [et-mgmt-tools] Summit Slides on appliances and on cft/puppet In-Reply-To: <1179243142.4286.71.camel@galia.watzmann.net> References: <1179243142.4286.71.camel@galia.watzmann.net> Message-ID: On Tue, 15 May 2007, David Lutterkort wrote: > http://people.redhat.com/dlutter/appliances.pdf The worked example mentioned on p 24 is 'coming soon' since 4/15 http://people.redhat.com/dlutter/kronolith-appliance.html Could you toss one up there for my interest, please? Thanks -- Russ Herrold From smooge at gmail.com Tue May 15 21:22:16 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 15 May 2007 15:22:16 -0600 Subject: [et-mgmt-tools] Summit Slides on appliances and on cft/puppet In-Reply-To: References: <1179243142.4286.71.camel@galia.watzmann.net> Message-ID: <80d7e4090705151422r35184b8v7a19ba4218f1089@mail.gmail.com> On 5/15/07, R P Herrold wrote: > On Tue, 15 May 2007, David Lutterkort wrote: > > > http://people.redhat.com/dlutter/appliances.pdf > > The worked example mentioned on p 24 is 'coming soon' since > 4/15 > > http://people.redhat.com/dlutter/kronolith-appliance.html > > Could you toss one up there for my interest, please? > Also when will there be an update for cft :)? Or is it waiting until puppet has password changing 'built' in? -- 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 hbrock at redhat.com Tue May 15 21:27:50 2007 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 15 May 2007 17:27:50 -0400 Subject: [et-mgmt-tools] [PATCH][RFC][virtinst] Adding Cloning Feature(changing from libvirtML) In-Reply-To: <002c01c79688$57128a60$a1ec830a@dirac> References: <002c01c79688$57128a60$a1ec830a@dirac> Message-ID: <464A25D6.6070202@redhat.com> Kazuki Mizushima wrote: > > Thank you for commets. > I made it again referring to virt-install and retested. > Attached patches shows help below Thanks for this! I will try it out as is and let you know if I think it needs anything else. 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 Wed May 16 07:55:50 2007 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 16 May 2007 07:55:50 +0000 Subject: [et-mgmt-tools] Summit Slides on appliances and on cft/puppet In-Reply-To: References: <1179243142.4286.71.camel@galia.watzmann.net> Message-ID: <1179302150.4286.80.camel@galia.watzmann.net> On Tue, 2007-05-15 at 16:32 -0400, R P Herrold wrote: > On Tue, 15 May 2007, David Lutterkort wrote: > > > http://people.redhat.com/dlutter/appliances.pdf > > The worked example mentioned on p 24 is 'coming soon' since > 4/15 > > http://people.redhat.com/dlutter/kronolith-appliance.html > > Could you toss one up there for my interest, please? Sorry for jumping the gun - I am in the process of putting that together, but it'll take a little longer. Hopefully in the next couple of weeks, I'll send a mail to the list when it's up. David From dlutter at redhat.com Wed May 16 08:01:07 2007 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 16 May 2007 10:01:07 +0200 Subject: [et-mgmt-tools] Summit Slides on appliances and on cft/puppet In-Reply-To: <80d7e4090705151422r35184b8v7a19ba4218f1089@mail.gmail.com> References: <1179243142.4286.71.camel@galia.watzmann.net> <80d7e4090705151422r35184b8v7a19ba4218f1089@mail.gmail.com> Message-ID: <1179302467.4286.86.camel@galia.watzmann.net> On Tue, 2007-05-15 at 15:22 -0600, Stephen John Smoogen wrote: > Also when will there be an update for cft :)? I released 0.2.1 on 5/8. Are there specific fixes you are looking for ? > Or is it waiting until puppet has password changing 'built' in? I am not sure what you are referring to there - are you talking about the capability to set passwords with the 'usre' resource ? That's actually in 0.22.4 David From markmc at redhat.com Wed May 16 11:41:35 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 16 May 2007 12:41:35 +0100 Subject: [et-mgmt-tools] [patch 0/8] [virtinst] Add installer concept and livecd installer example In-Reply-To: <20070510155444.GK31761@redhat.com> References: <20070502120733.362541000@redhat.com> <20070510155444.GK31761@redhat.com> Message-ID: <1179315695.3504.55.camel@blaa> Hi Dan, On Thu, 2007-05-10 at 16:54 +0100, Daniel P. Berrange wrote: > On Wed, May 02, 2007 at 01:15:28PM +0100, Mark McLoughlin wrote: > > Hey, > > This set of patches explores the notion of allowing virtinst > > to have different installer types apart from the existing support > > for distribution installers. > > > > This notion can be used to e.g. support livecd or pre-built > > system images. > > I've sent a few comments on respective patches, but in general I think this > is all good work we should include. Cool, are you happy with me to push these then? Or do you want a hg repo to pull them from? > Any idea when you'll be doing an installer to deal with pre-built images :-) Well, I have one (see attached) but I want to spend some time figuring out what we want from this and e.g. what the metadata should be like. I'm fairly happy with it so far, though. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-image-installer.patch Type: text/x-patch Size: 16077 bytes Desc: not available URL: From mdehaan at redhat.com Wed May 16 16:54:20 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 May 2007 12:54:20 -0400 Subject: [et-mgmt-tools] Cobbler features Message-ID: <464B373C.9080309@redhat.com> Based on recent list activity, and a talking with everyone at Summit and IRC, here's my list of the top 4 things I'd like to see added to cobbler in the near term: -- Virt support for deploying additional virt types KVM, etc Fullvirt Xen -- Extend the repo management code to deal with older non-yum content (RHN), like mrepo can do, such that running mrepo as a seperate tool for older distros is not required. -- Build a netinstall CD from cobbler for environments that don't do PXE. Tie the CD to a specific profile (or better, eventually, provide a boot menu). Lots of folks need baremetal provisioning and due to aspects beyond their control can't use PXE. -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait time when manage_dhcp is enabled and systems are updated. (Some folks I believe are looking at both of these?) If there's something you'd like to see added feature-wise, I'd be glad to hear ideas. --Michael From mdehaan at redhat.com Wed May 16 16:55:38 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 May 2007 12:55:38 -0400 Subject: [et-mgmt-tools] Re: Cobbler features In-Reply-To: <464B373C.9080309@redhat.com> References: <464B373C.9080309@redhat.com> Message-ID: <464B378A.4070803@redhat.com> Michael DeHaan wrote: > Based on recent list activity, and a talking with everyone at Summit > and IRC, here's my list of the top 4 things I'd like to see added to > cobbler in the near term: > > -- Virt support for deploying additional virt types > KVM, etc > Fullvirt Xen > > -- Extend the repo management code to deal with older non-yum content > (RHN), like mrepo can do, such that running mrepo as a seperate tool > for older distros is not required. > > -- Build a netinstall CD from cobbler for environments that don't do > PXE. Tie the CD to a specific profile (or better, eventually, > provide a boot menu). Lots of folks need baremetal provisioning and > due to aspects beyond their control can't use PXE. > > -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait > time when manage_dhcp is enabled and systems are updated. (Some > folks I believe are looking at both of these?) > > If there's something you'd like to see added feature-wise, I'd be glad > to hear ideas. > > --Michael > > Also: dynamic DNS integration. From smooge at gmail.com Wed May 16 17:30:32 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 16 May 2007 11:30:32 -0600 Subject: [et-mgmt-tools] Summit Slides on appliances and on cft/puppet In-Reply-To: <1179302467.4286.86.camel@galia.watzmann.net> References: <1179243142.4286.71.camel@galia.watzmann.net> <80d7e4090705151422r35184b8v7a19ba4218f1089@mail.gmail.com> <1179302467.4286.86.camel@galia.watzmann.net> Message-ID: <80d7e4090705161030v27ac2817n885b2daae35d4910@mail.gmail.com> On 5/16/07, David Lutterkort wrote: > On Tue, 2007-05-15 at 15:22 -0600, Stephen John Smoogen wrote: > > Also when will there be an update for cft :)? > > I released 0.2.1 on 5/8. Are there specific fixes you are looking for ? > > > Or is it waiting until puppet has password changing 'built' in? > > I am not sure what you are referring to there - are you talking about > the capability to set passwords with the 'usre' resource ? That's > actually in 0.22.4 > Or at least cft getting those changes. I am working on a sample set of puppet configurations that would mimic a chain of security requirements for a set of group of say 5 system administrators and 20+ users. {FISMA -> STIG, PCI} so that a site auditor would know that items were being met, and continually set. In trying cft a few weeks ago, it didnt 'capture' the passwd changes I had made to the pushed out accounts.. so wasnt sure that cft had what it needed to see that shadow changes had been made. -- 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 berrange at redhat.com Wed May 16 18:19:12 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 16 May 2007 19:19:12 +0100 Subject: [et-mgmt-tools] [patch 0/8] [virtinst] Add installer concept and livecd installer example In-Reply-To: <1179315695.3504.55.camel@blaa> References: <20070502120733.362541000@redhat.com> <20070510155444.GK31761@redhat.com> <1179315695.3504.55.camel@blaa> Message-ID: <20070516181912.GH16863@redhat.com> On Wed, May 16, 2007 at 12:41:35PM +0100, Mark McLoughlin wrote: > Hi Dan, > > On Thu, 2007-05-10 at 16:54 +0100, Daniel P. Berrange wrote: > > On Wed, May 02, 2007 at 01:15:28PM +0100, Mark McLoughlin wrote: > > > Hey, > > > This set of patches explores the notion of allowing virtinst > > > to have different installer types apart from the existing support > > > for distribution installers. > > > > > > This notion can be used to e.g. support livecd or pre-built > > > system images. > > > > I've sent a few comments on respective patches, but in general I think this > > is all good work we should include. > > Cool, are you happy with me to push these then? Or do you want a hg > repo to pull them from? Yep, feel free to push this set of patches. 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 fj1826dm at aa.jp.fujitsu.com Thu May 17 08:02:20 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Thu, 17 May 2007 17:02:20 +0900 Subject: [et-mgmt-tools] [PATCH] Add MAC address setting for virt-manager Message-ID: <200705171702.EHB73417.N7EK2G93@aa.jp.fujitsu.com> Hi The attached patch adds MAC address setting to virt-manager. MAC address can set when it creates VM and it adds a network device. Also, the user can choose whether a MAC Address is fixed or automatic setup. c.f. This patch considers MAC address confliction. Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. -------------- next part -------------- A non-text attachment was scrubbed... Name: mac-setting.patch Type: application/octet-stream Size: 25641 bytes Desc: not available URL: From jakub.kulesza at 7bulls.com Thu May 17 09:23:55 2007 From: jakub.kulesza at 7bulls.com (Jakub Kulesza) Date: Thu, 17 May 2007 11:23:55 +0200 Subject: [et-mgmt-tools] Installing Dom-U RH5 and RH4 on non-RH Xen Dom0 Message-ID: <1179393835.14802.309.camel@localhost> Hi. I am trying to find a way to properly boot a Xen Dom-U with RHEL5 or RHEL4 inside, using a non-RH Xen Dom0 system. I don't also want to install the VMM and virt-install tools. I want to find what to put inside the xm configuration to get the instalation cd paravirtualized with the net going. The tools give you such functionality. Where in the code can i find data that is being fed to the xen to start up the VMs? I've tried to figure it out, but i'm not a programmer i'm afraid. I've seen, that the tools use Xen programming API instead of shell commands, so getting the xm configuration file would not be so straightforward i suppose. Do you have any suggestions where i could start looking? Thanks. -- Jakub Kulesza From jim at rossberry.com Thu May 17 08:48:26 2007 From: jim at rossberry.com (Jim Wildman) Date: Thu, 17 May 2007 04:48:26 -0400 (EDT) Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <464B373C.9080309@redhat.com> References: <464B373C.9080309@redhat.com> Message-ID: On Wed, 16 May 2007, Michael DeHaan wrote: > Based on recent list activity, and a talking with everyone at Summit and IRC, > here's my list of the top 4 things I'd like to see added to cobbler in the > near term: > > -- Virt support for deploying additional virt types > KVM, etc > Fullvirt Xen > > -- Extend the repo management code to deal with older non-yum content (RHN), > like mrepo can do, such that running mrepo as a seperate tool for older > distros is not required. > > -- Build a netinstall CD from cobbler for environments that don't do PXE. > Tie the CD to a specific profile (or better, eventually, provide a boot > menu). Lots of folks need baremetal provisioning and due to aspects beyond > their control can't use PXE. > > -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait time > when manage_dhcp is enabled and systems are updated. (Some folks I believe > are looking at both of these?) > > If there's something you'd like to see added feature-wise, I'd be glad to > hear ideas. > > --Michael -- make sure everything runs on RHEL4 from start. Don't Fedoraize cobbler. > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine From mdehaan at redhat.com Thu May 17 15:55:24 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 17 May 2007 11:55:24 -0400 Subject: [et-mgmt-tools] What do you want in yum/channel management tools? Message-ID: <464C7AEC.4000105@redhat.com> Hello et-mgmt-tools folks, Several of us have been thinking we need better free tools around channel (repo) management. Many of you have been saying the same thing. We are starting a new project (we're thinking about calling it 'surfr') to do just that. Basically we want to make it easier to create channels, to mirror existing channels, to add software to channels, to compose channels, and to control access of what computers (or profiles, etc) have access to what channels. These "channels" are basically yum repositories, though possibly they may be virtual yum repositories that actually serve up content from more than one repository (TBD). This would basically support all Red Hat based distros, Fedora, etc. We want to build something that can be easily integrated with cobbler and Virt-Factory from an API perspective, but more importantly also usable as a stand alone tool for those that just need a solid command line app for managing software updates in their datacenters. There are obviously some tools out there that do this now, though we've got some plans of our own and would like to get something out from Red Hat that's on top of the latest goodness (like possibly the yum errata plugin for picking specific updates to apply), and so forth. The app should glue all of this complexity together and make channels very easy to manage and control, and to decide which computers get what. We'd like to hear what you like and don't like about existing tools you use, and dream features you'd really love to have and can't get done today. And, if you'd like to pile on the project, you're absolutely welcome to do so. There's nothing to share yet as this is just lifting off, but we really wanted to gather in community opinions, experience, and insight. We should have some Wiki information up soon on et.redhat.com (pending comments) about goals and such. As there's a lot of code out there that gets pretty close to some of the basic features, I see this taking off fairly quickly. --Michael DeHaan From mdehaan at redhat.com Thu May 17 16:00:46 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 17 May 2007 12:00:46 -0400 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: References: <464B373C.9080309@redhat.com> Message-ID: <464C7C2E.3060808@redhat.com> Jim Wildman wrote: > On Wed, 16 May 2007, Michael DeHaan wrote: > >> Based on recent list activity, and a talking with everyone at Summit >> and IRC, here's my list of the top 4 things I'd like to see added to >> cobbler in the near term: >> >> -- Virt support for deploying additional virt types >> KVM, etc >> Fullvirt Xen >> >> -- Extend the repo management code to deal with older non-yum content >> (RHN), like mrepo can do, such that running mrepo as a seperate tool >> for older distros is not required. >> >> -- Build a netinstall CD from cobbler for environments that don't do >> PXE. Tie the CD to a specific profile (or better, eventually, provide >> a boot menu). Lots of folks need baremetal provisioning and due to >> aspects beyond their control can't use PXE. >> >> -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait >> time when manage_dhcp is enabled and systems are updated. (Some >> folks I believe are looking at both of these?) >> >> If there's something you'd like to see added feature-wise, I'd be >> glad to hear ideas. >> >> --Michael > > -- make sure everything runs on RHEL4 from start. Don't Fedoraize > cobbler. > Absolutely. Cobbler will always run on it. I've drawn the line on RHEL3 though RHEL3 is still provisionable from Cobbler, of course. koan still works on RHEL3 too. As far as new virt support is concerned, virt support in koan is only engaged when --virt is used, and koan will test for what virtualization support is available. Naturally there are lots of Fedora folks who want to play with new technology, and I believe we can happily support both. From markmc at redhat.com Thu May 17 16:03:50 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 17 May 2007 17:03:50 +0100 Subject: [et-mgmt-tools] [patch 0/8] [virtinst] Add installer concept and livecd installer example In-Reply-To: <20070516181912.GH16863@redhat.com> References: <20070502120733.362541000@redhat.com> <20070510155444.GK31761@redhat.com> <1179315695.3504.55.camel@blaa> <20070516181912.GH16863@redhat.com> Message-ID: <1179417830.3859.17.camel@blaa> On Wed, 2007-05-16 at 19:19 +0100, Daniel P. Berrange wrote: > On Wed, May 16, 2007 at 12:41:35PM +0100, Mark McLoughlin wrote: > > Cool, are you happy with me to push these then? Or do you want a hg > > repo to pull them from? > > Yep, feel free to push this set of patches. Okay, pushed now. No doubt I broke something :-) Cheers, Mark. From lippold at gmail.com Thu May 17 16:16:41 2007 From: lippold at gmail.com (Aaron Lippold) Date: Thu, 17 May 2007 18:16:41 +0200 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <464B373C.9080309@redhat.com> References: <464B373C.9080309@redhat.com> Message-ID: <39d2723b0705170916u3177f652r7488a1450c6437cd@mail.gmail.com> Hi Miheal, These sound like great options! The moment the "create install CD/DVD" feature is ready I will be using it!! Thank you for being so open and responsive to us the lowly end user :). Question, you call it a 'netinstall cd' does that mean that the CD would or would not contain the install packages? If not, could that be added as an option? i.e. cobbler --createcd-netinstall or --createcd-mediainstall ... myinstall.iso? I would guess adding the copy of the rpms from the repo would be a small bit of code. I know I would use both very heavily along with cobblers regular pattern. In some cases it might be easier just to walk and or mail a DVD to some places. Distributed group review of a system, testing that's just 'plug in the cd and then run your tests, etc. Thanks again! Aaron On 5/16/07, Michael DeHaan wrote: > Based on recent list activity, and a talking with everyone at Summit and > IRC, here's my list of the top 4 things I'd like to see added to cobbler > in the near term: > > -- Virt support for deploying additional virt types > KVM, etc > Fullvirt Xen > > -- Extend the repo management code to deal with older non-yum content > (RHN), like mrepo can do, such that running mrepo as a seperate tool for > older distros is not required. > > -- Build a netinstall CD from cobbler for environments that don't do > PXE. Tie the CD to a specific profile (or better, eventually, provide > a boot menu). Lots of folks need baremetal provisioning and due to > aspects beyond their control can't use PXE. > > -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait > time when manage_dhcp is enabled and systems are updated. (Some folks > I believe are looking at both of these?) > > If there's something you'd like to see added feature-wise, I'd be glad > to hear ideas. > > --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 Thu May 17 16:22:32 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 17 May 2007 12:22:32 -0400 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <39d2723b0705170916u3177f652r7488a1450c6437cd@mail.gmail.com> References: <464B373C.9080309@redhat.com> <39d2723b0705170916u3177f652r7488a1450c6437cd@mail.gmail.com> Message-ID: <464C8148.1040006@redhat.com> Aaron Lippold wrote: > Hi Miheal, > > These sound like great options! The moment the "create install CD/DVD" > feature is ready I will be using it!! Thank you for being so open and > responsive to us the lowly end user :). > > Question, you call it a 'netinstall cd' does that mean that the CD > would or would not contain the install packages? If not, could that > be added as an option? i.e. cobbler --createcd-netinstall or > --createcd-mediainstall ... myinstall.iso? I would guess adding the > copy of the rpms from the repo would be a small bit of code. Yeah, I think there is a need for both. From what I'm told the later isn't incredibly complex either, and there are some people that are already quite good at doing this who I can tap for advice. When doing the non-net-install the kickstart files have to be managled a bit such that the source changes, and that the tracking options in post don't occur, so the netinstall bit would probably happen first. > > I know I would use both very heavily along with cobblers regular > pattern. In some cases it might be easier just to walk and or mail a > DVD to some places. Distributed group review of a system, testing > that's just 'plug in the cd and then run your tests, etc. > > Thanks again! > > Aaron > > On 5/16/07, Michael DeHaan wrote: >> Based on recent list activity, and a talking with everyone at Summit and >> IRC, here's my list of the top 4 things I'd like to see added to cobbler >> in the near term: >> >> -- Virt support for deploying additional virt types >> KVM, etc >> Fullvirt Xen >> >> -- Extend the repo management code to deal with older non-yum content >> (RHN), like mrepo can do, such that running mrepo as a seperate tool for >> older distros is not required. >> >> -- Build a netinstall CD from cobbler for environments that don't do >> PXE. Tie the CD to a specific profile (or better, eventually, provide >> a boot menu). Lots of folks need baremetal provisioning and due to >> aspects beyond their control can't use PXE. >> >> -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait >> time when manage_dhcp is enabled and systems are updated. (Some folks >> I believe are looking at both of these?) >> >> If there's something you'd like to see added feature-wise, I'd be glad >> to hear ideas. >> >> --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 fj0873gn at aa.jp.fujitsu.com Fri May 18 04:56:35 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Fri, 18 May 2007 13:56:35 +0900 Subject: [et-mgmt-tools] [PATCH] Improve log function Message-ID: <200705181356.CFF17134.HGO0984K@aa.jp.fujitsu.com> Hi, I improved the log function. Outputting it to the file will become help to which our team promptly corresponds to customers. It is simple specifications as follows. * Destination -- /.virt-install/virt-install.log * Log size -- 1MB(1024*1024) * Number of Rotations -- 5 Could you apply this correction? Signed-off-by: Nobuhiro Itou Thanks, Nobuhiro Itou. --------------------------------------------------- diff -r 85efaff7a0a6 virt-install --- a/virt-install Thu May 17 16:07:22 2007 +0100 +++ b/virt-install Fri May 18 10:58:23 2007 +0900 @@ -18,6 +18,7 @@ from optparse import OptionParser, Optio from optparse import OptionParser, OptionValueError import subprocess import logging +import logging.handlers import libxml2 import urlgrabber.progress as progress @@ -25,6 +26,29 @@ import virtinst import virtinst MIN_RAM = 256 +MAX_LOGSIZE = 1024 * 1024 # 1MB +ROTATE_NUM = 5 +DIR_NAME = ".virt-install" +FILE_NAME = "virt-install.log" +FILE_MODE = 'a' +FILE_FORMAT = "[%(asctime)s virt-install %(process)d] %(levelname)s (%(module)s:%(lineno)d) %(message)s" +STREAM_FORMAT = "%(asctime)s %(levelname)-8s %(message)s" +DATEFMT = "%a, %d %b %Y %H:%M:%S" + +# set up logging +vi_dir = os.path.expanduser("~/%s" % DIR_NAME) +if not os.access(vi_dir,os.W_OK): + try: + os.mkdir(vi_dir) + except IOError, e: + raise RuntimeError, "Could not create %d directory: " % vi_dir, e + +filename = "%s/%s" % (vi_dir, FILE_NAME) +rootLogger = logging.getLogger() +rootLogger.setLevel(logging.DEBUG) +fileHandler = logging.handlers.RotatingFileHandler(filename, FILE_MODE, MAX_LOGSIZE, ROTATE_NUM) +fileHandler.setFormatter(logging.Formatter(FILE_FORMAT, DATEFMT)) +rootLogger.addHandler(fileHandler) ### Utility functions def yes_or_no(s): @@ -476,16 +500,13 @@ def main(): def main(): options = parse_args() + streamHandler = logging.StreamHandler(sys.stderr) + streamHandler.setFormatter(logging.Formatter(STREAM_FORMAT, DATEFMT)) if options.debug: - logging.basicConfig(level=logging.DEBUG, - format="%(asctime)s %(levelname)-8s %(message)s", - datefmt="%a, %d %b %Y %H:%M:%S", - stream=sys.stderr) - else: - logging.basicConfig(level=logging.ERROR, - format="%(asctime)s %(levelname)-8s %(message)s", - datefmt="%a, %d %b %Y %H:%M:%S", - stream=sys.stderr) + streamHandler.setLevel(logging.DEBUG) + else: + streamHandler.setLevel(logging.ERROR) + rootLogger.addHandler(streamHandler) conn = libvirt.open(options.connect) type = None @@ -623,4 +644,8 @@ def main(): raise if __name__ == "__main__": - main() + try: + main() + except Exception, e: + logging.exception(e) + From fj0873gn at aa.jp.fujitsu.com Fri May 18 08:08:23 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Fri, 18 May 2007 17:08:23 +0900 Subject: [et-mgmt-tools] [PATCH] Fix virt-manager.log problem Message-ID: <200705181708.FGD13015.KO8GH094@aa.jp.fujitsu.com> Hi, Now, there are the following problems in virt-manager.log. - The content of virt-manager.log is overwritten at the start time of virt-manager. - The log size is keeps increasing infinitely, if it keeps using virt-manager. The attached patch adds to solve these problems. It is change points as follows. * File mode -- append * Log size -- 1MB(1024*1024) * Number of Rotations -- 5 Signed-off-by: Nobuhiro Itou Thanks, Nobuhiro Itou. --------------------------------------------------- diff -r 1538611b315d src/virt-manager.py.in --- a/src/virt-manager.py.in Fri May 11 10:40:24 2007 -0400 +++ b/src/virt-manager.py.in Fri May 18 12:02:52 2007 +0900 @@ -25,6 +25,7 @@ import locale import locale import gettext import logging +import logging.handlers import traceback gettext_app = "virt-manager" @@ -34,8 +35,16 @@ gettext.install(gettext_app, gettext_dir gettext.install(gettext_app, gettext_dir) gettext.bindtextdomain(gettext_app, gettext_dir) +MAX_LOGSIZE = 1024 * 1024 # 1MB +ROTATE_NUM = 5 +DIR_NAME = ".virt-manager" +FILE_NAME = "virt-manager.log" +FILE_MODE = 'a' +FILE_FORMAT = "[%(asctime)s virt-manager %(process)d] %(levelname)s (%(module)s:%(lineno)d) %(message)s" +DATEFMT = "%a, %d %b %Y %H:%M:%S" + # set up logging -vm_dir = os.path.expanduser("~/.virt-manager") +vm_dir = os.path.expanduser("~/%s" % DIR_NAME) if not os.access(vm_dir,os.W_OK): try: os.mkdir(vm_dir) @@ -43,11 +52,12 @@ if not os.access(vm_dir,os.W_OK): raise RuntimeError, "Could not create %d directory: " % vm_dir, e # XXX should we get logging level from gconf, or command line args ? -logging.basicConfig(level=logging.DEBUG, - format="%(asctime)s %(levelname)-8s %(message)s", - datefmt="%a, %d %b %Y %H:%M:%S", - filename="%s/virt-manager.log" % vm_dir, - filemode='w') +filename = "%s/%s" % (vm_dir, FILE_NAME) +rootLogger = logging.getLogger() +rootLogger.setLevel(logging.DEBUG) +fileHandler = logging.handlers.RotatingFileHandler(filename, FILE_MODE, MAX_LOGSIZE, ROTATE_NUM) +fileHandler.setFormatter(logging.Formatter(FILE_FORMAT, DATEFMT)) +rootLogger.addHandler(fileHandler) # Urgh, pygtk merely logs a warning when failing to open # the X11 display connection, and lets everything carry @@ -243,4 +253,7 @@ def main(): gtk.gdk.threads_leave() if __name__ == "__main__": - main() + try: + main() + except Exception, e: + logging.exception(e) From fj0588di at aa.jp.fujitsu.com Fri May 18 10:05:13 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Fri, 18 May 2007 19:05:13 +0900 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting when virt-manager creates VM Message-ID: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> Hi, The attached patch adds VNC-Port setting when virt-manager creates VM. The user can choose whether a VNC-Port is fixed or automatic setup. Signed-off-by: Shigeki Sakamoto Thanks, Shigeki Sakamoto. -------------- next part -------------- A non-text attachment was scrubbed... Name: vnc-port-setting.patch Type: application/octet-stream Size: 29415 bytes Desc: not available URL: From mizushima.kazuk at jp.fujitsu.com Fri May 18 10:49:53 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Fri, 18 May 2007 19:49:53 +0900 Subject: [et-mgmt-tools][PATCH][TAKE2][virtinst]AddingCloningFeature(changing from libvirtML) References: <002c01c79688$57128a60$a1ec830a@dirac> <464A25D6.6070202@redhat.com> Message-ID: <017d01c7993a$44a538a0$a1ec830a@dirac> > Thanks for this! I will try it out as is and let you know if I think it > needs anything else. This patch added the following improvement and fixed bugs to the patch that had been sent last time. -Improvement >> This revision is not able to supported for diffrerent "disk type". >> (e.g. From "file" to "block" or From "block" to "file".) > > That's a reasonable limitation to start off with - should be easy enough > to fix it later. Attached this is able to supported for diffrerent "disk type" from "file" to "block" or from "block" to "file". It looks useful. -Bug fixed The specified Mac address is not set for the clone guest. And I retested the this around. The copy of a sparse file is being tested still and I paln to send the next patch. Two files are attaced. One is the patch named "CloneManager.py-new.patch", another is the patch named "Improvement.diff" done diff from the patch that had been sent last time. Because the patch is sent in succession though it has not been committed yet, it might be confused.I am sorry, will use this one ? Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: Improvement.diff Type: application/octet-stream Size: 8769 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.py-new.patch Type: application/octet-stream Size: 17640 bytes Desc: not available URL: From berrange at redhat.com Fri May 18 11:29:31 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 18 May 2007 12:29:31 +0100 Subject: [et-mgmt-tools] [PATCH] Fix virt-manager.log problem In-Reply-To: <200705181708.FGD13015.KO8GH094@aa.jp.fujitsu.com> References: <200705181708.FGD13015.KO8GH094@aa.jp.fujitsu.com> Message-ID: <20070518112931.GA6750@redhat.com> On Fri, May 18, 2007 at 05:08:23PM +0900, Nobuhiro Itou wrote: > Hi, > > Now, there are the following problems in virt-manager.log. > - The content of virt-manager.log is overwritten at the start > time of virt-manager. > - The log size is keeps increasing infinitely, if it keeps > using virt-manager. > The attached patch adds to solve these problems. > > It is change points as follows. > * File mode -- append > * Log size -- 1MB(1024*1024) > * Number of Rotations -- 5 Very good idea - thanks ! 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 timhughes at goldfish.me.uk Fri May 18 12:36:58 2007 From: timhughes at goldfish.me.uk (Tim Hughes) Date: Fri, 18 May 2007 13:36:58 +0100 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <464C8148.1040006@redhat.com> References: <464B373C.9080309@redhat.com> <39d2723b0705170916u3177f652r7488a1450c6437cd@mail.gmail.com> <464C8148.1040006@redhat.com> Message-ID: <977a11430705180536r2457efd4mcc8e82d1366740fb@mail.gmail.com> On 5/17/07, Michael DeHaan wrote: > Aaron Lippold wrote: > > Hi Miheal, > > > > These sound like great options! The moment the "create install CD/DVD" > > feature is ready I will be using it!! Thank you for being so open and > > responsive to us the lowly end user :). > > > > Question, you call it a 'netinstall cd' does that mean that the CD > > would or would not contain the install packages? If not, could that > > be added as an option? i.e. cobbler --createcd-netinstall or > > --createcd-mediainstall ... myinstall.iso? I would guess adding the > > copy of the rpms from the repo would be a small bit of code. > Yeah, I think there is a need for both. From what I'm told the later > isn't incredibly complex either, and there > are some people that are already quite good at doing this who I can tap > for advice. > > When doing the non-net-install the kickstart files have to be managled a > bit such that the source changes, and that > the tracking options in post don't occur, so the netinstall bit would > probably happen first. > > > > I know I would use both very heavily along with cobblers regular > > pattern. In some cases it might be easier just to walk and or mail a > > DVD to some places. Distributed group review of a system, testing > > that's just 'plug in the cd and then run your tests, etc. > > > > Thanks again! > > > > Aaron > > > > On 5/16/07, Michael DeHaan wrote: > >> Based on recent list activity, and a talking with everyone at Summit and > >> IRC, here's my list of the top 4 things I'd like to see added to cobbler > >> in the near term: > >> > >> -- Virt support for deploying additional virt types > >> KVM, etc > >> Fullvirt Xen > >> > >> -- Extend the repo management code to deal with older non-yum content > >> (RHN), like mrepo can do, such that running mrepo as a seperate tool for > >> older distros is not required. > >> > >> -- Build a netinstall CD from cobbler for environments that don't do > >> PXE. Tie the CD to a specific profile (or better, eventually, provide > >> a boot menu). Lots of folks need baremetal provisioning and due to > >> aspects beyond their control can't use PXE. > >> > >> -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait > >> time when manage_dhcp is enabled and systems are updated. (Some folks > >> I believe are looking at both of these?) > >> > >> If there's something you'd like to see added feature-wise, I'd be glad > >> to hear ideas. > >> > >> --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 > Just an idea for scalability, would it possable to store a lot of this in a database, I have setup a cobbler server at each of my three sites so that i can do pxi and it would be much easier to manage the configurations all from a central database that the cobbler servers could each contact rather than having to configure 3 individual servers -- Tim Hughes mailto:timhughes at goldfish.me.uk From berrange at redhat.com Fri May 18 13:15:38 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 18 May 2007 14:15:38 +0100 Subject: [et-mgmt-tools] [PATCH] Improve log function In-Reply-To: <200705181356.CFF17134.HGO0984K@aa.jp.fujitsu.com> References: <200705181356.CFF17134.HGO0984K@aa.jp.fujitsu.com> Message-ID: <20070518131537.GA338@redhat.com> On Fri, May 18, 2007 at 01:56:35PM +0900, Nobuhiro Itou wrote: > Hi, > > I improved the log function. > Outputting it to the file will become help to which our team > promptly corresponds to customers. > > It is simple specifications as follows. > * Destination -- /.virt-install/virt-install.log > * Log size -- 1MB(1024*1024) > * Number of Rotations -- 5 > > Could you apply this correction? Yes, having virt-manager always create a logfile has been very useful when dealing with bug reports, so I think this is a worthwhile addition to virt-install too. I will push it shortly. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Fri May 18 14:48:19 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 May 2007 10:48:19 -0400 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <977a11430705180536r2457efd4mcc8e82d1366740fb@mail.gmail.com> References: <464B373C.9080309@redhat.com> <39d2723b0705170916u3177f652r7488a1450c6437cd@mail.gmail.com> <464C8148.1040006@redhat.com> <977a11430705180536r2457efd4mcc8e82d1366740fb@mail.gmail.com> Message-ID: <464DBCB3.9000703@redhat.com> Tim Hughes wrote: > On 5/17/07, Michael DeHaan wrote: >> Aaron Lippold wrote: >> > Hi Miheal, >> > >> > These sound like great options! The moment the "create install CD/DVD" >> > feature is ready I will be using it!! Thank you for being so open and >> > responsive to us the lowly end user :). >> > >> > Question, you call it a 'netinstall cd' does that mean that the CD >> > would or would not contain the install packages? If not, could that >> > be added as an option? i.e. cobbler --createcd-netinstall or >> > --createcd-mediainstall ... myinstall.iso? I would guess adding the >> > copy of the rpms from the repo would be a small bit of code. >> Yeah, I think there is a need for both. From what I'm told the later >> isn't incredibly complex either, and there >> are some people that are already quite good at doing this who I can tap >> for advice. >> >> When doing the non-net-install the kickstart files have to be managled a >> bit such that the source changes, and that >> the tracking options in post don't occur, so the netinstall bit would >> probably happen first. >> > >> > I know I would use both very heavily along with cobblers regular >> > pattern. In some cases it might be easier just to walk and or mail a >> > DVD to some places. Distributed group review of a system, testing >> > that's just 'plug in the cd and then run your tests, etc. >> > >> > Thanks again! >> > >> > Aaron >> > >> > On 5/16/07, Michael DeHaan wrote: >> >> Based on recent list activity, and a talking with everyone at >> Summit and >> >> IRC, here's my list of the top 4 things I'd like to see added to >> cobbler >> >> in the near term: >> >> >> >> -- Virt support for deploying additional virt types >> >> KVM, etc >> >> Fullvirt Xen >> >> >> >> -- Extend the repo management code to deal with older non-yum content >> >> (RHN), like mrepo can do, such that running mrepo as a seperate >> tool for >> >> older distros is not required. >> >> >> >> -- Build a netinstall CD from cobbler for environments that don't do >> >> PXE. Tie the CD to a specific profile (or better, eventually, >> provide >> >> a boot menu). Lots of folks need baremetal provisioning and due to >> >> aspects beyond their control can't use PXE. >> >> >> >> -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait >> >> time when manage_dhcp is enabled and systems are updated. (Some >> folks >> >> I believe are looking at both of these?) >> >> >> >> If there's something you'd like to see added feature-wise, I'd be >> glad >> >> to hear ideas. >> >> >> >> --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 >> > > Just an idea for scalability, would it possable to store a lot of this > in a database, I have setup a cobbler server at each of my three sites > so that i can do pxi and it would be much easier to manage the > configurations all from a central database that the cobbler servers > could each contact rather than having to configure 3 individual > servers > One easy way to do this without a lot of database and active connectivity infrastructure (which rather complicates the app) would be to have one master server and several slaves. All that has to be done is to copy the source information over to the slaves and ask cobbler sync to keep things up to date. -- On each slave server, install cobbler, run "cobbler check", and configure /var/lib/cobbler/settings only -- Whenever a change takes place on the master, and you want to sync up the slaves, run a script that ... -- (A) Scp /var/lib/(distros|systems|profiles) to the slaves. -- (B) rsync /etc/cobbler to the slaves -- (C) Also rsync all of the kernel, initrd, and kickstart files stored in other directories to the slaves. A common NFS mount point would eliminate this. -- (D) If you have used "cobbler import", rsync /var/www/cobbler also to get the kickstart tree sources -- (E) for each slave "ssh root at slave01.example.com cobbler sync". I think that would work nicely and still leaves the config files human readable. If this is something a lot of people are interested in doing, I can probably include a command to automate it, though I imagine particular install variations might need site specific customizations. An article on the Wiki is probably a better bet. Having alternate storage backends (like a database) is interesting and that may happen someday, but since there are variations in the configurations between the servers, just putting everything in a database still leaves some stuff out of the picture (whether all the content is accessible from the same paths, etc). Thoughts? --Michael From David.Mackintosh at xdroop.com Fri May 18 18:40:20 2007 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Fri, 18 May 2007 14:40:20 -0400 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <464DBCB3.9000703@redhat.com> References: <464B373C.9080309@redhat.com> <39d2723b0705170916u3177f652r7488a1450c6437cd@mail.gmail.com> <464C8148.1040006@redhat.com> <977a11430705180536r2457efd4mcc8e82d1366740fb@mail.gmail.com> <464DBCB3.9000703@redhat.com> Message-ID: <20070518184020.GE5182@xdroop.com> On Fri, May 18, 2007 at 10:48:19AM -0400, Michael DeHaan wrote: > One easy way to do this without a lot of database and active > connectivity infrastructure (which rather complicates the app) > would be to have one master server and several slaves. All that has to > be done is to copy the source information over to the slaves > and ask cobbler sync to keep things up to date. It sounds like you are re-inventing NIS. -- /\oo/\ / /()\ \ David Mackintosh | dave at xdroop.com | http://www.xdroop.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mdehaan at redhat.com Fri May 18 18:45:52 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 May 2007 14:45:52 -0400 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <20070518184020.GE5182@xdroop.com> References: <464B373C.9080309@redhat.com> <39d2723b0705170916u3177f652r7488a1450c6437cd@mail.gmail.com> <464C8148.1040006@redhat.com> <977a11430705180536r2457efd4mcc8e82d1366740fb@mail.gmail.com> <464DBCB3.9000703@redhat.com> <20070518184020.GE5182@xdroop.com> Message-ID: <464DF460.2010105@redhat.com> David Mackintosh wrote: > On Fri, May 18, 2007 at 10:48:19AM -0400, Michael DeHaan wrote: > > >> One easy way to do this without a lot of database and active >> connectivity infrastructure (which rather complicates the app) >> would be to have one master server and several slaves. All that has to >> be done is to copy the source information over to the slaves >> and ask cobbler sync to keep things up to date. >> > > > > It sounds like you are re-inventing NIS. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Nope. From smooge at gmail.com Mon May 21 17:25:48 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 21 May 2007 11:25:48 -0600 Subject: [et-mgmt-tools] What do you want in yum/channel management tools? In-Reply-To: <464C7AEC.4000105@redhat.com> References: <464C7AEC.4000105@redhat.com> Message-ID: <80d7e4090705211025j6f2a505fv93d5f0bd4ca1ebc0@mail.gmail.com> On 5/17/07, Michael DeHaan wrote: > Hello et-mgmt-tools folks, > > Several of us have been thinking we need better free tools around > channel (repo) management. Many of you have been saying the same > thing. We are starting a new project (we're thinking about calling it > 'surfr') to do just that. > One thing I would like to be able to do with yum is see what architecture something is so I can deal with conflicts a bit easier :). I am having to roll out x86_64 boxes.. I would also like for some ways to deal with multiple repositories better.. I am of the opinion that mixing repo's is silly.. but what do I know :). My customers want to be able to get things from Free/Non-Free/Red/Blue/Orange repos however they want.. and we have to clean up after them. -- 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 berrange at redhat.com Mon May 21 19:58:33 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 21 May 2007 20:58:33 +0100 Subject: [et-mgmt-tools] FYI: manual pages for virt-install & virt-clone Message-ID: <20070521195833.GI24310@redhat.com> FYI, I've just added example man pages for both the virt-install and virt-clone tools. They go into more detail about all the different command line options, and have a handful of example usage sceanarios. English only for now, but I'm going to see if we can get virtinst hooked into the Fedora translation process[1], so we can get them translated to other locales. The man pages are written in Perl's POD format since its a really simple markup language to deal with. This then converted into man format using the pod2man tool. Files are man/en/*.pod and man/en/*.1 Regards, Dan. [1] libvirt & virt-manager are already both part of Fedora i18n process -- |=- 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 May 22 21:44:50 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 22 May 2007 14:44:50 -0700 Subject: [et-mgmt-tools] What do you want in yum/channel management tools? In-Reply-To: <464C7AEC.4000105@redhat.com> References: <464C7AEC.4000105@redhat.com> Message-ID: <1179870290.4293.55.camel@galia.watzmann.net> On Thu, 2007-05-17 at 11:55 -0400, Michael DeHaan wrote: > Basically we want to make it easier to create channels, to mirror > existing channels, to add software to channels, to compose channels, and > to control access of what computers (or profiles, etc) have access to > what channels. That would be really useful. Having used mrepo some, which addresses similar use cases, my two biggest problems with it are (1) mirrors are flaky, and switching mirrors requires editing the mrepo config (2) mrepo is file-based, not package-based; that makes defining what exactly to mirror cumbersome and fragile. One approach would be to define a 'channel' through a (partial) kickstart file, one that just has repo statements and a %packages section, with the resulting package set being the (partially) depclosed set of packages from the repos for that channel; might be that the % packages syntax for kickstart needs to be amended to accomodate all the ways in which people want to compose channels, but that will have to be seen. In addition, there's a lot of overlap with existing yum-utils; it would definitely be good to avoid code duplication with them, instead extending/refactoring as much as possible. As an example, yum doesn't deal with rsync URL's right now. If that is needed for this mirroring tool, it should be added to yum instead of using mirroring-specific code. There's some obvious overlap with mirror manager, too [1], especially when it comes to describing what is being mirrored; not sure how much of what's described on that page is implemented currently. David [1] http://fedoraproject.org/wiki/Infrastructure/MirrorManagement From mdehaan at redhat.com Tue May 22 22:38:56 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 22 May 2007 18:38:56 -0400 Subject: [et-mgmt-tools] What do you want in yum/channel management tools? In-Reply-To: <1179870290.4293.55.camel@galia.watzmann.net> References: <464C7AEC.4000105@redhat.com> <1179870290.4293.55.camel@galia.watzmann.net> Message-ID: <46537100.60108@redhat.com> David Lutterkort wrote: > On Thu, 2007-05-17 at 11:55 -0400, Michael DeHaan wrote: > > >> Basically we want to make it easier to create channels, to mirror >> existing channels, to add software to channels, to compose channels, and >> to control access of what computers (or profiles, etc) have access to >> what channels. >> > > That would be really useful. Having used mrepo some, which addresses > similar use cases, my two biggest problems with it are (1) mirrors are > flaky, and switching mirrors requires editing the mrepo config (2) mrepo > is file-based, not package-based; that makes defining what exactly to > mirror cumbersome and fragile. > As brought up a bit in the notes, from talking with many larger datacenter admins, some additional tooling is needed to control what packages get slurped in (not just everything/latest) as well as being able to snapshot mirrors at points in time for testing and then deployment. It seems a lot of these tools are written in house around existing things like yum-utils, and the same philosophy of "can't we all share this effort" applies as it did with Cobbler I think. It's not that these tools themselves are exceedingly complex, but that unifying glue to simplify them (and make such code available to higher level applications also) would be a huge bonus. > One approach would be to define a 'channel' through a (partial) > kickstart file, one that just has repo statements and a %packages > section, with the resulting package set being the (partially) depclosed > set of packages from the repos for that channel; might be that the % > packages syntax for kickstart needs to be amended to accomodate all the > ways in which people want to compose channels, but that will have to be > seen. > > In addition, there's a lot of overlap with existing yum-utils; it would > definitely be good to avoid code duplication with them, instead > extending/refactoring as much as possible. As an example, yum doesn't > deal with rsync URL's right now. If that is needed for this mirroring > tool, it should be added to yum instead of using mirroring-specific > code. > Agreed, and in fact, intended. We all see this being heavily reliant on yum-utils, particularly reposync, and yumdownloader (and also, obviously, createrepo). What is needed is some good glue that unites all of this (which ultimately ends up being fairly simple), though also there is some need for software to do things like manage errata (updating just parts of things) and be able to control who has access to what software -- some of which isn't doable in yum-utils today. This might speak yum API for greater flexibility in some areas. > There's some obvious overlap with mirror manager, too [1], especially > when it comes to describing what is being mirrored; not sure how much of > what's described on that page is implemented currently. > This too, possibly ... https://hosted.fedoraproject.org/projects/bodhi ... One of the primary goals here is to get something that is well supportive of older OS's as well and also command line + API tools that can easily integrate with things like cobbler + virt-factory. A lot of tools like this seem to be web apps, which presents a problem for adminstrative scripting and integration in tools like Virt-Factory. There isn't too much need of a web app specifically here (you can't put a web app on cron), but that doesn't preclude one from existing. However approaching these projects on combining efforts is definitely a good thing to do. > David > > [1] http://fedoraproject.org/wiki/Infrastructure/MirrorManagement > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > I think it was posted earlier, but if not, we have a mockup manpage in git (thanks to M?ir?n Duffy) *http://tinyurl.com/2uyvzg* There are also some meeting notes from one of our earlier meetings, though these have evolved some since... http://et.redhat.com/page/Surfr-notes-18-May-2007 Anyhow, more comments/feedback welcome. --Michael From jim at rossberry.com Wed May 23 04:11:59 2007 From: jim at rossberry.com (Jim Wildman) Date: Wed, 23 May 2007 00:11:59 -0400 (EDT) Subject: [et-mgmt-tools] issue with templating and substitution Message-ID: Given the following snippet in default.ks <-------snip----> cat << YUMEND > /etc/yum.repos.d/default.$lbuild.repo [$lbuild base] name = $lbuild base repo baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.os [$lbuild updates] name = $lbuild updates repo baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.updates [$lbuild rpmforge] name = $lbuild rpmforge repo baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.rpmforge enabled=0 YUMEND <-----end------> and a ksmeta for this profile of ks metadata : {'lbuild': 'centos5-i386'} Cobbler will successfully replace every instance of $lbuild with centos5-i386 except the _first_ one (the one in the 'cat' line). ie, the file ends up named 'default..repo'. I've tried $$lbuild (got me the PID of the cobbler sync I think), and \$ (got me nothing), and yum.repos.d/$lbuild.repo (which got me a hidden file named .repo which is why I added the 'default'). suggestions?? root at dl380 cobbler]# rpm -q cobbler cobbler-0.4.8-1 Host is centos4 ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine From fj0873gn at aa.jp.fujitsu.com Wed May 23 08:08:45 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Wed, 23 May 2007 17:08:45 +0900 Subject: [et-mgmt-tools] [PATCH] recognize CD-ROM from guest OS after install Message-ID: <200705231708.DEB95833.K4G8H9O0@aa.jp.fujitsu.com> Hi, I made the patch that the HVM domain after install has non-source virtual CD-ROM device. The effect of this patch is the following. - Users doesn't need attach virtual CD-ROM device to install software and driver after installing the domain. - CD-ROM can be used only by executing xm block-configure. Could you apply this correction? Signed-off-by: Nobuhiro Itou Thanks, Nobuhiro Itou. ----------------------------------------------------------- diff -r b5297ff8ca09 virtinst/FullVirtGuest.py --- a/virtinst/FullVirtGuest.py Mon May 21 16:08:11 2007 -0400 +++ b/virtinst/FullVirtGuest.py Tue May 22 15:55:46 2007 +0900 @@ -228,7 +228,10 @@ class FullVirtGuest(Guest.XenGuest): count = 0 for d in self.disks: if d.transient and not install: - continue + if d.device == Guest.VirtualDisk.DEVICE_CDROM: + d.path = None + else: + continue if count > 4: raise ValueError, "Can't use more than 4 disks on an HVM guest" if d.device == Guest.VirtualDisk.DEVICE_CDROM and count != 2: diff -r b5297ff8ca09 virtinst/Guest.py --- a/virtinst/Guest.py Mon May 21 16:08:11 2007 -0400 +++ b/virtinst/Guest.py Tue May 22 19:11:32 2007 +0900 @@ -119,17 +119,20 @@ class VirtualDisk: # FIXME: set selinux context? def get_xml_config(self, disknode): - typeattr = 'file' - if self.type == VirtualDisk.TYPE_BLOCK: - typeattr = 'dev' - - ret = " \n" % { "type": self.type, "device": self.device } - if not(self.driver_name is None): - if self.driver_type is None: - ret += " \n" % { "name": self.driver_name } - else: - ret += " \n" % { "name": self.driver_name, "type": self.driver_type } - ret += " \n" % { "typeattr": typeattr, "disk": self.path } + if self.path is None: + ret = " \n" % { "device": self.device } + else: + typeattr = 'file' + if self.type == VirtualDisk.TYPE_BLOCK: + typeattr = 'dev' + + ret = " \n" % { "type": self.type, "device": self.device } + if not(self.driver_name is None): + if self.driver_type is None: + ret += " \n" % { "name": self.driver_name } + else: + ret += " \n" % { "name": self.driver_name, "type": self.driver_type } + ret += " \n" % { "typeattr": typeattr, "disk": self.path } ret += " \n" % { "disknode": disknode } if self.read_only: ret += " \n" From fj1826dm at aa.jp.fujitsu.com Wed May 23 08:25:32 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Wed, 23 May 2007 17:25:32 +0900 Subject: [et-mgmt-tools] [PATCH] Add MAC address setting for virt-manager In-Reply-To: <200705171702.EHB73417.N7EK2G93@aa.jp.fujitsu.com> References: <200705171702.EHB73417.N7EK2G93@aa.jp.fujitsu.com> Message-ID: <200705231725.ICE78159.23EN7G9K@aa.jp.fujitsu.com> Hi Would you give me a comment on this patch? If not, please apply it. Thanks, Masayuki Sunou. In message <200705171702.EHB73417.N7EK2G93 at aa.jp.fujitsu.com> "[et-mgmt-tools] [PATCH] Add MAC address setting for virt-manager" "Masayuki Sunou " wrote: > Hi > > The attached patch adds MAC address setting to virt-manager. > MAC address can set when it creates VM and it adds a network device. > Also, the user can choose whether a MAC Address is fixed or automatic setup. > > c.f. > This patch considers MAC address confliction. > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From hyclak at math.ohiou.edu Wed May 23 11:40:05 2007 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Wed, 23 May 2007 07:40:05 -0400 Subject: [et-mgmt-tools] issue with templating and substitution In-Reply-To: References: Message-ID: <20070523114005.GA26821@math.ohiou.edu> On Wed, May 23, 2007 at 12:11:59AM -0400, Jim Wildman enlightened us: > Given the following snippet in default.ks > > <-------snip----> > cat << YUMEND > /etc/yum.repos.d/default.$lbuild.repo > [$lbuild base] > name = $lbuild base repo > baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.os > > [$lbuild updates] > name = $lbuild updates repo > baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.updates > > [$lbuild rpmforge] > name = $lbuild rpmforge repo > baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.rpmforge > enabled=0 > YUMEND > <-----end------> > > and a ksmeta for this profile of > ks metadata : {'lbuild': 'centos5-i386'} > > Cobbler will successfully replace every instance of $lbuild with > centos5-i386 except the _first_ one (the one in the 'cat' line). > ie, the file ends up named 'default..repo'. I've tried $$lbuild (got me > the PID of the cobbler sync I think), and \$ (got me nothing), and > yum.repos.d/$lbuild.repo (which got me a hidden file named .repo which > is why I added the 'default'). > > suggestions?? > ${lbuild} ? Seems to have solved some of my weird problems with cheetah... Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 From hbrock at redhat.com Wed May 23 14:00:06 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 23 May 2007 10:00:06 -0400 Subject: [et-mgmt-tools] [PATCH] Add MAC address setting for virt-manager In-Reply-To: <200705231725.ICE78159.23EN7G9K@aa.jp.fujitsu.com> References: <200705171702.EHB73417.N7EK2G93@aa.jp.fujitsu.com> <200705231725.ICE78159.23EN7G9K@aa.jp.fujitsu.com> Message-ID: <465448E6.9050803@redhat.com> Masayuki Sunou wrote: > Hi > > Would you give me a comment on this patch? > If not, please apply it. > > Thanks, > Masayuki Sunou. > Sorry, yes, I am looking at it today 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 hyclak at math.ohiou.edu Wed May 23 14:42:49 2007 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Wed, 23 May 2007 10:42:49 -0400 Subject: [et-mgmt-tools] Cobbler netboot_enable utility Message-ID: <20070523144249.GI6397@math.ohiou.edu> I just shared this with Michael on IRC and he suggested I posted it to the list, so here it is. Running koan on a target machine seemed too cumbersome sometimes, so I wrote this little app to more or less flip the netboot_enabled bit on a system, so that you could run this utility: cobbler_change_netboot.py enable mysystem and simply reboot the target machine. The next logical step, then, is to have the system phone home when it is finished reinstalling to flip the bit back to 0. I've done this in the past (on a homegrown system) by having the target wget a webpage which was a script that changed the status from 'reinstall' to 'installed'. This could also be done via some ssh magic. I would also like to add in some sort of trigger ability much like cobbler has to do things like 'puppetca --clean hostname' when preparing for a reinstall. This is a very basic proof of concept of the idea, but to be a good "release early, release often" type guy, here it is. Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 From hyclak at math.ohiou.edu Wed May 23 14:51:29 2007 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Wed, 23 May 2007 10:51:29 -0400 Subject: [et-mgmt-tools] Cobbler netboot_enable utility In-Reply-To: <20070523144249.GI6397@math.ohiou.edu> References: <20070523144249.GI6397@math.ohiou.edu> Message-ID: <20070523145129.GJ6397@math.ohiou.edu> On Wed, May 23, 2007 at 10:42:49AM -0400, Matt Hyclak enlightened us: > I just shared this with Michael on IRC and he suggested I posted it to the > list, so here it is. > > Running koan on a target machine seemed too cumbersome sometimes, so I wrote > this little app to more or less flip the netboot_enabled bit on a system, so > that you could run this utility: > > cobbler_change_netboot.py enable mysystem > > and simply reboot the target machine. > > The next logical step, then, is to have the system phone home when it is > finished reinstalling to flip the bit back to 0. I've done this in the past > (on a homegrown system) by having the target wget a webpage which was a > script that changed the status from 'reinstall' to 'installed'. This could > also be done via some ssh magic. > > I would also like to add in some sort of trigger ability much like cobbler > has to do things like 'puppetca --clean hostname' when preparing for a > reinstall. > > This is a very basic proof of concept of the idea, but to be a good "release > early, release often" type guy, here it is. > This time with an attachment... Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 -------------- next part -------------- #!/usr/bin/env python from cobbler import api import getopt, sys def usage(): print """ Usage: cobbler_change_netboot.py [-hv] COMMAND SYSTEMNAME """ def extended_usage(): print """ Usage: cobbler_change_netboot.py [-hv] COMMAND SYSTEMNAME Options: -h|--help Print help -v|--verbose Turns on more verbose messages Commands: enable Enables netboot for this system (causes reinstall) disable Disables netboot for this system (causes default boot) """ def vprint(msg): try: if verbose: print msg except NameError: pass try: opts, args = getopt.getopt(sys.argv[1:], "hv", ["help", "verbose"]) except getopt.GetoptError: usage() sys.exit(1) verbose = 0 for o, a in opts: if o in ("-h", "--help"): extended_usage() sys.exit(0) if o in ("-v", "--verbose"): verbose = 1 if len(args) != 2: usage() sys.exit(1) else: command = args[0] systemname = args[1] if command not in ["enable", "disable"]: extended_usage() sys.exit(1) elif (command == "enable"): netboot = 1 else: netboot = 0 shoehorn = api.BootAPI() systems = shoehorn.systems() found = systems.find(systemname) if (found): found.netboot_enabled = netboot retval = shoehorn.serialize() syncval = shoehorn.sync() # vim:tabstop=4 From mdehaan at redhat.com Wed May 23 16:20:39 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 23 May 2007 12:20:39 -0400 Subject: [et-mgmt-tools] Info on a few advanced topics up on the Cobbler Wiki Message-ID: <465469D7.5040703@redhat.com> I've added some basic documentation on writing apps using the Cobbler API, extending Cobbler with Triggers, and the XMLRPC interface to the Cobbler Wiki. http://et.redhat.com/page/Cobbler_Wiki If there's any other information you'd like to see added, let me know. Thanks, Michael From hbrock at redhat.com Wed May 23 19:48:21 2007 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 23 May 2007 15:48:21 -0400 Subject: [et-mgmt-tools] [PATCH] recognize CD-ROM from guest OS after install In-Reply-To: <200705231708.DEB95833.K4G8H9O0@aa.jp.fujitsu.com> References: <200705231708.DEB95833.K4G8H9O0@aa.jp.fujitsu.com> Message-ID: <46549A85.9010805@redhat.com> Nobuhiro Itou wrote: > Hi, > > I made the patch that the HVM domain after install has > non-source virtual CD-ROM device. > > The effect of this patch is the following. > - Users doesn't need attach virtual CD-ROM device to install software and driver > after installing the domain. > - CD-ROM can be used only by executing xm block-configure. > > Could you apply this correction? > > Signed-off-by: Nobuhiro Itou > > > Thanks, > Nobuhiro Itou. > > > ----------------------------------------------------------- I have applied this. But, could you post the xm block-configure command you used to get the hvm guest to actually mount the disk? I wasn't able to get that part to work. 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 Wed May 23 20:03:47 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 23 May 2007 16:03:47 -0400 Subject: [et-mgmt-tools] issue with templating and substitution In-Reply-To: <20070523114005.GA26821@math.ohiou.edu> References: <20070523114005.GA26821@math.ohiou.edu> Message-ID: <46549E23.7080601@redhat.com> Matt Hyclak wrote: > On Wed, May 23, 2007 at 12:11:59AM -0400, Jim Wildman enlightened us: > >> Given the following snippet in default.ks >> >> <-------snip----> >> cat << YUMEND > /etc/yum.repos.d/default.$lbuild.repo >> [$lbuild base] >> name = $lbuild base repo >> baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.os >> >> [$lbuild updates] >> name = $lbuild updates repo >> baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.updates >> >> [$lbuild rpmforge] >> name = $lbuild rpmforge repo >> baseurl = http://10.1.1.1/mrepo/$lbuild/RPMS.rpmforge >> enabled=0 >> YUMEND >> <-----end------> >> >> and a ksmeta for this profile of >> ks metadata : {'lbuild': 'centos5-i386'} >> >> Cobbler will successfully replace every instance of $lbuild with >> centos5-i386 except the _first_ one (the one in the 'cat' line). >> ie, the file ends up named 'default..repo'. I've tried $$lbuild (got me >> the PID of the cobbler sync I think), and \$ (got me nothing), and >> yum.repos.d/$lbuild.repo (which got me a hidden file named .repo which >> is why I added the 'default'). >> >> suggestions?? >> >> > > ${lbuild} ? > > Seems to have solved some of my weird problems with cheetah... > > Matt > > Sounds like a good topic for the Cobbler Wiki ... If anyone else is doing anything interesting or has any Cheetah templating tricks, share up and I'll post them... particularly anything interesting tricks about includes, both Cheetah #includes and kickstart %includes... --Michael From ccoffing at novell.com Wed May 23 20:16:31 2007 From: ccoffing at novell.com (Charles Coffing) Date: Wed, 23 May 2007 14:16:31 -0600 Subject: [et-mgmt-tools] [PATCH] virt-manager's "Delete machine" menu item does not work Message-ID: <46544BA2.D169.003C.0@novell.com> Selecting "Delete machine" from the Edit menu in virt-manager does nothing. The signal was never hooked up. The patch below fixes it. Thanks, Signed-off-by: Charles Coffing --- src/virtManager/manager.py~ 2007-05-23 14:05:19.000000000 -0600 +++ src/virtManager/manager.py 2007-05-23 14:06:48.000000000 -0600 @@ -171,6 +171,7 @@ "on_vm_open_clicked": self.open_vm_console, "on_vm_new_clicked": self.show_vm_create, "on_vm_delete_clicked": self.delete_vm, + "on_menu_edit_delete_activate" : self.delete_vm, "on_menu_edit_details_activate": self.show_vm_details, "on_menu_host_details_activate": self.show_host, From mdehaan at redhat.com Wed May 23 21:58:34 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 23 May 2007 17:58:34 -0400 Subject: [et-mgmt-tools] dnsmasq (was: Two cobbler feature suggestions (fwd)) In-Reply-To: <463F2507.5070205@redhat.com> References: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> <463F2507.5070205@redhat.com> Message-ID: <4654B90A.1030804@redhat.com> Michael DeHaan wrote: > Bryan K. Wright wrote: >> Hi folks, >> >> Here's a note I sent recently to Michael DeHaan, and his response. >> He suggested I forward it to the list. As he suggests, I'll take a look >> at Cobbler's trigger infrastructure and see what would be required >> to get Cobbler to play with dnsmasq. I've got a rough implementation coded up together on my server now that allows for using dnsmasq instead of ISC. Works pretty well. What you do is set "manage_dhcpd_mode" to "dnsmasq" and then can do things like: cobbler system add --name=AA:BB:CC:DD:EE:FF --ip-address=192.168.1.50 --hostname=blippy I should have something checked in to the repo tomorrow, (default mode = "isc"), though I'm experiencing some problems with routing setup. If there are any dnsmasq experts who might be able to help debug what's up with the kickstart files not being retrieved, that would prove useful. Basically the system will PXE fine, DHCP works as intended, but the cobbler server address (192.168.1.210 in this case) is apparently not reachable. Anyhow, this is pretty close to achieving dynamic DNS management within cobbler. I like what I see so far. If someone knows how to add host entries (DHCP and DNS) into dnsmasq without restart, that would also prove useful -- I see something can be done with polling resolv.conf (nice) but am not sure about the DHCP component. Right now cobbler is templating out /etc/dnsmasq.conf using /etc/cobbler/dnsmasq.template and reloading the service, much like the way the DHCP management works now. --Michael From fj0588di at aa.jp.fujitsu.com Thu May 24 00:57:46 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Thu, 24 May 2007 09:57:46 +0900 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting when virt-managercreates VM In-Reply-To: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> References: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> Message-ID: <200705240957.GDC09874.99JG60KE@aa.jp.fujitsu.com> Hi Would you give me a comment on this patch? If not, please apply it. Thanks, Shigeki Sakamoto. > Hi, > > The attached patch adds VNC-Port setting when virt-manager creates VM. > The user can choose whether a VNC-Port is fixed or automatic setup. > > Signed-off-by: Shigeki Sakamoto > > > Thanks, > Shigeki Sakamoto. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From berrange at redhat.com Thu May 24 01:35:28 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 May 2007 02:35:28 +0100 Subject: [et-mgmt-tools] dnsmasq (was: Two cobbler feature suggestions (fwd)) In-Reply-To: <4654B90A.1030804@redhat.com> References: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> <463F2507.5070205@redhat.com> <4654B90A.1030804@redhat.com> Message-ID: <20070524013528.GB21564@redhat.com> On Wed, May 23, 2007 at 05:58:34PM -0400, Michael DeHaan wrote: > Michael DeHaan wrote: > >Bryan K. Wright wrote: > >>Hi folks, > >> > >> Here's a note I sent recently to Michael DeHaan, and his response. > >>He suggested I forward it to the list. As he suggests, I'll take a look > >>at Cobbler's trigger infrastructure and see what would be required > >>to get Cobbler to play with dnsmasq. > > I've got a rough implementation coded up together on my server now that > allows for using dnsmasq instead of ISC. Works pretty well. > > What you do is set "manage_dhcpd_mode" to "dnsmasq" and then can do > things like: > > cobbler system add --name=AA:BB:CC:DD:EE:FF --ip-address=192.168.1.50 > --hostname=blippy > > I should have something checked in to the repo tomorrow, (default mode = > "isc"), though I'm experiencing some problems with routing setup. If > there are any dnsmasq experts who might be able to help debug what's up > with the kickstart files not being retrieved, that would prove useful. > Basically the system will PXE fine, DHCP works as intended, but the > cobbler server address (192.168.1.210 in this case) is apparently not > reachable. > > Anyhow, this is pretty close to achieving dynamic DNS management within > cobbler. I like what I see so far. > > If someone knows how to add host entries (DHCP and DNS) into dnsmasq > without restart, that would also prove useful -- I see something can be > done with polling resolv.conf (nice) but am not sure about the DHCP > component. Right now cobbler is templating out /etc/dnsmasq.conf using > /etc/cobbler/dnsmasq.template and reloading the service, much like the > way the DHCP management works now. dnsmasq has a DBus API you can use to control it while running. Never used it myself, but it sounds like the kinda thing you'd need. Also worth checking to see if sending the proess a SIGHUP / SIGUSR1 might cause it to reload its resolv.conf 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 May 24 01:41:00 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 May 2007 02:41:00 +0100 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting when virt-manager creates VM In-Reply-To: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> References: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> Message-ID: <20070524014100.GC21564@redhat.com> On Fri, May 18, 2007 at 07:05:13PM +0900, S.Sakamoto wrote: > Hi, > > The attached patch adds VNC-Port setting when virt-manager creates VM. > The user can choose whether a VNC-Port is fixed or automatic setup. I don't think we want to expose ability to specify a fixed VNC port numbers in virt-manager. 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. 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. Finally, any one using virt-manager for management of guests never needs to know the port number, since virt-manager will always query it from the XML, so this is a very small niche usecase & I don't think it is worthwhile adding an extra step in the new VM wizard just for this capability. 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 fj0873gn at aa.jp.fujitsu.com Thu May 24 05:15:43 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Thu, 24 May 2007 14:15:43 +0900 Subject: [et-mgmt-tools] [PATCH] recognize CD-ROM from guest OS afterinstall In-Reply-To: <46549A85.9010805@redhat.com> References: <200705231708.DEB95833.K4G8H9O0@aa.jp.fujitsu.com> <46549A85.9010805@redhat.com> Message-ID: <200705241415.BEC21377.O8G40HK9@aa.jp.fujitsu.com> Hi, Hugh > But, could you post the xm block-configure command you used to get the > hvm guest to actually mount the disk? I wasn't able to get that part to > work. I tested in the following environments. - Host OS : Fedora7-test4 - Guest OS : RHEL5 GA - Xen : 3.1.0-rc7-2925.8.f I send a result of xm block-configure command. Thanks, Nobuhiro Itou. -------------- next part -------------- A non-text attachment was scrubbed... Name: xm block-configure.txt Type: application/octet-stream Size: 5809 bytes Desc: not available URL: From mizushima.kazuk at jp.fujitsu.com Thu May 24 11:15:28 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Thu, 24 May 2007 20:15:28 +0900 Subject: [et-mgmt-tools] [PATCH][virtinst] support for cloning a sparse file Message-ID: <035a01c79df4$d5cb73d0$a1ec830a@dirac> Hi, I made a patch that supported for copying a sparse file for reference in an opinion of Dan Berrange and investigating cp.c source in fileutils. >> Now, I investigate sparse files copying. > > There's no easy way to detect if a file is sparse - particularly in python. > I think the best option is to detect sequences of zeros. eg, if you are > reading the source file 4096 bytes at a time, check to see if that 4096 > set of bytes are all zeros. If they are, then seek() forward 4096 bytes > instead of writing the set of zeros. When copying a sparse file, I change read/write buffer to 4096 because it is 4096 in cp.c. And I add the "--nonsparse" option as virt-install. Default behavior is creating a sparse. Basically when destination file/disk doesn't exist, create a sparse file and do sparselly copying (means lseek when detecting 4096 sequences of zeros) to that sparse file. When destination file exists, do non-sparselly copying(means no lseek when detecting 4096 sequences of zeros) to the existing file. In the above-mentioned, as a result of measuring the performance of copying a sparse, I get the performance equivalent to the command of 'cp --sparse=always'. A)used source file # ls -als sparse.img 2788280 -rwxr-xr-x 1 root root 5368709121 2007-05-18 12:48 sparse.img B)cp # time -p cp sparse.img sparse_copy.img --sparse=always --verbose `sparse.img' -> `sparse_copy.img' real 190.71 user 1.50 sys 10.70 # ls -als sparse* 2788280 -rwxr-xr-x 1 root root 5368709121 2007-05-18 12:48 sparse.img 2612528 -rwxr-xr-x 1 root root 5368709121 2007-05-18 16:25 sparse_copy.img C)virt-clone (sparse to sparse) # time -p ./virt-clone -o PV_RH5GA_SPA -n PV_RH5GA_SPA_CLONE -f /var/tmp/img/sparse_copy.img Cloning from /var/tmp/sparse.img to /var/tmp/img/sparse_copy.img Cloning domain... 100% |=========================| 5.0 GB 03:15 real 196.49 user 16.87 sys 13.68 # ls -als sparse* 2788280 -rwxr-xr-x 1 root root 5368709121 2007-05-18 12:48 sparse.img 2612536 -rwxr-xr-x 1 root root 5368709122 2007-05-24 09:31 sparse_copy.img Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.py.sparse.patch Type: application/octet-stream Size: 2606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone.sparse.patch Type: application/octet-stream Size: 1516 bytes Desc: not available URL: From mdehaan at redhat.com Thu May 24 14:16:00 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 24 May 2007 10:16:00 -0400 Subject: [et-mgmt-tools] dnsmasq In-Reply-To: <20070524013528.GB21564@redhat.com> References: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> <463F2507.5070205@redhat.com> <4654B90A.1030804@redhat.com> <20070524013528.GB21564@redhat.com> Message-ID: <46559E20.4050208@redhat.com> Daniel P. Berrange wrote: > On Wed, May 23, 2007 at 05:58:34PM -0400, Michael DeHaan wrote: > >> Michael DeHaan wrote: >> >>> Bryan K. Wright wrote: >>> >>>> Hi folks, >>>> >>>> Here's a note I sent recently to Michael DeHaan, and his response. >>>> He suggested I forward it to the list. As he suggests, I'll take a look >>>> at Cobbler's trigger infrastructure and see what would be required >>>> to get Cobbler to play with dnsmasq. >>>> >> I've got a rough implementation coded up together on my server now that >> allows for using dnsmasq instead of ISC. Works pretty well. >> >> What you do is set "manage_dhcpd_mode" to "dnsmasq" and then can do >> things like: >> >> cobbler system add --name=AA:BB:CC:DD:EE:FF --ip-address=192.168.1.50 >> --hostname=blippy >> >> I should have something checked in to the repo tomorrow, (default mode = >> "isc"), though I'm experiencing some problems with routing setup. If >> there are any dnsmasq experts who might be able to help debug what's up >> with the kickstart files not being retrieved, that would prove useful. >> Basically the system will PXE fine, DHCP works as intended, but the >> cobbler server address (192.168.1.210 in this case) is apparently not >> reachable. >> >> Anyhow, this is pretty close to achieving dynamic DNS management within >> cobbler. I like what I see so far. >> >> If someone knows how to add host entries (DHCP and DNS) into dnsmasq >> without restart, that would also prove useful -- I see something can be >> done with polling resolv.conf (nice) but am not sure about the DHCP >> component. Right now cobbler is templating out /etc/dnsmasq.conf using >> /etc/cobbler/dnsmasq.template and reloading the service, much like the >> way the DHCP management works now. >> > > dnsmasq has a DBus API you can use to control it while running. Never used > it myself, but it sounds like the kinda thing you'd need. Also worth > checking to see if sending the proess a SIGHUP / SIGUSR1 might cause it > to reload its resolv.conf > > Dan. > Very cool. Per the manpage, SIGHUP does resolv.conf but at least from the documentation it sounded like there wasn't a way to manipulate DHCP ... From mdehaan at redhat.com Thu May 24 14:34:34 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 24 May 2007 10:34:34 -0400 Subject: [et-mgmt-tools] dnsmasq In-Reply-To: <46559E20.4050208@redhat.com> References: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> <463F2507.5070205@redhat.com> <4654B90A.1030804@redhat.com> <20070524013528.GB21564@redhat.com> <46559E20.4050208@redhat.com> Message-ID: <4655A27A.4040906@redhat.com> Michael DeHaan wrote: > Daniel P. Berrange wrote: >> On Wed, May 23, 2007 at 05:58:34PM -0400, Michael DeHaan wrote: >>> Michael DeHaan wrote: >>>> Bryan K. Wright wrote: >>>>> Hi folks, >>>>> >>>>> Here's a note I sent recently to Michael DeHaan, and his response. >>>>> He suggested I forward it to the list. As he suggests, I'll take a >>>>> look >>>>> at Cobbler's trigger infrastructure and see what would be required >>>>> to get Cobbler to play with dnsmasq. >>> I've got a rough implementation coded up together on my server now >>> that allows for using dnsmasq instead of ISC. Works pretty well. >>> >>> What you do is set "manage_dhcpd_mode" to "dnsmasq" and then can do >>> things like: >>> >>> cobbler system add --name=AA:BB:CC:DD:EE:FF >>> --ip-address=192.168.1.50 --hostname=blippy >>> >>> I should have something checked in to the repo tomorrow, (default >>> mode = "isc"), though I'm experiencing some problems with routing >>> setup. If there are any dnsmasq experts who might be able to help >>> debug what's up with the kickstart files not being retrieved, that >>> would prove useful. Basically the system will PXE fine, DHCP works >>> as intended, but the cobbler server address (192.168.1.210 in this >>> case) is apparently not reachable. >>> >>> Anyhow, this is pretty close to achieving dynamic DNS management >>> within cobbler. I like what I see so far. >>> >>> If someone knows how to add host entries (DHCP and DNS) into dnsmasq >>> without restart, that would also prove useful -- I see something can >>> be done with polling resolv.conf (nice) but am not sure about the >>> DHCP component. Right now cobbler is templating out >>> /etc/dnsmasq.conf using /etc/cobbler/dnsmasq.template and reloading >>> the service, much like the way the DHCP management works now. >> >> dnsmasq has a DBus API you can use to control it while running. Never >> used >> it myself, but it sounds like the kinda thing you'd need. Also worth >> checking to see if sending the proess a SIGHUP / SIGUSR1 might cause it >> to reload its resolv.conf >> >> Dan. > Very cool. Per the manpage, SIGHUP does resolv.conf but at least from > the documentation it sounded like there wasn't a way to manipulate > DHCP ... > > > > > Incidentally my percieved "routing" problem was that I didn't have httpd started yesterday :) Changes coming in shortly, looking at dbus shortly after that ... --Michael From hbrock at redhat.com Thu May 24 14:33:23 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 24 May 2007 10:33:23 -0400 Subject: [et-mgmt-tools] [PATCH] recognize CD-ROM from guest OS afterinstall In-Reply-To: <200705241415.BEC21377.O8G40HK9@aa.jp.fujitsu.com> References: <200705231708.DEB95833.K4G8H9O0@aa.jp.fujitsu.com> <46549A85.9010805@redhat.com> <200705241415.BEC21377.O8G40HK9@aa.jp.fujitsu.com> Message-ID: <4655A233.5010600@redhat.com> Nobuhiro Itou wrote: > Hi, Hugh > >> But, could you post the xm block-configure command you used to get the >> hvm guest to actually mount the disk? I wasn't able to get that part to >> work. > > I tested in the following environments. > - Host OS : Fedora7-test4 > - Guest OS : RHEL5 GA > - Xen : 3.1.0-rc7-2925.8.f > > I send a result of xm block-configure command. > Oh, very good, I see how this works now. Thank you! Now, I wonder if it is worth making some UI in virt-manager to connect/disconnect the cdrom when it is configured for the guest, but with no source path... --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 May 24 15:42:34 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 24 May 2007 11:42:34 -0400 Subject: [et-mgmt-tools] dnsmasq In-Reply-To: <4655A27A.4040906@redhat.com> References: <200705071251.l47CpXp3007915@ayesha.phys.virginia.edu> <463F2507.5070205@redhat.com> <4654B90A.1030804@redhat.com> <20070524013528.GB21564@redhat.com> <46559E20.4050208@redhat.com> <4655A27A.4040906@redhat.com> Message-ID: <4655B26A.5090705@redhat.com> Michael DeHaan wrote: > >>>> I've got a rough implementation coded up together on my server now >>>> that allows for using dnsmasq instead of ISC. Works pretty well. >>>> >>>> What you do is set "manage_dhcpd_mode" to "dnsmasq" and then can do >>>> things like: >>>> >>>> cobbler system add --name=AA:BB:CC:DD:EE:FF >>>> --ip-address=192.168.1.50 --hostname=blippy >>>> >>> > This is checked in now, if anyone interested in using dnsmasq with cobbler would like to take a look at it ... I really like what I see so far. git clone git://et.redhat.com/cobbler make rpms To enable this, go into /var/lib/cobbler/settings and add (A) set 'manage_dhcp_mode' to 1 (B) set 'manage_dhcp_mode' = 'dnsmasq' (if you want to go back, change to 'isc') See the manpage notes before proceeding. If you have an existing dnsmasq config, copy the relevant bits to /etc/cobbler/dnsmasq.template first so it won't be overwritten. Off to look at dynamic control options now... --Michael From berrange at redhat.com Thu May 24 18:57:56 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 May 2007 19:57:56 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager's "Delete machine" menu item does not work In-Reply-To: <46544BA2.D169.003C.0@novell.com> References: <46544BA2.D169.003C.0@novell.com> Message-ID: <20070524185755.GB25906@redhat.com> On Wed, May 23, 2007 at 02:16:31PM -0600, Charles Coffing wrote: > Selecting "Delete machine" from the Edit menu in virt-manager > does nothing. The signal was never hooked up. The patch below fixes it. Thanks, will apply it... Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From hbrock at redhat.com Thu May 24 19:52:27 2007 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 24 May 2007 15:52:27 -0400 Subject: [et-mgmt-tools] [PATCH] Add MAC address setting for virt-manager In-Reply-To: <200705231725.ICE78159.23EN7G9K@aa.jp.fujitsu.com> References: <200705171702.EHB73417.N7EK2G93@aa.jp.fujitsu.com> <200705231725.ICE78159.23EN7G9K@aa.jp.fujitsu.com> Message-ID: <4655ECFB.3050600@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 <200705171702.EHB73417.N7EK2G93 at aa.jp.fujitsu.com> > "[et-mgmt-tools] [PATCH] Add MAC address setting for virt-manager" > "Masayuki Sunou " wrote: > >> Hi >> >> The attached patch adds MAC address setting to virt-manager. >> MAC address can set when it creates VM and it adds a network device. >> Also, the user can choose whether a MAC Address is fixed or automatic setup. >> >> c.f. >> This patch considers MAC address confliction. >> >> Signed-off-by: Masayuki Sunou >> >> Thanks, >> Masayuki Sunou. >> I have applied this, 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 nicolas at gmsnet.com Fri May 25 04:30:34 2007 From: nicolas at gmsnet.com (nicolas) Date: Fri, 25 May 2007 13:30:34 +0900 Subject: [et-mgmt-tools] rhel5 and xen with 2 NICs Message-ID: <200705251330.34502.nicolas@gmsnet.com> Hi there, I'm trying to figure what would be the best way to setup a rhel5 box as a Xen domain0. the machine have two physical nics. i would like to setup one nic with global ip (pingable from outside). and the other nic for intranet. i would like my virtual domains to use that configuration too.. each new virtual machine getting the two nics, configured like this .. 1nic pigable from outside, the other one for local network.. some one help me or point me to some tutorial ? thanks in advance .. From fj0873gn at aa.jp.fujitsu.com Fri May 25 09:49:58 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Fri, 25 May 2007 18:49:58 +0900 Subject: [et-mgmt-tools] [PATCH] Fix continue to install Windows Message-ID: <200705251849.DEE05724.O8GH40K9@aa.jp.fujitsu.com> Hi, 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 6bb44f72be68 virtinst/FullVirtGuest.py --- a/virtinst/FullVirtGuest.py Thu May 24 17:10:22 2007 -0400 +++ b/virtinst/FullVirtGuest.py Fri May 25 15:02:10 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 6bb44f72be68 virtinst/Guest.py --- a/virtinst/Guest.py Thu May 24 17:10:22 2007 -0400 +++ b/virtinst/Guest.py Fri May 25 14:22:11 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 fj0588di at aa.jp.fujitsu.com Fri May 25 11:15:53 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Fri, 25 May 2007 20:15:53 +0900 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting when virt-managercreates VM In-Reply-To: <20070524014100.GC21564@redhat.com> References: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> <20070524014100.GC21564@redhat.com> Message-ID: <200705252015.JAF78174.9E9K6GJ0@aa.jp.fujitsu.com> > > The attached patch adds VNC-Port setting when virt-manager creates VM. > > The user can choose whether a VNC-Port is fixed or automatic setup. > > I don't think we want to expose ability to specify a fixed VNC port numbers > in virt-manager. 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. 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. Finally, any one using virt-manager for management of guests > never needs to know the port number, since virt-manager will always query > it from the XML, so this is a very small niche usecase & I don't think it > is worthwhile adding an extra step in the new VM wizard just for this > capability. > Hi I think that fixed port is necessary. Because, it have a problem of security. Don't know a number of a port opening out... then, can't understand the port with attacked possibility. When auto-select, Even if we perform an operative design before guest making, We don't understand we are using any number, and which number was used. It may be a very small niche usecase. But, I think security is not an at all small problem. So, I think that selection of a fixed port number is better. Thanks, Shigeki Sakamoto. From sakaia at jp.fujitsu.com Fri May 25 11:52:07 2007 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Fri, 25 May 2007 20:52:07 +0900 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting whenvirt-managercreates VM In-Reply-To: <200705252015.JAF78174.9E9K6GJ0@aa.jp.fujitsu.com> References: <200705252015.JAF78174.9E9K6GJ0@aa.jp.fujitsu.com> Message-ID: <200705251153.l4PBr3Xk009352@fjmscan502.ms.jp.fujitsu.com> Hi, I think Shigeki is mis-understanding Dan's mail. I request Shigeki to repost his thinking. Thanks Atsushi SAKAI "S.Sakamoto" wrote: > > > The attached patch adds VNC-Port setting when virt-manager creates VM. > > > The user can choose whether a VNC-Port is fixed or automatic setup. > > > > I don't think we want to expose ability to specify a fixed VNC port numbers > > in virt-manager. 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. 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. Finally, any one using virt-manager for management of guests > > never needs to know the port number, since virt-manager will always query > > it from the XML, so this is a very small niche usecase & I don't think it > > is worthwhile adding an extra step in the new VM wizard just for this > > capability. > > > > Hi > > I think that fixed port is necessary. > Because, it have a problem of security. > > Don't know a number of a port opening out... > then, can't understand the port with attacked possibility. > > When auto-select, > Even if we perform an operative design before guest making, > We don't understand we are using any number, and which number was used. > > It may be a very small niche usecase. > But, I think security is not an at all small problem. > So, I think that selection of a fixed port number is better. > > > Thanks, > Shigeki Sakamoto. > > _______________________________________________ > 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 Fri May 25 14:52:07 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 25 May 2007 15:52:07 +0100 Subject: [et-mgmt-tools] [PATCH][virtinst] support for cloning a sparse file In-Reply-To: <035a01c79df4$d5cb73d0$a1ec830a@dirac> References: <035a01c79df4$d5cb73d0$a1ec830a@dirac> Message-ID: <20070525145207.GD11489@redhat.com> On Thu, May 24, 2007 at 08:15:28PM +0900, Kazuki Mizushima wrote: > >>Now, I investigate sparse files copying. > > > >There's no easy way to detect if a file is sparse - particularly in python. > >I think the best option is to detect sequences of zeros. eg, if you are > >reading the source file 4096 bytes at a time, check to see if that 4096 > >set of bytes are all zeros. If they are, then seek() forward 4096 bytes > >instead of writing the set of zeros. > > When copying a sparse file, I change read/write buffer to 4096 because it > is 4096 in cp.c. And I add the "--nonsparse" option as virt-install. > Default behavior is creating a sparse. Basically when destination file/disk > doesn't > exist, create a sparse file and do sparselly copying (means lseek when > detecting > 4096 sequences of zeros) to that sparse file. When destination file exists, > do non-sparselly copying(means no lseek when detecting 4096 sequences of > zeros) > to the existing file. > > In the above-mentioned, as a result of measuring the performance of copying > a sparse, I get the performance equivalent to the command of 'cp > --sparse=always'. Thanks, I have comitted this patch. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Fri May 25 18:51:52 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 25 May 2007 14:51:52 -0400 Subject: [et-mgmt-tools] Cobbler features In-Reply-To: <464B373C.9080309@redhat.com> References: <464B373C.9080309@redhat.com> Message-ID: <46573048.1020707@redhat.com> Michael DeHaan wrote: > Based on recent list activity, and a talking with everyone at Summit > and IRC, here's my list of the top 4 things I'd like to see added to > cobbler in the near term: > A few updates on these ideas... > -- Virt support for deploying additional virt types > KVM, etc > Fullvirt Xen Incidentally, this is going to happen a bit differently than I thought, so if you want to deploy other types of virtualization in an automated way, here's the deal ... It's good. Work is being done to make Xen fullvirt be able to PXE itself, so you'll be able to get everything you can get from Cobbler bare-metal PXE to work here -- presumably PXE menus and all. This is actually simpler and more powerful. However, if your environment can't use PXE (not friends with the guy who sets up the DHCP server, or some other software owns it?), this could cause problems. Getting a next-server address set for the MAC's in question would need to be done, I'm fairly sure the virt-install tools that allow you to set up the machine for PXE will allow you to set a MAC address of tell you what it will be. koan will still exist for helping out with paravirt installs and setting up redeployments. I'd like to see virt-install and virt-manager become aware of cobbler and be able to install from Cobbler servers automatically (pick the profile from a list), and we're looking into how to best make that happen. > > -- Extend the repo management code to deal with older non-yum content > (RHN), like mrepo can do, such that running mrepo as a seperate tool > for older distros is not required. This is going to happen via the new "surfr" project, which cobbler can later integrate at it gets further along. Should be goodness. > > -- Build a netinstall CD from cobbler for environments that don't do > PXE. Tie the CD to a specific profile (or better, eventually, > provide a boot menu). Lots of folks need baremetal provisioning and > due to aspects beyond their control can't use PXE. Just now starting to look at options here... > > -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait > time when manage_dhcp is enabled and systems are updated. (Some > folks I believe are looking at both of these?) DNSMasq support is in the upstream code, as I've sent out in a previous email. If you are using dnsmasq you do need to /sbin/service dnsmasq reload (sighup) the service to make it apply changes, which also happens automagically if you run "cobbler sync" -- but yes, you should get hostname control for free -- which is something several people were looking for. I played around with omshell for dynamic control of ISC dhcpd (OMAPI) and had some issues getting it to connect (no luck) -- but if someone wants to submit a patch that contains their omshell knowledge, that would be great. The cobbler triggers mechanism would also be good for this... http://et.redhat.com/page/Cobbler_Triggers. All that would be required would be writing a hook for the "system add" trigger that sent the appropriate omshell command(s), and a corresponding one for "system remove". --Michael From mizushima.kazuk at jp.fujitsu.com Mon May 28 09:33:13 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Mon, 28 May 2007 18:33:13 +0900 Subject: [et-mgmt-tools] [PATCH]This patch remains the original devices except "disk" Message-ID: <00ba01c7a10b$368b27b0$a1ec830a@dirac> Hi, I make a patch fixed the error when a Original guest has devices, cdrom usb floppy ..., except "disk". This patch remains the original devices except "disk". A user can use, for example, CD-ROM(floppy etc..) devices in the same way as a Original guest in a Cloning guest. I attach the log how the XML is changed before and after. Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: devices.patch Type: application/octet-stream Size: 5168 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 4128 bytes Desc: not available URL: From mizushima.kazuk at jp.fujitsu.com Mon May 28 11:24:50 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Mon, 28 May 2007 20:24:50 +0900 Subject: [et-mgmt-tools] [PATCH] Adding the option "--nodiskcopy" for virt-clone Message-ID: <014601c7a11a$ce2ee570$a1ec830a@dirac> Hi, I make a patch added "--nodiskcopy" option for virt-clone. When this option is specified, only changing and defining a XML is done, and read/write copying is not done. When a user wants to use a ready-made snapshot product and so on not a normal copy(read/write) at the time of device copying, I think that this option is effective. It may be faster than normal copying. A user uses in the following. 1)Take snapshot A user takes snapshot which becomes R/W volumes (e.g. split-mirror way). It depends on a product. 2)Take clone having --nodiskcopy option #virt-clone -o original -n clone -f /dev/snapshot_sysvol -f /dev/snapshot_data1 -f /dev/snapshot_data2 --nodiskcopy Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone.nodiskcopy.patch Type: application/octet-stream Size: 1293 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.nodiskcopy.patch Type: application/octet-stream Size: 1147 bytes Desc: not available URL: From thestrider at gmail.com Tue May 29 00:45:08 2007 From: thestrider at gmail.com (Adam Rosenwald) Date: Mon, 28 May 2007 20:45:08 -0400 Subject: [et-mgmt-tools] DNS-related trigger negatively affected by resolver check Message-ID: <465B7794.3070706@gmail.com> I have been working on a cobbler dns zone factory trigger, which populates zone files according to a customizable regex-based hostname-ip-mapping setting. The trigger is very basic now and uses static settings. Essentially it * Checks to see whether the hostname is valid. o This is done by means of a modifiable regex-based function. * The hostname is converted to an IP address o This is done by means of a modifiable regex-based function. * Forward/Reverse DNS zone templates are cheetahfied and written to a zone directory. Unfortunately, cobbler does two things that limit certain this kind of DNS trigger: 1. The 'syncing' occurs prior to the call of this trigger (and, I would gather, all triggers). * This prohibits custom checks for a valid --name, among other arguments, before the actual sync should occur. o Basically, the cobbler check that I've traced (as show below in the get_pxe_filename definition) determines whether the --name is a valid MAC address or IP address (the actual checking functions found in utils.py) OR whether the --name is a resolveable hostname. * Custom checks are a good idea, because they promote moving policy to trigger-space. 2. The check on 'resolveable hostnames' * This prevents modifications to zone files in triggers. o If the zone file(s) targeted for modification during the trigger mechanism do not possess name entries for the targeted systems (corresponding to system --name), cobbler will complain that --name does not resolve, and one receives an exception. My problem is that, by (2) I cannot implement my trigger at all without modifying cobbler source code (to allow unresolvable names as argument for system adds). If I were to modify the source code accordingly, I find the deeper problem (1), where although my custom check may prohibit a certain kind of hostname from being added to DNS, the system is *still* added, since syncing occurs prior to the call to the trigger. This is an architectural question, which has strong bearing on the development of triggers, and a philosophical question as to whether policy ought to be pushed out to the triggers. What would the best short-term approach to resolving this problem be? I appreciate your time. --BEGIN action_sync.py SNIPPER-- def get_pxe_filename(self,name_input): """ The configuration file for each system pxe uses is either a form of the MAC address of the hex version of the IP. Not sure about ipv6 (or if that works). The system name in the config file is either a system name, an IP, or the MAC, so figure it out, resolve the host if needed, and return the pxe directory name. """ if name_input == "default": return "default" name = utils.find_system_identifier(name_input) if utils.is_ip(name): return utils.get_host_ip(name) elif utils.is_mac(name): return "01-" + "-".join(name.split(":")).lower() else: raise cexceptions.CobblerException("err_resolv", name) --END action_sync.py SNIPPET-- --Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From fj0588di at aa.jp.fujitsu.com Tue May 29 07:44:15 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Tue, 29 May 2007 16:44:15 +0900 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting when virt-managercreates VM In-Reply-To: <20070524014100.GC21564@redhat.com> References: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> <20070524014100.GC21564@redhat.com> Message-ID: <200705291644.JHC35443.96JEGK09@aa.jp.fujitsu.com> 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. From these, I think the problem is bigger opening a port at random than repetition of a port number. That is why at first I make a function of the fixed port number at the time of making guest. Thanks, Shigeki Sakamoto. > On Fri, May 18, 2007 at 07:05:13PM +0900, S.Sakamoto wrote: > > Hi, > > > > The attached patch adds VNC-Port setting when virt-manager creates VM. > > The user can choose whether a VNC-Port is fixed or automatic setup. > > I don't think we want to expose ability to specify a fixed VNC port numbers > in virt-manager. 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. 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. Finally, any one using virt-manager for management of guests > never needs to know the port number, since virt-manager will always query > it from the XML, so this is a very small niche usecase & I don't think it > is worthwhile adding an extra step in the new VM wizard just for this > capability. > > 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 fj0873gn at aa.jp.fujitsu.com Tue May 29 07:59:09 2007 From: fj0873gn at aa.jp.fujitsu.com (Nobuhiro Itou) Date: Tue, 29 May 2007 16:59:09 +0900 Subject: [et-mgmt-tools] [PATCH] Fix virtinst logging Message-ID: <200705291659.JJB13504.84HGKO90@aa.jp.fujitsu.com> Hi, I corrected the following about the virtinst log. - Changing from "print >> sys.stderr" to "logging.error". - Default logging level is changed from ERROR to WARNING. - Adding to output optional and interactive information to the log file only. Could you apply this correction? Signed-off-by: Nobuhiro Itou Thanks, Nobuhiro Itou. -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst_logging.patch Type: application/octet-stream Size: 14384 bytes Desc: not available URL: From berrange at redhat.com Wed May 30 03:11:36 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 30 May 2007 04:11:36 +0100 Subject: [et-mgmt-tools] [PATCH] Add VNC-Port setting when virt-managercreates VM In-Reply-To: <200705291644.JHC35443.96JEGK09@aa.jp.fujitsu.com> References: <200705181905.IIE82330.J99G06KE@aa.jp.fujitsu.com> <20070524014100.GC21564@redhat.com> <200705291644.JHC35443.96JEGK09@aa.jp.fujitsu.com> Message-ID: <20070530031136.GA15129@redhat.com> 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 -=| From berrange at redhat.com Wed May 30 03:21:19 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 30 May 2007 04:21:19 +0100 Subject: [et-mgmt-tools] Re: [PATCH]This patch remains the original devices except "disk" In-Reply-To: <00ba01c7a10b$368b27b0$a1ec830a@dirac> References: <00ba01c7a10b$368b27b0$a1ec830a@dirac> Message-ID: <20070530032119.GB15129@redhat.com> On Mon, May 28, 2007 at 06:33:13PM +0900, Kazuki Mizushima wrote: > Hi, > > I make a patch fixed the error when a Original guest has devices, > cdrom usb floppy ..., except "disk". > > This patch remains the original devices except "disk". A user can use, > for example, CD-ROM(floppy etc..) devices in the same way as a Original > guest in a Cloning guest. I attach the log how the XML is changed before > and after. I came across this problem the other day too - I think we should approach it in a slightly different way though. Basically a disk can be given to the guest in 3 modes - read-only - exclusive read-write - shared read-write In the 2nd case, we definitely need to clone the disk. In the 3rd case we have no need to clone, since if a disk is marked as shared we should assume the user is doing some kinda of clustering setup. In the 1st case of read only we also don't neeed to copy the. It may occasionally be useful to copy shared or read only disks though, so we should have an option to override it default behaviour. eg, if 'hdc' is a readonly cdrom device, then we could have --force-copy=hdc to request that it be copied, even though it is read only. So I think we should deal with it thus: - If device is read-write => copy disk - If device is listed with a --force-copy flag => copy disk - If device is read-only => don't copy disk - If device is shared => don't copy disk Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Wed May 30 03:23:37 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 30 May 2007 04:23:37 +0100 Subject: [et-mgmt-tools] Re: [PATCH] Adding the option "--nodiskcopy" for virt-clone In-Reply-To: <014601c7a11a$ce2ee570$a1ec830a@dirac> References: <014601c7a11a$ce2ee570$a1ec830a@dirac> Message-ID: <20070530032337.GC15129@redhat.com> On Mon, May 28, 2007 at 08:24:50PM +0900, Kazuki Mizushima wrote: > Hi, > > I make a patch added "--nodiskcopy" option for virt-clone. > > When this option is specified, only changing and defining > a XML is done, and read/write copying is not done. > > When a user wants to use a ready-made snapshot product and so on > not a normal copy(read/write) at the time of device copying, I > think that this option is effective. It may be faster than > normal copying. > > A user uses in the following. > 1)Take snapshot > A user takes snapshot which becomes R/W volumes > (e.g. split-mirror way). It depends on a product. > > 2)Take clone having --nodiskcopy option > #virt-clone -o original -n clone -f /dev/snapshot_sysvol > -f /dev/snapshot_data1 > -f /dev/snapshot_data2 > --nodiskcopy Looks good to me, though I think I'd prefer --preserve-data instead of --nodiskcopy as a name. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Wed May 30 03:30:03 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 30 May 2007 04:30:03 +0100 Subject: [et-mgmt-tools] [PATCH] Fix virtinst logging In-Reply-To: <200705291659.JJB13504.84HGKO90@aa.jp.fujitsu.com> References: <200705291659.JJB13504.84HGKO90@aa.jp.fujitsu.com> Message-ID: <20070530033003.GD15129@redhat.com> On Tue, May 29, 2007 at 04:59:09PM +0900, Nobuhiro Itou wrote: > Hi, > > I corrected the following about the virtinst log. > - Changing from "print >> sys.stderr" to "logging.error". > - Default logging level is changed from ERROR to WARNING. > - Adding to output optional and interactive information to the log file only. Hmm. I'm not to sure about this change. It is basically feedback for user input go via the logging sub-system, instead of directly displaying on stderr. This means that if someone ever changed the logging setup, these important user interaction prompt could belost. At the same time, I understand why you want to make this change - to capture more info in the logfiles. I think that instead of replaces 'print >> sys.stderr' with 'logging.error' we should leave the 'print >> sys.stderr' statements as they currently are, and *add* extra calls to 'logging.error' at the same places in the code (or as needed). So important user interaction still goes directly to sys.stderr, but we also log the information at the same 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 bill at bfccomputing.com Wed May 30 04:31:02 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 30 May 2007 00:31:02 -0400 Subject: [et-mgmt-tools] "Could not communicate with" error Message-ID: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> Hi, list, I'm new to cobbler/koan, so I'm hoping this is a newbie error. I've followed the guides on the wiki, added a system, and now I'm trying to create a Xen guest with koan. When I run: koan --virt --server=bread --system=souffle I get a python stacktrace: http://pastebin.ca/521285 and the error: Could not communicate with bread:25151 cobblerd is running and I can telnet to its port, by host name. This is happening on loopback, so iptables shouldn't be in the way (and I tried stopping it as a test). `cobbler list` looks like: distribution : FC-6-xen-i386 profile : FC-6-xen-i386 system : souffle distribution : FC-6-i386 profile : FC-6-i386 repo : fc6i386updates repo : fc6i386extras The machine is: Linux bread 2.6.18-1.2869.fc6xen #1 SMP Wed Dec 20 15:28:06 EST 2006 i686 i686 i386 GNU/Linux (2.6.20 can be brought up with a trip on-site if it'd help) and the software versions are: koan-0.3.1-2.fc6 cobbler-0.4.8-1.fc6 Odds are I'm missing a step/concept. Ideas/suggestions/pointers-to- TFM welcome. 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 rjones at redhat.com Wed May 30 08:25:05 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 30 May 2007 09:25:05 +0100 Subject: [et-mgmt-tools] Re: [Libvir] Finally - fix the build on Debian In-Reply-To: <20fe3cf60705291612t20a33314kd4c7fc37b9a5e107@mail.gmail.com> References: <465C36FC.7060202@redhat.com> <20070529143012.GH7711@redhat.com> <465C3C71.1010709@redhat.com> <20fe3cf60705291612t20a33314kd4c7fc37b9a5e107@mail.gmail.com> Message-ID: <465D34E1.9080104@redhat.com> Marco Sinhoreli wrote: > Hello, > > I compiled the libvirt from last cvs source without to export CFLAGS > -fstack-protector option without problem. After it, I compiled the > virt-manger and it isn't working. Running virt-manager retur this error: > virt-manager > Traceback (most recent call last): > File "/usr/share/virt-manager/virt-manager.py", line 104, in ? > from virtManager.config import vmmConfig > File "/usr/share/virt-manager/virtManager/config.py", line 24, in ? > import libvirt > File "/usr/lib/python2.4/site-packages/libvirt.py", line 7, in ? > import libvirtmod > ImportError: /usr/lib/libvirt.so.0: undefined symbol: __stack_chk_guard > > Also is necess?ry correction in virt-manager code? Looks like it, yes. I'll have a go at compiling virt-manager 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 mdehaan at redhat.com Wed May 30 14:43:07 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 May 2007 10:43:07 -0400 Subject: [et-mgmt-tools] "Could not communicate with" error In-Reply-To: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> Message-ID: <465D8D7B.3010205@redhat.com> Bill McGonigle wrote: > Hi, list, > > I'm new to cobbler/koan, so I'm hoping this is a newbie error. I've > followed the guides on the wiki, added a system, and now I'm trying to > create a Xen guest with koan. When I run: > > koan --virt --server=bread --system=souffle > > I get a python stacktrace: > > http://pastebin.ca/521285 > > and the error: > > Could not communicate with bread:25151 > > cobblerd is running and I can telnet to its port, by host name. This > is happening on loopback, so iptables shouldn't be in the way (and I > tried stopping it as a test). > > `cobbler list` looks like: > > distribution : FC-6-xen-i386 > profile : FC-6-xen-i386 > system : souffle > distribution : FC-6-i386 > profile : FC-6-i386 > repo : fc6i386updates > repo : fc6i386extras > > The machine is: > > Linux bread 2.6.18-1.2869.fc6xen #1 SMP Wed Dec 20 15:28:06 EST 2006 > i686 i686 i386 GNU/Linux > > (2.6.20 can be brought up with a trip on-site if it'd help) and the > software versions are: > > koan-0.3.1-2.fc6 > cobbler-0.4.8-1.fc6 > > Odds are I'm missing a step/concept. Ideas/suggestions/pointers-to-TFM > welcome. > > 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 If this is a fresh install, most likely you haven't rebooted so cobblerd didn't come on automatically. /sbin/service cobblerd start Otherwise it might be a firewall issue, in which case you want to unblock TCP port 25151. --Michael From bill at bfccomputing.com Wed May 30 17:46:17 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 30 May 2007 13:46:17 -0400 Subject: [et-mgmt-tools] "Could not communicate with" error In-Reply-To: <465D8D7B.3010205@redhat.com> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> Message-ID: <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> On May 30, 2007, at 10:43, Michael DeHaan wrote: > > If this is a fresh install, most likely you haven't rebooted so > cobblerd didn't come on automatically. > > /sbin/service cobblerd start > > Otherwise it might be a firewall issue, in which case you want to > unblock TCP port 25151. Thanks, for the response, Michael. As I mentioned, cobblerd is running, I can telnet to the port, and I tried turning off iptables. 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 Wed May 30 18:13:07 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 May 2007 14:13:07 -0400 Subject: [et-mgmt-tools] "Could not communicate with" error In-Reply-To: <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> References: <942A186C-0C49-4607-BBB0-D4014AC64D42@bfccomputing.com> <465D8D7B.3010205@redhat.com> <5C10DBDE-5A72-4B0D-9842-A7D313D6D3EF@bfccomputing.com> Message-ID: <465DBEB3.8090500@redhat.com> Bill McGonigle wrote: > > On May 30, 2007, at 10:43, Michael DeHaan wrote: > >> >> If this is a fresh install, most likely you haven't rebooted so >> cobblerd didn't come on automatically. >> >> /sbin/service cobblerd start >> >> Otherwise it might be a firewall issue, in which case you want to >> unblock TCP port 25151. > > Thanks, for the response, Michael. As I mentioned, cobblerd is > running, I can telnet to the port, and I tried turning off iptables. > > 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 My apologies on my reading comprehension. Judging from the system name, you've found a bug with system names not being something I ordinarily expect them to be. Thankfully, there is an easy workaround that will do what you want. Explanation -- What's going on is Cobbler system objects ("cobbler system add --name=$name") really like to be IP's or hostnames, because these are things that bootloaders understand. PXE, for instance, can't key off of a hostname. In most places, if a hostname is given, cobbler internally maps it to it's resolved IP when setting up a PXE tree. This is really needless because it causes a bunch of dns lookups in an area of the code that shouldn't have to be doing this. So, best practices should state that cobbler system objects, as currently implemented, should be keyed off of MAC addresses, not hostnames. Now, this restriction really shouldn't apply to virt, so what we'll have eventually is allowing any value for --name and have a seperate parameter for specifying the --mac-address (and we already have --ip-address upstream). If --mac-address isn't specified, you'll still be able to create system objects, they just won't be PXE-able. It would look something like this: cobbler system add --name=this_is_just_a_description [--mac-address=AA:BB:CC:DD:EE:FF] [--ip-address=192.168.1.50] So, how to get around the above problem? Unless you need system specific kickstart templating, you can install koan using profiles, and it's much simpler. You won't have to create cobbler system objects for the machines unless you want cobbler to manage your DHCP and/or DNS features for these systems -- and in which case, you should be creating a system object that is keyed off a MAC address. So, how to run koan with profiles? koan --virt --profile=foo --server=bootserver.example.com --virtname=what-to-call-it You can also create regular cobbler system objects using a MAC address of your choice, and provision from that... koan --virt --profile=foo --server=bootserver.example.com --system=AA:BB:CC:DD:EE:FF And that won't run into the bug where the hostname isn't looked up. This will be straightened out more in the next release. Thanks for pointing this out! --Michael From fj1826dm at aa.jp.fujitsu.com Wed May 30 23:29:07 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Thu, 31 May 2007 08:29:07 +0900 Subject: [et-mgmt-tools] [PATCH] Fixes the error when Windows is installed with "-- os-variant" option Message-ID: <200705310829.GAI18261.73KNE29G@aa.jp.fujitsu.com> 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) ------------------------------------------------------------------------------- From mizushima.kazuk at jp.fujitsu.com Thu May 31 02:04:57 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Thu, 31 May 2007 11:04:57 +0900 Subject: [et-mgmt-tools] Re: [PATCH] Adding the option "--nodiskcopy" for virt-clone Message-ID: <008301c7a328$16c99f00$a1ec830a@dirac> > Looks good to me, though I think I'd prefer --preserve-data instead of > --nodiskcopy as a name. Thanks for your opinion. Certainly, the "--preserve-data" is easy to understand for a user. OK. I remake patches. Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.py.preserv.patch Type: application/octet-stream Size: 1147 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone.preserve.patch Type: application/octet-stream Size: 1288 bytes Desc: not available URL: From mizushima.kazuk at jp.fujitsu.com Thu May 31 09:17:52 2007 From: mizushima.kazuk at jp.fujitsu.com (Kazuki Mizushima) Date: Thu, 31 May 2007 18:17:52 +0900 Subject: [et-mgmt-tools] Re: [PATCH]This patch remains the original devices except "disk" References: <00ba01c7a10b$368b27b0$a1ec830a@dirac> <20070530032119.GB15129@redhat.com> Message-ID: <015e01c7a364$913e3a20$a1ec830a@dirac> > --force-copy=hdc > > to request that it be copied, even though it is read only. > > So I think we should deal with it thus: > > - If device is read-write => copy disk > - If device is listed with a --force-copy flag => copy disk > - If device is read-only => don't copy disk > - If device is shared => don't copy disk Thank you for your suggestion. Surely, your is reasonable rather than my. I attached patches which I remade. Signed-off-by: Kazuki Mizushima Thanks, Kazuki Mizushima -------------- next part -------------- A non-text attachment was scrubbed... Name: CloneManager.py.device.patch Type: application/octet-stream Size: 5269 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone.device.patch Type: application/octet-stream Size: 1502 bytes Desc: not available URL: From fj0588di at aa.jp.fujitsu.com Thu May 31 09:22:14 2007 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Thu, 31 May 2007 18:22:14 +0900 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: <200705311822.JEJ86930.0JK9G96E@aa.jp.fujitsu.com> 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 -=| > From daniel.hennessey at aah.co.uk Thu May 31 13:13:17 2007 From: daniel.hennessey at aah.co.uk (hennesd) Date: Thu, 31 May 2007 14:13:17 +0100 Subject: [et-mgmt-tools] koan --virt error Message-ID: <1180617197.6946.12.camel@ubuntu-vm1> 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.repo', 'http://221.206.29.50/cobbler/ks_mirror/CentOS5.0'], ['http://221.206.29.50/cobbler/ks_mirror/config/CentOS5.0-xen-i386-1.repo', '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 ************************************************************************ 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 Thu May 31 14:46:51 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 31 May 2007 10:46:51 -0400 Subject: [et-mgmt-tools] koan --virt error In-Reply-To: <1180617197.6946.12.camel@ubuntu-vm1> References: <1180617197.6946.12.camel@ubuntu-vm1> Message-ID: <465EDFDB.4050604@redhat.com> 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.repo', 'http://221.206.29.50/cobbler/ks_mirror/CentOS5.0'], ['http://221.206.29.50/cobbler/ks_mirror/config/CentOS5.0-xen-i386-1.repo', '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 From pasik at iki.fi Thu May 31 17:06:45 2007 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 31 May 2007 20:06:45 +0300 Subject: [et-mgmt-tools] Fedora 7 support in cobbler? Message-ID: <20070531170645.GO4933@edu.joroinen.fi> Hi! Does cobbler already support Fedora 7? Thanks! -- Pasi From mdehaan at redhat.com Thu May 31 17:11:57 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 31 May 2007 13:11:57 -0400 Subject: [et-mgmt-tools] Fedora 7 support in cobbler? In-Reply-To: <20070531170645.GO4933@edu.joroinen.fi> References: <20070531170645.GO4933@edu.joroinen.fi> Message-ID: <465F01DD.1040306@redhat.com> Pasi K?rkk?inen wrote: > Hi! > > Does cobbler already support Fedora 7? > > Thanks! > > -- Pasi > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > Of course... I'll update the web page seeing F7 isn't listed yet. "yum install cobbler koan" # done --Michael From pasik at iki.fi Thu May 31 18:26:17 2007 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 31 May 2007 21:26:17 +0300 Subject: [et-mgmt-tools] Fedora 7 support in cobbler? In-Reply-To: <465F01DD.1040306@redhat.com> References: <20070531170645.GO4933@edu.joroinen.fi> <465F01DD.1040306@redhat.com> Message-ID: <20070531182617.GP4933@edu.joroinen.fi> On Thu, May 31, 2007 at 01:11:57PM -0400, Michael DeHaan wrote: > Pasi K?rkk?inen wrote: > >Hi! > > > >Does cobbler already support Fedora 7? > > > >Thanks! > > > >-- Pasi > > > Of course... I'll update the web page seeing F7 isn't listed yet. > > "yum install cobbler koan" # done > > --Michael > .. and I guess this also means I can also import F7 to be provisioned with cobbler. I'll have to try it :) Thanks! -- Pasi From msinhore at gmail.com Thu May 31 20:48:02 2007 From: msinhore at gmail.com (Marco Sinhoreli) Date: Thu, 31 May 2007 17:48:02 -0300 Subject: [et-mgmt-tools] Re: [Libvir] Debian package structure In-Reply-To: <465DA008.9080701@redhat.com> References: <20fe3cf60705291048w1fb2c014ud5bdc0e826ac1482@mail.gmail.com> <465DA008.9080701@redhat.com> Message-ID: <20fe3cf60705311348u47e94ebdpeff21174f0df9e2a@mail.gmail.com> On 5/30/07, Richard W.M. Jones wrote: > > Marco Sinhoreli wrote: > > hello all, > > > > I have been worked in libvirt, virt-manager and virtinst packages to > > Debian for a weeks. Packages are now stabilized. Following below the > > /debian directories structure for analise. > > * libvirt: > > svn co http://svn.mussicorp.net/projetos/src/xen/libvirt/trunk/ > > In debian/rules you shouldn't need this any longer (with latest CVS): > > export CFLAGS += -fno-stack-protector I know it is fixed for libvirt, but it is nedded to fix virt-manager too. That's why I keep it in this package. > * Virt-manager: > > svn co > > > http://svn.mussicorp.net/projetos/src/xen/virt-manager/virt-manager/trunk/ > > Shouldn't virt-manager Depends: on python-libvirt and virtinst? My fault. I'll fix it. It should probably Build-Depends: on (eg) cdbs too, since firstly you're > using cdbs in debian/rules, and secondly virt-manager isn't pure Python > - it contains a C-based widget. okay. I'll pay attention on that. Not clear what the postrm was for. Is there configuration kept in > /usr/share/virt-manager? My fault. I'll checked it. Thanks -- Marco Sinhoreli -------------- next part -------------- An HTML attachment was scrubbed... URL: