From levon at movementarian.org Tue Jul 1 02:32:23 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 03:32:23 +0100 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <4863A86B.5080403@redhat.com> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> Message-ID: <20080701023223.GA31574@totally.trollied.org.uk> On Thu, Jun 26, 2008 at 10:32:11AM -0400, Joey Boggs wrote: > --- virtinst--devel.orig/virt-unpack 1969-12-31 19:00:00.000000000 -0500 > +++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 Why isn't this called virt-convert? I don't see any actually "unpacking" going on here. More generally, I'd like to see this be a lot more general, instead of hard-coding for vmx. Ideally 'virt-convert' would be a simple shell that would call out to .../virtinst/formats/vmx.py (or whatever) to handle the details. There's already Unware code there, shouldn't we re-use details wherever possible? regards john From dlutter at redhat.com Tue Jul 1 03:14:55 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 30 Jun 2008 20:14:55 -0700 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <20080701023223.GA31574@totally.trollied.org.uk> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> Message-ID: <1214882095.3368.73.camel@localhost.localdomain> On Tue, 2008-07-01 at 03:32 +0100, John Levon wrote: > On Thu, Jun 26, 2008 at 10:32:11AM -0400, Joey Boggs wrote: > > > --- virtinst--devel.orig/virt-unpack 1969-12-31 19:00:00.000000000 -0500 > > +++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 > > Why isn't this called virt-convert? I don't see any actually "unpacking" > going on here. Calling it virt-pack is more a historical accident. I think renaming it to virt-convert makes sense. It'll require some small changes in the command line switches though, so you cna say from what format and to what format you want to convert. David From jboggs at redhat.com Tue Jul 1 03:38:39 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 30 Jun 2008 23:38:39 -0400 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <1214882095.3368.73.camel@localhost.localdomain> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> Message-ID: <4869A6BF.1090708@redhat.com> Yep it was heading that way, and it's name was historical based on the original virt-pack work. Either way is fine with me, I figured getting a couple formats out there first and then rebasing the master conversion program to virt-convert might be easier once the few types of conversions had been used a bit to beat out any potential bugs. David Lutterkort wrote: > On Tue, 2008-07-01 at 03:32 +0100, John Levon wrote: > >> On Thu, Jun 26, 2008 at 10:32:11AM -0400, Joey Boggs wrote: >> >> >>> --- virtinst--devel.orig/virt-unpack 1969-12-31 19:00:00.000000000 -0500 >>> +++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 >>> >> Why isn't this called virt-convert? I don't see any actually "unpacking" >> going on here. >> > > Calling it virt-pack is more a historical accident. I think renaming it > to virt-convert makes sense. It'll require some small changes in the > command line switches though, so you cna say from what format and to > what format you want to convert. > > David > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From levon at movementarian.org Tue Jul 1 03:48:47 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 04:48:47 +0100 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <1214882095.3368.73.camel@localhost.localdomain> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> Message-ID: <20080701034847.GB31574@totally.trollied.org.uk> On Mon, Jun 30, 2008 at 08:14:55PM -0700, David Lutterkort wrote: > > > --- virtinst--devel.orig/virt-unpack 1969-12-31 19:00:00.000000000 -0500 > > > +++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 > > > > Why isn't this called virt-convert? I don't see any actually "unpacking" > > going on here. > > Calling it virt-pack is more a historical accident. I think renaming it > to virt-convert makes sense. It'll require some small changes in the > command line switches though, so you cna say from what format and to > what format you want to convert. Indeed. I have some comments on that too. What I'd like to see is something like the logic below. I may even be sending patches to do this, if I can get some consensus. virt-convert [-i ifmt] -o ofmt input [output] if input is a file: if ifmt is not specified, sniff ifmt input_dir = dirname(input) input_file = input else if input is a dir sniff dir for ifmt # ls *.vmx input_dir = input input_file = sniffed_input_file if ifmt is not specified error of ofmt is not specified error if output is not specified: output_file = prefix(input_file).libvirt-image.xml output_dir = input_dir else if output is a file: output_dir = dirname(input) output_file = output else if output is a dir: output_dir = output output_file = output_dir/prefix(input_file).libvirt-image.xml if (input_dir == output_dir) disks_need_copying = can-handle-input-disk-format? else disks_need_copying = True This covers some pretty common use cases: virt-convert -o libvirt-domain foo.vmx foo.xml virt-convert -o libvirt-image vmware_appliance/ virt-convert -o libvirt-image vmware_appliance/app.vmc vmware_appliance/app.xml Comments? thanks, john From liuyuhang at cse.buaa.edu.cn Tue Jul 1 07:23:05 2008 From: liuyuhang at cse.buaa.edu.cn (lyh) Date: Tue, 1 Jul 2008 15:23:05 +0800 (CST) Subject: [et-mgmt-tools] (no subject) Message-ID: <20080701072305.5926C37E50@mx2.buaa.edu.cn> An HTML attachment was scrubbed... URL: From berrange at redhat.com Tue Jul 1 08:49:06 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 1 Jul 2008 09:49:06 +0100 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <20080701034847.GB31574@totally.trollied.org.uk> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> <20080701034847.GB31574@totally.trollied.org.uk> Message-ID: <20080701084906.GA11280@redhat.com> On Tue, Jul 01, 2008 at 04:48:47AM +0100, John Levon wrote: > On Mon, Jun 30, 2008 at 08:14:55PM -0700, David Lutterkort wrote: > > > > > --- virtinst--devel.orig/virt-unpack 1969-12-31 19:00:00.000000000 -0500 > > > > +++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 > > > > > > Why isn't this called virt-convert? I don't see any actually "unpacking" > > > going on here. > > > > Calling it virt-pack is more a historical accident. I think renaming it > > to virt-convert makes sense. It'll require some small changes in the > > command line switches though, so you cna say from what format and to > > what format you want to convert. > > Indeed. I have some comments on that too. What I'd like to see is > something like the logic below. I may even be sending patches to do > this, if I can get some consensus. > > virt-convert [-i ifmt] -o ofmt input [output] [snip rest of example] I think this makes alot of sense - it is definitely important to have the command line syntax support multiple formats, even if we've only got an impl for vmware so far. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 1 08:56:01 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 1 Jul 2008 09:56:01 +0100 Subject: [et-mgmt-tools] (no subject) In-Reply-To: <20080701072305.5926C37E50@mx2.buaa.edu.cn> References: <20080701072305.5926C37E50@mx2.buaa.edu.cn> Message-ID: <20080701085600.GB11280@redhat.com> On Tue, Jul 01, 2008 at 03:23:05PM +0800, lyh wrote: > > > Dear Sir/Madam, > I am writing to you with reference to 5 questions: > > 1) Since the Virtio was chosen to be the main platform for IO > virtualization in KVM , how can I get to know the inside of this scheme? [snip rest of questions] This isn't really a KVM developer mailing list - this is for userspace tools managing KVM & other virtualization platforms. You'll likely get better answers from the KVM mailing list detailed here: http://kvm.qumranet.com/kvmwiki/Lists%2C_IRC Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From tom at ng23.net Tue Jul 1 10:20:35 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 11:20:35 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan Message-ID: <486A04F3.4040906@ng23.net> Hi I cant use DHCP yet in my prd environment but i can use koan so i can have cobbler rebuild existing hosts. I have setup a cobbler server and added a test system to that but i encounter an issue when i try and build using koan in that after the client reboots and boots the 'kick' kernel it seems unable to get the kickstart as it starts to ask me which ethernet card to use and also then tries to do a DHCP request. If i hit the URL that generates the kickstart it seems fine and the network part looks like this apart from the xxxxxx and the 'cobbler.server' hostname # Use network installation url --url=http://cobbler.server/cblr/links/RHEL4-u5-i386 # Network information network --bootproto=static --device=eth0 --onboot=on --ip=10.xxx.xxx.19 --netmask=255.255.254.0 --gateway=10.xxx.xxx.253 --nameserver=10.xxx.xxx.117 --hostname=xxxxxxxx In the grub config on the client before i reboot i see this title kick1214906905 root (hd0,0) kernel /vmlinuz ro root=LABEL=/ ks=http://cobbler.server/cblr/svc/op/ks/system/xxxxxxxx initrd /initrd.img and the 'cobbler.server' can be resolved from the client using the correct nameserver - Does anyone have any ideas whats going on as i am stuck? thanks From thestrider at gmail.com Tue Jul 1 10:52:47 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 03:52:47 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A04F3.4040906@ng23.net> References: <486A04F3.4040906@ng23.net> Message-ID: <486A0C7F.6040002@gmail.com> Tom, Please provide the following info: * What does /tftpboot/pxelinux.cfg/xxxxxxx look like (where xxxxxxxx corresponds to your system)? o Is xinetd (or standalone tftpd) running? * What does the host entry (corresponding to your system) in /etc/dhcpd.conf look like? o Is dhcpd running? * Are you 100% positive that there is an ethernet link on eth0 and not on some other NIC? (you may want to try setting ksdevice=link in your tftp boot file)? * Do you observe dhcp-related noise on the cobbler server (tcpdump, etc.) indicating that the provisioned system is communicating properly? Are there any f/w's, vlan issues (you may need a dhcp helper address if your system is on a separate vlan than the cobbler server), etc. that might interfere with the boot process? * Can you provide a more detailed list of what shows up on the console during the boot process? Regards, - A. Tom Brown wrote: > Hi > > I cant use DHCP yet in my prd environment but i can use koan so i can > have cobbler rebuild existing hosts. > > I have setup a cobbler server and added a test system to that but i > encounter an issue when i try and build using koan in that after the > client reboots and boots the 'kick' kernel it seems unable to get the > kickstart as it starts to ask me which ethernet card to use and also > then tries to do a DHCP request. > > If i hit the URL that generates the kickstart it seems fine and the > network part looks like this apart from the xxxxxx and the > 'cobbler.server' hostname > > # Use network installation > url --url=http://cobbler.server/cblr/links/RHEL4-u5-i386 > # Network information > network --bootproto=static --device=eth0 --onboot=on > --ip=10.xxx.xxx.19 --netmask=255.255.254.0 --gateway=10.xxx.xxx.253 > --nameserver=10.xxx.xxx.117 --hostname=xxxxxxxx > > In the grub config on the client before i reboot i see this > > title kick1214906905 > root (hd0,0) > kernel /vmlinuz ro root=LABEL=/ > ks=http://cobbler.server/cblr/svc/op/ks/system/xxxxxxxx > initrd /initrd.img > > and the 'cobbler.server' can be resolved from the client using the > correct nameserver - > > Does anyone have any ideas whats going on as i am stuck? > > thanks > > > _______________________________________________ > 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 tom at ng23.net Tue Jul 1 10:55:35 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 11:55:35 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A04F3.4040906@ng23.net> References: <486A04F3.4040906@ng23.net> Message-ID: <486A0D27.10309@ng23.net> > > > I cant use DHCP yet in my prd environment but i can use koan so i can > have cobbler rebuild existing hosts. > > I have setup a cobbler server and added a test system to that but i > encounter an issue when i try and build using koan in that after the > client reboots and boots the 'kick' kernel it seems unable to get the > kickstart as it starts to ask me which ethernet card to use and also > then tries to do a DHCP request. > > If i hit the URL that generates the kickstart it seems fine and the > network part looks like this apart from the xxxxxx and the > 'cobbler.server' hostname > > # Use network installation > url --url=http://cobbler.server/cblr/links/RHEL4-u5-i386 > # Network information > network --bootproto=static --device=eth0 --onboot=on > --ip=10.xxx.xxx.19 --netmask=255.255.254.0 --gateway=10.xxx.xxx.253 > --nameserver=10.xxx.xxx.117 --hostname=xxxxxxxx > > In the grub config on the client before i reboot i see this > > title kick1214906905 > root (hd0,0) > kernel /vmlinuz ro root=LABEL=/ > ks=http://cobbler.server/cblr/svc/op/ks/system/xxxxxxxx > initrd /initrd.img > > and the 'cobbler.server' can be resolved from the client using the > correct nameserver - > > Does anyone have any ideas whats going on as i am stuck? > i should perhaps point out that i i have manage_dhcp=0 in the configuration so DHCP should not come into the equation. Also i have since removed the cobbler server hostname and replaced it with an IP incase this made a difference, it hasnt. Using a different tty on the install process just before it asks me about which ethernet card to use i can see it say 'getting kickstart file' - If i boot the client i am trying to install back into its OS and then wget on the kickstart URL it downloads fine. still stuck.... thanks From tom at ng23.net Tue Jul 1 10:58:54 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 11:58:54 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A0C7F.6040002@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> Message-ID: <486A0DEE.4090801@ng23.net> > Tom, > > Please provide the following info: > > * What does /tftpboot/pxelinux.cfg/xxxxxxx look like (where > xxxxxxxx corresponds to your system)? > o Is xinetd (or standalone tftpd) running? > * What does the host entry (corresponding to your system) in > /etc/dhcpd.conf look like? > o Is dhcpd running? > * Are you 100% positive that there is an ethernet link on eth0 and > not on some other NIC? (you may want to try setting > ksdevice=link in your tftp boot file)? > * Do you observe dhcp-related noise on the cobbler server > (tcpdump, etc.) indicating that the provisioned system is > communicating properly? Are there any f/w's, vlan issues (you > may need a dhcp helper address if your system is on a separate > vlan than the cobbler server), etc. that might interfere with > the boot process? > * Can you provide a more detailed list of what shows up on the > console during the boot process? > thanks but i am NOT using DHCP - this is rebuilding a current OS. As the install should happen over http is TFTP required? I imagine not thanks From bkearney at redhat.com Tue Jul 1 11:01:33 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 01 Jul 2008 07:01:33 -0400 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <20080701084906.GA11280@redhat.com> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> <20080701034847.GB31574@totally.trollied.org.uk> <20080701084906.GA11280@redhat.com> Message-ID: <486A0E8D.8070205@redhat.com> Daniel P. Berrange wrote: > On Tue, Jul 01, 2008 at 04:48:47AM +0100, John Levon wrote: >> On Mon, Jun 30, 2008 at 08:14:55PM -0700, David Lutterkort wrote: >> >>>>> --- virtinst--devel.orig/virt-unpack 1969-12-31 19:00:00.000000000 -0500 >>>>> +++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 >>>> Why isn't this called virt-convert? I don't see any actually "unpacking" >>>> going on here. >>> >>> Calling it virt-pack is more a historical accident. I think renaming it >>> to virt-convert makes sense. It'll require some small changes in the >>> command line switches though, so you cna say from what format and to >>> what format you want to convert. >> Indeed. I have some comments on that too. What I'd like to see is >> something like the logic below. I may even be sending patches to do >> this, if I can get some consensus. >> >> virt-convert [-i ifmt] -o ofmt input [output] > > [snip rest of example] > > > I think this makes alot of sense - it is definitely important to have the > command line syntax support multiple formats, even if we've only got an > impl for vmware so far. > > Daniel Will the sniffing work for anything but vmware files? I rather it be explicit in all cases unless we can infer them all. -- bk From berrange at redhat.com Tue Jul 1 11:05:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 1 Jul 2008 12:05:08 +0100 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <486A0E8D.8070205@redhat.com> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> <20080701034847.GB31574@totally.trollied.org.uk> <20080701084906.GA11280@redhat.com> <486A0E8D.8070205@redhat.com> Message-ID: <20080701110508.GD11280@redhat.com> On Tue, Jul 01, 2008 at 07:01:33AM -0400, Bryan Kearney wrote: > Daniel P. Berrange wrote: > >On Tue, Jul 01, 2008 at 04:48:47AM +0100, John Levon wrote: > >>On Mon, Jun 30, 2008 at 08:14:55PM -0700, David Lutterkort wrote: > >> > >>>>>--- virtinst--devel.orig/virt-unpack 1969-12-31 > >>>>>19:00:00.000000000 -0500 > >>>>>+++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 > >>>>Why isn't this called virt-convert? I don't see any actually "unpacking" > >>>>going on here. > >>> > >>>Calling it virt-pack is more a historical accident. I think renaming it > >>>to virt-convert makes sense. It'll require some small changes in the > >>>command line switches though, so you cna say from what format and to > >>>what format you want to convert. > >>Indeed. I have some comments on that too. What I'd like to see is > >>something like the logic below. I may even be sending patches to do > >>this, if I can get some consensus. > >> > >>virt-convert [-i ifmt] -o ofmt input [output] > > > >[snip rest of example] > > > > > >I think this makes alot of sense - it is definitely important to have the > >command line syntax support multiple formats, even if we've only got an > >impl for vmware so far. > > > >Daniel > > Will the sniffing work for anything but vmware files? I rather it be > explicit in all cases unless we can infer them all. Yes, there is magic header that lets you detect pretty much all types of disk image file - see the 'qemu-img' command. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From tom at ng23.net Tue Jul 1 11:18:03 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 12:18:03 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A0C7F.6040002@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> Message-ID: <486A126B.6080605@ng23.net> > > * What does /tftpboot/pxelinux.cfg/xxxxxxx look like (where > xxxxxxxx corresponds to your system)? > o Is xinetd (or standalone tftpd) running? > * What does the host entry (corresponding to your system) in > /etc/dhcpd.conf look like? > o Is dhcpd running? > * Are you 100% positive that there is an ethernet link on eth0 and > not on some other NIC? (you may want to try setting > ksdevice=link in your tftp boot file)? > * Do you observe dhcp-related noise on the cobbler server > (tcpdump, etc.) indicating that the provisioned system is > communicating properly? Are there any f/w's, vlan issues (you > may need a dhcp helper address if your system is on a separate > vlan than the cobbler server), etc. that might interfere with > the boot process? > * Can you provide a more detailed list of what shows up on the > console during the boot process? > in addition to not using DHCP the box that i am trying to get cobbler running already provisions machines using kickstart over http using a bit of a home brew system. I am trying to get rid of this system and use cobbler like we do in other environments so from a network level there should be no issues getting the install tree over http as it already does that and i can get the kickstart etc over http to the client with a wget and it looks correct so i am a little stumped. From thestrider at gmail.com Tue Jul 1 11:20:11 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 04:20:11 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A0DEE.4090801@ng23.net> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> Message-ID: <486A12EB.4080206@gmail.com> Tom Brown wrote: > >> Tom, >> >> Please provide the following info: >> >> * What does /tftpboot/pxelinux.cfg/xxxxxxx look like (where >> xxxxxxxx corresponds to your system)? >> o Is xinetd (or standalone tftpd) running? >> * What does the host entry (corresponding to your system) in >> /etc/dhcpd.conf look like? >> o Is dhcpd running? >> * Are you 100% positive that there is an ethernet link on eth0 and >> not on some other NIC? (you may want to try setting >> ksdevice=link in your tftp boot file)? >> * Do you observe dhcp-related noise on the cobbler server >> (tcpdump, etc.) indicating that the provisioned system is >> communicating properly? Are there any f/w's, vlan issues (you >> may need a dhcp helper address if your system is on a separate >> vlan than the cobbler server), etc. that might interfere with >> the boot process? >> * Can you provide a more detailed list of what shows up on the >> console during the boot process? >> > > thanks but i am NOT using DHCP - this is rebuilding a current OS. As > the install should happen over http is TFTP required? I imagine not Yes. DHCP is needed, since your system hasn't been assigned an IP address and can only identify itself by MAC. The network portion of your kickstart file will ensure that a static IP will be assigned to eth0 only AFTER the kickstart file has been downloaded. * Set 'manage_dhcp=1' in /etc/cobbler/settings (or /var/lib/cobbler/settings if using an older version of cobbler). * In the dhcp template file (/etc/cobbler/dhcp.template) ensure that you have configured a stanza for the subnet corresponding to that of your provisioned system. o E.g. + ... + subnet 10.x.x.x netmask 255.255.254.0 { option routers 10.x.x.253; option subnet-mask 255.255.254.0; filename "/pxelinux.0"; next-server $next_server; } + ... o Just be sure there are no 'range dynamic-bootp', 'default-lease-time', or 'max-lease-time' statements, since you are probably concerned about dynamic IP assignments in a prod environment. * When provisioning your system with cobbler, specify *both* a MAC address *and* an IP address, so that the host stanza in /etc/dhcpd.conf is unique and not dependent upon dynamic options. Give it a whirl and reply with any updates. :) - A. > > thanks > > _______________________________________________ > 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 bkearney at redhat.com Tue Jul 1 11:23:53 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 01 Jul 2008 07:23:53 -0400 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <20080701110508.GD11280@redhat.com> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> <20080701034847.GB31574@totally.trollied.org.uk> <20080701084906.GA11280@redhat.com> <486A0E8D.8070205@redhat.com> <20080701110508.GD11280@redhat.com> Message-ID: <486A13C9.5010607@redhat.com> Daniel P. Berrange wrote: > On Tue, Jul 01, 2008 at 07:01:33AM -0400, Bryan Kearney wrote: >> Daniel P. Berrange wrote: >>> On Tue, Jul 01, 2008 at 04:48:47AM +0100, John Levon wrote: >>>> On Mon, Jun 30, 2008 at 08:14:55PM -0700, David Lutterkort wrote: >>>> >>>>>>> --- virtinst--devel.orig/virt-unpack 1969-12-31 >>>>>>> 19:00:00.000000000 -0500 >>>>>>> +++ virtinst--devel/virt-unpack 2008-06-26 10:30:45.000000000 -0400 >>>>>> Why isn't this called virt-convert? I don't see any actually "unpacking" >>>>>> going on here. >>>>> Calling it virt-pack is more a historical accident. I think renaming it >>>>> to virt-convert makes sense. It'll require some small changes in the >>>>> command line switches though, so you cna say from what format and to >>>>> what format you want to convert. >>>> Indeed. I have some comments on that too. What I'd like to see is >>>> something like the logic below. I may even be sending patches to do >>>> this, if I can get some consensus. >>>> >>>> virt-convert [-i ifmt] -o ofmt input [output] >>> [snip rest of example] >>> >>> >>> I think this makes alot of sense - it is definitely important to have the >>> command line syntax support multiple formats, even if we've only got an >>> impl for vmware so far. >>> >>> Daniel >> Will the sniffing work for anything but vmware files? I rather it be >> explicit in all cases unless we can infer them all. > > Yes, there is magic header that lets you detect pretty much all types > of disk image file - see the 'qemu-img' comm Ok.. then I agree that sniffing as muuch as possible woudl be great. -- bk From tom at ng23.net Tue Jul 1 11:27:18 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 12:27:18 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A12EB.4080206@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> Message-ID: <486A1496.1010302@ng23.net> > Yes. DHCP is needed, since your system hasn't been assigned an IP > address and can only identify itself by MAC. The network portion of > your kickstart file will ensure that a static IP will be assigned to > eth0 only AFTER the kickstart file has been downloaded. > > * Set 'manage_dhcp=1' in /etc/cobbler/settings (or > /var/lib/cobbler/settings if using an older version of cobbler). > * In the dhcp template file (/etc/cobbler/dhcp.template) ensure > that you have configured a stanza for the subnet corresponding > to that of your provisioned system. > o E.g. > + ... > + subnet 10.x.x.x netmask 255.255.254.0 { > option routers 10.x.x.253; > option subnet-mask 255.255.254.0; > filename "/pxelinux.0"; > next-server $next_server; > } > + ... > o Just be sure there are no 'range dynamic-bootp', > 'default-lease-time', or 'max-lease-time' statements, > since you are probably concerned about dynamic IP > assignments in a prod environment. > * When provisioning your system with cobbler, specify *both* a MAC > address *and* an IP address, so that the host stanza in > /etc/dhcpd.conf is unique and not dependent upon dynamic options. > > Give it a whirl and reply with any updates. :) > OK thanks for the update i am a bit confused though as i thought that using koan i could _reinstall_ a system without the need for DHCP and PXE - The simple fact is that right now i cant use DHCP in this specific network and so using koan to rebuild, and thats the key i think i am rebuilding a current running OS not bare metal, to contact the cobbler server. Koan contacts the cobbler server and i thought, and it seems correct, that it builds a minimal boot kernel, this boots with IP info and then the kickstart is downloaded negating the need for DHCP. I do similar things in another network to rebuild people's VM's running on laptops etc that are not covered in my DHCP setup and they rebuild fine, the only issue is that this is a new server and o cant seem to figure out whats wrong. i'd like to know if i've had a misconception about koan all this time ;) thanks From thestrider at gmail.com Tue Jul 1 11:34:25 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 04:34:25 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A126B.6080605@ng23.net> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A126B.6080605@ng23.net> Message-ID: <486A1641.2060103@gmail.com> Tom Brown wrote: > >> >> * What does /tftpboot/pxelinux.cfg/xxxxxxx look like (where >> xxxxxxxx corresponds to your system)? >> o Is xinetd (or standalone tftpd) running? >> * What does the host entry (corresponding to your system) in >> /etc/dhcpd.conf look like? >> o Is dhcpd running? >> * Are you 100% positive that there is an ethernet link on eth0 and >> not on some other NIC? (you may want to try setting >> ksdevice=link in your tftp boot file)? >> * Do you observe dhcp-related noise on the cobbler server >> (tcpdump, etc.) indicating that the provisioned system is >> communicating properly? Are there any f/w's, vlan issues (you >> may need a dhcp helper address if your system is on a separate >> vlan than the cobbler server), etc. that might interfere with >> the boot process? >> * Can you provide a more detailed list of what shows up on the >> console during the boot process? >> > > in addition to not using DHCP the box that i am trying to get cobbler > running already provisions machines using kickstart over http using a > bit of a home brew system. I am trying to get rid of this system and > use cobbler like we do in other environments so from a network level > there should be no issues getting the install tree over http as it > already does that and i can get the kickstart etc over http to the > client with a wget and it looks correct so i am a little stumped. Please explain how your home brew system talks to booting systems. When your provisioned systems boot, how do they communicate with the server hosting the kickstart files? As I understand it, at network boot time, they need to have IP addresses, netmasks assigned to them. PXE starts by the NIC(s) broadcasting its MAC address. Some daemon on the LAN segment (typically dhcp) will respond to the broadcast by assigning the NIC an IP address and subnet mask. Unless you have an ability to assign IPs/netmasks to NICs through BIOS (which I've never seen and which would be a pain to do for a 'lot' of servers) or have some other mechanism (i.e. other than DHCP) which assigns IPs/netmasks by responding to MAC broadcasts, you will have to use DHCP somewhere during a network install. -A. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From tom at ng23.net Tue Jul 1 11:41:11 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 12:41:11 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A1641.2060103@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A126B.6080605@ng23.net> <486A1641.2060103@gmail.com> Message-ID: <486A17D7.1010307@ng23.net> > Please explain how your home brew system talks to booting systems. > When your provisioned systems boot, how do they communicate with the > server hosting the kickstart files? > As I understand it, at network boot time, they need to have IP > addresses, netmasks assigned to them. PXE starts by the NIC(s) > broadcasting its MAC address. Some daemon on the LAN segment > (typically dhcp) will respond to the broadcast by assigning the NIC an > IP address and subnet mask. > > Unless you have an ability to assign IPs/netmasks to NICs through BIOS > (which I've never seen and which would be a pain to do for a 'lot' of > servers) or have some other mechanism (i.e. other than DHCP) which > assigns IPs/netmasks by responding to MAC broadcasts, you will have to > use DHCP somewhere during a network install. > i will try and explain as best i can as i did not write the system - but basically what i believes happens is that a minimal boot kernel boots that is generated on the client machines before a reboot is issued. Within this boot kernel is the network info that allows the box to have network info before it then downloads its kickstart file etc. This is how i thought koan worked as i can rebuild machines using a different cobbler server and in a different network that the cobbler server knows nothing about, i mean it knows nothing about these other networks from a DHCP point of view. I can of course see why my goal will not work on a bare metal system but i thought that on a system that has a running OS koan could be used to rebuild it to the profile as per assigned by the cobbler server. When rebuilds occur using koan i did not think DHCP or PXE came into it. thanks From thestrider at gmail.com Tue Jul 1 11:43:38 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 04:43:38 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A1496.1010302@ng23.net> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> Message-ID: <486A186A.4090500@gmail.com> Tom Brown wrote: > >> Yes. DHCP is needed, since your system hasn't been assigned an IP >> address and can only identify itself by MAC. The network portion of >> your kickstart file will ensure that a static IP will be assigned to >> eth0 only AFTER the kickstart file has been downloaded. >> >> * Set 'manage_dhcp=1' in /etc/cobbler/settings (or >> /var/lib/cobbler/settings if using an older version of cobbler). >> * In the dhcp template file (/etc/cobbler/dhcp.template) ensure >> that you have configured a stanza for the subnet corresponding >> to that of your provisioned system. >> o E.g. >> + ... >> + subnet 10.x.x.x netmask 255.255.254.0 { >> option routers 10.x.x.253; >> option subnet-mask 255.255.254.0; >> filename "/pxelinux.0"; >> next-server $next_server; >> } >> + ... >> o Just be sure there are no 'range dynamic-bootp', >> 'default-lease-time', or 'max-lease-time' statements, >> since you are probably concerned about dynamic IP >> assignments in a prod environment. >> * When provisioning your system with cobbler, specify *both* a MAC >> address *and* an IP address, so that the host stanza in >> /etc/dhcpd.conf is unique and not dependent upon dynamic options. >> >> Give it a whirl and reply with any updates. :) >> > > > OK thanks for the update i am a bit confused though as i thought that > using koan i could _reinstall_ a system without the need for DHCP and > PXE - The simple fact is that right now i cant use DHCP in this > specific network and so using koan to rebuild, and thats the key i > think i am rebuilding a current running OS not bare metal, to contact > the cobbler server. > > Koan contacts the cobbler server and i thought, and it seems correct, > that it builds a minimal boot kernel, this boots with IP info and then > the kickstart is downloaded negating the need for DHCP. I do similar > things in another network to rebuild people's VM's running on laptops > etc that are not covered in my DHCP setup and they rebuild fine, the > only issue is that this is a new server and o cant seem to figure out > whats wrong. > > i'd like to know if i've had a misconception about koan all this time ;) > > thanks OK. Something is definitely missing here. Notice how (http://www.redhat.com/magazine/024oct06/features/kickstart/) GRUB contains options for setting the IP address, netmask, and gateway for the system you intend to boot. These arguments are /*not*/ set in /your/ grub configuration. As to why they are not, either you didn't specify them during your cobbler system provisioning OR there is some kind of a bug in koan's 'reprovision' logic. Likely the former. Please double check that you specified cobbler .... --ip=X --subnet=Y --gateway=Z ... in your provision command. -A. > > _______________________________________________ > 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 tom at ng23.net Tue Jul 1 11:49:52 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 12:49:52 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A186A.4090500@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> Message-ID: <486A19E0.8010103@ng23.net> > OK. Something is definitely missing here. Notice how > (http://www.redhat.com/magazine/024oct06/features/kickstart/) GRUB > contains options for setting the IP address, netmask, and gateway for > the system you intend to boot. These arguments are /*not*/ set in > /your/ grub configuration. As to why they are not, either you didn't > specify them during your cobbler system provisioning OR there is some > kind of a bug in koan's 'reprovision' logic. Likely the former. > Please double check that you specified > > cobbler .... --ip=X --subnet=Y --gateway=Z ... > > in your provision command. > # cobbler system report --name=xxxxxx system : xxxxxx profile : RHEL4-u5-i386-prd kernel options : {} kickstart : <> ks metadata : {'nameserver': '10.xxx.xxx.117'} netboot enabled? : True owners : ['admin'] server : <> virt cpus : <> virt file size : <> virt path : <> virt ram : <> virt type : <> interface : intf0 mac address : 00:13:72:69:95:7E ip address : 10.xxx.xxx.19 hostname : xxxxxx gateway : 10.xxx.xxx.253 subnet : 255.255.254.0 virt bridge : dhcp tag : that seems fine to me? and the koan version on the client # rpm -qa | grep koan koan-1.0.0-1.el4 thanks for any further info From rjones at redhat.com Tue Jul 1 11:46:39 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 1 Jul 2008 12:46:39 +0100 Subject: [et-mgmt-tools] (no subject) In-Reply-To: <20080701072305.5926C37E50@mx2.buaa.edu.cn> References: <20080701072305.5926C37E50@mx2.buaa.edu.cn> Message-ID: <20080701114639.GA8114@amd.home.annexia.org> Please don't post HTML to mailing lists. I couldn't be bothered to read your message - it's just far too difficult if you post HTML. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From thestrider at gmail.com Tue Jul 1 11:51:22 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 04:51:22 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A17D7.1010307@ng23.net> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A126B.6080605@ng23.net> <486A1641.2060103@gmail.com> <486A17D7.1010307@ng23.net> Message-ID: <486A1A3A.2000708@gmail.com> Tom Brown wrote: > >> Please explain how your home brew system talks to booting systems. >> When your provisioned systems boot, how do they communicate with the >> server hosting the kickstart files? >> As I understand it, at network boot time, they need to have IP >> addresses, netmasks assigned to them. PXE starts by the NIC(s) >> broadcasting its MAC address. Some daemon on the LAN segment >> (typically dhcp) will respond to the broadcast by assigning the NIC >> an IP address and subnet mask. >> >> Unless you have an ability to assign IPs/netmasks to NICs through >> BIOS (which I've never seen and which would be a pain to do for a >> 'lot' of servers) or have some other mechanism (i.e. other than DHCP) >> which assigns IPs/netmasks by responding to MAC broadcasts, you will >> have to use DHCP somewhere during a network install. >> > > i will try and explain as best i can as i did not write the system - > but basically what i believes happens is that a minimal boot kernel > boots that is generated on the client machines before a reboot is > issued. Within this boot kernel is the network info that allows the > box to have network info before it then downloads its kickstart file > etc. This is how i thought koan worked as i can rebuild machines using > a different cobbler server and in a different network that the cobbler > server knows nothing about, i mean it knows nothing about these other > networks from a DHCP point of view. > > I can of course see why my goal will not work on a bare metal system > but i thought that on a system that has a running OS koan could be > used to rebuild it to the profile as per assigned by the cobbler > server. When rebuilds occur using koan i did not think DHCP or PXE > came into it. > > thanks I understand now. I haven't used GRUB before to pass anaconda options when attempting to perform network installs. Clearly we both now understand the problem and solution. :) -A. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From tom at ng23.net Tue Jul 1 11:54:36 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 12:54:36 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A1A3A.2000708@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A126B.6080605@ng23.net> <486A1641.2060103@gmail.com> <486A17D7.1010307@ng23.net> <486A1A3A.2000708@gmail.com> Message-ID: <486A1AFC.5000600@ng23.net> > I understand now. I haven't used GRUB before to pass anaconda options > when attempting to perform network installs. Clearly we both now > understand the problem and solution. :) > also http://www.nabble.com/koan-1.0.0-is-ignoring-kernel-options-td17702492.html /ME investigating From thestrider at gmail.com Tue Jul 1 12:04:52 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 05:04:52 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A19E0.8010103@ng23.net> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> <486A19E0.8010103@ng23.net> Message-ID: <486A1D64.8070305@gmail.com> Tom Brown wrote: > >> OK. Something is definitely missing here. Notice how >> (http://www.redhat.com/magazine/024oct06/features/kickstart/) GRUB >> contains options for setting the IP address, netmask, and gateway for >> the system you intend to boot. These arguments are /*not*/ set in >> /your/ grub configuration. As to why they are not, either you didn't >> specify them during your cobbler system provisioning OR there is some >> kind of a bug in koan's 'reprovision' logic. Likely the former. >> Please double check that you specified >> >> cobbler .... --ip=X --subnet=Y --gateway=Z ... >> >> in your provision command. >> > > # cobbler system report --name=xxxxxx > system : xxxxxx > profile : RHEL4-u5-i386-prd > kernel options : {} > kickstart : <> > ks metadata : {'nameserver': '10.xxx.xxx.117'} > netboot enabled? : True > owners : ['admin'] > server : <> > virt cpus : <> > virt file size : <> > virt path : <> > virt ram : <> > virt type : <> > interface : intf0 > mac address : 00:13:72:69:95:7E > ip address : 10.xxx.xxx.19 > hostname : xxxxxx > gateway : 10.xxx.xxx.253 > subnet : 255.255.254.0 > virt bridge : > dhcp tag : > > that seems fine to me? > > and the koan version on the client > > # rpm -qa | grep koan > koan-1.0.0-1.el4 > > thanks for any further info OK... good. If you could try to do so, please reprovision your system with the following amendment: * cobbler ... --kopts='ip=10.xxx.xxx.19 netmask=255.255.254.0 gateway=10.xxx.xxx.253 dns=10.xxx.xxx.117' ... Resync and see if the new grub file installed after koaning looks the part. -A. > > > _______________________________________________ > 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 thestrider at gmail.com Tue Jul 1 12:17:06 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 05:17:06 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A1D64.8070305@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> <486A19E0.8010103@ng23.net> <486A1D64.8070305@gmail.com> Message-ID: <486A2042.3000304@gmail.com> Adam Rosenwald wrote: > Tom Brown wrote: >> >>> OK. Something is definitely missing here. Notice how >>> (http://www.redhat.com/magazine/024oct06/features/kickstart/) GRUB >>> contains options for setting the IP address, netmask, and gateway >>> for the system you intend to boot. These arguments are /*not*/ set >>> in /your/ grub configuration. As to why they are not, either you >>> didn't specify them during your cobbler system provisioning OR there >>> is some kind of a bug in koan's 'reprovision' logic. Likely the >>> former. Please double check that you specified >>> >>> cobbler .... --ip=X --subnet=Y --gateway=Z ... >>> >>> in your provision command. >>> >> >> # cobbler system report --name=xxxxxx >> system : xxxxxx >> profile : RHEL4-u5-i386-prd >> kernel options : {} >> kickstart : <> >> ks metadata : {'nameserver': '10.xxx.xxx.117'} >> netboot enabled? : True >> owners : ['admin'] >> server : <> >> virt cpus : <> >> virt file size : <> >> virt path : <> >> virt ram : <> >> virt type : <> >> interface : intf0 >> mac address : 00:13:72:69:95:7E >> ip address : 10.xxx.xxx.19 >> hostname : xxxxxx >> gateway : 10.xxx.xxx.253 >> subnet : 255.255.254.0 >> virt bridge : >> dhcp tag : >> >> that seems fine to me? >> >> and the koan version on the client >> >> # rpm -qa | grep koan >> koan-1.0.0-1.el4 >> >> thanks for any further info > OK... good. If you could try to do so, please reprovision your system > with the following amendment: > > * cobbler ... --kopts='ip=10.xxx.xxx.19 netmask=255.255.254.0 > gateway=10.xxx.xxx.253 dns=10.xxx.xxx.117' ... > > Resync and see if the new grub file installed after koaning looks the > part. > > -A. Sorry. You could have also overridden the kernel options in koan itself: * koan ... --kopts='ip=10.xxx.xxx.19 netmask=255.255.254.0 gateway=10.xxx.xxx.253 dns=10.xxx.xxx.117' Basically koan doesn't make use of the cobbler's own --ip, --gateway, --subnet variables when interfacing with grubby to create the grub config file; rather it /only/ makes use of --kopts. This is rather nonintuitive, and it's difficult for me to think of a situation where one is attempting to reprovision (via koan --replace-self) a system, yet not want import those cobbler dictionary values (ip, subnet, etc.) into grub kernel arguments. Then, there is the problem of precedence: do --ip, --subnet, etc. override --kopts='ip=... netmask=...' if both are declared? Or vice versa? This is a policy decision which Michael shouldn't have to worry about enforcing. Rather, it may be more relevant to update the cobbler wiki under 'koan replace-self procedure'. -A. >> >> >> _______________________________________________ >> 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 tom at ng23.net Tue Jul 1 12:49:48 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 13:49:48 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A2042.3000304@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> <486A19E0.8010103@ng23.net> <486A1D64.8070305@gmail.com> <486A2042.3000304@gmail.com> Message-ID: <486A27EC.8030506@ng23.net> > Sorry. You could have also overridden the kernel options in koan itself: > > * koan ... --kopts='ip=10.xxx.xxx.19 netmask=255.255.254.0 > gateway=10.xxx.xxx.253 dns=10.xxx.xxx.117' > > Basically koan doesn't make use of the cobbler's own --ip, --gateway, > --subnet variables when interfacing with grubby to create the grub > config file; rather it /only/ makes use of --kopts. This is rather > nonintuitive, and it's difficult for me to think of a situation where > one is attempting to reprovision (via koan --replace-self) a system, > yet not want import those cobbler dictionary values (ip, subnet, etc.) > into grub kernel arguments. > > Then, there is the problem of precedence: do --ip, --subnet, etc. > override --kopts='ip=... netmask=...' if both are declared? Or vice > versa? This is a policy decision which Michael shouldn't have to > worry about enforcing. Rather, it may be more relevant to update the > cobbler wiki under 'koan replace-self procedure'. > OK to confirm in my own mind ;) You need to add network info to both the cobbler variables and also ksmeta variables at system configuration time in order to get the replace-self to work correctly? thanks From thestrider at gmail.com Tue Jul 1 13:04:13 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 06:04:13 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A27EC.8030506@ng23.net> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> <486A19E0.8010103@ng23.net> <486A1D64.8070305@gmail.com> <486A2042.3000304@gmail.com> <486A27EC.8030506@ng23.net> Message-ID: <486A2B4D.6030505@gmail.com> Tom Brown wrote: > >> Sorry. You could have also overridden the kernel options in koan >> itself: >> >> * koan ... --kopts='ip=10.xxx.xxx.19 netmask=255.255.254.0 >> gateway=10.xxx.xxx.253 dns=10.xxx.xxx.117' >> >> Basically koan doesn't make use of the cobbler's own --ip, --gateway, >> --subnet variables when interfacing with grubby to create the grub >> config file; rather it /only/ makes use of --kopts. This is rather >> nonintuitive, and it's difficult for me to think of a situation where >> one is attempting to reprovision (via koan --replace-self) a system, >> yet not want import those cobbler dictionary values (ip, subnet, >> etc.) into grub kernel arguments. >> >> Then, there is the problem of precedence: do --ip, --subnet, etc. >> override --kopts='ip=... netmask=...' if both are declared? Or vice >> versa? This is a policy decision which Michael shouldn't have to >> worry about enforcing. Rather, it may be more relevant to update the >> cobbler wiki under 'koan replace-self procedure'. >> > > > OK to confirm in my own mind ;) > > You need to add network info to both the cobbler variables and also > ksmeta variables at system configuration time in order to get the > replace-self to work correctly? No. You need to do specify the kopts variables on either the cobbler end or the koan end. * cobbler ... --kopts='' or * koan ... --kopts='' FYI, -A. > > thanks > > > _______________________________________________ > 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 tom at ng23.net Tue Jul 1 13:12:11 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 14:12:11 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A2B4D.6030505@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> <486A19E0.8010103@ng23.net> <486A1D64.8070305@gmail.com> <486A2042.3000304@gmail.com> <486A27EC.8030506@ng23.net> <486A2B4D.6030505@gmail.com> Message-ID: <486A2D2B.1040509@ng23.net> > No. You need to do specify the kopts variables on either the cobbler > end or the koan end. > > * cobbler ... --kopts='' > > or > > * koan ... --kopts='' > > FYI, > yes - i wrote ksmeta but meant kopts - my bad there, now i have more of a scripting question To add a system i have a script that i pass some args to and it looks like this cobbler system add --name=$1 --mac=$2 --hostname=$1 --ip=$3 --subnet=$4 --gateway=$5 --ksmeta="nameserver=10.xxx.xxx.117" --profile=$6 works fine and by 'scraping' that info from machines currently running i can automate the process of adding systems. A typical use of this script i call 'buildbox' would be buildbox xxxxxx 00:13:72:69:95:7E 10.xxx.xxx.19 255.255.254.0 10.xxx.xxx.253 RHEL4-u5-i386-prd This works like a charm and adds machines - however when i add the following... cobbler system add --name=$1 --mac=$2 --hostname=$1 --ip=$3 --subnet=$4 --gateway=$5 --ksmeta="nameserver=10.168.86.117" --profile=$6 --kopts='ip=$3 netmask=$4 gateway=$5 dns=10.xxx.xxx.117' the 'ksopts' bits just end up as $3, $4 etc and not their actual value - Can anyone offer me a hint here thanks From thestrider at gmail.com Tue Jul 1 13:17:02 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 06:17:02 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A2D2B.1040509@ng23.net> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> <486A19E0.8010103@ng23.net> <486A1D64.8070305@gmail.com> <486A2042.3000304@gmail.com> <486A27EC.8030506@ng23.net> <486A2B4D.6030505@gmail.com> <486A2D2B.1040509@ng23.net> Message-ID: <486A2E4E.9040709@gmail.com> Try double quotes instead of single quotes. :) Tom Brown wrote: > >> No. You need to do specify the kopts variables on either the cobbler >> end or the koan end. >> >> * cobbler ... --kopts='' >> >> or >> >> * koan ... --kopts='' >> >> FYI, >> > > yes - i wrote ksmeta but meant kopts - my bad there, now i have more > of a scripting question > > To add a system i have a script that i pass some args to and it looks > like this > > cobbler system add --name=$1 --mac=$2 --hostname=$1 --ip=$3 > --subnet=$4 --gateway=$5 --ksmeta="nameserver=10.xxx.xxx.117" > --profile=$6 > > works fine and by 'scraping' that info from machines currently running > i can automate the process of adding systems. > > A typical use of this script i call 'buildbox' would be > > buildbox xxxxxx 00:13:72:69:95:7E 10.xxx.xxx.19 255.255.254.0 > 10.xxx.xxx.253 RHEL4-u5-i386-prd > > This works like a charm and adds machines - however when i add the > following... > > cobbler system add --name=$1 --mac=$2 --hostname=$1 --ip=$3 > --subnet=$4 --gateway=$5 --ksmeta="nameserver=10.168.86.117" > --profile=$6 --kopts='ip=$3 netmask=$4 gateway=$5 dns=10.xxx.xxx.117' > > the 'ksopts' bits just end up as $3, $4 etc and not their actual value - > > Can anyone offer me a hint here > > thanks > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From tom at ng23.net Tue Jul 1 13:28:07 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 14:28:07 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A2E4E.9040709@gmail.com> References: <486A04F3.4040906@ng23.net> <486A0C7F.6040002@gmail.com> <486A0DEE.4090801@ng23.net> <486A12EB.4080206@gmail.com> <486A1496.1010302@ng23.net> <486A186A.4090500@gmail.com> <486A19E0.8010103@ng23.net> <486A1D64.8070305@gmail.com> <486A2042.3000304@gmail.com> <486A27EC.8030506@ng23.net> <486A2B4D.6030505@gmail.com> <486A2D2B.1040509@ng23.net> <486A2E4E.9040709@gmail.com> Message-ID: <486A30E7.3090300@ng23.net> > Try double quotes instead of single quotes. :) > looks like we have a winner! thanks - also my boxes are now rebuilding using koan and no DHCP ir PXE in sight ;) personally a feature request for koan would be to inherit these values but adding them on the end of my script also works it just seems a bit excessive. thanks From smooge at gmail.com Tue Jul 1 14:05:21 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 1 Jul 2008 08:05:21 -0600 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A04F3.4040906@ng23.net> References: <486A04F3.4040906@ng23.net> Message-ID: <80d7e4090807010705o25b9d962k2abc90b1a70ba4a6@mail.gmail.com> On Tue, Jul 1, 2008 at 4:20 AM, Tom Brown wrote: > Hi > > I cant use DHCP yet in my prd environment but i can use koan so i can have > cobbler rebuild existing hosts. > > I have setup a cobbler server and added a test system to that but i > encounter an issue when i try and build using koan in that after the client > reboots and boots the 'kick' kernel it seems unable to get the kickstart as > it starts to ask me which ethernet card to use and also then tries to do a > DHCP request. > Which OS are you trying to replace it with? There are a couple of possible items: 1) The ethernet card is not detected easily.. or you have multiple cards and it could not contact the cobbler server so it tried to probe for other ethernet systems. Our Dell 2950's have this problem.. on installation eth0 is eth1 and vice versa. > If i hit the URL that generates the kickstart it seems fine and the network > part looks like this apart from the xxxxxx and the 'cobbler.server' hostname > > # Use network installation > url --url=http://cobbler.server/cblr/links/RHEL4-u5-i386 > # Network information > network --bootproto=static --device=eth0 --onboot=on --ip=10.xxx.xxx.19 > --netmask=255.255.254.0 --gateway=10.xxx.xxx.253 > --nameserver=10.xxx.xxx.117 --hostname=xxxxxxxx > > In the grub config on the client before i reboot i see this > > title kick1214906905 > root (hd0,0) > kernel /vmlinuz ro root=LABEL=/ > ks=http://cobbler.server/cblr/svc/op/ks/system/xxxxxxxx > initrd /initrd.img > > and the 'cobbler.server' can be resolved from the client using the correct > nameserver - > > Does anyone have any ideas whats going on as i am stuck? > > thanks > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tom at ng23.net Tue Jul 1 14:23:58 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 15:23:58 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <80d7e4090807010705o25b9d962k2abc90b1a70ba4a6@mail.gmail.com> References: <486A04F3.4040906@ng23.net> <80d7e4090807010705o25b9d962k2abc90b1a70ba4a6@mail.gmail.com> Message-ID: <486A3DFE.20102@ng23.net> > > Which OS are you trying to replace it with? There are a couple of > possible items: > > 1) The ethernet card is not detected easily.. or you have multiple > cards and it could not contact the cobbler server so it tried to probe > for other ethernet systems. Our Dell 2950's have this problem.. on > installation eth0 is eth1 and vice versa. > > thanks - i have resolved this by using a non broken version of koan and adding ksopts to the cobbler creation line thanks From mdehaan at redhat.com Tue Jul 1 14:44:16 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 10:44:16 -0400 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A04F3.4040906@ng23.net> References: <486A04F3.4040906@ng23.net> Message-ID: <486A42C0.1030809@redhat.com> > > > In the grub config on the client before i reboot i see this > > title kick1214906905 > root (hd0,0) > kernel /vmlinuz ro root=LABEL=/ > ks=http://cobbler.server/cblr/svc/op/ks/system/xxxxxxxx > initrd /initrd.img > Hi Tom, The latest stable version of koan is 1.0.1, cobbler is 1.0.2. You should upgrade as this includes the fix for the above problem with the missing kernel options. You should be pulling from EPEL testing or the Fedora repos, if you have access to neither, see http://cobbler.et.redhat.com/download. --Michael From levon at movementarian.org Tue Jul 1 14:50:35 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 15:50:35 +0100 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <20080701110508.GD11280@redhat.com> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> <20080701034847.GB31574@totally.trollied.org.uk> <20080701084906.GA11280@redhat.com> <486A0E8D.8070205@redhat.com> <20080701110508.GD11280@redhat.com> Message-ID: <20080701145035.GA1020@totally.trollied.org.uk> On Tue, Jul 01, 2008 at 12:05:08PM +0100, Daniel P. Berrange wrote: > > Will the sniffing work for anything but vmware files? I rather it be > > explicit in all cases unless we can infer them all. > > Yes, there is magic header that lets you detect pretty much all types > of disk image file - see the 'qemu-img' command. The disk stuff is OK, but the config file is maybe a little harder. vmware is easy, as is libvirt. Old-style .py files is even possible, probably. When is this stuff hitting a repo? I'm particularly interested in the libvirt-domain style output and making the necessary changes as I describe above. regards john From mdehaan at redhat.com Tue Jul 1 14:54:38 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 10:54:38 -0400 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A42C0.1030809@redhat.com> References: <486A04F3.4040906@ng23.net> <486A42C0.1030809@redhat.com> Message-ID: <486A452E.90808@redhat.com> Michael DeHaan wrote: > >> >> >> In the grub config on the client before i reboot i see this >> >> title kick1214906905 >> root (hd0,0) >> kernel /vmlinuz ro root=LABEL=/ >> ks=http://cobbler.server/cblr/svc/op/ks/system/xxxxxxxx >> initrd /initrd.img >> > > Hi Tom, > > The latest stable version of koan is 1.0.1, cobbler is 1.0.2. You > should upgrade as this includes the fix for the above problem with the > missing kernel options. > > You should be pulling from EPEL testing or the Fedora repos, if you > have access to neither, see http://cobbler.et.redhat.com/download. > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I don't know how to expand threads, apparently :) Glad this is already resolved. From tom at ng23.net Tue Jul 1 14:59:01 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 15:59:01 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A452E.90808@redhat.com> References: <486A04F3.4040906@ng23.net> <486A42C0.1030809@redhat.com> <486A452E.90808@redhat.com> Message-ID: <486A4635.4040507@ng23.net> > > I don't know how to expand threads, apparently :) > > Glad this is already resolved. > > > it is yes thanks - although any opinion in inheriting those values from cobbler into koan? From mdehaan at redhat.com Tue Jul 1 15:07:39 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 11:07:39 -0400 Subject: [et-mgmt-tools] Seperate mailing lists revisited? Message-ID: <486A483B.1070003@redhat.com> With Cobbler, virsh, and virt-manager both getting a lot of traffic now (which is great!), I'm thinking we might want to revisit the idea of having seperate mailing lists. Other similar projects like ovirt/func/etc have seperate lists, for instance. By default we could auto-invite everyone here to the new cobbler list, but we would not auto-subscribe everyone because that may not be desired. Thoughts? --Michael From mdehaan at redhat.com Tue Jul 1 15:10:25 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 11:10:25 -0400 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A4635.4040507@ng23.net> References: <486A04F3.4040906@ng23.net> <486A42C0.1030809@redhat.com> <486A452E.90808@redhat.com> <486A4635.4040507@ng23.net> Message-ID: <486A48E1.1060800@redhat.com> Tom Brown wrote: > >> >> I don't know how to expand threads, apparently :) >> >> Glad this is already resolved. >> >> >> > > it is yes thanks - although any opinion in inheriting those values > from cobbler into koan? > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Hmm, I'm not sure I understand the question. All kernel options given to cobbler settings, distros, profiles, and systems end up used by koan. Can you elaborate? --Michael From tom at ng23.net Tue Jul 1 15:13:16 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 16:13:16 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A48E1.1060800@redhat.com> References: <486A04F3.4040906@ng23.net> <486A42C0.1030809@redhat.com> <486A452E.90808@redhat.com> <486A4635.4040507@ng23.net> <486A48E1.1060800@redhat.com> Message-ID: <486A498C.6070104@ng23.net> > > Hmm, I'm not sure I understand the question. All kernel options > given to cobbler settings, distros, profiles, and systems end up used > by koan. > > Can you elaborate? > > on a rebuild IP, mask and gateway info thats in cobbler does not get pulled by koan and inserted onto the grub command line unless you specify the --kopts when you provision a system or hand it to koan at the rebuild time. Rather than having to add --kopts to cobbler during provision cant the values already given be used? thanks From swissslinky at gmail.com Tue Jul 1 15:16:43 2008 From: swissslinky at gmail.com (Slinky) Date: Tue, 1 Jul 2008 17:16:43 +0200 Subject: [et-mgmt-tools] Seperate mailing lists revisited? In-Reply-To: <486A483B.1070003@redhat.com> References: <486A483B.1070003@redhat.com> Message-ID: +1 for separate list. 2008/7/1 Michael DeHaan : > With Cobbler, virsh, and virt-manager both getting a lot of traffic now > (which is great!), I'm thinking we might want to revisit the idea of having > seperate mailing lists. Other similar projects like ovirt/func/etc have > seperate lists, for instance. > > By default we could auto-invite everyone here to the new cobbler list, but > we would not auto-subscribe everyone because that may not be desired. > > Thoughts? > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.concilio at gmail.com Tue Jul 1 15:22:44 2008 From: matteo.concilio at gmail.com (Matteo Concilio) Date: Tue, 1 Jul 2008 17:22:44 +0200 Subject: [et-mgmt-tools] Seperate mailing lists revisited? In-Reply-To: <486A483B.1070003@redhat.com> References: <486A483B.1070003@redhat.com> Message-ID: <1270e2cb0807010822y3bdeb195yb2608819654adc41@mail.gmail.com> 2008/7/1 Michael DeHaan : > I'm thinking we might want to revisit the idea of having seperate mailing lists. Good idea > By default we could auto-invite everyone here to the new cobbler list, > but we would not auto-subscribe everyone because that may not be desired. Beautiful idea. -- Matteo Concilio From mdehaan at redhat.com Tue Jul 1 15:29:54 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 11:29:54 -0400 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A498C.6070104@ng23.net> References: <486A04F3.4040906@ng23.net> <486A42C0.1030809@redhat.com> <486A452E.90808@redhat.com> <486A4635.4040507@ng23.net> <486A48E1.1060800@redhat.com> <486A498C.6070104@ng23.net> Message-ID: <486A4D72.305@redhat.com> Tom Brown wrote: > >> >> Hmm, I'm not sure I understand the question. All kernel options >> given to cobbler settings, distros, profiles, and systems end up used >> by koan. >> >> Can you elaborate? >> >> > > on a rebuild IP, mask and gateway info thats in cobbler does not get > pulled by koan and inserted onto the grub command line unless you > specify the --kopts when you provision a system or hand it to koan at > the rebuild time. If you have those variables stored on the system object's --kopts, you just invoke koan as: koan --server=cobbler.example.org --replace-self --system=this_system_name If the mac address is in Cobbler, it's smart enough to auto-find the system, so you can just do: koan --server=cobbler.example.org --replace-self I think what you're saying is if the network parameters are not in --kopts, but are stored on the interface, they don't show up in --kopts. This is true. Before we used to have a parameter to auto-discover the network details from the local system and append them to the kernel options line to eliminate DHCP, however due to some python version incompatibilies we had to remove that feature. If that is interesting, this is something that we could work on cleaning up and adding back. Another option would be to add in support for just using the IP info in cobbler and adding /that/ to --kopts implicitly. Perhaps this would look like: koan --server=cobbler.example.org --replace-self --use-static-interface=0 All of these problems of course go away when you have DHCP :) --Michael From tom at ng23.net Tue Jul 1 15:34:26 2008 From: tom at ng23.net (Tom Brown) Date: Tue, 01 Jul 2008 16:34:26 +0100 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A4D72.305@redhat.com> References: <486A04F3.4040906@ng23.net> <486A42C0.1030809@redhat.com> <486A452E.90808@redhat.com> <486A4635.4040507@ng23.net> <486A48E1.1060800@redhat.com> <486A498C.6070104@ng23.net> <486A4D72.305@redhat.com> Message-ID: <486A4E82.2070300@ng23.net> > > If you have those variables stored on the system object's --kopts, you > just invoke koan as: > > koan --server=cobbler.example.org --replace-self > --system=this_system_name > > If the mac address is in Cobbler, it's smart enough to auto-find the > system, so you can just do: > > koan --server=cobbler.example.org --replace-self > > I think what you're saying is if the network parameters are not in > --kopts, but are stored on the interface, they don't show up in --kopts. > This is true. > > Before we used to have a parameter to auto-discover the network > details from the local system and append them to the kernel options > line to eliminate DHCP, however due to some python version > incompatibilies we had to remove that feature. If that is > interesting, this is something that we could work on cleaning up and > adding back. > > Another option would be to add in support for just using the IP info > in cobbler and adding /that/ to --kopts implicitly. > > Perhaps this would look like: > > koan --server=cobbler.example.org --replace-self --use-static-interface=0 > > All of these problems of course go away when you have DHCP :) you have hit the nail on the head and also why this used to 'work' but seemed to stop working for me when i installed another cobbler server in a network where DHCP is a big no-no (but thats another thing i'm working an angle on ;)) the feature of auto-appending the network details was nice to have but personally using the IP info available to cobbler and just adding that implicitly to -kopts would be the way to go, thats how i have solved this issue for me by adding a bit to a script but it would be nice if it did this by default. IMHO From jeckersb at redhat.com Tue Jul 1 15:45:21 2008 From: jeckersb at redhat.com (John Eckersberg) Date: Tue, 01 Jul 2008 11:45:21 -0400 Subject: [et-mgmt-tools] Seperate mailing lists revisited? In-Reply-To: <486A483B.1070003@redhat.com> References: <486A483B.1070003@redhat.com> Message-ID: <486A5111.9060808@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael DeHaan wrote: | With Cobbler, virsh, and virt-manager both getting a lot of traffic now | (which is great!), I'm thinking we might want to revisit the idea of | having seperate mailing lists. Other similar projects like | ovirt/func/etc have seperate lists, for instance. | | By default we could auto-invite everyone here to the new cobbler list, | but we would not auto-subscribe everyone because that may not be desired. | | Thoughts? | | --Michael | | _______________________________________________ | et-mgmt-tools mailing list | et-mgmt-tools at redhat.com | https://www.redhat.com/mailman/listinfo/et-mgmt-tools Yes separate lists would be nice. - -- John Eckersberg Production Operations Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhqUREACgkQO5VSO/Qqm+iSNwCdG6vDSM5XEZ4k+DKyCkZheCRN 2F8AoLBmFAt7wVMGM4Qx9xKbcNyutXmT =CsWr -----END PGP SIGNATURE----- From thestrider at gmail.com Tue Jul 1 15:47:06 2008 From: thestrider at gmail.com (Adam Rosenwald) Date: Tue, 01 Jul 2008 08:47:06 -0700 Subject: [et-mgmt-tools] cobbler-1.0.1-2 - build problem using koan In-Reply-To: <486A4D72.305@redhat.com> References: <486A04F3.4040906@ng23.net> <486A42C0.1030809@redhat.com> <486A452E.90808@redhat.com> <486A4635.4040507@ng23.net> <486A48E1.1060800@redhat.com> <486A498C.6070104@ng23.net> <486A4D72.305@redhat.com> Message-ID: <486A517A.5080205@gmail.com> Michael DeHaan wrote: > Tom Brown wrote: >> >>> >>> Hmm, I'm not sure I understand the question. All kernel options >>> given to cobbler settings, distros, profiles, and systems end up >>> used by koan. >>> >>> Can you elaborate? >>> >>> >> >> on a rebuild IP, mask and gateway info thats in cobbler does not get >> pulled by koan and inserted onto the grub command line unless you >> specify the --kopts when you provision a system or hand it to koan at >> the rebuild time. > > If you have those variables stored on the system object's --kopts, you > just invoke koan as: > > koan --server=cobbler.example.org --replace-self > --system=this_system_name > > If the mac address is in Cobbler, it's smart enough to auto-find the > system, so you can just do: > > koan --server=cobbler.example.org --replace-self > > I think what you're saying is if the network parameters are not in > --kopts, but are stored on the interface, they don't show up in --kopts. > This is true. > > Before we used to have a parameter to auto-discover the network > details from the local system and append them to the kernel options > line to eliminate DHCP, however due to some python version > incompatibilies we had to remove that feature. If that is > interesting, this is something that we could work on cleaning up and > adding back. > > Another option would be to add in support for just using the IP info > in cobbler and adding /that/ to --kopts implicitly. > > Perhaps this would look like: > > koan --server=cobbler.example.org --replace-self --use-static-interface=0 > > All of these problems of course go away when you have DHCP :) > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > What about auto-discovery of IP, netmask, gateway when explicitly performing a koan --replace-self operation? The discovered values can then be appended to and/or override the koan kopts string. This seems like the most logical approach, given that this is needed only when not using dhcp. -A. From mdehaan at redhat.com Tue Jul 1 15:50:08 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 11:50:08 -0400 Subject: [et-mgmt-tools] Seperate mailing lists revisited? In-Reply-To: <486A5111.9060808@redhat.com> References: <486A483B.1070003@redhat.com> <486A5111.9060808@redhat.com> Message-ID: <486A5230.7030308@redhat.com> John Eckersberg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael DeHaan wrote: > | With Cobbler, virsh, and virt-manager both getting a lot of traffic now > | (which is great!), I'm thinking we might want to revisit the idea of > | having seperate mailing lists. Other similar projects like > | ovirt/func/etc have seperate lists, for instance. > | > | By default we could auto-invite everyone here to the new cobbler list, > | but we would not auto-subscribe everyone because that may not be > desired. > | > | Thoughts? > | > | --Michael > | > | _______________________________________________ > | et-mgmt-tools mailing list > | et-mgmt-tools at redhat.com > | https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > Yes separate lists would be nice. > > - -- > John Eckersberg > Production Operations > Red Hat, Inc. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkhqUREACgkQO5VSO/Qqm+iSNwCdG6vDSM5XEZ4k+DKyCkZheCRN > 2F8AoLBmFAt7wVMGM4Qx9xKbcNyutXmT > =CsWr > -----END PGP SIGNATURE----- > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I will make it so. Details TBD. From crobinso at redhat.com Tue Jul 1 16:38:08 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 01 Jul 2008 12:38:08 -0400 Subject: [et-mgmt-tools] [PATCH 2 of 2] Added a --replace option to virt-image which allows it to replace an existing machine if it is current running or defined In-Reply-To: References: Message-ID: <486A5D70.1050803@redhat.com> "Bryan M. Kearney "@redhat.com wrote: > # HG changeset patch > # User "Bryan M. Kearney " > # Date 1214497967 14400 > # Node ID efba908eb79ad0bf2805c27f784de92578207f1b > # Parent 63aca2dbb3154a65505b1ccef080a8887742cef5 > Added a --replace option to virt-image which allows it to replace an existing machine if it is current running or defined > > diff -r 63aca2dbb315 -r efba908eb79a virt-image > --- a/virt-image Tue Jun 24 12:30:24 2008 -0400 > +++ b/virt-image Thu Jun 26 12:32:47 2008 -0400 > @@ -142,7 +142,10 @@ def parse_args(): > help=_("The zero-based index of the boot record to use")) > parser.add_option("", "--force", action="store_true", dest="force", > help=_("Do not prompt for input. Answers yes where applicable, terminates for all other prompts"), > - default=False) > + default=False) > + parser.add_option("", "--replace",action="store_true", dest="replace", > + help=_("Overwrite, or destroy, an existing image with the same name"), > + default=False) > > (options,args) = parser.parse_args() > if len(args) < 1: > @@ -211,7 +214,7 @@ def main(): > try: > print _("\n\nCreating guest %s...") % guest.name > > - dom = guest.start_install(None, progresscb) > + dom = guest.start_install(None, progresscb, options.replace) > if dom is None: > print _("Guest creation failed") > sys.exit(1) > diff -r 63aca2dbb315 -r efba908eb79a virtinst/Guest.py > --- a/virtinst/Guest.py Tue Jun 24 12:30:24 2008 -0400 > +++ b/virtinst/Guest.py Thu Jun 26 12:32:47 2008 -0400 > @@ -914,7 +914,7 @@ class Guest(object): > "action": action } > > > - def start_install(self, consolecb = None, meter = None): > + def start_install(self, consolecb = None, meter = None, removeOld = False): > """Do the startup of the guest installation.""" > self.validate_parms() > > @@ -924,7 +924,7 @@ class Guest(object): > > self._prepare_install(meter) > try: > - return self._do_install(consolecb, meter) > + return self._do_install(consolecb, meter, removeOld) > finally: > self._installer.cleanup() > > @@ -932,10 +932,20 @@ class Guest(object): > self._install_disks = self.disks[:] > self._install_nics = self.nics[:] > > - def _do_install(self, consolecb, meter): > + def _do_install(self, consolecb, meter, removeOld = False): > try: > - if self.conn.lookupByName(self.name) is not None: > - raise RuntimeError, _("Domain named %s already exists!") %(self.name,) > + vm = self.conn.lookupByName(self.name) > + if removeOld: > + if vm is not None: > + if vm.ID() == -1: > + logging.info("Removing old definition for image %s" %(self.name)) > + vm.undefine() > + else: > + logging.info("Destroying image %s" %(self.name)) > + vm.destroy() > + else: > + if vm is not None: > + raise RuntimeError, _("Domain named %s already exists!") %(self.name,) > except libvirt.libvirtError: > pass > Hmm, just looking at this again, and the exception handling can throw away some important info. You'll want to throw away the libvirtError from the lookupByName call only: if destroy or undefine fail, the install should fail, raising the exception and giving a nicer message such as "Couldn't destroy/undefine existing vm 'vmname': %s" str(e)" Also, could you combine the two patches into one? It will just make reviewing easier :) Thanks, Cole From crobinso at redhat.com Tue Jul 1 16:45:02 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 01 Jul 2008 12:45:02 -0400 Subject: [et-mgmt-tools] [PATCH] convert vmware machines to virt-image xml format In-Reply-To: <20080701145035.GA1020@totally.trollied.org.uk> References: <4863A716.2050202@redhat.com> <4863A86B.5080403@redhat.com> <20080701023223.GA31574@totally.trollied.org.uk> <1214882095.3368.73.camel@localhost.localdomain> <20080701034847.GB31574@totally.trollied.org.uk> <20080701084906.GA11280@redhat.com> <486A0E8D.8070205@redhat.com> <20080701110508.GD11280@redhat.com> <20080701145035.GA1020@totally.trollied.org.uk> Message-ID: <486A5F0E.8080601@redhat.com> John Levon wrote: > On Tue, Jul 01, 2008 at 12:05:08PM +0100, Daniel P. Berrange wrote: > >>> Will the sniffing work for anything but vmware files? I rather it be >>> explicit in all cases unless we can infer them all. >> Yes, there is magic header that lets you detect pretty much all types >> of disk image file - see the 'qemu-img' command. > > The disk stuff is OK, but the config file is maybe a little harder. > vmware is easy, as is libvirt. Old-style .py files is even possible, > probably. > > When is this stuff hitting a repo? I'm particularly interested in the > libvirt-domain style output and making the necessary changes as I > describe above. > > regards > john > I just committed the posted code as is (virt-unpack). http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=7e907d31aaa6 Also, if we move virt-unpack to virt-convert we will want to combine the also recently committed virt-pack into this as well. Thanks, Cole From mdehaan at redhat.com Tue Jul 1 17:20:06 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 13:20:06 -0400 Subject: [et-mgmt-tools] who NoPassRequired Message-ID: <486A6746.3000007@redhat.com> From mdehaan at redhat.com Tue Jul 1 17:39:10 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 13:39:10 -0400 Subject: [et-mgmt-tools] New mailing list for Cobbler Message-ID: <486A6BBE.20109@redhat.com> Hello everyone, In interest of keeping things organized here, I've created a seperate mailing list for Cobbler at cobbler at lists.fedorahosted.org -- this will be a combined users and developers list. Those asking Cobbler questions here will be kindly directed to the new list. If you would like to subscribe (subscription is required for posting, you can do so here): https://fedorahosted.org/mailman/listinfo/cobbler If you are already subscribed to et-mgmt-tools directly, you should recieve an invite for the new list. If you don't recieve one, you can still subscribe using the link above. et-mgmt-tools subscribers are /not/ automatically subscribed to this new list, so please make sure you subscribe if you are interested in Cobbler and koan. If you're reading by another aggregator, adding the new list to the said aggegrators would be much appreciated :) Thanks! --Michael From drew.einhorn at gmail.com Tue Jul 1 17:37:05 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 1 Jul 2008 11:37:05 -0600 Subject: [et-mgmt-tools] Cobbler on Xen Message-ID: Is there a guide to getting started with cobbler on xen? I just started bozoing around, didn't have much luck. Then I realized the difference between running on boxes with hardware virtualization support, and those without. The first box I tried requires paravirtualization, and probably requires a more complicated setup, I'm still working through that issue. Some of my questions will veer off topic but I think think they will still be within the expertise of folks who hang around here. First, where do you recommend running the cobbler server? On the dom0 vm, or in a separate domU vm? In either case, is there anything else you would recommend running in the same vm as cobbler? Any selinux issues? There is a setroubleshoot page that runs under X, that really makes it a lot easier to troubleshoot selinux, but I really don't want to run X on all my vms. Does anyone here know of an equivalent that doesn't require X? -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Jul 1 18:02:43 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Jul 2008 14:02:43 -0400 Subject: [et-mgmt-tools] Cobbler on Xen In-Reply-To: References: Message-ID: <486A7143.7080207@redhat.com> drew einhorn wrote: I'll field this one as the new cobbler list is just a few minutes old :) > Is there a guide to getting started with cobbler on xen? > > I just started bozoing around, didn't have much luck. > Then I realized the difference between running on > boxes with hardware virtualization support, and those > without. The first box I tried requires paravirtualization, > and probably requires a more complicated setup, I'm > still working through that issue. Paravirt is actually easier. Cobbler import some EL or Fedora trees, and do man "koan" to see how koan works. > > Some of my questions will veer off topic but I think think > they will still be within the expertise of folks who hang > around here. > > First, where do you recommend running the cobbler > server? On the dom0 vm, or in a separate domU vm? I personally install it on dom0, as it's fairly base level infrastructure. Frequently on the same box as DHCP and DNS as it can help manage those. > > In either case, is there anything else you would recommend > running in the same vm as cobbler? DHCP and DNS, TFTP (required for netboot), Apache (required), ... Pretty much anythign you want. > > Any selinux issues? There is a setroubleshoot page that > runs under X, that really makes it a lot easier to troubleshoot > selinux, but I really don't want to run X on all my vms. There shouldn't be any. Cobbler is written to play nice with selinux, and if you run with selinux on, cobbler check will let you know about some common booleans you need to change (in 1.0.2). > > Does anyone here know of an equivalent that doesn't > require X? I don't, but these guys probably do know: http://www.redhat.com/mailman/listinfo/fedora-selinux-list audit2allow and such are command line based, though with cobbler it's largely about setting up the booleans that cobbler check will let you know about. Shouldn't be any more than that. --Michael From levon at movementarian.org Tue Jul 1 19:23:55 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:23:55 +0100 Subject: [et-mgmt-tools] [PATCH] Extend virt-unpack options Message-ID: <20080701192355.GD11119@totally.trollied.org.uk> Extend virt-unpack options Fix up virt-unpack options to allow both input and output directories, and formats other than vmx->virt-image. This is just the first step of moving towards virt-convert. Signed-off-by: John Levon diff --git a/man/en/virt-unpack.1 b/man/en/virt-unpack.1 --- a/man/en/virt-unpack.1 +++ b/man/en/virt-unpack.1 @@ -1,4 +1,4 @@ -.\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.05) +.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32 .\" .\" Standard preamble: .\" ======================================================================== @@ -25,11 +25,11 @@ .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left -.\" double quote, and \*(R" will give a right double quote. \*(C+ will -.\" give a nicer C++. Capital omega is used to do unbreakable dashes and -.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, -.\" nothing in troff, for use with C<>. -.tr \(*W- +.\" double quote, and \*(R" will give a right double quote. | will give a +.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to +.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' +.\" expand to `' in nroff, nothing in troff, for use with C<>. +.tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- @@ -48,25 +48,22 @@ . ds R" '' 'br\} .\" -.\" Escape single quotes in literal strings from groff's Unicode transform. -.ie \n(.g .ds Aq \(aq -.el .ds Aq ' -.\" .\" If the F register is turned on, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. -.ie \nF \{\ +.if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . nr % 0 . rr F .\} -.el \{\ -. de IX -.. -.\} +.\" +.\" For nroff, turn off justification. Always turn off hyphenation; it makes +.\" way too many mistakes in technical documents. +.hy 0 +.if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. @@ -132,42 +129,51 @@ .\" ======================================================================== .\" .IX Title "VIRT-UNPACK 1" -.TH VIRT-UNPACK 1 "2008-07-01" "perl v5.10.0" "User Contributed Perl Documentation" -.\" For nroff, turn off justification. Always turn off hyphenation; it makes -.\" way too many mistakes in technical documents. -.if n .ad l -.nh +.TH VIRT-UNPACK 1 "2008-07-01" "perl v5.8.8" "Virtual Machine Install Tools" .SH "NAME" -virt\-unpack \- convert virtual machines from VMware(tm) format into an xml image descriptor +virt\-unpack \- convert virtual machines between formats .SH "SYNOPSIS" .IX Header "SYNOPSIS" -\&\fBvirt-unpack\fR [\s-1OPTION\s0]... \s-1IMAGE\s0.VMX +\&\fBvirt-unpack\fR [\s-1OPTION\s0]... \s-1INPUT\s0.VMX|INPUT\-DIR [\s-1OUTPUT\s0.XML|OUTPUT\-DIR] .SH "DESCRIPTION" .IX Header "DESCRIPTION" -\&\fBvirt-unpack\fR is a command line tool for converting virtual machines from an -VMware(tm) format machine into an \s-1XML\s0 image descriptor \f(CW\*(C`IMAGE.XML\*(C'\fR (\fIvirt\-image\fR\|(5)). -The basic configuration of the virtual machine are taken from the VMware configuration file (e.g., -disk image files, memory, name, vcpus) and a new \s-1XML\s0 image descriptor file is created using -these values. The conversion process requires that all necessary kernel modules and configuration -to boot using Xen or \s-1KVM\s0 are completed prior to running this tool. +\&\fBvirt-unpack\fR is a command line tool for converting virtual machines +from one format to another. Pass in either a \s-1VM\s0 definition file (such +as VMWare vmx format) or a directory containing a \s-1VM\s0. By default, a new +\&\s-1VM\s0 definition file, and converted disk images, will be placed in a new +output directory. +.PP +If an output directory is specified, it will be created if necessary, +and the output \s-1VM\s0 definition placed within, along with any disk images +as needed. +.PP +If an output \s-1VM\s0 definition file is specified, it will be created +alongside any disks in the same directory. .SH "OPTIONS" .IX Header "OPTIONS" Any of the options can be omitted, in which case \fBvirt-unpack\fR will use defaults when required. +An input \s-1VM\s0 definition or containing directory must be provided. By +default, an output directory is generated based upon the name of the \s-1VM\s0. +The default input format is VMWare vmx, and the default output format is +a libvirt \*(L"image\*(R" \s-1XML\s0 definition (see \fIvirt\-image\fR\|(5)). .IP "\-h, \-\-help" 4 .IX Item "-h, --help" Show the help message and exit .IP "\-a \s-1ARCH\s0, \-\-arch=ARCH" 4 .IX Item "-a ARCH, --arch=ARCH" -Architecture of the virtual machine (i686/x86_64,ppc) +Architecture of the virtual machine (i686, x86_64, ppc) .IP "\-v, \-\-hvm Create a fully virtualized guest image" 4 .IX Item "-v, --hvm Create a fully virtualized guest image" Convert machine to a hvm/qemu based image (this is the default if paravirt is not specified) .IP "\-p, \-\-paravirt Create a paravirtualized guest image" 4 .IX Item "-p, --paravirt Create a paravirtualized guest image" Convert machine to a paravirt xen based image -.IP "\-o \s-1OUTPUTDIR\s0, \-\-outputdir=NAME" 4 -.IX Item "-o OUTPUTDIR, --outputdir=NAME" -Directory in which files will be placed +.IP "\-i format" 4 +.IX Item "-i format" +Input format. Currently, \f(CW\*(C`vmx\*(C'\fR is the only supported input format. +.IP "\-o format" 4 +.IX Item "-o format" +Output format. Currently, \f(CW\*(C`virt\-image\*(C'\fR is the only supported output format. .IP "\-d, \-\-debug" 4 .IX Item "-d, --debug" Print debugging information @@ -176,13 +182,13 @@ Convert a paravirt guest from \f(CW\*(C` Convert a paravirt guest from \f(CW\*(C`image.vmx\*(C'\fR: .PP .Vb 1 -\& # virt\-unpack image.vmx \-\-arch=i686 \-\-paravirt +\& # virt-unpack --arch=i686 --paravirt image.vmx .Ve .PP -Convert a hvm guest and output the created file to /tmp +Convert a 64\-bit hvm guest: .PP .Vb 1 -\& # virt\-unpack image.vmx \-\-arch=x86_64 \-\-hvm \-\-outputdir /tmp +\& # virt-unpack --arch=x86_64 vmx-appliance/ hvm-appliance/ .Ve .SH "AUTHOR" .IX Header "AUTHOR" diff --git a/man/en/virt-unpack.pod b/man/en/virt-unpack.pod --- a/man/en/virt-unpack.pod +++ b/man/en/virt-unpack.pod @@ -2,25 +2,34 @@ =head1 NAME -virt-unpack - convert virtual machines from VMware(tm) format into an xml image descriptor +virt-unpack - convert virtual machines between formats =head1 SYNOPSIS -B [OPTION]... IMAGE.VMX +B [OPTION]... INPUT.VMX|INPUT-DIR [OUTPUT.XML|OUTPUT-DIR] =head1 DESCRIPTION -B is a command line tool for converting virtual machines from an -VMware(tm) format machine into an XML image descriptor C (L). -The basic configuration of the virtual machine are taken from the VMware configuration file (e.g., -disk image files, memory, name, vcpus) and a new XML image descriptor file is created using -these values. The conversion process requires that all necessary kernel modules and configuration -to boot using Xen or KVM are completed prior to running this tool. +B is a command line tool for converting virtual machines +from one format to another. Pass in either a VM definition file (such +as VMWare vmx format) or a directory containing a VM. By default, a new +VM definition file, and converted disk images, will be placed in a new +output directory. +If an output directory is specified, it will be created if necessary, +and the output VM definition placed within, along with any disk images +as needed. + +If an output VM definition file is specified, it will be created +alongside any disks in the same directory. =head1 OPTIONS Any of the options can be omitted, in which case B will use defaults when required. +An input VM definition or containing directory must be provided. By +default, an output directory is generated based upon the name of the VM. +The default input format is VMWare vmx, and the default output format is +a libvirt "image" XML definition (see L). =over 4 @@ -30,7 +39,7 @@ Show the help message and exit =item -a ARCH, --arch=ARCH -Architecture of the virtual machine (i686/x86_64,ppc) +Architecture of the virtual machine (i686, x86_64, ppc) =item -v, --hvm Create a fully virtualized guest image @@ -40,9 +49,13 @@ Convert machine to a hvm/qemu based imag Convert machine to a paravirt xen based image -=item -o OUTPUTDIR, --outputdir=NAME +=item -i format -Directory in which files will be placed +Input format. Currently, C is the only supported input format. + +=item -o format + +Output format. Currently, C is the only supported output format. =item -d, --debug @@ -54,11 +67,11 @@ Print debugging information Convert a paravirt guest from C: - # virt-unpack image.vmx --arch=i686 --paravirt + # virt-unpack --arch=i686 --paravirt image.vmx -Convert a hvm guest and output the created file to /tmp +Convert a 64-bit hvm guest: - # virt-unpack image.vmx --arch=x86_64 --hvm --outputdir /tmp + # virt-unpack --arch=x86_64 vmx-appliance/ hvm-appliance/ =head1 AUTHOR diff --git a/virt-unpack b/virt-unpack old mode 100644 new mode 100755 --- a/virt-unpack +++ b/virt-unpack @@ -28,32 +28,65 @@ import pdb import pdb import shutil import logging +import errno from optparse import OptionParser, OptionValueError def parse_args(): parser = OptionParser() - parser.set_usage("%prog [options] image.vmx") + parser.set_usage("%prog [options] inputdir|input.vmx [outputdir|output.xml]") parser.add_option("-a", "--arch", type="string", dest="arch", help=("Machine Architecture Type (i686/x86_64/ppc)")) parser.add_option("-t", "--type", type="string", dest="type", help=("Output virtualization type (hvm, paravirt")) parser.add_option("-d", "--debug", action="store_true", dest="debug", help=("Print debugging information")) - parser.add_option("-o", "--outputdir", type="string", dest="outputdir", - help=("Output directory in which files will be created")) + parser.add_option("-i", "--input-format", action="store_true", + dest="inputformat", default="vmx", + help=("Input format, e.g. 'vmx'")) + parser.add_option("-o", "--output-format", action="store_true", + dest="outputformat", default="virt-image", + help=("Output format, e.g. 'virt-image'")) parser.add_option("-v", "--hvm", action="store_true", dest="fullvirt", help=("This guest should be a fully virtualized guest")) parser.add_option("-p", "--paravirt", action="store_true", dest="paravirt", help=("This guest should be a paravirtualized guest")) - (options,args) = parser.parse_args() if len(args) < 1: - parser.error(("You need to provide an image XML descriptor")) - options.file = args[0] + parser.error(("You need to provide an input VM definition")) + if len(args) > 2: + parser.error(("Too many arguments provided")) if (options.arch is None): parser.error(("Missing option value \n\nArchitecture: " + str(options.arch))) + + # hard-code for now + if options.inputformat != "vmx": + parser.error(("Unsupported input format \"%s\"" % options.inputformat)) + if options.outputformat != "virt-image": + parser.error(("Unsupported output format \"%s\"" % options.outputformat)) + if os.path.isdir(args[0]): + vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] + if (len(vmx_files)) == 0: + parser.error(("No VM definition file was found in %s" % args[0])) + if (len(vmx_files)) > 1: + parser.error(("Too many .vmx definitions found in %s" % args[0])) + options.input_file = os.path.join(args[0], vmx_files[0]) + options.input_dir = args[0] + else: + options.input_file = args[0] + options.input_dir = os.path.dirname(os.path.realpath(args[0])) + + if len(args) == 1: + options.output_file = None + options.output_dir = None + elif os.path.isdir(args[1]) or args[1].endswith("/"): + options.output_file = None + options.output_dir = args[1] + else: + options.output_file = args[1] + options.output_dir = os.path.dirname(os.path.realpath(args[1])) + return options # Begin creation of xml template from parsed vmx config file @@ -62,29 +95,31 @@ def vmx_to_image_xml(disks_list,record,o fv_disk_list = [] storage_disk_list = [] + file = options.input_file + # validate required values for conversion are in the input vmx file if record.has_key("displayName"): name = record["displayName"] else: - logging.error("displayName key not parsed from %s" % options.file) + logging.error("displayName key not parsed from %s" % file) sys.exit(1) if record.has_key("memsize"): memory = int(record["memsize"]) * 1024 else: - logging.error("memsize key not parsed from %s" % options.file) + logging.error("memsize key not parsed from %s" % file) sys.exit(1) if record.has_key("annotation"): annotation = record["annotation"] else: - logging.error("annotation key not parsed from %s, creating blank comment" % options.file) + logging.error("annotation key not parsed from %s, creating blank comment" % file) annotation = "" if record.has_key("numvcpus"): vcpus = record["numvcpus"] else: - logging.error("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % options.file) + logging.error("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) vcpus = "1" @@ -164,9 +199,9 @@ def vmx_to_image_xml(disks_list,record,o # parse input vmware configuration def parse_vmware_config(options): - if not os.access(options.file,os.R_OK): - raise ValueError, "Could not read file: %s" % options.file - input = open(options.file,"r") + if not os.access(options.input_file, os.R_OK): + raise ValueError, "Could not read file: %s" % options.input_file + input = open(options.input_file, "r") contents = input.readlines() input.close() record = {} @@ -191,18 +226,30 @@ def parse_vmware_config(options): return record,disks_list -def convert_disks(disks_list,dirname): +def convert_disks(disks_list, options): for disk in disks_list: - file = disk.replace(".vmdk","").strip() - convert_cmd="qemu-img convert %s -O raw %s/%s.img" % (disk.strip(),dirname,file) - logging.debug("Converting %s" % disk.strip()) - print "\nConverting %s to %s/%s.img" % (disk.strip(),dirname,file) - os.system(convert_cmd) + infile = disk.strip() + if not os.path.isabs(infile): + infile = os.path.join(options.input_dir, infile) + + outfile = disk.replace(".vmdk","").strip() + outfile += ".img" + if not os.path.isabs(outfile): + outfile = os.path.join(options.output_dir, outfile) + convert_cmd="qemu-img convert %s -O raw %s" % (infile, outfile) + ret = os.system(convert_cmd) + print ret def main(): options = parse_args() cli.setupLogging("virt-unpack", options.debug) + + logging.debug("input_file: %s" % options.input_file) + logging.debug("input_dir: %s" % options.input_dir) + logging.debug("output_file: %s" % options.output_file) + logging.debug("output_dir: %s" % options.input_dir) + vm_config = parse_vmware_config(options) record, disks_list = vm_config @@ -210,26 +257,31 @@ def main(): hvm = False else: hvm = True - virtimage_xml = vmx_to_image_xml(disks_list,record,options,hvm) + out_contents = vmx_to_image_xml(disks_list, record, options, hvm) name = record["displayName"].replace(" ","-") - dirname = options.outputdir - if not dirname: - dirname = name + if not options.output_dir: + options.output_dir = name try: - logging.debug ("Creating directory %s" % dirname) - os.mkdir(dirname) + logging.debug("Creating directory %s" % options.output_dir) + os.mkdir(options.output_dir) except OSError,e: - logging.error("Could not create directory %s: %s" % (dirname, str(e))) - sys.exit(1) + if (e.errno != errno.EEXIST): + logging.error("Could not create directory %s: %s" % + (options.output_dir, str(e))) + sys.exit(1) + + if not options.output_file: + options.output_file = os.path.join(options.output_dir, + "%s.virt-image.xml" % name) # configuration completed, ready to write config file and convert disks - virtimage_xml_file = open(dirname + "/" + name + ".virtimage.xml","w") - virtimage_xml_file.writelines(virtimage_xml) - virtimage_xml_file.close() - convert_disks(disks_list,dirname) + out = open(options.output_file, "w") + out.writelines(out_contents) + out.close() + convert_disks(disks_list, options) - print "\n\nConversion completed and placed in: %s" % dirname + print "\n\nConversion completed and placed in: %s" % options.output_dir if __name__ == "__main__": From levon at movementarian.org Tue Jul 1 19:24:36 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:24:36 +0100 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img Message-ID: <20080701192436.GE11119@totally.trollied.org.uk> Check result of qemu-img If qemu-img convert fails, report an error and exit. Signed-off-by: John Levon diff --git a/virt-unpack b/virt-unpack --- a/virt-unpack +++ b/virt-unpack @@ -237,8 +237,9 @@ def convert_disks(disks_list, options): if not os.path.isabs(outfile): outfile = os.path.join(options.output_dir, outfile) convert_cmd="qemu-img convert %s -O raw %s" % (infile, outfile) - ret = os.system(convert_cmd) - print ret + if os.system(convert_cmd) != 0: + logging.error("Converting disk %s failed.\n" % infile) + sys.exit(1) def main(): From levon at movementarian.org Tue Jul 1 19:25:10 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:25:10 +0100 Subject: [et-mgmt-tools] [PATCH] Add a newline to virt-image output definition Message-ID: <20080701192510.GF11119@totally.trollied.org.uk> Add a newline to virt-image output definition Signed-off-by: John Levon diff --git a/virt-unpack b/virt-unpack --- a/virt-unpack +++ b/virt-unpack @@ -192,7 +192,8 @@ def vmx_to_image_xml(disks_list,record,o %(vm_storage)s -""" + +""" virtimage_xml_template = virt_image_xml_template % virt_image_xml_dict return virtimage_xml_template From levon at movementarian.org Tue Jul 1 19:25:29 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:25:29 +0100 Subject: [et-mgmt-tools] [PATCH] Make lack of 'numvcpus' a warning only Message-ID: <20080701192529.GG11119@totally.trollied.org.uk> Make lack of 'numvcpus' a warning only A .vmx file without 'numvcpus' seems common. Make the warning be a debug-only message. Signed-off-by: John Levon diff --git a/virt-unpack b/virt-unpack --- a/virt-unpack +++ b/virt-unpack @@ -119,7 +119,7 @@ def vmx_to_image_xml(disks_list,record,o if record.has_key("numvcpus"): vcpus = record["numvcpus"] else: - logging.error("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) + logging.warning("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) vcpus = "1" From levon at movementarian.org Tue Jul 1 19:25:51 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:25:51 +0100 Subject: [et-mgmt-tools] [PATCH] Fix some pylint in virt-unpack Message-ID: <20080701192551.GH11119@totally.trollied.org.uk> Fix some pylint in virt-unpack Not fully pylint clean, but this fixes most of the complaints. Signed-off-by: John Levon diff --git a/virt-unpack b/virt-unpack --- a/virt-unpack +++ b/virt-unpack @@ -24,16 +24,14 @@ from string import ascii_letters from string import ascii_letters import virtinst.cli as cli import os -import random -import pdb -import shutil import logging import errno -from optparse import OptionParser, OptionValueError +from optparse import OptionParser def parse_args(): parser = OptionParser() - parser.set_usage("%prog [options] inputdir|input.vmx [outputdir|output.xml]") + parser.set_usage("%prog [options] inputdir|input.vmx " + "[outputdir|output.xml]") parser.add_option("-a", "--arch", type="string", dest="arch", help=("Machine Architecture Type (i686/x86_64/ppc)")) parser.add_option("-t", "--type", type="string", dest="type", @@ -51,20 +49,22 @@ def parse_args(): parser.add_option("-p", "--paravirt", action="store_true", dest="paravirt", help=("This guest should be a paravirtualized guest")) - (options,args) = parser.parse_args() + (options, args) = parser.parse_args() if len(args) < 1: - parser.error(("You need to provide an input VM definition")) + parser.error(("You need to provide an input VM definition")) if len(args) > 2: - parser.error(("Too many arguments provided")) + parser.error(("Too many arguments provided")) if (options.arch is None): - parser.error(("Missing option value \n\nArchitecture: " + str(options.arch))) + parser.error(("Missing option value \n\nArchitecture: " + + str(options.arch))) # hard-code for now if options.inputformat != "vmx": parser.error(("Unsupported input format \"%s\"" % options.inputformat)) if options.outputformat != "virt-image": - parser.error(("Unsupported output format \"%s\"" % options.outputformat)) + parser.error(("Unsupported output format \"%s\"" + % options.outputformat)) if os.path.isdir(args[0]): vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] if (len(vmx_files)) == 0: @@ -90,47 +90,50 @@ def parse_args(): return options # Begin creation of xml template from parsed vmx config file -def vmx_to_image_xml(disks_list,record,options,hvm): +def vmx_to_image_xml(disks_list, record, options, hvm): pv_disk_list = [] fv_disk_list = [] storage_disk_list = [] - file = options.input_file + infile = options.input_file # validate required values for conversion are in the input vmx file if record.has_key("displayName"): name = record["displayName"] else: - logging.error("displayName key not parsed from %s" % file) + logging.error("displayName key not parsed from %s" % infile) sys.exit(1) if record.has_key("memsize"): memory = int(record["memsize"]) * 1024 else: - logging.error("memsize key not parsed from %s" % file) + logging.error("memsize key not parsed from %s" % infile) sys.exit(1) if record.has_key("annotation"): - annotation = record["annotation"] + annotation = record["annotation"] else: - logging.error("annotation key not parsed from %s, creating blank comment" % file) + logging.error("annotation key not parsed from %s, " + "creating blank comment" % infile) annotation = "" if record.has_key("numvcpus"): vcpus = record["numvcpus"] else: - logging.warning("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) + logging.warning("numvcpus key not parsed from %s, " + "defaulting to 1 virtual cpu" % infile) vcpus = "1" # create disk filename lists for xml template - for (number, file) in enumerate(disks_list): - file = str(file.replace(".vmdk","")).strip() + for (number, dfile) in enumerate(disks_list): + dfile = str(dfile.replace(".vmdk","")).strip() pv_disk_list.append("""""" % \ - (file, ascii_letters[number % 26])) + (dfile, ascii_letters[number % 26])) fv_disk_list.append("""""" % \ - (file, ascii_letters[number % 26])) - storage_disk_list.append("""""" % (file)) + (dfile, ascii_letters[number % 26])) + storage_disk_list.append( + """""" % (dfile)) # determine virtualization type for image.boot section if hvm is False: @@ -202,9 +205,9 @@ def parse_vmware_config(options): def parse_vmware_config(options): if not os.access(options.input_file, os.R_OK): raise ValueError, "Could not read file: %s" % options.input_file - input = open(options.input_file, "r") - contents = input.readlines() - input.close() + infile = open(options.input_file, "r") + contents = infile.readlines() + infile.close() record = {} vm_config = [] disks_list = [] @@ -217,14 +220,14 @@ def parse_vmware_config(options): vm_config.append(line) for line in vm_config: - beforeEq, afterEq = line.split("=", 1) - key = beforeEq.replace(" ","") - value = afterEq.replace('"',"") + before_eq, after_eq = line.split("=", 1) + key = before_eq.replace(" ","") + value = after_eq.replace('"',"") record[key] = value.strip() - logging.debug("Key: %s Value: %s" % (key,value)) + logging.debug("Key: %s Value: %s" % (key, value)) if value.endswith("vmdk\n"): # separate disks from config disks_list.append(value) - return record,disks_list + return record, disks_list def convert_disks(disks_list, options): @@ -234,10 +237,10 @@ def convert_disks(disks_list, options): infile = os.path.join(options.input_dir, infile) outfile = disk.replace(".vmdk","").strip() - outfile += ".img" + outfile += ".img" if not os.path.isabs(outfile): outfile = os.path.join(options.output_dir, outfile) - convert_cmd="qemu-img convert %s -O raw %s" % (infile, outfile) + convert_cmd = "qemu-img convert %s -O raw %s" % (infile, outfile) if os.system(convert_cmd) != 0: logging.error("Converting disk %s failed.\n" % infile) sys.exit(1) @@ -256,18 +259,18 @@ def main(): record, disks_list = vm_config if options.paravirt: - hvm = False + hvm = False else: - hvm = True + hvm = True out_contents = vmx_to_image_xml(disks_list, record, options, hvm) name = record["displayName"].replace(" ","-") if not options.output_dir: options.output_dir = name try: - logging.debug("Creating directory %s" % options.output_dir) - os.mkdir(options.output_dir) - except OSError,e: + logging.debug("Creating directory %s" % options.output_dir) + os.mkdir(options.output_dir) + except OSError, e: if (e.errno != errno.EEXIST): logging.error("Could not create directory %s: %s" % (options.output_dir, str(e))) @@ -292,7 +295,7 @@ if __name__ == "__main__": except SystemExit, e: sys.exit(e.code) except KeyboardInterrupt, e: - print >> sys.stderr, _("Aborted at user request") + print >> sys.stderr, "Aborted at user request" except Exception, e: logging.exception(e) sys.exit(1) From levon at movementarian.org Tue Jul 1 19:26:29 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:26:29 +0100 Subject: [et-mgmt-tools] [PATCH] Rename virt-unpack to virt-convert. Message-ID: <20080701192629.GI11119@totally.trollied.org.uk> Rename virt-unpack to virt-convert. Signed-off-by: John Levon diff --git a/man/en/Makefile b/man/en/Makefile --- a/man/en/Makefile +++ b/man/en/Makefile @@ -1,9 +1,9 @@ CENTER="Virtual Machine Install Tools" CENTER="Virtual Machine Install Tools" -all: virt-install.1 virt-image.1 virt-clone.1 virt-image.5 +all: virt-install.1 virt-image.1 virt-clone.1 virt-image.5 virt-convert.1 -html: virt-install.html virt-clone.html virt-image.html virt-image-xml.html +html: virt-install.html virt-clone.html virt-image.html virt-image-xml.html virt-convert.html clean: rm *.1 *.5 diff --git a/man/en/virt-unpack.1 b/man/en/virt-convert.1 rename from man/en/virt-unpack.1 rename to man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -128,16 +128,16 @@ .rm #[ #] #H #V #F C .\" ======================================================================== .\" -.IX Title "VIRT-UNPACK 1" -.TH VIRT-UNPACK 1 "2008-07-01" "perl v5.8.8" "Virtual Machine Install Tools" +.IX Title "VIRT-CONVERT 1" +.TH VIRT-CONVERT 1 "2008-07-01" "perl v5.8.8" "Virtual Machine Install Tools" .SH "NAME" -virt\-unpack \- convert virtual machines between formats +virt\-convert \- convert virtual machines between formats .SH "SYNOPSIS" .IX Header "SYNOPSIS" -\&\fBvirt-unpack\fR [\s-1OPTION\s0]... \s-1INPUT\s0.VMX|INPUT\-DIR [\s-1OUTPUT\s0.XML|OUTPUT\-DIR] +\&\fBvirt-convert\fR [\s-1OPTION\s0]... \s-1INPUT\s0.VMX|INPUT\-DIR [\s-1OUTPUT\s0.XML|OUTPUT\-DIR] .SH "DESCRIPTION" .IX Header "DESCRIPTION" -\&\fBvirt-unpack\fR is a command line tool for converting virtual machines +\&\fBvirt-convert\fR is a command line tool for converting virtual machines from one format to another. Pass in either a \s-1VM\s0 definition file (such as VMWare vmx format) or a directory containing a \s-1VM\s0. By default, a new \&\s-1VM\s0 definition file, and converted disk images, will be placed in a new @@ -151,7 +151,7 @@ alongside any disks in the same director alongside any disks in the same directory. .SH "OPTIONS" .IX Header "OPTIONS" -Any of the options can be omitted, in which case \fBvirt-unpack\fR will use defaults when required. +Any of the options can be omitted, in which case \fBvirt-convert\fR will use defaults when required. An input \s-1VM\s0 definition or containing directory must be provided. By default, an output directory is generated based upon the name of the \s-1VM\s0. The default input format is VMWare vmx, and the default output format is @@ -182,13 +182,13 @@ Convert a paravirt guest from \f(CW\*(C` Convert a paravirt guest from \f(CW\*(C`image.vmx\*(C'\fR: .PP .Vb 1 -\& # virt-unpack --arch=i686 --paravirt image.vmx +\& # virt-convert --arch=i686 --paravirt image.vmx .Ve .PP Convert a 64\-bit hvm guest: .PP .Vb 1 -\& # virt-unpack --arch=x86_64 vmx-appliance/ hvm-appliance/ +\& # virt-convert --arch=x86_64 vmx-appliance/ hvm-appliance/ .Ve .SH "AUTHOR" .IX Header "AUTHOR" diff --git a/man/en/virt-unpack.pod b/man/en/virt-convert.pod rename from man/en/virt-unpack.pod rename to man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -2,15 +2,15 @@ =head1 NAME -virt-unpack - convert virtual machines between formats +virt-convert - convert virtual machines between formats =head1 SYNOPSIS -B [OPTION]... INPUT.VMX|INPUT-DIR [OUTPUT.XML|OUTPUT-DIR] +B [OPTION]... INPUT.VMX|INPUT-DIR [OUTPUT.XML|OUTPUT-DIR] =head1 DESCRIPTION -B is a command line tool for converting virtual machines +B is a command line tool for converting virtual machines from one format to another. Pass in either a VM definition file (such as VMWare vmx format) or a directory containing a VM. By default, a new VM definition file, and converted disk images, will be placed in a new @@ -25,7 +25,7 @@ alongside any disks in the same director =head1 OPTIONS -Any of the options can be omitted, in which case B will use defaults when required. +Any of the options can be omitted, in which case B will use defaults when required. An input VM definition or containing directory must be provided. By default, an output directory is generated based upon the name of the VM. The default input format is VMWare vmx, and the default output format is @@ -67,11 +67,11 @@ Print debugging information Convert a paravirt guest from C: - # virt-unpack --arch=i686 --paravirt image.vmx + # virt-convert --arch=i686 --paravirt image.vmx Convert a 64-bit hvm guest: - # virt-unpack --arch=x86_64 vmx-appliance/ hvm-appliance/ + # virt-convert --arch=x86_64 vmx-appliance/ hvm-appliance/ =head1 AUTHOR diff --git a/setup.py b/setup.py --- a/setup.py +++ b/setup.py @@ -14,7 +14,7 @@ datafiles = [('share/man/man1', ['man/en 'man/en/virt-clone.1', 'man/en/virt-image.1', 'man/en/virt-pack.1', - 'man/en/virt-unpack.1']), + 'man/en/virt-convert.1']), ('share/man/man5', ['man/en/virt-image.5'])] locale = None builddir = None @@ -118,7 +118,7 @@ setup(name='virtinst', license='GPL', package_dir={'virtinst': 'virtinst'}, scripts = ["virt-install","virt-clone", "virt-image", "virt-pack", - "virt-unpack"], + "virt-convert"], packages=pkgs, data_files = datafiles, cmdclass = { 'test': TestCommand, 'build': build, \ diff --git a/virt-unpack b/virt-convert rename from virt-unpack rename to virt-convert --- a/virt-convert +++ b/virt-convert @@ -248,7 +248,7 @@ def convert_disks(disks_list, options): def main(): options = parse_args() - cli.setupLogging("virt-unpack", options.debug) + cli.setupLogging("virt-convert", options.debug) logging.debug("input_file: %s" % options.input_file) logging.debug("input_dir: %s" % options.input_dir) From berrange at redhat.com Tue Jul 1 19:28:01 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 1 Jul 2008 20:28:01 +0100 Subject: [et-mgmt-tools] [PATCH] Make lack of 'numvcpus' a warning only In-Reply-To: <20080701192529.GG11119@totally.trollied.org.uk> References: <20080701192529.GG11119@totally.trollied.org.uk> Message-ID: <20080701192801.GB31728@redhat.com> On Tue, Jul 01, 2008 at 08:25:29PM +0100, John Levon wrote: > > Make lack of 'numvcpus' a warning only > > A .vmx file without 'numvcpus' seems common. Make the warning be a > debug-only message. > > Signed-off-by: John Levon > > diff --git a/virt-unpack b/virt-unpack > --- a/virt-unpack > +++ b/virt-unpack > @@ -119,7 +119,7 @@ def vmx_to_image_xml(disks_list,record,o > if record.has_key("numvcpus"): > vcpus = record["numvcpus"] > else: > - logging.error("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) > + logging.warning("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) > vcpus = "1" IMHO, we shoudn't bother logging anything just silently default it to 1. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Tue Jul 1 19:37:44 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:37:44 +0100 Subject: [et-mgmt-tools] [PATCH] Make lack of 'numvcpus' a warning only In-Reply-To: <20080701192801.GB31728@redhat.com> References: <20080701192529.GG11119@totally.trollied.org.uk> <20080701192801.GB31728@redhat.com> Message-ID: <20080701193744.GA13745@totally.trollied.org.uk> On Tue, Jul 01, 2008 at 08:28:01PM +0100, Daniel P. Berrange wrote: > > diff --git a/virt-unpack b/virt-unpack > > --- a/virt-unpack > > +++ b/virt-unpack > > @@ -119,7 +119,7 @@ def vmx_to_image_xml(disks_list,record,o > > if record.has_key("numvcpus"): > > vcpus = record["numvcpus"] > > else: > > - logging.error("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) > > + logging.warning("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) > > vcpus = "1" > > IMHO, we shoudn't bother logging anything just silently default > it to 1. Fine by me. What about 'annotation'? I couldn't find this documented on sanbarrow.com regards john From levon at movementarian.org Tue Jul 1 19:38:48 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 20:38:48 +0100 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <20080701192436.GE11119@totally.trollied.org.uk> References: <20080701192436.GE11119@totally.trollied.org.uk> Message-ID: <20080701193848.GB13745@totally.trollied.org.uk> On Tue, Jul 01, 2008 at 08:24:36PM +0100, John Levon wrote: > Check result of qemu-img > > If qemu-img convert fails, report an error and exit. BTW, on my Fedora 8 box, it doesn't seem able to parse .vmdk: qemu-img: Could not open '/home/moz/src/appliances/drupal-1.1.0/disks/root/root.vmdk' (A strace shows it opening the file successfully, then giving this error) regards john From jboggs at redhat.com Tue Jul 1 19:59:01 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 01 Jul 2008 15:59:01 -0400 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <20080701193848.GB13745@totally.trollied.org.uk> References: <20080701192436.GE11119@totally.trollied.org.uk> <20080701193848.GB13745@totally.trollied.org.uk> Message-ID: <486A8C85.7040703@redhat.com> You might need to specify the -f option, I know there's an older qemu-img version on Fedora 8 that does not autodetect the file format. qemu-img -f file.vmdk John Levon wrote: > On Tue, Jul 01, 2008 at 08:24:36PM +0100, John Levon wrote: > > >> Check result of qemu-img >> >> If qemu-img convert fails, report an error and exit. >> > > BTW, on my Fedora 8 box, it doesn't seem able to parse .vmdk: > > qemu-img: Could not open '/home/moz/src/appliances/drupal-1.1.0/disks/root/root.vmdk' > > (A strace shows it opening the file successfully, then giving this > error) > > regards > john > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From levon at movementarian.org Tue Jul 1 20:02:10 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 21:02:10 +0100 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <486A8C85.7040703@redhat.com> References: <20080701192436.GE11119@totally.trollied.org.uk> <20080701193848.GB13745@totally.trollied.org.uk> <486A8C85.7040703@redhat.com> Message-ID: <20080701200210.GA14518@totally.trollied.org.uk> On Tue, Jul 01, 2008 at 03:59:01PM -0400, Joey Boggs wrote: > You might need to specify the -f option, I know there's an older > qemu-img version on Fedora 8 that does not autodetect the file format. > > qemu-img -f file.vmdk No good: $ qemu-img convert -f vmdk root.vmdk -O raw a.raw qemu-img: Could not open 'root.vmdk' vmdk is: $ cat root.vmdk # Disk DescriptorFile version=1 CID=ab3d47b2 parentCID=ffffffff createType="twoGbMaxExtentFlat" # Extent description RW 3145728 FLAT "root.hdd" 0 # The Disk Data Base #DDB ddb.virtualHWVersion = "4" ddb.geometry.cylinders = "768" ddb.geometry.heads = "128" ddb.geometry.sectors = "32" ddb.adapterType = "lsilogic" ddb.toolsVersion = "6533" From jboggs at redhat.com Tue Jul 1 20:05:37 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 01 Jul 2008 16:05:37 -0400 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <20080701200210.GA14518@totally.trollied.org.uk> References: <20080701192436.GE11119@totally.trollied.org.uk> <20080701193848.GB13745@totally.trollied.org.uk> <486A8C85.7040703@redhat.com> <20080701200210.GA14518@totally.trollied.org.uk> Message-ID: <486A8E11.5040706@redhat.com> John, Looks like the vmdk file is just a descriptor file. The real image may already be raw: root.hdd # Extent description RW 3145728 FLAT "root.hdd" 0 John Levon wrote: > On Tue, Jul 01, 2008 at 03:59:01PM -0400, Joey Boggs wrote: > > >> You might need to specify the -f option, I know there's an older >> qemu-img version on Fedora 8 that does not autodetect the file format. >> >> qemu-img -f file.vmdk >> > > No good: > > $ qemu-img convert -f vmdk root.vmdk -O raw a.raw > qemu-img: Could not open 'root.vmdk' > > vmdk is: > > $ cat root.vmdk > # Disk DescriptorFile > version=1 > CID=ab3d47b2 > parentCID=ffffffff > createType="twoGbMaxExtentFlat" > > # Extent description > RW 3145728 FLAT "root.hdd" 0 > > # The Disk Data Base > #DDB > > ddb.virtualHWVersion = "4" > ddb.geometry.cylinders = "768" > ddb.geometry.heads = "128" > ddb.geometry.sectors = "32" > ddb.adapterType = "lsilogic" > ddb.toolsVersion = "6533" > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From levon at movementarian.org Tue Jul 1 20:08:47 2008 From: levon at movementarian.org (John Levon) Date: Tue, 1 Jul 2008 21:08:47 +0100 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <486A8E11.5040706@redhat.com> References: <20080701192436.GE11119@totally.trollied.org.uk> <20080701193848.GB13745@totally.trollied.org.uk> <486A8C85.7040703@redhat.com> <20080701200210.GA14518@totally.trollied.org.uk> <486A8E11.5040706@redhat.com> Message-ID: <20080701200847.GC14518@totally.trollied.org.uk> On Tue, Jul 01, 2008 at 04:05:37PM -0400, Joey Boggs wrote: > Looks like the vmdk file is just a descriptor file. Well, yep. That's pretty much standard practice AFAIK. > The real image may already be raw: root.hdd If qemu-img isn't smart enough to handle the above VMDK format, it looks like it'll need to be handled in virt-convert somehow. (Side note: the ability to handle VMDK is of course hypervisor-specific; we'll need to figure out a way to skip the conversion step.) regards john From levon at movementarian.org Wed Jul 2 04:49:43 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 05:49:43 +0100 Subject: [et-mgmt-tools] [PATCH] move option debugging in virt-convert Message-ID: <20080702044943.GA16405@totally.trollied.org.uk> Move debugging Move option debugging to a more useful place. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -249,11 +250,6 @@ def main(): def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) - - logging.debug("input_file: %s" % options.input_file) - logging.debug("input_dir: %s" % options.input_dir) - logging.debug("output_file: %s" % options.output_file) - logging.debug("output_dir: %s" % options.input_dir) vm_config = parse_vmware_config(options) record, disks_list = vm_config @@ -280,6 +276,11 @@ def main(): options.output_file = os.path.join(options.output_dir, "%s.virt-image.xml" % name) + logging.debug("input_file: %s" % options.input_file) + logging.debug("input_dir: %s" % options.input_dir) + logging.debug("output_file: %s" % options.output_file) + logging.debug("output_dir: %s" % options.input_dir) + # configuration completed, ready to write config file and convert disks out = open(options.output_file, "w") out.writelines(out_contents) From levon at movementarian.org Wed Jul 2 04:50:03 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 05:50:03 +0100 Subject: [et-mgmt-tools] [PATCH] Fix DOS VMX files Message-ID: <20080702045003.GB16405@totally.trollied.org.uk> Fix .vmx parsing for DOS files The handling for DOS-formatted .vmx files was incorrect. Fix it up. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -223,9 +223,10 @@ def parse_vmware_config(options): before_eq, after_eq = line.split("=", 1) key = before_eq.replace(" ","") value = after_eq.replace('"',"") - record[key] = value.strip() - logging.debug("Key: %s Value: %s" % (key, value)) - if value.endswith("vmdk\n"): # separate disks from config + value = value.strip() + record[key] = value + logging.debug("Key: %s Value: \"%s\"" % (key, value)) + if value.endswith("vmdk"): # separate disks from config disks_list.append(value) return record, disks_list From levon at movementarian.org Wed Jul 2 04:50:30 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 05:50:30 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: fix option handling Message-ID: <20080702045030.GC16405@totally.trollied.org.uk> Fix up options handling for input dirs. If we specify an input directory, and no output, then default to placing a config file in the input directory. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -80,6 +80,8 @@ def parse_args(): if len(args) == 1: options.output_file = None options.output_dir = None + if os.path.isdir(args[0]): + options.output_dir = options.input_dir elif os.path.isdir(args[1]) or args[1].endswith("/"): options.output_file = None options.output_dir = args[1] From levon at movementarian.org Wed Jul 2 04:50:51 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 05:50:51 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: arch is required Message-ID: <20080702045051.GD16405@totally.trollied.org.uk> Fix usage message The -a option is required; reflect this in the help message. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -30,7 +30,7 @@ from optparse import OptionParser def parse_args(): parser = OptionParser() - parser.set_usage("%prog [options] inputdir|input.vmx " + parser.set_usage("%prog [options] -a arch inputdir|input.vmx " "[outputdir|output.xml]") parser.add_option("-a", "--arch", type="string", dest="arch", help=("Machine Architecture Type (i686/x86_64/ppc)")) From levon at movementarian.org Wed Jul 2 04:51:08 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 05:51:08 +0100 Subject: [et-mgmt-tools] [PATCH] Fix format options Message-ID: <20080702045108.GE16405@totally.trollied.org.uk> Fix format options Fix -i and -o so they work properly. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -38,10 +38,10 @@ def parse_args(): help=("Output virtualization type (hvm, paravirt")) parser.add_option("-d", "--debug", action="store_true", dest="debug", help=("Print debugging information")) - parser.add_option("-i", "--input-format", action="store_true", + parser.add_option("-i", "--input-format", action="store", dest="inputformat", default="vmx", help=("Input format, e.g. 'vmx'")) - parser.add_option("-o", "--output-format", action="store_true", + parser.add_option("-o", "--output-format", action="store", dest="outputformat", default="virt-image", help=("Output format, e.g. 'virt-image'")) parser.add_option("-v", "--hvm", action="store_true", dest="fullvirt", From levon at movementarian.org Wed Jul 2 04:51:41 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 05:51:41 +0100 Subject: [et-mgmt-tools] [PATCH] Implement plugin method for virt-convert Message-ID: <20080702045141.GF16405@totally.trollied.org.uk> Create config parser plugin system Start a plugin system for config formats parsing, and implement enough of it to get to where we were with virt-convert. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -21,56 +21,59 @@ # MA 02110-1301 USA. import sys -from string import ascii_letters -import virtinst.cli as cli import os import logging import errno from optparse import OptionParser +import virtinst.cli as cli +import virtconv +import virtconv.vmconfig as vmconfig + def parse_args(): - parser = OptionParser() - parser.set_usage("%prog [options] -a arch inputdir|input.vmx " + """Parse command-line options and arguments.""" + opts = OptionParser() + opts.set_usage("%prog [options] -a arch inputdir|input.vmx " "[outputdir|output.xml]") - parser.add_option("-a", "--arch", type="string", dest="arch", - help=("Machine Architecture Type (i686/x86_64/ppc)")) - parser.add_option("-t", "--type", type="string", dest="type", - help=("Output virtualization type (hvm, paravirt")) - parser.add_option("-d", "--debug", action="store_true", dest="debug", - help=("Print debugging information")) - parser.add_option("-i", "--input-format", action="store", - dest="inputformat", default="vmx", - help=("Input format, e.g. 'vmx'")) - parser.add_option("-o", "--output-format", action="store", - dest="outputformat", default="virt-image", - help=("Output format, e.g. 'virt-image'")) - parser.add_option("-v", "--hvm", action="store_true", dest="fullvirt", - help=("This guest should be a fully virtualized guest")) - parser.add_option("-p", "--paravirt", action="store_true", dest="paravirt", - help=("This guest should be a paravirtualized guest")) + opts.add_option("-a", "--arch", type="string", dest="arch", + help=("Machine Architecture Type (i686/x86_64/ppc)")) + opts.add_option("-t", "--type", type="string", dest="type", + help=("Output virtualization type (hvm, paravirt")) + opts.add_option("-d", "--debug", action="store_true", dest="debug", + help=("Print debugging information")) + opts.add_option("-i", "--input-format", action="store", + dest="inputformat", default="vmx", + help=("Input format, e.g. 'vmx'")) + opts.add_option("-o", "--output-format", action="store", + dest="outputformat", default="virt-image", + help=("Output format, e.g. 'virt-image'")) + opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", + help=("This guest should be a fully virtualized guest")) + opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", + help=("This guest should be a paravirtualized guest")) - (options, args) = parser.parse_args() + (options, args) = opts.parse_args() if len(args) < 1: - parser.error(("You need to provide an input VM definition")) + opts.error(("You need to provide an input VM definition")) if len(args) > 2: - parser.error(("Too many arguments provided")) + opts.error(("Too many arguments provided")) if (options.arch is None): - parser.error(("Missing option value \n\nArchitecture: " + + opts.error(("Missing option value \n\nArchitecture: " + str(options.arch))) # hard-code for now if options.inputformat != "vmx": - parser.error(("Unsupported input format \"%s\"" % options.inputformat)) + opts.error(("Unsupported input format \"%s\"" % options.inputformat)) if options.outputformat != "virt-image": - parser.error(("Unsupported output format \"%s\"" + opts.error(("Unsupported output format \"%s\"" % options.outputformat)) if os.path.isdir(args[0]): vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] if (len(vmx_files)) == 0: - parser.error(("No VM definition file was found in %s" % args[0])) + opts.error(("No VM definition file was found in %s" % args[0])) if (len(vmx_files)) > 1: - parser.error(("Too many .vmx definitions found in %s" % args[0])) + opts.error(("Too many .vmx definitions found in %s" % args[0])) options.input_file = os.path.join(args[0], vmx_files[0]) options.input_dir = args[0] else: @@ -91,204 +94,79 @@ def parse_args(): return options -# Begin creation of xml template from parsed vmx config file -def vmx_to_image_xml(disks_list, record, options, hvm): - pv_disk_list = [] - fv_disk_list = [] - storage_disk_list = [] - - infile = options.input_file - - # validate required values for conversion are in the input vmx file - if record.has_key("displayName"): - name = record["displayName"] - else: - logging.error("displayName key not parsed from %s" % infile) - sys.exit(1) - - if record.has_key("memsize"): - memory = int(record["memsize"]) * 1024 - else: - logging.error("memsize key not parsed from %s" % infile) - sys.exit(1) - - if record.has_key("annotation"): - annotation = record["annotation"] - else: - logging.error("annotation key not parsed from %s, " - "creating blank comment" % infile) - annotation = "" - - if record.has_key("numvcpus"): - vcpus = record["numvcpus"] - else: - logging.warning("numvcpus key not parsed from %s, " - "defaulting to 1 virtual cpu" % infile) - vcpus = "1" - - -# create disk filename lists for xml template - for (number, dfile) in enumerate(disks_list): - dfile = str(dfile.replace(".vmdk","")).strip() - pv_disk_list.append("""""" % \ - (dfile, ascii_letters[number % 26])) - fv_disk_list.append("""""" % \ - (dfile, ascii_letters[number % 26])) - storage_disk_list.append( - """""" % (dfile)) - -# determine virtualization type for image.boot section - if hvm is False: - virt_boot_template = """ - - %(vm_arch)s - - - - - - pygrub - - %(vm_pv_disks)s - """ - elif hvm is True: - virt_boot_template = """ - - %(vm_arch)s - - - - - %(vm_fv_disks)s - """ - - -# xml replacements dictionaries - virt_boot_xml_dict = { - "vm_pv_disks" : "".join(pv_disk_list), - "vm_fv_disks" : "".join(fv_disk_list), - "vm_arch" : options.arch, - } - virt_boot_template = virt_boot_template % virt_boot_xml_dict - virt_image_xml_dict = { - "virt_boot_template" : virt_boot_template, - "vm_displayName": name.replace(" ","_"), - "vm_annotation" : annotation, - "vm_vcpus" : vcpus, - "vm_mem" : memory, - "vm_storage" : "".join(storage_disk_list), - } - - virt_image_xml_template = """ - %(vm_displayName)s - - - %(vm_annotation)s - - - %(virt_boot_template)s - - %(vm_vcpus)s - %(vm_mem)s - - - - - - %(vm_storage)s - - -""" - - virtimage_xml_template = virt_image_xml_template % virt_image_xml_dict - return virtimage_xml_template - -# parse input vmware configuration -def parse_vmware_config(options): - if not os.access(options.input_file, os.R_OK): - raise ValueError, "Could not read file: %s" % options.input_file - infile = open(options.input_file, "r") - contents = infile.readlines() - infile.close() - record = {} - vm_config = [] - disks_list = [] - -# strip out comment and blank lines for easy splitting of values - for line in contents: - if not line.strip() or line.startswith("#"): - continue - else: - vm_config.append(line) - - for line in vm_config: - before_eq, after_eq = line.split("=", 1) - key = before_eq.replace(" ","") - value = after_eq.replace('"',"") - value = value.strip() - record[key] = value - logging.debug("Key: %s Value: \"%s\"" % (key, value)) - if value.endswith("vmdk"): # separate disks from config - disks_list.append(value) - return record, disks_list - - -def convert_disks(disks_list, options): - for disk in disks_list: - infile = disk.strip() - if not os.path.isabs(infile): - infile = os.path.join(options.input_dir, infile) - - outfile = disk.replace(".vmdk","").strip() - outfile += ".img" - if not os.path.isabs(outfile): - outfile = os.path.join(options.output_dir, outfile) - convert_cmd = "qemu-img convert %s -O raw %s" % (infile, outfile) - if os.system(convert_cmd) != 0: - logging.error("Converting disk %s failed.\n" % infile) - sys.exit(1) - - def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) - vm_config = parse_vmware_config(options) - record, disks_list = vm_config + try: + inp = virtconv.vmconfig.find_parser_by_name(options.inputformat) + except: + logging.error("No parser of format \"%s\" was found." % + options.inputformat) + sys.exit(1) + try: + outp = virtconv.vmconfig.find_parser_by_name(options.outputformat) + except: + logging.error("No parser of format \"%s\" was found." % + options.outputformat) + sys.exit(1) + + vmdef = None + + try: + vmdef = inp.import_file(options.input_file) + except IOError, e: + logging.error("Couldn't import file \"%s\": %s" % + (options.input_file, e.strerror)) + sys.exit(1) + except Exception, e: + logging.error("Couldn't import file \"%s\": %s" % + (options.input_file, e.message)) + sys.exit(1) + if options.paravirt: - hvm = False + vmdef.type = vmconfig.VM_TYPE_PV else: - hvm = True - out_contents = vmx_to_image_xml(disks_list, record, options, hvm) + vmdef.type = vmconfig.VM_TYPE_HVM - name = record["displayName"].replace(" ","-") + vmdef.arch = options.arch + + unixname = vmdef.name.replace(" ", "-") if not options.output_dir: - options.output_dir = name + options.output_dir = unixname try: logging.debug("Creating directory %s" % options.output_dir) os.mkdir(options.output_dir) except OSError, e: if (e.errno != errno.EEXIST): logging.error("Could not create directory %s: %s" % - (options.output_dir, str(e))) + (options.output_dir, e.strerror)) sys.exit(1) if not options.output_file: options.output_file = os.path.join(options.output_dir, - "%s.virt-image.xml" % name) + "%s%s" % (unixname, outp.suffix)) logging.debug("input_file: %s" % options.input_file) logging.debug("input_dir: %s" % options.input_dir) logging.debug("output_file: %s" % options.output_file) logging.debug("output_dir: %s" % options.input_dir) - # configuration completed, ready to write config file and convert disks - out = open(options.output_file, "w") - out.writelines(out_contents) - out.close() - convert_disks(disks_list, options) + try: + for d in vmdef.disks: + d.convert(options.input_dir, options.output_dir, + vmconfig.DISK_TYPE_RAW) + except Exception, e: + logging.error(e) + sys.exit(1) + try: + outp.export_file(vmdef, options.output_file) + except Exception, e: + logging.error(e) + sys.exit(1) + print "\n\nConversion completed and placed in: %s" % options.output_dir diff --git a/virtconv/__init__.py b/virtconv/__init__.py new file mode 100644 --- /dev/null +++ b/virtconv/__init__.py @@ -0,0 +1,29 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +import pkgutil +import imp +import os + +parsers_path = [os.path.join(__path__[0], "parsers/")] + +for loader, name, ispkg in pkgutil.iter_modules(parsers_path): + filename, pathname, desc = imp.find_module(name, parsers_path) + imp.load_module(name, filename, pathname, desc) diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py new file mode 100644 --- /dev/null +++ b/virtconv/parsers/virtimage.py @@ -0,0 +1,152 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +from string import ascii_letters +import virtconv.vmconfig as vmconfig + +pv_boot_template = """ + + + %(arch)s + + + + + + pygrub + + %(pv_disks)s + +""" + +hvm_boot_template = """ + + + %(arch)s + + + + + %(hvm_disks)s + +""" + +image_template = """ + + %(name)s + + + %(description)s + + + %(boot_template)s + + %(nr_vcpus)s + %(memory)s + + + + + + %(storage)s + + +""" + +class virtimage_parser(vmconfig.parser): + """ + Support for virt-install's image format (see virt-image man page). + """ + name = "virt-image" + suffix = ".virt-image.xml" + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + raise NotImplementedError + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + + if not vm.memory: + raise ValueError("VM must have a memory setting") + + pv_disks = [] + hvm_disks = [] + storage_disks = [] + + # create disk filename lists for xml template + for disk in vm.disks: + number = disk.number + path = disk.path + + # FIXME: needs updating for later Xen enhancements; need to + # implement capabilities checking for max disks etc. + pv_disks.append("""""" % + (path, ascii_letters[number % 26])) + hvm_disks.append("""""" % + (path, ascii_letters[number % 26])) + storage_disks.append( + """""" % path) + + if vm.type == vmconfig.VM_TYPE_PV: + boot_template = pv_boot_template + else: + boot_template = hvm_boot_template + + boot_xml = boot_template % { + "pv_disks" : "".join(pv_disks), + "hvm_disks" : "".join(hvm_disks), + "arch" : vm.arch, + } + + out = image_template % { + "boot_template": boot_xml, + "name" : vm.name, + "description" : vm.description, + "nr_vcpus" : vm.nr_vcpus, + # Mb to Kb + "memory" : int(vm.memory) * 1024, + "storage" : "".join(storage_disks), + } + + outfile = open(output_file, "w") + outfile.writelines(out) + outfile.close() + +vmconfig.register_parser(virtimage_parser) diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py new file mode 100644 --- /dev/null +++ b/virtconv/parsers/vmx.py @@ -0,0 +1,107 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +import virtconv.vmconfig as vmconfig + +class vmx_parser(vmconfig.parser): + """ + Support for VMWare .vmx files. Note that documentation is + particularly sparse on this format, with pretty much the best + resource being http://sanbarrow.com/vmx.html + """ + + name = "vmx" + suffix = ".vmx" + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + + vm = vmconfig.vm() + + infile = open(input_file, "r") + contents = infile.readlines() + infile.close() + + lines = [] + + # strip out comment and blank lines for easy splitting of values + for line in contents: + if not line.strip() or line.startswith("#"): + continue + else: + lines.append(line) + + config = {} + + # split out all remaining entries of key = value form + for (line_nr, line) in enumerate(lines): + try: + before_eq, after_eq = line.split("=", 1) + key = before_eq.replace(" ","") + value = after_eq.replace('"',"") + value = value.strip() + config[key] = value + except: + raise Exception("Syntax error at line %d: %s" % + (line_nr + 1, line.strip())) + + if not config.get("displayName"): + raise ValueError("No displayName defined in \"%s\"" % input_file) + vm.name = config.get("displayName") + + vm.memory = config.get("memsize") + vm.description = config.get("annotation") + vm.nr_vcpus = config.get("numvcpus") + + # FIXME: this should probably be a lot smarter. I don't think + # this even gets disk numbering right. + disks = [ d for d in config.values() if d.endswith(".vmdk") ] + + for (number, path) in enumerate(disks): + vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] + + vm.validate() + return vm + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + + raise NotImplementedError + +vmconfig.register_parser(vmx_parser) diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py new file mode 100644 --- /dev/null +++ b/virtconv/vmconfig.py @@ -0,0 +1,195 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +import os + +_parsers = [ ] + +VM_TYPE_PV = 0 +VM_TYPE_HVM = 1 + +DISK_TYPE_RAW = 0 +DISK_TYPE_VMDK = 1 + +disk_suffixes = { + DISK_TYPE_RAW: ".img", + DISK_TYPE_VMDK: ".vmdk", +} + +qemu_formats = { + DISK_TYPE_RAW: "raw", + DISK_TYPE_VMDK: "vmdk", +} + +class disk(object): + """Definition of an individual disk instance.""" + + def __init__(self, path = None, number = None, type = None): + self.path = path + self.number = number + self.type = type + + def convert(self, input_dir, output_dir, output_type): + """ + Convert a disk into the requested format if possible, in the + given output directory. Raises NotImplementedError or other + failures. + """ + + if self.type == output_type: + return + + if output_type != DISK_TYPE_RAW: + raise NotImplementedError("Cannot convert to disk type %d" % + output_type) + + infile = self.path + + if not os.path.isabs(infile): + infile = os.path.join(input_dir, infile) + + outfile = self.path + + if os.path.isabs(outfile): + outfile = os.path.basename(outfile) + + outfile = outfile.replace(disk_suffixes[self.type], + disk_suffixes[output_type]).strip() + + convert_cmd = ("qemu-img convert \"%s\" -O %s \"%s\"" % + (infile, qemu_formats[output_type], + os.path.join(output_dir, outfile))) + + ret = os.system(convert_cmd) + if ret != 0: + raise OSError("qemu-img failed with exit status %d" % ret) + + # Note: this is the *relative* path still + self.path = outfile + self.type = output_type + + +class vm(object): + """ + Generic configuration for a particular VM instance. + + At export, a plugin is guaranteed to have the at least the following + values set (any others needed should be checked for, raising + ValueError on failure): + + vm.name + vm.description (defaults to empty string) + vm.nr_vcpus (defaults to 1) + vm.type + vm.arch + + If vm.memory is set, it is in Mb units. + """ + + name = None + suffix = None + + def __init__(self): + self.name = None + self.description = None + self.memory = None + self.nr_vcpus = None + self.disks = [ ] + self.type = VM_TYPE_HVM + self.arch = "i686" # FIXME? + + def validate(self): + """ + Validate all parameters, and fix up any unset values to meet the + guarantees we make above. + """ + + if not self.name: + raise ValueError("VM name is not set") + if not self.description: + self.description = "" + if not self.nr_vcpus: + self.nr_vcpus = 1 + if not self.type: + raise ValueError("VM type is not set") + if not self.arch: + raise ValueError("VM arch is not set") + + +class parser(object): + """ + Base class for particular config file format definitions of + a VM instance. + + Warning: this interface is not (yet) considered stable and may + change at will. + """ + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + raise NotImplementedError + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @output_file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + raise NotImplementedError + + +def register_parser(parser): + """ + Register a particular config format parser. This should be called by each + config plugin on import. + """ + + global _parsers + _parsers += [ parser ] + +def find_parser_by_name(name): + """ + Return the parser of the given name + """ + return [p for p in _parsers if p.name == name][0] or None + +def find_parser_by_file(input_file): + """ + Return the parser that is capable of comprehending the given file. + """ + for p in _parsers: + if p.identify_file(input_file): + return p + return None From robin-lists at robinbowes.com Wed Jul 2 08:21:21 2008 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 02 Jul 2008 09:21:21 +0100 Subject: [et-mgmt-tools] Re: New mailing list for Cobbler In-Reply-To: <486A6BBE.20109@redhat.com> References: <486A6BBE.20109@redhat.com> Message-ID: Michael, Did you make sure the new list is also ported to gmane? R. From sakaia at jp.fujitsu.com Wed Jul 2 10:05:43 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Wed, 02 Jul 2008 19:05:43 +0900 Subject: [et-mgmt-tools] [FYI] Build error of virt-unpack Message-ID: <200807021005.m62A5hJi007264@fjmscan503.ms.jp.fujitsu.com> Hi, Cole FYI virt-unpack need to add to rpmbuild file. http://builder.virt-manager.org/logs/modules/virtinst--devel-build-output.log RPM build errors: error: Installed (but unpackaged) file(s) found: /usr/bin/virt-unpack Installed (but unpackaged) file(s) found: /usr/bin/virt-unpack Thanks Atsushi SAKAI From "Bryan M. Kearney " at redhat.com Wed Jul 2 13:45:55 2008 From: "Bryan M. Kearney " at redhat.com ("Bryan M. Kearney " at redhat.com) Date: Wed, 02 Jul 2008 09:45:55 -0400 Subject: [et-mgmt-tools] [PATCH] Resend: Add a --remove flag to allow virt-image to install new imageswhen an existing one with the same name is defined Message-ID: # HG changeset patch # User "Bryan M. Kearney " # Date 1215006150 14400 # Node ID cada7b0a146fb7b4c187a9043ac2a33d2350268b # Parent 5d9cf6c2662494d21d84fbafbc0b7980096b1998 Add a --remove flag to allow virt-image to install new images when an existing one with the same name is defined diff -r 5d9cf6c26624 -r cada7b0a146f virt-image --- a/virt-image Wed Jul 02 10:50:05 2008 +0100 +++ b/virt-image Wed Jul 02 09:42:30 2008 -0400 @@ -142,7 +142,10 @@ def parse_args(): help=_("The zero-based index of the boot record to use")) parser.add_option("", "--force", action="store_true", dest="force", help=_("Do not prompt for input. Answers yes where applicable, terminates for all other prompts"), - default=False) + default=False) + parser.add_option("", "--replace",action="store_true", dest="replace", + help=_("Overwrite, or destroy, an existing image with the same name"), + default=False) (options,args) = parser.parse_args() if len(args) < 1: @@ -211,7 +214,7 @@ def main(): try: print _("\n\nCreating guest %s...") % guest.name - dom = guest.start_install(None, progresscb) + dom = guest.start_install(None, progresscb, options.replace) if dom is None: print _("Guest creation failed") sys.exit(1) diff -r 5d9cf6c26624 -r cada7b0a146f virtinst/Guest.py --- a/virtinst/Guest.py Wed Jul 02 10:50:05 2008 +0100 +++ b/virtinst/Guest.py Wed Jul 02 09:42:30 2008 -0400 @@ -914,7 +914,7 @@ class Guest(object): "action": action } - def start_install(self, consolecb = None, meter = None): + def start_install(self, consolecb = None, meter = None, removeOld = False): """Do the startup of the guest installation.""" self.validate_parms() @@ -924,7 +924,7 @@ class Guest(object): self._prepare_install(meter) try: - return self._do_install(consolecb, meter) + return self._do_install(consolecb, meter, removeOld) finally: self._installer.cleanup() @@ -932,10 +932,22 @@ class Guest(object): self._install_disks = self.disks[:] self._install_nics = self.nics[:] - def _do_install(self, consolecb, meter): + def _do_install(self, consolecb, meter ,removeOld = False): try: - if self.conn.lookupByName(self.name) is not None: - raise RuntimeError, _("Domain named %s already exists!") %(self.name,) + vm = self.conn.lookupByName(self.name) + if removeOld: + if vm is not None: + if vm.ID() != -1: + logging.info("Destroying image %s" %(self.name)) + vm.destroy() + try: + logging.info("Removing old definition for image %s" %(self.name)) + vm.undefine() + except libvirt.libvirtError, e: + raise RuntimeError, _("Could not remove old vm '%s': %s") %(self.name, str(e)) + else: + if vm is not None: + raise RuntimeError, _("Domain named %s already exists!") %(self.name,) except libvirt.libvirtError: pass From crobinso at redhat.com Wed Jul 2 14:18:11 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 02 Jul 2008 10:18:11 -0400 Subject: [et-mgmt-tools] [PATCH] Resend: Add a --remove flag to allow virt-image to install new imageswhen an existing one with the same name is defined In-Reply-To: References: Message-ID: <486B8E23.1050603@redhat.com> "Bryan M. Kearney "@redhat.com wrote: > # HG changeset patch > # User "Bryan M. Kearney " > # Date 1215006150 14400 > # Node ID cada7b0a146fb7b4c187a9043ac2a33d2350268b > # Parent 5d9cf6c2662494d21d84fbafbc0b7980096b1998 > Add a --remove flag to allow virt-image to install new images when an existing one with the same name is defined > > diff -r 5d9cf6c26624 -r cada7b0a146f virt-image > --- a/virt-image Wed Jul 02 10:50:05 2008 +0100 > +++ b/virt-image Wed Jul 02 09:42:30 2008 -0400 > @@ -142,7 +142,10 @@ def parse_args(): > help=_("The zero-based index of the boot record to use")) > parser.add_option("", "--force", action="store_true", dest="force", > help=_("Do not prompt for input. Answers yes where applicable, terminates for all other prompts"), > - default=False) > + default=False) > + parser.add_option("", "--replace",action="store_true", dest="replace", > + help=_("Overwrite, or destroy, an existing image with the same name"), > + default=False) > > (options,args) = parser.parse_args() > if len(args) < 1: > @@ -211,7 +214,7 @@ def main(): > try: > print _("\n\nCreating guest %s...") % guest.name > > - dom = guest.start_install(None, progresscb) > + dom = guest.start_install(None, progresscb, options.replace) > if dom is None: > print _("Guest creation failed") > sys.exit(1) > diff -r 5d9cf6c26624 -r cada7b0a146f virtinst/Guest.py > --- a/virtinst/Guest.py Wed Jul 02 10:50:05 2008 +0100 > +++ b/virtinst/Guest.py Wed Jul 02 09:42:30 2008 -0400 > @@ -914,7 +914,7 @@ class Guest(object): > "action": action } > > > - def start_install(self, consolecb = None, meter = None): > + def start_install(self, consolecb = None, meter = None, removeOld = False): > """Do the startup of the guest installation.""" > self.validate_parms() > > @@ -924,7 +924,7 @@ class Guest(object): > > self._prepare_install(meter) > try: > - return self._do_install(consolecb, meter) > + return self._do_install(consolecb, meter, removeOld) > finally: > self._installer.cleanup() > > @@ -932,10 +932,22 @@ class Guest(object): > self._install_disks = self.disks[:] > self._install_nics = self.nics[:] > > - def _do_install(self, consolecb, meter): > + def _do_install(self, consolecb, meter ,removeOld = False): > try: > - if self.conn.lookupByName(self.name) is not None: > - raise RuntimeError, _("Domain named %s already exists!") %(self.name,) > + vm = self.conn.lookupByName(self.name) > + if removeOld: > + if vm is not None: > + if vm.ID() != -1: > + logging.info("Destroying image %s" %(self.name)) > + vm.destroy() > + try: > + logging.info("Removing old definition for image %s" %(self.name)) > + vm.undefine() > + except libvirt.libvirtError, e: > + raise RuntimeError, _("Could not remove old vm '%s': %s") %(self.name, str(e)) > + else: > + if vm is not None: > + raise RuntimeError, _("Domain named %s already exists!") %(self.name,) > except libvirt.libvirtError: > pass > Hi, I responded to your initial posting yesterday, but forgot to cc you so maybe you missed it. Most of it is still relevant: https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00047.html If you address that issue I think the patch will be fine to commit. Thanks, Cole From bkearney at redhat.com Wed Jul 2 14:19:19 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 02 Jul 2008 10:19:19 -0400 Subject: [et-mgmt-tools] [PATCH] Resend: Add a --remove flag to allow virt-image to install new imageswhen an existing one with the same name is defined In-Reply-To: <486B8E23.1050603@redhat.com> References: <486B8E23.1050603@redhat.com> Message-ID: <486B8E67.7060802@redhat.com> Cole Robinson wrote: > "Bryan M. Kearney "@redhat.com wrote: >> # HG changeset patch >> # User "Bryan M. Kearney " >> # Date 1215006150 14400 >> # Node ID cada7b0a146fb7b4c187a9043ac2a33d2350268b >> # Parent 5d9cf6c2662494d21d84fbafbc0b7980096b1998 >> Add a --remove flag to allow virt-image to install new images when an existing one with the same name is defined >> >> diff -r 5d9cf6c26624 -r cada7b0a146f virt-image >> --- a/virt-image Wed Jul 02 10:50:05 2008 +0100 >> +++ b/virt-image Wed Jul 02 09:42:30 2008 -0400 >> @@ -142,7 +142,10 @@ def parse_args(): >> help=_("The zero-based index of the boot record to use")) >> parser.add_option("", "--force", action="store_true", dest="force", >> help=_("Do not prompt for input. Answers yes where applicable, terminates for all other prompts"), >> - default=False) >> + default=False) >> + parser.add_option("", "--replace",action="store_true", dest="replace", >> + help=_("Overwrite, or destroy, an existing image with the same name"), >> + default=False) >> >> (options,args) = parser.parse_args() >> if len(args) < 1: >> @@ -211,7 +214,7 @@ def main(): >> try: >> print _("\n\nCreating guest %s...") % guest.name >> >> - dom = guest.start_install(None, progresscb) >> + dom = guest.start_install(None, progresscb, options.replace) >> if dom is None: >> print _("Guest creation failed") >> sys.exit(1) >> diff -r 5d9cf6c26624 -r cada7b0a146f virtinst/Guest.py >> --- a/virtinst/Guest.py Wed Jul 02 10:50:05 2008 +0100 >> +++ b/virtinst/Guest.py Wed Jul 02 09:42:30 2008 -0400 >> @@ -914,7 +914,7 @@ class Guest(object): >> "action": action } >> >> >> - def start_install(self, consolecb = None, meter = None): >> + def start_install(self, consolecb = None, meter = None, removeOld = False): >> """Do the startup of the guest installation.""" >> self.validate_parms() >> >> @@ -924,7 +924,7 @@ class Guest(object): >> >> self._prepare_install(meter) >> try: >> - return self._do_install(consolecb, meter) >> + return self._do_install(consolecb, meter, removeOld) >> finally: >> self._installer.cleanup() >> >> @@ -932,10 +932,22 @@ class Guest(object): >> self._install_disks = self.disks[:] >> self._install_nics = self.nics[:] >> >> - def _do_install(self, consolecb, meter): >> + def _do_install(self, consolecb, meter ,removeOld = False): >> try: >> - if self.conn.lookupByName(self.name) is not None: >> - raise RuntimeError, _("Domain named %s already exists!") %(self.name,) >> + vm = self.conn.lookupByName(self.name) >> + if removeOld: >> + if vm is not None: >> + if vm.ID() != -1: >> + logging.info("Destroying image %s" %(self.name)) >> + vm.destroy() >> + try: >> + logging.info("Removing old definition for image %s" %(self.name)) >> + vm.undefine() >> + except libvirt.libvirtError, e: >> + raise RuntimeError, _("Could not remove old vm '%s': %s") %(self.name, str(e)) >> + else: >> + if vm is not None: >> + raise RuntimeError, _("Domain named %s already exists!") %(self.name,) >> except libvirt.libvirtError: >> pass >> > > Hi, I responded to your initial posting yesterday, but forgot to cc you > so maybe you missed it. Most of it is still relevant: > > https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00047.html > > If you address that issue I think the patch will be fine to commit. > > Thanks, > Cole I thought it did... the internal libvirt errors from the undefine/destroy are turned into a Rentime error which should be propegated up. -- bk From crobinso at redhat.com Wed Jul 2 14:28:26 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 02 Jul 2008 10:28:26 -0400 Subject: [et-mgmt-tools] [PATCH] Resend: Add a --remove flag to allow virt-image to install new imageswhen an existing one with the same name is defined In-Reply-To: <486B8E67.7060802@redhat.com> References: <486B8E23.1050603@redhat.com> <486B8E67.7060802@redhat.com> Message-ID: <486B908A.8010304@redhat.com> Bryan Kearney wrote: > > Cole Robinson wrote: >> "Bryan M. Kearney "@redhat.com wrote: >>> # HG changeset patch >>> # User "Bryan M. Kearney " >>> # Date 1215006150 14400 >>> # Node ID cada7b0a146fb7b4c187a9043ac2a33d2350268b >>> # Parent 5d9cf6c2662494d21d84fbafbc0b7980096b1998 >>> Add a --remove flag to allow virt-image to install new images when an existing one with the same name is defined >>> >>> diff -r 5d9cf6c26624 -r cada7b0a146f virt-image >>> --- a/virt-image Wed Jul 02 10:50:05 2008 +0100 >>> +++ b/virt-image Wed Jul 02 09:42:30 2008 -0400 >>> @@ -142,7 +142,10 @@ def parse_args(): >>> help=_("The zero-based index of the boot record to use")) >>> parser.add_option("", "--force", action="store_true", dest="force", >>> help=_("Do not prompt for input. Answers yes where applicable, terminates for all other prompts"), >>> - default=False) >>> + default=False) >>> + parser.add_option("", "--replace",action="store_true", dest="replace", >>> + help=_("Overwrite, or destroy, an existing image with the same name"), >>> + default=False) >>> >>> (options,args) = parser.parse_args() >>> if len(args) < 1: >>> @@ -211,7 +214,7 @@ def main(): >>> try: >>> print _("\n\nCreating guest %s...") % guest.name >>> >>> - dom = guest.start_install(None, progresscb) >>> + dom = guest.start_install(None, progresscb, options.replace) >>> if dom is None: >>> print _("Guest creation failed") >>> sys.exit(1) >>> diff -r 5d9cf6c26624 -r cada7b0a146f virtinst/Guest.py >>> --- a/virtinst/Guest.py Wed Jul 02 10:50:05 2008 +0100 >>> +++ b/virtinst/Guest.py Wed Jul 02 09:42:30 2008 -0400 >>> @@ -914,7 +914,7 @@ class Guest(object): >>> "action": action } >>> >>> >>> - def start_install(self, consolecb = None, meter = None): >>> + def start_install(self, consolecb = None, meter = None, removeOld = False): >>> """Do the startup of the guest installation.""" >>> self.validate_parms() >>> >>> @@ -924,7 +924,7 @@ class Guest(object): >>> >>> self._prepare_install(meter) >>> try: >>> - return self._do_install(consolecb, meter) >>> + return self._do_install(consolecb, meter, removeOld) >>> finally: >>> self._installer.cleanup() >>> >>> @@ -932,10 +932,22 @@ class Guest(object): >>> self._install_disks = self.disks[:] >>> self._install_nics = self.nics[:] >>> >>> - def _do_install(self, consolecb, meter): >>> + def _do_install(self, consolecb, meter ,removeOld = False): >>> try: >>> - if self.conn.lookupByName(self.name) is not None: >>> - raise RuntimeError, _("Domain named %s already exists!") %(self.name,) >>> + vm = self.conn.lookupByName(self.name) >>> + if removeOld: >>> + if vm is not None: >>> + if vm.ID() != -1: >>> + logging.info("Destroying image %s" %(self.name)) >>> + vm.destroy() >>> + try: >>> + logging.info("Removing old definition for image %s" %(self.name)) >>> + vm.undefine() >>> + except libvirt.libvirtError, e: >>> + raise RuntimeError, _("Could not remove old vm '%s': %s") %(self.name, str(e)) >>> + else: >>> + if vm is not None: >>> + raise RuntimeError, _("Domain named %s already exists!") %(self.name,) >>> except libvirt.libvirtError: >>> pass >>> >> Hi, I responded to your initial posting yesterday, but forgot to cc you >> so maybe you missed it. Most of it is still relevant: >> >> https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00047.html >> >> If you address that issue I think the patch will be fine to commit. >> >> Thanks, >> Cole > > > I thought it did... the internal libvirt errors from the > undefine/destroy are turned into a Rentime error which should be > propegated up. > > -- bk If vm.destroy() raises an exception in the above code, it will only be caught by the outer except: which ignores libvirterrors, so the failure will be thrown away. I would say move the changed code outside the outer exception handler. If you initialize the vm variable as None, then everything will just work provided you put the vm.destroy in the inner try block. - Cole From crobinso at redhat.com Wed Jul 2 14:36:04 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 02 Jul 2008 10:36:04 -0400 Subject: [et-mgmt-tools] [PATCH] Extend virt-unpack options In-Reply-To: <20080701192355.GD11119@totally.trollied.org.uk> References: <20080701192355.GD11119@totally.trollied.org.uk> Message-ID: <486B9254.9030203@redhat.com> John Levon wrote: > Extend virt-unpack options > > Fix up virt-unpack options to allow both input and output directories, > and formats other than vmx->virt-image. This is just the first step of > moving towards virt-convert. > Committed: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=2bbc65f542f6 Thanks, Cole From crobinso at redhat.com Wed Jul 2 14:38:48 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 02 Jul 2008 10:38:48 -0400 Subject: [et-mgmt-tools] [PATCH] Make lack of 'numvcpus' a warning only In-Reply-To: <20080701193744.GA13745@totally.trollied.org.uk> References: <20080701192529.GG11119@totally.trollied.org.uk> <20080701192801.GB31728@redhat.com> <20080701193744.GA13745@totally.trollied.org.uk> Message-ID: <486B92F8.9000004@redhat.com> John Levon wrote: > On Tue, Jul 01, 2008 at 08:28:01PM +0100, Daniel P. Berrange wrote: > >>> diff --git a/virt-unpack b/virt-unpack >>> --- a/virt-unpack >>> +++ b/virt-unpack >>> @@ -119,7 +119,7 @@ def vmx_to_image_xml(disks_list,record,o >>> if record.has_key("numvcpus"): >>> vcpus = record["numvcpus"] >>> else: >>> - logging.error("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) >>> + logging.warning("numvcpus key not parsed from %s, defaulting to 1 virtual cpu" % file) >>> vcpus = "1" >> IMHO, we shoudn't bother logging anything just silently default >> it to 1. > > Fine by me. What about 'annotation'? I couldn't find this documented on > sanbarrow.com > > regards > john > Since annotation seems to just represent a machine description which can't be an essential piece, I just removed the logging for it, as well as for the vcpu default: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=ed588cd21acb Thanks, Cole From crobinso at redhat.com Wed Jul 2 14:48:08 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 02 Jul 2008 10:48:08 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: arch is required In-Reply-To: <20080702045051.GD16405@totally.trollied.org.uk> References: <20080702045051.GD16405@totally.trollied.org.uk> Message-ID: <486B9528.1000407@redhat.com> John Levon wrote: > Fix usage message > > The -a option is required; reflect this in the help message. > > Signed-off-by: John Levon > > diff --git a/virt-convert b/virt-convert > --- a/virt-convert > +++ b/virt-convert > @@ -30,7 +30,7 @@ from optparse import OptionParser > > def parse_args(): > parser = OptionParser() > - parser.set_usage("%prog [options] inputdir|input.vmx " > + parser.set_usage("%prog [options] -a arch inputdir|input.vmx " > "[outputdir|output.xml]") > parser.add_option("-a", "--arch", type="string", dest="arch", > help=("Machine Architecture Type (i686/x86_64/ppc)")) > I realize this is just a docs change but we probably shouldn't require arch to be specified. Seems sensible just to default to the host arch if it is in some supported whitelist. - Cole From crobinso at redhat.com Wed Jul 2 14:55:27 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 02 Jul 2008 10:55:27 -0400 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <20080701192436.GE11119@totally.trollied.org.uk> References: <20080701192436.GE11119@totally.trollied.org.uk> Message-ID: <486B96DF.90406@redhat.com> John Levon wrote: > Check result of qemu-img > > If qemu-img convert fails, report an error and exit. > > Signed-off-by: John Levon > > diff --git a/virt-unpack b/virt-unpack > --- a/virt-unpack > +++ b/virt-unpack > @@ -237,8 +237,9 @@ def convert_disks(disks_list, options): > if not os.path.isabs(outfile): > outfile = os.path.join(options.output_dir, outfile) > convert_cmd="qemu-img convert %s -O raw %s" % (infile, outfile) > - ret = os.system(convert_cmd) > - print ret > + if os.system(convert_cmd) != 0: > + logging.error("Converting disk %s failed.\n" % infile) > + sys.exit(1) > > > def main(): > Is just exiting the right choice here? Seems like we should do some cleanup. Also for future reference it might be a good idea to iterate through the list of disks and try 'qemu-img info' to make sure the disk at least appears to be in the correct format before we convert. - Cole From crobinso at redhat.com Wed Jul 2 14:59:24 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 02 Jul 2008 10:59:24 -0400 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <20080701192436.GE11119@totally.trollied.org.uk> References: <20080701192436.GE11119@totally.trollied.org.uk> Message-ID: <486B97CC.6060409@redhat.com> John Levon wrote: > Check result of qemu-img > > If qemu-img convert fails, report an error and exit. > > Signed-off-by: John Levon > Just pointing out that I committed everything you posted prior to this, excluding this and the arch docs patch. Thanks, Cole From levon at movementarian.org Wed Jul 2 15:05:59 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 16:05:59 +0100 Subject: [et-mgmt-tools] [PATCH] Check result of qemu-img In-Reply-To: <486B96DF.90406@redhat.com> References: <20080701192436.GE11119@totally.trollied.org.uk> <486B96DF.90406@redhat.com> Message-ID: <20080702150559.GI23929@totally.trollied.org.uk> On Wed, Jul 02, 2008 at 10:55:27AM -0400, Cole Robinson wrote: > Is just exiting the right choice here? Seems like we should do some cleanup. In my tip version, the only possible cleanup is to remove a created directory plus any already-created files, but yes, I'll look at doing that. > Also for future reference it might be a good idea to iterate through the > list of disks and try 'qemu-img info' to make sure the disk at least appears > to be in the correct format before we convert. Sounds like a good idea. regards john From "Bryan M. Kearney " at redhat.com Wed Jul 2 15:17:05 2008 From: "Bryan M. Kearney " at redhat.com ("Bryan M. Kearney " at redhat.com) Date: Wed, 02 Jul 2008 11:17:05 -0400 Subject: [et-mgmt-tools] [PATCH] Resend (hopefully final) adding of --replace command for virt-image Message-ID: <3e86a75795e73277056b.1215011825@localhost.localdomain> # HG changeset patch # User "Bryan M. Kearney " # Date 1215011615 14400 # Node ID 3e86a75795e73277056bfcea0c54b97f7a5945e9 # Parent 5d9cf6c2662494d21d84fbafbc0b7980096b1998 Add a --remove flag to allow virt-image to install new images when an existing one with the same name is defined diff -r 5d9cf6c26624 -r 3e86a75795e7 virt-image --- a/virt-image Wed Jul 02 10:50:05 2008 +0100 +++ b/virt-image Wed Jul 02 11:13:35 2008 -0400 @@ -142,7 +142,10 @@ def parse_args(): help=_("The zero-based index of the boot record to use")) parser.add_option("", "--force", action="store_true", dest="force", help=_("Do not prompt for input. Answers yes where applicable, terminates for all other prompts"), - default=False) + default=False) + parser.add_option("", "--replace",action="store_true", dest="replace", + help=_("Overwrite, or destroy, an existing image with the same name"), + default=False) (options,args) = parser.parse_args() if len(args) < 1: @@ -211,7 +214,7 @@ def main(): try: print _("\n\nCreating guest %s...") % guest.name - dom = guest.start_install(None, progresscb) + dom = guest.start_install(None, progresscb, options.replace) if dom is None: print _("Guest creation failed") sys.exit(1) diff -r 5d9cf6c26624 -r 3e86a75795e7 virtinst/Guest.py --- a/virtinst/Guest.py Wed Jul 02 10:50:05 2008 +0100 +++ b/virtinst/Guest.py Wed Jul 02 11:13:35 2008 -0400 @@ -914,7 +914,7 @@ class Guest(object): "action": action } - def start_install(self, consolecb = None, meter = None): + def start_install(self, consolecb = None, meter = None, removeOld = False): """Do the startup of the guest installation.""" self.validate_parms() @@ -924,7 +924,7 @@ class Guest(object): self._prepare_install(meter) try: - return self._do_install(consolecb, meter) + return self._do_install(consolecb, meter, removeOld) finally: self._installer.cleanup() @@ -932,10 +932,22 @@ class Guest(object): self._install_disks = self.disks[:] self._install_nics = self.nics[:] - def _do_install(self, consolecb, meter): + def _do_install(self, consolecb, meter ,removeOld = False): try: - if self.conn.lookupByName(self.name) is not None: - raise RuntimeError, _("Domain named %s already exists!") %(self.name,) + vm = self.conn.lookupByName(self.name) + if removeOld: + if vm is not None: + try: + if vm.ID() != -1: + logging.info("Destroying image %s" %(self.name)) + vm.destroy() + logging.info("Removing old definition for image %s" %(self.name)) + vm.undefine() + except libvirt.libvirtError, e: + raise RuntimeError, _("Could not remove old vm '%s': %s") %(self.name, str(e)) + else: + if vm is not None: + raise RuntimeError, _("Domain named %s already exists!") %(self.name,) except libvirt.libvirtError: pass From levon at movementarian.org Wed Jul 2 16:04:08 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 17:04:08 +0100 Subject: [et-mgmt-tools] [PATCH] modular virt-convert Message-ID: <20080702160408.GN23929@totally.trollied.org.uk> This is merged with current tip and now installs properly. thanks john Create config parser plugin system Start a plugin system for config formats parsing, and implement enough of it to get to where we were with virt-convert. Signed-off-by: John Levon diff --git a/setup.py b/setup.py --- a/setup.py +++ b/setup.py @@ -9,7 +9,8 @@ import os, sys import os, sys import tests.coverage as coverage -pkgs = ['virtinst'] +pkgs = ['virtinst', 'virtconv', 'virtconv.parsers' ] + datafiles = [('share/man/man1', ['man/en/virt-install.1', 'man/en/virt-clone.1', 'man/en/virt-image.1', diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -21,56 +21,58 @@ # MA 02110-1301 USA. import sys -from string import ascii_letters -import virtinst.cli as cli import os import logging import errno from optparse import OptionParser +import virtinst.cli as cli +import virtconv +import virtconv.vmconfig as vmconfig + def parse_args(): - parser = OptionParser() - parser.set_usage("%prog [options] inputdir|input.vmx " + opts = OptionParser() + opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") - parser.add_option("-a", "--arch", type="string", dest="arch", - help=("Machine Architecture Type (i686/x86_64/ppc)")) - parser.add_option("-t", "--type", type="string", dest="type", - help=("Output virtualization type (hvm, paravirt")) - parser.add_option("-d", "--debug", action="store_true", dest="debug", - help=("Print debugging information")) - parser.add_option("-i", "--input-format", action="store", - dest="inputformat", default="vmx", - help=("Input format, e.g. 'vmx'")) - parser.add_option("-o", "--output-format", action="store", - dest="outputformat", default="virt-image", - help=("Output format, e.g. 'virt-image'")) - parser.add_option("-v", "--hvm", action="store_true", dest="fullvirt", - help=("This guest should be a fully virtualized guest")) - parser.add_option("-p", "--paravirt", action="store_true", dest="paravirt", - help=("This guest should be a paravirtualized guest")) + opts.add_option("-a", "--arch", type="string", dest="arch", + help=("Machine Architecture Type (i686/x86_64/ppc)")) + opts.add_option("-t", "--type", type="string", dest="type", + help=("Output virtualization type (hvm, paravirt")) + opts.add_option("-d", "--debug", action="store_true", dest="debug", + help=("Print debugging information")) + opts.add_option("-i", "--input-format", action="store", + dest="inputformat", default="vmx", + help=("Input format, e.g. 'vmx'")) + opts.add_option("-o", "--output-format", action="store", + dest="outputformat", default="virt-image", + help=("Output format, e.g. 'virt-image'")) + opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", + help=("This guest should be a fully virtualized guest")) + opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", + help=("This guest should be a paravirtualized guest")) - (options, args) = parser.parse_args() + (options, args) = opts.parse_args() if len(args) < 1: - parser.error(("You need to provide an input VM definition")) + opts.error(("You need to provide an input VM definition")) if len(args) > 2: - parser.error(("Too many arguments provided")) + opts.error(("Too many arguments provided")) if (options.arch is None): - parser.error(("Missing option value \n\nArchitecture: " + + opts.error(("Missing option value \n\nArchitecture: " + str(options.arch))) # hard-code for now if options.inputformat != "vmx": - parser.error(("Unsupported input format \"%s\"" % options.inputformat)) + opts.error(("Unsupported input format \"%s\"" % options.inputformat)) if options.outputformat != "virt-image": - parser.error(("Unsupported output format \"%s\"" + opts.error(("Unsupported output format \"%s\"" % options.outputformat)) if os.path.isdir(args[0]): vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] if (len(vmx_files)) == 0: - parser.error(("No VM definition file was found in %s" % args[0])) + opts.error(("No VM definition file was found in %s" % args[0])) if (len(vmx_files)) > 1: - parser.error(("Too many .vmx definitions found in %s" % args[0])) + opts.error(("Too many .vmx definitions found in %s" % args[0])) options.input_file = os.path.join(args[0], vmx_files[0]) options.input_dir = args[0] else: @@ -91,197 +93,78 @@ def parse_args(): return options -# Begin creation of xml template from parsed vmx config file -def vmx_to_image_xml(disks_list, record, options, hvm): - pv_disk_list = [] - fv_disk_list = [] - storage_disk_list = [] - - infile = options.input_file - - # validate required values for conversion are in the input vmx file - if record.has_key("displayName"): - name = record["displayName"] - else: - logging.error("displayName key not parsed from %s" % infile) - sys.exit(1) - - if record.has_key("memsize"): - memory = int(record["memsize"]) * 1024 - else: - logging.error("memsize key not parsed from %s" % infile) - sys.exit(1) - - if record.has_key("annotation"): - annotation = record["annotation"] - else: - annotation = "" - - if record.has_key("numvcpus"): - vcpus = record["numvcpus"] - else: - vcpus = "1" - - -# create disk filename lists for xml template - for (number, dfile) in enumerate(disks_list): - dfile = str(dfile.replace(".vmdk","")).strip() - pv_disk_list.append("""""" % \ - (dfile, ascii_letters[number % 26])) - fv_disk_list.append("""""" % \ - (dfile, ascii_letters[number % 26])) - storage_disk_list.append("""""" % (dfile)) - -# determine virtualization type for image.boot section - if hvm is False: - virt_boot_template = """ - - %(vm_arch)s - - - - - - pygrub - - %(vm_pv_disks)s - """ - elif hvm is True: - virt_boot_template = """ - - %(vm_arch)s - - - - - %(vm_fv_disks)s - """ - - -# xml replacements dictionaries - virt_boot_xml_dict = { - "vm_pv_disks" : "".join(pv_disk_list), - "vm_fv_disks" : "".join(fv_disk_list), - "vm_arch" : options.arch, - } - virt_boot_template = virt_boot_template % virt_boot_xml_dict - virt_image_xml_dict = { - "virt_boot_template" : virt_boot_template, - "vm_displayName": name.replace(" ","_"), - "vm_annotation" : annotation, - "vm_vcpus" : vcpus, - "vm_mem" : memory, - "vm_storage" : "".join(storage_disk_list), - } - - virt_image_xml_template = """ - %(vm_displayName)s - - - %(vm_annotation)s - - - %(virt_boot_template)s - - %(vm_vcpus)s - %(vm_mem)s - - - - - - %(vm_storage)s - - -""" - - virtimage_xml_template = virt_image_xml_template % virt_image_xml_dict - return virtimage_xml_template - -# parse input vmware configuration -def parse_vmware_config(options): - if not os.access(options.input_file, os.R_OK): - raise ValueError, "Could not read file: %s" % options.input_file - infile = open(options.input_file, "r") - contents = infile.readlines() - infile.close() - record = {} - vm_config = [] - disks_list = [] - - # strip out comment and blank lines for easy splitting of values - for line in contents: - if not line.strip() or line.startswith("#"): - continue - else: - vm_config.append(line) - - for line in vm_config: - before_eq, after_eq = line.split("=", 1) - key = before_eq.replace(" ","") - value = after_eq.replace('"',"") - value = value.strip() - record[key] = value - logging.debug("Key: %s Value: \"%s\"" % (key, value)) - if value.endswith("vmdk"): # separate disks from config - disks_list.append(value) - return record, disks_list - - -def convert_disks(disks_list, options): - for disk in disks_list: - infile = disk.strip() - if not os.path.isabs(infile): - infile = os.path.join(options.input_dir, infile) - - outfile = disk.replace(".vmdk","").strip() - outfile += ".img" - if not os.path.isabs(outfile): - outfile = os.path.join(options.output_dir, outfile) - convert_cmd = "qemu-img convert %s -O raw %s" % (infile, outfile) - ret = os.system(convert_cmd) - print ret - - def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) - vm_config = parse_vmware_config(options) - record, disks_list = vm_config + try: + inp = virtconv.vmconfig.find_parser_by_name(options.inputformat) + except: + logging.error("No parser of format \"%s\" was found." % + options.inputformat) + sys.exit(1) + + try: + outp = virtconv.vmconfig.find_parser_by_name(options.outputformat) + except: + logging.error("No parser of format \"%s\" was found." % + options.outputformat) + sys.exit(1) + + vmdef = None + + try: + vmdef = inp.import_file(options.input_file) + except IOError, e: + logging.error("Couldn't import file \"%s\": %s" % + (options.input_file, e.strerror)) + sys.exit(1) + except Exception, e: + logging.error("Couldn't import file \"%s\": %s" % + (options.input_file, e.message)) + sys.exit(1) if options.paravirt: - hvm = False + vmdef.type = vmconfig.VM_TYPE_PV else: - hvm = True - out_contents = vmx_to_image_xml(disks_list, record, options, hvm) + vmdef.type = vmconfig.VM_TYPE_HVM - name = record["displayName"].replace(" ","-") + vmdef.arch = options.arch + + unixname = vmdef.name.replace(" ", "-") if not options.output_dir: - options.output_dir = name + options.output_dir = unixname try: logging.debug("Creating directory %s" % options.output_dir) os.mkdir(options.output_dir) except OSError, e: if (e.errno != errno.EEXIST): logging.error("Could not create directory %s: %s" % - (options.output_dir, str(e))) + (options.output_dir, e.strerror)) sys.exit(1) if not options.output_file: options.output_file = os.path.join(options.output_dir, - "%s.virt-image.xml" % name) + "%s%s" % (unixname, outp.suffix)) logging.debug("input_file: %s" % options.input_file) logging.debug("input_dir: %s" % options.input_dir) logging.debug("output_file: %s" % options.output_file) logging.debug("output_dir: %s" % options.input_dir) - # configuration completed, ready to write config file and convert disks - out = open(options.output_file, "w") - out.writelines(out_contents) - out.close() - convert_disks(disks_list, options) + try: + for d in vmdef.disks: + d.convert(options.input_dir, options.output_dir, + vmconfig.DISK_TYPE_RAW) + except Exception, e: + logging.error(e) + sys.exit(1) + + try: + outp.export_file(vmdef, options.output_file) + except Exception, e: + logging.error(e) + sys.exit(1) print "\n\nConversion completed and placed in: %s" % options.output_dir diff --git a/virtconv/__init__.py b/virtconv/__init__.py new file mode 100644 --- /dev/null +++ b/virtconv/__init__.py @@ -0,0 +1,29 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +import pkgutil +import imp +import os + +parsers_path = [os.path.join(__path__[0], "parsers/")] + +for loader, name, ispkg in pkgutil.iter_modules(parsers_path): + filename, pathname, desc = imp.find_module(name, parsers_path) + imp.load_module(name, filename, pathname, desc) diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py new file mode 100644 --- /dev/null +++ b/virtconv/parsers/virtimage.py @@ -0,0 +1,152 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +from string import ascii_letters +import virtconv.vmconfig as vmconfig + +pv_boot_template = """ + + + %(arch)s + + + + + + pygrub + + %(pv_disks)s + +""" + +hvm_boot_template = """ + + + %(arch)s + + + + + %(hvm_disks)s + +""" + +image_template = """ + + %(name)s + + + %(description)s + + + %(boot_template)s + + %(nr_vcpus)s + %(memory)s + + + + + + %(storage)s + + +""" + +class virtimage_parser(vmconfig.parser): + """ + Support for virt-install's image format (see virt-image man page). + """ + name = "virt-image" + suffix = ".virt-image.xml" + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + raise NotImplementedError + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + + if not vm.memory: + raise ValueError("VM must have a memory setting") + + pv_disks = [] + hvm_disks = [] + storage_disks = [] + + # create disk filename lists for xml template + for disk in vm.disks: + number = disk.number + path = disk.path + + # FIXME: needs updating for later Xen enhancements; need to + # implement capabilities checking for max disks etc. + pv_disks.append("""""" % + (path, ascii_letters[number % 26])) + hvm_disks.append("""""" % + (path, ascii_letters[number % 26])) + storage_disks.append( + """""" % path) + + if vm.type == vmconfig.VM_TYPE_PV: + boot_template = pv_boot_template + else: + boot_template = hvm_boot_template + + boot_xml = boot_template % { + "pv_disks" : "".join(pv_disks), + "hvm_disks" : "".join(hvm_disks), + "arch" : vm.arch, + } + + out = image_template % { + "boot_template": boot_xml, + "name" : vm.name, + "description" : vm.description, + "nr_vcpus" : vm.nr_vcpus, + # Mb to Kb + "memory" : int(vm.memory) * 1024, + "storage" : "".join(storage_disks), + } + + outfile = open(output_file, "w") + outfile.writelines(out) + outfile.close() + +vmconfig.register_parser(virtimage_parser) diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py new file mode 100644 --- /dev/null +++ b/virtconv/parsers/vmx.py @@ -0,0 +1,107 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +import virtconv.vmconfig as vmconfig + +class vmx_parser(vmconfig.parser): + """ + Support for VMWare .vmx files. Note that documentation is + particularly sparse on this format, with pretty much the best + resource being http://sanbarrow.com/vmx.html + """ + + name = "vmx" + suffix = ".vmx" + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + + vm = vmconfig.vm() + + infile = open(input_file, "r") + contents = infile.readlines() + infile.close() + + lines = [] + + # strip out comment and blank lines for easy splitting of values + for line in contents: + if not line.strip() or line.startswith("#"): + continue + else: + lines.append(line) + + config = {} + + # split out all remaining entries of key = value form + for (line_nr, line) in enumerate(lines): + try: + before_eq, after_eq = line.split("=", 1) + key = before_eq.replace(" ","") + value = after_eq.replace('"',"") + value = value.strip() + config[key] = value + except: + raise Exception("Syntax error at line %d: %s" % + (line_nr + 1, line.strip())) + + if not config.get("displayName"): + raise ValueError("No displayName defined in \"%s\"" % input_file) + vm.name = config.get("displayName") + + vm.memory = config.get("memsize") + vm.description = config.get("annotation") + vm.nr_vcpus = config.get("numvcpus") + + # FIXME: this should probably be a lot smarter. I don't think + # this even gets disk numbering right. + disks = [ d for d in config.values() if d.endswith(".vmdk") ] + + for (number, path) in enumerate(disks): + vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] + + vm.validate() + return vm + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + + raise NotImplementedError + +vmconfig.register_parser(vmx_parser) diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py new file mode 100644 --- /dev/null +++ b/virtconv/vmconfig.py @@ -0,0 +1,193 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +import os + +_parsers = [ ] + +VM_TYPE_PV = 0 +VM_TYPE_HVM = 1 + +DISK_TYPE_RAW = 0 +DISK_TYPE_VMDK = 1 + +disk_suffixes = { + DISK_TYPE_RAW: ".img", + DISK_TYPE_VMDK: ".vmdk", +} + +qemu_formats = { + DISK_TYPE_RAW: "raw", + DISK_TYPE_VMDK: "vmdk", +} + +class disk(object): + """Definition of an individual disk instance.""" + + def __init__(self, path = None, number = None, type = None): + self.path = path + self.number = number + self.type = type + + def convert(self, input_dir, output_dir, output_type): + """ + Convert a disk into the requested format if possible, in the + given output directory. Raises NotImplementedError or other + failures. + """ + + if self.type == output_type: + return + + if output_type != DISK_TYPE_RAW: + raise NotImplementedError("Cannot convert to disk type %d" % + output_type) + + infile = self.path + + if not os.path.isabs(infile): + infile = os.path.join(input_dir, infile) + + outfile = self.path + + if os.path.isabs(outfile): + outfile = os.path.basename(outfile) + + outfile = outfile.replace(disk_suffixes[self.type], + disk_suffixes[output_type]).strip() + + convert_cmd = ("qemu-img convert \"%s\" -O %s \"%s\"" % + (infile, qemu_formats[output_type], + os.path.join(output_dir, outfile))) + + os.system(convert_cmd) + + # Note: this is the *relative* path still + self.path = outfile + self.type = output_type + + +class vm(object): + """ + Generic configuration for a particular VM instance. + + At export, a plugin is guaranteed to have the at least the following + values set (any others needed should be checked for, raising + ValueError on failure): + + vm.name + vm.description (defaults to empty string) + vm.nr_vcpus (defaults to 1) + vm.type + vm.arch + + If vm.memory is set, it is in Mb units. + """ + + name = None + suffix = None + + def __init__(self): + self.name = None + self.description = None + self.memory = None + self.nr_vcpus = None + self.disks = [ ] + self.type = VM_TYPE_HVM + self.arch = "i686" # FIXME? + + def validate(self): + """ + Validate all parameters, and fix up any unset values to meet the + guarantees we make above. + """ + + if not self.name: + raise ValueError("VM name is not set") + if not self.description: + self.description = "" + if not self.nr_vcpus: + self.nr_vcpus = 1 + if not self.type: + raise ValueError("VM type is not set") + if not self.arch: + raise ValueError("VM arch is not set") + + +class parser(object): + """ + Base class for particular config file format definitions of + a VM instance. + + Warning: this interface is not (yet) considered stable and may + change at will. + """ + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + raise NotImplementedError + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @output_file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + raise NotImplementedError + + +def register_parser(parser): + """ + Register a particular config format parser. This should be called by each + config plugin on import. + """ + + global _parsers + _parsers += [ parser ] + +def find_parser_by_name(name): + """ + Return the parser of the given name + """ + return [p for p in _parsers if p.name == name][0] or None + +def find_parser_by_file(input_file): + """ + Return the parser that is capable of comprehending the given file. + """ + for p in _parsers: + if p.identify_file(input_file): + return p + return None From levon at movementarian.org Wed Jul 2 16:05:06 2008 From: levon at movementarian.org (John Levon) Date: Wed, 2 Jul 2008 17:05:06 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: check for qemu-img failure Message-ID: <20080702160506.GO23929@totally.trollied.org.uk> I didn't go the "qemu-info" route (yet), as it only produces human-readable output: I didn't see a way to get it to print just the file format. regards john Cleanup on failure If we can't convert the disks or export the file, perform some cleanup. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -31,6 +31,7 @@ import virtconv.vmconfig as vmconfig import virtconv.vmconfig as vmconfig def parse_args(): + """Parse and verify command line.""" opts = OptionParser() opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") @@ -93,6 +94,36 @@ def parse_args(): return options +def rmrf(path): + """Remove a directory and all its contents.""" + + assert path is not None + + for dirpath, _, files in os.walk(path): + for filename in files: + os.remove(os.path.join(dirpath, filename)) + for dirpath, subdirs, _ in os.walk(path, topdown=False): + for dirname in subdirs: + os.rmdir(os.path.join(dirpath, dirname)) + os.rmdir(path) + +def cleanup(msg, options, created_dir): + """ + After failure, clean up anything we created. Take a conservative + approach: only if we created the output directory do we delete + anything. + """ + logging.error(msg) + + if created_dir: + try: + rmrf(options.output_dir) + except OSError, e: + logging.error("Couldn't clean up output directory \"%s\": %s" % + (options.output_dir, e.strerror)) + + sys.exit(1) + def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) @@ -131,12 +162,15 @@ def main(): vmdef.arch = options.arch + created_dir = False unixname = vmdef.name.replace(" ", "-") + if not options.output_dir: options.output_dir = unixname try: logging.debug("Creating directory %s" % options.output_dir) os.mkdir(options.output_dir) + created_dir = True except OSError, e: if (e.errno != errno.EEXIST): logging.error("Could not create directory %s: %s" % @@ -156,19 +190,19 @@ def main(): for d in vmdef.disks: d.convert(options.input_dir, options.output_dir, vmconfig.DISK_TYPE_RAW) - except Exception, e: - logging.error(e) - sys.exit(1) + except OSError, e: + cleanup("Couldn't convert disks: %s" % e.strerror, options, created_dir) + except RuntimeError, e: + cleanup("Couldn't convert disks: %s" % e.message, options, created_dir) try: outp.export_file(vmdef, options.output_file) - except Exception, e: - logging.error(e) - sys.exit(1) + except ValueError, e: + cleanup("Couldn't export to file \"%s\": %s" % + (options.output_file, e.message), options, created_dir) print "\n\nConversion completed and placed in: %s" % options.output_dir - if __name__ == "__main__": try: main() diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -77,7 +77,9 @@ class disk(object): (infile, qemu_formats[output_type], os.path.join(output_dir, outfile))) - os.system(convert_cmd) + ret = os.system(convert_cmd) + if ret != 0: + raise RuntimeError("qemu-img failed with exit status %d" % ret) # Note: this is the *relative* path still self.path = outfile From berrange at redhat.com Wed Jul 2 16:11:23 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 2 Jul 2008 17:11:23 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: check for qemu-img failure In-Reply-To: <20080702160506.GO23929@totally.trollied.org.uk> References: <20080702160506.GO23929@totally.trollied.org.uk> Message-ID: <20080702161123.GM9275@redhat.com> On Wed, Jul 02, 2008 at 05:05:06PM +0100, John Levon wrote: > > I didn't go the "qemu-info" route (yet), as it only produces > human-readable output: I didn't see a way to get it to print just the > file format. Yes that kinda sucks. When I added the storage pool/volume APis to libvirt I basically re-implemented the file magic checks directly rather than parse qemu-info. Having looked this, I'm wondering whether we need to add some more storage APIs which just work on ad-hoc file paths, rather than the higher level pool/volume objects, to let us query metdata about them without using qemu-info. Not that we should wait for this before adding the virt-convert command. Once we have an impl decided upon it'll give a better picture of what we need to address in the libvirt APIs Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From dlutter at redhat.com Wed Jul 2 17:51:49 2008 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 02 Jul 2008 10:51:49 -0700 Subject: [et-mgmt-tools] [PATCH] virt-convert: check for qemu-img failure In-Reply-To: <20080702161123.GM9275@redhat.com> References: <20080702160506.GO23929@totally.trollied.org.uk> <20080702161123.GM9275@redhat.com> Message-ID: <1215021109.3368.107.camel@localhost.localdomain> On Wed, 2008-07-02 at 17:11 +0100, Daniel P. Berrange wrote: > Yes that kinda sucks. When I added the storage pool/volume APis to > libvirt I basically re-implemented the file magic checks directly > rather than parse qemu-info. Is there any way to get that upstream into qemu rather than forcing libvirt to deal with these fairly low-level issues ? David From berrange at redhat.com Thu Jul 3 08:10:41 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 3 Jul 2008 09:10:41 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: check for qemu-img failure In-Reply-To: <1215021109.3368.107.camel@localhost.localdomain> References: <20080702160506.GO23929@totally.trollied.org.uk> <20080702161123.GM9275@redhat.com> <1215021109.3368.107.camel@localhost.localdomain> Message-ID: <20080703081041.GB312@redhat.com> On Wed, Jul 02, 2008 at 10:51:49AM -0700, David Lutterkort wrote: > On Wed, 2008-07-02 at 17:11 +0100, Daniel P. Berrange wrote: > > Yes that kinda sucks. When I added the storage pool/volume APis to > > libvirt I basically re-implemented the file magic checks directly > > rather than parse qemu-info. > > Is there any way to get that upstream into qemu rather than forcing > libvirt to deal with these fairly low-level issues ? The idea of providing a library API gets raise every 6 months or so but no one ever wants to commit to a stable ABI with QEMU internals, so it doesn't go anywhere useful. I don't expect that to change any time soon since QEMU is still evolving quite significantly under the hood. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jboggs at redhat.com Thu Jul 3 14:28:23 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 03 Jul 2008 10:28:23 -0400 Subject: [et-mgmt-tools] [patch] virt-convert python-virtinst.spec.in update Message-ID: <486CE207.9060804@redhat.com> Couldn't build due to unpackaged error: --- virtinst--devel.orig/python-virtinst.spec.in 2008-07-03 10:25:46.000000000 -0400 +++ virtinst--devel/python-virtinst.spec.in 2008-07-03 10:23:58.000000000 -0400 @@ -70,6 +70,7 @@ %{_bindir}/virt-clone %{_bindir}/virt-image %{_bindir}/virt-pack +%{_bindir}/virt-convert %changelog * Mon Mar 10 2008 Daniel P. Berrange - 0.300.3-1 From crobinso at redhat.com Thu Jul 3 15:59:44 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 03 Jul 2008 11:59:44 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: check for qemu-img failure In-Reply-To: <20080702160506.GO23929@totally.trollied.org.uk> References: <20080702160506.GO23929@totally.trollied.org.uk> Message-ID: <486CF770.9010807@redhat.com> John Levon wrote: > I didn't go the "qemu-info" route (yet), as it only produces > human-readable output: I didn't see a way to get it to print just the > file format. > One potential option would be to try 'qemu-info -f vmx imagename', throw away the output and just check the return value. I don't know if this works for all formats but in my quick check the above command on a raw file failed. It would prevent us from autodetecting the format, but it's at least an option. > regards > john > > > Cleanup on failure > > If we can't convert the disks or export the file, perform some cleanup. > > Signed-off-by: John Levon > > diff --git a/virt-convert b/virt-convert > --- a/virt-convert > +++ b/virt-convert > @@ -31,6 +31,7 @@ import virtconv.vmconfig as vmconfig > import virtconv.vmconfig as vmconfig > > def parse_args(): > + """Parse and verify command line.""" > opts = OptionParser() > opts.set_usage("%prog [options] inputdir|input.vmx " > "[outputdir|output.xml]") > @@ -93,6 +94,36 @@ def parse_args(): > > return options > > +def rmrf(path): > + """Remove a directory and all its contents.""" > + > + assert path is not None > + > + for dirpath, _, files in os.walk(path): > + for filename in files: > + os.remove(os.path.join(dirpath, filename)) > + for dirpath, subdirs, _ in os.walk(path, topdown=False): > + for dirname in subdirs: > + os.rmdir(os.path.join(dirpath, dirname)) > + os.rmdir(path) > + > +def cleanup(msg, options, created_dir): > + """ > + After failure, clean up anything we created. Take a conservative > + approach: only if we created the output directory do we delete > + anything. > + """ > + logging.error(msg) > + > + if created_dir: > + try: > + rmrf(options.output_dir) > + except OSError, e: > + logging.error("Couldn't clean up output directory \"%s\": %s" % > + (options.output_dir, e.strerror)) > + > + sys.exit(1) > + Hmm, this scares the hell out of me, even with the created_dir check. If someone in the future ever messed up this code we could accidently start deleting someones homedir. I think a whitelist approach would be better: have convert_disks clean up its own files, and keep all other file/directory creation in the main() function (like it currently is) so it can handle the rest of the cleanup on a per file basis. At the end, if the output_dir is empty and we created it, we can delete it. Maybe it's overly paranoid, but better to be safe than sorry. - Cole From levon at movementarian.org Thu Jul 3 16:02:53 2008 From: levon at movementarian.org (John Levon) Date: Thu, 3 Jul 2008 17:02:53 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: check for qemu-img failure In-Reply-To: <486CF770.9010807@redhat.com> References: <20080702160506.GO23929@totally.trollied.org.uk> <486CF770.9010807@redhat.com> Message-ID: <20080703160253.GB28815@totally.trollied.org.uk> On Thu, Jul 03, 2008 at 11:59:44AM -0400, Cole Robinson wrote: > > I didn't go the "qemu-info" route (yet), as it only produces > > human-readable output: I didn't see a way to get it to print just the > > file format. > > One potential option would be to try 'qemu-info -f vmx imagename', throw > away the output and just check the return value. I don't know if this > works for all formats but in my quick check the above command on a raw > file failed. It would prevent us from autodetecting the format, but it's > at least an option. But why is this any better than just trying the qemu-img convert? regards john From crobinso at redhat.com Thu Jul 3 16:16:54 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 03 Jul 2008 12:16:54 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: check for qemu-img failure In-Reply-To: <20080703160253.GB28815@totally.trollied.org.uk> References: <20080702160506.GO23929@totally.trollied.org.uk> <486CF770.9010807@redhat.com> <20080703160253.GB28815@totally.trollied.org.uk> Message-ID: <486CFB76.2080705@redhat.com> John Levon wrote: > On Thu, Jul 03, 2008 at 11:59:44AM -0400, Cole Robinson wrote: > >>> I didn't go the "qemu-info" route (yet), as it only produces >>> human-readable output: I didn't see a way to get it to print just the >>> file format. >> One potential option would be to try 'qemu-info -f vmx imagename', throw >> away the output and just check the return value. I don't know if this >> works for all formats but in my quick check the above command on a raw >> file failed. It would prevent us from autodetecting the format, but it's >> at least an option. > > But why is this any better than just trying the qemu-img convert? > > regards > john If we have multiple disks to convert, this could tell us we have a bad apple at the end of the list rather than take quite a while to convert all the others just to find out we are going to fail. - Cole From crobinso at redhat.com Thu Jul 3 16:46:50 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 03 Jul 2008 12:46:50 -0400 Subject: [et-mgmt-tools] [PATCH] Resend (hopefully final) adding of --replace command for virt-image In-Reply-To: <3e86a75795e73277056b.1215011825@localhost.localdomain> References: <3e86a75795e73277056b.1215011825@localhost.localdomain> Message-ID: <486D027A.3070404@redhat.com> "Bryan M. Kearney "@redhat.com wrote: > # HG changeset patch > # User "Bryan M. Kearney " > # Date 1215011615 14400 > # Node ID 3e86a75795e73277056bfcea0c54b97f7a5945e9 > # Parent 5d9cf6c2662494d21d84fbafbc0b7980096b1998 > Add a --remove flag to allow virt-image to install new images when an existing one with the same name is defined Thanks, I've committed this: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=6d7d84623847 - Cole From crobinso at redhat.com Thu Jul 3 16:47:27 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 03 Jul 2008 12:47:27 -0400 Subject: [et-mgmt-tools] [patch] virt-convert python-virtinst.spec.in update In-Reply-To: <486CE207.9060804@redhat.com> References: <486CE207.9060804@redhat.com> Message-ID: <486D029F.70006@redhat.com> Joey Boggs wrote: > Couldn't build due to unpackaged error: > Thanks, committed upstream: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=583dc88770f7 - Cole From crobinso at redhat.com Thu Jul 3 16:48:23 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 03 Jul 2008 12:48:23 -0400 Subject: [et-mgmt-tools] [PATCH] modular virt-convert In-Reply-To: <20080702160408.GN23929@totally.trollied.org.uk> References: <20080702160408.GN23929@totally.trollied.org.uk> Message-ID: <486D02D7.9060702@redhat.com> John Levon wrote: > This is merged with current tip and now installs properly. > > thanks > john > > > Create config parser plugin system > > Start a plugin system for config formats parsing, and implement enough > of it to get to where we were with virt-convert. > > Signed-off-by: John Levon > This looks good to me. Seems like the way to go to expand this in the future. If Dan and Joey are ok with this as well, I'll commit it. Thanks, Cole > diff --git a/setup.py b/setup.py > --- a/setup.py > +++ b/setup.py > @@ -9,7 +9,8 @@ import os, sys > import os, sys > import tests.coverage as coverage > > -pkgs = ['virtinst'] > +pkgs = ['virtinst', 'virtconv', 'virtconv.parsers' ] > + > datafiles = [('share/man/man1', ['man/en/virt-install.1', > 'man/en/virt-clone.1', > 'man/en/virt-image.1', > diff --git a/virt-convert b/virt-convert > --- a/virt-convert > +++ b/virt-convert > @@ -21,56 +21,58 @@ > # MA 02110-1301 USA. > > import sys > -from string import ascii_letters > -import virtinst.cli as cli > import os > import logging > import errno > from optparse import OptionParser > > +import virtinst.cli as cli > +import virtconv > +import virtconv.vmconfig as vmconfig > + > def parse_args(): > - parser = OptionParser() > - parser.set_usage("%prog [options] inputdir|input.vmx " > + opts = OptionParser() > + opts.set_usage("%prog [options] inputdir|input.vmx " > "[outputdir|output.xml]") > - parser.add_option("-a", "--arch", type="string", dest="arch", > - help=("Machine Architecture Type (i686/x86_64/ppc)")) > - parser.add_option("-t", "--type", type="string", dest="type", > - help=("Output virtualization type (hvm, paravirt")) > - parser.add_option("-d", "--debug", action="store_true", dest="debug", > - help=("Print debugging information")) > - parser.add_option("-i", "--input-format", action="store", > - dest="inputformat", default="vmx", > - help=("Input format, e.g. 'vmx'")) > - parser.add_option("-o", "--output-format", action="store", > - dest="outputformat", default="virt-image", > - help=("Output format, e.g. 'virt-image'")) > - parser.add_option("-v", "--hvm", action="store_true", dest="fullvirt", > - help=("This guest should be a fully virtualized guest")) > - parser.add_option("-p", "--paravirt", action="store_true", dest="paravirt", > - help=("This guest should be a paravirtualized guest")) > + opts.add_option("-a", "--arch", type="string", dest="arch", > + help=("Machine Architecture Type (i686/x86_64/ppc)")) > + opts.add_option("-t", "--type", type="string", dest="type", > + help=("Output virtualization type (hvm, paravirt")) > + opts.add_option("-d", "--debug", action="store_true", dest="debug", > + help=("Print debugging information")) > + opts.add_option("-i", "--input-format", action="store", > + dest="inputformat", default="vmx", > + help=("Input format, e.g. 'vmx'")) > + opts.add_option("-o", "--output-format", action="store", > + dest="outputformat", default="virt-image", > + help=("Output format, e.g. 'virt-image'")) > + opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", > + help=("This guest should be a fully virtualized guest")) > + opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", > + help=("This guest should be a paravirtualized guest")) > > - (options, args) = parser.parse_args() > + (options, args) = opts.parse_args() > if len(args) < 1: > - parser.error(("You need to provide an input VM definition")) > + opts.error(("You need to provide an input VM definition")) > if len(args) > 2: > - parser.error(("Too many arguments provided")) > + opts.error(("Too many arguments provided")) > > if (options.arch is None): > - parser.error(("Missing option value \n\nArchitecture: " + > + opts.error(("Missing option value \n\nArchitecture: " + > str(options.arch))) > > # hard-code for now > if options.inputformat != "vmx": > - parser.error(("Unsupported input format \"%s\"" % options.inputformat)) > + opts.error(("Unsupported input format \"%s\"" % options.inputformat)) > if options.outputformat != "virt-image": > - parser.error(("Unsupported output format \"%s\"" > + opts.error(("Unsupported output format \"%s\"" > % options.outputformat)) > if os.path.isdir(args[0]): > vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] > if (len(vmx_files)) == 0: > - parser.error(("No VM definition file was found in %s" % args[0])) > + opts.error(("No VM definition file was found in %s" % args[0])) > if (len(vmx_files)) > 1: > - parser.error(("Too many .vmx definitions found in %s" % args[0])) > + opts.error(("Too many .vmx definitions found in %s" % args[0])) > options.input_file = os.path.join(args[0], vmx_files[0]) > options.input_dir = args[0] > else: > @@ -91,197 +93,78 @@ def parse_args(): > > return options > > -# Begin creation of xml template from parsed vmx config file > -def vmx_to_image_xml(disks_list, record, options, hvm): > - pv_disk_list = [] > - fv_disk_list = [] > - storage_disk_list = [] > - > - infile = options.input_file > - > - # validate required values for conversion are in the input vmx file > - if record.has_key("displayName"): > - name = record["displayName"] > - else: > - logging.error("displayName key not parsed from %s" % infile) > - sys.exit(1) > - > - if record.has_key("memsize"): > - memory = int(record["memsize"]) * 1024 > - else: > - logging.error("memsize key not parsed from %s" % infile) > - sys.exit(1) > - > - if record.has_key("annotation"): > - annotation = record["annotation"] > - else: > - annotation = "" > - > - if record.has_key("numvcpus"): > - vcpus = record["numvcpus"] > - else: > - vcpus = "1" > - > - > -# create disk filename lists for xml template > - for (number, dfile) in enumerate(disks_list): > - dfile = str(dfile.replace(".vmdk","")).strip() > - pv_disk_list.append("""""" % \ > - (dfile, ascii_letters[number % 26])) > - fv_disk_list.append("""""" % \ > - (dfile, ascii_letters[number % 26])) > - storage_disk_list.append("""""" % (dfile)) > - > -# determine virtualization type for image.boot section > - if hvm is False: > - virt_boot_template = """ > - > - %(vm_arch)s > - > - > - > - > - > - pygrub > - > - %(vm_pv_disks)s > - """ > - elif hvm is True: > - virt_boot_template = """ > - > - %(vm_arch)s > - > - > - > - > - %(vm_fv_disks)s > - """ > - > - > -# xml replacements dictionaries > - virt_boot_xml_dict = { > - "vm_pv_disks" : "".join(pv_disk_list), > - "vm_fv_disks" : "".join(fv_disk_list), > - "vm_arch" : options.arch, > - } > - virt_boot_template = virt_boot_template % virt_boot_xml_dict > - virt_image_xml_dict = { > - "virt_boot_template" : virt_boot_template, > - "vm_displayName": name.replace(" ","_"), > - "vm_annotation" : annotation, > - "vm_vcpus" : vcpus, > - "vm_mem" : memory, > - "vm_storage" : "".join(storage_disk_list), > - } > - > - virt_image_xml_template = """ > - %(vm_displayName)s > - > - > - %(vm_annotation)s > - > - > - %(virt_boot_template)s > - > - %(vm_vcpus)s > - %(vm_mem)s > - > - > - > - > - > - %(vm_storage)s > - > - > -""" > - > - virtimage_xml_template = virt_image_xml_template % virt_image_xml_dict > - return virtimage_xml_template > - > -# parse input vmware configuration > -def parse_vmware_config(options): > - if not os.access(options.input_file, os.R_OK): > - raise ValueError, "Could not read file: %s" % options.input_file > - infile = open(options.input_file, "r") > - contents = infile.readlines() > - infile.close() > - record = {} > - vm_config = [] > - disks_list = [] > - > - # strip out comment and blank lines for easy splitting of values > - for line in contents: > - if not line.strip() or line.startswith("#"): > - continue > - else: > - vm_config.append(line) > - > - for line in vm_config: > - before_eq, after_eq = line.split("=", 1) > - key = before_eq.replace(" ","") > - value = after_eq.replace('"',"") > - value = value.strip() > - record[key] = value > - logging.debug("Key: %s Value: \"%s\"" % (key, value)) > - if value.endswith("vmdk"): # separate disks from config > - disks_list.append(value) > - return record, disks_list > - > - > -def convert_disks(disks_list, options): > - for disk in disks_list: > - infile = disk.strip() > - if not os.path.isabs(infile): > - infile = os.path.join(options.input_dir, infile) > - > - outfile = disk.replace(".vmdk","").strip() > - outfile += ".img" > - if not os.path.isabs(outfile): > - outfile = os.path.join(options.output_dir, outfile) > - convert_cmd = "qemu-img convert %s -O raw %s" % (infile, outfile) > - ret = os.system(convert_cmd) > - print ret > - > - > def main(): > options = parse_args() > cli.setupLogging("virt-convert", options.debug) > > - vm_config = parse_vmware_config(options) > - record, disks_list = vm_config > + try: > + inp = virtconv.vmconfig.find_parser_by_name(options.inputformat) > + except: > + logging.error("No parser of format \"%s\" was found." % > + options.inputformat) > + sys.exit(1) > + > + try: > + outp = virtconv.vmconfig.find_parser_by_name(options.outputformat) > + except: > + logging.error("No parser of format \"%s\" was found." % > + options.outputformat) > + sys.exit(1) > + > + vmdef = None > + > + try: > + vmdef = inp.import_file(options.input_file) > + except IOError, e: > + logging.error("Couldn't import file \"%s\": %s" % > + (options.input_file, e.strerror)) > + sys.exit(1) > + except Exception, e: > + logging.error("Couldn't import file \"%s\": %s" % > + (options.input_file, e.message)) > + sys.exit(1) > > if options.paravirt: > - hvm = False > + vmdef.type = vmconfig.VM_TYPE_PV > else: > - hvm = True > - out_contents = vmx_to_image_xml(disks_list, record, options, hvm) > + vmdef.type = vmconfig.VM_TYPE_HVM > > - name = record["displayName"].replace(" ","-") > + vmdef.arch = options.arch > + > + unixname = vmdef.name.replace(" ", "-") > if not options.output_dir: > - options.output_dir = name > + options.output_dir = unixname > try: > logging.debug("Creating directory %s" % options.output_dir) > os.mkdir(options.output_dir) > except OSError, e: > if (e.errno != errno.EEXIST): > logging.error("Could not create directory %s: %s" % > - (options.output_dir, str(e))) > + (options.output_dir, e.strerror)) > sys.exit(1) > > if not options.output_file: > options.output_file = os.path.join(options.output_dir, > - "%s.virt-image.xml" % name) > + "%s%s" % (unixname, outp.suffix)) > > logging.debug("input_file: %s" % options.input_file) > logging.debug("input_dir: %s" % options.input_dir) > logging.debug("output_file: %s" % options.output_file) > logging.debug("output_dir: %s" % options.input_dir) > > - # configuration completed, ready to write config file and convert disks > - out = open(options.output_file, "w") > - out.writelines(out_contents) > - out.close() > - convert_disks(disks_list, options) > + try: > + for d in vmdef.disks: > + d.convert(options.input_dir, options.output_dir, > + vmconfig.DISK_TYPE_RAW) > + except Exception, e: > + logging.error(e) > + sys.exit(1) > + > + try: > + outp.export_file(vmdef, options.output_file) > + except Exception, e: > + logging.error(e) > + sys.exit(1) > > print "\n\nConversion completed and placed in: %s" % options.output_dir > > diff --git a/virtconv/__init__.py b/virtconv/__init__.py > new file mode 100644 > --- /dev/null > +++ b/virtconv/__init__.py > @@ -0,0 +1,29 @@ > +# > +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. > +# Use is subject to license terms. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301 USA. > +# > + > +import pkgutil > +import imp > +import os > + > +parsers_path = [os.path.join(__path__[0], "parsers/")] > + > +for loader, name, ispkg in pkgutil.iter_modules(parsers_path): > + filename, pathname, desc = imp.find_module(name, parsers_path) > + imp.load_module(name, filename, pathname, desc) > diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py > new file mode 100644 > --- /dev/null > +++ b/virtconv/parsers/virtimage.py > @@ -0,0 +1,152 @@ > +# > +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. > +# Use is subject to license terms. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301 USA. > +# > + > +from string import ascii_letters > +import virtconv.vmconfig as vmconfig > + > +pv_boot_template = """ > + > + > + %(arch)s > + > + > + > + > + > + pygrub > + > + %(pv_disks)s > + > +""" > + > +hvm_boot_template = """ > + > + > + %(arch)s > + > + > + > + > + %(hvm_disks)s > + > +""" > + > +image_template = """ > + > + %(name)s > + > + > + %(description)s > + > + > + %(boot_template)s > + > + %(nr_vcpus)s > + %(memory)s > + > + > + > + > + > + %(storage)s > + > + > +""" > + > +class virtimage_parser(vmconfig.parser): > + """ > + Support for virt-install's image format (see virt-image man page). > + """ > + name = "virt-image" > + suffix = ".virt-image.xml" > + > + @staticmethod > + def identify_file(input_file): > + """ > + Return True if the given file is of this format. > + """ > + raise NotImplementedError > + > + @staticmethod > + def import_file(input_file): > + """ > + Import a configuration file. Raises if the file couldn't be > + opened, or parsing otherwise failed. > + """ > + raise NotImplementedError > + > + @staticmethod > + def export_file(vm, output_file): > + """ > + Export a configuration file. > + @vm vm configuration instance > + @file Output file > + > + Raises ValueError if configuration is not suitable, or another > + exception on failure to write the output file. > + """ > + > + if not vm.memory: > + raise ValueError("VM must have a memory setting") > + > + pv_disks = [] > + hvm_disks = [] > + storage_disks = [] > + > + # create disk filename lists for xml template > + for disk in vm.disks: > + number = disk.number > + path = disk.path > + > + # FIXME: needs updating for later Xen enhancements; need to > + # implement capabilities checking for max disks etc. > + pv_disks.append("""""" % > + (path, ascii_letters[number % 26])) > + hvm_disks.append("""""" % > + (path, ascii_letters[number % 26])) > + storage_disks.append( > + """""" % path) > + > + if vm.type == vmconfig.VM_TYPE_PV: > + boot_template = pv_boot_template > + else: > + boot_template = hvm_boot_template > + > + boot_xml = boot_template % { > + "pv_disks" : "".join(pv_disks), > + "hvm_disks" : "".join(hvm_disks), > + "arch" : vm.arch, > + } > + > + out = image_template % { > + "boot_template": boot_xml, > + "name" : vm.name, > + "description" : vm.description, > + "nr_vcpus" : vm.nr_vcpus, > + # Mb to Kb > + "memory" : int(vm.memory) * 1024, > + "storage" : "".join(storage_disks), > + } > + > + outfile = open(output_file, "w") > + outfile.writelines(out) > + outfile.close() > + > +vmconfig.register_parser(virtimage_parser) > diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py > new file mode 100644 > --- /dev/null > +++ b/virtconv/parsers/vmx.py > @@ -0,0 +1,107 @@ > +# > +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. > +# Use is subject to license terms. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301 USA. > +# > + > +import virtconv.vmconfig as vmconfig > + > +class vmx_parser(vmconfig.parser): > + """ > + Support for VMWare .vmx files. Note that documentation is > + particularly sparse on this format, with pretty much the best > + resource being http://sanbarrow.com/vmx.html > + """ > + > + name = "vmx" > + suffix = ".vmx" > + > + @staticmethod > + def identify_file(input_file): > + """ > + Return True if the given file is of this format. > + """ > + raise NotImplementedError > + > + @staticmethod > + def import_file(input_file): > + """ > + Import a configuration file. Raises if the file couldn't be > + opened, or parsing otherwise failed. > + """ > + > + vm = vmconfig.vm() > + > + infile = open(input_file, "r") > + contents = infile.readlines() > + infile.close() > + > + lines = [] > + > + # strip out comment and blank lines for easy splitting of values > + for line in contents: > + if not line.strip() or line.startswith("#"): > + continue > + else: > + lines.append(line) > + > + config = {} > + > + # split out all remaining entries of key = value form > + for (line_nr, line) in enumerate(lines): > + try: > + before_eq, after_eq = line.split("=", 1) > + key = before_eq.replace(" ","") > + value = after_eq.replace('"',"") > + value = value.strip() > + config[key] = value > + except: > + raise Exception("Syntax error at line %d: %s" % > + (line_nr + 1, line.strip())) > + > + if not config.get("displayName"): > + raise ValueError("No displayName defined in \"%s\"" % input_file) > + vm.name = config.get("displayName") > + > + vm.memory = config.get("memsize") > + vm.description = config.get("annotation") > + vm.nr_vcpus = config.get("numvcpus") > + > + # FIXME: this should probably be a lot smarter. I don't think > + # this even gets disk numbering right. > + disks = [ d for d in config.values() if d.endswith(".vmdk") ] > + > + for (number, path) in enumerate(disks): > + vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] > + > + vm.validate() > + return vm > + > + @staticmethod > + def export_file(vm, output_file): > + """ > + Export a configuration file. > + @vm vm configuration instance > + @file Output file > + > + Raises ValueError if configuration is not suitable, or another > + exception on failure to write the output file. > + """ > + > + raise NotImplementedError > + > +vmconfig.register_parser(vmx_parser) > diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py > new file mode 100644 > --- /dev/null > +++ b/virtconv/vmconfig.py > @@ -0,0 +1,193 @@ > +# > +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. > +# Use is subject to license terms. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301 USA. > +# > + > +import os > + > +_parsers = [ ] > + > +VM_TYPE_PV = 0 > +VM_TYPE_HVM = 1 > + > +DISK_TYPE_RAW = 0 > +DISK_TYPE_VMDK = 1 > + > +disk_suffixes = { > + DISK_TYPE_RAW: ".img", > + DISK_TYPE_VMDK: ".vmdk", > +} > + > +qemu_formats = { > + DISK_TYPE_RAW: "raw", > + DISK_TYPE_VMDK: "vmdk", > +} > + > +class disk(object): > + """Definition of an individual disk instance.""" > + > + def __init__(self, path = None, number = None, type = None): > + self.path = path > + self.number = number > + self.type = type > + > + def convert(self, input_dir, output_dir, output_type): > + """ > + Convert a disk into the requested format if possible, in the > + given output directory. Raises NotImplementedError or other > + failures. > + """ > + > + if self.type == output_type: > + return > + > + if output_type != DISK_TYPE_RAW: > + raise NotImplementedError("Cannot convert to disk type %d" % > + output_type) > + > + infile = self.path > + > + if not os.path.isabs(infile): > + infile = os.path.join(input_dir, infile) > + > + outfile = self.path > + > + if os.path.isabs(outfile): > + outfile = os.path.basename(outfile) > + > + outfile = outfile.replace(disk_suffixes[self.type], > + disk_suffixes[output_type]).strip() > + > + convert_cmd = ("qemu-img convert \"%s\" -O %s \"%s\"" % > + (infile, qemu_formats[output_type], > + os.path.join(output_dir, outfile))) > + > + os.system(convert_cmd) > + > + # Note: this is the *relative* path still > + self.path = outfile > + self.type = output_type > + > + > +class vm(object): > + """ > + Generic configuration for a particular VM instance. > + > + At export, a plugin is guaranteed to have the at least the following > + values set (any others needed should be checked for, raising > + ValueError on failure): > + > + vm.name > + vm.description (defaults to empty string) > + vm.nr_vcpus (defaults to 1) > + vm.type > + vm.arch > + > + If vm.memory is set, it is in Mb units. > + """ > + > + name = None > + suffix = None > + > + def __init__(self): > + self.name = None > + self.description = None > + self.memory = None > + self.nr_vcpus = None > + self.disks = [ ] > + self.type = VM_TYPE_HVM > + self.arch = "i686" # FIXME? > + > + def validate(self): > + """ > + Validate all parameters, and fix up any unset values to meet the > + guarantees we make above. > + """ > + > + if not self.name: > + raise ValueError("VM name is not set") > + if not self.description: > + self.description = "" > + if not self.nr_vcpus: > + self.nr_vcpus = 1 > + if not self.type: > + raise ValueError("VM type is not set") > + if not self.arch: > + raise ValueError("VM arch is not set") > + > + > +class parser(object): > + """ > + Base class for particular config file format definitions of > + a VM instance. > + > + Warning: this interface is not (yet) considered stable and may > + change at will. > + """ > + > + @staticmethod > + def identify_file(input_file): > + """ > + Return True if the given file is of this format. > + """ > + raise NotImplementedError > + > + @staticmethod > + def import_file(input_file): > + """ > + Import a configuration file. Raises if the file couldn't be > + opened, or parsing otherwise failed. > + """ > + raise NotImplementedError > + > + @staticmethod > + def export_file(vm, output_file): > + """ > + Export a configuration file. > + @vm vm configuration instance > + @output_file Output file > + > + Raises ValueError if configuration is not suitable, or another > + exception on failure to write the output file. > + """ > + raise NotImplementedError > + > + > +def register_parser(parser): > + """ > + Register a particular config format parser. This should be called by each > + config plugin on import. > + """ > + > + global _parsers > + _parsers += [ parser ] > + > +def find_parser_by_name(name): > + """ > + Return the parser of the given name > + """ > + return [p for p in _parsers if p.name == name][0] or None > + > +def find_parser_by_file(input_file): > + """ > + Return the parser that is capable of comprehending the given file. > + """ > + for p in _parsers: > + if p.identify_file(input_file): > + return p > + return None > From jboggs at redhat.com Thu Jul 3 16:57:22 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 03 Jul 2008 12:57:22 -0400 Subject: [et-mgmt-tools] [PATCH] modular virt-convert In-Reply-To: <486D02D7.9060702@redhat.com> References: <20080702160408.GN23929@totally.trollied.org.uk> <486D02D7.9060702@redhat.com> Message-ID: <486D04F2.5010604@redhat.com> I'm more than happy with it, surprised it took off so fast actually :) Thanks for you contributions John Cole Robinson wrote: > John Levon wrote: > >> This is merged with current tip and now installs properly. >> >> thanks >> john >> >> >> Create config parser plugin system >> >> Start a plugin system for config formats parsing, and implement enough >> of it to get to where we were with virt-convert. >> >> Signed-off-by: John Levon >> >> > > This looks good to me. Seems like the way to go to expand this in > the future. > > If Dan and Joey are ok with this as well, I'll commit it. > > Thanks, > Cole > > > >> diff --git a/setup.py b/setup.py >> --- a/setup.py >> +++ b/setup.py >> @@ -9,7 +9,8 @@ import os, sys >> import os, sys >> import tests.coverage as coverage >> >> -pkgs = ['virtinst'] >> +pkgs = ['virtinst', 'virtconv', 'virtconv.parsers' ] >> + >> datafiles = [('share/man/man1', ['man/en/virt-install.1', >> 'man/en/virt-clone.1', >> 'man/en/virt-image.1', >> diff --git a/virt-convert b/virt-convert >> --- a/virt-convert >> +++ b/virt-convert >> @@ -21,56 +21,58 @@ >> # MA 02110-1301 USA. >> >> import sys >> -from string import ascii_letters >> -import virtinst.cli as cli >> import os >> import logging >> import errno >> from optparse import OptionParser >> >> +import virtinst.cli as cli >> +import virtconv >> +import virtconv.vmconfig as vmconfig >> + >> def parse_args(): >> - parser = OptionParser() >> - parser.set_usage("%prog [options] inputdir|input.vmx " >> + opts = OptionParser() >> + opts.set_usage("%prog [options] inputdir|input.vmx " >> "[outputdir|output.xml]") >> - parser.add_option("-a", "--arch", type="string", dest="arch", >> - help=("Machine Architecture Type (i686/x86_64/ppc)")) >> - parser.add_option("-t", "--type", type="string", dest="type", >> - help=("Output virtualization type (hvm, paravirt")) >> - parser.add_option("-d", "--debug", action="store_true", dest="debug", >> - help=("Print debugging information")) >> - parser.add_option("-i", "--input-format", action="store", >> - dest="inputformat", default="vmx", >> - help=("Input format, e.g. 'vmx'")) >> - parser.add_option("-o", "--output-format", action="store", >> - dest="outputformat", default="virt-image", >> - help=("Output format, e.g. 'virt-image'")) >> - parser.add_option("-v", "--hvm", action="store_true", dest="fullvirt", >> - help=("This guest should be a fully virtualized guest")) >> - parser.add_option("-p", "--paravirt", action="store_true", dest="paravirt", >> - help=("This guest should be a paravirtualized guest")) >> + opts.add_option("-a", "--arch", type="string", dest="arch", >> + help=("Machine Architecture Type (i686/x86_64/ppc)")) >> + opts.add_option("-t", "--type", type="string", dest="type", >> + help=("Output virtualization type (hvm, paravirt")) >> + opts.add_option("-d", "--debug", action="store_true", dest="debug", >> + help=("Print debugging information")) >> + opts.add_option("-i", "--input-format", action="store", >> + dest="inputformat", default="vmx", >> + help=("Input format, e.g. 'vmx'")) >> + opts.add_option("-o", "--output-format", action="store", >> + dest="outputformat", default="virt-image", >> + help=("Output format, e.g. 'virt-image'")) >> + opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", >> + help=("This guest should be a fully virtualized guest")) >> + opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", >> + help=("This guest should be a paravirtualized guest")) >> >> - (options, args) = parser.parse_args() >> + (options, args) = opts.parse_args() >> if len(args) < 1: >> - parser.error(("You need to provide an input VM definition")) >> + opts.error(("You need to provide an input VM definition")) >> if len(args) > 2: >> - parser.error(("Too many arguments provided")) >> + opts.error(("Too many arguments provided")) >> >> if (options.arch is None): >> - parser.error(("Missing option value \n\nArchitecture: " + >> + opts.error(("Missing option value \n\nArchitecture: " + >> str(options.arch))) >> >> # hard-code for now >> if options.inputformat != "vmx": >> - parser.error(("Unsupported input format \"%s\"" % options.inputformat)) >> + opts.error(("Unsupported input format \"%s\"" % options.inputformat)) >> if options.outputformat != "virt-image": >> - parser.error(("Unsupported output format \"%s\"" >> + opts.error(("Unsupported output format \"%s\"" >> % options.outputformat)) >> if os.path.isdir(args[0]): >> vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] >> if (len(vmx_files)) == 0: >> - parser.error(("No VM definition file was found in %s" % args[0])) >> + opts.error(("No VM definition file was found in %s" % args[0])) >> if (len(vmx_files)) > 1: >> - parser.error(("Too many .vmx definitions found in %s" % args[0])) >> + opts.error(("Too many .vmx definitions found in %s" % args[0])) >> options.input_file = os.path.join(args[0], vmx_files[0]) >> options.input_dir = args[0] >> else: >> @@ -91,197 +93,78 @@ def parse_args(): >> >> return options >> >> -# Begin creation of xml template from parsed vmx config file >> -def vmx_to_image_xml(disks_list, record, options, hvm): >> - pv_disk_list = [] >> - fv_disk_list = [] >> - storage_disk_list = [] >> - >> - infile = options.input_file >> - >> - # validate required values for conversion are in the input vmx file >> - if record.has_key("displayName"): >> - name = record["displayName"] >> - else: >> - logging.error("displayName key not parsed from %s" % infile) >> - sys.exit(1) >> - >> - if record.has_key("memsize"): >> - memory = int(record["memsize"]) * 1024 >> - else: >> - logging.error("memsize key not parsed from %s" % infile) >> - sys.exit(1) >> - >> - if record.has_key("annotation"): >> - annotation = record["annotation"] >> - else: >> - annotation = "" >> - >> - if record.has_key("numvcpus"): >> - vcpus = record["numvcpus"] >> - else: >> - vcpus = "1" >> - >> - >> -# create disk filename lists for xml template >> - for (number, dfile) in enumerate(disks_list): >> - dfile = str(dfile.replace(".vmdk","")).strip() >> - pv_disk_list.append("""""" % \ >> - (dfile, ascii_letters[number % 26])) >> - fv_disk_list.append("""""" % \ >> - (dfile, ascii_letters[number % 26])) >> - storage_disk_list.append("""""" % (dfile)) >> - >> -# determine virtualization type for image.boot section >> - if hvm is False: >> - virt_boot_template = """ >> - >> - %(vm_arch)s >> - >> - >> - >> - >> - >> - pygrub >> - >> - %(vm_pv_disks)s >> - """ >> - elif hvm is True: >> - virt_boot_template = """ >> - >> - %(vm_arch)s >> - >> - >> - >> - >> - %(vm_fv_disks)s >> - """ >> - >> - >> -# xml replacements dictionaries >> - virt_boot_xml_dict = { >> - "vm_pv_disks" : "".join(pv_disk_list), >> - "vm_fv_disks" : "".join(fv_disk_list), >> - "vm_arch" : options.arch, >> - } >> - virt_boot_template = virt_boot_template % virt_boot_xml_dict >> - virt_image_xml_dict = { >> - "virt_boot_template" : virt_boot_template, >> - "vm_displayName": name.replace(" ","_"), >> - "vm_annotation" : annotation, >> - "vm_vcpus" : vcpus, >> - "vm_mem" : memory, >> - "vm_storage" : "".join(storage_disk_list), >> - } >> - >> - virt_image_xml_template = """ >> - %(vm_displayName)s >> - >> - >> - %(vm_annotation)s >> - >> - >> - %(virt_boot_template)s >> - >> - %(vm_vcpus)s >> - %(vm_mem)s >> - >> - >> - >> - >> - >> - %(vm_storage)s >> - >> - >> -""" >> - >> - virtimage_xml_template = virt_image_xml_template % virt_image_xml_dict >> - return virtimage_xml_template >> - >> -# parse input vmware configuration >> -def parse_vmware_config(options): >> - if not os.access(options.input_file, os.R_OK): >> - raise ValueError, "Could not read file: %s" % options.input_file >> - infile = open(options.input_file, "r") >> - contents = infile.readlines() >> - infile.close() >> - record = {} >> - vm_config = [] >> - disks_list = [] >> - >> - # strip out comment and blank lines for easy splitting of values >> - for line in contents: >> - if not line.strip() or line.startswith("#"): >> - continue >> - else: >> - vm_config.append(line) >> - >> - for line in vm_config: >> - before_eq, after_eq = line.split("=", 1) >> - key = before_eq.replace(" ","") >> - value = after_eq.replace('"',"") >> - value = value.strip() >> - record[key] = value >> - logging.debug("Key: %s Value: \"%s\"" % (key, value)) >> - if value.endswith("vmdk"): # separate disks from config >> - disks_list.append(value) >> - return record, disks_list >> - >> - >> -def convert_disks(disks_list, options): >> - for disk in disks_list: >> - infile = disk.strip() >> - if not os.path.isabs(infile): >> - infile = os.path.join(options.input_dir, infile) >> - >> - outfile = disk.replace(".vmdk","").strip() >> - outfile += ".img" >> - if not os.path.isabs(outfile): >> - outfile = os.path.join(options.output_dir, outfile) >> - convert_cmd = "qemu-img convert %s -O raw %s" % (infile, outfile) >> - ret = os.system(convert_cmd) >> - print ret >> - >> - >> def main(): >> options = parse_args() >> cli.setupLogging("virt-convert", options.debug) >> >> - vm_config = parse_vmware_config(options) >> - record, disks_list = vm_config >> + try: >> + inp = virtconv.vmconfig.find_parser_by_name(options.inputformat) >> + except: >> + logging.error("No parser of format \"%s\" was found." % >> + options.inputformat) >> + sys.exit(1) >> + >> + try: >> + outp = virtconv.vmconfig.find_parser_by_name(options.outputformat) >> + except: >> + logging.error("No parser of format \"%s\" was found." % >> + options.outputformat) >> + sys.exit(1) >> + >> + vmdef = None >> + >> + try: >> + vmdef = inp.import_file(options.input_file) >> + except IOError, e: >> + logging.error("Couldn't import file \"%s\": %s" % >> + (options.input_file, e.strerror)) >> + sys.exit(1) >> + except Exception, e: >> + logging.error("Couldn't import file \"%s\": %s" % >> + (options.input_file, e.message)) >> + sys.exit(1) >> >> if options.paravirt: >> - hvm = False >> + vmdef.type = vmconfig.VM_TYPE_PV >> else: >> - hvm = True >> - out_contents = vmx_to_image_xml(disks_list, record, options, hvm) >> + vmdef.type = vmconfig.VM_TYPE_HVM >> >> - name = record["displayName"].replace(" ","-") >> + vmdef.arch = options.arch >> + >> + unixname = vmdef.name.replace(" ", "-") >> if not options.output_dir: >> - options.output_dir = name >> + options.output_dir = unixname >> try: >> logging.debug("Creating directory %s" % options.output_dir) >> os.mkdir(options.output_dir) >> except OSError, e: >> if (e.errno != errno.EEXIST): >> logging.error("Could not create directory %s: %s" % >> - (options.output_dir, str(e))) >> + (options.output_dir, e.strerror)) >> sys.exit(1) >> >> if not options.output_file: >> options.output_file = os.path.join(options.output_dir, >> - "%s.virt-image.xml" % name) >> + "%s%s" % (unixname, outp.suffix)) >> >> logging.debug("input_file: %s" % options.input_file) >> logging.debug("input_dir: %s" % options.input_dir) >> logging.debug("output_file: %s" % options.output_file) >> logging.debug("output_dir: %s" % options.input_dir) >> >> - # configuration completed, ready to write config file and convert disks >> - out = open(options.output_file, "w") >> - out.writelines(out_contents) >> - out.close() >> - convert_disks(disks_list, options) >> + try: >> + for d in vmdef.disks: >> + d.convert(options.input_dir, options.output_dir, >> + vmconfig.DISK_TYPE_RAW) >> + except Exception, e: >> + logging.error(e) >> + sys.exit(1) >> + >> + try: >> + outp.export_file(vmdef, options.output_file) >> + except Exception, e: >> + logging.error(e) >> + sys.exit(1) >> >> print "\n\nConversion completed and placed in: %s" % options.output_dir >> >> diff --git a/virtconv/__init__.py b/virtconv/__init__.py >> new file mode 100644 >> --- /dev/null >> +++ b/virtconv/__init__.py >> @@ -0,0 +1,29 @@ >> +# >> +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. >> +# Use is subject to license terms. >> +# >> +# This program is free software; you can redistribute it and/or modify >> +# it under the terms of the GNU General Public License as published by >> +# the Free Software Foundation; either version 2 of the License, or >> +# (at your option) any later version. >> +# >> +# This program is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program; if not, write to the Free Software >> +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, >> +# MA 02110-1301 USA. >> +# >> + >> +import pkgutil >> +import imp >> +import os >> + >> +parsers_path = [os.path.join(__path__[0], "parsers/")] >> + >> +for loader, name, ispkg in pkgutil.iter_modules(parsers_path): >> + filename, pathname, desc = imp.find_module(name, parsers_path) >> + imp.load_module(name, filename, pathname, desc) >> diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py >> new file mode 100644 >> --- /dev/null >> +++ b/virtconv/parsers/virtimage.py >> @@ -0,0 +1,152 @@ >> +# >> +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. >> +# Use is subject to license terms. >> +# >> +# This program is free software; you can redistribute it and/or modify >> +# it under the terms of the GNU General Public License as published by >> +# the Free Software Foundation; either version 2 of the License, or >> +# (at your option) any later version. >> +# >> +# This program is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program; if not, write to the Free Software >> +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, >> +# MA 02110-1301 USA. >> +# >> + >> +from string import ascii_letters >> +import virtconv.vmconfig as vmconfig >> + >> +pv_boot_template = """ >> + >> + >> + %(arch)s >> + >> + >> + >> + >> + >> + pygrub >> + >> + %(pv_disks)s >> + >> +""" >> + >> +hvm_boot_template = """ >> + >> + >> + %(arch)s >> + >> + >> + >> + >> + %(hvm_disks)s >> + >> +""" >> + >> +image_template = """ >> + >> + %(name)s >> + >> + >> + %(description)s >> + >> + >> + %(boot_template)s >> + >> + %(nr_vcpus)s >> + %(memory)s >> + >> + >> + >> + >> + >> + %(storage)s >> + >> + >> +""" >> + >> +class virtimage_parser(vmconfig.parser): >> + """ >> + Support for virt-install's image format (see virt-image man page). >> + """ >> + name = "virt-image" >> + suffix = ".virt-image.xml" >> + >> + @staticmethod >> + def identify_file(input_file): >> + """ >> + Return True if the given file is of this format. >> + """ >> + raise NotImplementedError >> + >> + @staticmethod >> + def import_file(input_file): >> + """ >> + Import a configuration file. Raises if the file couldn't be >> + opened, or parsing otherwise failed. >> + """ >> + raise NotImplementedError >> + >> + @staticmethod >> + def export_file(vm, output_file): >> + """ >> + Export a configuration file. >> + @vm vm configuration instance >> + @file Output file >> + >> + Raises ValueError if configuration is not suitable, or another >> + exception on failure to write the output file. >> + """ >> + >> + if not vm.memory: >> + raise ValueError("VM must have a memory setting") >> + >> + pv_disks = [] >> + hvm_disks = [] >> + storage_disks = [] >> + >> + # create disk filename lists for xml template >> + for disk in vm.disks: >> + number = disk.number >> + path = disk.path >> + >> + # FIXME: needs updating for later Xen enhancements; need to >> + # implement capabilities checking for max disks etc. >> + pv_disks.append("""""" % >> + (path, ascii_letters[number % 26])) >> + hvm_disks.append("""""" % >> + (path, ascii_letters[number % 26])) >> + storage_disks.append( >> + """""" % path) >> + >> + if vm.type == vmconfig.VM_TYPE_PV: >> + boot_template = pv_boot_template >> + else: >> + boot_template = hvm_boot_template >> + >> + boot_xml = boot_template % { >> + "pv_disks" : "".join(pv_disks), >> + "hvm_disks" : "".join(hvm_disks), >> + "arch" : vm.arch, >> + } >> + >> + out = image_template % { >> + "boot_template": boot_xml, >> + "name" : vm.name, >> + "description" : vm.description, >> + "nr_vcpus" : vm.nr_vcpus, >> + # Mb to Kb >> + "memory" : int(vm.memory) * 1024, >> + "storage" : "".join(storage_disks), >> + } >> + >> + outfile = open(output_file, "w") >> + outfile.writelines(out) >> + outfile.close() >> + >> +vmconfig.register_parser(virtimage_parser) >> diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py >> new file mode 100644 >> --- /dev/null >> +++ b/virtconv/parsers/vmx.py >> @@ -0,0 +1,107 @@ >> +# >> +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. >> +# Use is subject to license terms. >> +# >> +# This program is free software; you can redistribute it and/or modify >> +# it under the terms of the GNU General Public License as published by >> +# the Free Software Foundation; either version 2 of the License, or >> +# (at your option) any later version. >> +# >> +# This program is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program; if not, write to the Free Software >> +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, >> +# MA 02110-1301 USA. >> +# >> + >> +import virtconv.vmconfig as vmconfig >> + >> +class vmx_parser(vmconfig.parser): >> + """ >> + Support for VMWare .vmx files. Note that documentation is >> + particularly sparse on this format, with pretty much the best >> + resource being http://sanbarrow.com/vmx.html >> + """ >> + >> + name = "vmx" >> + suffix = ".vmx" >> + >> + @staticmethod >> + def identify_file(input_file): >> + """ >> + Return True if the given file is of this format. >> + """ >> + raise NotImplementedError >> + >> + @staticmethod >> + def import_file(input_file): >> + """ >> + Import a configuration file. Raises if the file couldn't be >> + opened, or parsing otherwise failed. >> + """ >> + >> + vm = vmconfig.vm() >> + >> + infile = open(input_file, "r") >> + contents = infile.readlines() >> + infile.close() >> + >> + lines = [] >> + >> + # strip out comment and blank lines for easy splitting of values >> + for line in contents: >> + if not line.strip() or line.startswith("#"): >> + continue >> + else: >> + lines.append(line) >> + >> + config = {} >> + >> + # split out all remaining entries of key = value form >> + for (line_nr, line) in enumerate(lines): >> + try: >> + before_eq, after_eq = line.split("=", 1) >> + key = before_eq.replace(" ","") >> + value = after_eq.replace('"',"") >> + value = value.strip() >> + config[key] = value >> + except: >> + raise Exception("Syntax error at line %d: %s" % >> + (line_nr + 1, line.strip())) >> + >> + if not config.get("displayName"): >> + raise ValueError("No displayName defined in \"%s\"" % input_file) >> + vm.name = config.get("displayName") >> + >> + vm.memory = config.get("memsize") >> + vm.description = config.get("annotation") >> + vm.nr_vcpus = config.get("numvcpus") >> + >> + # FIXME: this should probably be a lot smarter. I don't think >> + # this even gets disk numbering right. >> + disks = [ d for d in config.values() if d.endswith(".vmdk") ] >> + >> + for (number, path) in enumerate(disks): >> + vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] >> + >> + vm.validate() >> + return vm >> + >> + @staticmethod >> + def export_file(vm, output_file): >> + """ >> + Export a configuration file. >> + @vm vm configuration instance >> + @file Output file >> + >> + Raises ValueError if configuration is not suitable, or another >> + exception on failure to write the output file. >> + """ >> + >> + raise NotImplementedError >> + >> +vmconfig.register_parser(vmx_parser) >> diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py >> new file mode 100644 >> --- /dev/null >> +++ b/virtconv/vmconfig.py >> @@ -0,0 +1,193 @@ >> +# >> +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. >> +# Use is subject to license terms. >> +# >> +# This program is free software; you can redistribute it and/or modify >> +# it under the terms of the GNU General Public License as published by >> +# the Free Software Foundation; either version 2 of the License, or >> +# (at your option) any later version. >> +# >> +# This program is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program; if not, write to the Free Software >> +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, >> +# MA 02110-1301 USA. >> +# >> + >> +import os >> + >> +_parsers = [ ] >> + >> +VM_TYPE_PV = 0 >> +VM_TYPE_HVM = 1 >> + >> +DISK_TYPE_RAW = 0 >> +DISK_TYPE_VMDK = 1 >> + >> +disk_suffixes = { >> + DISK_TYPE_RAW: ".img", >> + DISK_TYPE_VMDK: ".vmdk", >> +} >> + >> +qemu_formats = { >> + DISK_TYPE_RAW: "raw", >> + DISK_TYPE_VMDK: "vmdk", >> +} >> + >> +class disk(object): >> + """Definition of an individual disk instance.""" >> + >> + def __init__(self, path = None, number = None, type = None): >> + self.path = path >> + self.number = number >> + self.type = type >> + >> + def convert(self, input_dir, output_dir, output_type): >> + """ >> + Convert a disk into the requested format if possible, in the >> + given output directory. Raises NotImplementedError or other >> + failures. >> + """ >> + >> + if self.type == output_type: >> + return >> + >> + if output_type != DISK_TYPE_RAW: >> + raise NotImplementedError("Cannot convert to disk type %d" % >> + output_type) >> + >> + infile = self.path >> + >> + if not os.path.isabs(infile): >> + infile = os.path.join(input_dir, infile) >> + >> + outfile = self.path >> + >> + if os.path.isabs(outfile): >> + outfile = os.path.basename(outfile) >> + >> + outfile = outfile.replace(disk_suffixes[self.type], >> + disk_suffixes[output_type]).strip() >> + >> + convert_cmd = ("qemu-img convert \"%s\" -O %s \"%s\"" % >> + (infile, qemu_formats[output_type], >> + os.path.join(output_dir, outfile))) >> + >> + os.system(convert_cmd) >> + >> + # Note: this is the *relative* path still >> + self.path = outfile >> + self.type = output_type >> + >> + >> +class vm(object): >> + """ >> + Generic configuration for a particular VM instance. >> + >> + At export, a plugin is guaranteed to have the at least the following >> + values set (any others needed should be checked for, raising >> + ValueError on failure): >> + >> + vm.name >> + vm.description (defaults to empty string) >> + vm.nr_vcpus (defaults to 1) >> + vm.type >> + vm.arch >> + >> + If vm.memory is set, it is in Mb units. >> + """ >> + >> + name = None >> + suffix = None >> + >> + def __init__(self): >> + self.name = None >> + self.description = None >> + self.memory = None >> + self.nr_vcpus = None >> + self.disks = [ ] >> + self.type = VM_TYPE_HVM >> + self.arch = "i686" # FIXME? >> + >> + def validate(self): >> + """ >> + Validate all parameters, and fix up any unset values to meet the >> + guarantees we make above. >> + """ >> + >> + if not self.name: >> + raise ValueError("VM name is not set") >> + if not self.description: >> + self.description = "" >> + if not self.nr_vcpus: >> + self.nr_vcpus = 1 >> + if not self.type: >> + raise ValueError("VM type is not set") >> + if not self.arch: >> + raise ValueError("VM arch is not set") >> + >> + >> +class parser(object): >> + """ >> + Base class for particular config file format definitions of >> + a VM instance. >> + >> + Warning: this interface is not (yet) considered stable and may >> + change at will. >> + """ >> + >> + @staticmethod >> + def identify_file(input_file): >> + """ >> + Return True if the given file is of this format. >> + """ >> + raise NotImplementedError >> + >> + @staticmethod >> + def import_file(input_file): >> + """ >> + Import a configuration file. Raises if the file couldn't be >> + opened, or parsing otherwise failed. >> + """ >> + raise NotImplementedError >> + >> + @staticmethod >> + def export_file(vm, output_file): >> + """ >> + Export a configuration file. >> + @vm vm configuration instance >> + @output_file Output file >> + >> + Raises ValueError if configuration is not suitable, or another >> + exception on failure to write the output file. >> + """ >> + raise NotImplementedError >> + >> + >> +def register_parser(parser): >> + """ >> + Register a particular config format parser. This should be called by each >> + config plugin on import. >> + """ >> + >> + global _parsers >> + _parsers += [ parser ] >> + >> +def find_parser_by_name(name): >> + """ >> + Return the parser of the given name >> + """ >> + return [p for p in _parsers if p.name == name][0] or None >> + >> +def find_parser_by_file(input_file): >> + """ >> + Return the parser that is capable of comprehending the given file. >> + """ >> + for p in _parsers: >> + if p.identify_file(input_file): >> + return p >> + return None >> >> From sakaia at jp.fujitsu.com Fri Jul 4 09:14:08 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Fri, 04 Jul 2008 18:14:08 +0900 Subject: [et-mgmt-tools] Question about virt-inst build test status. Message-ID: <200807040914.m649E93r026063@fjmscan501.ms.jp.fujitsu.com> Hi, Dan Virtual Machine Installer is failed for 2 days with following message. Is there any plan to fix this? ================== WARNING:root:The filesystem will not have enough free space to fully allocate the sparse file when the guest is running. ================== http://builder.virt-manager.org/module-virtinst--devel.html Thanks Atsushi SAKAI From berrange at redhat.com Fri Jul 4 09:18:35 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 4 Jul 2008 10:18:35 +0100 Subject: [et-mgmt-tools] Question about virt-inst build test status. In-Reply-To: <200807040914.m649E93r026063@fjmscan501.ms.jp.fujitsu.com> References: <200807040914.m649E93r026063@fjmscan501.ms.jp.fujitsu.com> Message-ID: <20080704091835.GB27188@redhat.com> On Fri, Jul 04, 2008 at 06:14:08PM +0900, Atsushi SAKAI wrote: > Hi, Dan > > Virtual Machine Installer is failed for 2 days with following message. > Is there any plan to fix this? > > ================== > WARNING:root:The filesystem will not have enough free space to fully allocate the sparse file when the guest is running. > ================== That one is only a warning - the failure is caused by a change in the XML being generated which I've not tracked down yet. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Fri Jul 4 09:25:33 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 4 Jul 2008 10:25:33 +0100 Subject: [et-mgmt-tools] Question about virt-inst build test status. In-Reply-To: <20080704091835.GB27188@redhat.com> References: <200807040914.m649E93r026063@fjmscan501.ms.jp.fujitsu.com> <20080704091835.GB27188@redhat.com> Message-ID: <20080704092533.GC27188@redhat.com> On Fri, Jul 04, 2008 at 10:18:35AM +0100, Daniel P. Berrange wrote: > On Fri, Jul 04, 2008 at 06:14:08PM +0900, Atsushi SAKAI wrote: > > Hi, Dan > > > > Virtual Machine Installer is failed for 2 days with following message. > > Is there any plan to fix this? > > > > ================== > > WARNING:root:The filesystem will not have enough free space to fully allocate the sparse file when the guest is running. > > ================== > > That one is only a warning - the failure is caused by a change in the XML > being generated which I've not tracked down yet. Actually I've fixed it already - it was just a change I'd forgotten to commit & push. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Fri Jul 4 15:29:16 2008 From: levon at movementarian.org (John Levon) Date: Fri, 4 Jul 2008 16:29:16 +0100 Subject: [et-mgmt-tools] 'arch' in image XML Message-ID: <20080704152916.GA25070@totally.trollied.org.uk> What is the purpose of this option exactly? From a quick look it only seems to be used to select which RPMs to use when doing an install. Is there some extra semantics to it? Another question: it seems that virt-image always insists on an install step. What was the intent behind using virt-convert (nee virt-unpack) with virt-image output, in this case? thanks john From berrange at redhat.com Fri Jul 4 16:22:19 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 4 Jul 2008 17:22:19 +0100 Subject: [et-mgmt-tools] 'arch' in image XML In-Reply-To: <20080704152916.GA25070@totally.trollied.org.uk> References: <20080704152916.GA25070@totally.trollied.org.uk> Message-ID: <20080704162219.GB30428@redhat.com> On Fri, Jul 04, 2008 at 04:29:16PM +0100, John Levon wrote: > > What is the purpose of this option exactly? From a quick look it only > seems to be used to select which RPMs to use when doing an install. Is > there some extra semantics to it? The 'arch' is refering to the architecture of the guest OS kernel, eg one of i686, x86_64, ppc, sparc, etc, etc. The 'virsh capabilities' XML for a hypervisor driver declares what architectures the driver supports and thus allows virt-image to determine whether it is capable of executing the OS being requested. Some drivers like QEMU supported a whole suite of architectures by virtue of doing emulation, others only support matching host arch (eg Xen). Basically the idea behind the virt-image XML in general is to declare the requirements for its execution. This is matched up with capabilities of hosts. So things which are deployment specific are not included in the virt-image XML. As an example we declare the filessytem format (eg raw or qcow) but don't declare the full path or driver (eg tap vs phy vs file) since those are deployment details > Another question: it seems that virt-image always insists on an install > step. What was the intent behind using virt-convert (nee virt-unpack) > with virt-image output, in this case? I'm not sure what you mean by 'install step' here. The idea is that the disk image associated with the XML doc contains a pre-installed operating system (or 'appliance' in marketing buzzword bingo), so there isn't really any install step. We're merely validating requirements against capabilities, and configuring deployment specific details. The idea behind the virt-image/virt-unpack association is that the virt-image XML defines a portable format for 'appliance' metadata information (cf OVF) but not the distribution format (ZIP, tar.gz, etc). So the virt-pack tool would doing bundling into ZIP files. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Fri Jul 4 17:17:19 2008 From: levon at movementarian.org (John Levon) Date: Fri, 4 Jul 2008 18:17:19 +0100 Subject: [et-mgmt-tools] 'arch' in image XML In-Reply-To: <20080704162219.GB30428@redhat.com> References: <20080704152916.GA25070@totally.trollied.org.uk> <20080704162219.GB30428@redhat.com> Message-ID: <20080704171719.GA27473@totally.trollied.org.uk> On Fri, Jul 04, 2008 at 05:22:19PM +0100, Daniel P. Berrange wrote: > The 'arch' is refering to the architecture of the guest OS kernel, eg one > of i686, x86_64, ppc, sparc, etc, etc. The 'virsh capabilities' XML for > a hypervisor driver declares what architectures the driver supports and > thus allows virt-image to determine whether it is capable of executing > the OS being requested. Some drivers like QEMU supported a whole suite > of architectures by virtue of doing emulation, others only support matching > host arch (eg Xen). What do you mean? Xen most definitely runs i686 guest OSes on x86_64. But, thanks, I see now. > Basically the idea behind the virt-image XML in general is to declare the > requirements for its execution. This is matched up with capabilities of Right, I'd gathered as much. > > Another question: it seems that virt-image always insists on an install > > step. What was the intent behind using virt-convert (nee virt-unpack) > > with virt-image output, in this case? > > I'm not sure what you mean by 'install step' here. The idea is that the > disk image associated with the XML doc contains a pre-installed operating > system (or 'appliance' in marketing buzzword bingo), so there isn't > really any install step. We're merely validating requirements against > capabilities, and configuring deployment specific details. virt-image.py:217 dom = guest.start_install(None, progresscb, options.replace) Is this just using the install code as a shell, or something? > The idea behind the virt-image/virt-unpack association is that the > virt-image XML defines a portable format for 'appliance' metadata > information (cf OVF) but not the distribution format (ZIP, tar.gz, > etc). So the virt-pack tool would doing bundling into ZIP files. Right. It's not yet clear what's the best way to deal with the unpack/pack step: maybe virt-convert could automatically handle it. Presumably we /do/ want to move virt-pack to be virt-convert too at some point. regards john From berrange at redhat.com Fri Jul 4 18:53:25 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 4 Jul 2008 19:53:25 +0100 Subject: [et-mgmt-tools] 'arch' in image XML In-Reply-To: <20080704171719.GA27473@totally.trollied.org.uk> References: <20080704152916.GA25070@totally.trollied.org.uk> <20080704162219.GB30428@redhat.com> <20080704171719.GA27473@totally.trollied.org.uk> Message-ID: <20080704185325.GA17744@redhat.com> On Fri, Jul 04, 2008 at 06:17:19PM +0100, John Levon wrote: > On Fri, Jul 04, 2008 at 05:22:19PM +0100, Daniel P. Berrange wrote: > > > The 'arch' is refering to the architecture of the guest OS kernel, eg one > > of i686, x86_64, ppc, sparc, etc, etc. The 'virsh capabilities' XML for > > a hypervisor driver declares what architectures the driver supports and > > thus allows virt-image to determine whether it is capable of executing > > the OS being requested. Some drivers like QEMU supported a whole suite > > of architectures by virtue of doing emulation, others only support matching > > host arch (eg Xen). > > What do you mean? Xen most definitely runs i686 guest OSes on x86_64. Yes, the capabilities information for Xen on x86_64 declares both i686 and x86_64 capabilities. > > virt-image.py:217 > > dom = guest.start_install(None, progresscb, options.replace) > > Is this just using the install code as a shell, or something? Yeah, I think this is just badly named methods here - I'm pretty sure its just booting the guest. > > The idea behind the virt-image/virt-unpack association is that the > > virt-image XML defines a portable format for 'appliance' metadata > > information (cf OVF) but not the distribution format (ZIP, tar.gz, > > etc). So the virt-pack tool would doing bundling into ZIP files. > > Right. It's not yet clear what's the best way to deal with the > unpack/pack step: maybe virt-convert could automatically handle it. > Presumably we /do/ want to move virt-pack to be virt-convert too at some > point. Yeah, I think it'd be good to have it all in one tool - we need to decide on this before I do the next release of virtinst code. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Jul 7 16:30:13 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 7 Jul 2008 17:30:13 +0100 Subject: [et-mgmt-tools] [PATCH] modular virt-convert In-Reply-To: <486D02D7.9060702@redhat.com> References: <20080702160408.GN23929@totally.trollied.org.uk> <486D02D7.9060702@redhat.com> Message-ID: <20080707163013.GE16400@redhat.com> On Thu, Jul 03, 2008 at 12:48:23PM -0400, Cole Robinson wrote: > John Levon wrote: > > This is merged with current tip and now installs properly. > > > > thanks > > john > > > > > > Create config parser plugin system > > > > Start a plugin system for config formats parsing, and implement enough > > of it to get to where we were with virt-convert. > > > > Signed-off-by: John Levon > > > > This looks good to me. Seems like the way to go to expand this in > the future. > > If Dan and Joey are ok with this as well, I'll commit it. Yep, this gets my vote - go ahead & commit it. You'll probably need to add more to the %files section of the RPM spec because of the new top level 'virtconv' directory. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Mon Jul 7 19:28:23 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 07 Jul 2008 15:28:23 -0400 Subject: [et-mgmt-tools] [PATCH] modular virt-convert In-Reply-To: <20080707163013.GE16400@redhat.com> References: <20080702160408.GN23929@totally.trollied.org.uk> <486D02D7.9060702@redhat.com> <20080707163013.GE16400@redhat.com> Message-ID: <48726E57.9020301@redhat.com> Daniel P. Berrange wrote: > On Thu, Jul 03, 2008 at 12:48:23PM -0400, Cole Robinson wrote: >> John Levon wrote: >>> This is merged with current tip and now installs properly. >>> >>> thanks >>> john >>> >>> >>> Create config parser plugin system >>> >>> Start a plugin system for config formats parsing, and implement enough >>> of it to get to where we were with virt-convert. >>> >>> Signed-off-by: John Levon >>> >> This looks good to me. Seems like the way to go to expand this in >> the future. >> >> If Dan and Joey are ok with this as well, I'll commit it. > > Yep, this gets my vote - go ahead & commit it. > > You'll probably need to add more to the %files section of the RPM spec > because of the new top level 'virtconv' directory. > > Daniel Okay, pushed: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c1db997c73ff Thanks, Cole From levon at movementarian.org Mon Jul 7 20:29:14 2008 From: levon at movementarian.org (John Levon) Date: Mon, 7 Jul 2008 21:29:14 +0100 Subject: [et-mgmt-tools] [PATCH] modular virt-convert In-Reply-To: <48726E57.9020301@redhat.com> References: <20080702160408.GN23929@totally.trollied.org.uk> <486D02D7.9060702@redhat.com> <20080707163013.GE16400@redhat.com> <48726E57.9020301@redhat.com> Message-ID: <20080707202914.GA11501@totally.trollied.org.uk> On Mon, Jul 07, 2008 at 03:28:23PM -0400, Cole Robinson wrote: > Okay, pushed: > > http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c1db997c73ff You missed 'hg add' on the new files I think regards john From crobinso at redhat.com Mon Jul 7 22:50:38 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 07 Jul 2008 18:50:38 -0400 Subject: [et-mgmt-tools] [PATCH] modular virt-convert In-Reply-To: <20080707202914.GA11501@totally.trollied.org.uk> References: <20080702160408.GN23929@totally.trollied.org.uk> <486D02D7.9060702@redhat.com> <20080707163013.GE16400@redhat.com> <48726E57.9020301@redhat.com> <20080707202914.GA11501@totally.trollied.org.uk> Message-ID: <48729DBE.4010200@redhat.com> John Levon wrote: > On Mon, Jul 07, 2008 at 03:28:23PM -0400, Cole Robinson wrote: > >> Okay, pushed: >> >> http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c1db997c73ff > > You missed 'hg add' on the new files I think > > regards > john Whoops, sorry. Fixed now: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=a2be1263c2f5 Thanks, Cole From john.levon at sun.com Mon Jul 7 22:51:31 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:31 -0700 Subject: [et-mgmt-tools] [PATCH 01 of 11] Fix multiple disks In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215470367 25200 # Node ID c75d57437b7b219443580f6e9d6736d27d76ebcf # Parent a2be1263c2f5d3f346cfc3501682073fce2e8966 Fix multiple disks Fix handling of multiple disks. Signed-off-by: John Levon diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -117,12 +117,12 @@ class virtimage_parser(vmconfig.parser): # FIXME: needs updating for later Xen enhancements; need to # implement capabilities checking for max disks etc. - pv_disks.append("""""" % + pv_disks.append("""\n""" % (path, ascii_letters[number % 26])) - hvm_disks.append("""""" % + hvm_disks.append("""\n""" % (path, ascii_letters[number % 26])) storage_disks.append( - """""" % path) + """\n""" % path) if vm.type == vmconfig.VM_TYPE_PV: boot_template = pv_boot_template diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -60,6 +60,7 @@ class vmx_parser(vmconfig.parser): lines.append(line) config = {} + disks = [] # split out all remaining entries of key = value form for (line_nr, line) in enumerate(lines): @@ -69,6 +70,9 @@ class vmx_parser(vmconfig.parser): value = after_eq.replace('"',"") value = value.strip() config[key] = value + # FIXME: this should probably be a lot smarter. + if value.endswith(".vmdk"): + disks += [ value ] except: raise Exception("Syntax error at line %d: %s" % (line_nr + 1, line.strip())) @@ -80,10 +84,6 @@ class vmx_parser(vmconfig.parser): vm.memory = config.get("memsize") vm.description = config.get("annotation") vm.nr_vcpus = config.get("numvcpus") - - # FIXME: this should probably be a lot smarter. I don't think - # this even gets disk numbering right. - disks = [ d for d in config.values() if d.endswith(".vmdk") ] for (number, path) in enumerate(disks): vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] From john.levon at sun.com Mon Jul 7 22:51:40 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:40 -0700 Subject: [et-mgmt-tools] [PATCH 10 of 11] Support CD-ROMs In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215470463 25200 # Node ID bed866186030cc9549f6a020e0abda871fc008c2 # Parent 26beabc283b11e40ed01584be33678fd0840fed2 Support CD-ROMs Add support for CD-ROMs and also extend disk handling with some hokey checks for block versus file. Signed-off-by: John Levon diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -35,7 +35,7 @@ pv_boot_template = """ pygrub - %(pv_disks)s + %(disks)s """ @@ -47,7 +47,7 @@ hvm_boot_template = """ - %(hvm_disks)s + %(disks)s """ @@ -73,6 +73,71 @@ image_template = """ """ +def export_disks(vm): + """ + Export code for the disks. Slightly tricky for two reasons. + + We can't handle duplicate disks: some vmx files define SCSI/IDE devices + that point to the same storage, and Xen isn't happy about that. We + just ignore any entries that have duplicate paths. + + Since there is no meaningful SCSI support in rombios/qemu, we + forcibly switch the disks to IDE, and expect the guest OS to cope + (which at least Linux does admirably). + """ + + paths = [] + + disks = {} + + for (bus, instance), disk in sorted(vm.disks.iteritems()): + + if disk.path and disk.path in paths: + continue + + if bus == "scsi": + instance = 0 + while disks.get(("ide", instance)): + instance += 1 + + disks[("ide", instance)] = disk + + if disk.path: + paths += [ disk.path ] + + diskout = [] + storage = [] + + for (bus, instance), disk in sorted(disks.iteritems()): + + # virt-image XML cannot handle an empty CD device + if not disk.path: + continue + + path = disk.path + drive_nr = ascii_letters[int(instance) % 26] + + disk_prefix = "xvd" + if vm.type == vmconfig.VM_TYPE_HVM: + if bus == "ide": + disk_prefix = "hd" + else: + disk_prefix = "sd" + + # FIXME: needs updating for later Xen enhancements; need to + # implement capabilities checking for max disks etc. + diskout.append("""\n""" % + (path, disk_prefix, drive_nr)) + + type = "raw" + if disk.type == vmconfig.DISK_TYPE_ISO: + type = "iso" + storage.append( + """\n""" % + (path, type)) + + return storage, diskout + def export_os_params(vm): """ Export OS-specific parameters. @@ -143,26 +208,7 @@ class virtimage_parser(vmconfig.parser): if not vm.memory: raise ValueError("VM must have a memory setting") - pv_disks = [] - hvm_disks = [] - storage_disks = [] - - # create disk filename lists for xml template - for devid, disk in sorted(vm.disks.iteritems()): - if disk.type != vmconfig.DISK_TYPE_DISK: - continue - - path = disk.path - drive_nr = ascii_letters[int(devid[1]) % 26] - - # FIXME: needs updating for later Xen enhancements; need to - # implement capabilities checking for max disks etc. - pv_disks.append("""\n""" % - (path, drive_nr)) - hvm_disks.append("""\n""" % - (path, drive_nr)) - storage_disks.append( - """\n""" % path) + (storage, disks) = export_disks(vm) # Hmm. Any interface is a good interface? interface = None @@ -177,8 +223,7 @@ class virtimage_parser(vmconfig.parser): boot_template = hvm_boot_template boot_xml = boot_template % { - "pv_disks" : "".join(pv_disks), - "hvm_disks" : "".join(hvm_disks), + "disks" : "".join(disks), "arch" : vm.arch, "acpi" : acpi, "apic" : apic, @@ -192,7 +237,7 @@ class virtimage_parser(vmconfig.parser): # Mb to Kb "memory" : int(vm.memory) * 1024, "interface" : interface, - "storage" : "".join(storage_disks), + "storage" : "".join(storage), } outfile = open(output_file, "w") diff --git a/virtconv/parsers/virtinstance.py b/virtconv/parsers/virtinstance.py --- a/virtconv/parsers/virtinstance.py +++ b/virtconv/parsers/virtinstance.py @@ -22,6 +22,8 @@ import virtconv.vmconfig as vmconfig import virtconv.vmconfig as vmconfig import virtinst.FullVirtGuest as fv +import os +import stat import re bootloaders = { @@ -50,10 +52,10 @@ consoles = { } disk_template = """ - - - + + %(hostdev)s + %(readonly)s """ @@ -104,7 +106,7 @@ def export_netdevs(vm): netdevs = [] - for number, netdev in sorted(vm.netdevs.iteritems()): + for netdev in vm.netdevs.values(): mac = "" if netdev.mac != "auto": mac = "" % netdev.mac @@ -142,30 +144,97 @@ def export_netdevs(vm): def export_disks(vm): """ - Export code for the disks. - """ - - disk_prefix = "xvd" - if (vm.type == vmconfig.VM_TYPE_HVM): - disk_prefix = "hd" - - disks = [] - - for devid, disk in sorted(vm.disks.iteritems()): - if disk.type != vmconfig.DISK_TYPE_DISK: + Export code for the disks. Slightly tricky for two reasons. + + We can't handle duplicate disks: some vmx files define SCSI/IDE devices + that point to the same storage, and Xen isn't happy about that. We + just ignore any entries that have duplicate paths. + + Since there is no meaningful SCSI support in rombios/qemu, we + forcibly switch the disks to IDE, and expect the guest OS to cope + (which at least Linux does admirably). + """ + + out = [] + paths = [] + + disks = {} + + for (bus, instance), disk in sorted(vm.disks.iteritems()): + + if disk.path and disk.path in paths: continue + + if bus == "scsi": + instance = 0 + while disks.get(("ide", instance)): + instance += 1 + + disks[("ide", instance)] = disk + + if disk.path: + paths += [ disk.path ] + + for (bus, instance), disk in sorted(disks.iteritems()): + + if not disk.path: + typeattr = "" + hostdev = "" + + # It's quite common for .vmx files to reference a + # non-existent ISO (which was cleaned up in vmx_parser). + # Just skip them. + if disk.type == vmconfig.DISK_TYPE_ISO: + continue + else: + # Of course, this file path might be relative, so we won't be + # able to stat() it. In such a case, it's almost certainly a + # file anyway, so the fallback is fine. + typeattr = "type='file'" + hostdev = ("\n" + "\n" % disk.path) + + try: + if stat.S_ISBLK(os.stat(disk.path)[0]): + typeattr = "type='block'" + hostdev = ("\n" + "\n" % disk.path) + except: + pass + + device = "disk" + readonly = "" + + if (disk.type == vmconfig.DISK_TYPE_CDROM or + disk.type == vmconfig.DISK_TYPE_ISO): + device = "cdrom" + readonly = "" + + bus = "ide" + + disk_prefix = "xvd" + if vm.type == vmconfig.VM_TYPE_HVM: + if bus == "ide": + disk_prefix = "hd" + else: + disk_prefix = "sd" # FIXME: needs updating for later Xen enhancements; need to # implement capabilities checking for max disks etc. - drive_nr = ascii_letters[int(devid[1]) % 26] - - disks.append(disk_template % { - "path" : disk.path, + drive_nr = ascii_letters[int(instance) % 26] + + instance += 1 + + out.append(disk_template % { + "typeattr" : typeattr, + "device" : device, + "hostdev" : hostdev, "prefix" : disk_prefix, - "dev" : drive_nr + "dev" : drive_nr, + "readonly" : readonly, }) - - return disks + + return out def export_os_params(vm): """ diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -32,14 +32,18 @@ def parse_disk_entry(vm, fullkey, value) if re.match(r"^(scsi|ide)[0-9]+[^:]", fullkey): return - # FIXME: we don't check bus number, we should - _, bus, _, inst, key = re.split(r"^(scsi|ide)([0-9]+):([0-9]+)\.", + _, bus, bus_nr, inst, key = re.split(r"^(scsi|ide)([0-9]+):([0-9]+)\.", fullkey) lvalue = value.lower() if key == "present" and lvalue == "false": return + + # Does anyone else think it's scary that we're still doing things + # like this? + if bus == "ide": + inst = int(inst) + int(bus_nr) * 2 devid = (bus, inst) if not vm.disks.get(devid): From john.levon at sun.com Mon Jul 7 22:51:37 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:37 -0700 Subject: [et-mgmt-tools] [PATCH 07 of 11] Implement network device handling In-Reply-To: Message-ID: <20daa7230dc53978e5f6.1215471097@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1215470437 25200 # Node ID 20daa7230dc53978e5f67fabf7950d961ed3bdd8 # Parent a8f5d5be978f0237f41c35275936863c2787a73b Implement network device handling Also clean up disk processing somewhat. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -24,8 +24,8 @@ # # Convert between VM definition formats. TODO: # -# support networking # port virtinstance.py to Solaris +# networking support is nowhere near complete # better disk checking # support CD-ROM # add option for host selection @@ -212,9 +212,9 @@ def main(): try: for d in vmdef.disks: verbose(options, "Converting disk \"%s\" to type %s..." % - (d.path, vmconfig.qemu_formats[vmconfig.DISK_TYPE_RAW])) + (d.path, vmconfig.qemu_formats[vmconfig.DISK_FORMAT_RAW])) d.convert(options.input_dir, options.output_dir, - vmconfig.DISK_TYPE_RAW) + vmconfig.DISK_FORMAT_RAW) except OSError, e: cleanup("Couldn't convert disks: %s" % e.strerror, options, created_dir) except RuntimeError, e: diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -26,7 +26,7 @@ pv_boot_template = """ %(arch)s - + @@ -42,7 +42,7 @@ hvm_boot_template = """ %(arch)s - + %(hvm_disks)s @@ -60,8 +60,8 @@ image_template = """ %(nr_vcpus)s %(memory)s - - + %(interface)s + @@ -114,18 +114,26 @@ class virtimage_parser(vmconfig.parser): storage_disks = [] # create disk filename lists for xml template - for disk in vm.disks: - number = disk.number + for devid, disk in sorted(vm.disks.iteritems()): + if disk.type != vmconfig.DISK_TYPE_DISK: + continue + path = disk.path + drive_nr = ascii_letters[int(devid[1]) % 26] # FIXME: needs updating for later Xen enhancements; need to # implement capabilities checking for max disks etc. pv_disks.append("""\n""" % - (path, ascii_letters[number % 26])) + (path, drive_nr)) hvm_disks.append("""\n""" % - (path, ascii_letters[number % 26])) + (path, drive_nr)) storage_disks.append( """\n""" % path) + + # Hmm. Any interface is a good interface? + interface = None + if len(vm.netdevs): + interface = "" if vm.type == vmconfig.VM_TYPE_PV: boot_template = pv_boot_template @@ -145,6 +153,7 @@ class virtimage_parser(vmconfig.parser): "nr_vcpus" : vm.nr_vcpus, # Mb to Kb "memory" : int(vm.memory) * 1024, + "interface" : interface, "storage" : "".join(storage_disks), } diff --git a/virtconv/parsers/virtinstance.py b/virtconv/parsers/virtinstance.py --- a/virtconv/parsers/virtinstance.py +++ b/virtconv/parsers/virtinstance.py @@ -54,6 +54,14 @@ disk_template = """ +""" + +netdev_template = """ + + %(source)s + %(mac)s + %(model)s + """ instance_template = """ @@ -77,6 +85,7 @@ instance_template = """ %(emulator)s %(disks)s + %(netdevs)s @@ -95,6 +104,11 @@ class virtinstance_parser(vmconfig.parse example, the pygrub path. For now, we'll assume it's for the current platform. In the future we might want to consider adding a --host-type option. + + Known limitations: + + - Only handles bridge, ethernet, and network type netdevs + - doesn't handle netdev script or IP address """ name = "virt-instance" @@ -142,16 +156,54 @@ class virtinstance_parser(vmconfig.parse disk_prefix = "hd" disks = [] - - for disk in vm.disks: - drive_nr = ascii_letters[disk.number % 26] + netdevs = [] + + for devid, disk in sorted(vm.disks.iteritems()): + if disk.type != vmconfig.DISK_TYPE_DISK: + continue # FIXME: needs updating for later Xen enhancements; need to # implement capabilities checking for max disks etc. + drive_nr = ascii_letters[int(devid[1]) % 26] + disks.append(disk_template % { "path" : disk.path, "prefix" : disk_prefix, "dev" : drive_nr + }) + + for number, netdev in sorted(vm.netdevs.iteritems()): + mac = "" + if netdev.mac != "auto": + mac = "" % netdev.mac + + nettype = { + vmconfig.NETDEV_TYPE_DEV : "ethernet", + vmconfig.NETDEV_TYPE_BRIDGE : "bridge", + vmconfig.NETDEV_TYPE_UNKNOWN : "bridge", + vmconfig.NETDEV_TYPE_NETWORK : "network", + }.get(netdev.type) + + source = "" + if netdev.source: + srcattr = nettype + if netdev.type == vmconfig.NETDEV_TYPE_DEV: + srcattr = "dev" + source = "" % (srcattr, netdev.source) + + # FIXME: should warn here + if not nettype: + continue + + model = "" + if netdev.driver: + model = "" % netdev.driver + + netdevs.append(netdev_template % { + "type" : nettype, + "source" : source, + "mac" : mac, + "model": model, }) out = instance_template % { @@ -164,6 +216,7 @@ class virtinstance_parser(vmconfig.parse "memory" : int(vm.memory) * 1024, "nr_vcpus" : vm.nr_vcpus, "emulator" : emulators[vm.type], + "netdevs" : "".join(netdevs), "disks" : "".join(disks), "console" : consoles[vm.type], } diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -20,7 +20,68 @@ import virtconv.vmconfig as vmconfig import re +import os +def parse_disk_entry(vm, fullkey, value): + """ + Parse a particular key/value for a disk. FIXME: this should be a + lot smarter. + """ + + # skip bus values, e.g. 'scsi0.present = "TRUE"' + if re.match(r"^(scsi|ide)[0-9]+[^:]", fullkey): + return + + # FIXME: we don't check bus number, we should + _, bus, _, inst, key = re.split(r"^(scsi|ide)([0-9]+):([0-9]+)\.", + fullkey) + + lvalue = value.lower() + + if key == "present" and lvalue == "false": + return + + devid = (bus, inst) + if not vm.disks.get(devid): + vm.disks[devid] = vmconfig.disk(bus = bus, + type = vmconfig.DISK_TYPE_DISK) + + if key == "deviceType": + if lvalue == "atapi-cdrom" or lvalue == "cdrom-raw": + vm.disks[devid].type = vmconfig.DISK_TYPE_CDROM + elif lvalue == "cdrom-image": + vm.disks[devid].type = vmconfig.DISK_TYPE_ISO + + if key == "fileName": + vm.disks[devid].path = value + vm.disks[devid].format = vmconfig.DISK_FORMAT_RAW + if lvalue.endswith(".vmdk"): + vm.disks[devid].format = vmconfig.DISK_FORMAT_VMDK + +def parse_netdev_entry(vm, fullkey, value): + """ + Parse a particular key/value for a network. Throws ValueError. + """ + + _, _, inst, key = re.split("^(ethernet)([0-9]+).", fullkey) + + lvalue = value.lower() + + if key == "present" and lvalue == "false": + return + + if not vm.netdevs.get(inst): + vm.netdevs[inst] = vmconfig.netdev(type = vmconfig.NETDEV_TYPE_UNKNOWN) + + # "vlance", "vmxnet", "e1000" + if key == "virtualDev": + vm.netdevs[inst].driver = lvalue + if key == "addressType" and lvalue == "generated": + vm.netdevs[inst].mac = "auto" + # we ignore .generatedAddress for auto mode + if key == "address": + vm.netdevs[inst].mac = lvalue + class vmx_parser(vmconfig.parser): """ Support for VMWare .vmx files. Note that documentation is @@ -71,22 +132,31 @@ class vmx_parser(vmconfig.parser): lines.append(line) config = {} - disks = [] # split out all remaining entries of key = value form for (line_nr, line) in enumerate(lines): try: before_eq, after_eq = line.split("=", 1) - key = before_eq.replace(" ","") - value = after_eq.replace('"',"") - value = value.strip() + key = before_eq.strip() + value = after_eq.strip().strip('"') config[key] = value - # FIXME: this should probably be a lot smarter. - if value.endswith(".vmdk"): - disks += [ value ] + + if key.startswith("scsi") or key.startswith("ide"): + parse_disk_entry(vm, key, value) + if key.startswith("ethernet"): + parse_netdev_entry(vm, key, value) except: raise Exception("Syntax error at line %d: %s" % (line_nr + 1, line.strip())) + + for devid, disk in vm.disks.iteritems(): + if disk.type == vmconfig.DISK_TYPE_DISK: + continue + + # vmx files often have dross left in path for CD entries + if (disk.path == "auto detect" or + not os.path.exists(disk.path)): + vm.disks[devid].path = None if not config.get("displayName"): raise ValueError("No displayName defined in \"%s\"" % input_file) @@ -95,10 +165,7 @@ class vmx_parser(vmconfig.parser): vm.memory = config.get("memsize") vm.description = config.get("annotation") vm.nr_vcpus = config.get("numvcpus") - - for (number, path) in enumerate(disks): - vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] - + vm.validate() return vm diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -25,40 +25,54 @@ VM_TYPE_PV = 0 VM_TYPE_PV = 0 VM_TYPE_HVM = 1 -DISK_TYPE_RAW = 0 -DISK_TYPE_VMDK = 1 +NETDEV_TYPE_UNKNOWN = 0 +NETDEV_TYPE_DEV = 1 +NETDEV_TYPE_BRIDGE = 2 +NETDEV_TYPE_NETWORK = 3 + +DISK_FORMAT_RAW = 0 +DISK_FORMAT_VMDK = 1 + +DISK_TYPE_DISK = 0 +DISK_TYPE_CDROM = 1 +DISK_TYPE_ISO = 2 disk_suffixes = { - DISK_TYPE_RAW: ".img", - DISK_TYPE_VMDK: ".vmdk", + DISK_FORMAT_RAW: ".img", + DISK_FORMAT_VMDK: ".vmdk", } qemu_formats = { - DISK_TYPE_RAW: "raw", - DISK_TYPE_VMDK: "vmdk", + DISK_FORMAT_RAW: "raw", + DISK_FORMAT_VMDK: "vmdk", } class disk(object): """Definition of an individual disk instance.""" - def __init__(self, path = None, number = None, type = None): + def __init__(self, path = None, format = None, bus = "ide", + type = DISK_TYPE_DISK): self.path = path - self.number = number + self.format = format + self.bus = bus self.type = type - def convert(self, input_dir, output_dir, output_type): + def convert(self, input_dir, output_dir, output_format): """ Convert a disk into the requested format if possible, in the - given output directory. Raises NotImplementedError or other + given output directory. Raises RuntimeError or other failures. """ - if self.type == output_type: + if self.format == output_format: return - if output_type != DISK_TYPE_RAW: - raise NotImplementedError("Cannot convert to disk type %d" % - output_type) + if self.type != DISK_TYPE_DISK: + return + + if output_format != DISK_FORMAT_RAW: + raise NotImplementedError("Cannot convert to disk format %d" % + output_format) infile = self.path @@ -70,11 +84,11 @@ class disk(object): if os.path.isabs(outfile): outfile = os.path.basename(outfile) - outfile = outfile.replace(disk_suffixes[self.type], - disk_suffixes[output_type]).strip() + outfile = outfile.replace(disk_suffixes[self.format], + disk_suffixes[output_format]).strip() convert_cmd = ("qemu-img convert \"%s\" -O %s \"%s\"" % - (infile, qemu_formats[output_type], + (infile, qemu_formats[output_format], os.path.join(output_dir, outfile))) ret = os.system(convert_cmd) @@ -83,8 +97,22 @@ class disk(object): # Note: this is the *relative* path still self.path = outfile - self.type = output_type - + self.format = output_format + +class netdev(object): + """Definition of an individual network device.""" + + def __init__(self, mac = "auto", type = NETDEV_TYPE_UNKNOWN, + source = None, driver = None): + """@mac: either a MAC address, or "auto" + @type: NETDEV_TYPE_* + @source: bridge or net device, or network name + @driver: device emulated for VM (e.g. vmxnet) + """ + self.mac = mac + self.type = type + self.source = source + self.driver = driver class vm(object): """ @@ -111,7 +139,8 @@ class vm(object): self.description = None self.memory = None self.nr_vcpus = None - self.disks = [ ] + self.disks = {} + self.netdevs = {} self.type = VM_TYPE_HVM self.arch = "i686" # FIXME? @@ -132,7 +161,11 @@ class vm(object): if not self.arch: raise ValueError("VM arch is not set") - + for (bus, inst), disk in self.disks.iteritems(): + if not disk.path and disk.type == DISK_TYPE_DISK: + raise ValueError("Disk device %s:%d has no path." % + (bus, inst)) + class parser(object): """ Base class for particular config file format definitions of From john.levon at sun.com Mon Jul 7 22:51:41 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:41 -0700 Subject: [et-mgmt-tools] [PATCH 11 of 11] Add --host option In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215470469 25200 # Node ID d025b8efe3e3f578e731a452417a0dd5ef73d8ac # Parent bed866186030cc9549f6a020e0abda871fc008c2 Add --host option Some formats need unpleasant knowledge of what hypervisor they're going to run on. We default to the current machine, but add a --host option to allow people to choose (and so we can write tests). Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -129,7 +129,7 @@ .\" ======================================================================== .\" .IX Title "VIRT-CONVERT 1" -.TH VIRT-CONVERT 1 "2008-07-04" "perl v5.8.8" "Virtual Machine Install Tools" +.TH VIRT-CONVERT 1 "2008-07-07" "perl v5.8.8" "Virtual Machine Install Tools" .SH "NAME" virt\-convert \- convert virtual machines between formats .SH "SYNOPSIS" @@ -159,6 +159,11 @@ a libvirt \*(L"image\*(R" \s-1XML\s0 def .IP "\-h, \-\-help" 4 .IX Item "-h, --help" Show the help message and exit +.IP "\-H \s-1HOST\s0, \-\-host=HOST" 4 +.IX Item "-H HOST, --host=HOST" +Hypervisor target host. This is needed for some output formats such as +\&\f(CW\*(C`virt\-instance\*(C'\fR, and it will default to the current host. Current +accepted values are 'xvm' (for Solaris xVM), or 'xen' (for Xen). .IP "\-a \s-1ARCH\s0, \-\-arch=ARCH" 4 .IX Item "-a ARCH, --arch=ARCH" Architecture of the virtual machine (i686, x86_64, ppc). Defaults to diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -37,6 +37,12 @@ a libvirt "image" XML definition (see L< Show the help message and exit +=item -H HOST, --host=HOST + +Hypervisor target host. This is needed for some output formats such as +C, and it will default to the current host. Current +accepted values are 'xvm' (for Solaris xVM), or 'xen' (for Xen). + =item -a ARCH, --arch=ARCH Architecture of the virtual machine (i686, x86_64, ppc). Defaults to diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -83,6 +83,8 @@ def parse_args(): help=("Disables APIC for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) opts.add_option("", "--noacpi", action="store_true", dest="noacpi", help=("Disables ACPI for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) + opts.add_option("-H", "--host", type="string", dest="host", action="store", + default=vmconfig.default_host(), help=("Host hypervisor type, e.g. 'xen'")) (options, args) = opts.parse_args() if len(args) < 1: @@ -196,6 +198,7 @@ def main(): else: vmdef.type = vmconfig.VM_TYPE_HVM + vmdef.host = options.host vmdef.arch = options.arch vmdef.os_type = options.os_type vmdef.os_variant = options.os_variant diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -19,6 +19,8 @@ # import os + +from virtinst import util _parsers = [ ] @@ -286,3 +288,13 @@ def find_input(path, format = None): return (os.path.join(path, cfgfile), p.name) raise StandardError("unknown format") + +def default_host(): + """ + Return the default host hypervisor, or 'None' if none seems present. + """ + if platform.system() == "SunOS": + return "xvm" + + # FIXME: should we massage this value? + return util.default_connection() From john.levon at sun.com Mon Jul 7 22:51:39 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:39 -0700 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: Message-ID: <26beabc283b11e40ed01.1215471099@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1215470455 25200 # Node ID 26beabc283b11e40ed01584be33678fd0840fed2 # Parent 9d9b282172f77f9d77035017bb0bc8e219be18ba Add OS variant options to virt-convert. And use them to set ACPI, APIC, clock, and USB tablet. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -186,6 +186,151 @@ Print debugging information .IP "\-q, \-\-quiet" 4 .IX Item "-q, --quiet" Avoid verbose output. +.IP "\-\-os\-type=OS_TYPE" 4 +.IX Item "--os-type=OS_TYPE" +Optimize the guest configuration for a type of operating system. This will +attempt to pick the most suitable \s-1ACPI\s0 & \s-1APIC\s0 settings, optimally supported +mouse drivers and generally accommodate other operating system quirks. The +valid operating system types are +.RS 4 +.IP "linux" 4 +.IX Item "linux" +Linux 2.x series +.IP "windows" 4 +.IX Item "windows" +Microsoft Windows 9x or later +.IP "unix" 4 +.IX Item "unix" +Traditional \s-1UNIX\s0 \s-1BSD\s0 or SysV derivatives +.IP "other" 4 +.IX Item "other" +Operating systems not in one of the 3 prior groups +.RE +.RS 4 +.RE +.IP "\-\-os\-variant=OS_VARIANT" 4 +.IX Item "--os-variant=OS_VARIANT" +Further optimize the guest configuration for a specific operating system +variant. This parameter is optional. The valid variants are +.RS 4 +.IP "linux" 4 +.IX Item "linux" +.RS 4 +.PD 0 +.IP "rhel2.1" 4 +.IX Item "rhel2.1" +.PD +Red Hat Enterprise Linux 2.1 +.IP "rhel3" 4 +.IX Item "rhel3" +Red Hat Enterprise Linux 3 +.IP "rhel4" 4 +.IX Item "rhel4" +Red Hat Enterprise Linux 4 +.IP "rhel5" 4 +.IX Item "rhel5" +Red Hat Enterprise Linux 5 +.IP "centos5" 4 +.IX Item "centos5" +Cent \s-1OS\s0 5 +.IP "fedora5" 4 +.IX Item "fedora5" +Fedora Core 5 +.IP "fedora6" 4 +.IX Item "fedora6" +Fedora Core 6 +.IP "fedora7" 4 +.IX Item "fedora7" +Fedora 7 +.IP "sles10" 4 +.IX Item "sles10" +Suse Linux Enterprise Server 10.x +.IP "debianEtch" 4 +.IX Item "debianEtch" +Debian 4.0 (Etch) +.IP "debianLenny" 4 +.IX Item "debianLenny" +Debian Lenny +.IP "generic26" 4 +.IX Item "generic26" +Generic Linux 2.6.x kernel +.IP "generic24" 4 +.IX Item "generic24" +Generic Linux 2.4.x kernel +.RE +.RS 4 +.RE +.IP "windows" 4 +.IX Item "windows" +.RS 4 +.PD 0 +.IP "winxp" 4 +.IX Item "winxp" +.PD +Microsoft Windows \s-1XP\s0 +.IP "win2k" 4 +.IX Item "win2k" +Microsoft Windows 2000 +.IP "win2k3" 4 +.IX Item "win2k3" +Microsoft Windows 2003 +.IP "vista" 4 +.IX Item "vista" +Microsoft Windows Vista +.RE +.RS 4 +.RE +.IP "unix" 4 +.IX Item "unix" +.RS 4 +.PD 0 +.IP "solaris9" 4 +.IX Item "solaris9" +.PD +Sun Solaris 9 +.IP "solaris10" 4 +.IX Item "solaris10" +Sun Solaris 10 +.IP "freebsd6" 4 +.IX Item "freebsd6" +Free \s-1BSD\s0 6.x +.IP "openbsd4" 4 +.IX Item "openbsd4" +Open \s-1BSD\s0 4.x +.RE +.RS 4 +.RE +.IP "other" 4 +.IX Item "other" +.RS 4 +.PD 0 +.IP "msdos" 4 +.IX Item "msdos" +.PD +Microsoft \s-1DOS\s0 +.IP "netware4" 4 +.IX Item "netware4" +Novell Netware 4 +.IP "netware5" 4 +.IX Item "netware5" +Novell Netware 5 +.IP "netware6" 4 +.IX Item "netware6" +Novell Netware 6 +.RE +.RS 4 +.RE +.RE +.RS 4 +.RE +.IP "\-\-noapic" 4 +.IX Item "--noapic" +Override the \s-1OS\s0 type / variant to disables the \s-1APIC\s0 setting for fully +virtualized guest. +.IP "\-\-noacpi" 4 +.IX Item "--noacpi" +Override the \s-1OS\s0 type / variant to disables the \s-1ACPI\s0 setting for fully +virtualized guest. .SH "EXAMPLES" .IX Header "EXAMPLES" Convert a paravirt guest from \f(CW\*(C`image.vmx\*(C'\fR: diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -72,6 +72,176 @@ Print debugging information Avoid verbose output. +=item --os-type=OS_TYPE + +Optimize the guest configuration for a type of operating system. This will +attempt to pick the most suitable ACPI & APIC settings, optimally supported +mouse drivers and generally accommodate other operating system quirks. The +valid operating system types are + +=over 4 + +=item linux + +Linux 2.x series + +=item windows + +Microsoft Windows 9x or later + +=item unix + +Traditional UNIX BSD or SysV derivatives + +=item other + +Operating systems not in one of the 3 prior groups + +=back + +=item --os-variant=OS_VARIANT + +Further optimize the guest configuration for a specific operating system +variant. This parameter is optional. The valid variants are + +=over 4 + +=item linux + +=over 4 + +=item rhel2.1 + +Red Hat Enterprise Linux 2.1 + +=item rhel3 + +Red Hat Enterprise Linux 3 + +=item rhel4 + +Red Hat Enterprise Linux 4 + +=item rhel5 + +Red Hat Enterprise Linux 5 + +=item centos5 + +Cent OS 5 + +=item fedora5 + +Fedora Core 5 + +=item fedora6 + +Fedora Core 6 + +=item fedora7 + +Fedora 7 + +=item sles10 + +Suse Linux Enterprise Server 10.x + +=item debianEtch + +Debian 4.0 (Etch) + +=item debianLenny + +Debian Lenny + +=item generic26 + +Generic Linux 2.6.x kernel + +=item generic24 + +Generic Linux 2.4.x kernel + +=back + +=item windows + +=over 4 + +=item winxp + +Microsoft Windows XP + +=item win2k + +Microsoft Windows 2000 + +=item win2k3 + +Microsoft Windows 2003 + +=item vista + +Microsoft Windows Vista + +=back + +=item unix + +=over 4 + +=item solaris9 + +Sun Solaris 9 + +=item solaris10 + +Sun Solaris 10 + +=item freebsd6 + +Free BSD 6.x + +=item openbsd4 + +Open BSD 4.x + +=back + +=item other + +=over 4 + +=item msdos + +Microsoft DOS + +=item netware4 + +Novell Netware 4 + +=item netware5 + +Novell Netware 5 + +=item netware6 + +Novell Netware 6 + +=back + +=back + +=item --noapic + +Override the OS type / variant to disables the APIC setting for fully +virtualized guest. + +=item --noacpi + +Override the OS type / variant to disables the ACPI setting for fully +virtualized guest. + =back =head1 EXAMPLES diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -73,6 +73,16 @@ def parse_args(): help=("This guest should be a fully virtualized guest")) opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", help=("This guest should be a paravirtualized guest")) + opts.add_option("", "--os-type", type="string", dest="os_type", + action="callback", callback=cli.check_before_store, + help=("The OS type for fully virtualized guests, e.g. 'linux', 'unix', 'windows'")) + opts.add_option("", "--os-variant", type="string", dest="os_variant", + action="callback", callback=cli.check_before_store, + help=("The OS variant for fully virtualized guests, e.g. 'fedora6', 'rhel5', 'solaris10', 'win2k', 'vista'")) + opts.add_option("", "--noapic", action="store_true", dest="noapic", + help=("Disables APIC for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) + opts.add_option("", "--noacpi", action="store_true", dest="noacpi", + help=("Disables ACPI for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) (options, args) = opts.parse_args() if len(args) < 1: @@ -187,6 +197,10 @@ def main(): vmdef.type = vmconfig.VM_TYPE_HVM vmdef.arch = options.arch + vmdef.os_type = options.os_type + vmdef.os_variant = options.os_variant + vmdef.noapic = options.noapic + vmdef.noacpi = options.noacpi created_dir = False unixname = vmdef.name.replace(" ", "-") diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -20,12 +20,15 @@ from string import ascii_letters import virtconv.vmconfig as vmconfig +import virtinst.FullVirtGuest as fv pv_boot_template = """ %(arch)s + $(acpi)s + $(apic)s @@ -70,6 +73,37 @@ image_template = """ """ +def export_os_params(vm): + """ + Export OS-specific parameters. + """ + ostype = None + osvariant = None + + ostype = fv.OS_TYPES.get(vm.os_type) + if ostype: + osvariant = ostype.variants.get(vm.os_variant) + + def get_os_val(key, default): + val = None + if osvariant: + val = osvariant.get(key) + if not val and ostype: + val = ostype.get(key) + if not val: + val = default + return val + + acpi = "" + if vm.noacpi is False and get_os_val("acpi", True): + acpi = "" + + apic = "" + if vm.noapic is False and get_os_val("apic", False): + apic = "" + + return acpi, apic + class virtimage_parser(vmconfig.parser): """ Support for virt-install's image format (see virt-image man page). @@ -135,6 +169,8 @@ class virtimage_parser(vmconfig.parser): if len(vm.netdevs): interface = "" + acpi, apic = export_os_params(vm) + if vm.type == vmconfig.VM_TYPE_PV: boot_template = pv_boot_template else: @@ -144,6 +180,8 @@ class virtimage_parser(vmconfig.parser): "pv_disks" : "".join(pv_disks), "hvm_disks" : "".join(hvm_disks), "arch" : vm.arch, + "acpi" : acpi, + "apic" : apic, } out = image_template % { diff --git a/virtconv/parsers/virtinstance.py b/virtconv/parsers/virtinstance.py --- a/virtconv/parsers/virtinstance.py +++ b/virtconv/parsers/virtinstance.py @@ -20,6 +20,7 @@ from string import ascii_letters import virtconv.vmconfig as vmconfig +import virtinst.FullVirtGuest as fv import re @@ -78,21 +79,131 @@ instance_template = """ destroy restart restart + - + %(acpi)s + %(apic)s %(emulator)s %(disks)s %(netdevs)s + - - + %(usbtablet)s %(console)s """ + +def export_netdevs(vm): + """ + Export code for the network devices. + """ + + netdevs = [] + + for number, netdev in sorted(vm.netdevs.iteritems()): + mac = "" + if netdev.mac != "auto": + mac = "" % netdev.mac + + nettype = { + vmconfig.NETDEV_TYPE_DEV : "ethernet", + vmconfig.NETDEV_TYPE_BRIDGE : "bridge", + vmconfig.NETDEV_TYPE_UNKNOWN : "bridge", + vmconfig.NETDEV_TYPE_NETWORK : "network", + }.get(netdev.type) + + source = "" + if netdev.source: + srcattr = nettype + if netdev.type == vmconfig.NETDEV_TYPE_DEV: + srcattr = "dev" + source = "" % (srcattr, netdev.source) + + # FIXME: should warn here + if not nettype: + continue + + model = "" + if netdev.driver: + model = "" % netdev.driver + + netdevs.append(netdev_template % { + "type" : nettype, + "source" : source, + "mac" : mac, + "model": model, + }) + + return netdevs + +def export_disks(vm): + """ + Export code for the disks. + """ + + disk_prefix = "xvd" + if (vm.type == vmconfig.VM_TYPE_HVM): + disk_prefix = "hd" + + disks = [] + + for devid, disk in sorted(vm.disks.iteritems()): + if disk.type != vmconfig.DISK_TYPE_DISK: + continue + + # FIXME: needs updating for later Xen enhancements; need to + # implement capabilities checking for max disks etc. + drive_nr = ascii_letters[int(devid[1]) % 26] + + disks.append(disk_template % { + "path" : disk.path, + "prefix" : disk_prefix, + "dev" : drive_nr + }) + + return disks + +def export_os_params(vm): + """ + Export OS-specific parameters. + """ + ostype = None + osvariant = None + + ostype = fv.OS_TYPES.get(vm.os_type) + if ostype: + osvariant = ostype.variants.get(vm.os_variant) + + def get_os_val(key, default): + val = None + if osvariant: + val = osvariant.get(key) + if not val and ostype: + val = ostype.get(key) + if not val: + val = default + return val + + acpi = "" + if vm.noacpi is False and get_os_val("acpi", True): + acpi = "" + + apic = "" + if vm.noapic is False and get_os_val("apic", False): + apic = "" + + clock = get_os_val("clock", "utc") + + usbtablet = "" + if get_os_val("input", [ "tablet", "usb" ])[0] == "tablet": + usbtablet = "" + + return acpi, apic, clock, usbtablet + class virtinstance_parser(vmconfig.parser): """ @@ -150,61 +261,13 @@ class virtinstance_parser(vmconfig.parse vmname = re.sub(r'[^A-Za-z0-9_.:/+-]+', '_', vm.name) vmtype = "xen" - disk_prefix = "xvd" if (vm.type == vmconfig.VM_TYPE_HVM): vmtype = "hvm" - disk_prefix = "hd" - - disks = [] - netdevs = [] - - for devid, disk in sorted(vm.disks.iteritems()): - if disk.type != vmconfig.DISK_TYPE_DISK: - continue - - # FIXME: needs updating for later Xen enhancements; need to - # implement capabilities checking for max disks etc. - drive_nr = ascii_letters[int(devid[1]) % 26] - - disks.append(disk_template % { - "path" : disk.path, - "prefix" : disk_prefix, - "dev" : drive_nr - }) - - for number, netdev in sorted(vm.netdevs.iteritems()): - mac = "" - if netdev.mac != "auto": - mac = "" % netdev.mac - - nettype = { - vmconfig.NETDEV_TYPE_DEV : "ethernet", - vmconfig.NETDEV_TYPE_BRIDGE : "bridge", - vmconfig.NETDEV_TYPE_UNKNOWN : "bridge", - vmconfig.NETDEV_TYPE_NETWORK : "network", - }.get(netdev.type) - - source = "" - if netdev.source: - srcattr = nettype - if netdev.type == vmconfig.NETDEV_TYPE_DEV: - srcattr = "dev" - source = "" % (srcattr, netdev.source) - - # FIXME: should warn here - if not nettype: - continue - - model = "" - if netdev.driver: - model = "" % netdev.driver - - netdevs.append(netdev_template % { - "type" : nettype, - "source" : source, - "mac" : mac, - "model": model, - }) + + netdevs = export_netdevs(vm) + disks = export_disks(vm) + + acpi, apic, clock, usbtablet = export_os_params(vm) out = instance_template % { "name" : vmname.replace(" ", "-"), @@ -215,9 +278,13 @@ class virtinstance_parser(vmconfig.parse # Mb to Kb "memory" : int(vm.memory) * 1024, "nr_vcpus" : vm.nr_vcpus, + "clock" : clock, + "acpi" : acpi, + "apic" : apic, "emulator" : emulators[vm.type], + "disks" : "".join(disks), "netdevs" : "".join(netdevs), - "disks" : "".join(disks), + "usbtablet" : usbtablet, "console" : consoles[vm.type], } From john.levon at sun.com Mon Jul 7 22:51:38 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:38 -0700 Subject: [et-mgmt-tools] [PATCH 08 of 11] Allow specification of output disk format In-Reply-To: Message-ID: <9d9b282172f77f9d7703.1215471098@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1215470441 25200 # Node ID 9d9b282172f77f9d77035017bb0bc8e219be18ba # Parent 20daa7230dc53978e5f67fabf7950d961ed3bdd8 Allow specification of output disk format In particular, allow the disk conversion to be skipped. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -176,6 +176,10 @@ Input format. Currently, \f(CW\*(C`vmx\* .IX Item "-o format" Output format. Currently, the only supported outputs are \f(CW\*(C`virt\-image\*(C'\fR and \f(CW\*(C`virt\-instance\*(C'\fR. +.IP "\-D format" 4 +.IX Item "-D format" +Output disk format, or \f(CW\*(C`none\*(C'\fR if no conversion should be performed. See +\&\fIqemu\-img\fR\|(1). .IP "\-d, \-\-debug" 4 .IX Item "-d, --debug" Print debugging information @@ -197,7 +201,7 @@ Convert a 64\-bit hvm guest: .Ve .SH "AUTHOR" .IX Header "AUTHOR" -Written by Joey Boggs +Written by Joey Boggs and John Levon .PP See the \s-1AUTHORS\s0 file in the source distribution for the complete list of credits. .SH "BUGS" diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -59,6 +59,11 @@ Output format. Currently, the only suppo Output format. Currently, the only supported outputs are C and C. +=item -D format + +Output disk format, or C if no conversion should be performed. See +L. + =item -d, --debug Print debugging information @@ -81,7 +86,7 @@ Convert a 64-bit hvm guest: =head1 AUTHOR -Written by Joey Boggs +Written by Joey Boggs and John Levon See the AUTHORS file in the source distribution for the complete list of credits. diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -30,7 +30,6 @@ # support CD-ROM # add option for host selection # --uuid, --os-type, --os-variant, and other virt-install options -# disk conversion should be optional # use qemu-img info to verify the disk type # add some unit tests # input/output/detection for all formats @@ -41,6 +40,7 @@ import os import os import logging import errno +import platform from optparse import OptionParser import virtinst.cli as cli @@ -67,6 +67,8 @@ def parse_args(): opts.add_option("-o", "--output-format", action="store", dest="output_format", default="virt-image", help=("Output format, e.g. 'virt-image'")) + opts.add_option("-D", "--disk-format", action="store", + dest="disk_format", help=("Output disk format")) opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", help=("This guest should be a fully virtualized guest")) opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", @@ -78,6 +80,10 @@ def parse_args(): if len(args) > 2: opts.error(("Too many arguments provided")) + if (options.disk_format and + options.disk_format not in vmconfig.disk_formats()): + opts.error("Unknown output disk format \"%s\"" % options.disk_format) + if len(args) == 1: options.output_file = None options.output_dir = None @@ -210,11 +216,23 @@ def main(): (options.output_format, options.output_dir)) try: - for d in vmdef.disks: + for d in vmdef.disks.values(): + format = options.disk_format + + if format == "none": + continue + + # no auto-conversion on Solaris for VMDK disks + if (d.format == vmconfig.DISK_FORMAT_VMDK and + not format and platform.system() == "SunOS"): + continue + + if not format: + format = "raw" verbose(options, "Converting disk \"%s\" to type %s..." % - (d.path, vmconfig.qemu_formats[vmconfig.DISK_FORMAT_RAW])) - d.convert(options.input_dir, options.output_dir, - vmconfig.DISK_FORMAT_RAW) + (d.path, format)) + + d.convert(options.input_dir, options.output_dir, format) except OSError, e: cleanup("Couldn't convert disks: %s" % e.strerror, options, created_dir) except RuntimeError, e: diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -30,8 +30,9 @@ NETDEV_TYPE_BRIDGE = 2 NETDEV_TYPE_BRIDGE = 2 NETDEV_TYPE_NETWORK = 3 -DISK_FORMAT_RAW = 0 -DISK_FORMAT_VMDK = 1 +DISK_FORMAT_NONE = 0 +DISK_FORMAT_RAW = 1 +DISK_FORMAT_VMDK = 2 DISK_TYPE_DISK = 0 DISK_TYPE_CDROM = 1 @@ -45,6 +46,12 @@ qemu_formats = { qemu_formats = { DISK_FORMAT_RAW: "raw", DISK_FORMAT_VMDK: "vmdk", +} + +disk_format_names = { + "none": DISK_FORMAT_NONE, + "raw": DISK_FORMAT_RAW, + "vmdk": DISK_FORMAT_VMDK, } class disk(object): @@ -64,14 +71,16 @@ class disk(object): failures. """ - if self.format == output_format: + out_format = disk_format_names[output_format] + + if self.format == out_format or out_format == DISK_FORMAT_NONE: return if self.type != DISK_TYPE_DISK: return - if output_format != DISK_FORMAT_RAW: - raise NotImplementedError("Cannot convert to disk format %d" % + if out_format != DISK_FORMAT_RAW: + raise NotImplementedError("Cannot convert to disk format %s" % output_format) infile = self.path @@ -85,10 +94,10 @@ class disk(object): outfile = os.path.basename(outfile) outfile = outfile.replace(disk_suffixes[self.format], - disk_suffixes[output_format]).strip() + disk_suffixes[out_format]).strip() convert_cmd = ("qemu-img convert \"%s\" -O %s \"%s\"" % - (infile, qemu_formats[output_format], + (infile, qemu_formats[out_format], os.path.join(output_dir, outfile))) ret = os.system(convert_cmd) @@ -97,7 +106,7 @@ class disk(object): # Note: this is the *relative* path still self.path = outfile - self.format = output_format + self.format = out_format class netdev(object): """Definition of an individual network device.""" @@ -247,6 +256,12 @@ def output_formats(): """ return [p.name for p in _parsers if p.can_export] +def disk_formats(): + """ + Return a list of supported disk formats. + """ + return disk_format_names.keys() + def find_input(path, format = None): """ Search for a configuration file automatically. If @format is given, From john.levon at sun.com Mon Jul 7 22:51:32 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:32 -0700 Subject: [et-mgmt-tools] [PATCH 02 of 11] Cleanup on failure In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215470371 25200 # Node ID f0ddebbf39a3926f55045ade4fbf850706ed6c3e # Parent c75d57437b7b219443580f6e9d6736d27d76ebcf Cleanup on failure If we can't convert the disks or export the file, perform some cleanup. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -31,6 +31,7 @@ import virtconv.vmconfig as vmconfig import virtconv.vmconfig as vmconfig def parse_args(): + """Parse and verify command line.""" opts = OptionParser() opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") @@ -93,6 +94,36 @@ def parse_args(): return options +def rmrf(path): + """Remove a directory and all its contents.""" + + assert path is not None + + for dirpath, _, files in os.walk(path): + for filename in files: + os.remove(os.path.join(dirpath, filename)) + for dirpath, subdirs, _ in os.walk(path, topdown=False): + for dirname in subdirs: + os.rmdir(os.path.join(dirpath, dirname)) + os.rmdir(path) + +def cleanup(msg, options, created_dir): + """ + After failure, clean up anything we created. Take a conservative + approach: only if we created the output directory do we delete + anything. + """ + logging.error(msg) + + if created_dir: + try: + rmrf(options.output_dir) + except OSError, e: + logging.error("Couldn't clean up output directory \"%s\": %s" % + (options.output_dir, e.strerror)) + + sys.exit(1) + def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) @@ -131,12 +162,15 @@ def main(): vmdef.arch = options.arch + created_dir = False unixname = vmdef.name.replace(" ", "-") + if not options.output_dir: options.output_dir = unixname try: logging.debug("Creating directory %s" % options.output_dir) os.mkdir(options.output_dir) + created_dir = True except OSError, e: if (e.errno != errno.EEXIST): logging.error("Could not create directory %s: %s" % @@ -156,19 +190,19 @@ def main(): for d in vmdef.disks: d.convert(options.input_dir, options.output_dir, vmconfig.DISK_TYPE_RAW) - except Exception, e: - logging.error(e) - sys.exit(1) + except OSError, e: + cleanup("Couldn't convert disks: %s" % e.strerror, options, created_dir) + except RuntimeError, e: + cleanup("Couldn't convert disks: %s" % e.message, options, created_dir) try: outp.export_file(vmdef, options.output_file) - except Exception, e: - logging.error(e) - sys.exit(1) + except ValueError, e: + cleanup("Couldn't export to file \"%s\": %s" % + (options.output_file, e.message), options, created_dir) print "\n\nConversion completed and placed in: %s" % options.output_dir - if __name__ == "__main__": try: main() diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -77,7 +77,9 @@ class disk(object): (infile, qemu_formats[output_type], os.path.join(output_dir, outfile))) - os.system(convert_cmd) + ret = os.system(convert_cmd) + if ret != 0: + raise RuntimeError("qemu-img failed with exit status %d" % ret) # Note: this is the *relative* path still self.path = outfile From john.levon at sun.com Mon Jul 7 22:51:33 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:33 -0700 Subject: [et-mgmt-tools] [PATCH 03 of 11] Make --arch optional In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215470376 25200 # Node ID fa3aae2098440bb154e4b699c1a352fe6a4f110b # Parent f0ddebbf39a3926f55045ade4fbf850706ed6c3e Make --arch optional. Default to the current system arch. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -129,7 +129,7 @@ .\" ======================================================================== .\" .IX Title "VIRT-CONVERT 1" -.TH VIRT-CONVERT 1 "2008-07-01" "perl v5.8.8" "Virtual Machine Install Tools" +.TH VIRT-CONVERT 1 "2008-07-04" "perl v5.8.8" "Virtual Machine Install Tools" .SH "NAME" virt\-convert \- convert virtual machines between formats .SH "SYNOPSIS" @@ -161,7 +161,8 @@ Show the help message and exit Show the help message and exit .IP "\-a \s-1ARCH\s0, \-\-arch=ARCH" 4 .IX Item "-a ARCH, --arch=ARCH" -Architecture of the virtual machine (i686, x86_64, ppc) +Architecture of the virtual machine (i686, x86_64, ppc). Defaults to +that of the host machine. .IP "\-v, \-\-hvm Create a fully virtualized guest image" 4 .IX Item "-v, --hvm Create a fully virtualized guest image" Convert machine to a hvm/qemu based image (this is the default if paravirt is not specified) diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -39,7 +39,8 @@ Show the help message and exit =item -a ARCH, --arch=ARCH -Architecture of the virtual machine (i686, x86_64, ppc) +Architecture of the virtual machine (i686, x86_64, ppc). Defaults to +that of the host machine. =item -v, --hvm Create a fully virtualized guest image diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -27,6 +27,7 @@ from optparse import OptionParser from optparse import OptionParser import virtinst.cli as cli +import virtinst.util as util import virtconv import virtconv.vmconfig as vmconfig @@ -36,6 +37,7 @@ def parse_args(): opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") opts.add_option("-a", "--arch", type="string", dest="arch", + default=util.get_default_arch(), help=("Machine Architecture Type (i686/x86_64/ppc)")) opts.add_option("-t", "--type", type="string", dest="type", help=("Output virtualization type (hvm, paravirt")) @@ -58,10 +60,6 @@ def parse_args(): if len(args) > 2: opts.error(("Too many arguments provided")) - if (options.arch is None): - opts.error(("Missing option value \n\nArchitecture: " + - str(options.arch))) - # hard-code for now if options.inputformat != "vmx": opts.error(("Unsupported input format \"%s\"" % options.inputformat)) From john.levon at sun.com Mon Jul 7 22:51:35 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:35 -0700 Subject: [et-mgmt-tools] [PATCH 05 of 11] Allow output in libvirt.rng format In-Reply-To: Message-ID: <4528daf7a40728f906e1.1215471095@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1215470429 25200 # Node ID 4528daf7a40728f906e1843b8368198ce9d438c5 # Parent 6042ba3dce6a57dbe7ee547ae65be93dbef1b0a2 Allow output in libvirt.rng format Add "virt-instance" formatter. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -174,7 +174,8 @@ Input format. Currently, \f(CW\*(C`vmx\* Input format. Currently, \f(CW\*(C`vmx\*(C'\fR is the only supported input format. .IP "\-o format" 4 .IX Item "-o format" -Output format. Currently, \f(CW\*(C`virt\-image\*(C'\fR is the only supported output format. +Output format. Currently, the only supported outputs are \f(CW\*(C`virt\-image\*(C'\fR +and \f(CW\*(C`virt\-instance\*(C'\fR. .IP "\-d, \-\-debug" 4 .IX Item "-d, --debug" Print debugging information diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -56,7 +56,8 @@ Input format. Currently, C is the =item -o format -Output format. Currently, C is the only supported output format. +Output format. Currently, the only supported outputs are C +and C. =item -d, --debug diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -1,9 +1,10 @@ #!/usr/bin/python -# -# Convert a VMware(tm) virtual machine into an XML image description # # Copyright 2008 Red Hat, Inc. # Joey Boggs +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -19,6 +20,21 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA. + +# +# Convert between VM definition formats. TODO: +# +# support networking +# port virtinstance.py to Solaris +# better disk checking +# support CD-ROM +# add option for host selection +# --uuid, --os-type, --os-variant, and other virt-install options +# disk conversion should be optional +# use qemu-img info to verify the disk type +# add some unit tests +# input/output/detection for all formats +# import sys import os @@ -62,12 +78,18 @@ def parse_args(): if len(args) > 2: opts.error(("Too many arguments provided")) - # hard-code for now - if options.input_format != "vmx": - opts.error(("Unsupported input format \"%s\"" % options.input_format)) - if options.output_format != "virt-image": - opts.error(("Unsupported output format \"%s\"" + if options.input_format not in vmconfig.formats(): + opts.error(("Unknown input format \"%s\"" % options.input_format)) + if options.input_format not in vmconfig.input_formats(): + opts.error(("No input handler for format \"%s\"" + % options.input_format)) + + if options.output_format not in vmconfig.formats(): + opts.error(("Unknown output format \"%s\"" % options.output_format)) + if options.output_format not in vmconfig.output_formats(): + opts.error(("No output handler for format \"%s\"" % options.output_format)) + if os.path.isdir(args[0]): vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] if (len(vmx_files)) == 0: diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -76,6 +76,8 @@ class virtimage_parser(vmconfig.parser): """ name = "virt-image" suffix = ".virt-image.xml" + can_import = False + can_export = True @staticmethod def identify_file(input_file): diff --git a/virtconv/parsers/virtinstance.py b/virtconv/parsers/virtinstance.py new file mode 100644 --- /dev/null +++ b/virtconv/parsers/virtinstance.py @@ -0,0 +1,174 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +from string import ascii_letters +import virtconv.vmconfig as vmconfig + +import re + +bootloaders = { + vmconfig.VM_TYPE_PV: "/usr/lib/xen/bin/pygrub", + vmconfig.VM_TYPE_HVM: "", +} + +bootdevs = { + vmconfig.VM_TYPE_PV: "", + vmconfig.VM_TYPE_HVM: "", +} + +loaders = { + vmconfig.VM_TYPE_PV: "", + vmconfig.VM_TYPE_HVM: "/usr/lib/xen/boot/hvmloader", +} + +emulators = { + vmconfig.VM_TYPE_PV: "", + vmconfig.VM_TYPE_HVM: "/usr/lib/xen/bin/qemu-dm", +} + +consoles = { + vmconfig.VM_TYPE_PV: "", + vmconfig.VM_TYPE_HVM: "", +} + +disk_template = """ + + + + + +""" + +instance_template = """ + + %(name)s + %(bootloader)s + + %(type)s + %(loader)s + %(bootdev)s + + %(memory)s + %(nr_vcpus)s + destroy + restart + restart + + + + + + %(emulator)s + %(disks)s + + + + %(console)s + + +""" + +class virtinstance_parser(vmconfig.parser): + """ + Support for libvirt's domain instance format as defined (mostly) by + libvirt.rng. Currently, this only produces domains for Xen. + + This is a somewhat challenging format as it encodes significant + amounts of information specific to a particular platform (for + example, the pygrub path. For now, we'll assume it's for the current + platform. In the future we might want to consider adding a + --host-type option. + """ + + name = "virt-instance" + suffix = ".virt-instance.xml" + can_import = False + can_export = True + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + raise NotImplementedError + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + + if not vm.memory: + raise ValueError("VM must have a memory setting") + + # xend wants the name to match r'^[A-Za-z0-9_\-\.\:\/\+]+$' + vmname = re.sub(r'[^A-Za-z0-9_.:/+-]+', '_', vm.name) + + vmtype = "xen" + disk_prefix = "xvd" + if (vm.type == vmconfig.VM_TYPE_HVM): + vmtype = "hvm" + disk_prefix = "hd" + + disks = [] + + for disk in vm.disks: + drive_nr = ascii_letters[disk.number % 26] + + # FIXME: needs updating for later Xen enhancements; need to + # implement capabilities checking for max disks etc. + disks.append(disk_template % { + "path" : disk.path, + "prefix" : disk_prefix, + "dev" : drive_nr + }) + + out = instance_template % { + "name" : vmname.replace(" ", "-"), + "bootloader" : bootloaders[vm.type], + "type" : vmtype, + "loader" : loaders[vm.type], + "bootdev" : bootdevs[vm.type], + # Mb to Kb + "memory" : int(vm.memory) * 1024, + "nr_vcpus" : vm.nr_vcpus, + "emulator" : emulators[vm.type], + "disks" : "".join(disks), + "console" : consoles[vm.type], + } + + outfile = open(output_file, "w") + outfile.writelines(out) + outfile.close() + +vmconfig.register_parser(virtinstance_parser) diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -29,6 +29,8 @@ class vmx_parser(vmconfig.parser): name = "vmx" suffix = ".vmx" + can_import = True + can_export = False @staticmethod def identify_file(input_file): diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -193,3 +193,21 @@ def find_parser_by_file(input_file): if p.identify_file(input_file): return p return None + +def formats(): + """ + Return a list of supported formats. + """ + return [p.name for p in _parsers] + +def input_formats(): + """ + Return a list of supported input formats. + """ + return [p.name for p in _parsers if p.can_import] + +def output_formats(): + """ + Return a list of supported output formats. + """ + return [p.name for p in _parsers if p.can_export] From john.levon at sun.com Mon Jul 7 22:51:30 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:30 -0700 Subject: [et-mgmt-tools] [PATCH 00 of 11] virt-convert updates Message-ID: The following patches as a series implements significantly more handling of VM config files and fixes a number of issues. In addition, it implements "virt-instance" output for directly generating libvirt.rng-style definitions. From john.levon at sun.com Mon Jul 7 22:51:34 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:34 -0700 Subject: [et-mgmt-tools] [PATCH 04 of 11] Improve virt-convert output In-Reply-To: Message-ID: <6042ba3dce6a57dbe7ee.1215471094@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1215470381 25200 # Node ID 6042ba3dce6a57dbe7ee547ae65be93dbef1b0a2 # Parent fa3aae2098440bb154e4b699c1a352fe6a4f110b Improve virt-convert output Print some details before long operations such as disk convert, and add a --quiet flag to allow skipping them. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -178,6 +178,9 @@ Output format. Currently, \f(CW\*(C`virt .IP "\-d, \-\-debug" 4 .IX Item "-d, --debug" Print debugging information +.IP "\-q, \-\-quiet" 4 +.IX Item "-q, --quiet" +Avoid verbose output. .SH "EXAMPLES" .IX Header "EXAMPLES" Convert a paravirt guest from \f(CW\*(C`image.vmx\*(C'\fR: diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -62,6 +62,10 @@ Output format. Currently, C Print debugging information +=item -q, --quiet + +Avoid verbose output. + =back =head1 EXAMPLES diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -36,6 +36,8 @@ def parse_args(): opts = OptionParser() opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") + opts.add_option("-q", "--quiet", action="store_true", dest="quiet", + help=("Don't be verbose")) opts.add_option("-a", "--arch", type="string", dest="arch", default=util.get_default_arch(), help=("Machine Architecture Type (i686/x86_64/ppc)")) @@ -44,10 +46,10 @@ def parse_args(): opts.add_option("-d", "--debug", action="store_true", dest="debug", help=("Print debugging information")) opts.add_option("-i", "--input-format", action="store", - dest="inputformat", default="vmx", + dest="input_format", default="vmx", help=("Input format, e.g. 'vmx'")) opts.add_option("-o", "--output-format", action="store", - dest="outputformat", default="virt-image", + dest="output_format", default="virt-image", help=("Output format, e.g. 'virt-image'")) opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", help=("This guest should be a fully virtualized guest")) @@ -61,11 +63,11 @@ def parse_args(): opts.error(("Too many arguments provided")) # hard-code for now - if options.inputformat != "vmx": - opts.error(("Unsupported input format \"%s\"" % options.inputformat)) - if options.outputformat != "virt-image": + if options.input_format != "vmx": + opts.error(("Unsupported input format \"%s\"" % options.input_format)) + if options.output_format != "virt-image": opts.error(("Unsupported output format \"%s\"" - % options.outputformat)) + % options.output_format)) if os.path.isdir(args[0]): vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] if (len(vmx_files)) == 0: @@ -92,6 +94,11 @@ def parse_args(): return options +def verbose(options, msg): + """Output a message if --quiet is not set.""" + if not options.quiet: + print msg + def rmrf(path): """Remove a directory and all its contents.""" @@ -127,17 +134,17 @@ def main(): cli.setupLogging("virt-convert", options.debug) try: - inp = virtconv.vmconfig.find_parser_by_name(options.inputformat) + inp = virtconv.vmconfig.find_parser_by_name(options.input_format) except: logging.error("No parser of format \"%s\" was found." % - options.inputformat) + options.input_format) sys.exit(1) try: - outp = virtconv.vmconfig.find_parser_by_name(options.outputformat) + outp = virtconv.vmconfig.find_parser_by_name(options.output_format) except: logging.error("No parser of format \"%s\" was found." % - options.outputformat) + options.output_format) sys.exit(1) vmdef = None @@ -184,8 +191,13 @@ def main(): logging.debug("output_file: %s" % options.output_file) logging.debug("output_dir: %s" % options.input_dir) + verbose(options, "Generating output in \"%s\" format to %s/" % + (options.output_format, options.output_dir)) + try: for d in vmdef.disks: + verbose(options, "Converting disk \"%s\" to type %s..." % + (d.path, vmconfig.qemu_formats[vmconfig.DISK_TYPE_RAW])) d.convert(options.input_dir, options.output_dir, vmconfig.DISK_TYPE_RAW) except OSError, e: @@ -199,7 +211,7 @@ def main(): cleanup("Couldn't export to file \"%s\": %s" % (options.output_file, e.message), options, created_dir) - print "\n\nConversion completed and placed in: %s" % options.output_dir + verbose(options, "Done.") if __name__ == "__main__": try: From john.levon at sun.com Mon Jul 7 22:51:36 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Mon, 07 Jul 2008 15:51:36 -0700 Subject: [et-mgmt-tools] [PATCH 06 of 11] Format detection for .vmx In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215470433 25200 # Node ID a8f5d5be978f0237f41c35275936863c2787a73b # Parent 4528daf7a40728f906e1843b8368198ce9d438c5 Format detection for .vmx Auto-detect vmx format. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -34,6 +34,7 @@ # use qemu-img info to verify the disk type # add some unit tests # input/output/detection for all formats +# add --formats? # import sys @@ -62,8 +63,7 @@ def parse_args(): opts.add_option("-d", "--debug", action="store_true", dest="debug", help=("Print debugging information")) opts.add_option("-i", "--input-format", action="store", - dest="input_format", default="vmx", - help=("Input format, e.g. 'vmx'")) + dest="input_format", help=("Input format, e.g. 'vmx'")) opts.add_option("-o", "--output-format", action="store", dest="output_format", default="virt-image", help=("Output format, e.g. 'virt-image'")) @@ -78,41 +78,45 @@ def parse_args(): if len(args) > 2: opts.error(("Too many arguments provided")) + if len(args) == 1: + options.output_file = None + options.output_dir = None + if os.path.isdir(args[0]): + options.output_dir = args[0] + elif os.path.isdir(args[1]) or args[1].endswith("/"): + options.output_file = None + options.output_dir = args[1] + else: + options.output_file = args[1] + options.output_dir = os.path.dirname(os.path.realpath(args[1])) + + if options.output_format not in vmconfig.formats(): + opts.error(("Unknown output format \"%s\"" % options.output_format)) + if options.output_format not in vmconfig.output_formats(): + opts.error(("No output handler for format \"%s\"" + % options.output_format)) + + if not options.input_format: + try: + (args[0], options.input_format) = vmconfig.find_input(args[0]) + except StandardError, e: + opts.error("Couldn't determine input format for \"%s\": %s" % + (args[0], e.message)) + sys.exit(1) + if options.input_format not in vmconfig.formats(): opts.error(("Unknown input format \"%s\"" % options.input_format)) if options.input_format not in vmconfig.input_formats(): opts.error(("No input handler for format \"%s\"" % options.input_format)) - if options.output_format not in vmconfig.formats(): - opts.error(("Unknown output format \"%s\"" % options.output_format)) - if options.output_format not in vmconfig.output_formats(): - opts.error(("No output handler for format \"%s\"" - % options.output_format)) - if os.path.isdir(args[0]): - vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] - if (len(vmx_files)) == 0: - opts.error(("No VM definition file was found in %s" % args[0])) - if (len(vmx_files)) > 1: - opts.error(("Too many .vmx definitions found in %s" % args[0])) - options.input_file = os.path.join(args[0], vmx_files[0]) + (options.input_file, _) = vmconfig.find_input(args[0], + options.input_format) options.input_dir = args[0] else: options.input_file = args[0] options.input_dir = os.path.dirname(os.path.realpath(args[0])) - - if len(args) == 1: - options.output_file = None - options.output_dir = None - if os.path.isdir(args[0]): - options.output_dir = options.input_dir - elif os.path.isdir(args[1]) or args[1].endswith("/"): - options.output_file = None - options.output_dir = args[1] - else: - options.output_file = args[1] - options.output_dir = os.path.dirname(os.path.realpath(args[1])) return options @@ -155,19 +159,8 @@ def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) - try: - inp = virtconv.vmconfig.find_parser_by_name(options.input_format) - except: - logging.error("No parser of format \"%s\" was found." % - options.input_format) - sys.exit(1) - - try: - outp = virtconv.vmconfig.find_parser_by_name(options.output_format) - except: - logging.error("No parser of format \"%s\" was found." % - options.output_format) - sys.exit(1) + inp = vmconfig.parser_by_name(options.input_format) + outp = vmconfig.parser_by_name(options.output_format) vmdef = None diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -78,6 +78,7 @@ class virtimage_parser(vmconfig.parser): suffix = ".virt-image.xml" can_import = False can_export = True + can_identify = False @staticmethod def identify_file(input_file): diff --git a/virtconv/parsers/virtinstance.py b/virtconv/parsers/virtinstance.py --- a/virtconv/parsers/virtinstance.py +++ b/virtconv/parsers/virtinstance.py @@ -101,6 +101,7 @@ class virtinstance_parser(vmconfig.parse suffix = ".virt-instance.xml" can_import = False can_export = True + can_identify = False @staticmethod def identify_file(input_file): diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -19,6 +19,7 @@ # import virtconv.vmconfig as vmconfig +import re class vmx_parser(vmconfig.parser): """ @@ -31,13 +32,21 @@ class vmx_parser(vmconfig.parser): suffix = ".vmx" can_import = True can_export = False + can_identify = True @staticmethod def identify_file(input_file): """ Return True if the given file is of this format. """ - raise NotImplementedError + infile = open(input_file, "r") + line = infile.readline() + infile.close() + + # some .vmx files don't bother with the header + if re.match(r'^config.version\s+=', line): + return True + return re.match(r'^#!\s*/usr/bin/vm(ware|player)', line) is not None @staticmethod def import_file(input_file): diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -179,11 +179,13 @@ def register_parser(parser): global _parsers _parsers += [ parser ] -def find_parser_by_name(name): - """ - Return the parser of the given name - """ - return [p for p in _parsers if p.name == name][0] or None +def parser_by_name(name): + """ + Return the parser of the given name. + """ + parsers = [p for p in _parsers if p.name == name] + if len(parsers): + return parsers[0] def find_parser_by_file(input_file): """ @@ -211,3 +213,28 @@ def output_formats(): Return a list of supported output formats. """ return [p.name for p in _parsers if p.can_export] + +def find_input(path, format = None): + """ + Search for a configuration file automatically. If @format is given, + then only search using a matching format parser. + """ + + if os.path.isdir(path): + files = os.listdir(path) + + for p in _parsers: + if not p.can_identify: + continue + if format and format != p.name: + continue + + if os.path.isfile(path): + if p.identify_file(path): + return (path, p.name) + elif os.path.isdir(path): + for cfgfile in [ x for x in files if x.endswith(p.suffix) ]: + if p.identify_file(os.path.join(path, cfgfile)): + return (os.path.join(path, cfgfile), p.name) + + raise StandardError("unknown format") From levon at movementarian.org Tue Jul 8 00:36:54 2008 From: levon at movementarian.org (John Levon) Date: Tue, 8 Jul 2008 01:36:54 +0100 Subject: [et-mgmt-tools] [PATCH 11 of 11] Add --host option In-Reply-To: References: Message-ID: <20080708003654.GA7664@totally.trollied.org.uk> On Mon, Jul 07, 2008 at 03:51:41PM -0700, john.levon at sun.com wrote: > Add --host option I didn't quite mean to send this patch yet, but here's a version that actually works below thanks john Add --host option Some formats need unpleasant knowledge of what hypervisor they're going to run on. We default to the current machine, but add a --host option to allow people to choose (and so we can write tests). Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -129,7 +129,7 @@ .\" ======================================================================== .\" .IX Title "VIRT-CONVERT 1" -.TH VIRT-CONVERT 1 "2008-07-04" "perl v5.8.8" "Virtual Machine Install Tools" +.TH VIRT-CONVERT 1 "2008-07-07" "perl v5.8.8" "Virtual Machine Install Tools" .SH "NAME" virt\-convert \- convert virtual machines between formats .SH "SYNOPSIS" @@ -159,6 +159,11 @@ .IP "\-h, \-\-help" 4 .IX Item "-h, --help" Show the help message and exit +.IP "\-H \s-1HOST\s0, \-\-host=HOST" 4 +.IX Item "-H HOST, --host=HOST" +Hypervisor target host. This is needed for some output formats such as +\&\f(CW\*(C`virt\-instance\*(C'\fR, and it will default to the current host. Current +accepted values are 'xvm' (for Solaris xVM), or 'xen' (for Xen). .IP "\-a \s-1ARCH\s0, \-\-arch=ARCH" 4 .IX Item "-a ARCH, --arch=ARCH" Architecture of the virtual machine (i686, x86_64, ppc). Defaults to diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -36,6 +36,12 @@ =item -h, --help Show the help message and exit + +=item -H HOST, --host=HOST + +Hypervisor target host. This is needed for some output formats such as +C, and it will default to the current host. Current +accepted values are 'xvm' (for Solaris xVM), or 'xen' (for Xen). =item -a ARCH, --arch=ARCH diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -83,6 +83,8 @@ help=("Disables APIC for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) opts.add_option("", "--noacpi", action="store_true", dest="noacpi", help=("Disables ACPI for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) + opts.add_option("-H", "--host", type="string", dest="host", action="store", + default=vmconfig.default_host(), help=("Host hypervisor type, e.g. 'xen'")) (options, args) = opts.parse_args() if len(args) < 1: @@ -196,6 +198,7 @@ else: vmdef.type = vmconfig.VM_TYPE_HVM + vmdef.host = options.host vmdef.arch = options.arch vmdef.os_type = options.os_type vmdef.os_variant = options.os_variant diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmconfig.py @@ -18,7 +18,10 @@ # MA 02110-1301 USA. # +import platform import os + +from virtinst import util _parsers = [ ] @@ -286,3 +289,13 @@ return (os.path.join(path, cfgfile), p.name) raise StandardError("unknown format") + +def default_host(): + """ + Return the default host hypervisor, or 'None' if none seems present. + """ + if platform.system() == "SunOS": + return "xvm" + + # FIXME: should we massage this value? + return util.default_connection() From berrange at redhat.com Tue Jul 8 12:14:46 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:14:46 +0100 Subject: [et-mgmt-tools] [PATCH 01 of 11] Fix multiple disks In-Reply-To: References: Message-ID: <20080708121446.GJ24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:31PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470367 25200 > # Node ID c75d57437b7b219443580f6e9d6736d27d76ebcf > # Parent a2be1263c2f5d3f346cfc3501682073fce2e8966 > Fix multiple disks > > Fix handling of multiple disks. > > Signed-off-by: John Levon > > diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py > --- a/virtconv/parsers/virtimage.py > +++ b/virtconv/parsers/virtimage.py > @@ -117,12 +117,12 @@ class virtimage_parser(vmconfig.parser): > > # FIXME: needs updating for later Xen enhancements; need to > # implement capabilities checking for max disks etc. > - pv_disks.append("""""" % > + pv_disks.append("""\n""" % > (path, ascii_letters[number % 26])) > - hvm_disks.append("""""" % > + hvm_disks.append("""\n""" % > (path, ascii_letters[number % 26])) IDE only allows upto 4 disks. To allow more than this requires use of SCSI or VirtIO/Xen paravirt drivers. I'd probably say default to IDE for first 4, and then switch to sdNNN for any subsequent disks. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 8 12:15:14 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:15:14 +0100 Subject: [et-mgmt-tools] [PATCH 02 of 11] Cleanup on failure In-Reply-To: References: Message-ID: <20080708121514.GK24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:32PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470371 25200 > # Node ID f0ddebbf39a3926f55045ade4fbf850706ed6c3e > # Parent c75d57437b7b219443580f6e9d6736d27d76ebcf > Cleanup on failure > > If we can't convert the disks or export the file, perform some cleanup. ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 8 12:16:46 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:16:46 +0100 Subject: [et-mgmt-tools] [PATCH 03 of 11] Make --arch optional In-Reply-To: References: Message-ID: <20080708121646.GL24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:33PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470376 25200 > # Node ID fa3aae2098440bb154e4b699c1a352fe6a4f110b > # Parent f0ddebbf39a3926f55045ade4fbf850706ed6c3e > Make --arch optional. > > Default to the current system arch. > > Signed-off-by: John Levon ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 8 12:18:03 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:18:03 +0100 Subject: [et-mgmt-tools] [PATCH 04 of 11] Improve virt-convert output In-Reply-To: <6042ba3dce6a57dbe7ee.1215471094@xenbld> References: <6042ba3dce6a57dbe7ee.1215471094@xenbld> Message-ID: <20080708121803.GM24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:34PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470381 25200 > # Node ID 6042ba3dce6a57dbe7ee547ae65be93dbef1b0a2 > # Parent fa3aae2098440bb154e4b699c1a352fe6a4f110b > Improve virt-convert output > > Print some details before long operations such as disk convert, and add > a --quiet flag to allow skipping them. > > Signed-off-by: John Levon Good idea, we should add a --quiet flag to other tools in the future sometime too, to avoid the verbose progress bars during downloads,etc Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Tue Jul 8 12:20:57 2008 From: levon at movementarian.org (John Levon) Date: Tue, 8 Jul 2008 13:20:57 +0100 Subject: [et-mgmt-tools] [PATCH 01 of 11] Fix multiple disks In-Reply-To: <20080708121446.GJ24934@redhat.com> References: <20080708121446.GJ24934@redhat.com> Message-ID: <20080708122057.GC466@totally.trollied.org.uk> On Tue, Jul 08, 2008 at 01:14:46PM +0100, Daniel P. Berrange wrote: > > Signed-off-by: John Levon > > > > diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py > > --- a/virtconv/parsers/virtimage.py > > +++ b/virtconv/parsers/virtimage.py > > @@ -117,12 +117,12 @@ class virtimage_parser(vmconfig.parser): > > > > # FIXME: needs updating for later Xen enhancements; need to > > # implement capabilities checking for max disks etc. > > - pv_disks.append("""""" % > > + pv_disks.append("""\n""" % > > (path, ascii_letters[number % 26])) > > - hvm_disks.append("""""" % > > + hvm_disks.append("""\n""" % > > (path, ascii_letters[number % 26])) > > IDE only allows upto 4 disks. To allow more than this requires use of > SCSI or VirtIO/Xen paravirt drivers. A later patch fixes this up somewhat, though this part is just a small fix to existing code. > I'd probably say default to IDE for first 4, and then switch to sdNNN > for any subsequent disks. Xen doesn't seem to be able to handle sd* meaningfully, at least. regards john From berrange at redhat.com Tue Jul 8 12:25:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:25:08 +0100 Subject: [et-mgmt-tools] [PATCH 05 of 11] Allow output in libvirt.rng format In-Reply-To: <4528daf7a40728f906e1.1215471095@xenbld> References: <4528daf7a40728f906e1.1215471095@xenbld> Message-ID: <20080708122507.GN24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:35PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470429 25200 > # Node ID 4528daf7a40728f906e1843b8368198ce9d438c5 > # Parent 6042ba3dce6a57dbe7ee547ae65be93dbef1b0a2 > Allow output in libvirt.rng format > > Add "virt-instance" formatter. > > Signed-off-by: John Levon This is overlapping quite alot with what virt-image does when it converts 'image' format XML into the libvirt XML, and its never going to give satisfactory results because virt-image is operating standalone without any libvirt connection. This means it is unable to get any hypervisor specific capabilities data to determine what the required OS / boot type options are. > +bootloaders = { > + vmconfig.VM_TYPE_PV: "/usr/lib/xen/bin/pygrub", > + vmconfig.VM_TYPE_HVM: "", > +} > + > +bootdevs = { > + vmconfig.VM_TYPE_PV: "", > + vmconfig.VM_TYPE_HVM: "", > +} > + > +loaders = { > + vmconfig.VM_TYPE_PV: "", > + vmconfig.VM_TYPE_HVM: "/usr/lib/xen/boot/hvmloader", > +} > + > +emulators = { > + vmconfig.VM_TYPE_PV: "", > + vmconfig.VM_TYPE_HVM: "/usr/lib/xen/bin/qemu-dm", > +} This kind of data all has to be taken from the capabilities XML for a specific hypervisor - there's no generic libvirt domain XML config you can generate which will work portably, which is why we have the separate virt-image XML format. So IMHO, virt-convert should only deal in the virt-image XML format, and if you want to immediately get a launchable config, then we should make it so that you can easily run virt-image with the output of virt-convert in some way. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 8 12:26:14 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:26:14 +0100 Subject: [et-mgmt-tools] [PATCH 06 of 11] Format detection for .vmx In-Reply-To: References: Message-ID: <20080708122613.GO24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:36PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470433 25200 > # Node ID a8f5d5be978f0237f41c35275936863c2787a73b > # Parent 4528daf7a40728f906e1843b8368198ce9d438c5 > Format detection for .vmx > > Auto-detect vmx format. > > Signed-off-by: John Levon ACK, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 8 12:26:47 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:26:47 +0100 Subject: [et-mgmt-tools] [PATCH 08 of 11] Allow specification of output disk format In-Reply-To: <9d9b282172f77f9d7703.1215471098@xenbld> References: <9d9b282172f77f9d7703.1215471098@xenbld> Message-ID: <20080708122647.GP24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:38PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470441 25200 > # Node ID 9d9b282172f77f9d77035017bb0bc8e219be18ba > # Parent 20daa7230dc53978e5f67fabf7950d961ed3bdd8 > Allow specification of output disk format > > In particular, allow the disk conversion to be skipped. > > Signed-off-by: John Levon ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 8 12:30:42 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 13:30:42 +0100 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: <26beabc283b11e40ed01.1215471099@xenbld> References: <26beabc283b11e40ed01.1215471099@xenbld> Message-ID: <20080708123042.GQ24934@redhat.com> On Mon, Jul 07, 2008 at 03:51:39PM -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470455 25200 > # Node ID 26beabc283b11e40ed01584be33678fd0840fed2 > # Parent 9d9b282172f77f9d77035017bb0bc8e219be18ba > Add OS variant options to virt-convert. > > And use them to set ACPI, APIC, clock, and USB tablet. Again, I don't think libvirt domain XML should be handled by this tool precisely because of the issues you're attempting to address here. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Tue Jul 8 12:49:41 2008 From: levon at movementarian.org (John Levon) Date: Tue, 8 Jul 2008 13:49:41 +0100 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: <20080708123042.GQ24934@redhat.com> References: <26beabc283b11e40ed01.1215471099@xenbld> <20080708123042.GQ24934@redhat.com> Message-ID: <20080708124941.GB2003@totally.trollied.org.uk> On Tue, Jul 08, 2008 at 01:30:42PM +0100, Daniel P. Berrange wrote: > > Add OS variant options to virt-convert. > > > > And use them to set ACPI, APIC, clock, and USB tablet. > > Again, I don't think libvirt domain XML should be handled by this tool > precisely because of the issues you're attempting to address here. What do you mean "again" ? libvirt is only part of the problem: it's not the only virt format with hypervisor specific settings. Even if you were to enforce the use of virt-image, you've still got the same problems if we ever want true mobility between other formats. Even worse, the image XML is very lossy. Whilst I imagine that virt-image will *typically* be used, enforcing an information-removing step doesn't make much sense to me. And finally, there is currently no way to generate image XML from a domain config (AFAIK). So we want this for libvirt import anyway. regards john From crobinso at redhat.com Tue Jul 8 14:44:42 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 08 Jul 2008 10:44:42 -0400 Subject: [et-mgmt-tools] [PATCH 02 of 11] Cleanup on failure In-Reply-To: References: Message-ID: <48737D5A.3020006@redhat.com> john.levon at sun.com wrote: Hi John, Comments inline: > # HG changeset patch > # User john.levon at sun.com > # Date 1215470371 25200 > # Node ID f0ddebbf39a3926f55045ade4fbf850706ed6c3e > # Parent c75d57437b7b219443580f6e9d6736d27d76ebcf > Cleanup on failure > > If we can't convert the disks or export the file, perform some cleanup. > > Signed-off-by: John Levon > > diff --git a/virt-convert b/virt-convert > --- a/virt-convert > +++ b/virt-convert > @@ -31,6 +31,7 @@ import virtconv.vmconfig as vmconfig > import virtconv.vmconfig as vmconfig > > def parse_args(): > + """Parse and verify command line.""" > opts = OptionParser() > opts.set_usage("%prog [options] inputdir|input.vmx " > "[outputdir|output.xml]") > @@ -93,6 +94,36 @@ def parse_args(): > > return options > > +def rmrf(path): > + """Remove a directory and all its contents.""" > + > + assert path is not None > + > + for dirpath, _, files in os.walk(path): You'll want to use a different variable other than '_' since this will overwrite the gettext function in the local scope. Doesn't cause issues in the current code, but could with future changes. > + for filename in files: > + os.remove(os.path.join(dirpath, filename)) > + for dirpath, subdirs, _ in os.walk(path, topdown=False): > + for dirname in subdirs: > + os.rmdir(os.path.join(dirpath, dirname)) > + os.rmdir(path) > + > +def cleanup(msg, options, created_dir): > + """ > + After failure, clean up anything we created. Take a conservative > + approach: only if we created the output directory do we delete > + anything. > + """ > + logging.error(msg) > + > + if created_dir: > + try: > + rmrf(options.output_dir) > + except OSError, e: > + logging.error("Couldn't clean up output directory \"%s\": %s" % > + (options.output_dir, e.strerror)) > + > + sys.exit(1) > + Hmm, did you see the comment I made in my response to this original patch? "Hmm, this scares the hell out of me, even with the created_dir check. If someone in the future ever messed up this code we could accidently start deleting someones homedir. I think a whitelist approach would be better: have convert_disks clean up its own files, and keep all other file/directory creation in the main() function (like it currently is) so it can handle the rest of the cleanup on a per file basis. At the end, if the output_dir is empty and we created it, we can delete it. Maybe it's overly paranoid, but better to be safe than sorry." Any comment on this? > def main(): > options = parse_args() > cli.setupLogging("virt-convert", options.debug) > @@ -131,12 +162,15 @@ def main(): > > vmdef.arch = options.arch > > + created_dir = False > unixname = vmdef.name.replace(" ", "-") > + > if not options.output_dir: > options.output_dir = unixname > try: > logging.debug("Creating directory %s" % options.output_dir) > os.mkdir(options.output_dir) > + created_dir = True > except OSError, e: > if (e.errno != errno.EEXIST): > logging.error("Could not create directory %s: %s" % > @@ -156,19 +190,19 @@ def main(): > for d in vmdef.disks: > d.convert(options.input_dir, options.output_dir, > vmconfig.DISK_TYPE_RAW) > - except Exception, e: > - logging.error(e) > - sys.exit(1) > + except OSError, e: > + cleanup("Couldn't convert disks: %s" % e.strerror, options, created_dir) > + except RuntimeError, e: > + cleanup("Couldn't convert disks: %s" % e.message, options, created_dir) > > try: > outp.export_file(vmdef, options.output_file) > - except Exception, e: > - logging.error(e) > - sys.exit(1) > + except ValueError, e: > + cleanup("Couldn't export to file \"%s\": %s" % > + (options.output_file, e.message), options, created_dir) > > print "\n\nConversion completed and placed in: %s" % options.output_dir > > - > if __name__ == "__main__": > try: > main() > diff --git a/virtconv/vmconfig.py b/virtconv/vmconfig.py > --- a/virtconv/vmconfig.py > +++ b/virtconv/vmconfig.py > @@ -77,7 +77,9 @@ class disk(object): > (infile, qemu_formats[output_type], > os.path.join(output_dir, outfile))) > > - os.system(convert_cmd) > + ret = os.system(convert_cmd) > + if ret != 0: > + raise RuntimeError("qemu-img failed with exit status %d" % ret) > > # Note: this is the *relative* path still > self.path = outfile > From john.levon at sun.com Tue Jul 8 14:59:57 2008 From: john.levon at sun.com (John Levon) Date: Tue, 8 Jul 2008 15:59:57 +0100 Subject: [et-mgmt-tools] [PATCH 02 of 11] Cleanup on failure In-Reply-To: <48737D5A.3020006@redhat.com> References: <48737D5A.3020006@redhat.com> Message-ID: <20080708145957.GA26859@barman.uk.sun.com> On Tue, Jul 08, 2008 at 10:44:42AM -0400, Cole Robinson wrote: > > + for dirpath, _, files in os.walk(path): > > You'll want to use a different variable other than '_' since this will > overwrite the gettext function in the local scope. Doesn't cause issues > in the current code, but could with future changes. Hmm, OK. _ is pretty standard for "don't care", what would you prefer? > > +def cleanup(msg, options, created_dir): > > + """ > > + After failure, clean up anything we created. Take a conservative > > + approach: only if we created the output directory do we delete > > + anything. > > + """ > > + logging.error(msg) > > + > > + if created_dir: > > + try: > > + rmrf(options.output_dir) > > + except OSError, e: > > + logging.error("Couldn't clean up output directory \"%s\": %s" % > > + (options.output_dir, e.strerror)) > > + > > + sys.exit(1) > > + > > Hmm, did you see the comment I made in my response to this original > patch? No, I don't think so. > I think a whitelist approach would be better: have convert_disks clean > up its own files, and keep all other file/directory creation in the > main() function (like it currently is) so it can handle the rest > of the cleanup on a per file basis. At the end, if the output_dir > is empty and we created it, we can delete it. Maybe it's overly > paranoid, but better to be safe than sorry." > > Any comment on this? Seems sensible, yes. regards, john From crobinso at redhat.com Tue Jul 8 15:02:01 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 08 Jul 2008 11:02:01 -0400 Subject: [et-mgmt-tools] [PATCH 02 of 11] Cleanup on failure In-Reply-To: <20080708145957.GA26859@barman.uk.sun.com> References: <48737D5A.3020006@redhat.com> <20080708145957.GA26859@barman.uk.sun.com> Message-ID: <48738169.2030207@redhat.com> John Levon wrote: > On Tue, Jul 08, 2008 at 10:44:42AM -0400, Cole Robinson wrote: > >>> + for dirpath, _, files in os.walk(path): >> You'll want to use a different variable other than '_' since this will >> overwrite the gettext function in the local scope. Doesn't cause issues >> in the current code, but could with future changes. > > Hmm, OK. _ is pretty standard for "don't care", what would you prefer? No preference: 'ignore', 'unused', anything reasonable and consistent. - Cole From dlutter at redhat.com Tue Jul 8 18:45:57 2008 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 08 Jul 2008 18:45:57 +0000 Subject: [et-mgmt-tools] [PATCH 05 of 11] Allow output in libvirt.rng format In-Reply-To: <20080708122507.GN24934@redhat.com> References: <4528daf7a40728f906e1.1215471095@xenbld> <20080708122507.GN24934@redhat.com> Message-ID: <1215542757.3368.210.camel@localhost.localdomain> On Tue, 2008-07-08 at 13:25 +0100, Daniel P. Berrange wrote: > On Mon, Jul 07, 2008 at 03:51:35PM -0700, john.levon at sun.com wrote: > > # HG changeset patch > > # User john.levon at sun.com > > # Date 1215470429 25200 > > # Node ID 4528daf7a40728f906e1843b8368198ce9d438c5 > > # Parent 6042ba3dce6a57dbe7ee547ae65be93dbef1b0a2 > > Allow output in libvirt.rng format > > > > Add "virt-instance" formatter. > > > > Signed-off-by: John Levon > > This is overlapping quite alot with what virt-image does when it > converts 'image' format XML into the libvirt XML, and its never > going to give satisfactory results because virt-image is operating I assume you mean 'virt-instance' - for virt-image I was very careful to only use information from capabilities XML, and avoid hardcoded data in the code because it would be too much of a maintenance burden. > standalone without any libvirt connection. This means it is unable > to get any hypervisor specific capabilities data to determine what > the required OS / boot type options are. The right approach then seems to use virt-convert to convert to image.xml and use virt-image to fill in the deployment specific bits, even if the user thinks they are just converting a VM from one format to another. David From levon at movementarian.org Tue Jul 8 18:51:11 2008 From: levon at movementarian.org (John Levon) Date: Tue, 8 Jul 2008 19:51:11 +0100 Subject: [et-mgmt-tools] [PATCH 05 of 11] Allow output in libvirt.rng format In-Reply-To: <1215542757.3368.210.camel@localhost.localdomain> References: <4528daf7a40728f906e1.1215471095@xenbld> <20080708122507.GN24934@redhat.com> <1215542757.3368.210.camel@localhost.localdomain> Message-ID: <20080708185111.GB18805@totally.trollied.org.uk> On Tue, Jul 08, 2008 at 06:45:57PM +0000, David Lutterkort wrote: > > standalone without any libvirt connection. This means it is unable > > to get any hypervisor specific capabilities data to determine what > > the required OS / boot type options are. > > The right approach then seems to use virt-convert to convert to > image.xml and use virt-image to fill in the deployment specific bits, > even if the user thinks they are just converting a VM from one format to > another. If you mean implementation-wise (i.e. virtinstance.py should just call out to virt-image), then I suppose that'd be OK, because you can use virt-convert cmdline options plus the parsed config to specify exactly what you need in virt-image. If you mean the *user* should do this, then see my other mail. regards john From berrange at redhat.com Tue Jul 8 20:32:49 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 21:32:49 +0100 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: <20080708124941.GB2003@totally.trollied.org.uk> References: <26beabc283b11e40ed01.1215471099@xenbld> <20080708123042.GQ24934@redhat.com> <20080708124941.GB2003@totally.trollied.org.uk> Message-ID: <20080708203249.GA28823@redhat.com> On Tue, Jul 08, 2008 at 01:49:41PM +0100, John Levon wrote: > On Tue, Jul 08, 2008 at 01:30:42PM +0100, Daniel P. Berrange wrote: > > > > Add OS variant options to virt-convert. > > > > > > And use them to set ACPI, APIC, clock, and USB tablet. > > > > Again, I don't think libvirt domain XML should be handled by this tool > > precisely because of the issues you're attempting to address here. > > What do you mean "again" ? > > libvirt is only part of the problem: it's not the only virt format with > hypervisor specific settings. Even if you were to enforce the use of > virt-image, you've still got the same problems if we ever want true > mobility between other formats. This isn't really solving the mobility problem though - its exchanging one problem (a VMWare specific config file) for another equally bad problem (a 32-bit Xen speciifc libvirt XML config). The virt-image or OVF formats are the only two I'm aware of that achieve any degree of mobility because they remove all instance specific metadata and focus on the core requirements of a VM. > Even worse, the image XML is very lossy. Whilst I imagine that > virt-image will *typically* be used, enforcing an information-removing > step doesn't make much sense to me. It is delibrately lossy in many areas. It explicitly excludes info that is fundamentally specific to a particular deployment of a VM. It fills this info in at time of instantiation based on the capabilities XML presented by the hypervisor being deployed onto. If we accept we want to use virt-convert to generate libvirt XML, then we need to require a hypervisor connection URI for this conversion so we can fetch the capabilities data and fill in the deployment specific bits. And the resulting libvirt XML generated will be specific to the machine it was generated on (or another with equivalent setup). > And finally, there is currently no way to generate image XML from a > domain config (AFAIK). So we want this for libvirt import anyway. Yes, we do need a way to go from libvirt XML to virt-image XML, but this is a far easier problem because we're not hardcoding hypervisor specific data, rather we''re removing it. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Tue Jul 8 20:55:57 2008 From: levon at movementarian.org (John Levon) Date: Tue, 8 Jul 2008 21:55:57 +0100 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: <20080708203249.GA28823@redhat.com> References: <26beabc283b11e40ed01.1215471099@xenbld> <20080708123042.GQ24934@redhat.com> <20080708124941.GB2003@totally.trollied.org.uk> <20080708203249.GA28823@redhat.com> Message-ID: <20080708205557.GA25569@totally.trollied.org.uk> On Tue, Jul 08, 2008 at 09:32:49PM +0100, Daniel P. Berrange wrote: > > > Again, I don't think libvirt domain XML should be handled by this tool > > > precisely because of the issues you're attempting to address here. > > > > What do you mean "again" ? > > > > libvirt is only part of the problem: it's not the only virt format with > > hypervisor specific settings. Even if you were to enforce the use of > > virt-image, you've still got the same problems if we ever want true > > mobility between other formats. > > This isn't really solving the mobility problem though - its exchanging > one problem (a VMWare specific config file) for another equally bad > problem (a 32-bit Xen speciifc libvirt XML config). The virt-image > or OVF formats are the only two I'm aware of that achieve any degree > of mobility because they remove all instance specific metadata and > focus on the core requirements of a VM. You're perfectly right, but I'm not trying to solve the general mobility problem, nor is virt-convert. (If it were trying to do that, then there wouldn't be a .vmx importer in the first place.) > If we accept we want to use virt-convert to generate libvirt XML, then > we need to require a hypervisor connection URI for this conversion so > we can fetch the capabilities data and fill in the deployment specific > bits. And the resulting libvirt XML generated will be specific to the > machine it was generated on (or another with equivalent setup). Why is this an improvement over specifying stuff on the command line (like --arch) ? regards john From dlutter at redhat.com Tue Jul 8 21:16:42 2008 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 08 Jul 2008 21:16:42 +0000 Subject: [et-mgmt-tools] [PATCH 05 of 11] Allow output in libvirt.rng format In-Reply-To: <20080708185111.GB18805@totally.trollied.org.uk> References: <4528daf7a40728f906e1.1215471095@xenbld> <20080708122507.GN24934@redhat.com> <1215542757.3368.210.camel@localhost.localdomain> <20080708185111.GB18805@totally.trollied.org.uk> Message-ID: <1215551802.3368.217.camel@localhost.localdomain> On Tue, 2008-07-08 at 19:51 +0100, John Levon wrote: > On Tue, Jul 08, 2008 at 06:45:57PM +0000, David Lutterkort wrote: > > > > standalone without any libvirt connection. This means it is unable > > > to get any hypervisor specific capabilities data to determine what > > > the required OS / boot type options are. > > > > The right approach then seems to use virt-convert to convert to > > image.xml and use virt-image to fill in the deployment specific bits, > > even if the user thinks they are just converting a VM from one format to > > another. > > If you mean implementation-wise (i.e. virtinstance.py should just call > out to virt-image), then I suppose that'd be OK, because you can use > virt-convert cmdline options plus the parsed config to specify exactly > what you need in virt-image. It should even be possible to do this in-process - if there is anything of interest left in the actual virt-image CLI driver that is needed, it should just be moved into the virtinst/ 'API' > If you mean the *user* should do this, then see my other mail. I am losing tracks of mails in this thread - I *think* I know which one you are referring to, and will reply to that. What the right flow is, i.e. whether the user should get a libvirt XML or image.xml depends on the specific use case. The work around virt-pack/virt-convert initially came out of wanting to turn an appliance (i.e., VM image) into an appliance usable with another virt solution. Of course, the use case of importing a VMWare VM into a libvirt-based hypervisor is extremely important, too, though whether you're going from VMWare VM -> libvirt image -> libvirt VM or straight from one VM to the other depends a lot on what the user is trying to do, since VMWare does not distinguish between a VM image/template and an instantiated VM. David From dlutter at redhat.com Tue Jul 8 21:21:11 2008 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 08 Jul 2008 21:21:11 +0000 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: <20080708124941.GB2003@totally.trollied.org.uk> References: <26beabc283b11e40ed01.1215471099@xenbld> <20080708123042.GQ24934@redhat.com> <20080708124941.GB2003@totally.trollied.org.uk> Message-ID: <1215552071.3368.223.camel@localhost.localdomain> On Tue, 2008-07-08 at 13:49 +0100, John Levon wrote: > On Tue, Jul 08, 2008 at 01:30:42PM +0100, Daniel P. Berrange wrote: > > > > Add OS variant options to virt-convert. > > > > > > And use them to set ACPI, APIC, clock, and USB tablet. > > > > Again, I don't think libvirt domain XML should be handled by this tool > > precisely because of the issues you're attempting to address here. > > What do you mean "again" ? > > libvirt is only part of the problem: it's not the only virt format with > hypervisor specific settings. Even if you were to enforce the use of > virt-image, you've still got the same problems if we ever want true > mobility between other formats. > > Even worse, the image XML is very lossy. Whilst I imagine that > virt-image will *typically* be used, enforcing an information-removing > step doesn't make much sense to me. As far as this patch is concernd, ACPI and APIC can be requested in the virt-image XML; and clock and USB tablet should probably be added to it. The clock setting is a little weird, but I can imagine scenarios where that's not really a deployment specific option (or one that sets a default that can be overridden) What other VM attributes do you need to preserve ? Other things like MAC address fall into the category of 'needed in some cases, but not in others' IMHO > And finally, there is currently no way to generate image XML from a > domain config (AFAIK). Yes, that's definitely a gap. > So we want this for libvirt import anyway. Are you talking about a libvirt -> VMWare etc. conversion or something else ? David From levon at movementarian.org Tue Jul 8 21:38:41 2008 From: levon at movementarian.org (John Levon) Date: Tue, 8 Jul 2008 22:38:41 +0100 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: <1215552071.3368.223.camel@localhost.localdomain> References: <26beabc283b11e40ed01.1215471099@xenbld> <20080708123042.GQ24934@redhat.com> <20080708124941.GB2003@totally.trollied.org.uk> <1215552071.3368.223.camel@localhost.localdomain> Message-ID: <20080708213841.GA26629@totally.trollied.org.uk> On Tue, Jul 08, 2008 at 09:21:11PM +0000, David Lutterkort wrote: > > > > And use them to set ACPI, APIC, clock, and USB tablet. > > > > > > Again, I don't think libvirt domain XML should be handled by this tool > > > precisely because of the issues you're attempting to address here. > > > > What do you mean "again" ? > > > > libvirt is only part of the problem: it's not the only virt format with > > hypervisor specific settings. Even if you were to enforce the use of > > virt-image, you've still got the same problems if we ever want true > > mobility between other formats. > > > > Even worse, the image XML is very lossy. Whilst I imagine that > > virt-image will *typically* be used, enforcing an information-removing > > step doesn't make much sense to me. > > As far as this patch is concernd, ACPI and APIC can be requested in the > virt-image XML; and clock and USB tablet should probably be added to it. > The clock setting is a little weird, but I can imagine scenarios where > that's not really a deployment specific option (or one that sets a > default that can be overridden) It's not just about these particular options, it's a general thing. Whilst I agree that the virt-image route is the right one for most cases, and I expect us to use it for most things, it doesn't make sense for a conversion tool to purposefully throw away useful information. A concrete example: several hypervisors can make use of qemu char device specs (putting the serial console on a particular port for telnet, for example). Without direct output, we'd throw that information out. Now, there are a lot of use cases where we *don't* care about that stuff, and that's great: we have virt-image as the default output format for that. Furthermore, the more of these things you add, the more you'll find yourself with non-agnostic XML. Today, for example, the ACPI/APIC settings are already host-specific (apic=1 kills a UP Solaris domU, but presumably not on VMWare, maybe not on kvm, etc.). > > And finally, there is currently no way to generate image XML from a > > domain config (AFAIK). > > So we want this for libvirt import anyway. > > Are you talking about a libvirt -> VMWare etc. conversion That, plus building templates based on existing domUs etc. For example, if I bring a dom0 under the control of oVirt (or whatever), I most definitely want to dig out virt-image format descriptions of each of the domUs. Hope that makes my thinking on this a little clearer. regards, john From crobinso at redhat.com Wed Jul 9 15:18:11 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 09 Jul 2008 11:18:11 -0400 Subject: [et-mgmt-tools] [PATCH 0/2] virtinst: add support for audio devices Message-ID: <4874D6B3.6050005@redhat.com> The following patches add support for creating sound device xml in virtinst, and using this from virt-install. If there are no objections I'll commit in a few days. Thanks, Cole From crobinso at redhat.com Wed Jul 9 15:21:28 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 09 Jul 2008 11:21:28 -0400 Subject: [et-mgmt-tools] [PATCH 1/2] virtinst: add VirtualAudio class In-Reply-To: <4874D6B3.6050005@redhat.com> References: <4874D6B3.6050005@redhat.com> Message-ID: <4874D778.7030602@redhat.com> A VirtualAudio class is added which is used to generate a single xml tag. It validates the passed model against an internal whitelist, though hopefully this will eventually be exposed via libvirt capabilities xml so we won't need to maintain duplicate lists. The Guest class has a sound_devs list which holds any VirtualAudio devices to add to the xml. Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-virtualaudio-patch URL: From crobinso at redhat.com Wed Jul 9 15:21:39 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 09 Jul 2008 11:21:39 -0400 Subject: [et-mgmt-tools] [PATCH 2/2] virtinst: add --sound option to virt-install In-Reply-To: <4874D6B3.6050005@redhat.com> References: <4874D6B3.6050005@redhat.com> Message-ID: <4874D783.9000807@redhat.com> In virt-install I added a boolean --sound option which defaults to adding the es1370 device, which seems to be sufficient for most modern distros. I'm not sure if this option should be adjusted to allow the user to specify sound models but it seems like added complexity for an undetermined use case. Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-install-sound-patch URL: From berrange at redhat.com Wed Jul 9 15:25:00 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 9 Jul 2008 16:25:00 +0100 Subject: [et-mgmt-tools] [PATCH 1/2] virtinst: add VirtualAudio class In-Reply-To: <4874D778.7030602@redhat.com> References: <4874D6B3.6050005@redhat.com> <4874D778.7030602@redhat.com> Message-ID: <20080709152500.GB14415@redhat.com> On Wed, Jul 09, 2008 at 11:21:28AM -0400, Cole Robinson wrote: > A VirtualAudio class is added which is used to generate a single > xml tag. It validates the passed model against an internal > whitelist, though hopefully this will eventually be exposed via > libvirt capabilities xml so we won't need to maintain duplicate > lists. The Guest class has a sound_devs list which holds any > VirtualAudio devices to add to the xml. ACK. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Jul 9 15:25:53 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 9 Jul 2008 16:25:53 +0100 Subject: [et-mgmt-tools] [PATCH 2/2] virtinst: add --sound option to virt-install In-Reply-To: <4874D783.9000807@redhat.com> References: <4874D6B3.6050005@redhat.com> <4874D783.9000807@redhat.com> Message-ID: <20080709152553.GC14415@redhat.com> On Wed, Jul 09, 2008 at 11:21:39AM -0400, Cole Robinson wrote: > In virt-install I added a boolean --sound option which defaults > to adding the es1370 device, which seems to be sufficient for > most modern distros. I'm not sure if this option should be > adjusted to allow the user to specify sound models but it seems > like added complexity for an undetermined use case. > @@ -405,6 +406,7 @@ > cli.get_memory(options.memory, guest) > cli.get_uuid(options.uuid, guest) > cli.get_vcpus(options.vcpus, options.check_cpu, guest, conn) > + cli.get_sound(options.sound, guest) You want to skip this unless explicitly 'hvm' - paravirt Xen and container based virt have no sound support. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Wed Jul 9 15:28:00 2008 From: levon at movementarian.org (John Levon) Date: Wed, 9 Jul 2008 16:28:00 +0100 Subject: [et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert In-Reply-To: <20080708205557.GA25569@totally.trollied.org.uk> References: <26beabc283b11e40ed01.1215471099@xenbld> <20080708123042.GQ24934@redhat.com> <20080708124941.GB2003@totally.trollied.org.uk> <20080708203249.GA28823@redhat.com> <20080708205557.GA25569@totally.trollied.org.uk> Message-ID: <20080709152800.GA2184@totally.trollied.org.uk> On Tue, Jul 08, 2008 at 09:55:57PM +0100, John Levon wrote: > > If we accept we want to use virt-convert to generate libvirt XML, then > > we need to require a hypervisor connection URI for this conversion so > > we can fetch the capabilities data and fill in the deployment specific > > bits. And the resulting libvirt XML generated will be specific to the > > machine it was generated on (or another with equivalent setup). > > Why is this an improvement over specifying stuff on the command line > (like --arch) ? I take that back, whilst certainly the capabilities stuff is irrelevant today for Xen (based on what I get back on Solaris, anyway), I can see that it will matter in the future. So yes, we need a --connect option. It would typically default to none except when needed, and then we use the default connection. regards john From crobinso at redhat.com Wed Jul 9 15:47:23 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 09 Jul 2008 11:47:23 -0400 Subject: [et-mgmt-tools] Anyone have a bonding device setup working with virt-manager? Message-ID: <4874DD8B.8060109@redhat.com> Hi All, Back in February, support for checking bonding and vlan devices was added to virt-manager, and released in version 0.5.4. I'm curious if anyone has a working setup with this code? Reason I ask is that I backported this code to rhel5.2 and it doesn't seem to work, because of the following bit: + def _net_get_bonding_masters(self): + masters = [] + f = open("/sys/class/net/bonding_masters") + while True: + rline = f.readline() + if not rline: break + if rline == "\x00": continue + rline = rline.strip("\n\t") + masters = rline[:-1].split(' ') ^^^ this piece + return masters For some reason the last character is stripped off, which breaks all the setups I've tested on. Clearly this must have worked for someone at some time, so I would be curious to get some help from someone with a working setup, since there must be some middle ground that can work for both parties. I've tried contacting the original author but haven't received a response. This code is from: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=6a155cfe437c Thanks, Cole From crobinso at redhat.com Wed Jul 9 15:50:11 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 09 Jul 2008 11:50:11 -0400 Subject: [et-mgmt-tools] [PATCH 2/2] virtinst: add --sound option to virt-install In-Reply-To: <20080709152553.GC14415@redhat.com> References: <4874D6B3.6050005@redhat.com> <4874D783.9000807@redhat.com> <20080709152553.GC14415@redhat.com> Message-ID: <4874DE33.4020306@redhat.com> Daniel P. Berrange wrote: > On Wed, Jul 09, 2008 at 11:21:39AM -0400, Cole Robinson wrote: >> In virt-install I added a boolean --sound option which defaults >> to adding the es1370 device, which seems to be sufficient for >> most modern distros. I'm not sure if this option should be >> adjusted to allow the user to specify sound models but it seems >> like added complexity for an undetermined use case. > >> @@ -405,6 +406,7 @@ >> cli.get_memory(options.memory, guest) >> cli.get_uuid(options.uuid, guest) >> cli.get_vcpus(options.vcpus, options.check_cpu, guest, conn) >> + cli.get_sound(options.sound, guest) > > You want to skip this unless explicitly 'hvm' - paravirt Xen and > container based virt have no sound support. > > Daniel Ah good call, I'll fix when I apply. Thanks, Cole From berrange at redhat.com Wed Jul 9 16:06:24 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 9 Jul 2008 17:06:24 +0100 Subject: [et-mgmt-tools] Anyone have a bonding device setup working with virt-manager? In-Reply-To: <4874DD8B.8060109@redhat.com> References: <4874DD8B.8060109@redhat.com> Message-ID: <20080709160624.GE14415@redhat.com> On Wed, Jul 09, 2008 at 11:47:23AM -0400, Cole Robinson wrote: > Hi All, > > Back in February, support for checking bonding and vlan devices was > added to virt-manager, and released in version 0.5.4. I'm curious if > anyone has a working setup with this code? > > Reason I ask is that I backported this code to rhel5.2 and it doesn't > seem to work, because of the following bit: > > + def _net_get_bonding_masters(self): > + masters = [] > + f = open("/sys/class/net/bonding_masters") > + while True: > + rline = f.readline() > + if not rline: break > + if rline == "\x00": continue > + rline = rline.strip("\n\t") > + masters = rline[:-1].split(' ') > ^^^ > this piece > + return masters > > For some reason the last character is stripped off, which breaks all > the setups I've tested on. Clearly this must have worked for someone > at some time, so I would be curious to get some help from someone with > a working setup, since there must be some middle ground that can work > for both parties. I've tried contacting the original author but haven't > received a response. Interesting - that code was tested on a machine running Fedora 8 IIRC so its quite possible the older RHEL-5 kernel had slightly different info in sysfs. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Wed Jul 9 17:44:14 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 09 Jul 2008 13:44:14 -0400 Subject: [et-mgmt-tools] Anyone have a bonding device setup working with virt-manager? In-Reply-To: <20080709160624.GE14415@redhat.com> References: <4874DD8B.8060109@redhat.com> <20080709160624.GE14415@redhat.com> Message-ID: <4874F8EE.40406@redhat.com> Daniel P. Berrange wrote: > On Wed, Jul 09, 2008 at 11:47:23AM -0400, Cole Robinson wrote: >> Hi All, >> >> Back in February, support for checking bonding and vlan devices was >> added to virt-manager, and released in version 0.5.4. I'm curious if >> anyone has a working setup with this code? >> >> Reason I ask is that I backported this code to rhel5.2 and it doesn't >> seem to work, because of the following bit: >> >> + def _net_get_bonding_masters(self): >> + masters = [] >> + f = open("/sys/class/net/bonding_masters") >> + while True: >> + rline = f.readline() >> + if not rline: break >> + if rline == "\x00": continue >> + rline = rline.strip("\n\t") >> + masters = rline[:-1].split(' ') >> ^^^ >> this piece >> + return masters >> >> For some reason the last character is stripped off, which breaks all >> the setups I've tested on. Clearly this must have worked for someone >> at some time, so I would be curious to get some help from someone with >> a working setup, since there must be some middle ground that can work >> for both parties. I've tried contacting the original author but haven't >> received a response. > > Interesting - that code was tested on a machine running Fedora 8 IIRC > so its quite possible the older RHEL-5 kernel had slightly different > info in sysfs. > > Daniel That's my guess as well: on the RHEL setup this was stripping a legitimate character. Maybe there is some seperator or whitespace character that is present on f8? If anyone has a bonding setup on fedora they could probably paste their /sys/class/net/bonding_masters (and possibly a hexdump of it) and we could fix this. - Cole From john.levon at sun.com Wed Jul 9 18:29:36 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Wed, 09 Jul 2008 11:29:36 -0700 Subject: [et-mgmt-tools] [PATCH 2 of 5] Fix multiple disks In-Reply-To: Message-ID: <96d74c328fd60b05c27a.1215628176@joos> # HG changeset patch # User john.levon at sun.com # Date 1215627964 25200 # Node ID 96d74c328fd60b05c27af8ea1b4412756bf329db # Parent c6d2254702a49d9674d6c549bd57cb87ac920e87 Fix multiple disks Fix handling of multiple disks. Signed-off-by: John Levon diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -117,12 +117,12 @@ # FIXME: needs updating for later Xen enhancements; need to # implement capabilities checking for max disks etc. - pv_disks.append("""""" % + pv_disks.append("""\n""" % (path, ascii_letters[number % 26])) - hvm_disks.append("""""" % + hvm_disks.append("""\n""" % (path, ascii_letters[number % 26])) storage_disks.append( - """""" % path) + """\n""" % path) if vm.type == vmconfig.VM_TYPE_PV: boot_template = pv_boot_template diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -60,6 +60,7 @@ lines.append(line) config = {} + disks = [] # split out all remaining entries of key = value form for (line_nr, line) in enumerate(lines): @@ -69,6 +70,9 @@ value = after_eq.replace('"',"") value = value.strip() config[key] = value + # FIXME: this should probably be a lot smarter. + if value.endswith(".vmdk"): + disks += [ value ] except: raise Exception("Syntax error at line %d: %s" % (line_nr + 1, line.strip())) @@ -80,10 +84,6 @@ vm.memory = config.get("memsize") vm.description = config.get("annotation") vm.nr_vcpus = config.get("numvcpus") - - # FIXME: this should probably be a lot smarter. I don't think - # this even gets disk numbering right. - disks = [ d for d in config.values() if d.endswith(".vmdk") ] for (number, path) in enumerate(disks): vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] From john.levon at sun.com Wed Jul 9 18:29:37 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Wed, 09 Jul 2008 11:29:37 -0700 Subject: [et-mgmt-tools] [PATCH 3 of 5] Improve virt-convert output In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215627974 25200 # Node ID c96c084d9b8d39a6df238cd9798011a8c4a34dd0 # Parent 96d74c328fd60b05c27af8ea1b4412756bf329db Improve virt-convert output Print some details before long operations such as disk convert, and add a --quiet flag to allow skipping them. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -178,6 +178,9 @@ .IP "\-d, \-\-debug" 4 .IX Item "-d, --debug" Print debugging information +.IP "\-q, \-\-quiet" 4 +.IX Item "-q, --quiet" +Avoid verbose output. .SH "EXAMPLES" .IX Header "EXAMPLES" Convert a paravirt guest from \f(CW\*(C`image.vmx\*(C'\fR: diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -62,6 +62,10 @@ Print debugging information +=item -q, --quiet + +Avoid verbose output. + =back =head1 EXAMPLES diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -35,6 +35,8 @@ opts = OptionParser() opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") + opts.add_option("-q", "--quiet", action="store_true", dest="quiet", + help=("Don't be verbose")) opts.add_option("-a", "--arch", type="string", dest="arch", default=util.get_default_arch(), help=("Machine Architecture Type (i686/x86_64/ppc)")) @@ -43,10 +45,10 @@ opts.add_option("-d", "--debug", action="store_true", dest="debug", help=("Print debugging information")) opts.add_option("-i", "--input-format", action="store", - dest="inputformat", default="vmx", + dest="input_format", default="vmx", help=("Input format, e.g. 'vmx'")) opts.add_option("-o", "--output-format", action="store", - dest="outputformat", default="virt-image", + dest="output_format", default="virt-image", help=("Output format, e.g. 'virt-image'")) opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", help=("This guest should be a fully virtualized guest")) @@ -60,11 +62,11 @@ opts.error(("Too many arguments provided")) # hard-code for now - if options.inputformat != "vmx": - opts.error(("Unsupported input format \"%s\"" % options.inputformat)) - if options.outputformat != "virt-image": + if options.input_format != "vmx": + opts.error(("Unsupported input format \"%s\"" % options.input_format)) + if options.output_format != "virt-image": opts.error(("Unsupported output format \"%s\"" - % options.outputformat)) + % options.output_format)) if os.path.isdir(args[0]): vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] if (len(vmx_files)) == 0: @@ -91,22 +93,27 @@ return options +def verbose(options, msg): + """Output a message if --quiet is not set.""" + if not options.quiet: + print msg + def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) try: - inp = virtconv.vmconfig.find_parser_by_name(options.inputformat) + inp = virtconv.vmconfig.find_parser_by_name(options.input_format) except: logging.error("No parser of format \"%s\" was found." % - options.inputformat) + options.input_format) sys.exit(1) try: - outp = virtconv.vmconfig.find_parser_by_name(options.outputformat) + outp = virtconv.vmconfig.find_parser_by_name(options.output_format) except: logging.error("No parser of format \"%s\" was found." % - options.outputformat) + options.output_format) sys.exit(1) vmdef = None @@ -150,8 +157,13 @@ logging.debug("output_file: %s" % options.output_file) logging.debug("output_dir: %s" % options.input_dir) + verbose(options, "Generating output in \"%s\" format to %s/" % + (options.output_format, options.output_dir)) + try: for d in vmdef.disks: + verbose(options, "Converting disk \"%s\" to type %s..." % + (d.path, vmconfig.qemu_formats[vmconfig.DISK_TYPE_RAW])) d.convert(options.input_dir, options.output_dir, vmconfig.DISK_TYPE_RAW) except Exception, e: @@ -164,7 +176,7 @@ logging.error(e) sys.exit(1) - print "\n\nConversion completed and placed in: %s" % options.output_dir + verbose(options, "Done.") if __name__ == "__main__": From john.levon at sun.com Wed Jul 9 18:29:34 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Wed, 09 Jul 2008 11:29:34 -0700 Subject: [et-mgmt-tools] [PATCH 0 of 5] virt-convert fixes Message-ID: This is a resend of a few of the less controversial bits in my last series, with suggested fixes applied. From john.levon at sun.com Wed Jul 9 18:29:39 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Wed, 09 Jul 2008 11:29:39 -0700 Subject: [et-mgmt-tools] [PATCH 5 of 5] Allow specification of output disk format In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215628144 25200 # Node ID eca4a4800ad7c6254fdaef56587f143cf16f5262 # Parent a36c666ef5d381e3961545d0359949e82d6d064b Allow specification of output disk format In particular, allow the disk conversion to be skipped. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -129,7 +129,7 @@ .\" ======================================================================== .\" .IX Title "VIRT-CONVERT 1" -.TH VIRT-CONVERT 1 "2008-07-04" "perl v5.8.8" "Virtual Machine Install Tools" +.TH VIRT-CONVERT 1 "2008-07-09" "perl v5.8.8" "Virtual Machine Install Tools" .SH "NAME" virt\-convert \- convert virtual machines between formats .SH "SYNOPSIS" @@ -175,6 +175,10 @@ .IP "\-o format" 4 .IX Item "-o format" Output format. Currently, \f(CW\*(C`virt\-image\*(C'\fR is the only supported output format. +.IP "\-D format" 4 +.IX Item "-D format" +Output disk format, or \f(CW\*(C`none\*(C'\fR if no conversion should be performed. See +\&\fIqemu\-img\fR\|(1). .IP "\-d, \-\-debug" 4 .IX Item "-d, --debug" Print debugging information @@ -196,7 +200,7 @@ .Ve .SH "AUTHOR" .IX Header "AUTHOR" -Written by Joey Boggs +Written by Joey Boggs and John Levon .PP See the \s-1AUTHORS\s0 file in the source distribution for the complete list of credits. .SH "BUGS" diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -58,6 +58,11 @@ Output format. Currently, C is the only supported output format. +=item -D format + +Output disk format, or C if no conversion should be performed. See +L. + =item -d, --debug Print debugging information @@ -80,7 +85,7 @@ =head1 AUTHOR -Written by Joey Boggs +Written by Joey Boggs and John Levon See the AUTHORS file in the source distribution for the complete list of credits. diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -24,6 +24,7 @@ import os import logging import errno +import platform from optparse import OptionParser import virtinst.cli as cli @@ -53,6 +54,8 @@ opts.add_option("-o", "--output-format", action="store", dest="output_format", default="virt-image", help=("Output format, e.g. 'virt-image'")) + opts.add_option("-D", "--disk-format", action="store", + dest="disk_format", help=("Output disk format")) opts.add_option("-v", "--hvm", action="store_true", dest="fullvirt", help=("This guest should be a fully virtualized guest")) opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", @@ -64,6 +67,10 @@ if len(args) > 2: opts.error(("Too many arguments provided")) + if (options.disk_format and + options.disk_format not in diskcfg.disk_formats()): + opts.error("Unknown output disk format \"%s\"" % options.disk_format) + # hard-code for now if options.input_format != "vmx": opts.error(("Unsupported input format \"%s\"" % options.input_format)) @@ -191,9 +198,22 @@ try: for d in vmdef.disks: - verbose(options, "Converting disk \"%s\" to type %s..." % - (d.path, "raw")) - d.convert(options.input_dir, options.output_dir, "raw") + format = options.disk_format + + # no auto-conversion on Solaris for VMDK disks + if (d.format == diskcfg.DISK_FORMAT_VMDK and + not format and platform.system() == "SunOS"): + continue + + if not format: + format = "raw" + + if format != "none": + verbose(options, "Converting disk \"%s\" to type %s..." % + (d.path, format)) + + d.convert(options.input_dir, options.output_dir, format) + except OSError, e: cleanup("Couldn't convert disks: %s" % e.strerror, options, vmdef, clean) From john.levon at sun.com Wed Jul 9 18:29:35 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Wed, 09 Jul 2008 11:29:35 -0700 Subject: [et-mgmt-tools] [PATCH 1 of 5] Make --arch optional In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215627958 25200 # Node ID c6d2254702a49d9674d6c549bd57cb87ac920e87 # Parent a2be1263c2f5d3f346cfc3501682073fce2e8966 Make --arch optional. Default to the current system arch. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -129,7 +129,7 @@ .\" ======================================================================== .\" .IX Title "VIRT-CONVERT 1" -.TH VIRT-CONVERT 1 "2008-07-01" "perl v5.8.8" "Virtual Machine Install Tools" +.TH VIRT-CONVERT 1 "2008-07-04" "perl v5.8.8" "Virtual Machine Install Tools" .SH "NAME" virt\-convert \- convert virtual machines between formats .SH "SYNOPSIS" @@ -161,7 +161,8 @@ Show the help message and exit .IP "\-a \s-1ARCH\s0, \-\-arch=ARCH" 4 .IX Item "-a ARCH, --arch=ARCH" -Architecture of the virtual machine (i686, x86_64, ppc) +Architecture of the virtual machine (i686, x86_64, ppc). Defaults to +that of the host machine. .IP "\-v, \-\-hvm Create a fully virtualized guest image" 4 .IX Item "-v, --hvm Create a fully virtualized guest image" Convert machine to a hvm/qemu based image (this is the default if paravirt is not specified) diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -39,7 +39,8 @@ =item -a ARCH, --arch=ARCH -Architecture of the virtual machine (i686, x86_64, ppc) +Architecture of the virtual machine (i686, x86_64, ppc). Defaults to +that of the host machine. =item -v, --hvm Create a fully virtualized guest image diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -27,6 +27,7 @@ from optparse import OptionParser import virtinst.cli as cli +import virtinst.util as util import virtconv import virtconv.vmconfig as vmconfig @@ -35,6 +36,7 @@ opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") opts.add_option("-a", "--arch", type="string", dest="arch", + default=util.get_default_arch(), help=("Machine Architecture Type (i686/x86_64/ppc)")) opts.add_option("-t", "--type", type="string", dest="type", help=("Output virtualization type (hvm, paravirt")) @@ -57,10 +59,6 @@ if len(args) > 2: opts.error(("Too many arguments provided")) - if (options.arch is None): - opts.error(("Missing option value \n\nArchitecture: " + - str(options.arch))) - # hard-code for now if options.inputformat != "vmx": opts.error(("Unsupported input format \"%s\"" % options.inputformat)) From john.levon at sun.com Wed Jul 9 18:29:38 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Wed, 09 Jul 2008 11:29:38 -0700 Subject: [et-mgmt-tools] [PATCH 4 of 5] Cleanup on failure In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215627983 25200 # Node ID a36c666ef5d381e3961545d0359949e82d6d064b # Parent c96c084d9b8d39a6df238cd9798011a8c4a34dd0 Cleanup on failure If we can't convert the disks or export the file, perform some cleanup. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -29,9 +29,12 @@ import virtinst.cli as cli import virtinst.util as util import virtconv -import virtconv.vmconfig as vmconfig +import virtconv.formats as formats +import virtconv.vmcfg as vmcfg +import virtconv.diskcfg as diskcfg def parse_args(): + """Parse and verify command line.""" opts = OptionParser() opts.set_usage("%prog [options] inputdir|input.vmx " "[outputdir|output.xml]") @@ -98,19 +101,41 @@ if not options.quiet: print msg +def cleanup(msg, options, vmdef, paths): + """ + After failure, clean up anything we created. + """ + logging.error(msg) + + try: + paths.reverse() + for path in paths: + if os.path.isdir(path): + os.rmdir(path) + elif os.path.isfile(path): + os.remove(path) + + for disk in vmdef.disks: + disk.cleanup() + except OSError, e: + logging.error("Couldn't clean up output directory \"%s\": %s" % + (options.output_dir, e.strerror)) + + sys.exit(1) + def main(): options = parse_args() cli.setupLogging("virt-convert", options.debug) try: - inp = virtconv.vmconfig.find_parser_by_name(options.input_format) + inp = formats.find_parser_by_name(options.input_format) except: logging.error("No parser of format \"%s\" was found." % options.input_format) sys.exit(1) try: - outp = virtconv.vmconfig.find_parser_by_name(options.output_format) + outp = formats.find_parser_by_name(options.output_format) except: logging.error("No parser of format \"%s\" was found." % options.output_format) @@ -130,17 +155,21 @@ sys.exit(1) if options.paravirt: - vmdef.type = vmconfig.VM_TYPE_PV + vmdef.type = vmcfg.VM_TYPE_PV else: - vmdef.type = vmconfig.VM_TYPE_HVM + vmdef.type = vmcfg.VM_TYPE_HVM vmdef.arch = options.arch + clean = [] + unixname = vmdef.name.replace(" ", "-") + if not options.output_dir: options.output_dir = unixname try: logging.debug("Creating directory %s" % options.output_dir) + clean += [ options.output_dir ] os.mkdir(options.output_dir) except OSError, e: if (e.errno != errno.EEXIST): @@ -163,18 +192,20 @@ try: for d in vmdef.disks: verbose(options, "Converting disk \"%s\" to type %s..." % - (d.path, vmconfig.qemu_formats[vmconfig.DISK_TYPE_RAW])) - d.convert(options.input_dir, options.output_dir, - vmconfig.DISK_TYPE_RAW) - except Exception, e: - logging.error(e) - sys.exit(1) - + (d.path, "raw")) + d.convert(options.input_dir, options.output_dir, "raw") + except OSError, e: + cleanup("Couldn't convert disks: %s" % e.strerror, + options, vmdef, clean) + except RuntimeError, e: + cleanup("Couldn't convert disks: %s" % e.message, options, vmdef, clean) + try: + clean += [ options.output_file ] outp.export_file(vmdef, options.output_file) - except Exception, e: - logging.error(e) - sys.exit(1) + except ValueError, e: + cleanup("Couldn't export to file \"%s\": %s" % + (options.output_file, e.message), options, vmdef, clean) verbose(options, "Done.") diff --git a/virtconv/diskcfg.py b/virtconv/diskcfg.py new file mode 100644 --- /dev/null +++ b/virtconv/diskcfg.py @@ -0,0 +1,181 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +import shutil +import errno +import os + +DISK_FORMAT_NONE = 0 +DISK_FORMAT_RAW = 1 +DISK_FORMAT_VMDK = 2 +DISK_FORMAT_VDISK = 3 + +DISK_TYPE_DISK = 0 +DISK_TYPE_CDROM = 1 +DISK_TYPE_ISO = 2 + +disk_suffixes = { + DISK_FORMAT_RAW: ".img", + DISK_FORMAT_VMDK: ".vmdk", + DISK_FORMAT_VDISK: ".vdisk.xml", +} + +qemu_formats = { + DISK_FORMAT_RAW: "raw", + DISK_FORMAT_VMDK: "vmdk", + DISK_FORMAT_VDISK: "vdisk", +} + +disk_format_names = { + "none": DISK_FORMAT_NONE, + "raw": DISK_FORMAT_RAW, + "vmdk": DISK_FORMAT_VMDK, + "vdisk": DISK_FORMAT_VDISK, +} + +def ensuredirs(path): + """ + Make sure that all the containing directories of the given file + path exist. + """ + try: + os.makedirs(os.path.dirname(path)) + except OSError, e: + if e.errno != errno.EEXIST: + raise + +class disk(object): + """Definition of an individual disk instance.""" + + def __init__(self, path = None, number = 0, format = None, bus = "ide", + type = DISK_TYPE_DISK): + self.path = path + self.format = format + self.number = number + self.bus = bus + self.type = type + self.clean = [] + + def cleanup(self): + """ + Remove any generated output. + """ + + for path in self.clean: + if os.path.isfile(path): + os.remove(path) + + self.clean = [] + + def copy_file(self, infile, outfile): + """Copy an individual file.""" + self.clean += [ outfile ] + ensuredirs(outfile) + shutil.copy(infile, outfile) + + def copy(self, indir, outdir, out_format): + """ + Copy the underlying disk files to a destination, if necessary. + Return True if we need a further conversion step. + """ + + if os.path.isabs(self.path): + return False + + need_copy = False + need_convert = False + + if self.format == out_format: + need_convert = False + need_copy = (indir != outdir) + else: + if out_format == DISK_FORMAT_NONE: + need_copy = (indir != outdir) + need_convert = False + else: + need_copy = (indir != outdir and out_format == DISK_FORMAT_VDISK) + need_convert = True + + if need_copy: + if out_format == DISK_FORMAT_VDISK: + stdin, stdout = os.popen2(["/usr/bin/vdiskadm", "import", "-n", + "-f", "-t", qemu_formats[self.format], + "\"%s\"" % os.path.join(indir, self.path)]) + paths = stdout.readlines() + stdin.close() + stdout.close() + for path in paths: + self.copy_file(os.path.join(indir, path), + os.path.join(outdir, path)) + return need_convert + + # this is not correct for all VMDK files, but it will have + # to do for now + self.copy_file(os.path.join(indir, self.path), + os.path.join(outdir, self.path)) + + return need_convert + + def convert(self, indir, outdir, output_format): + """ + Convert a disk into the requested format if possible, in the + given output directory. Raises RuntimeError or other + failures. + """ + + out_format = disk_format_names[output_format] + indir = os.path.normpath(os.path.abspath(indir)) + outdir = os.path.normpath(os.path.abspath(outdir)) + + need_convert = self.copy(indir, outdir, out_format) + if not need_convert: + return + + relin = self.path + relout = self.path.replace(disk_suffixes[self.format], + disk_suffixes[out_format]) + absin = os.path.join(indir, relin) + absout = os.path.join(outdir, relout) + + ensuredirs(absout) + + if out_format == DISK_FORMAT_VDISK: + convert_cmd = ("""/usr/bin/vdiskadm import -t %s "%s" "%s" """ % + (qemu_formats[out_format], absin, absout)) + elif out_format == DISK_FORMAT_RAW: + convert_cmd = ("""qemu-img convert "%s" -O %s "%s" """ % + (absin, qemu_formats[out_format], absout)) + else: + raise NotImplementedError("Cannot convert to disk format %s" % + output_format) + + ret = os.system(convert_cmd) + if ret != 0: + raise RuntimeError("Disk conversion failed with exit status %d" + % ret) + + self.path = relout + self.format = out_format + +def disk_formats(): + """ + Return a list of supported disk formats. + """ + return disk_format_names.keys() diff --git a/virtconv/formats.py b/virtconv/formats.py new file mode 100644 --- /dev/null +++ b/virtconv/formats.py @@ -0,0 +1,82 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +_parsers = [ ] + +class parser(object): + """ + Base class for particular config file format definitions of + a VM instance. + + Warning: this interface is not (yet) considered stable and may + change at will. + """ + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + raise NotImplementedError + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @output_file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + raise NotImplementedError + + +def register_parser(parser): + """ + Register a particular config format parser. This should be called by each + config plugin on import. + """ + + global _parsers + _parsers += [ parser ] + +def find_parser_by_name(name): + """ + Return the parser of the given name + """ + return [p for p in _parsers if p.name == name][0] or None + +def find_parser_by_file(input_file): + """ + Return the parser that is capable of comprehending the given file. + """ + for p in _parsers: + if p.identify_file(input_file): + return p + return None diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -19,7 +19,9 @@ # from string import ascii_letters -import virtconv.vmconfig as vmconfig +import virtconv.formats as formats +import virtconv.vmcfg as vmcfg +import virtconv.diskcfg as diskcfg pv_boot_template = """ @@ -70,7 +72,7 @@ """ -class virtimage_parser(vmconfig.parser): +class virtimage_parser(formats.parser): """ Support for virt-install's image format (see virt-image man page). """ @@ -122,9 +124,10 @@ hvm_disks.append("""\n""" % (path, ascii_letters[number % 26])) storage_disks.append( - """\n""" % path) + """\n""" + % (path, diskcfg.qemu_formats[disk.format])) - if vm.type == vmconfig.VM_TYPE_PV: + if vm.type == vmcfg.VM_TYPE_PV: boot_template = pv_boot_template else: boot_template = hvm_boot_template @@ -149,4 +152,4 @@ outfile.writelines(out) outfile.close() -vmconfig.register_parser(virtimage_parser) +formats.register_parser(virtimage_parser) diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -18,9 +18,11 @@ # MA 02110-1301 USA. # -import virtconv.vmconfig as vmconfig +import virtconv.formats as formats +import virtconv.vmcfg as vmcfg +import virtconv.diskcfg as diskcfg -class vmx_parser(vmconfig.parser): +class vmx_parser(formats.parser): """ Support for VMWare .vmx files. Note that documentation is particularly sparse on this format, with pretty much the best @@ -44,7 +46,7 @@ opened, or parsing otherwise failed. """ - vm = vmconfig.vm() + vm = vmcfg.vm() infile = open(input_file, "r") contents = infile.readlines() @@ -86,7 +88,7 @@ vm.nr_vcpus = config.get("numvcpus") for (number, path) in enumerate(disks): - vm.disks += [ vmconfig.disk(path, number, vmconfig.DISK_TYPE_VMDK) ] + vm.disks += [ diskcfg.disk(path, number, diskcfg.DISK_FORMAT_VMDK) ] vm.validate() return vm @@ -104,4 +106,4 @@ raise NotImplementedError -vmconfig.register_parser(vmx_parser) +formats.register_parser(vmx_parser) diff --git a/virtconv/vmconfig.py b/virtconv/vmcfg.py rename from virtconv/vmconfig.py rename to virtconv/vmcfg.py --- a/virtconv/vmconfig.py +++ b/virtconv/vmcfg.py @@ -18,71 +18,8 @@ # MA 02110-1301 USA. # -import os - -_parsers = [ ] - VM_TYPE_PV = 0 VM_TYPE_HVM = 1 - -DISK_TYPE_RAW = 0 -DISK_TYPE_VMDK = 1 - -disk_suffixes = { - DISK_TYPE_RAW: ".img", - DISK_TYPE_VMDK: ".vmdk", -} - -qemu_formats = { - DISK_TYPE_RAW: "raw", - DISK_TYPE_VMDK: "vmdk", -} - -class disk(object): - """Definition of an individual disk instance.""" - - def __init__(self, path = None, number = None, type = None): - self.path = path - self.number = number - self.type = type - - def convert(self, input_dir, output_dir, output_type): - """ - Convert a disk into the requested format if possible, in the - given output directory. Raises NotImplementedError or other - failures. - """ - - if self.type == output_type: - return - - if output_type != DISK_TYPE_RAW: - raise NotImplementedError("Cannot convert to disk type %d" % - output_type) - - infile = self.path - - if not os.path.isabs(infile): - infile = os.path.join(input_dir, infile) - - outfile = self.path - - if os.path.isabs(outfile): - outfile = os.path.basename(outfile) - - outfile = outfile.replace(disk_suffixes[self.type], - disk_suffixes[output_type]).strip() - - convert_cmd = ("qemu-img convert \"%s\" -O %s \"%s\"" % - (infile, qemu_formats[output_type], - os.path.join(output_dir, outfile))) - - os.system(convert_cmd) - - # Note: this is the *relative* path still - self.path = outfile - self.type = output_type - class vm(object): """ @@ -111,7 +48,7 @@ self.nr_vcpus = None self.disks = [ ] self.type = VM_TYPE_HVM - self.arch = "i686" # FIXME? + self.arch = "i686" def validate(self): """ @@ -129,65 +66,3 @@ raise ValueError("VM type is not set") if not self.arch: raise ValueError("VM arch is not set") - - -class parser(object): - """ - Base class for particular config file format definitions of - a VM instance. - - Warning: this interface is not (yet) considered stable and may - change at will. - """ - - @staticmethod - def identify_file(input_file): - """ - Return True if the given file is of this format. - """ - raise NotImplementedError - - @staticmethod - def import_file(input_file): - """ - Import a configuration file. Raises if the file couldn't be - opened, or parsing otherwise failed. - """ - raise NotImplementedError - - @staticmethod - def export_file(vm, output_file): - """ - Export a configuration file. - @vm vm configuration instance - @output_file Output file - - Raises ValueError if configuration is not suitable, or another - exception on failure to write the output file. - """ - raise NotImplementedError - - -def register_parser(parser): - """ - Register a particular config format parser. This should be called by each - config plugin on import. - """ - - global _parsers - _parsers += [ parser ] - -def find_parser_by_name(name): - """ - Return the parser of the given name - """ - return [p for p in _parsers if p.name == name][0] or None - -def find_parser_by_file(input_file): - """ - Return the parser that is capable of comprehending the given file. - """ - for p in _parsers: - if p.identify_file(input_file): - return p - return None From crobinso at redhat.com Wed Jul 9 19:57:19 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 09 Jul 2008 15:57:19 -0400 Subject: [et-mgmt-tools] [PATCH 0 of 5] virt-convert fixes In-Reply-To: References: Message-ID: <4875181F.6090504@redhat.com> john.levon at sun.com wrote: > This is a resend of a few of the less controversial bits in my last series, > with suggested fixes applied. > Thanks! I've applied them. For future reference, if you are going to send exported commits, please make the commit messages a bit more useful (i.e. specifically mention virt-convert). I touched up these messages so no worries for this round. Thanks, Cole From berrange at redhat.com Wed Jul 9 21:21:42 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 9 Jul 2008 22:21:42 +0100 Subject: [et-mgmt-tools] [PATCH 0 of 5] virt-convert fixes In-Reply-To: References: Message-ID: <20080709212142.GF716@redhat.com> On Wed, Jul 09, 2008 at 11:29:34AM -0700, john.levon at sun.com wrote: > > This is a resend of a few of the less controversial bits in my last series, > with suggested fixes applied. All 5 get my vote. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Wed Jul 9 22:01:06 2008 From: levon at movementarian.org (John Levon) Date: Wed, 9 Jul 2008 23:01:06 +0100 Subject: [et-mgmt-tools] [PATCH 01 of 11] Fix multiple disks In-Reply-To: <20080708121446.GJ24934@redhat.com> References: <20080708121446.GJ24934@redhat.com> Message-ID: <20080709220106.GA25851@totally.trollied.org.uk> On Tue, Jul 08, 2008 at 01:14:46PM +0100, Daniel P. Berrange wrote: > > diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py > > --- a/virtconv/parsers/virtimage.py > > +++ b/virtconv/parsers/virtimage.py > > @@ -117,12 +117,12 @@ class virtimage_parser(vmconfig.parser): > > > > # FIXME: needs updating for later Xen enhancements; need to > > # implement capabilities checking for max disks etc. > > - pv_disks.append("""""" % > > + pv_disks.append("""\n""" % > > (path, ascii_letters[number % 26])) > > - hvm_disks.append("""""" % > > + hvm_disks.append("""\n""" % > > (path, ascii_letters[number % 26])) > > IDE only allows upto 4 disks. To allow more than this requires use of > SCSI or VirtIO/Xen paravirt drivers. I missed the second part of this until I just thought about it. What do we do here? Not sure how the Linux paravirt drivers work, but I think the Solaris ones at least can do "hde" etc. > I'd probably say default to IDE for first 4, and then switch to sdNNN > for any subsequent disks. Solaris doesn't have a shim to turn the SCSI device into a PV driver though. regards john From levon at movementarian.org Thu Jul 10 02:23:10 2008 From: levon at movementarian.org (John Levon) Date: Thu, 10 Jul 2008 03:23:10 +0100 Subject: [et-mgmt-tools] image.rng and Message-ID: <20080710022310.GA7653@totally.trollied.org.uk> The schema says no but virt-unpack did create it for virt-image. Which is right? regards john From levon at movementarian.org Thu Jul 10 02:26:13 2008 From: levon at movementarian.org (John Levon) Date: Thu, 10 Jul 2008 03:26:13 +0100 Subject: [et-mgmt-tools] image.rng and In-Reply-To: <20080710022310.GA7653@totally.trollied.org.uk> References: <20080710022310.GA7653@totally.trollied.org.uk> Message-ID: <20080710022613.GB7653@totally.trollied.org.uk> On Thu, Jul 10, 2008 at 03:23:10AM +0100, John Levon wrote: > The schema says no but virt-unpack did create it for > virt-image. Which is right? Sigh, ignore me, a bug... regards john From john.levon at sun.com Thu Jul 10 13:48:40 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:40 -0700 Subject: [et-mgmt-tools] [PATCH 10 of 11] virt-install: correct pygrub path In-Reply-To: Message-ID: <92de696f634f80d47b94.1215697720@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697572 25200 # Node ID 92de696f634f80d47b9413b9db5101de0edf9b7f # Parent 443b42b45ee6f799020a9418388440b93d9ab78c virt-install: correct pygrub path The path to pygrub differs between OS hosts. Properly speaking, this is a property of the hypervisor capabilities, and we'd get it from there. However, traditionally the loader value is empty for PV Xen hosts, so we can't rely on it, so we hard-code it based upon the current host. Signed-off-by: John Levon diff --git a/virtinst/DistroManager.py b/virtinst/DistroManager.py --- a/virtinst/DistroManager.py +++ b/virtinst/DistroManager.py @@ -218,7 +218,7 @@ else: self._prepare_kernel_and_initrd(guest, distro, meter) - def _get_osblob(self, install, hvm, arch = None, loader = None): + def _get_osblob(self, install, hvm, arch = None, loader = None, conn = None): osblob = "" if install or hvm: osblob = "\n" @@ -248,7 +248,7 @@ osblob += " " else: - osblob += "/usr/bin/pygrub" + osblob += "%s" % util.pygrub_path(conn) return osblob @@ -275,7 +275,7 @@ def prepare(self, guest, meter, distro = None): pass - def _get_osblob(self, install, hvm, arch = None, loader = None): + def _get_osblob(self, install, hvm, arch = None, loader = None, conn = None): osblob = "" if install or hvm: osblob = "\n" @@ -300,7 +300,7 @@ osblob += " " else: - osblob += "/usr/bin/pygrub" + osblob += "%s" % util.pygrub_path(conn) return osblob diff --git a/virtinst/FullVirtGuest.py b/virtinst/FullVirtGuest.py --- a/virtinst/FullVirtGuest.py +++ b/virtinst/FullVirtGuest.py @@ -203,7 +203,8 @@ return ret + " " def _get_osblob(self, install): - osblob = self.installer._get_osblob(install, True, self.arch, self.loader) + osblob = self.installer._get_osblob(install, hvm = True, + arch = self.arch, loader = self.loader, conn = self.conn) if osblob is None: return None diff --git a/virtinst/ImageManager.py b/virtinst/ImageManager.py --- a/virtinst/ImageManager.py +++ b/virtinst/ImageManager.py @@ -106,7 +106,7 @@ guest._install_disks.append(d) - def _get_osblob(self, install, hvm, arch = None, loader = None): + def _get_osblob(self, install, hvm, arch = None, loader = None, conn = None): osblob = "\n" if hvm: @@ -136,7 +136,7 @@ osblob += " " elif self.boot_caps.loader == "pygrub" or (self.boot_caps.loader is None and self.boot_caps.type == "xen"): osblob += " \n" - osblob += " /usr/bin/pygrub" + osblob += " %s" % util.pygrub_path(conn) return osblob diff --git a/virtinst/LiveCDInstaller.py b/virtinst/LiveCDInstaller.py --- a/virtinst/LiveCDInstaller.py +++ b/virtinst/LiveCDInstaller.py @@ -55,7 +55,7 @@ readOnly = True) guest._install_disks.insert(0, disk) - def _get_osblob(self, install, hvm, arch = None, loader = None): + def _get_osblob(self, install, hvm, arch = None, loader = None, conn = None): if install: return None diff --git a/virtinst/ParaVirtGuest.py b/virtinst/ParaVirtGuest.py --- a/virtinst/ParaVirtGuest.py +++ b/virtinst/ParaVirtGuest.py @@ -33,7 +33,7 @@ self.disknode = "xvd" def _get_osblob(self, install): - return self.installer._get_osblob(install, hvm = False) + return self.installer._get_osblob(install, hvm = False, conn = self.conn) def get_input_device(self): return ("mouse", "xen") diff --git a/virtinst/util.py b/virtinst/util.py --- a/virtinst/util.py +++ b/virtinst/util.py @@ -19,6 +19,7 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA. +import platform import random import os.path import re @@ -27,6 +28,8 @@ import libvirt from virtinst import _virtinst as _ +from virtinst import CapabilitiesParser + KEYBOARD_DIR = "/etc/sysconfig/keyboard" @@ -277,3 +280,18 @@ f.close() return keymap +def pygrub_path(conn=None): + """ + Return the pygrub path for the current host, or connection if + available. + """ + if conn: + cap = CapabilitiesParser.parse(conn.getCapabilities()) + if (cap.host.arch == "i86pc"): + return "/usr/lib/xen/bin/pygrub" + else: + return "/usr/bin/pygrub" + + if platform.system() == "SunOS": + return "/usr/lib/xen/bin/pygrub" + return "/usr/bin/pygrub" From john.levon at sun.com Thu Jul 10 13:48:31 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:31 -0700 Subject: [et-mgmt-tools] [PATCH 01 of 11] Modify VM name validation In-Reply-To: Message-ID: <8f7a10cd096ad71cf5e7.1215697711@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697436 25200 # Node ID 8f7a10cd096ad71cf5e7d414958a0db6c1b90e63 # Parent 0482bf130febcf585e1ac33dc8a3042c111b8587 Modify VM name validation There are .vmx files with dots in the VM names. Make the restrictions somewhat looser, and fix virt-image output to replace bad characters such as space. Signed-off-by: John Levon diff --git a/doc/image.rng b/doc/image.rng --- a/doc/image.rng +++ b/doc/image.rng @@ -236,7 +236,7 @@ - [a-zA-Z0-9_\+\-]+ + [A-Za-z0-9_.:/+-]+ diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -22,6 +22,8 @@ import virtconv.formats as formats import virtconv.vmcfg as vmcfg import virtconv.diskcfg as diskcfg + +import re pv_boot_template = """ @@ -108,6 +110,9 @@ if not vm.memory: raise ValueError("VM must have a memory setting") + # xend wants the name to match r'^[A-Za-z0-9_\-\.\:\/\+]+$' + vmname = re.sub(r'[^A-Za-z0-9_.:/+-]+', '_', vm.name) + pv_disks = [] hvm_disks = [] storage_disks = [] @@ -140,7 +145,7 @@ out = image_template % { "boot_template": boot_xml, - "name" : vm.name, + "name" : vmname, "description" : vm.description, "nr_vcpus" : vm.nr_vcpus, # Mb to Kb From john.levon at sun.com Thu Jul 10 13:48:32 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:32 -0700 Subject: [et-mgmt-tools] [PATCH 02 of 11] virt-convert: escape In-Reply-To: Message-ID: <8691412fa7603514b6c3.1215697712@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697436 25200 # Node ID 8691412fa7603514b6c321ec5b09729dedd88bed # Parent 8f7a10cd096ad71cf5e7d414958a0db6c1b90e63 virt-convert: escape Make sure to properly escape contents for XML metacharacters. Signed-off-by: John Levon diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -18,6 +18,7 @@ # MA 02110-1301 USA. # +from xml.sax.saxutils import escape from string import ascii_letters import virtconv.formats as formats import virtconv.vmcfg as vmcfg @@ -146,7 +147,7 @@ out = image_template % { "boot_template": boot_xml, "name" : vmname, - "description" : vm.description, + "description" : escape(vm.description), "nr_vcpus" : vm.nr_vcpus, # Mb to Kb "memory" : int(vm.memory) * 1024, From john.levon at sun.com Thu Jul 10 13:48:38 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:38 -0700 Subject: [et-mgmt-tools] [PATCH 08 of 11] virt-convert: implement network device handling In-Reply-To: Message-ID: <72eec78868efe7a872ea.1215697718@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697571 25200 # Node ID 72eec78868efe7a872eab6c08502b3b84bf00a46 # Parent 8ffd21ddf5c72ddbe8a30f65f0761e2f39705d57 virt-convert: implement network device handling Signed-off-by: John Levon diff --git a/virtconv/netdevcfg.py b/virtconv/netdevcfg.py new file mode 100644 --- /dev/null +++ b/virtconv/netdevcfg.py @@ -0,0 +1,39 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +NETDEV_TYPE_UNKNOWN = 0 +NETDEV_TYPE_BRIDGE = 1 +NETDEV_TYPE_DEV = 2 +NETDEV_TYPE_NETWORK = 3 + +class netdev(object): + """Definition of an individual network device.""" + + def __init__(self, mac = "auto", type = NETDEV_TYPE_UNKNOWN, + source = None, driver = None): + """@mac: either a MAC address, or "auto" + @type: NETDEV_TYPE_* + @source: bridge or net device, or network name + @driver: device emulated for VM (e.g. vmxnet) + """ + self.mac = mac + self.type = type + self.source = source + self.driver = driver diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -65,8 +65,8 @@ %(nr_vcpus)s %(memory)s - - + %(interface)s + @@ -185,6 +185,11 @@ # xend wants the name to match r'^[A-Za-z0-9_\-\.\:\/\+]+$' vmname = re.sub(r'[^A-Za-z0-9_.:/+-]+', '_', vm.name) + # Hmm. Any interface is a good interface? + interface = None + if len(vm.netdevs): + interface = "" + if vm.type == vmcfg.VM_TYPE_PV: boot_template = pv_boot_template else: @@ -204,6 +209,7 @@ "nr_vcpus" : vm.nr_vcpus, # Mb to Kb "memory" : int(vm.memory) * 1024, + "interface" : interface, "storage" : "".join(storage), } diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -21,9 +21,34 @@ import virtconv.formats as formats import virtconv.vmcfg as vmcfg import virtconv.diskcfg as diskcfg +import virtconv.netdevcfg as netdevcfg import re import os + +def parse_netdev_entry(vm, fullkey, value): + """ + Parse a particular key/value for a network. Throws ValueError. + """ + + _, _, inst, key = re.split("^(ethernet)([0-9]+).", fullkey) + + lvalue = value.lower() + + if key == "present" and lvalue == "false": + return + + if not vm.netdevs.get(inst): + vm.netdevs[inst] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) + + # "vlance", "vmxnet", "e1000" + if key == "virtualDev": + vm.netdevs[inst].driver = lvalue + if key == "addressType" and lvalue == "generated": + vm.netdevs[inst].mac = "auto" + # we ignore .generatedAddress for auto mode + if key == "address": + vm.netdevs[inst].mac = lvalue def parse_disk_entry(vm, fullkey, value): """ @@ -126,6 +151,8 @@ if key.startswith("scsi") or key.startswith("ide"): parse_disk_entry(vm, key, value) + if key.startswith("ethernet"): + parse_netdev_entry(vm, key, value) except: raise Exception("Syntax error at line %d: %s" % (line_nr + 1, line.strip())) diff --git a/virtconv/vmcfg.py b/virtconv/vmcfg.py --- a/virtconv/vmcfg.py +++ b/virtconv/vmcfg.py @@ -52,6 +52,7 @@ self.memory = None self.nr_vcpus = None self.disks = {} + self.netdevs = {} self.type = VM_TYPE_HVM self.arch = "i686" From john.levon at sun.com Thu Jul 10 13:48:35 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:35 -0700 Subject: [et-mgmt-tools] [PATCH 05 of 11] virt-convert: small cleanup fix In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215697490 25200 # Node ID f5e35abf05eb1fa3b64af2cf2cdcfc26139025fd # Parent af294fad5bde2b91640c55b8f279cbe8f9a41b37 virt-convert: small cleanup fix Only add the directory if we really did create it. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -176,8 +176,8 @@ options.output_dir = unixname try: logging.debug("Creating directory %s" % options.output_dir) + os.mkdir(options.output_dir) clean += [ options.output_dir ] - os.mkdir(options.output_dir) except OSError, e: if (e.errno != errno.EEXIST): logging.error("Could not create directory %s: %s" % From john.levon at sun.com Thu Jul 10 13:48:39 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:39 -0700 Subject: [et-mgmt-tools] [PATCH 09 of 11] virt-convert: Add OS variant options In-Reply-To: Message-ID: <443b42b45ee6f799020a.1215697719@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697571 25200 # Node ID 443b42b45ee6f799020a9418388440b93d9ab78c # Parent 72eec78868efe7a872eab6c08502b3b84bf00a46 virt-convert: Add OS variant options And use them to set ACPI, APIC, clock, and USB tablet. Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -185,6 +185,151 @@ .IP "\-q, \-\-quiet" 4 .IX Item "-q, --quiet" Avoid verbose output. +.IP "\-\-os\-type=OS_TYPE" 4 +.IX Item "--os-type=OS_TYPE" +Optimize the guest configuration for a type of operating system. This will +attempt to pick the most suitable \s-1ACPI\s0 & \s-1APIC\s0 settings, optimally supported +mouse drivers and generally accommodate other operating system quirks. The +valid operating system types are +.RS 4 +.IP "linux" 4 +.IX Item "linux" +Linux 2.x series +.IP "windows" 4 +.IX Item "windows" +Microsoft Windows 9x or later +.IP "unix" 4 +.IX Item "unix" +Traditional \s-1UNIX\s0 \s-1BSD\s0 or SysV derivatives +.IP "other" 4 +.IX Item "other" +Operating systems not in one of the 3 prior groups +.RE +.RS 4 +.RE +.IP "\-\-os\-variant=OS_VARIANT" 4 +.IX Item "--os-variant=OS_VARIANT" +Further optimize the guest configuration for a specific operating system +variant. This parameter is optional. The valid variants are +.RS 4 +.IP "linux" 4 +.IX Item "linux" +.RS 4 +.PD 0 +.IP "rhel2.1" 4 +.IX Item "rhel2.1" +.PD +Red Hat Enterprise Linux 2.1 +.IP "rhel3" 4 +.IX Item "rhel3" +Red Hat Enterprise Linux 3 +.IP "rhel4" 4 +.IX Item "rhel4" +Red Hat Enterprise Linux 4 +.IP "rhel5" 4 +.IX Item "rhel5" +Red Hat Enterprise Linux 5 +.IP "centos5" 4 +.IX Item "centos5" +Cent \s-1OS\s0 5 +.IP "fedora5" 4 +.IX Item "fedora5" +Fedora Core 5 +.IP "fedora6" 4 +.IX Item "fedora6" +Fedora Core 6 +.IP "fedora7" 4 +.IX Item "fedora7" +Fedora 7 +.IP "sles10" 4 +.IX Item "sles10" +Suse Linux Enterprise Server 10.x +.IP "debianEtch" 4 +.IX Item "debianEtch" +Debian 4.0 (Etch) +.IP "debianLenny" 4 +.IX Item "debianLenny" +Debian Lenny +.IP "generic26" 4 +.IX Item "generic26" +Generic Linux 2.6.x kernel +.IP "generic24" 4 +.IX Item "generic24" +Generic Linux 2.4.x kernel +.RE +.RS 4 +.RE +.IP "windows" 4 +.IX Item "windows" +.RS 4 +.PD 0 +.IP "winxp" 4 +.IX Item "winxp" +.PD +Microsoft Windows \s-1XP\s0 +.IP "win2k" 4 +.IX Item "win2k" +Microsoft Windows 2000 +.IP "win2k3" 4 +.IX Item "win2k3" +Microsoft Windows 2003 +.IP "vista" 4 +.IX Item "vista" +Microsoft Windows Vista +.RE +.RS 4 +.RE +.IP "unix" 4 +.IX Item "unix" +.RS 4 +.PD 0 +.IP "solaris9" 4 +.IX Item "solaris9" +.PD +Sun Solaris 9 +.IP "solaris10" 4 +.IX Item "solaris10" +Sun Solaris 10 +.IP "freebsd6" 4 +.IX Item "freebsd6" +Free \s-1BSD\s0 6.x +.IP "openbsd4" 4 +.IX Item "openbsd4" +Open \s-1BSD\s0 4.x +.RE +.RS 4 +.RE +.IP "other" 4 +.IX Item "other" +.RS 4 +.PD 0 +.IP "msdos" 4 +.IX Item "msdos" +.PD +Microsoft \s-1DOS\s0 +.IP "netware4" 4 +.IX Item "netware4" +Novell Netware 4 +.IP "netware5" 4 +.IX Item "netware5" +Novell Netware 5 +.IP "netware6" 4 +.IX Item "netware6" +Novell Netware 6 +.RE +.RS 4 +.RE +.RE +.RS 4 +.RE +.IP "\-\-noapic" 4 +.IX Item "--noapic" +Override the \s-1OS\s0 type / variant to disables the \s-1APIC\s0 setting for fully +virtualized guest. +.IP "\-\-noacpi" 4 +.IX Item "--noacpi" +Override the \s-1OS\s0 type / variant to disables the \s-1ACPI\s0 setting for fully +virtualized guest. .SH "EXAMPLES" .IX Header "EXAMPLES" Convert a paravirt guest from \f(CW\*(C`image.vmx\*(C'\fR: diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -71,6 +71,176 @@ Avoid verbose output. +=item --os-type=OS_TYPE + +Optimize the guest configuration for a type of operating system. This will +attempt to pick the most suitable ACPI & APIC settings, optimally supported +mouse drivers and generally accommodate other operating system quirks. The +valid operating system types are + +=over 4 + +=item linux + +Linux 2.x series + +=item windows + +Microsoft Windows 9x or later + +=item unix + +Traditional UNIX BSD or SysV derivatives + +=item other + +Operating systems not in one of the 3 prior groups + +=back + +=item --os-variant=OS_VARIANT + +Further optimize the guest configuration for a specific operating system +variant. This parameter is optional. The valid variants are + +=over 4 + +=item linux + +=over 4 + +=item rhel2.1 + +Red Hat Enterprise Linux 2.1 + +=item rhel3 + +Red Hat Enterprise Linux 3 + +=item rhel4 + +Red Hat Enterprise Linux 4 + +=item rhel5 + +Red Hat Enterprise Linux 5 + +=item centos5 + +Cent OS 5 + +=item fedora5 + +Fedora Core 5 + +=item fedora6 + +Fedora Core 6 + +=item fedora7 + +Fedora 7 + +=item sles10 + +Suse Linux Enterprise Server 10.x + +=item debianEtch + +Debian 4.0 (Etch) + +=item debianLenny + +Debian Lenny + +=item generic26 + +Generic Linux 2.6.x kernel + +=item generic24 + +Generic Linux 2.4.x kernel + +=back + +=item windows + +=over 4 + +=item winxp + +Microsoft Windows XP + +=item win2k + +Microsoft Windows 2000 + +=item win2k3 + +Microsoft Windows 2003 + +=item vista + +Microsoft Windows Vista + +=back + +=item unix + +=over 4 + +=item solaris9 + +Sun Solaris 9 + +=item solaris10 + +Sun Solaris 10 + +=item freebsd6 + +Free BSD 6.x + +=item openbsd4 + +Open BSD 4.x + +=back + +=item other + +=over 4 + +=item msdos + +Microsoft DOS + +=item netware4 + +Novell Netware 4 + +=item netware5 + +Novell Netware 5 + +=item netware6 + +Novell Netware 6 + +=back + +=back + +=item --noapic + +Override the OS type / variant to disables the APIC setting for fully +virtualized guest. + +=item --noacpi + +Override the OS type / variant to disables the ACPI setting for fully +virtualized guest. + =back =head1 EXAMPLES diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -59,6 +59,16 @@ help=("This guest should be a fully virtualized guest")) opts.add_option("-p", "--paravirt", action="store_true", dest="paravirt", help=("This guest should be a paravirtualized guest")) + opts.add_option("", "--os-type", type="string", dest="os_type", + action="callback", callback=cli.check_before_store, + help=("The OS type for fully virtualized guests, e.g. 'linux', 'unix', 'windows'")) + opts.add_option("", "--os-variant", type="string", dest="os_variant", + action="callback", callback=cli.check_before_store, + help=("The OS variant for fully virtualized guests, e.g. 'fedora6', 'rhel5', 'solaris10', 'win2k', 'vista'")) + opts.add_option("", "--noapic", action="store_true", dest="noapic", + help=("Disables APIC for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) + opts.add_option("", "--noacpi", action="store_true", dest="noacpi", + help=("Disables ACPI for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) (options, args) = opts.parse_args() if len(args) < 1: @@ -165,6 +175,10 @@ vmdef.type = vmcfg.VM_TYPE_HVM vmdef.arch = options.arch + vmdef.os_type = options.os_type + vmdef.os_variant = options.os_variant + vmdef.noapic = options.noapic + vmdef.noacpi = options.noacpi clean = [] diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -18,12 +18,13 @@ # MA 02110-1301 USA. # -from xml.sax.saxutils import escape -from string import ascii_letters import virtconv.formats as formats import virtconv.vmcfg as vmcfg import virtconv.diskcfg as diskcfg +import virtinst.FullVirtGuest as fv +from xml.sax.saxutils import escape +from string import ascii_letters import re pv_boot_template = """ @@ -31,6 +32,8 @@ %(arch)s + %(acpi)s + %(apic)s @@ -74,6 +77,37 @@ """ + +def export_os_params(vm): + """ + Export OS-specific parameters. + """ + ostype = None + osvariant = None + + ostype = fv.OS_TYPES.get(vm.os_type) + if ostype: + osvariant = ostype.variants.get(vm.os_variant) + + def get_os_val(key, default): + val = None + if osvariant: + val = osvariant.get(key) + if not val and ostype: + val = ostype.get(key) + if not val: + val = default + return val + + acpi = "" + if vm.noacpi is False and get_os_val("acpi", True): + acpi = "" + + apic = "" + if vm.noapic is False and get_os_val("apic", False): + apic = "" + + return acpi, apic def export_disks(vm): """ @@ -190,6 +224,8 @@ if len(vm.netdevs): interface = "" + acpi, apic = export_os_params(vm) + if vm.type == vmcfg.VM_TYPE_PV: boot_template = pv_boot_template else: @@ -200,6 +236,8 @@ boot_xml = boot_template % { "disks" : "".join(disks), "arch" : vm.arch, + "acpi" : acpi, + "apic" : apic, } out = image_template % { diff --git a/virtconv/vmcfg.py b/virtconv/vmcfg.py --- a/virtconv/vmcfg.py +++ b/virtconv/vmcfg.py @@ -55,6 +55,10 @@ self.netdevs = {} self.type = VM_TYPE_HVM self.arch = "i686" + self.noacpi = None + self.noapic = None + self.os_type = None + self.os_variant = None def validate(self): """ From john.levon at sun.com Thu Jul 10 13:48:41 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:41 -0700 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: Message-ID: <112cd8c4aa97e9da9d75.1215697721@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697572 25200 # Node ID 112cd8c4aa97e9da9d7532fee7d826d35e1003e8 # Parent 92de696f634f80d47b9413b9db5101de0edf9b7f virt-convert: Add "virt-instance" formatter. Allow output in libvirt.rng format Signed-off-by: John Levon diff --git a/man/en/virt-convert.1 b/man/en/virt-convert.1 --- a/man/en/virt-convert.1 +++ b/man/en/virt-convert.1 @@ -174,7 +174,8 @@ Input format. Currently, \f(CW\*(C`vmx\*(C'\fR is the only supported input format. .IP "\-o format" 4 .IX Item "-o format" -Output format. Currently, \f(CW\*(C`virt\-image\*(C'\fR is the only supported output format. +Output format. Currently, the only supported outputs are \f(CW\*(C`virt\-image\*(C'\fR +and \f(CW\*(C`virt\-instance\*(C'\fR. .IP "\-D format" 4 .IX Item "-D format" Output disk format, or \f(CW\*(C`none\*(C'\fR if no conversion should be performed. See diff --git a/man/en/virt-convert.pod b/man/en/virt-convert.pod --- a/man/en/virt-convert.pod +++ b/man/en/virt-convert.pod @@ -56,7 +56,8 @@ =item -o format -Output format. Currently, C is the only supported output format. +Output format. Currently, the only supported outputs are C +and C. =item -D format diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -156,10 +156,10 @@ inp = formats.parser_by_name(options.input_format) outp = formats.parser_by_name(options.output_format) - vmdef = None + vmdef = vmcfg.vm(options.arch, options.paravirt) try: - vmdef = inp.import_file(options.input_file) + inp.import_file(options.input_file, vmdef) except IOError, e: logging.error("Couldn't import file \"%s\": %s" % (options.input_file, e.strerror)) @@ -169,12 +169,6 @@ (options.input_file, e.message)) sys.exit(1) - if options.paravirt: - vmdef.type = vmcfg.VM_TYPE_PV - else: - vmdef.type = vmcfg.VM_TYPE_HVM - - vmdef.arch = options.arch vmdef.os_type = options.os_type vmdef.os_variant = options.os_variant vmdef.noapic = options.noapic diff --git a/virtconv/formats.py b/virtconv/formats.py --- a/virtconv/formats.py +++ b/virtconv/formats.py @@ -39,7 +39,7 @@ raise NotImplementedError @staticmethod - def import_file(input_file): + def import_file(input_file, vm): """ Import a configuration file. Raises if the file couldn't be opened, or parsing otherwise failed. diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -195,7 +195,7 @@ raise NotImplementedError @staticmethod - def import_file(input_file): + def import_file(input_file, vm): """ Import a configuration file. Raises if the file couldn't be opened, or parsing otherwise failed. diff --git a/virtconv/parsers/virtinstance.py b/virtconv/parsers/virtinstance.py new file mode 100644 --- /dev/null +++ b/virtconv/parsers/virtinstance.py @@ -0,0 +1,370 @@ +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA. +# + +from string import ascii_letters +import virtconv.vmcfg as vmcfg +import virtconv.diskcfg as diskcfg +import virtconv.netdevcfg as netdevcfg +import virtconv.formats as formats +import virtinst.FullVirtGuest as fv + +import os +import stat +import re + +bootdevs = { + vmcfg.VM_TYPE_PV: "", + vmcfg.VM_TYPE_HVM: "", +} + +consoles = { + vmcfg.VM_TYPE_PV: "", + vmcfg.VM_TYPE_HVM: "", +} + +disk_template = """ + + %(hostdev)s + + %(readonly)s + +""" + +netdev_template = """ + + %(source)s + %(mac)s + %(model)s + +""" + +instance_template = """ + + %(name)s + %(bootloader)s + + %(type)s + %(loader)s + %(bootdev)s + + %(memory)s + %(nr_vcpus)s + destroy + restart + restart + + + %(acpi)s + %(apic)s + + + + %(emulator)s + %(disks)s + %(netdevs)s + + + %(usbtablet)s + %(console)s + + +""" + +def export_netdevs(vm): + """ + Export code for the network devices. + """ + + netdevs = [] + + for netdev in vm.netdevs.values(): + mac = "" + if netdev.mac != "auto": + mac = "" % netdev.mac + + nettype = { + netdevcfg.NETDEV_TYPE_DEV : "ethernet", + netdevcfg.NETDEV_TYPE_BRIDGE : "bridge", + netdevcfg.NETDEV_TYPE_UNKNOWN : "bridge", + netdevcfg.NETDEV_TYPE_NETWORK : "network", + }.get(netdev.type) + + source = "" + if netdev.source: + srcattr = nettype + if netdev.type == netdevcfg.NETDEV_TYPE_DEV: + srcattr = "dev" + source = "" % (srcattr, netdev.source) + + # FIXME: should warn here + if not nettype: + continue + + model = "" + if netdev.driver: + model = "" % netdev.driver + + netdevs.append(netdev_template % { + "type" : nettype, + "source" : source, + "mac" : mac, + "model": model, + }) + + return netdevs + +def export_disks(vm): + """ + Export code for the disks. Slightly tricky for two reasons. + + We can't handle duplicate disks: some vmx files define SCSI/IDE devices + that point to the same storage, and Xen isn't happy about that. We + just ignore any entries that have duplicate paths. + + Since there is no meaningful SCSI support in rombios/qemu, we + forcibly switch the disks to IDE, and expect the guest OS to cope + (which at least Linux does admirably). + """ + + out = [] + paths = [] + + disks = {} + + for (bus, instance), disk in sorted(vm.disks.iteritems()): + + if disk.path and disk.path in paths: + continue + + if bus == "scsi": + instance = 0 + while disks.get(("ide", instance)): + instance += 1 + + disks[("ide", instance)] = disk + + if disk.path: + paths += [ disk.path ] + + for (bus, instance), disk in sorted(disks.iteritems()): + + if not disk.path: + typeattr = "" + hostdev = "" + + # It's quite common for .vmx files to reference a + # non-existent ISO (which was cleaned up in vmx_parser). + # Just skip them. + if disk.type == diskcfg.DISK_TYPE_ISO: + continue + else: + # Of course, this file path might be relative, so we won't be + # able to stat() it. In such a case, it's almost certainly a + # file anyway, so the fallback is fine. + typeattr = "type='file'" + hostdev = ("\n" + "\n" % disk.path) + + try: + if stat.S_ISBLK(os.stat(disk.path)[0]): + typeattr = "type='block'" + hostdev = ("\n" + "\n" % disk.path) + except: + pass + + if disk.format == diskcfg.DISK_FORMAT_VDISK: + hostdev = ("\n" + "\n" % disk.path) + + device = "disk" + readonly = "" + + if (disk.type == diskcfg.DISK_TYPE_CDROM or + disk.type == diskcfg.DISK_TYPE_ISO): + device = "cdrom" + readonly = "" + + bus = "ide" + + disk_prefix = "xvd" + if vm.type == vmcfg.VM_TYPE_HVM: + if bus == "ide": + disk_prefix = "hd" + else: + disk_prefix = "sd" + + # FIXME: needs updating for later Xen enhancements; need to + # implement capabilities checking for max disks etc. + drive_nr = ascii_letters[int(instance) % 26] + + instance += 1 + + out.append(disk_template % { + "typeattr" : typeattr, + "device" : device, + "hostdev" : hostdev, + "prefix" : disk_prefix, + "dev" : drive_nr, + "readonly" : readonly, + }) + + return out + +def export_os_params(vm): + """ + Export OS-specific parameters. + """ + ostype = None + osvariant = None + + ostype = fv.OS_TYPES.get(vm.os_type) + if ostype: + osvariant = ostype.variants.get(vm.os_variant) + + def get_os_val(key, default): + val = None + if osvariant: + val = osvariant.get(key) + if not val and ostype: + val = ostype.get(key) + if not val: + val = default + return val + + acpi = "" + if vm.noacpi is False and get_os_val("acpi", True): + acpi = "" + + apic = "" + if vm.noapic is False and get_os_val("apic", False): + apic = "" + + clock = get_os_val("clock", "utc") + + usbtablet = "" + if get_os_val("input", [ "tablet", "usb" ])[0] == "tablet": + usbtablet = "" + + return acpi, apic, clock, usbtablet + + +class virtinstance_parser(formats.parser): + """ + Support for libvirt's domain instance format as defined (mostly) by + libvirt.rng. Currently, this only produces domains for Xen. + + This is a somewhat challenging format as it encodes significant + amounts of information specific to a particular platform (for + example, the pygrub path. For now, we'll assume it's for the current + platform. Later, we'd take an optional hypervisor connection. + + Known limitations: + + - Only handles bridge, ethernet, and network type netdevs + - doesn't handle netdev script or IP address + """ + + name = "virt-instance" + suffix = ".virt-instance.xml" + can_import = False + can_export = True + can_identify = False + + @staticmethod + def identify_file(input_file): + """ + Return True if the given file is of this format. + """ + raise NotImplementedError + + @staticmethod + def import_file(input_file, vm): + """ + Import a configuration file. Raises if the file couldn't be + opened, or parsing otherwise failed. + """ + raise NotImplementedError + + @staticmethod + def export_file(vm, output_file): + """ + Export a configuration file. + @vm vm configuration instance + @file Output file + + Raises ValueError if configuration is not suitable, or another + exception on failure to write the output file. + """ + + if not vm.memory: + raise ValueError("VM must have a memory setting") + + # xend wants the name to match r'^[A-Za-z0-9_\-\.\:\/\+]+$' + vmname = re.sub(r'[^A-Za-z0-9_.:/+-]+', '_', vm.name) + + vmtype = "xen" + if vm.type == vmcfg.VM_TYPE_HVM: + vmtype = "hvm" + + emulator = vm.emulator() + bootloader = "" + loader = vm.loader() + + if vm.type == vmcfg.VM_TYPE_PV: + bootloader = loader + loader = "" + + if bootloader: + bootloader = "%s" % bootloader + if emulator: + emulator = "%s" % emulator + if loader: + loader = "%s" % loader + + netdevs = export_netdevs(vm) + disks = export_disks(vm) + + acpi, apic, clock, usbtablet = export_os_params(vm) + + out = instance_template % { + "name" : vmname, + "bootloader" : bootloader, + "type" : vmtype, + "loader" : loader, + "bootdev" : bootdevs[vm.type], + # Mb to Kb + "memory" : int(vm.memory) * 1024, + "nr_vcpus" : vm.nr_vcpus, + "clock" : clock, + "acpi" : acpi, + "apic" : apic, + "emulator" : emulator, + "disks" : "".join(disks), + "netdevs" : "".join(netdevs), + "usbtablet" : usbtablet, + "console" : consoles[vm.type], + } + + outfile = open(output_file, "w") + outfile.writelines(out) + outfile.close() + +formats.register_parser(virtinstance_parser) diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -118,13 +118,11 @@ return re.match(r'^#!\s*/usr/bin/vm(ware|player)', line) is not None @staticmethod - def import_file(input_file): + def import_file(input_file, vm): """ Import a configuration file. Raises if the file couldn't be opened, or parsing otherwise failed. """ - - vm = vmcfg.vm() infile = open(input_file, "r") contents = infile.readlines() @@ -175,7 +173,6 @@ vm.nr_vcpus = config.get("numvcpus") vm.validate() - return vm @staticmethod def export_file(vm, output_file): diff --git a/virtconv/vmcfg.py b/virtconv/vmcfg.py --- a/virtconv/vmcfg.py +++ b/virtconv/vmcfg.py @@ -21,6 +21,7 @@ import platform from virtconv import diskcfg from virtinst import CapabilitiesParser +from virtinst import util VM_TYPE_UNKNOWN = 0 VM_TYPE_PV = 1 @@ -46,19 +47,21 @@ name = None suffix = None - def __init__(self): + def __init__(self, arch, is_pv): self.name = None self.description = None self.memory = None self.nr_vcpus = None self.disks = {} self.netdevs = {} - self.type = VM_TYPE_HVM - self.arch = "i686" + self.arch = arch self.noacpi = None self.noapic = None self.os_type = None self.os_variant = None + self.type = VM_TYPE_HVM + if is_pv: + self.type = VM_TYPE_PV def validate(self): """ @@ -82,6 +85,41 @@ raise ValueError("Disk %s:%s storage does not exist" % (bus, inst)) + def emulator(self, conn=None): + """ + Return the emulator path for this VM. + """ + typename = "xen" + if self.type == VM_TYPE_HVM: + typename = "hvm" + + if conn: + caps = CapabilitiesParser.parse(conn.getCapabilities()) + guest = caps.guestForOSType(typename, self.arch) + if guest and len(guest.domains): + return guest.domains[0].emulator + + if self.type == VM_TYPE_PV: + return "" + return util.default_emulator() + + def loader(self, conn=None): + """ + Return the loader path for this VM. + """ + + # loader is not set for PV in capabilities + if self.type == VM_TYPE_PV: + return util.pygrub_path(conn) + + if conn: + caps = CapabilitiesParser.parse(conn.getCapabilities()) + guest = caps.guestForOSType("hvm", self.arch) + if guest and len(guest.domains): + return guest.domains[0].loader + + return util.default_loader() + def host(conn=None): """ Return the host, as seen in platform.system(), but possibly from a diff --git a/virtinst/FullVirtGuest.py b/virtinst/FullVirtGuest.py --- a/virtinst/FullVirtGuest.py +++ b/virtinst/FullVirtGuest.py @@ -124,13 +124,10 @@ self.arch = arch if emulator is None: if self.type == "xen": - if os.uname()[4] in ("x86_64"): - emulator = "/usr/lib64/xen/bin/qemu-dm" - else: - emulator = "/usr/lib/xen/bin/qemu-dm" + emulator = util.default_emulator() self.emulator = emulator if self.type == "xen": - self.loader = "/usr/lib/xen/boot/hvmloader" + self.loader = util.default_loader() else: self.loader = None self._os_type = None diff --git a/virtinst/util.py b/virtinst/util.py --- a/virtinst/util.py +++ b/virtinst/util.py @@ -295,3 +295,13 @@ if platform.system() == "SunOS": return "/usr/lib/xen/bin/pygrub" return "/usr/bin/pygrub" + +def default_emulator(): + """Return a default emulator for a domain.""" + if os.uname()[4] in ("x86_64"): + return "/usr/lib64/xen/bin/qemu-dm" + return "/usr/lib/xen/bin/qemu-dm" + +def default_loader(): + """Return a default loader for a domain.""" + return "/usr/lib/xen/boot/hvmloader" From john.levon at sun.com Thu Jul 10 13:48:30 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:30 -0700 Subject: [et-mgmt-tools] [PATCH 00 of 11] More virt-convert fixes Message-ID: More fixes. Some of these you've seen before, though they're mostly much better tested now. Signed-off-by: John Levon From john.levon at sun.com Thu Jul 10 13:48:34 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:34 -0700 Subject: [et-mgmt-tools] [PATCH 04 of 11] virt-convert: Fix PV install In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215697436 25200 # Node ID af294fad5bde2b91640c55b8f279cbe8f9a41b37 # Parent a4920bf6af2fa78e7797d971f92e416fd78af0ca virt-convert: Fix PV install Need to fix a test that was triggering as VM_TYPE_PV was zero. Signed-off-by: John Levon diff --git a/virtconv/vmcfg.py b/virtconv/vmcfg.py --- a/virtconv/vmcfg.py +++ b/virtconv/vmcfg.py @@ -18,8 +18,9 @@ # MA 02110-1301 USA. # -VM_TYPE_PV = 0 -VM_TYPE_HVM = 1 +VM_TYPE_UNKNOWN = 0 +VM_TYPE_PV = 1 +VM_TYPE_HVM = 2 class vm(object): """ @@ -62,7 +63,7 @@ self.description = "" if not self.nr_vcpus: self.nr_vcpus = 1 - if not self.type: + if self.type == VM_TYPE_UNKNOWN: raise ValueError("VM type is not set") if not self.arch: raise ValueError("VM arch is not set") From john.levon at sun.com Thu Jul 10 13:48:33 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:33 -0700 Subject: [et-mgmt-tools] [PATCH 03 of 11] virt-install: fix a typo In-Reply-To: Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1215697436 25200 # Node ID a4920bf6af2fa78e7797d971f92e416fd78af0ca # Parent 8691412fa7603514b6c321ec5b09729dedd88bed virt-install: fix a typo Fix a mis-indentation and typo that pylint noticed. Signed-off-by: John Levon diff --git a/virtinst/util.py b/virtinst/util.py --- a/virtinst/util.py +++ b/virtinst/util.py @@ -274,6 +274,6 @@ keymap = keytable.keytable[kt] else: logging.debug("Didn't find keymap '%s' in keytable!" % kt) - f.close + f.close() return keymap From john.levon at sun.com Thu Jul 10 13:48:37 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:37 -0700 Subject: [et-mgmt-tools] [PATCH 07 of 11] virt-convert: improve disk handling In-Reply-To: Message-ID: <8ffd21ddf5c72ddbe8a3.1215697717@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697571 25200 # Node ID 8ffd21ddf5c72ddbe8a30f65f0761e2f39705d57 # Parent 91d463e8e9921844271a90f416e0e6d94fd2af40 virt-convert: improve disk handling A whole bunch of fixes for more accurate disk handling. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -25,7 +25,6 @@ import os import logging import errno -import platform from optparse import OptionParser import virtinst.cli as cli @@ -125,15 +124,15 @@ logging.error(msg) try: + for disk in vmdef.disks.values(): + disk.cleanup() + paths.reverse() for path in paths: if os.path.isdir(path): os.rmdir(path) elif os.path.isfile(path): os.remove(path) - - for disk in vmdef.disks: - disk.cleanup() except OSError, e: logging.error("Couldn't clean up output directory \"%s\": %s" % (options.output_dir, e.strerror)) @@ -196,18 +195,18 @@ (options.output_format, options.output_dir)) try: - for d in vmdef.disks: + for d in vmdef.disks.values(): format = options.disk_format - # no auto-conversion on Solaris for VMDK disks + # VMDK disks on Solaris converted to vdisk by default if (d.format == diskcfg.DISK_FORMAT_VMDK and - not format and platform.system() == "SunOS"): - continue + not format and vmcfg.host() == "SunOS"): + format = "vdisk" if not format: format = "raw" - if format != "none": + if d.path and format != "none": verbose(options, "Converting disk \"%s\" to type %s..." % (d.path, format)) diff --git a/virtconv/diskcfg.py b/virtconv/diskcfg.py --- a/virtconv/diskcfg.py +++ b/virtconv/diskcfg.py @@ -64,11 +64,10 @@ class disk(object): """Definition of an individual disk instance.""" - def __init__(self, path = None, number = 0, format = None, bus = "ide", + def __init__(self, path = None, format = None, bus = "ide", type = DISK_TYPE_DISK): self.path = path self.format = format - self.number = number self.bus = bus self.type = type self.clean = [] @@ -140,6 +139,9 @@ failures. """ + if self.type != DISK_TYPE_DISK: + return + out_format = disk_format_names[output_format] indir = os.path.normpath(os.path.abspath(indir)) outdir = os.path.normpath(os.path.abspath(outdir)) @@ -160,11 +162,13 @@ convert_cmd = ("""/usr/bin/vdiskadm import -t %s "%s" "%s" """ % (qemu_formats[out_format], absin, absout)) elif out_format == DISK_FORMAT_RAW: - convert_cmd = ("""qemu-img convert "%s" -O %s "%s" """ % - (absin, qemu_formats[out_format], absout)) + convert_cmd = ("""qemu-img convert -O %s "%s" "%s" """ % + (qemu_formats[out_format], absin, absout)) else: raise NotImplementedError("Cannot convert to disk format %s" % output_format) + + self.clean += [ absout ] ret = os.system(convert_cmd) if ret != 0: diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -37,7 +37,7 @@ pygrub - %(pv_disks)s + %(disks)s """ @@ -49,7 +49,7 @@ - %(hvm_disks)s + %(disks)s """ @@ -74,6 +74,74 @@ """ + +def export_disks(vm): + """ + Export code for the disks. Slightly tricky for two reasons. + + We can't handle duplicate disks: some vmx files define SCSI/IDE devices + that point to the same storage, and Xen isn't happy about that. We + just ignore any entries that have duplicate paths. + + Since there is no SCSI support in rombios, and the SCSI emulation is + troublesome with Solaris, we forcibly switch the disks to IDE, and expect + the guest OS to cope (which at least Linux does admirably). + + Note that we even go beyond hdd: above that work if the domU has PV + drivers. + """ + + paths = [] + + disks = {} + + for (bus, instance), disk in sorted(vm.disks.iteritems()): + + if disk.path and disk.path in paths: + continue + + if bus == "scsi": + instance = 0 + while disks.get(("ide", instance)): + instance += 1 + + disks[("ide", instance)] = disk + + if disk.path: + paths += [ disk.path ] + + diskout = [] + storage = [] + + for (bus, instance), disk in sorted(disks.iteritems()): + + # virt-image XML cannot handle an empty CD device + if not disk.path: + continue + + path = disk.path + drive_nr = ascii_letters[int(instance) % 26] + + disk_prefix = "xvd" + if vm.type == vmcfg.VM_TYPE_HVM: + if bus == "ide": + disk_prefix = "hd" + else: + disk_prefix = "sd" + + # FIXME: needs updating for later Xen enhancements; need to + # implement capabilities checking for max disks etc. + diskout.append("""\n""" % + (path, disk_prefix, drive_nr)) + + type = "raw" + if disk.type == diskcfg.DISK_TYPE_ISO: + type = "iso" + storage.append( + """\n""" % + (path, type)) + + return storage, diskout class virtimage_parser(formats.parser): """ @@ -117,33 +185,15 @@ # xend wants the name to match r'^[A-Za-z0-9_\-\.\:\/\+]+$' vmname = re.sub(r'[^A-Za-z0-9_.:/+-]+', '_', vm.name) - pv_disks = [] - hvm_disks = [] - storage_disks = [] - - # create disk filename lists for xml template - for disk in vm.disks: - number = disk.number - path = disk.path - - # FIXME: needs updating for later Xen enhancements; need to - # implement capabilities checking for max disks etc. - pv_disks.append("""\n""" % - (path, ascii_letters[number % 26])) - hvm_disks.append("""\n""" % - (path, ascii_letters[number % 26])) - storage_disks.append( - """\n""" - % (path, diskcfg.qemu_formats[disk.format])) - if vm.type == vmcfg.VM_TYPE_PV: boot_template = pv_boot_template else: boot_template = hvm_boot_template + (storage, disks) = export_disks(vm) + boot_xml = boot_template % { - "pv_disks" : "".join(pv_disks), - "hvm_disks" : "".join(hvm_disks), + "disks" : "".join(disks), "arch" : vm.arch, } @@ -154,7 +204,7 @@ "nr_vcpus" : vm.nr_vcpus, # Mb to Kb "memory" : int(vm.memory) * 1024, - "storage" : "".join(storage_disks), + "storage" : "".join(storage), } outfile = open(output_file, "w") diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -23,6 +23,47 @@ import virtconv.diskcfg as diskcfg import re +import os + +def parse_disk_entry(vm, fullkey, value): + """ + Parse a particular key/value for a disk. FIXME: this should be a + lot smarter. + """ + + # skip bus values, e.g. 'scsi0.present = "TRUE"' + if re.match(r"^(scsi|ide)[0-9]+[^:]", fullkey): + return + + _, bus, bus_nr, inst, key = re.split(r"^(scsi|ide)([0-9]+):([0-9]+)\.", + fullkey) + + lvalue = value.lower() + + if key == "present" and lvalue == "false": + return + + # Does anyone else think it's scary that we're still doing things + # like this? + if bus == "ide": + inst = int(inst) + int(bus_nr) * 2 + + devid = (bus, inst) + if not vm.disks.get(devid): + vm.disks[devid] = diskcfg.disk(bus = bus, + type = diskcfg.DISK_TYPE_DISK) + + if key == "deviceType": + if lvalue == "atapi-cdrom" or lvalue == "cdrom-raw": + vm.disks[devid].type = diskcfg.DISK_TYPE_CDROM + elif lvalue == "cdrom-image": + vm.disks[devid].type = diskcfg.DISK_TYPE_ISO + + if key == "fileName": + vm.disks[devid].path = value + vm.disks[devid].format = diskcfg.DISK_FORMAT_RAW + if lvalue.endswith(".vmdk"): + vm.disks[devid].format = diskcfg.DISK_FORMAT_VMDK class vmx_parser(formats.parser): """ @@ -74,22 +115,29 @@ lines.append(line) config = {} - disks = [] # split out all remaining entries of key = value form for (line_nr, line) in enumerate(lines): try: before_eq, after_eq = line.split("=", 1) - key = before_eq.replace(" ","") - value = after_eq.replace('"',"") - value = value.strip() + key = before_eq.strip() + value = after_eq.strip().strip('"') config[key] = value - # FIXME: this should probably be a lot smarter. - if value.endswith(".vmdk"): - disks += [ value ] + + if key.startswith("scsi") or key.startswith("ide"): + parse_disk_entry(vm, key, value) except: raise Exception("Syntax error at line %d: %s" % (line_nr + 1, line.strip())) + + for devid, disk in vm.disks.iteritems(): + if disk.type == diskcfg.DISK_TYPE_DISK: + continue + + # vmx files often have dross left in path for CD entries + if (disk.path == "auto detect" or + not os.path.exists(disk.path)): + vm.disks[devid].path = None if not config.get("displayName"): raise ValueError("No displayName defined in \"%s\"" % input_file) @@ -98,10 +146,7 @@ vm.memory = config.get("memsize") vm.description = config.get("annotation") vm.nr_vcpus = config.get("numvcpus") - - for (number, path) in enumerate(disks): - vm.disks += [ diskcfg.disk(path, number, diskcfg.DISK_FORMAT_VMDK) ] - + vm.validate() return vm diff --git a/virtconv/vmcfg.py b/virtconv/vmcfg.py --- a/virtconv/vmcfg.py +++ b/virtconv/vmcfg.py @@ -17,6 +17,10 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA. # + +import platform +from virtconv import diskcfg +from virtinst import CapabilitiesParser VM_TYPE_UNKNOWN = 0 VM_TYPE_PV = 1 @@ -47,7 +51,7 @@ self.description = None self.memory = None self.nr_vcpus = None - self.disks = [ ] + self.disks = {} self.type = VM_TYPE_HVM self.arch = "i686" @@ -67,3 +71,25 @@ raise ValueError("VM type is not set") if not self.arch: raise ValueError("VM arch is not set") + + for (bus, inst), disk in sorted(self.disks.iteritems()): + if disk.type == diskcfg.DISK_TYPE_DISK and not disk.path: + raise ValueError("Disk %s:%s storage does not exist" + % (bus, inst)) + +def host(conn=None): + """ + Return the host, as seen in platform.system(), but possibly from a + hypervisor connection. Note: use default_arch() in almost all + cases, unless you need to detect the OS. In particular, this value + gives no indication of 32 vs 64 bitness. + """ + if conn: + cap = CapabilitiesParser.parse(conn.getCapabilities()) + if cap.host.arch == "i86pc": + return "SunOS" + else: + # or Linux-alike. Hmm. + return "Linux" + + return platform.system() From john.levon at sun.com Thu Jul 10 13:48:36 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 10 Jul 2008 06:48:36 -0700 Subject: [et-mgmt-tools] [PATCH 06 of 11] virt-convert: add format detection In-Reply-To: Message-ID: <91d463e8e9921844271a.1215697716@joos> # HG changeset patch # User john.levon at sun.com # Date 1215697570 25200 # Node ID 91d463e8e9921844271a90f416e0e6d94fd2af40 # Parent f5e35abf05eb1fa3b64af2cf2cdcfc26139025fd virt-convert: add format detection Add format detection, along with detection for VMX Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -1,9 +1,10 @@ #!/usr/bin/python -# -# Convert a VMware(tm) virtual machine into an XML image description # # Copyright 2008 Red Hat, Inc. # Joey Boggs +# +# Copyright 2008 Sun Microsystems, Inc. All rights reserved. +# Use is subject to license terms. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -49,8 +50,7 @@ opts.add_option("-d", "--debug", action="store_true", dest="debug", help=("Print debugging information")) opts.add_option("-i", "--input-format", action="store", - dest="input_format", default="vmx", - help=("Input format, e.g. 'vmx'")) + dest="input_format", help=("Input format, e.g. 'vmx'")) opts.add_option("-o", "--output-format", action="store", dest="output_format", default="virt-image", help=("Output format, e.g. 'virt-image'")) @@ -71,35 +71,45 @@ options.disk_format not in diskcfg.disk_formats()): opts.error("Unknown output disk format \"%s\"" % options.disk_format) - # hard-code for now - if options.input_format != "vmx": - opts.error(("Unsupported input format \"%s\"" % options.input_format)) - if options.output_format != "virt-image": - opts.error(("Unsupported output format \"%s\"" - % options.output_format)) - if os.path.isdir(args[0]): - vmx_files = [x for x in os.listdir(args[0]) if x.endswith(".vmx") ] - if (len(vmx_files)) == 0: - opts.error(("No VM definition file was found in %s" % args[0])) - if (len(vmx_files)) > 1: - opts.error(("Too many .vmx definitions found in %s" % args[0])) - options.input_file = os.path.join(args[0], vmx_files[0]) - options.input_dir = args[0] - else: - options.input_file = args[0] - options.input_dir = os.path.dirname(os.path.realpath(args[0])) - if len(args) == 1: options.output_file = None options.output_dir = None if os.path.isdir(args[0]): - options.output_dir = options.input_dir + options.output_dir = args[0] elif os.path.isdir(args[1]) or args[1].endswith("/"): options.output_file = None options.output_dir = args[1] else: options.output_file = args[1] options.output_dir = os.path.dirname(os.path.realpath(args[1])) + + if options.output_format not in formats.formats(): + opts.error(("Unknown output format \"%s\"" % options.output_format)) + if options.output_format not in formats.output_formats(): + opts.error(("No output handler for format \"%s\"" + % options.output_format)) + + if not options.input_format: + try: + (args[0], options.input_format) = formats.find_input(args[0]) + except StandardError, e: + opts.error("Couldn't determine input format for \"%s\": %s" % + (args[0], e.message)) + sys.exit(1) + + if options.input_format not in formats.formats(): + opts.error(("Unknown input format \"%s\"" % options.input_format)) + if options.input_format not in formats.input_formats(): + opts.error(("No input handler for format \"%s\"" + % options.input_format)) + + if os.path.isdir(args[0]): + (options.input_file, _) = formats.find_input(args[0], + options.input_format) + options.input_dir = args[0] + else: + options.input_file = args[0] + options.input_dir = os.path.dirname(os.path.realpath(args[0])) return options @@ -134,19 +144,8 @@ options = parse_args() cli.setupLogging("virt-convert", options.debug) - try: - inp = formats.find_parser_by_name(options.input_format) - except: - logging.error("No parser of format \"%s\" was found." % - options.input_format) - sys.exit(1) - - try: - outp = formats.find_parser_by_name(options.output_format) - except: - logging.error("No parser of format \"%s\" was found." % - options.output_format) - sys.exit(1) + inp = formats.parser_by_name(options.input_format) + outp = formats.parser_by_name(options.output_format) vmdef = None diff --git a/virtconv/formats.py b/virtconv/formats.py --- a/virtconv/formats.py +++ b/virtconv/formats.py @@ -17,6 +17,8 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA. # + +import os _parsers = [ ] @@ -66,11 +68,13 @@ global _parsers _parsers += [ parser ] -def find_parser_by_name(name): +def parser_by_name(name): """ - Return the parser of the given name + Return the parser of the given name. """ - return [p for p in _parsers if p.name == name][0] or None + parsers = [p for p in _parsers if p.name == name] + if len(parsers): + return parsers[0] def find_parser_by_file(input_file): """ @@ -80,3 +84,46 @@ if p.identify_file(input_file): return p return None + +def formats(): + """ + Return a list of supported formats. + """ + return [p.name for p in _parsers] + +def input_formats(): + """ + Return a list of supported input formats. + """ + return [p.name for p in _parsers if p.can_import] + +def output_formats(): + """ + Return a list of supported output formats. + """ + return [p.name for p in _parsers if p.can_export] + +def find_input(path, format = None): + """ + Search for a configuration file automatically. If @format is given, + then only search using a matching format parser. + """ + + if os.path.isdir(path): + files = os.listdir(path) + + for p in _parsers: + if not p.can_identify: + continue + if format and format != p.name: + continue + + if os.path.isfile(path): + if p.identify_file(path): + return (path, p.name) + elif os.path.isdir(path): + for cfgfile in [ x for x in files if x.endswith(p.suffix) ]: + if p.identify_file(os.path.join(path, cfgfile)): + return (os.path.join(path, cfgfile), p.name) + + raise StandardError("unknown format") diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -81,6 +81,9 @@ """ name = "virt-image" suffix = ".virt-image.xml" + can_import = False + can_export = True + can_identify = False @staticmethod def identify_file(input_file): diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -22,6 +22,8 @@ import virtconv.vmcfg as vmcfg import virtconv.diskcfg as diskcfg +import re + class vmx_parser(formats.parser): """ Support for VMWare .vmx files. Note that documentation is @@ -31,13 +33,23 @@ name = "vmx" suffix = ".vmx" + can_import = True + can_export = False + can_identify = True @staticmethod def identify_file(input_file): """ Return True if the given file is of this format. """ - raise NotImplementedError + infile = open(input_file, "r") + line = infile.readline() + infile.close() + + # some .vmx files don't bother with the header + if re.match(r'^config.version\s+=', line): + return True + return re.match(r'^#!\s*/usr/bin/vm(ware|player)', line) is not None @staticmethod def import_file(input_file): From crobinso at redhat.com Thu Jul 10 16:34:55 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 10 Jul 2008 12:34:55 -0400 Subject: [et-mgmt-tools] [PATCH 00 of 11] More virt-convert fixes In-Reply-To: References: Message-ID: <48763A2F.1090402@redhat.com> john.levon at sun.com wrote: > More fixes. Some of these you've seen before, though they're mostly much > better tested now. > > Signed-off-by: John Levon > I committed the first 6 patches in the series since they are pretty straight forward. I'll take a look at the others later in the day. Thanks, Cole From crobinso at redhat.com Thu Jul 10 16:36:21 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 10 Jul 2008 12:36:21 -0400 Subject: [et-mgmt-tools] [PATCH 0/2] virtinst: add support for audio devices In-Reply-To: <4874D6B3.6050005@redhat.com> References: <4874D6B3.6050005@redhat.com> Message-ID: <48763A85.3040500@redhat.com> Cole Robinson wrote: > The following patches add support for creating sound device xml > in virtinst, and using this from virt-install. > I've committed these with the change Dan suggested: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=b4b5cc914a6f http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=4f90a2ba095c - Cole From macscr at macscr.com Sat Jul 12 11:11:38 2008 From: macscr at macscr.com (Mark Chaney) Date: Sat, 12 Jul 2008 06:11:38 -0500 Subject: [et-mgmt-tools] no longer can create shared network Message-ID: <01ed01c8e410$0f4503d0$2dcf0b70$@com> I am running Centos 5.2 x86_64, Xen 3.2.1, and virt-manager 0.5.4. Ever since I upgraded xen and virt-manager to the newest, I cant seem to create a new xen pv domU with a shared network device (bridged I guess?). Nothing shows up in the shared network device list. Heck, even when I try the default network option, the domU created cant connect to the internet. I have 3 domU's that I created before this upgrade that seem to work fine. Any ideas? Thanks, Mark From crobinso at redhat.com Sun Jul 13 20:10:18 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 13 Jul 2008 16:10:18 -0400 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <01ed01c8e410$0f4503d0$2dcf0b70$@com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> Message-ID: <487A612A.5010908@redhat.com> Mark Chaney wrote: > I am running Centos 5.2 x86_64, Xen 3.2.1, and virt-manager 0.5.4. > > Ever since I upgraded xen and virt-manager to the newest, I cant seem to > create a new xen pv domU with a shared network device (bridged I guess?). > Nothing shows up in the shared network device list. Heck, even when I try > the default network option, the domU created cant connect to the internet. I > have 3 domU's that I created before this upgrade that seem to work fine. Any > ideas? > > Thanks, > Mark > Check ~/.virt-manager/virt-manager.log and see if there is a traceback anywhere. If you pulled down the stock 0.5.4 my guess is you will hit a number of issues on centos since we use newer dbus calls and rely on updated versions of gtk-vnc and possibly libvirt. - Cole From macscr at macscr.com Sun Jul 13 20:44:01 2008 From: macscr at macscr.com (Mark Chaney) Date: Sun, 13 Jul 2008 15:44:01 -0500 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <487A612A.5010908@redhat.com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> <487A612A.5010908@redhat.com> Message-ID: <026f01c8e529$2ffa6ce0$8fef46a0$@com> You mean something like this? [Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175) Unable to connect to HAL to list network devices: '%s'dbus_bindings.DBusException Could not get owner of name 'org.freedesktop.Hal': no such name Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 155, in __init__ self.hal_iface.connect_to_signal("DeviceAdded", self._net_phys_device_added) File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 291, in connect_to_signal self._obj.connect_to_signal(signal_name, handler_function, dbus_interface, **keywords) File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 151, in connect_to_signal path=self._object_path, File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 179, in add_signal_receiver named_service = bus_object.GetNameOwner(named_service, dbus_interface='org.freedesktop.DBus') File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 25, in __call__ ret = self._proxy_method (*args, **keywords) File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 102, in __call__ reply_message = self._connection.send_with_reply_and_block(message, timeout) File "dbus_bindings.pyx", line 455, in dbus_bindings.Connection.send_with_reply_and_block DBusException: Could not get owner of name 'org.freedesktop.Hal': no such name Also, how in the world can RHEL 5.2 be considered old? Mark Chaney wrote: > I am running Centos 5.2 x86_64, Xen 3.2.1, and virt-manager 0.5.4. > > Ever since I upgraded xen and virt-manager to the newest, I cant seem to > create a new xen pv domU with a shared network device (bridged I guess?). > Nothing shows up in the shared network device list. Heck, even when I try > the default network option, the domU created cant connect to the internet. I > have 3 domU's that I created before this upgrade that seem to work fine. Any > ideas? > > Thanks, > Mark > Check ~/.virt-manager/virt-manager.log and see if there is a traceback anywhere. If you pulled down the stock 0.5.4 my guess is you will hit a number of issues on centos since we use newer dbus calls and rely on updated versions of gtk-vnc and possibly libvirt. - Cole From crobinso at redhat.com Sun Jul 13 21:35:31 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 13 Jul 2008 17:35:31 -0400 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <026f01c8e529$2ffa6ce0$8fef46a0$@com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> <487A612A.5010908@redhat.com> <026f01c8e529$2ffa6ce0$8fef46a0$@com> Message-ID: <487A7523.9090508@redhat.com> Mark Chaney wrote: > You mean something like this? > > [Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175) Unable > to connect to HAL to list network devices: '%s'dbus_bindings.DBusException > Could not get owner of name 'org.freedesktop.Hal': no such name > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/connection.py", line 155, in > __init__ > self.hal_iface.connect_to_signal("DeviceAdded", > self._net_phys_device_added) > File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 291, in > connect_to_signal > self._obj.connect_to_signal(signal_name, handler_function, > dbus_interface, **keywords) > File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 151, in > connect_to_signal > path=self._object_path, > File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 179, in > add_signal_receiver > named_service = bus_object.GetNameOwner(named_service, > dbus_interface='org.freedesktop.DBus') > File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 25, in > __call__ > ret = self._proxy_method (*args, **keywords) > File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 102, in > __call__ > reply_message = self._connection.send_with_reply_and_block(message, > timeout) > File "dbus_bindings.pyx", line 455, in > dbus_bindings.Connection.send_with_reply_and_block > DBusException: Could not get owner of name 'org.freedesktop.Hal': no such > name > Yeah that would do it. I don't know if it would be a simple fix or not: you can try pulling down the current upstream and see if that produces any different results. Chances are though that things would require a bit of backporting to work on the rhel stack. > Also, how in the world can RHEL 5.2 be considered old? The entire point of RHEL is a release with a mostly stable set of major components that is maintained with bug fixes. We don't pull in the latest and greatest versions of every piece in the stack for an update release. As a result, dbus in 5.2 is probably just a patched version of dbus from 5.0 (haven't checked) making it essentially over a year old. - Cole From macscr at macscr.com Sun Jul 13 21:54:20 2008 From: macscr at macscr.com (Mark Chaney) Date: Sun, 13 Jul 2008 16:54:20 -0500 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <487A7523.9090508@redhat.com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> <487A612A.5010908@redhat.com> <026f01c8e529$2ffa6ce0$8fef46a0$@com> <487A7523.9090508@redhat.com> Message-ID: <027901c8e533$027edb20$077c9160$@com> So should I go back to 0.5.3? I figured I should update to 0.5.4 since I am using the newest version of xen -----Original Message----- From: Cole Robinson [mailto:crobinso at redhat.com] Sent: Sunday, July 13, 2008 4:36 PM To: Mark Chaney Cc: 'Fedora/Linux Management Tools' Subject: Re: [et-mgmt-tools] no longer can create shared network Mark Chaney wrote: > You mean something like this? > > [Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175) Unable > to connect to HAL to list network devices: '%s'dbus_bindings.DBusException > Could not get owner of name 'org.freedesktop.Hal': no such name > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/connection.py", line 155, in > __init__ > self.hal_iface.connect_to_signal("DeviceAdded", > self._net_phys_device_added) > File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 291, in > connect_to_signal > self._obj.connect_to_signal(signal_name, handler_function, > dbus_interface, **keywords) > File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 151, in > connect_to_signal > path=self._object_path, > File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 179, in > add_signal_receiver > named_service = bus_object.GetNameOwner(named_service, > dbus_interface='org.freedesktop.DBus') > File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 25, in > __call__ > ret = self._proxy_method (*args, **keywords) > File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 102, in > __call__ > reply_message = self._connection.send_with_reply_and_block(message, > timeout) > File "dbus_bindings.pyx", line 455, in > dbus_bindings.Connection.send_with_reply_and_block > DBusException: Could not get owner of name 'org.freedesktop.Hal': no such > name > Yeah that would do it. I don't know if it would be a simple fix or not: you can try pulling down the current upstream and see if that produces any different results. Chances are though that things would require a bit of backporting to work on the rhel stack. > Also, how in the world can RHEL 5.2 be considered old? The entire point of RHEL is a release with a mostly stable set of major components that is maintained with bug fixes. We don't pull in the latest and greatest versions of every piece in the stack for an update release. As a result, dbus in 5.2 is probably just a patched version of dbus from 5.0 (haven't checked) making it essentially over a year old. - Cole From crobinso at redhat.com Sun Jul 13 23:52:48 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 13 Jul 2008 19:52:48 -0400 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <027901c8e533$027edb20$077c9160$@com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> <487A612A.5010908@redhat.com> <026f01c8e529$2ffa6ce0$8fef46a0$@com> <487A7523.9090508@redhat.com> <027901c8e533$027edb20$077c9160$@com> Message-ID: <487A9550.3030701@redhat.com> Mark Chaney wrote: > So should I go back to 0.5.3? I figured I should update to 0.5.4 since I am > using the newest version of xen > Yeah I would recommend just sticking with the virt-manager in 5.2. - Cole From macscr at macscr.com Mon Jul 14 00:17:36 2008 From: macscr at macscr.com (Mark Chaney) Date: Sun, 13 Jul 2008 19:17:36 -0500 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <487A981C.3080103@redhat.com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> <487A612A.5010908@redhat.com> <026f01c8e529$2ffa6ce0$8fef46a0$@com> <487A7523.9090508@redhat.com> <027901c8e533$027edb20$077c9160$@com> <487A9550.3030701@redhat.com> <028101c8e544$5f362560$1da27020$@com> <487A981C.3080103@redhat.com> Message-ID: <028201c8e547$060af800$1220e800$@com> [root at ratchet /]# lshal error: libhal_ctx_init: (null): (null) Could not initialise connection to hald. Normally this mean the HAL daemon (hald) is not running or not ready. lshal.c 689 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set. -----Original Message----- From: Cole Robinson [mailto:crobinso at redhat.com] Sent: Sunday, July 13, 2008 7:05 PM To: Mark Chaney Subject: Re: [et-mgmt-tools] no longer can create shared network Mark Chaney wrote: > Downgrading didn't seem to make a diff =/ > > What version of libvirt should I be running? > > -----Original Message----- > From: Cole Robinson [mailto:crobinso at redhat.com] > Sent: Sunday, July 13, 2008 6:53 PM > To: Fedora/Linux Management Tools > Cc: macscr at macscr.com >> Mark Chaney > Subject: Re: [et-mgmt-tools] no longer can create shared network > > Mark Chaney wrote: >> So should I go back to 0.5.3? I figured I should update to 0.5.4 since I > am >> using the newest version of xen >> > > Yeah I would recommend just sticking with the virt-manager in 5.2. > > - Cole > The stock 5.2 version and you are still getting that error? Does 'lshal' return anything? - Cole From crobinso at redhat.com Mon Jul 14 02:21:01 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 13 Jul 2008 22:21:01 -0400 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <028201c8e547$060af800$1220e800$@com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> <487A612A.5010908@redhat.com> <026f01c8e529$2ffa6ce0$8fef46a0$@com> <487A7523.9090508@redhat.com> <027901c8e533$027edb20$077c9160$@com> <487A9550.3030701@redhat.com> <028101c8e544$5f362560$1da27020$@com> <487A981C.3080103@redhat.com> <028201c8e547$060af800$1220e800$@com> Message-ID: <487AB80D.7000304@redhat.com> Mark Chaney wrote: > [root at ratchet /]# lshal > error: libhal_ctx_init: (null): (null) > Could not initialise connection to hald. > Normally this mean the HAL daemon (hald) is not running or not ready. > lshal.c 689 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set. > Okay so virt-manager seems fine, there is just some hal or dbus issue. Try starting hald like it says, but if that fails for some reason I really can't help. - Cole From hefaneden at gmail.com Mon Jul 14 03:56:38 2008 From: hefaneden at gmail.com (fan he) Date: Mon, 14 Jul 2008 11:56:38 +0800 Subject: [et-mgmt-tools] virt-manager error in Fedora8+xen3.2 Message-ID: <5741ebef0807132056k66d902e9p56592ba262b878bf@mail.gmail.com> Hi I'm sorry for this repeated question, but i failed to start my virt-manager in Fedora8+xen3.2, error shows like: Unable to open connection to hypervisor URI 'xen:///': virConnectOpenReadOnly() failed Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 307, in _open_thread self.vmm = libvirt.openReadOnly(self.uri) File "/usr/lib/python2.5/site-packages/libvirt.py", line 148, in openReadOnly if ret is None:raise libvirtError('virConnectOpenReadOnly() failed') libvirtError: virConnectOpenReadOnly() failed I download and install xen3.2 on Fedora8 successfully. There is always a warning ask me to disable tls in /lib/tls before the OS begining, though making initrd.img after mv /lib/tls /lib/tls.disable and i am sure the Dom0 works well. I use "yum install virt-manager" to setup virt-manager and it should be the lastest version. I restart the xend with no error. Is there a compatiable error using xen3.2 and virt-manager? Or the /lib/tls do bad to my virt-manager? Any patches? Beg for any replies, thanks. Oscar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Charles_Duffy at messageone.com Mon Jul 14 06:25:22 2008 From: Charles_Duffy at messageone.com (Charles Duffy) Date: Mon, 14 Jul 2008 01:25:22 -0500 Subject: [et-mgmt-tools] Recursive distro delete trying to remove a profile more than once? Message-ID: Howdy. I'm trying to remove a number of distros and profiles, and hitting exceptions similar to the following: Traceback (most recent call last): File "cobbler_sync.py", line 132, in run cobbler_api.distros().remove(distro.name, with_delete=True, recursive=True) File "/usr/lib/python2.4/site-packages/cobbler/collection_distros.py", line 51, in remove self.config.api.remove_profile(k, recursive=True) File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 176, in remove_profile return self._config.profiles().remove(ref.name, recursive=recursive) File "/usr/lib/python2.4/site-packages/cobbler/collection_profiles.py", line 70, in remove raise CX(_("cannot delete an object that does not exist: %s") % name) cobbler.cexceptions.CX: 'cannot delete an object that does not exist: centos-5.1-xen-x86_64' The calling code looks like the following: for distro in list(cobbler_api.distros()): if not cobbler_api.find_distro(distro.name): continue # we've been removed by a recursive delete if not distro.name in desired_distro_list: logger.info('removing distro %r' % (distro.name,)) if not noop: cobbler_api.distros().remove(distro.name, with_delete=True, recursive=True) This issue is reproduced after the import of a new distribution. From berrange at redhat.com Mon Jul 14 08:50:19 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 14 Jul 2008 09:50:19 +0100 Subject: [et-mgmt-tools] no longer can create shared network In-Reply-To: <026f01c8e529$2ffa6ce0$8fef46a0$@com> References: <01ed01c8e410$0f4503d0$2dcf0b70$@com> <487A612A.5010908@redhat.com> <026f01c8e529$2ffa6ce0$8fef46a0$@com> Message-ID: <20080714085019.GB27537@redhat.com> On Sun, Jul 13, 2008 at 03:44:01PM -0500, Mark Chaney wrote: > You mean something like this? > > [Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175) Unable > to connect to HAL to list network devices: '%s'dbus_bindings.DBusException > Could not get owner of name 'org.freedesktop.Hal': no such name HAL isn't running - turn it on again. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Jul 14 08:54:31 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 14 Jul 2008 09:54:31 +0100 Subject: [et-mgmt-tools] virt-manager error in Fedora8+xen3.2 In-Reply-To: <5741ebef0807132056k66d902e9p56592ba262b878bf@mail.gmail.com> References: <5741ebef0807132056k66d902e9p56592ba262b878bf@mail.gmail.com> Message-ID: <20080714085431.GA28892@redhat.com> On Mon, Jul 14, 2008 at 11:56:38AM +0800, fan he wrote: > Hi > > I'm sorry for this repeated question, but i failed to start my virt-manager > in Fedora8+xen3.2, error shows like: > > Unable to open connection to hypervisor URI 'xen:///': > virConnectOpenReadOnly() failed > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/connection.py", line 307, in > _open_thread > self.vmm = libvirt.openReadOnly(self.uri) > File "/usr/lib/python2.5/site-packages/libvirt.py", line 148, in > openReadOnly > if ret is None:raise libvirtError('virConnectOpenReadOnly() failed') > libvirtError: virConnectOpenReadOnly() failed > > I download and install xen3.2 on Fedora8 successfully. > > There is always a warning ask me to disable tls in /lib/tls before the OS > begining, though making initrd.img after mv /lib/tls /lib/tls.disable and > i am sure the Dom0 works well. I use "yum install virt-manager" to setup > virt-manager and it should be the lastest version. I restart the xend with > no error. Ignore the /lib/tls warning - that hasn't been relevant for years. You probably don't have Xend listening for connections. You need (xend-unix-server yes) Set in /etc/xen/xend-config.sxp Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Mon Jul 14 16:49:11 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 12:49:11 -0400 Subject: [et-mgmt-tools] [PATCH 07 of 11] virt-convert: improve disk handling In-Reply-To: <8ffd21ddf5c72ddbe8a3.1215697717@joos> References: <8ffd21ddf5c72ddbe8a3.1215697717@joos> Message-ID: <487B8387.2050500@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215697571 25200 > # Node ID 8ffd21ddf5c72ddbe8a30f65f0761e2f39705d57 > # Parent 91d463e8e9921844271a90f416e0e6d94fd2af40 > virt-convert: improve disk handling > > A whole bunch of fixes for more accurate disk handling. > > Signed-off-by: John Levon I've committed this, with a minor change using the variable name 'ignore' rather than '_'. Thanks, Cole From crobinso at redhat.com Mon Jul 14 16:49:18 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 12:49:18 -0400 Subject: [et-mgmt-tools] [PATCH 08 of 11] virt-convert: implement network device handling In-Reply-To: <72eec78868efe7a872ea.1215697718@joos> References: <72eec78868efe7a872ea.1215697718@joos> Message-ID: <487B838E.1070200@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215697571 25200 > # Node ID 72eec78868efe7a872eab6c08502b3b84bf00a46 > # Parent 8ffd21ddf5c72ddbe8a30f65f0761e2f39705d57 > virt-convert: implement network device handling > I've committed this with a small change similar to the one I added for the disk patch. Thanks, Cole From crobinso at redhat.com Mon Jul 14 16:50:12 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 12:50:12 -0400 Subject: [et-mgmt-tools] [PATCH 09 of 11] virt-convert: Add OS variant options In-Reply-To: <443b42b45ee6f799020a.1215697719@joos> References: <443b42b45ee6f799020a.1215697719@joos> Message-ID: <487B83C4.6070601@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215697571 25200 > # Node ID 443b42b45ee6f799020a9418388440b93d9ab78c > # Parent 72eec78868efe7a872eab6c08502b3b84bf00a46 > virt-convert: Add OS variant options > > And use them to set ACPI, APIC, clock, and USB tablet. > I've committed this, though this brings to mind a few things we should change before a next release. Just some thoughts: Duplicating the internal OS dictionary in man pages isn't helpful: we should just add a cli option to virt-install (maybe all the tools that use the dict?) to dump the dictionary in a readable manner and exit. That way the man pages can just say 'see "virt-install --show-me-the-money" for a complete list.' VMX files have a field which specifies the guest os: we should probably try to translate that into an entry in the virtinst OS dict if the user doesn't supply one. Also I think the virt-image format should have an entry for the OS type of the guest, so we should probably add this option to virt-image as well. Thanks, Cole From crobinso at redhat.com Mon Jul 14 16:50:21 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 12:50:21 -0400 Subject: [et-mgmt-tools] [PATCH 10 of 11] virt-install: correct pygrub path In-Reply-To: <92de696f634f80d47b94.1215697720@joos> References: <92de696f634f80d47b94.1215697720@joos> Message-ID: <487B83CD.1090507@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215697572 25200 > # Node ID 92de696f634f80d47b9413b9db5101de0edf9b7f > # Parent 443b42b45ee6f799020a9418388440b93d9ab78c > virt-install: correct pygrub path > > The path to pygrub differs between OS hosts. Properly speaking, this is a > property of the hypervisor capabilities, and we'd get it from there. However, > traditionally the loader value is empty for PV Xen hosts, so we can't rely on > it, so we hard-code it based upon the current host. > > Signed-off-by: John Levon > I've committed this with a couple comments to the util function specifying that this will be deprecated by (hopefully) fixed capabilities xml. Thanks, Cole From john.levon at sun.com Mon Jul 14 16:56:14 2008 From: john.levon at sun.com (John Levon) Date: Mon, 14 Jul 2008 17:56:14 +0100 Subject: [et-mgmt-tools] [PATCH 09 of 11] virt-convert: Add OS variant options In-Reply-To: <487B83C4.6070601@redhat.com> References: <443b42b45ee6f799020a.1215697719@joos> <487B83C4.6070601@redhat.com> Message-ID: <20080714165614.GE27623@barman.uk.sun.com> On Mon, Jul 14, 2008 at 12:50:12PM -0400, Cole Robinson wrote: > Duplicating the internal OS dictionary in man pages isn't > helpful: we should just add a cli option to virt-install > (maybe all the tools that use the dict?) to dump the dictionary > in a readable manner and exit. That way the man pages can > just say 'see "virt-install --show-me-the-money" for a > complete list.' Yes. In fact we have a requirement for dumping this in a parsable way too for higher-level tools to comprehend. > VMX files have a field which specifies the guest os: we should > probably try to translate that into an entry in the virtinst > OS dict if the user doesn't supply one. I'll try to take a look at this. > Also I think the virt-image format should have an entry for > the OS type of the guest, so we should probably add this > option to virt-image as well. Agreed regards, john From crobinso at redhat.com Mon Jul 14 16:55:23 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 12:55:23 -0400 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <112cd8c4aa97e9da9d75.1215697721@joos> References: <112cd8c4aa97e9da9d75.1215697721@joos> Message-ID: <487B84FB.1050204@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1215697572 25200 > # Node ID 112cd8c4aa97e9da9d7532fee7d826d35e1003e8 > # Parent 92de696f634f80d47b9413b9db5101de0edf9b7f > virt-convert: Add "virt-instance" formatter. > > Allow output in libvirt.rng format > So I'm not generally opposed to this idea, however the way this patch implements it is a massive duplication of the virtinst apis, so NACK in this current form. Like Dan mentioned before, if we allow converting to libvirt xml, we need to make it clear that the generated config is really only applicable on the machine it is generated. A connection must be required in order to do the conversion so we can use the virtinst apis and check capabilities xml. This makes it kind of messy since we will have cli options that are relevant for some formats and not for others, but it's unavoidable, and as long as the documentation is clear, it shouldn't be confusing. Thanks, Cole From mdehaan at redhat.com Mon Jul 14 18:25:07 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 Jul 2008 14:25:07 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? Message-ID: <487B9A03.7080801@redhat.com> Here's something I would like to see, but do not know how to cleanly accomplish: virt-clone -o GUESTNAME -f NEWDISKFILE -x NEWXML The idea here is I really want to be able to clone guests, but I don't necessarily want to clone them on the same host. Instead, I want to be able to track a central library of guests (and their associated disk images) in cobbler that I can clone later -- in my case, koan will be just doing the bare-minimum to get the virt-image parameters right to feed to virt-image. So, in order to do this, I also need to get some XML out of the guest that is compatible with virt-image, so I can save it on the central server. The problem I have now is that the XML coming out of virsh dumpxml is not compatible with virt-image. This "-x" output would need to be in virt-image format and it would write this XML in addition to the diskfile. For example, once established, I could just feed this back into virt-image like so: virt-image foo.xml --n NEWNAME -u NEWUUID -m NEWMAC -b NEWBRIDGE I do not think I'm familiar with virtinst internals to add this, though it's something we are going to eventually need for ovirt. You can see a bit of what syntax I'm getting at (and the general idea) here: https://fedorahosted.org/cobbler/wiki/KoanWithIsos Though in addition koan would be tracking the xmlfile for cloning info as well. --Michael From levon at movementarian.org Mon Jul 14 18:45:47 2008 From: levon at movementarian.org (John Levon) Date: Mon, 14 Jul 2008 19:45:47 +0100 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <487B84FB.1050204@redhat.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> Message-ID: <20080714184547.GH15331@totally.trollied.org.uk> On Mon, Jul 14, 2008 at 12:55:23PM -0400, Cole Robinson wrote: > So I'm not generally opposed to this idea, however the way this patch > implements it is a massive duplication of the virtinst apis, so > NACK in this current form. I'm not sure it's "massive". Are you saying I should be using setup_install, etc. to generate the XML? This will leave me with no ability to modify what gets created, unless I'm misunderstanding you. I admit I'm not very familiar with these APIs. I don't want to use virt-image directly because of its information-losing properties. I'm happy to do this if it's workable, could do with some implementation guidance. > Like Dan mentioned before, if we allow converting to libvirt xml, we > need to make it clear that the generated config is really only > applicable on the machine it is generated. Surely, only applicable to machine it's generated on OR the connection it's connected to, if one's provided? I agree we need to make this clear. Perhaps a warning is appropriate if output is in any format other than virt-image (or OVF)? > A connection must be required in order to do the conversion so we can > use the virtinst apis and check capabilities xml. I'm a bit unclear on the need for this to be a requirement. It just seems to be placing unnecessary obstacles in the user's way. You're basically turning the warning above into an error for many situations. (Yes, I know I don't have a connection option yet, hopefully I'll be adding this soon.) regards john From crobinso at redhat.com Mon Jul 14 19:21:03 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 15:21:03 -0400 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <20080714184547.GH15331@totally.trollied.org.uk> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> Message-ID: <487BA71F.1090407@redhat.com> John Levon wrote: > On Mon, Jul 14, 2008 at 12:55:23PM -0400, Cole Robinson wrote: > >> So I'm not generally opposed to this idea, however the way this patch >> implements it is a massive duplication of the virtinst apis, so >> NACK in this current form. > > I'm not sure it's "massive". Are you saying I should be using > setup_install, etc. to generate the XML? This will leave me with no > ability to modify what gets created, unless I'm misunderstanding you. > I admit I'm not very familiar with these APIs. > No, setup_install would not be neccessary. You could populate a Guest object with all the data imported from another format, and then call validate_parms and get_xml_config. Truthfully, virtinst as an API is a mess: It's been built incrementally from an interactive script that made xen guests. I've been thinking alot recently about ways to clean it up and really seperate all the pieces. That aside, It's main functions are as a way to build libvirt xml, and a way to simplify install processes like fetching tree kernels, setting up disks for cdrom booting, etc. In this case you would be ignoring all the install pieces and just using the objects to build the xml. > I don't want to use virt-image directly because of its > information-losing properties. I understand this, virt-image certainly isn't the thing to use unless portability is the specific goal. >> Like Dan mentioned before, if we allow converting to libvirt xml, we >> need to make it clear that the generated config is really only >> applicable on the machine it is generated. > > Surely, only applicable to machine it's generated on OR the connection it's > connected to, if one's provided? > Yes my statement was unclear, I meant to say "only applicable for the host the libvirt connection is on." >> A connection must be required in order to do the conversion so we can >> use the virtinst apis and check capabilities xml. > > I'm a bit unclear on the need for this to be a requirement. It just > seems to be placing unnecessary obstacles in the user's way. You're > basically turning the warning above into an error for many situations. > If we don't require using an active libvirt connection, we will find ourselves just duplicating information that is already presented by libvirt capabilities xml, such as emulator paths, feature availability like pae, and in the future, whitelists for device models, all with varying degrees of accuracy. Also, what is the usecase of converting to libvirt xml _without_ an active connection? If, lacking a connection, the best we can guarantee is "this xml will work on this physical machine", then the xml would only be useful if they have a libvirt setup on that physical machine, and if that's the case they can provide a uri to the app. Granted, having to specify a uri is annoying for a user, but we can choose sensible defaults and make this largely transparent, as virt-install currently does. > (Yes, I know I don't have a connection option yet, hopefully I'll be > adding this soon.) > > regards > john > Thanks, Cole From crobinso at redhat.com Mon Jul 14 19:35:28 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 15:35:28 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487B9A03.7080801@redhat.com> References: <487B9A03.7080801@redhat.com> Message-ID: <487BAA80.2000009@redhat.com> Michael DeHaan wrote: > Here's something I would like to see, but do not know how to cleanly > accomplish: > > virt-clone -o GUESTNAME -f NEWDISKFILE -x NEWXML > > The idea here is I really want to be able to clone guests, but I don't > necessarily want to clone them on the same host. Instead, I want to be > able to track a central library of guests (and their associated disk > images) in cobbler that I can clone later -- in my case, koan will be > just doing the bare-minimum to get the virt-image parameters right to > feed to virt-image. So, in order to do this, I also need to get some > XML out of the guest that is compatible with virt-image, so I can save > it on the central server. > > The problem I have now is that the XML coming out of virsh dumpxml is > not compatible with virt-image. > > This "-x" output would need to be in virt-image format and it would > write this XML in addition to the diskfile. > > For example, once established, I could just feed this back into > virt-image like so: > > virt-image foo.xml --n NEWNAME -u NEWUUID -m NEWMAC -b NEWBRIDGE > > I do not think I'm familiar with virtinst internals to add this, though > it's something we are going to eventually need for ovirt. > > You can see a bit of what syntax I'm getting at (and the general idea) here: > > https://fedorahosted.org/cobbler/wiki/KoanWithIsos > > Though in addition koan would be tracking the xmlfile for cloning info > as well. > I think the premise is okay, but from an app separation point of view it should be achieved a bit differently. We could add an option to virt-clone to output the libvirt xml of the new guest. This would be pretty simple to add. We could then use the new virt-convert tool to convert libvirt xml to virt-image xml. This functionality isn't present but work is being done in this area and would not be all that difficult to add. This adds an extra step to your proposed process, but I think is the sensible way to go. Converting libvirt xml to virt-image xml is desired functionality anyways, so we want to head in this direction. - Cole From mdehaan at redhat.com Mon Jul 14 19:49:59 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 Jul 2008 15:49:59 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BAA80.2000009@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> Message-ID: <487BADE7.5050301@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Here's something I would like to see, but do not know how to cleanly >> accomplish: >> >> virt-clone -o GUESTNAME -f NEWDISKFILE -x NEWXML >> >> The idea here is I really want to be able to clone guests, but I don't >> necessarily want to clone them on the same host. Instead, I want to be >> able to track a central library of guests (and their associated disk >> images) in cobbler that I can clone later -- in my case, koan will be >> just doing the bare-minimum to get the virt-image parameters right to >> feed to virt-image. So, in order to do this, I also need to get some >> XML out of the guest that is compatible with virt-image, so I can save >> it on the central server. >> >> The problem I have now is that the XML coming out of virsh dumpxml is >> not compatible with virt-image. >> >> This "-x" output would need to be in virt-image format and it would >> write this XML in addition to the diskfile. >> >> For example, once established, I could just feed this back into >> virt-image like so: >> >> virt-image foo.xml --n NEWNAME -u NEWUUID -m NEWMAC -b NEWBRIDGE >> >> I do not think I'm familiar with virtinst internals to add this, though >> it's something we are going to eventually need for ovirt. >> >> You can see a bit of what syntax I'm getting at (and the general idea) here: >> >> https://fedorahosted.org/cobbler/wiki/KoanWithIsos >> >> Though in addition koan would be tracking the xmlfile for cloning info >> as well. >> >> > > I think the premise is okay, but from an app separation point > of view it should be achieved a bit differently. > > We could add an option to virt-clone to output the libvirt xml of > the new guest. This would be pretty simple to add. > > We could then use the new virt-convert tool to convert libvirt xml > to virt-image xml. This functionality isn't present but work is > being done in this area and would not be all that difficult to > add. > > This adds an extra step to your proposed process, but I think is > the sensible way to go. Converting libvirt xml to virt-image xml > is desired functionality anyways, so we want to head in this > direction. > > - Cole > > > > Cool. Just to be sure we're on the same page, do you see this process looking something like: virt-clone guestname --dumpxml foo.xml --disk bar.disk && virt-convert --input foo.xml --dumpxml baz.xml cp bar.disk /some/nfs_mounted/path/bar.disk cp foo.xml /some/nfs_mounted/path/foo.xml cobbler image --name=blip add --disk nfs://.../bar.disk --xml nfs://.../foo.xml koan --server=cobbler.example.com --image=blip --virt The koan command, when run: (a) copies the xml file from NFS to some directory (b) copies the disk from NFS to some directory (c) performs minimal xml surgery to fix up path URLs and replace any mac addresses the best it can using mac info stored in cobbler or randomly generated (d) (if any overrides are in cobbler, like --virt-ram, it may also try to replace those, though those features are TBD and not really a concern in the ovirt case) (e) runs virt-image against tweaked xml file. Sound good/close? --Michael From crobinso at redhat.com Mon Jul 14 19:54:24 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 15:54:24 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BADE7.5050301@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> <487BADE7.5050301@redhat.com> Message-ID: <487BAEF0.4040805@redhat.com> Michael DeHaan wrote: > Cole Robinson wrote: >> Michael DeHaan wrote: >> >>> Here's something I would like to see, but do not know how to cleanly >>> accomplish: >>> >>> virt-clone -o GUESTNAME -f NEWDISKFILE -x NEWXML >>> >>> The idea here is I really want to be able to clone guests, but I don't >>> necessarily want to clone them on the same host. Instead, I want to be >>> able to track a central library of guests (and their associated disk >>> images) in cobbler that I can clone later -- in my case, koan will be >>> just doing the bare-minimum to get the virt-image parameters right to >>> feed to virt-image. So, in order to do this, I also need to get some >>> XML out of the guest that is compatible with virt-image, so I can save >>> it on the central server. >>> >>> The problem I have now is that the XML coming out of virsh dumpxml is >>> not compatible with virt-image. >>> >>> This "-x" output would need to be in virt-image format and it would >>> write this XML in addition to the diskfile. >>> >>> For example, once established, I could just feed this back into >>> virt-image like so: >>> >>> virt-image foo.xml --n NEWNAME -u NEWUUID -m NEWMAC -b NEWBRIDGE >>> >>> I do not think I'm familiar with virtinst internals to add this, though >>> it's something we are going to eventually need for ovirt. >>> >>> You can see a bit of what syntax I'm getting at (and the general idea) here: >>> >>> https://fedorahosted.org/cobbler/wiki/KoanWithIsos >>> >>> Though in addition koan would be tracking the xmlfile for cloning info >>> as well. >>> >>> >> I think the premise is okay, but from an app separation point >> of view it should be achieved a bit differently. >> >> We could add an option to virt-clone to output the libvirt xml of >> the new guest. This would be pretty simple to add. >> >> We could then use the new virt-convert tool to convert libvirt xml >> to virt-image xml. This functionality isn't present but work is >> being done in this area and would not be all that difficult to >> add. >> >> This adds an extra step to your proposed process, but I think is >> the sensible way to go. Converting libvirt xml to virt-image xml >> is desired functionality anyways, so we want to head in this >> direction. >> >> - Cole >> >> >> >> > > Cool. > > Just to be sure we're on the same page, do you see this process looking > something like: > > virt-clone guestname --dumpxml foo.xml --disk bar.disk && virt-convert > --input foo.xml --dumpxml baz.xml > cp bar.disk /some/nfs_mounted/path/bar.disk > cp foo.xml /some/nfs_mounted/path/foo.xml > cobbler image --name=blip add --disk nfs://.../bar.disk --xml > nfs://.../foo.xml > koan --server=cobbler.example.com --image=blip --virt > Yeah as far as I can imagine that seems about right. > The koan command, when run: > > (a) copies the xml file from NFS to some directory > (b) copies the disk from NFS to some directory > (c) performs minimal xml surgery to fix up path URLs and replace any mac > addresses the best it can using mac info stored in cobbler or randomly > generated Actually the nature of the virt-image format is that you shouldn't need to do any xml surgery, it is (ideally) completely portable. Specific things like memory amounts and mac addresses are specified at the time virt-image is called: see virt-image --help for all the goodies that can be specified. > (d) (if any overrides are in cobbler, like --virt-ram, it may also try > to replace those, though those features are TBD and not really a concern > in the ovirt case) > (e) runs virt-image against tweaked xml file. > > Sound good/close? > > --Michael From bkearney at redhat.com Mon Jul 14 20:01:26 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 14 Jul 2008 16:01:26 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BAEF0.4040805@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> <487BADE7.5050301@redhat.com> <487BAEF0.4040805@redhat.com> Message-ID: <487BB096.8070600@redhat.com> > > Actually the nature of the virt-image format is that you shouldn't > need to do any xml surgery, it is (ideally) completely portable. Specific > things like memory amounts and mac addresses are specified at the time > virt-image is called: see virt-image --help for all the goodies that > can be specified. > tools But ideally, the initial virt image xml would contain the memory and cpu settings from the source system.. since that is as close to a template as we have. -- bk From mdehaan at redhat.com Mon Jul 14 20:08:29 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 Jul 2008 16:08:29 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BAEF0.4040805@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> <487BADE7.5050301@redhat.com> <487BAEF0.4040805@redhat.com> Message-ID: <487BB23D.2040201@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Cole Robinson wrote: >> >>> Michael DeHaan wrote: >>> >>> >>>> Here's something I would like to see, but do not know how to cleanly >>>> accomplish: >>>> >>>> virt-clone -o GUESTNAME -f NEWDISKFILE -x NEWXML >>>> >>>> The idea here is I really want to be able to clone guests, but I don't >>>> necessarily want to clone them on the same host. Instead, I want to be >>>> able to track a central library of guests (and their associated disk >>>> images) in cobbler that I can clone later -- in my case, koan will be >>>> just doing the bare-minimum to get the virt-image parameters right to >>>> feed to virt-image. So, in order to do this, I also need to get some >>>> XML out of the guest that is compatible with virt-image, so I can save >>>> it on the central server. >>>> >>>> The problem I have now is that the XML coming out of virsh dumpxml is >>>> not compatible with virt-image. >>>> >>>> This "-x" output would need to be in virt-image format and it would >>>> write this XML in addition to the diskfile. >>>> >>>> For example, once established, I could just feed this back into >>>> virt-image like so: >>>> >>>> virt-image foo.xml --n NEWNAME -u NEWUUID -m NEWMAC -b NEWBRIDGE >>>> >>>> I do not think I'm familiar with virtinst internals to add this, though >>>> it's something we are going to eventually need for ovirt. >>>> >>>> You can see a bit of what syntax I'm getting at (and the general idea) here: >>>> >>>> https://fedorahosted.org/cobbler/wiki/KoanWithIsos >>>> >>>> Though in addition koan would be tracking the xmlfile for cloning info >>>> as well. >>>> >>>> >>>> >>> I think the premise is okay, but from an app separation point >>> of view it should be achieved a bit differently. >>> >>> We could add an option to virt-clone to output the libvirt xml of >>> the new guest. This would be pretty simple to add. >>> >>> We could then use the new virt-convert tool to convert libvirt xml >>> to virt-image xml. This functionality isn't present but work is >>> being done in this area and would not be all that difficult to >>> add. >>> >>> This adds an extra step to your proposed process, but I think is >>> the sensible way to go. Converting libvirt xml to virt-image xml >>> is desired functionality anyways, so we want to head in this >>> direction. >>> >>> - Cole >>> >>> >>> >>> >>> >> Cool. >> >> Just to be sure we're on the same page, do you see this process looking >> something like: >> >> virt-clone guestname --dumpxml foo.xml --disk bar.disk && virt-convert >> --input foo.xml --dumpxml baz.xml >> cp bar.disk /some/nfs_mounted/path/bar.disk >> cp foo.xml /some/nfs_mounted/path/foo.xml >> cobbler image --name=blip add --disk nfs://.../bar.disk --xml >> nfs://.../foo.xml >> koan --server=cobbler.example.com --image=blip --virt >> >> > > Yeah as far as I can imagine that seems about right. > > >> The koan command, when run: >> >> (a) copies the xml file from NFS to some directory >> (b) copies the disk from NFS to some directory >> (c) performs minimal xml surgery to fix up path URLs and replace any mac >> addresses the best it can using mac info stored in cobbler or randomly >> generated >> > > Actually the nature of the virt-image format is that you shouldn't > need to do any xml surgery, it is (ideally) completely portable. Specific > things like memory amounts and mac addresses are specified at the time > virt-image is called: see virt-image --help for all the goodies that > can be specified. > > That's even better. So it is possible to reuse --disk and --mac for multiple disks/macs, then? >> (d) (if any overrides are in cobbler, like --virt-ram, it may also try >> to replace those, though those features are TBD and not really a concern >> in the ovirt case) >> (e) runs virt-image against tweaked xml file. >> >> Sound good/close? >> >> --Michael >> > > From mdehaan at redhat.com Mon Jul 14 20:14:37 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 Jul 2008 16:14:37 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BB096.8070600@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> <487BADE7.5050301@redhat.com> <487BAEF0.4040805@redhat.com> <487BB096.8070600@redhat.com> Message-ID: <487BB3AD.4060709@redhat.com> Bryan Kearney wrote: > >> >> Actually the nature of the virt-image format is that you shouldn't >> need to do any xml surgery, it is (ideally) completely portable. >> Specific >> things like memory amounts and mac addresses are specified at the time >> virt-image is called: see virt-image --help for all the goodies that >> can be specified. >> tools > But ideally, the initial virt image xml would contain the memory and > cpu settings from the source system.. since that is as close to a > template as we have. > > -- bk Yes, we'd want that if it's not already there. In the cobbler use case, I can see defaulting --virt-ram (in cobbler) to "", which would mean, "use what is in the file", but more often than not someone is going to want to tweak it up or down. For instance: cobbler image copy --name=image --newname=image-with-more-ram --virt-ram=1024 This makes an image object like image-with-more-ram (keeping the behind the scenes XML the same), but when invoked with koan, grants more RAM to the system than was originally requested. This is basically how all the overrides in cobbler work today and makes things easy to edit in the web app. Currently non-image based guests default to a ram value in /etc/cobbler/settings when they are created without specificing a limit. Anyhow, as long as we have all the flags on --virt-image so we don't have to override the XML, and make it very easy to /get/ that XML, I'm happy and can start working on this shortly ... we can just wait for the tools to prepare that to come along and add them to the docs/process later. --Michael From crobinso at redhat.com Mon Jul 14 20:13:23 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 16:13:23 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BB096.8070600@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> <487BADE7.5050301@redhat.com> <487BAEF0.4040805@redhat.com> <487BB096.8070600@redhat.com> Message-ID: <487BB363.4020904@redhat.com> Bryan Kearney wrote: >> Actually the nature of the virt-image format is that you shouldn't >> need to do any xml surgery, it is (ideally) completely portable. Specific >> things like memory amounts and mac addresses are specified at the time >> virt-image is called: see virt-image --help for all the goodies that >> can be specified. >> tools > But ideally, the initial virt image xml would contain the memory and cpu > settings from the source system.. since that is as close to a template > as we have. > > -- bk > Oh, yes that's true. I forgot that mem and vcpu recommendations can be in the image xml. Thankfully though the virt-image removes any need to manually alter xml. - Cole From crobinso at redhat.com Mon Jul 14 20:19:05 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 16:19:05 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BB23D.2040201@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> <487BADE7.5050301@redhat.com> <487BAEF0.4040805@redhat.com> <487BB23D.2040201@redhat.com> Message-ID: <487BB4B9.9010300@redhat.com> Michael DeHaan wrote: > Cole Robinson wrote: >> Michael DeHaan wrote: >> >>> The koan command, when run: >>> >>> (a) copies the xml file from NFS to some directory >>> (b) copies the disk from NFS to some directory >>> (c) performs minimal xml surgery to fix up path URLs and replace any mac >>> addresses the best it can using mac info stored in cobbler or randomly >>> generated >>> >> Actually the nature of the virt-image format is that you shouldn't >> need to do any xml surgery, it is (ideally) completely portable. Specific >> things like memory amounts and mac addresses are specified at the time >> virt-image is called: see virt-image --help for all the goodies that >> can be specified. >> >> > That's even better. So it is possible to reuse --disk and --mac for > multiple disks/macs, then? > > I'm a bit confused: are you talking cobbler/koan options or virt-image options? If the latter, there is no --disk option, since it pulls all that info from the image xml. Multiple --network and --mac options can be specified though. - Cole From mdehaan at redhat.com Mon Jul 14 20:34:50 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 Jul 2008 16:34:50 -0400 Subject: [et-mgmt-tools] Idea/help with virt-clone? In-Reply-To: <487BB4B9.9010300@redhat.com> References: <487B9A03.7080801@redhat.com> <487BAA80.2000009@redhat.com> <487BADE7.5050301@redhat.com> <487BAEF0.4040805@redhat.com> <487BB23D.2040201@redhat.com> <487BB4B9.9010300@redhat.com> Message-ID: <487BB86A.5080801@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Cole Robinson wrote: >> >>> Michael DeHaan wrote: >>> >>> >>>> The koan command, when run: >>>> >>>> (a) copies the xml file from NFS to some directory >>>> (b) copies the disk from NFS to some directory >>>> (c) performs minimal xml surgery to fix up path URLs and replace any mac >>>> addresses the best it can using mac info stored in cobbler or randomly >>>> generated >>>> >>>> >>> Actually the nature of the virt-image format is that you shouldn't >>> need to do any xml surgery, it is (ideally) completely portable. Specific >>> things like memory amounts and mac addresses are specified at the time >>> virt-image is called: see virt-image --help for all the goodies that >>> can be specified. >>> >>> >>> >> That's even better. So it is possible to reuse --disk and --mac for >> multiple disks/macs, then? >> >> >> > > I'm a bit confused: are you talking cobbler/koan options or virt-image > options? If the latter, there is no --disk option, since it pulls all > that info from the image xml. Multiple --network and --mac options > can be specified though. > > - Cole > virt-image options. And you're right on disks :) From john.levon at sun.com Mon Jul 14 20:35:42 2008 From: john.levon at sun.com (John Levon) Date: Mon, 14 Jul 2008 21:35:42 +0100 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <487BA71F.1090407@redhat.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> <487BA71F.1090407@redhat.com> Message-ID: <20080714203542.GB28500@barman.uk.sun.com> On Mon, Jul 14, 2008 at 03:21:03PM -0400, Cole Robinson wrote: > No, setup_install would not be neccessary. You could populate a > Guest object with all the data imported from another format, > and then call validate_parms and get_xml_config. This sounds good, I'll look at doing this. > > I'm a bit unclear on the need for this to be a requirement. It just > > seems to be placing unnecessary obstacles in the user's way. You're > > basically turning the warning above into an error for many situations. > > If we don't require using an active libvirt connection, we will find > ourselves just duplicating information that is already presented by > libvirt capabilities xml, such as emulator paths, feature availability > like pae, and in the future, whitelists for device models, all with > varying degrees of accuracy. Hmm. I don't think that's a big deal now at all (since virt-install is already encoding all this stuff *anyway*). But I thought about it, and you're right. This could become very tricky in the future. However, there's still a problem I'm not sure how to deal with: general export. In this case we might not even be exporting to a format that libvirt can even *deal* with, never mind one that's on the other end of the connection. What do we do in this case? How can I export to .vmx without hard-coding some stuff based upon command-line options? Do we require a connection for this, and try to work out defaults based on the connection anyway? This is less than ideal: consider the poor user who's not booted under Xen, and wants to import his Xen VM into VMWare on that machine. regards john From bkearney at redhat.com Mon Jul 14 20:36:03 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 14 Jul 2008 16:36:03 -0400 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <20080714203542.GB28500@barman.uk.sun.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> <487BA71F.1090407@redhat.com> <20080714203542.GB28500@barman.uk.sun.com> Message-ID: <487BB8B3.3080305@redhat.com> John Levon wrote: > On Mon, Jul 14, 2008 at 03:21:03PM -0400, Cole Robinson wrote: > >> No, setup_install would not be neccessary. You could populate a >> Guest object with all the data imported from another format, >> and then call validate_parms and get_xml_config. > > This sounds good, I'll look at doing this. > >>> I'm a bit unclear on the need for this to be a requirement. It just >>> seems to be placing unnecessary obstacles in the user's way. You're >>> basically turning the warning above into an error for many situations. >> If we don't require using an active libvirt connection, we will find >> ourselves just duplicating information that is already presented by >> libvirt capabilities xml, such as emulator paths, feature availability >> like pae, and in the future, whitelists for device models, all with >> varying degrees of accuracy. > > Hmm. I don't think that's a big deal now at all (since virt-install is > already encoding all this stuff *anyway*). But I thought about it, and > you're right. This could become very tricky in the future. > > However, there's still a problem I'm not sure how to deal with: general > export. In this case we might not even be exporting to a format that > libvirt can even *deal* with, never mind one that's on the other end of > the connection. What do we do in this case? > > How can I export to .vmx without hard-coding some stuff based upon > command-line options? Do we require a connection for this, and try to > work out defaults based on the connection anyway? This is less > than ideal: consider the poor user who's not booted under Xen, and wants > to import his Xen VM into VMWare on that machine. I agree.. I could see a 2 very common use cases: 1) I am running on hypervisorX, and I get an image for hypervisor Y which I want to play with. I should be able to convert Y to X without having Y running in my enterprise. 2) I am building appliances, and I want to support hypervisor Y. I should be able to build for my internal X and then convert to Y. --bk From crobinso at redhat.com Mon Jul 14 20:49:51 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 16:49:51 -0400 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <20080714203542.GB28500@barman.uk.sun.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> <487BA71F.1090407@redhat.com> <20080714203542.GB28500@barman.uk.sun.com> Message-ID: <487BBBEF.4020308@redhat.com> John Levon wrote: > >>> I'm a bit unclear on the need for this to be a requirement. It just >>> seems to be placing unnecessary obstacles in the user's way. You're >>> basically turning the warning above into an error for many situations. >> If we don't require using an active libvirt connection, we will find >> ourselves just duplicating information that is already presented by >> libvirt capabilities xml, such as emulator paths, feature availability >> like pae, and in the future, whitelists for device models, all with >> varying degrees of accuracy. > > Hmm. I don't think that's a big deal now at all (since virt-install is > already encoding all this stuff *anyway*). But I thought about it, and > you're right. This could become very tricky in the future. > Like I mentioned above, virtinst is pretty crufty. Anything we have hardcoded that is available via capabilities xml is a bug: unfortunately virtinst pre-dated capabilities xml. If we have the option to start from scratch, avoiding the hardcoding approach is definitely the way to go, and only more motivation to fill out capabilities in libvirt :) > However, there's still a problem I'm not sure how to deal with: general > export. In this case we might not even be exporting to a format that > libvirt can even *deal* with, never mind one that's on the other end of > the connection. What do we do in this case? > > How can I export to .vmx without hard-coding some stuff based upon > command-line options? Do we require a connection for this, and try to > work out defaults based on the connection anyway? This is less > than ideal: consider the poor user who's not booted under Xen, and wants > to import his Xen VM into VMWare on that machine. > I think a libvirt connection will only be necessary when converting TO libvirt xml. If the input format is libvirt xml, we shouldn't need a connection, since there really won't be anything we can gain from it. So if this user has a libvirt domain xml file and wants to convert to vmware, we don't use a connection, and will have to use some hardcoded conversions and defaults for libvirt->vmx. That's fine since as far as I know there isn't a better alternative. - Cole From john.levon at sun.com Mon Jul 14 20:54:25 2008 From: john.levon at sun.com (John Levon) Date: Mon, 14 Jul 2008 21:54:25 +0100 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <487BBBEF.4020308@redhat.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> <487BA71F.1090407@redhat.com> <20080714203542.GB28500@barman.uk.sun.com> <487BBBEF.4020308@redhat.com> Message-ID: <20080714205425.GE28500@barman.uk.sun.com> On Mon, Jul 14, 2008 at 04:49:51PM -0400, Cole Robinson wrote: > So if this user has a libvirt domain xml file and wants to convert to > vmware, we don't use a connection, and will have to use some > hardcoded conversions and defaults for libvirt->vmx. That's fine since > as far as I know there isn't a better alternative. Speaking generally, the problem that requires a connection for libvirt format applies to various other formats. If we're OK hacking around for those other formats, why not libvirt? It seems a little strange to be very picky for libvirt but not other formats. regards, john From levon at movementarian.org Mon Jul 14 20:54:55 2008 From: levon at movementarian.org (John Levon) Date: Mon, 14 Jul 2008 21:54:55 +0100 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <487BB8B3.3080305@redhat.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> <487BA71F.1090407@redhat.com> <20080714203542.GB28500@barman.uk.sun.com> <487BB8B3.3080305@redhat.com> Message-ID: <20080714205455.GJ15331@totally.trollied.org.uk> On Mon, Jul 14, 2008 at 04:36:03PM -0400, Bryan Kearney wrote: > I agree.. I could see a 2 very common use cases: > > 1) I am running on hypervisorX, and I get an image for hypervisor Y > which I want to play with. I should be able to convert Y to X without > having Y running in my enterprise. > > 2) I am building appliances, and I want to support hypervisor Y. I > should be able to build for my internal X and then convert to Y. For anything libvirt-supported, producing virt-image output would be the /best/ way to deal with these use cases. But indeed, for anything machine-specific Y, we will /have/ to have a non-connection backup. My argument is essentially that it's silly not to have a backup approach for libvirt too. If it becomes infeasible with device models or whatever in the future we can do: virt-convert: error: export of 'foo' in bar.xml requires a connection regards john From crobinso at redhat.com Mon Jul 14 20:55:47 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 16:55:47 -0400 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <487BB8B3.3080305@redhat.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> <487BA71F.1090407@redhat.com> <20080714203542.GB28500@barman.uk.sun.com> <487BB8B3.3080305@redhat.com> Message-ID: <487BBD53.6020105@redhat.com> Bryan Kearney wrote: >> Hmm. I don't think that's a big deal now at all (since virt-install is >> already encoding all this stuff *anyway*). But I thought about it, and >> you're right. This could become very tricky in the future. >> >> However, there's still a problem I'm not sure how to deal with: general >> export. In this case we might not even be exporting to a format that >> libvirt can even *deal* with, never mind one that's on the other end of >> the connection. What do we do in this case? >> >> How can I export to .vmx without hard-coding some stuff based upon >> command-line options? Do we require a connection for this, and try to >> work out defaults based on the connection anyway? This is less >> than ideal: consider the poor user who's not booted under Xen, and wants >> to import his Xen VM into VMWare on that machine. > > I agree.. I could see a 2 very common use cases: > > 1) I am running on hypervisorX, and I get an image for hypervisor Y > which I want to play with. I should be able to convert Y to X without > having Y running in my enterprise. So if you download vmx and are on libvirt, you have an active connection available which you can pass to virt-convert. If you are on vmware and download libvirt, a connection won't be required for conversion so this also would work fine. > > 2) I am building appliances, and I want to support hypervisor Y. I > should be able to build for my internal X and then convert to Y. > >From the appliance perspective, portability is key. Unfortunately, libvirt domain xml is not portable. So the case of converting TO libvirt xml is not relevant here. So if you build a libvirt domain, you can then export to vmx or virt-image format without needing any special connections as mentioned above. So I think requiring the libvirt connection for domain xml export doesn't impede these use cases. - Cole From crobinso at redhat.com Mon Jul 14 21:11:00 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 17:11:00 -0400 Subject: [et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter In-Reply-To: <20080714205425.GE28500@barman.uk.sun.com> References: <112cd8c4aa97e9da9d75.1215697721@joos> <487B84FB.1050204@redhat.com> <20080714184547.GH15331@totally.trollied.org.uk> <487BA71F.1090407@redhat.com> <20080714203542.GB28500@barman.uk.sun.com> <487BBBEF.4020308@redhat.com> <20080714205425.GE28500@barman.uk.sun.com> Message-ID: <487BC0E4.4070800@redhat.com> John Levon wrote: > On Mon, Jul 14, 2008 at 04:49:51PM -0400, Cole Robinson wrote: > > >> So if this user has a libvirt domain xml file and wants to convert to >> vmware, we don't use a connection, and will have to use some >> hardcoded conversions and defaults for libvirt->vmx. That's fine since >> as far as I know there isn't a better alternative. > > Speaking generally, the problem that requires a connection for libvirt > format applies to various other formats. If we're OK hacking around for > those other formats, why not libvirt? It seems a little strange to be > very picky for libvirt but not other formats. > The reason we are picky with libvirt is because we _can_be_. Point me at an alternative for hardcoding defaults for other formats and we can consider them. I'm comparatively ignorant on the amount of ways a vmx file can work on one machine and fail on another. Perhaps the sensible solution is to require the host to have a full fledged vmware setup to convert _to_ that format. The difference is really small: say I'm on a xen host and want to convert a xen machine to vmware. If we DONT require an active vmware connection/ setup, then we run virt-convert on the xen config, reboot into regular kernel/vmware, and run the converted config. The other way: start on xen, dump the config to a file. Reboot into vmware, run virt-convert on the xen config to convert to vmx, then import. If we have the means, I would definitely say go with version 2, since the info we can glean from the active connection will reduce maintainance burden and produce more accurate results. Someone would probably be pretty pissed if they converted, rebooted, tried to run the config and it failed. So in actuality, the warning about 'this config will only work for this host/connection' may very well apply to vmx exports as well. I'm just not familiar enough with the format to say for sure. - Cole From crobinso at redhat.com Mon Jul 14 22:50:25 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Jul 2008 18:50:25 -0400 Subject: [et-mgmt-tools] Recursive distro delete trying to remove a profile more than once? In-Reply-To: References: Message-ID: <487BD831.1010209@redhat.com> Charles Duffy wrote: > Howdy. I'm trying to remove a number of distros and profiles, and > hitting exceptions similar to the following: > > Traceback (most recent call last): > File "cobbler_sync.py", line 132, in run > cobbler_api.distros().remove(distro.name, with_delete=True, > recursive=True) > File > "/usr/lib/python2.4/site-packages/cobbler/collection_distros.py", line > 51, in remove > self.config.api.remove_profile(k, recursive=True) > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 176, in > remove_profile > return self._config.profiles().remove(ref.name, recursive=recursive) > File > "/usr/lib/python2.4/site-packages/cobbler/collection_profiles.py", line > 70, in remove > raise CX(_("cannot delete an object that does not exist: %s") % name) > cobbler.cexceptions.CX: 'cannot delete an object that does not exist: > centos-5.1-xen-x86_64' > > > The calling code looks like the following: > > for distro in list(cobbler_api.distros()): > if not cobbler_api.find_distro(distro.name): > continue # we've been removed by a recursive delete > if not distro.name in desired_distro_list: > logger.info('removing distro %r' % (distro.name,)) > if not noop: > cobbler_api.distros().remove(distro.name, with_delete=True, > recursive=True) > > This issue is reproduced after the import of a new distribution. > Cobbler moved to its own list at: https://fedorahosted.org/mailman/listinfo/cobbler So you'll probably want to move your question there. - Cole From bleanhar at redhat.com Wed Jul 16 00:05:16 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Tue, 15 Jul 2008 20:05:16 -0400 Subject: [et-mgmt-tools] strange virt-install/koan issue Message-ID: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> I've recently upgraded a machine to F9 (fresh install) and I'm hitting a strange virt-install/koan issue. The machine is i386 and HVM is enabled in the BIOS. Running "virt-install" with no arguments yields: "Unsupported virtualization type". Running with the "--hvm" flag works as expected. In the past virt-install had always done the right thing whenever KVM was the only option. The only reason I suspect my koan problem is related is simply because of the error message, and that koan uses virt-install. The Virt host is running F9 with KVM. Here is the output from koan: koan -s [my cobbler server] --virt --virt-type=qemu --virt-path=/images --profile Fedora9-i386 --virt-name=bleanhar1-koan --virt-bridge=br0 - reading URL: http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 install_tree: http://10.11.227.63/cblr/links/Fedora9-i386 libvirtd (pid 2897) is running... - using qemu hypervisor, type=kvm - adding disk: /images/bleanhar1-koan-disk0 of size 5 libvir: QEMU error : Domain not found libvir: QEMU error : Domain not found libvir: QEMU error : internal error unsupported architecture ... File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 866, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib/python2.5/site-packages/libvirt.py", line 841, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) Any thoughts on what could cause the "Unsupported virtualization type" and the "unsupported architecture" errors? I've already triple checked that the guest being installed is i386 and that "virt-install --hvm" actually works. --Brenton From bleanhar at redhat.com Wed Jul 16 12:19:35 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 16 Jul 2008 08:19:35 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <20080716121935.GB23377@tumbolia-jboss-dev.usersys.redhat.com> +++ Brenton Leanhardt [15/07/08 20:05 -0400]: > I've recently upgraded a machine to F9 (fresh install) and I'm hitting > a strange virt-install/koan issue. The machine is i386 and HVM is > enabled in the BIOS. > > Running "virt-install" with no arguments yields: "Unsupported > virtualization type". Running with the "--hvm" flag works as > expected. In the past virt-install had always done the right thing > whenever KVM was the only option. I must have been confused about the virt-install functionality. After a quick look at the code it looks like it simply defaults to 'xen' for the os_type whenever you don't specify '--hvm' on the command line, hence the "Unsupported virtualization type" error. Now to debug the error from koan since all the virt-install stuff was really just yak shaving. > > The only reason I suspect my koan problem is related is simply because > of the error message, and that koan uses virt-install. The Virt host > is running F9 with KVM. Here is the output from koan: > > koan -s [my cobbler server] --virt --virt-type=qemu > --virt-path=/images --profile Fedora9-i386 --virt-name=bleanhar1-koan > --virt-bridge=br0 - reading URL: > http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 > install_tree: http://10.11.227.63/cblr/links/Fedora9-i386 > libvirtd (pid 2897) is running... > - using qemu hypervisor, type=kvm > - adding disk: /images/bleanhar1-koan-disk0 of size 5 > libvir: QEMU error : Domain not found > libvir: QEMU error : Domain not found > libvir: QEMU error : internal error unsupported architecture ... > File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line > 866, in _do_install > self.domain = self.conn.createLinux(install_xml, 0) > File "/usr/lib/python2.5/site-packages/libvirt.py", line 841, in > createLinux > if ret is None:raise libvirtError('virDomainCreateLinux() failed', > conn=self) > > > > > Any thoughts on what could cause the "Unsupported virtualization type" > and the "unsupported architecture" errors? I've already triple > checked that the guest being installed is i386 and that "virt-install > --hvm" actually works. > > --Brenton From bleanhar at redhat.com Wed Jul 16 12:38:43 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 16 Jul 2008 08:38:43 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716121935.GB23377@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716121935.GB23377@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <20080716123843.GC23377@tumbolia-jboss-dev.usersys.redhat.com> +++ Brenton Leanhardt [16/07/08 08:19 -0400]: > +++ Brenton Leanhardt [15/07/08 20:05 -0400]: >> I've recently upgraded a machine to F9 (fresh install) and I'm hitting >> a strange virt-install/koan issue. The machine is i386 and HVM is >> enabled in the BIOS. >> >> Running "virt-install" with no arguments yields: "Unsupported >> virtualization type". Running with the "--hvm" flag works as >> expected. In the past virt-install had always done the right thing >> whenever KVM was the only option. > > I must have been confused about the virt-install functionality. After > a quick look at the code it looks like it simply defaults to 'xen' for > the os_type whenever you don't specify '--hvm' on the command line, > hence the "Unsupported virtualization type" error. > > Now to debug the error from koan since all the virt-install stuff was > really just yak shaving. >> >> The only reason I suspect my koan problem is related is simply because >> of the error message, and that koan uses virt-install. The Virt host >> is running F9 with KVM. Here is the output from koan: >> >> koan -s [my cobbler server] --virt --virt-type=qemu >> --virt-path=/images --profile Fedora9-i386 --virt-name=bleanhar1-koan >> --virt-bridge=br0 - reading URL: >> http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 >> install_tree: http://10.11.227.63/cblr/links/Fedora9-i386 >> libvirtd (pid 2897) is running... >> - using qemu hypervisor, type=kvm >> - adding disk: /images/bleanhar1-koan-disk0 of size 5 >> libvir: QEMU error : Domain not found >> libvir: QEMU error : Domain not found >> libvir: QEMU error : internal error unsupported architecture ... >> File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line >> 866, in _do_install >> self.domain = self.conn.createLinux(install_xml, 0) >> File "/usr/lib/python2.5/site-packages/libvirt.py", line 841, in >> createLinux >> if ret is None:raise libvirtError('virDomainCreateLinux() failed', >> conn=self) >> >> >> >> >> Any thoughts on what could cause the "Unsupported virtualization type" >> and the "unsupported architecture" errors? I've already triple >> checked that the guest being installed is i386 and that "virt-install >> --hvm" actually works. >> >> --Brenton I've attached the xml Koan is passing to virtinst. I can take koan out of the picture and simply try to create the guest with virsh and I get the exact same error. Here's more host info: [root at dhcp227-200 ~]# uname -a Linux dhcp227-200.rdu.redhat.com 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 20:46:03 EDT 2008 i686 i686 i386 GNU/Linux [root at dhcp227-200 ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5410 @ 2.33GHz stepping : 6 cpu MHz : 2327.632 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca sse4_1 lahf_lm bogomips : 4657.93 clflush size : 64 There are a total of 8 processors, but their info is all the same obviously. -------------- next part -------------- A non-text attachment was scrubbed... Name: bleanhar1-koan.xml Type: text/xml Size: 1118 bytes Desc: not available URL: From bleanhar at redhat.com Wed Jul 16 13:27:03 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 16 Jul 2008 09:27:03 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716123843.GC23377@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716121935.GB23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716123843.GC23377@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <20080716132703.GD23377@tumbolia-jboss-dev.usersys.redhat.com> +++ Brenton Leanhardt [16/07/08 08:38 -0400]: > +++ Brenton Leanhardt [16/07/08 08:19 -0400]: >> +++ Brenton Leanhardt [15/07/08 20:05 -0400]: >>> I've recently upgraded a machine to F9 (fresh install) and I'm hitting >>> a strange virt-install/koan issue. The machine is i386 and HVM is >>> enabled in the BIOS. >>> >>> Running "virt-install" with no arguments yields: "Unsupported >>> virtualization type". Running with the "--hvm" flag works as >>> expected. In the past virt-install had always done the right thing >>> whenever KVM was the only option. >> >> I must have been confused about the virt-install functionality. After >> a quick look at the code it looks like it simply defaults to 'xen' for >> the os_type whenever you don't specify '--hvm' on the command line, >> hence the "Unsupported virtualization type" error. >> >> Now to debug the error from koan since all the virt-install stuff was >> really just yak shaving. >>> >>> The only reason I suspect my koan problem is related is simply because >>> of the error message, and that koan uses virt-install. The Virt host >>> is running F9 with KVM. Here is the output from koan: >>> >>> koan -s [my cobbler server] --virt --virt-type=qemu >>> --virt-path=/images --profile Fedora9-i386 --virt-name=bleanhar1-koan >>> --virt-bridge=br0 - reading URL: >>> http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 >>> install_tree: http://10.11.227.63/cblr/links/Fedora9-i386 >>> libvirtd (pid 2897) is running... >>> - using qemu hypervisor, type=kvm >>> - adding disk: /images/bleanhar1-koan-disk0 of size 5 >>> libvir: QEMU error : Domain not found >>> libvir: QEMU error : Domain not found >>> libvir: QEMU error : internal error unsupported architecture ... >>> File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line >>> 866, in _do_install >>> self.domain = self.conn.createLinux(install_xml, 0) >>> File "/usr/lib/python2.5/site-packages/libvirt.py", line 841, in >>> createLinux >>> if ret is None:raise libvirtError('virDomainCreateLinux() failed', >>> conn=self) >>> >>> >>> >>> >>> Any thoughts on what could cause the "Unsupported virtualization type" >>> and the "unsupported architecture" errors? I've already triple >>> checked that the guest being installed is i386 and that "virt-install >>> --hvm" actually works. >>> >>> --Brenton > > I've attached the xml Koan is passing to virtinst. I can take koan > out of the picture and simply try to create the guest with virsh and I > get the exact same error. Here's more host info: > > [root at dhcp227-200 ~]# uname -a > Linux dhcp227-200.rdu.redhat.com 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul > 7 20:46:03 EDT 2008 i686 i686 i386 GNU/Linux > > [root at dhcp227-200 ~]# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Xeon(R) CPU E5410 @ 2.33GHz > stepping : 6 > cpu MHz : 2327.632 > cache size : 6144 KB > physical id : 0 > siblings : 4 > core id : 0 > cpu cores : 4 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm > constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 > ssse3 cx16 xtpr dca sse4_1 lahf_lm > bogomips : 4657.93 > clflush size : 64 > > There are a total of 8 processors, but their info is all the same > obviously. Anyone know how the kernels under /var/lib/libvirt/boot get created? The xml created by koan/virt-install (attached in my previous email) references a kernel and initrd that doesn't exist on my filesystem. From mdehaan at redhat.com Wed Jul 16 15:05:04 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 Jul 2008 11:05:04 -0400 Subject: [et-mgmt-tools] strange virt-install/koan issue In-Reply-To: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <487E0E20.5090602@redhat.com> Brenton Leanhardt wrote: > I've recently upgraded a machine to F9 (fresh install) and I'm hitting > a strange virt-install/koan issue. The machine is i386 and HVM is > enabled in the BIOS. > > Running "virt-install" with no arguments yields: "Unsupported > virtualization type". Running with the "--hvm" flag works as > expected. In the past virt-install had always done the right thing > whenever KVM was the only option. > > The only reason I suspect my koan problem is related is simply because > of the error message, and that koan uses virt-install. The Virt host > is running F9 with KVM. Here is the output from koan: > > koan -s [my cobbler server] --virt --virt-type=qemu > --virt-path=/images --profile Fedora9-i386 --virt-name=bleanhar1-koan > --virt-bridge=br0 - reading URL: > http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 > install_tree: http://10.11.227.63/cblr/links/Fedora9-i386 > libvirtd (pid 2897) is running... > - using qemu hypervisor, type=kvm > - adding disk: /images/bleanhar1-koan-disk0 of size 5 > libvir: QEMU error : Domain not found > libvir: QEMU error : Domain not found > libvir: QEMU error : internal error unsupported architecture ... > File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line > 866, in _do_install > self.domain = self.conn.createLinux(install_xml, 0) > File "/usr/lib/python2.5/site-packages/libvirt.py", line 841, in > createLinux > if ret is None:raise libvirtError('virDomainCreateLinux() failed', > conn=self) > > > > > Any thoughts on what could cause the "Unsupported virtualization type" > and the "unsupported architecture" errors? I've already triple > checked that the guest being installed is i386 and that "virt-install > --hvm" actually works. > > --Brenton > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Can you share your ~/.koan/*.log and also the versions of the associated packages? This can possibly help identify what koan should be doing with the virt-install APIs, but maybe isn't, in your case. --Michael From bleanhar at redhat.com Wed Jul 16 15:13:53 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 16 Jul 2008 11:13:53 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <487E0E20.5090602@redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <487E0E20.5090602@redhat.com> Message-ID: <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> +++ Michael DeHaan [16/07/08 11:05 -0400]: > Brenton Leanhardt wrote: >> I've recently upgraded a machine to F9 (fresh install) and I'm hitting >> a strange virt-install/koan issue. The machine is i386 and HVM is >> enabled in the BIOS. >> >> Running "virt-install" with no arguments yields: "Unsupported >> virtualization type". Running with the "--hvm" flag works as >> expected. In the past virt-install had always done the right thing >> whenever KVM was the only option. >> >> The only reason I suspect my koan problem is related is simply because >> of the error message, and that koan uses virt-install. The Virt host >> is running F9 with KVM. Here is the output from koan: >> >> koan -s [my cobbler server] --virt --virt-type=qemu >> --virt-path=/images --profile Fedora9-i386 --virt-name=bleanhar1-koan >> --virt-bridge=br0 - reading URL: >> http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 >> install_tree: http://10.11.227.63/cblr/links/Fedora9-i386 >> libvirtd (pid 2897) is running... >> - using qemu hypervisor, type=kvm >> - adding disk: /images/bleanhar1-koan-disk0 of size 5 >> libvir: QEMU error : Domain not found >> libvir: QEMU error : Domain not found >> libvir: QEMU error : internal error unsupported architecture ... >> File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line >> 866, in _do_install >> self.domain = self.conn.createLinux(install_xml, 0) >> File "/usr/lib/python2.5/site-packages/libvirt.py", line 841, in >> createLinux >> if ret is None:raise libvirtError('virDomainCreateLinux() failed', >> conn=self) >> >> >> >> >> Any thoughts on what could cause the "Unsupported virtualization type" >> and the "unsupported architecture" errors? I've already triple >> checked that the guest being installed is i386 and that "virt-install >> --hvm" actually works. >> >> --Brenton >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > Can you share your ~/.koan/*.log and also the versions of the associated > packages? > > This can possibly help identify what koan should be doing with the > virt-install APIs, but maybe isn't, in your case. > > --Michael koan-1.0.1-1.fc9.noarch kvm-65-7.fc9.i386 python-virtinst-0.300.3-7.fc9.noarch kernel-2.6.25.10-86.fc9.i686 I've attached the logs though I think I finally found something interesting. I copied the temporay kernel, initrd, and xml used during the koan process. I then made one modification to the xml, removing the "arch='i386'" attribute from the os type. I noticed the xml created by the virt-install cli didn't have that so I took a shot in the dark. Seconds later I was actually able to run 'virsh start mydomain.xml' and have it work. I suspect that if we can get koan to not set that attribute it will solve my problem. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -------------- next part -------------- [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (Guest:83) Disk path not found: Assuming file disk type. [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.9DQHEB [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.PhLuK4 [Tue, 15 Jul 2008 16:07:57 koan 3813] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 16:07:58 koan 3813] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.t7JPqO [Tue, 15 Jul 2008 16:07:58 koan 3813] DEBUG (Guest:864) Creating guest from ' bleanhar1-test 1572864 1572864 3b1c82aa-8a74-3b28-8dd8-5c3b69a6effe hvm /var/lib/libvirt/boot/virtinst-vmlinuz.PhLuK4 /var/lib/libvirt/boot/virtinst-initrd.img.t7JPqO ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 16:07:58 koan 3813] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.PhLuK4 [Tue, 15 Jul 2008 16:07:58 koan 3813] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.t7JPqO [Tue, 15 Jul 2008 16:09:12 koan 3887] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 16:09:12 koan 3887] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 16:09:12 koan 3887] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 16:09:12 koan 3887] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.KkEvyz [Tue, 15 Jul 2008 16:09:12 koan 3887] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 16:09:12 koan 3887] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.t1RzQ6 [Tue, 15 Jul 2008 16:09:12 koan 3887] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 16:09:13 koan 3887] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.cBFiv7 [Tue, 15 Jul 2008 16:09:13 koan 3887] DEBUG (Guest:864) Creating guest from ' bleanhar1-test 1572864 1572864 c27bf228-4ad7-a64c-a08b-bb69e3d8f3dc hvm /var/lib/libvirt/boot/virtinst-vmlinuz.t1RzQ6 /var/lib/libvirt/boot/virtinst-initrd.img.cBFiv7 ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 16:09:13 koan 3887] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.t1RzQ6 [Tue, 15 Jul 2008 16:09:13 koan 3887] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.cBFiv7 [Tue, 15 Jul 2008 16:21:03 koan 4165] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 16:21:03 koan 4165] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 16:21:03 koan 4165] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 16:21:03 koan 4165] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.W4wWVz [Tue, 15 Jul 2008 16:21:03 koan 4165] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 16:21:03 koan 4165] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.TdP4m_ [Tue, 15 Jul 2008 16:21:03 koan 4165] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 16:21:04 koan 4165] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.8otvYi [Tue, 15 Jul 2008 16:21:04 koan 4165] DEBUG (Guest:864) Creating guest from ' bleanhar1-test 1572864 1572864 e4d9d24e-c806-d797-a7f7-6dda00a5f2dc hvm /var/lib/libvirt/boot/virtinst-vmlinuz.TdP4m_ /var/lib/libvirt/boot/virtinst-initrd.img.8otvYi ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 16:21:04 koan 4165] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.TdP4m_ [Tue, 15 Jul 2008 16:21:04 koan 4165] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.8otvYi [Tue, 15 Jul 2008 16:56:50 koan 5128] DEBUG (Guest:83) Disk path not found: Assuming file disk type. [Tue, 15 Jul 2008 16:56:50 koan 5128] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 16:56:50 koan 5128] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 16:56:50 koan 5128] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 16:56:50 koan 5128] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.AHgoNe [Tue, 15 Jul 2008 16:56:50 koan 5128] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 16:56:51 koan 5128] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.zgB5lz [Tue, 15 Jul 2008 16:56:51 koan 5128] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 16:56:51 koan 5128] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.vDpS6U [Tue, 15 Jul 2008 16:56:51 koan 5128] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.zgB5lz [Tue, 15 Jul 2008 16:56:51 koan 5128] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.vDpS6U [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (Guest:83) Disk path not found: Assuming file disk type. [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.UZ7b1f [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.6J8bLt [Tue, 15 Jul 2008 16:57:10 koan 5141] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 16:57:11 koan 5141] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.EG5veP [Tue, 15 Jul 2008 16:57:11 koan 5141] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 d3b85a7f-ec55-d7b3-8de5-6cd88e0f51d7 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.6J8bLt /var/lib/libvirt/boot/virtinst-initrd.img.EG5veP ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 16:57:11 koan 5141] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.6J8bLt [Tue, 15 Jul 2008 16:57:11 koan 5141] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.EG5veP [Tue, 15 Jul 2008 16:58:15 koan 5160] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 16:58:15 koan 5160] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 16:58:15 koan 5160] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 16:58:15 koan 5160] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.OnT18H [Tue, 15 Jul 2008 16:58:15 koan 5160] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 16:58:15 koan 5160] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.MNA1hN [Tue, 15 Jul 2008 16:58:15 koan 5160] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 16:58:16 koan 5160] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.j3kS4N [Tue, 15 Jul 2008 16:58:16 koan 5160] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 718083f1-bf51-1b8b-369d-f01b2b82d808 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.MNA1hN /var/lib/libvirt/boot/virtinst-initrd.img.j3kS4N ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 16:58:16 koan 5160] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.MNA1hN [Tue, 15 Jul 2008 16:58:16 koan 5160] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.j3kS4N [Tue, 15 Jul 2008 16:59:36 koan 5177] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 16:59:36 koan 5177] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 16:59:36 koan 5177] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 16:59:36 koan 5177] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.v4pp_b [Tue, 15 Jul 2008 16:59:36 koan 5177] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 16:59:36 koan 5177] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.nR_Ufd [Tue, 15 Jul 2008 16:59:36 koan 5177] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 16:59:37 koan 5177] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.XzquVa [Tue, 15 Jul 2008 16:59:37 koan 5177] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 479e242f-0adf-774a-3329-efeb841a2eaf hvm /var/lib/libvirt/boot/virtinst-vmlinuz.nR_Ufd /var/lib/libvirt/boot/virtinst-initrd.img.XzquVa ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 16:59:37 koan 5177] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.nR_Ufd [Tue, 15 Jul 2008 16:59:37 koan 5177] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.XzquVa [Tue, 15 Jul 2008 17:01:44 koan 5200] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:01:44 koan 5200] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:01:44 koan 5200] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:01:44 koan 5200] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo._42jGn [Tue, 15 Jul 2008 17:01:44 koan 5200] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:01:44 koan 5200] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.CCDWLi [Tue, 15 Jul 2008 17:01:44 koan 5200] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:01:45 koan 5200] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.mOAvRS [Tue, 15 Jul 2008 17:01:45 koan 5200] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 868985b3-7f5d-603d-3c6c-cb88c9000a85 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.CCDWLi /var/lib/libvirt/boot/virtinst-initrd.img.mOAvRS ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:01:45 koan 5200] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.CCDWLi [Tue, 15 Jul 2008 17:01:45 koan 5200] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.mOAvRS [Tue, 15 Jul 2008 17:11:48 koan 3305] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:11:48 koan 3305] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:11:48 koan 3305] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:11:48 koan 3305] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.n02ymJ [Tue, 15 Jul 2008 17:11:48 koan 3305] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:11:48 koan 3305] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.Xb8Pt6 [Tue, 15 Jul 2008 17:11:48 koan 3305] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:11:49 koan 3305] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.MCwZgX [Tue, 15 Jul 2008 17:11:49 koan 3305] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 5a204b49-ac95-32f1-4ed7-e47d451498c5 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.Xb8Pt6 /var/lib/libvirt/boot/virtinst-initrd.img.MCwZgX ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:11:49 koan 3305] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.Xb8Pt6 [Tue, 15 Jul 2008 17:11:49 koan 3305] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.MCwZgX [Tue, 15 Jul 2008 17:12:02 koan 3400] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:12:02 koan 3400] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:12:02 koan 3400] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:12:02 koan 3400] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.d3kQhF [Tue, 15 Jul 2008 17:12:02 koan 3400] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:12:03 koan 3400] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.h1Z0YJ [Tue, 15 Jul 2008 17:12:03 koan 3400] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:12:03 koan 3400] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.yuRGvi [Tue, 15 Jul 2008 17:12:03 koan 3400] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 3d1362ea-a97f-ff95-e181-c126ef66ca8c hvm /var/lib/libvirt/boot/virtinst-vmlinuz.h1Z0YJ /var/lib/libvirt/boot/virtinst-initrd.img.yuRGvi ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:12:03 koan 3400] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.h1Z0YJ [Tue, 15 Jul 2008 17:12:03 koan 3400] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.yuRGvi [Tue, 15 Jul 2008 17:19:38 koan 3514] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:19:38 koan 3514] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:19:38 koan 3514] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:19:38 koan 3514] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.qhyoCn [Tue, 15 Jul 2008 17:19:38 koan 3514] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:19:38 koan 3514] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.FwTgJY [Tue, 15 Jul 2008 17:19:38 koan 3514] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:19:39 koan 3514] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.umb2e_ [Tue, 15 Jul 2008 17:19:39 koan 3514] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 1da423c0-902d-c9e1-a936-689ce2428025 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.FwTgJY /var/lib/libvirt/boot/virtinst-initrd.img.umb2e_ ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:19:39 koan 3514] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.FwTgJY [Tue, 15 Jul 2008 17:19:39 koan 3514] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.umb2e_ [Tue, 15 Jul 2008 17:23:12 koan 3534] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:23:12 koan 3534] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:23:12 koan 3534] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:23:12 koan 3534] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.A3SPQ5 [Tue, 15 Jul 2008 17:23:12 koan 3534] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:23:12 koan 3534] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.pUcMGc [Tue, 15 Jul 2008 17:23:12 koan 3534] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:23:13 koan 3534] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.RCtl4i [Tue, 15 Jul 2008 17:23:13 koan 3534] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 3f1291ef-9a20-277b-c4a0-4c736c197c05 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.pUcMGc /var/lib/libvirt/boot/virtinst-initrd.img.RCtl4i ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:23:13 koan 3534] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.pUcMGc [Tue, 15 Jul 2008 17:23:13 koan 3534] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.RCtl4i [Tue, 15 Jul 2008 17:27:27 koan 3556] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:27:27 koan 3556] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:27:27 koan 3556] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:27:27 koan 3556] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.fk2NS1 [Tue, 15 Jul 2008 17:27:27 koan 3556] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:27:27 koan 3556] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.9wGRcb [Tue, 15 Jul 2008 17:27:27 koan 3556] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:27:28 koan 3556] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.6vjS3Y [Tue, 15 Jul 2008 17:27:28 koan 3556] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 f3fe38ec-6db3-435d-57e2-36108b637afa hvm /var/lib/libvirt/boot/virtinst-vmlinuz.9wGRcb /var/lib/libvirt/boot/virtinst-initrd.img.6vjS3Y ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:27:28 koan 3556] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.9wGRcb [Tue, 15 Jul 2008 17:27:28 koan 3556] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.6vjS3Y [Tue, 15 Jul 2008 17:28:51 koan 3573] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:28:51 koan 3573] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:28:51 koan 3573] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:28:51 koan 3573] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.n6vYrU [Tue, 15 Jul 2008 17:28:51 koan 3573] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:28:51 koan 3573] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.4e4NL1 [Tue, 15 Jul 2008 17:28:51 koan 3573] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:28:52 koan 3573] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.61obwZ [Tue, 15 Jul 2008 17:28:52 koan 3573] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 4fedac27-bc5d-4a6f-1e6e-373120e74fbd hvm /var/lib/libvirt/boot/virtinst-vmlinuz.4e4NL1 /var/lib/libvirt/boot/virtinst-initrd.img.61obwZ ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:28:52 koan 3573] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.4e4NL1 [Tue, 15 Jul 2008 17:28:52 koan 3573] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.61obwZ [Tue, 15 Jul 2008 17:30:49 koan 3606] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:30:49 koan 3606] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:30:49 koan 3606] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:30:49 koan 3606] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.xMytjE [Tue, 15 Jul 2008 17:30:49 koan 3606] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:30:50 koan 3606] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.1eWxtR [Tue, 15 Jul 2008 17:30:50 koan 3606] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:30:50 koan 3606] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.R_grii [Tue, 15 Jul 2008 17:30:50 koan 3606] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 5d951382-7361-f6cd-07ba-bfe2cd686343 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.1eWxtR /var/lib/libvirt/boot/virtinst-initrd.img.R_grii ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:30:50 koan 3606] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.1eWxtR [Tue, 15 Jul 2008 17:30:50 koan 3606] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.R_grii [Tue, 15 Jul 2008 17:35:02 koan 3683] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 17:35:02 koan 3683] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 17:35:02 koan 3683] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 17:35:02 koan 3683] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.ITOH3C [Tue, 15 Jul 2008 17:35:02 koan 3683] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 17:35:02 koan 3683] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.FFXhxo [Tue, 15 Jul 2008 17:35:02 koan 3683] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 17:35:03 koan 3683] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.cVdn_T [Tue, 15 Jul 2008 17:35:03 koan 3683] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 d0b50671-1fd3-2815-4da1-0b7c2f68e9ee hvm /var/lib/libvirt/boot/virtinst-vmlinuz.FFXhxo /var/lib/libvirt/boot/virtinst-initrd.img.cVdn_T ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 17:35:03 koan 3683] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.FFXhxo [Tue, 15 Jul 2008 17:35:03 koan 3683] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.cVdn_T [Tue, 15 Jul 2008 18:26:01 koan 6664] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 18:26:01 koan 6664] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 18:26:01 koan 6664] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Tue, 15 Jul 2008 18:26:01 koan 6664] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.Enr80I [Tue, 15 Jul 2008 18:26:01 koan 6664] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 18:26:02 koan 6664] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.DwhH96 [Tue, 15 Jul 2008 18:26:02 koan 6664] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 18:26:02 koan 6664] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.C0Np0h [Tue, 15 Jul 2008 18:26:02 koan 6664] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 a8c348c3-1413-adff-396d-e808b7c42488 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.DwhH96 /var/lib/libvirt/boot/virtinst-initrd.img.C0Np0h ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 18:26:02 koan 6664] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.DwhH96 [Tue, 15 Jul 2008 18:26:02 koan 6664] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.C0Np0h [Tue, 15 Jul 2008 18:41:03 koan 6154] DEBUG (DistroManager:63) Attempting to detect distro: [Tue, 15 Jul 2008 18:41:03 koan 6154] DEBUG (OSDistro:61) Detected .treeinfo file [Tue, 15 Jul 2008 18:41:03 koan 6154] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/Fedora9-i386//.treeinfo [Tue, 15 Jul 2008 18:41:03 koan 6154] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.RA_W4d [Tue, 15 Jul 2008 18:41:03 koan 6154] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/Fedora9-i386//images/pxeboot/vmlinuz [Tue, 15 Jul 2008 18:41:03 koan 6154] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.HR3IkL [Tue, 15 Jul 2008 18:41:03 koan 6154] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/Fedora9-i386//images/pxeboot/initrd.img [Tue, 15 Jul 2008 18:41:04 koan 6154] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.6VTMQ_ [Tue, 15 Jul 2008 18:41:04 koan 6154] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 524288 524288 3b01b00c-8fcd-2592-1589-24a99728fc9a hvm /var/lib/libvirt/boot/virtinst-vmlinuz.HR3IkL /var/lib/libvirt/boot/virtinst-initrd.img.6VTMQ_ ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/Fedora9-i386/ destroy destroy destroy 1 ' [Tue, 15 Jul 2008 18:41:04 koan 6154] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.HR3IkL [Tue, 15 Jul 2008 18:41:04 koan 6154] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.6VTMQ_ [Wed, 16 Jul 2008 07:25:38 koan 6380] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 07:25:38 koan 6380] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 07:25:38 koan 6380] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 07:25:38 koan 6380] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.hnaA89 [Wed, 16 Jul 2008 07:25:38 koan 6380] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 07:25:38 koan 6380] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.qIa7yL [Wed, 16 Jul 2008 07:25:38 koan 6380] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 07:25:39 koan 6380] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.tW_XnN [Wed, 16 Jul 2008 07:25:39 koan 6380] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 b940dbf6-f8b6-b960-f01d-14e4bf94124f hvm /var/lib/libvirt/boot/virtinst-vmlinuz.qIa7yL /var/lib/libvirt/boot/virtinst-initrd.img.tW_XnN ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 07:25:39 koan 6380] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.qIa7yL [Wed, 16 Jul 2008 07:25:39 koan 6380] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.tW_XnN [Wed, 16 Jul 2008 07:27:16 koan 6399] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 07:27:16 koan 6399] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 07:27:16 koan 6399] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 07:27:16 koan 6399] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.rCkQQB [Wed, 16 Jul 2008 07:27:16 koan 6399] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 07:27:16 koan 6399] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.R8l9Zz [Wed, 16 Jul 2008 07:27:16 koan 6399] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 07:27:17 koan 6399] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.iu36o0 [Wed, 16 Jul 2008 07:27:17 koan 6399] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 2a50a7a9-3979-0d6c-7f26-57b39948099b hvm /var/lib/libvirt/boot/virtinst-vmlinuz.R8l9Zz /var/lib/libvirt/boot/virtinst-initrd.img.iu36o0 ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 07:27:17 koan 6399] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.R8l9Zz [Wed, 16 Jul 2008 07:27:17 koan 6399] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.iu36o0 [Wed, 16 Jul 2008 07:36:22 koan 6435] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 07:36:22 koan 6435] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 07:36:22 koan 6435] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 07:36:22 koan 6435] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.6DG4Te [Wed, 16 Jul 2008 07:36:22 koan 6435] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 07:36:22 koan 6435] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.JKeb-M [Wed, 16 Jul 2008 07:36:22 koan 6435] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 07:36:23 koan 6435] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.FdLBL6 [Wed, 16 Jul 2008 07:36:23 koan 6435] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 8f0e8d4f-93be-f420-fcf5-0c4f4ca30d92 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.JKeb-M /var/lib/libvirt/boot/virtinst-initrd.img.FdLBL6 ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 07:36:23 koan 6435] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.JKeb-M [Wed, 16 Jul 2008 07:36:23 koan 6435] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.FdLBL6 [Wed, 16 Jul 2008 08:16:08 koan 6794] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 08:16:08 koan 6794] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 08:16:08 koan 6794] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 08:16:08 koan 6794] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.D4afPj [Wed, 16 Jul 2008 08:16:08 koan 6794] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 08:16:09 koan 6794] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.mlnhIF [Wed, 16 Jul 2008 08:16:09 koan 6794] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 08:16:09 koan 6794] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.yNBXiz [Wed, 16 Jul 2008 08:16:09 koan 6794] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 473c75d0-74be-4dbb-3a57-03abadd22932 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.mlnhIF /var/lib/libvirt/boot/virtinst-initrd.img.yNBXiz ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 08:16:09 koan 6794] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.mlnhIF [Wed, 16 Jul 2008 08:16:09 koan 6794] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.yNBXiz [Wed, 16 Jul 2008 08:17:43 koan 6810] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 08:17:43 koan 6810] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 08:17:43 koan 6810] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 08:17:43 koan 6810] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.tz8wQl [Wed, 16 Jul 2008 08:17:43 koan 6810] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 08:17:43 koan 6810] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.nP5um3 [Wed, 16 Jul 2008 08:17:43 koan 6810] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 08:17:44 koan 6810] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.huq6Im [Wed, 16 Jul 2008 08:17:44 koan 6810] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 0f983659-b6e1-9b27-7942-26e153029015 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.nP5um3 /var/lib/libvirt/boot/virtinst-initrd.img.huq6Im ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 08:17:44 koan 6810] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.nP5um3 [Wed, 16 Jul 2008 08:17:44 koan 6810] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.huq6Im [Wed, 16 Jul 2008 08:57:04 koan 6880] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 08:57:04 koan 6880] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 08:57:04 koan 6880] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 08:57:04 koan 6880] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.10iR92 [Wed, 16 Jul 2008 08:57:04 koan 6880] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 08:57:04 koan 6880] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.GqBS-n [Wed, 16 Jul 2008 08:57:04 koan 6880] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 08:57:05 koan 6880] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.H_mqzL [Wed, 16 Jul 2008 08:57:05 koan 6880] DEBUG (Guest:865) Creating guest from ' bleanhar1-koan 1572864 1572864 9ad6fea6-8469-6a59-b8b1-665e72eaa8e4 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.GqBS-n /var/lib/libvirt/boot/virtinst-initrd.img.H_mqzL ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 08:57:05 koan 6880] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.GqBS-n [Wed, 16 Jul 2008 08:57:05 koan 6880] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.H_mqzL [Wed, 16 Jul 2008 09:08:53 koan 6949] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:08:53 koan 6949] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:08:53 koan 6949] DEBUG (ImageFetcher:87) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:08:53 koan 6949] DEBUG (ImageFetcher:96) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.VCFjMM [Wed, 16 Jul 2008 09:08:53 koan 6949] DEBUG (ImageFetcher:87) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:08:53 koan 6949] DEBUG (ImageFetcher:96) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.ezWlGE [Wed, 16 Jul 2008 09:08:53 koan 6949] DEBUG (ImageFetcher:87) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:08:54 koan 6949] DEBUG (ImageFetcher:96) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.uGLQzI [Wed, 16 Jul 2008 09:08:54 koan 6949] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 2efb97e4-a906-06f4-eeb6-9575c128ba63 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.ezWlGE /var/lib/libvirt/boot/virtinst-initrd.img.uGLQzI ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:08:54 koan 6949] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.ezWlGE [Wed, 16 Jul 2008 09:08:54 koan 6949] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.uGLQzI [Wed, 16 Jul 2008 09:10:06 koan 6964] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:10:06 koan 6964] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:10:06 koan 6964] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:10:06 koan 6964] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.zt83kc [Wed, 16 Jul 2008 09:10:06 koan 6964] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:10:07 koan 6964] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.CYGZDw [Wed, 16 Jul 2008 09:10:07 koan 6964] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:10:07 koan 6964] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.ahH895 [Wed, 16 Jul 2008 09:10:07 koan 6964] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 978238c0-99c5-c0f5-5f5c-cd3a492e88db hvm /var/lib/libvirt/boot/virtinst-vmlinuz.CYGZDw /var/lib/libvirt/boot/virtinst-initrd.img.ahH895 ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:10:07 koan 6964] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.CYGZDw [Wed, 16 Jul 2008 09:10:07 koan 6964] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.ahH895 [Wed, 16 Jul 2008 09:17:16 koan 6979] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:17:16 koan 6979] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:17:16 koan 6979] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:17:16 koan 6979] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.fE3ePi [Wed, 16 Jul 2008 09:17:16 koan 6979] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:17:16 koan 6979] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.xy_KRe [Wed, 16 Jul 2008 09:17:41 koan 6979] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:17:41 koan 6979] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.JCkOde [Wed, 16 Jul 2008 09:17:42 koan 6979] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 bb7fb110-c3fd-a708-2e23-b03766c83fa5 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.xy_KRe /var/lib/libvirt/boot/virtinst-initrd.img.JCkOde ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:17:42 koan 6979] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.xy_KRe [Wed, 16 Jul 2008 09:17:42 koan 6979] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.JCkOde [Wed, 16 Jul 2008 09:18:42 koan 6994] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:18:42 koan 6994] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:18:42 koan 6994] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:18:42 koan 6994] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.ACoPZ6 [Wed, 16 Jul 2008 09:18:42 koan 6994] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:18:42 koan 6994] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.K6lWrz [Wed, 16 Jul 2008 09:18:42 koan 6994] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:18:43 koan 6994] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.4zCW0n [Wed, 16 Jul 2008 09:19:00 koan 6994] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 10ab78f1-57c8-55f2-373a-b10bbe219bee hvm /var/lib/libvirt/boot/virtinst-vmlinuz.K6lWrz /var/lib/libvirt/boot/virtinst-initrd.img.4zCW0n ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:19:00 koan 6994] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.K6lWrz [Wed, 16 Jul 2008 09:19:00 koan 6994] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.4zCW0n [Wed, 16 Jul 2008 09:20:20 koan 7009] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:20:20 koan 7009] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:20:20 koan 7009] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:20:20 koan 7009] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.gHHZKI [Wed, 16 Jul 2008 09:20:20 koan 7009] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:20:20 koan 7009] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.PLg2gA [Wed, 16 Jul 2008 09:20:20 koan 7009] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:20:21 koan 7009] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.MZ4IXa [Wed, 16 Jul 2008 09:20:34 koan 7009] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 abbe819d-fe54-9f84-066f-e7e0e253b27f hvm /var/lib/libvirt/boot/virtinst-vmlinuz.PLg2gA /var/lib/libvirt/boot/virtinst-initrd.img.MZ4IXa ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:20:34 koan 7009] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.PLg2gA [Wed, 16 Jul 2008 09:20:34 koan 7009] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.MZ4IXa [Wed, 16 Jul 2008 09:32:04 koan 7025] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:32:04 koan 7025] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:32:04 koan 7025] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:32:04 koan 7025] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.8OxDs5 [Wed, 16 Jul 2008 09:32:04 koan 7025] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:32:04 koan 7025] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.3Rs27Y [Wed, 16 Jul 2008 09:32:04 koan 7025] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:32:05 koan 7025] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.Ufvx4B [Wed, 16 Jul 2008 09:32:33 koan 7025] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 1f963929-cb0c-bc7d-fb79-8f50c04a268c hvm /var/lib/libvirt/boot/virtinst-vmlinuz.3Rs27Y /var/lib/libvirt/boot/virtinst-initrd.img.Ufvx4B ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:32:33 koan 7025] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.3Rs27Y [Wed, 16 Jul 2008 09:32:33 koan 7025] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.Ufvx4B [Wed, 16 Jul 2008 09:47:38 koan 7078] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:47:38 koan 7078] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:47:38 koan 7078] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:47:38 koan 7078] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.m5lznN [Wed, 16 Jul 2008 09:47:38 koan 7078] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:47:38 koan 7078] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.GpDTIt [Wed, 16 Jul 2008 09:47:38 koan 7078] DEBUG (ImageFetcher:88) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:47:39 koan 7078] DEBUG (ImageFetcher:97) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.CbUwsx [Wed, 16 Jul 2008 09:47:39 koan 7078] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 3f28d3cf-0482-3366-b275-27db3947f8e8 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.GpDTIt /var/lib/libvirt/boot/virtinst-initrd.img.CbUwsx ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:47:39 koan 7078] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.GpDTIt [Wed, 16 Jul 2008 09:47:39 koan 7078] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.CbUwsx [Wed, 16 Jul 2008 09:49:06 koan 7093] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:49:06 koan 7093] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:49:06 koan 7093] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:49:06 koan 7093] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.Jsq9ZV [Wed, 16 Jul 2008 09:49:06 koan 7093] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:49:06 koan 7093] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.bRCxwm [Wed, 16 Jul 2008 09:49:06 koan 7093] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:49:07 koan 7093] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.iTR7L3 [Wed, 16 Jul 2008 09:49:07 koan 7093] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 98e082b4-8000-fe7f-eb3d-8e58f4a75237 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.bRCxwm /var/lib/libvirt/boot/virtinst-initrd.img.iTR7L3 ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:49:07 koan 7093] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.bRCxwm [Wed, 16 Jul 2008 09:49:07 koan 7093] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.iTR7L3 [Wed, 16 Jul 2008 09:51:53 koan 7107] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 09:51:53 koan 7107] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 09:51:53 koan 7107] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 09:51:53 koan 7107] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.fs_AXZ [Wed, 16 Jul 2008 09:51:53 koan 7107] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 09:51:53 koan 7107] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.zdlBiy [Wed, 16 Jul 2008 09:51:53 koan 7107] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 09:51:54 koan 7107] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.KmeFMV [Wed, 16 Jul 2008 09:51:54 koan 7107] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 a4be41be-14e0-48a5-8347-32505956b8cf hvm /var/lib/libvirt/boot/virtinst-vmlinuz.zdlBiy /var/lib/libvirt/boot/virtinst-initrd.img.KmeFMV ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 09:51:54 koan 7107] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.zdlBiy [Wed, 16 Jul 2008 09:51:54 koan 7107] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.KmeFMV [Wed, 16 Jul 2008 10:02:29 koan 7190] DEBUG (DistroManager:63) Attempting to detect distro: [Wed, 16 Jul 2008 10:02:29 koan 7190] DEBUG (OSDistro:61) Detected .treeinfo file [Wed, 16 Jul 2008 10:02:29 koan 7190] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//.treeinfo [Wed, 16 Jul 2008 10:02:29 koan 7190] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-.treeinfo.gRMzaF [Wed, 16 Jul 2008 10:02:29 koan 7190] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/vmlinuz [Wed, 16 Jul 2008 10:02:30 koan 7190] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.8ZeWjp [Wed, 16 Jul 2008 10:02:30 koan 7190] DEBUG (ImageFetcher:86) Fetching URI http://10.11.227.63/cblr/links/F9-i386//images/pxeboot/initrd.img [Wed, 16 Jul 2008 10:02:30 koan 7190] DEBUG (ImageFetcher:95) Saved file to /var/lib/libvirt/boot/virtinst-initrd.img.m2qnGE [Wed, 16 Jul 2008 10:03:17 koan 7190] DEBUG (Guest:864) Creating guest from ' bleanhar1-koan 1572864 1572864 67fcf8aa-4285-832f-143f-7dce01e137b1 hvm /var/lib/libvirt/boot/virtinst-vmlinuz.8ZeWjp /var/lib/libvirt/boot/virtinst-initrd.img.m2qnGE ksdevice=eth0 lang= text ks=http://10.11.227.63/cblr/svc/op/ks/profile/Genome__Appliance-Fedora-9-i386 syslog=10.11.227.63:25150 kssendmac method=http://10.11.227.63/cblr/links/F9-i386/ destroy destroy destroy 1 ' [Wed, 16 Jul 2008 10:03:17 koan 7190] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-vmlinuz.8ZeWjp [Wed, 16 Jul 2008 10:03:17 koan 7190] DEBUG (Guest:458) Removing /var/lib/libvirt/boot/virtinst-initrd.img.m2qnGE From bleanhar at redhat.com Wed Jul 16 15:16:04 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 16 Jul 2008 11:16:04 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716132703.GD23377@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716121935.GB23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716123843.GC23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716132703.GD23377@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <20080716151604.GB27925@tumbolia-jboss-dev.usersys.redhat.com> +++ Brenton Leanhardt [16/07/08 09:27 -0400]: > +++ Brenton Leanhardt [16/07/08 08:38 -0400]: >> +++ Brenton Leanhardt [16/07/08 08:19 -0400]: >>> +++ Brenton Leanhardt [15/07/08 20:05 -0400]: >>>> I've recently upgraded a machine to F9 (fresh install) and I'm hitting >>>> a strange virt-install/koan issue. The machine is i386 and HVM is >>>> enabled in the BIOS. >>>> >>>> Running "virt-install" with no arguments yields: "Unsupported >>>> virtualization type". Running with the "--hvm" flag works as >>>> expected. In the past virt-install had always done the right thing >>>> whenever KVM was the only option. >>> >>> I must have been confused about the virt-install functionality. After >>> a quick look at the code it looks like it simply defaults to 'xen' for >>> the os_type whenever you don't specify '--hvm' on the command line, >>> hence the "Unsupported virtualization type" error. >>> >>> Now to debug the error from koan since all the virt-install stuff was >>> really just yak shaving. >>>> >>>> The only reason I suspect my koan problem is related is simply because >>>> of the error message, and that koan uses virt-install. The Virt host >>>> is running F9 with KVM. Here is the output from koan: >>>> >>>> koan -s [my cobbler server] --virt --virt-type=qemu >>>> --virt-path=/images --profile Fedora9-i386 --virt-name=bleanhar1-koan >>>> --virt-bridge=br0 - reading URL: >>>> http://10.11.227.63/cblr/svc/op/ks/profile/Fedora9-i386 >>>> install_tree: http://10.11.227.63/cblr/links/Fedora9-i386 >>>> libvirtd (pid 2897) is running... >>>> - using qemu hypervisor, type=kvm >>>> - adding disk: /images/bleanhar1-koan-disk0 of size 5 >>>> libvir: QEMU error : Domain not found >>>> libvir: QEMU error : Domain not found >>>> libvir: QEMU error : internal error unsupported architecture ... >>>> File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line >>>> 866, in _do_install >>>> self.domain = self.conn.createLinux(install_xml, 0) >>>> File "/usr/lib/python2.5/site-packages/libvirt.py", line 841, in >>>> createLinux >>>> if ret is None:raise libvirtError('virDomainCreateLinux() failed', >>>> conn=self) >>>> >>>> >>>> >>>> >>>> Any thoughts on what could cause the "Unsupported virtualization type" >>>> and the "unsupported architecture" errors? I've already triple >>>> checked that the guest being installed is i386 and that "virt-install >>>> --hvm" actually works. >>>> >>>> --Brenton >> >> I've attached the xml Koan is passing to virtinst. I can take koan >> out of the picture and simply try to create the guest with virsh and I >> get the exact same error. Here's more host info: >> >> [root at dhcp227-200 ~]# uname -a >> Linux dhcp227-200.rdu.redhat.com 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul >> 7 20:46:03 EDT 2008 i686 i686 i386 GNU/Linux >> >> [root at dhcp227-200 ~]# cat /proc/cpuinfo >> processor : 0 >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 23 >> model name : Intel(R) Xeon(R) CPU E5410 @ 2.33GHz >> stepping : 6 >> cpu MHz : 2327.632 >> cache size : 6144 KB >> physical id : 0 >> siblings : 4 >> core id : 0 >> cpu cores : 4 >> fdiv_bug : no >> hlt_bug : no >> f00f_bug : no >> coma_bug : no >> fpu : yes fpu_exception : yes >> cpuid level : 10 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca >> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm >> constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 >> ssse3 cx16 xtpr dca sse4_1 lahf_lm >> bogomips : 4657.93 >> clflush size : 64 >> >> There are a total of 8 processors, but their info is all the same >> obviously. > > Anyone know how the kernels under /var/lib/libvirt/boot get created? > The xml created by koan/virt-install (attached in my previous email) > references a kernel and initrd that doesn't exist on my filesystem. Should anyone care, that directory is the "scratchdir" used for kvm installs. The kernels and initrd are only used temporarily and are unlinked once the install starts. I don't know why the .treeinfo files aren't removed. From crobinso at redhat.com Wed Jul 16 15:35:08 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 16 Jul 2008 11:35:08 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716151604.GB27925@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716121935.GB23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716123843.GC23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716132703.GD23377@tumbolia-jboss-dev.usersys.redhat.com> <20080716151604.GB27925@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <487E152C.1090107@redhat.com> Brenton Leanhardt wrote: >> Anyone know how the kernels under /var/lib/libvirt/boot get created? >> The xml created by koan/virt-install (attached in my previous email) >> references a kernel and initrd that doesn't exist on my filesystem. > > Should anyone care, that directory is the "scratchdir" used for kvm > installs. The kernels and initrd are only used temporarily and are > unlinked once the install starts. I don't know why the .treeinfo > files aren't removed. > The lack of treeinfo file remove is a bug that is fixed upstream, just hasn't made it into a release yet. - Cole From mdehaan at redhat.com Wed Jul 16 17:45:41 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 Jul 2008 13:45:41 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <487E0E20.5090602@redhat.com> <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <487E33C5.2020409@redhat.com> > I suspect that if we can get koan to not set that > attribute it will solve my problem. >> >> _______________________________________________ >> 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 Here is what koan does in qcreate.py: if arch is not None and arch.lower() == "x86": arch = "i686" guest = virtinst.FullVirtGuest(hypervisorURI="qemu:///system",type=vtype, arch=arch) I am not sure of the ramifications of leaving off the arch or why that might be breaking things. Perhaps remove that arch bit in koan and try it? --Michael From bleanhar at redhat.com Wed Jul 16 17:54:58 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 16 Jul 2008 13:54:58 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <487E0E20.5090602@redhat.com> <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <20080716175458.GC28230@tumbolia-jboss-dev.usersys.redhat.com> +++ Brenton Leanhardt [16/07/08 11:13 -0400]: > +++ Michael DeHaan [16/07/08 11:05 -0400]: >> Brenton Leanhardt wrote: >> >> Can you share your ~/.koan/*.log and also the versions of the associated >> packages? >> >> This can possibly help identify what koan should be doing with the >> virt-install APIs, but maybe isn't, in your case. >> >> --Michael > > koan-1.0.1-1.fc9.noarch > kvm-65-7.fc9.i386 > python-virtinst-0.300.3-7.fc9.noarch > kernel-2.6.25.10-86.fc9.i686 > > I've attached the logs though I think I finally found something > interesting. > I copied the temporay kernel, initrd, and xml used during the koan > process. I then made one modification to the xml, removing the > "arch='i386'" attribute from the os type. I noticed the xml created > by the virt-install cli didn't have that so I took a shot in the dark. > Seconds later I was actually able to run 'virsh start mydomain.xml' > and have it work. I suspect that if we can get koan to not set that > attribute it will solve my problem. More interesting advancements in tracking down this issue: 1) Removing "arch='i386'" allows for kvm guests to be provisioned 2) Changing "arch='i386'" to "arch='i686'" also allows kvm guests to be provisioned on my hardware After digging through all the libraries involved in the koan process I couldn't determine a _good_ way to implement #1. As for #2 I'm starting to wonder if my problem isn't related to how 'cobbler import' works. 'i686' is not a valid architecture for cobbler distros while both 'i386' and 'x86' are. Here's something interesting from koan/qcreate.py: if arch is not None and arch.lower() == "x86": arch = "i686" Unfortuntely it seems like 'x86' is never returned from Cobbler for a profile's arch, only 'i386', therefore the arch never get's set to 'i686' in my case. As mentioned in #2, if "i686" could somehow be set, I think koan would work for me. Questions: 1) Why does a kvm guest with a 'i386' arch not work on my hardware yet 'i686' does? 2) Should "cobbler import" import 'i386' distros as 'x86'? 3) Should cobblerd return 'x86' whenever the arch is 'x86' or 'i386'? From bleanhar at redhat.com Wed Jul 16 18:01:38 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 16 Jul 2008 14:01:38 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <487E33C5.2020409@redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <487E0E20.5090602@redhat.com> <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> <487E33C5.2020409@redhat.com> Message-ID: <20080716180138.GD28230@tumbolia-jboss-dev.usersys.redhat.com> +++ Michael DeHaan [16/07/08 13:45 -0400]: > >> I suspect that if we can get koan to not set that >> attribute it will solve my problem. >>> >>> _______________________________________________ >>> 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 > > Here is what koan does in qcreate.py: > > if arch is not None and arch.lower() == "x86": > arch = "i686" > > guest = > virtinst.FullVirtGuest(hypervisorURI="qemu:///system",type=vtype, > arch=arch) > > I am not sure of the ramifications of leaving off the arch or why that > might be breaking things. Perhaps remove that arch bit in koan and try > it? > > --Michael Ha, how simple. That does indeed work for me. If that's an acceptible solution I'd love to see it make it in into a release. I'm still puzzled as to why a guest arch of 'i386' doesn't work on my hardware while 'i686' does. --Brenton > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Wed Jul 16 19:33:09 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 Jul 2008 15:33:09 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716180138.GD28230@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <487E0E20.5090602@redhat.com> <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> <487E33C5.2020409@redhat.com> <20080716180138.GD28230@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <487E4CF5.1030908@redhat.com> Brenton Leanhardt wrote: > +++ Michael DeHaan [16/07/08 13:45 -0400]: >> >>> I suspect that if we can get koan to not set that >>> attribute it will solve my problem. >>>> >>>> _______________________________________________ >>>> 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 >> >> Here is what koan does in qcreate.py: >> >> if arch is not None and arch.lower() == "x86": >> arch = "i686" >> >> guest = >> virtinst.FullVirtGuest(hypervisorURI="qemu:///system",type=vtype, >> arch=arch) >> >> I am not sure of the ramifications of leaving off the arch or why >> that might be breaking things. Perhaps remove that arch bit in koan >> and try it? >> >> --Michael > > Ha, how simple. That does indeed work for me. If that's an > acceptible solution I'd love to see it make it in into a release. > > I'm still puzzled as to why a guest arch of 'i386' doesn't work on my > hardware while 'i686' does. > > --Brenton >> >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools This is there because cobbler uses i386 as an internal representation to say "generically intel but not x86_64", though the code is set to send what libvirt wants to libvirt. IIRC, yum wants to see i386, so it's just glue there. --Michael From mdehaan at redhat.com Wed Jul 16 19:34:31 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 Jul 2008 15:34:31 -0400 Subject: [et-mgmt-tools] Re: strange virt-install/koan issue In-Reply-To: <20080716175458.GC28230@tumbolia-jboss-dev.usersys.redhat.com> References: <20080716000516.GA23377@tumbolia-jboss-dev.usersys.redhat.com> <487E0E20.5090602@redhat.com> <20080716151353.GA27925@tumbolia-jboss-dev.usersys.redhat.com> <20080716175458.GC28230@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <487E4D47.1010109@redhat.com> Brenton Leanhardt wrote: > +++ Brenton Leanhardt [16/07/08 11:13 -0400]: >> +++ Michael DeHaan [16/07/08 11:05 -0400]: > >>> Brenton Leanhardt wrote: >>> >>> Can you share your ~/.koan/*.log and also the versions of the >>> associated packages? >>> >>> This can possibly help identify what koan should be doing with the >>> virt-install APIs, but maybe isn't, in your case. >>> >>> --Michael >> >> koan-1.0.1-1.fc9.noarch >> kvm-65-7.fc9.i386 >> python-virtinst-0.300.3-7.fc9.noarch >> kernel-2.6.25.10-86.fc9.i686 >> >> I've attached the logs though I think I finally found something >> interesting. I copied the temporay kernel, initrd, and xml used >> during the koan >> process. I then made one modification to the xml, removing the >> "arch='i386'" attribute from the os type. I noticed the xml created >> by the virt-install cli didn't have that so I took a shot in the dark. >> Seconds later I was actually able to run 'virsh start mydomain.xml' >> and have it work. I suspect that if we can get koan to not set that >> attribute it will solve my problem. > > > More interesting advancements in tracking down this issue: > > 1) Removing "arch='i386'" allows for kvm guests to be > provisioned > 2) Changing "arch='i386'" to "arch='i686'" also allows kvm guests to > be provisioned on my hardware > > After digging through all the libraries involved in the koan process I > couldn't determine a _good_ way to implement #1. As for #2 I'm > starting to wonder if my problem isn't related to how 'cobbler import' > works. 'i686' is not a valid architecture for cobbler distros while both > 'i386' and 'x86' are. > Here's something interesting from koan/qcreate.py: > > if arch is not None and arch.lower() == "x86": > arch = "i686" > > Unfortuntely it seems like 'x86' is never returned from Cobbler for a > profile's arch, only 'i386', therefore the arch never get's set to > 'i686' in my case. As mentioned in #2, if "i686" could somehow be > set, I think koan would work for me. > Questions: > 1) Why does a kvm guest with a 'i386' arch not work on my hardware yet > 'i686' does? > 2) Should "cobbler import" import 'i386' distros as 'x86'? > 3) Should cobblerd return 'x86' whenever the arch is 'x86' or 'i386'? Questions aside, basically it's about making sure we always send i686 and not the internal arch storage. The reasons for this internal storage are really not that important, so I'll take care of this. Thanks! --Michael. From john.levon at sun.com Thu Jul 17 18:56:51 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 17 Jul 2008 11:56:51 -0700 Subject: [et-mgmt-tools] [PATCH] virt-convert: fix Python 2.4 compatibility Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1216320992 25200 # Node ID cdab3fd5617c32955e16b9bf9cf1d121634746ec # Parent cd648dc6a9492fe3b703e5ebc7f43d05bb03adeb virt-convert: fix Python 2.4 compatibility Sadly, pkgutil.iter_modules() is new in Python 2.5, so the automatic module finding code won't work in 2.4. Add hard-coded fallbacks for Python 2.4 and earlier. Signed-off-by: John Levon diff --git a/virtconv/__init__.py b/virtconv/__init__.py --- a/virtconv/__init__.py +++ b/virtconv/__init__.py @@ -24,6 +24,15 @@ parsers_path = [os.path.join(__path__[0], "parsers/")] -for loader, name, ispkg in pkgutil.iter_modules(parsers_path): +# iter_modules is only in Python 2.5, sadly +parser_names = [ "vmx", "virtimage" ] + +if hasattr(pkgutil, "iter_modules"): + print "here" + parser_names = [] + for _, name, _ in pkgutil.iter_modules(parsers_path): + parser_names += [ name ] + +for name in parser_names: filename, pathname, desc = imp.find_module(name, parsers_path) imp.load_module(name, filename, pathname, desc) From crobinso at redhat.com Thu Jul 17 19:07:08 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 17 Jul 2008 15:07:08 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: fix Python 2.4 compatibility In-Reply-To: References: Message-ID: <487F985C.2090304@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1216320992 25200 > # Node ID cdab3fd5617c32955e16b9bf9cf1d121634746ec > # Parent cd648dc6a9492fe3b703e5ebc7f43d05bb03adeb > virt-convert: fix Python 2.4 compatibility > > Sadly, pkgutil.iter_modules() is new in Python 2.5, so the automatic > module finding code won't work in 2.4. Add hard-coded fallbacks for Python 2.4 > and earlier. > > Signed-off-by: John Levon > > diff --git a/virtconv/__init__.py b/virtconv/__init__.py > --- a/virtconv/__init__.py > +++ b/virtconv/__init__.py > @@ -24,6 +24,15 @@ > > parsers_path = [os.path.join(__path__[0], "parsers/")] > > -for loader, name, ispkg in pkgutil.iter_modules(parsers_path): > +# iter_modules is only in Python 2.5, sadly > +parser_names = [ "vmx", "virtimage" ] > + > +if hasattr(pkgutil, "iter_modules"): > + print "here" Probably didn't mean to include this line. > + parser_names = [] > + for _, name, _ in pkgutil.iter_modules(parsers_path): Please use something other than '_' here as previously mentioned. - Cole > + parser_names += [ name ] > + > +for name in parser_names: > filename, pathname, desc = imp.find_module(name, parsers_path) > imp.load_module(name, filename, pathname, desc) > From john.levon at sun.com Thu Jul 17 21:07:25 2008 From: john.levon at sun.com (John Levon) Date: Thu, 17 Jul 2008 22:07:25 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: fix Python 2.4 compatibility In-Reply-To: <487F985C.2090304@redhat.com> References: <487F985C.2090304@redhat.com> Message-ID: <20080717210725.GA2806@barman.uk.sun.com> On Thu, Jul 17, 2008 at 03:07:08PM -0400, Cole Robinson wrote: > > +if hasattr(pkgutil, "iter_modules"): > > + print "here" > > Probably didn't mean to include this line. Sigh, sorry. > > + parser_names = [] > > + for _, name, _ in pkgutil.iter_modules(parsers_path): > > Please use something other than '_' here as previously > mentioned. Even for obviously internal only files like this? Will do. Will resend shortly. regards john From crobinso at redhat.com Thu Jul 17 21:19:28 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 17 Jul 2008 17:19:28 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: fix Python 2.4 compatibility In-Reply-To: <20080717210725.GA2806@barman.uk.sun.com> References: <487F985C.2090304@redhat.com> <20080717210725.GA2806@barman.uk.sun.com> Message-ID: <487FB760.8040309@redhat.com> John Levon wrote: >>> + parser_names = [] >>> + for _, name, _ in pkgutil.iter_modules(parsers_path): >> Please use something other than '_' here as previously >> mentioned. > > Even for obviously internal only files like this? Will do. > Yeah, I (wrongly) thought that this could stomp '_' in any files that imported it but I wasn't thinking clearly. - Cole From john.levon at sun.com Thu Jul 17 21:30:34 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 17 Jul 2008 14:30:34 -0700 Subject: [et-mgmt-tools] [PATCH] virt-convert: fix Python 2.4 compatibility Message-ID: <2ff8e5fe0868cf18643e.1216330234@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1216330222 25200 # Node ID 2ff8e5fe0868cf18643e1d7d2455d479c9379f44 # Parent cd648dc6a9492fe3b703e5ebc7f43d05bb03adeb virt-convert: fix Python 2.4 compatibility Sadly, pkgutil.iter_modules() is new in Python 2.5, so the automatic module finding code won't work in 2.4. Add hard-coded fallbacks for Python 2.4 and earlier. Signed-off-by: John Levon diff --git a/virtconv/__init__.py b/virtconv/__init__.py --- a/virtconv/__init__.py +++ b/virtconv/__init__.py @@ -24,6 +24,14 @@ parsers_path = [os.path.join(__path__[0], "parsers/")] -for loader, name, ispkg in pkgutil.iter_modules(parsers_path): +# iter_modules is only in Python 2.5, sadly +parser_names = [ "vmx", "virtimage" ] + +if hasattr(pkgutil, "iter_modules"): + parser_names = [] + for ignore, name, ignore in pkgutil.iter_modules(parsers_path): + parser_names += [ name ] + +for name in parser_names: filename, pathname, desc = imp.find_module(name, parsers_path) imp.load_module(name, filename, pathname, desc) From crobinso at redhat.com Tue Jul 22 16:19:39 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 22 Jul 2008 12:19:39 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: fix Python 2.4 compatibility In-Reply-To: <2ff8e5fe0868cf18643e.1216330234@xenbld> References: <2ff8e5fe0868cf18643e.1216330234@xenbld> Message-ID: <4886089B.7030800@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1216330222 25200 > # Node ID 2ff8e5fe0868cf18643e1d7d2455d479c9379f44 > # Parent cd648dc6a9492fe3b703e5ebc7f43d05bb03adeb > virt-convert: fix Python 2.4 compatibility > > Sadly, pkgutil.iter_modules() is new in Python 2.5, so the automatic > module finding code won't work in 2.4. Add hard-coded fallbacks for Python 2.4 > and earlier. > > Signed-off-by: John Levon > > diff --git a/virtconv/__init__.py b/virtconv/__init__.py > --- a/virtconv/__init__.py > +++ b/virtconv/__init__.py > @@ -24,6 +24,14 @@ > > parsers_path = [os.path.join(__path__[0], "parsers/")] > > -for loader, name, ispkg in pkgutil.iter_modules(parsers_path): > +# iter_modules is only in Python 2.5, sadly > +parser_names = [ "vmx", "virtimage" ] > + > +if hasattr(pkgutil, "iter_modules"): > + parser_names = [] > + for ignore, name, ignore in pkgutil.iter_modules(parsers_path): > + parser_names += [ name ] > + > +for name in parser_names: > filename, pathname, desc = imp.find_module(name, parsers_path) > imp.load_module(name, filename, pathname, desc) > Okay, looks good. I've committed this: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=2ff8e5fe0868 Thanks, Cole From crobinso at redhat.com Wed Jul 23 15:50:51 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 23 Jul 2008 11:50:51 -0400 Subject: [et-mgmt-tools] [PATCH] virt-install: add --wait option Message-ID: <4887535B.1090104@redhat.com> The attached patch adds a --wait option to virt-install, which forces the app to watch the install for a specified number of minutes. If the time limit is exceeded, we simply exit the app, leaving the domain in whatever state it is in. If the vm shuts down as expected, the app continues as usual. The time limit is regardless of whether a console has been specified or if one has already closed. A negative value implies waiting indefinitely, and a value of 0 is the same as not specifying --wait at all. Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-wait-option-patch URL: From crobinso at redhat.com Wed Jul 23 15:51:40 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 23 Jul 2008 11:51:40 -0400 Subject: [et-mgmt-tools] [RFC] virtinst: build libvirt storage xml Message-ID: <4887538C.7090508@redhat.com> I've been working on a virtinst API to build and install xml for libvirt storage objects. The current version is attached: so far only nfs, filesystem and dir pools are implemented, as well as their associated file volumes, but the remainder will be mostly a cut and paste job. I have some UI wizards for building these in virt-manager mostly complete, so this has been tested to be pretty solid, though there is still some clean up that needs doing. The general workflow is as follows: ========================================= import virtinst.Storage.StoragePool as sp # This gives the appropriate class for the specified pool type pool_class = sp.get_pool_class(sp.TYPE_FOO) # Only required params are a conn/uri and name. Default formats # and target paths have default values, but source paths/ # devices and hostnames obviously have no sensible default, but # they still aren't required for object instantiation pool = pool_class(name="foo", uri="xen:///") pool.source_path = "/dev/foo" etc. # Prints xml config: will error if all required members aren't # specified pool.get_xml_config() # Attempts to install and build pool on the passed connection poolobj = pool.install() # Will return appropriate volume class for this pool type vol_class = pool.get_volume_class() # For volumes, we require a pool instead of conn/uri, as well # as name and capacity vol = vol_class(name="volfoo", pool=poolobj) volobj = vol.install() ===================================== An active connection/URI/pool object is required. I figure there isn't a real use case for wanting to generate xml on a machine without a libvirt setup, and this will ensure in the future we can check against capabilities xml, make sure we aren't colliding names and other things. I think the implemented code covers most of the different cases for generating storage xml, with the exception of username and password for iscsi: I see this in the libvirt code but this isn't documented anywhere, so I'm not sure if their are any real catches. Comments welcome. Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Storage.py URL: From drew.einhorn at gmail.com Thu Jul 24 04:43:53 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Wed, 23 Jul 2008 22:43:53 -0600 Subject: [et-mgmt-tools] Fwd: remote virtual terminals In-Reply-To: References: Message-ID: Hi, I have a bunch of software that is not playing well together. I have Hardy Heron laptotp with a ssh connection to a remote RHEL5 Xen Dom0. I'm using cobbler/koan attempting to provision RHEL5 DomU vitual machines. I run koan --virt --nogfx ... on the Dom0 and it sucessfully starts the new DomU VM. I successfully connect to the VM using virsh on the Dom0 via the ssh connection from my Hardy laptop. The RHEL5 installer attempts to set up networking using DHCP and runs astray. I need to do Ctl-Alt-Fn to access alternate Virtual Consoles on the virsh console on the DomU to troubleshoot the DHCP issue. But the Hardy laptop is catching the Ctrl-Alt-Fn and presenting alternate Virtual Consoles on the laptop instead of sending to them to the remote virsh console. through the ssh connection Is there a better way to get access to a shell and a bunch of logs on the DomU. -- Drew Einhorn -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From gwiener at aenigmacorp.com Thu Jul 24 10:13:28 2008 From: gwiener at aenigmacorp.com (Geoff Wiener) Date: Thu, 24 Jul 2008 11:13:28 +0100 Subject: [et-mgmt-tools] Virt-Manager, libvirt & TLS Message-ID: <89ADFB63BC286B49BC71F1D34A7E38D612D9E2@EXVS01.aenigmacorp.com> Hi! This is my first post to either of these list, I have been lurking, (sorry to cross post but I don't know if this is a virt-manager or libvirt question). So first off thank you to everyone for all your efforts. I think libvirt and virt-manager are excellent! I've built a pair of server s in the lab with a Xen stack and have been attempting to get virt-manager 0.5.4 to communicate with, first libvirt 0.4.2 and then libvirt 0.4.4 using TLS across the network in a "client / server" configuration unsuccessfully. All the machines are on the same subnet (192.168.4.x/24). I can make Virt-Manager communicate with Libvirt over TCP without authentication so now that I know the installation works I want to further secure it using TLS. I've read everything I can get my hands on, subscribe to the lists and feel that I must be making a simple error ;I could really use a fresh perspective. I would really appreciate any feedback you can offer. Here's my configuration and testing method. Workstation Ubuntu Hardy Heron 64 bit Virt-manager 0.5.4 Server Distribution = CentOS 5.1 (64 bit) Kernel = 2.6.18.8-xen (compiled from source) Xen = 3.2.1.gz virsh # version Compiled against library: libvir 0.4.4 Using library: libvir 0.4.4 Using API: Xen 3.0.1 Running hypervisor: Xen 3.2.0 /usr/local/etc/libvirt/libvirtd.conf Listen_tcp = 1 auth_unix_ro = "none" auth_unix_rw="none" auth_tcp="none" In this configuration I can use "Remove Password or Kerberos" to connect. I just enter the hostname of the Xen machine and Virt-Manager lets me see all the Domains that are running (or shutdown if I virsh define them) as well as look at their consoles (if the vfb is configured correctly). I followed the configuration notes at: http://libvirt.org/remote.html with a couple of exceptions: 1. I already have a linux based CA that I use with OpenVPN so I used that CA root certificate and just generated client and server cert / key pairs for my client and server (I tested with just one server) 2. I reverted back to the default libvirtd.conf to setup for TLS and noticed that the default paths for the certificate locations were not in line with the documentation on the web page but there were commented sections as follows that matched the documentation, so I uncommented them: key_file = "/etc/pki/libvirt/private/serverkey.pem" cert_file = "/etc/pki/libvirt/servercert.pem" ca_file = "/etc/pki/CA/cacert.pem" #crl_file = "/etc/pki/CA/crl.pem" Note: I did not uncomment the CRL_FILE path as I do not want to use a CRL at this time 3. On the server I execute "libvirtd -listen -verbose" (libvirtd output) attached 4. virt-manager 0.5.4 (as root) , File, Open Connection Hypervisor: Xen Connection: Remote SSL/TLS with x509 certificate Hostname: vxen-01.aenigmacorp.com (I have a host entry for this machine) The virt-manager console reports "unable to open a connection to the libvirt management daemon". Verify that the "libvirtd" daemon has been started. Then, in details there is a lot of info (see virt-manager output) 5. If I tail /root/.virt-manager/virt-manager.log I get the following output (see virt-manager.log) That about sums it up. I have not read any instructions that ask me to copy the CA root certificate to the client, is that required? And if so where would I put it. Also, whenever I attempt to connect there are no errors appearing in the libvirtd output, which is a bit surprising. I would have expected that by using -verbose on the libvirtd command line that i would see more info. Lin 94 in the libvirt.py script is definitely trying to do some kind of authentication but I don't really know what to do to troubleshot this next? I still don't know if my issue is related to the client or the server? Any advice would be greatly appreciated. Many thanks Geoff Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libvirtd output Type: application/octet-stream Size: 5047 bytes Desc: libvirtd output URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager output Type: application/octet-stream Size: 523 bytes Desc: virt-manager output URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager.log Type: application/octet-stream Size: 1697 bytes Desc: virt-manager.log URL: From berrange at redhat.com Thu Jul 24 11:18:35 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Jul 2008 12:18:35 +0100 Subject: [et-mgmt-tools] Virt-Manager, libvirt & TLS In-Reply-To: <89ADFB63BC286B49BC71F1D34A7E38D612D9E2@EXVS01.aenigmacorp.com> References: <89ADFB63BC286B49BC71F1D34A7E38D612D9E2@EXVS01.aenigmacorp.com> Message-ID: <20080724111835.GS1138@redhat.com> On Thu, Jul 24, 2008 at 11:13:28AM +0100, Geoff Wiener wrote: > Hi! > > > > This is my first post to either of these list, I have been lurking, > (sorry to cross post but I don't know if this is a virt-manager or > libvirt question). So first off thank you to everyone for all your > efforts. I think libvirt and virt-manager are excellent! I've built > a pair of server s in the lab with a Xen stack and have been attempting > to get virt-manager 0.5.4 to communicate with, first libvirt 0.4.2 and > then libvirt 0.4.4 using TLS across the network in a "client / server" > configuration unsuccessfully. All the machines are on the same subnet > (192.168.4.x/24). I can make Virt-Manager communicate with Libvirt > over TCP without authentication so now that I know the installation > works I want to further secure it using TLS. > > /usr/local/etc/libvirt/libvirtd.conf > > > > Listen_tcp = 1 > > auth_unix_ro = "none" > > auth_unix_rw="none" > > auth_tcp="none" That's all fine. > I followed the configuration notes at: http://libvirt.org/remote.html with a couple of exceptions: > > 1. I already have a linux based CA that I use with OpenVPN so I used that CA root certificate and just generated client and server cert / key pairs for my client and server (I tested with just one server) That's fine - any CA will do the job. > 2. I reverted back to the default libvirtd.conf to setup for TLS and > noticed that the default paths for the certificate locations were not in > line with the documentation on the web page but there were commented sections > as follows that matched the documentation, so I uncommented them: > > key_file = "/etc/pki/libvirt/private/serverkey.pem" > cert_file = "/etc/pki/libvirt/servercert.pem" > ca_file = "/etc/pki/CA/cacert.pem" No need to uncomment any of these - its fine to use the the default settings built-in to libvirt > > #crl_file = "/etc/pki/CA/crl.pem" > Note: I did not uncomment the CRL_FILE path as I do not want to use a CRL at this time Ok, no problem there. > 3. On the server I execute "libvirtd -listen -verbose" (libvirtd output) attached > > 4. virt-manager 0.5.4 (as root) , File, Open Connection > Hypervisor: Xen > > Connection: Remote SSL/TLS with x509 certificate > > Hostname: vxen-01.aenigmacorp.com (I have a host entry for this machine) > > > > The virt-manager console reports "unable to open a connection to the libvirt > management daemon". Verify that the "libvirtd" daemon has been started. Then, > in details there is a lot of info (see virt-manager output) I'd recommend getting it working using virsh as a client first - this gives clearer diagnostics. Once virsh is working, then virt-manager should just work too, although it has an extra step required for VNC access. > That about sums it up. I have not read any instructions that ask me to copy > the CA root certificate to the client, is that required? And if so where would > I put it. Yes, the CA certificate needs to be on all machines - in the same location as for the server - /etc/pki/CA/cacert.pem. The client server needs to be in the loication /etc/pki/libvirt/clientcert.pem There are some additional docs on the virt-manager wiki about the VNC setup steps too http://virt-manager.org/page/RemoteTLS Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Thu Jul 24 12:17:06 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Jul 2008 13:17:06 +0100 Subject: [et-mgmt-tools] [PATCH] virt-install: add --wait option In-Reply-To: <4887535B.1090104@redhat.com> References: <4887535B.1090104@redhat.com> Message-ID: <20080724121706.GX1138@redhat.com> On Wed, Jul 23, 2008 at 11:50:51AM -0400, Cole Robinson wrote: > The attached patch adds a --wait option to virt-install, which > forces the app to watch the install for a specified number > of minutes. If the time limit is exceeded, we simply exit > the app, leaving the domain in whatever state it is in. If > the vm shuts down as expected, the app continues as usual. > > The time limit is regardless of whether a console has been > specified or if one has already closed. A negative value > implies waiting indefinitely, and a value of 0 is the same > as not specifying --wait at all. This looks reasonable to me. The only comment I'd have is wrt to its interaction with --noautoconsole. Perhaps '--wait=0' should imply --noautoconsole, because otherwise it'd still actually wait. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Thu Jul 24 12:18:26 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Jul 2008 13:18:26 +0100 Subject: [et-mgmt-tools] [RFC] virtinst: build libvirt storage xml In-Reply-To: <4887538C.7090508@redhat.com> References: <4887538C.7090508@redhat.com> Message-ID: <20080724121826.GY1138@redhat.com> On Wed, Jul 23, 2008 at 11:51:40AM -0400, Cole Robinson wrote: > I've been working on a virtinst API to build and install xml > for libvirt storage objects. The current version is attached: > so far only nfs, filesystem and dir pools are implemented, as > well as their associated file volumes, but the remainder will > be mostly a cut and paste job. I have some UI wizards for > building these in virt-manager mostly complete, so this has > been tested to be pretty solid, though there is still some clean > up that needs doing. I think this is generally sound - the proof of any such API is how well it suits its users, so if it works well for virt-manager and virt-install CLI then go for it. > The general workflow is as follows: > > ========================================= > import virtinst.Storage.StoragePool as sp > > # This gives the appropriate class for the specified pool type > pool_class = sp.get_pool_class(sp.TYPE_FOO) > > # Only required params are a conn/uri and name. Default formats > # and target paths have default values, but source paths/ > # devices and hostnames obviously have no sensible default, but > # they still aren't required for object instantiation > pool = pool_class(name="foo", uri="xen:///") Should proably allow a existing connection to be passed in, otherwise this class has to deal with authentication issues too. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From Greg.Caetano at hp.com Thu Jul 24 16:19:15 2008 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Thu, 24 Jul 2008 16:19:15 +0000 Subject: [et-mgmt-tools] How to stop Virt-install from looking for distribution? Message-ID: I like using virt-install CLI to setup/define the domain file and create the disk image file. Is there a way to have the utility not look for the distribution (eg. Create the files but don't boot to installation environment?" Thanks greg Greg Caetano Chicago, IL Red Hat Certified Engineer From john.levon at sun.com Thu Jul 24 16:37:58 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 24 Jul 2008 09:37:58 -0700 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching Message-ID: <4b889eda816bdb1b3bff.1216917478@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1216917462 25200 # Node ID 4b889eda816bdb1b3bff21fd8a2a89029813a1a2 # Parent cd648dc6a9492fe3b703e5ebc7f43d05bb03adeb Fix Relax-NG pattern matching Don't use unescaped meta-characters in the patterns. Signed-off-by: John Levon diff --git a/doc/image.rng b/doc/image.rng --- a/doc/image.rng +++ b/doc/image.rng @@ -236,7 +236,7 @@ - [A-Za-z0-9_.:/+-]+ + [A-Za-z0-9_\.\+\-:/]+ @@ -246,12 +246,12 @@ - [a-zA-Z0-9_\+\-%.][a-zA-Z0-9_\+\-%./]* + [a-zA-Z0-9_\.\+\-%][a-zA-Z0-9_\.\+\-%/]* - [a-zA-Z0-9_\-:./]+ + [a-zA-Z0-9_\.\-:/]+ From crobinso at redhat.com Thu Jul 24 18:40:48 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 24 Jul 2008 14:40:48 -0400 Subject: [et-mgmt-tools] How to stop Virt-install from looking for distribution? In-Reply-To: References: Message-ID: <4888CCB0.9090308@redhat.com> Caetano, Greg wrote: > I like using virt-install CLI to setup/define the domain file and create the disk image file. Is there a way to have the utility not look for the distribution (eg. Create the files but don't boot to installation environment?" > > Thanks > greg > No way that I know of. What exactly are you trying to achieve? Just set up a guest and do the install later? Or are you using pre existing disks and just want to define a new VM around them? Something else maybe? Just curious. Thanks, Cole From gwiener at aenigmacorp.com Thu Jul 24 19:34:47 2008 From: gwiener at aenigmacorp.com (Geoff Wiener) Date: Thu, 24 Jul 2008 20:34:47 +0100 Subject: [libvirt] Re: [et-mgmt-tools] Virt-Manager, libvirt & TLS References: <89ADFB63BC286B49BC71F1D34A7E38D612D9E2@EXVS01.aenigmacorp.com> <20080724111835.GS1138@redhat.com> Message-ID: <89ADFB63BC286B49BC71F1D34A7E38D612D9F6@EXVS01.aenigmacorp.com> Hi Daniel; Thanks for the quick response and for your help, this is working now. If you are interested in the gory details they are detailed below, at least I'll document them here for the sake of others on the list. See "Gory Details - start" While I have your attention I have another question if you don't mind. I have done all this because I wanted to see if I could use virsh to live migrate a VM between physical hosts. Actually I wanted to use libvirt but virsh is my easiest way to talk to libvirt. My two physical xen servers are connecting to the same iSCSI SAN LUN formatted and mounted with ocfs2. I have a PV vm residing on the LUN (centos 5.1 - 2.6.8.18-xen). If I use standard xen config files and don't "define" my guest using virsh (xml) I can use the XM commands to migrate without any trouble. If I try to "define" the guest and then use XM to migrate it everything gets confused. So I thought I would "define" the guest and then try to use virsh to migrate. The same confusion takes place. I just did this and got some weird behaviour. I started the VM "centpv" up on host2 and then asked it to migrate to host1 using virsh from the (now working) client. The migration worked as expected. I was able to disconnect my VNC connection to the VM on host2 and connect it to the machine on host1. This where it gets weird. Host2 (Source) virsh # list --all Id Name State ---------------------------------- 0 Domain-0 running - centpv shut off - xi-ad-01 shut off - xi3mps01h shut off Host 1 (destination) virsh # list --all Id Name State ---------------------------------- 0 Domain-0 running 1 centpv blocked As you can see centpv is now listed on both machines. The state on host2 is shutoff which is technically correct. The VM is actually running on host 1. Host 1 has it as running. If you look at virt-manager you get an even more confusing story. Host1 says that centpv is "shutoff" until you highlight the machine then it says its running, and it quickly switches to saying it's shutoff. Host 2 claims the machine is still running. Killing virt-manager and re spawning it helps somewhat in that now host1 knows the machine is running. Host 2 thinks its shutdown. (Reflecting what is listed by virsh). The next thing I did was to "virsh undefine centpv" from host2. That also worked. Now all is right with the world. How can I find out more about how the "define" command works? (read the source code?) If the machine is "defined" doesn?t this place a hard entry in the local xenstore on the Xen machine on which it was defined?. I have to go read up on xenstore as I'm not that familiar with it yet. Do we need to migrate and then undefine the machine once the machine lands at the destination? Finally could these issues be related to the way virsh handles the libvirt "migrate" or is this a problem with libvirt? My next plan is to work up a python script that will talk directly to libvirt and execute a migration. This will take me some time as I don't know python... but let's see what happens. In the interest of time (and my sanity) does anyone have any basic python script that talk directly to libvirt that they would be willing to share? Thanks in advance. Gory Details - start. Your suggestion to use Virsh in the first instance was key. >From the Ubuntu workstation when I tried to connect to vxen-01 using virsh I immediately got an error relating to the missing CA.crt (which we both suspected was an issue). After copying the root cert to the correct location I was given a different error message: libvir: QEMU error : internal error cannot create bridge 'virbr0' : File exists >From which I googled my way to the following post: http://bbs.archlinux.org/viewtopic.php?id=5147 So I checked iptables and despite the fact that I don't remember configuring it, there were rules present. I think libvirtd does some stuff to iptables. After shutting down iptables and kicking the libvirtD I stopped getting that error. Now both virsh and virt-manager are working using TLS. Strangely the URI I had to use for virt-manager and virsh were different. Virt-manager URI = xen://vxen-01.domain.com Virsh URI = xen://vxen-01.domain.com/ Virsh needed the trailing "/". Without it I get console messages (on the server) that say "libvir: error : invalid argument in could not parse connection URI". I have typed it exactly, that grammar problem is not a typo, that's what it says. Best Regards -----Original Message----- From: libvir-list-bounces at redhat.com [mailto:libvir-list-bounces at redhat.com] On Behalf Of Daniel P. Berrange Sent: 24 July 2008 12:19 To: Fedora/Linux Management Tools Cc: libvir-list at redhat.com Subject: [libvirt] Re: [et-mgmt-tools] Virt-Manager, libvirt & TLS On Thu, Jul 24, 2008 at 11:13:28AM +0100, Geoff Wiener wrote: > Hi! > > > > This is my first post to either of these list, I have been lurking, > (sorry to cross post but I don't know if this is a virt-manager or > libvirt question). So first off thank you to everyone for all your > efforts. I think libvirt and virt-manager are excellent! I've built > a pair of server s in the lab with a Xen stack and have been attempting > to get virt-manager 0.5.4 to communicate with, first libvirt 0.4.2 and > then libvirt 0.4.4 using TLS across the network in a "client / server" > configuration unsuccessfully. All the machines are on the same subnet > (192.168.4.x/24). I can make Virt-Manager communicate with Libvirt > over TCP without authentication so now that I know the installation > works I want to further secure it using TLS. > > /usr/local/etc/libvirt/libvirtd.conf > > > > Listen_tcp = 1 > > auth_unix_ro = "none" > > auth_unix_rw="none" > > auth_tcp="none" That's all fine. > I followed the configuration notes at: http://libvirt.org/remote.html with a couple of exceptions: > > 1. I already have a linux based CA that I use with OpenVPN so I used that CA root certificate and just generated client and server cert / key pairs for my client and server (I tested with just one server) That's fine - any CA will do the job. > 2. I reverted back to the default libvirtd.conf to setup for TLS and > noticed that the default paths for the certificate locations were not in > line with the documentation on the web page but there were commented sections > as follows that matched the documentation, so I uncommented them: > > key_file = "/etc/pki/libvirt/private/serverkey.pem" > cert_file = "/etc/pki/libvirt/servercert.pem" > ca_file = "/etc/pki/CA/cacert.pem" No need to uncomment any of these - its fine to use the the default settings built-in to libvirt > > #crl_file = "/etc/pki/CA/crl.pem" > Note: I did not uncomment the CRL_FILE path as I do not want to use a CRL at this time Ok, no problem there. > 3. On the server I execute "libvirtd -listen -verbose" (libvirtd output) attached > > 4. virt-manager 0.5.4 (as root) , File, Open Connection > Hypervisor: Xen > > Connection: Remote SSL/TLS with x509 certificate > > Hostname: vxen-01.aenigmacorp.com (I have a host entry for this machine) > > > > The virt-manager console reports "unable to open a connection to the libvirt > management daemon". Verify that the "libvirtd" daemon has been started. Then, > in details there is a lot of info (see virt-manager output) I'd recommend getting it working using virsh as a client first - this gives clearer diagnostics. Once virsh is working, then virt-manager should just work too, although it has an extra step required for VNC access. > That about sums it up. I have not read any instructions that ask me to copy > the CA root certificate to the client, is that required? And if so where would > I put it. Yes, the CA certificate needs to be on all machines - in the same location as for the server - /etc/pki/CA/cacert.pem. The client server needs to be in the loication /etc/pki/libvirt/clientcert.pem There are some additional docs on the virt-manager wiki about the VNC setup steps too http://virt-manager.org/page/RemoteTLS Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list at redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From dlutter at redhat.com Thu Jul 24 20:46:32 2008 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 24 Jul 2008 13:46:32 -0700 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <4b889eda816bdb1b3bff.1216917478@xenbld> References: <4b889eda816bdb1b3bff.1216917478@xenbld> Message-ID: <1216932392.20132.21.camel@localhost.localdomain> On Thu, 2008-07-24 at 09:37 -0700, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1216917462 25200 > # Node ID 4b889eda816bdb1b3bff21fd8a2a89029813a1a2 > # Parent cd648dc6a9492fe3b703e5ebc7f43d05bb03adeb > Fix Relax-NG pattern matching > > Don't use unescaped meta-characters in the patterns. Haven't checked myself, but are you sure that in the Relax-NG '.' and '+' retain their special meaning inside character classes ? In some regex syntaxes (e.g. extended POSIX) they are treated as ordinary characters inside a character class - as an example, run echo "a.b.c" | sed -r -e 's/[.]/:/g' In any event, the '-' characters need to go at the very end of those character classes - that's definitely broken. David From levon at movementarian.org Thu Jul 24 21:11:26 2008 From: levon at movementarian.org (John Levon) Date: Thu, 24 Jul 2008 22:11:26 +0100 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <1216932392.20132.21.camel@localhost.localdomain> References: <4b889eda816bdb1b3bff.1216917478@xenbld> <1216932392.20132.21.camel@localhost.localdomain> Message-ID: <20080724211126.GB5160@totally.trollied.org.uk> On Thu, Jul 24, 2008 at 01:46:32PM -0700, David Lutterkort wrote: > Haven't checked myself, but are you sure that in the Relax-NG '.' and > '+' retain their special meaning inside character classes ? In some Yep: xenbld:virt-convert $ grep '' suse.hvm.virt-image.xml SUSE_Linux xenbld:virt-convert $ xmllint --relaxng doc/image.rng suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' xenbld:virt-convert $ vi doc/image.rng # . -> \. xenbld:virt-convert $ xmllint --relaxng doc/image.rng suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' suse.hvm.virt-image.xml:3: element name: Relax-NG validity error : Error validating datatype string > In any event, the '-' characters need to go at the very end of those > character classes - that's definitely broken. Are you sure about this? [A-Za-z0-9_\.\+\-:/]+ ... 58 X 59 Y 5A Z 5B [ 5C \ 5D ] 5E ^ 5F ... $ grep '' suse.hvm.virt-image.xml SUSE_Linux-^ $ xmllint --relaxng doc/image.rng suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' suse.hvm.virt-image.xml:3: element name: Relax-NG validity error : Error validating datatype string It doesn't seem to be treating it as a range to me. regards john From dlutter at redhat.com Thu Jul 24 22:26:21 2008 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 24 Jul 2008 15:26:21 -0700 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <20080724211126.GB5160@totally.trollied.org.uk> References: <4b889eda816bdb1b3bff.1216917478@xenbld> <1216932392.20132.21.camel@localhost.localdomain> <20080724211126.GB5160@totally.trollied.org.uk> Message-ID: <1216938381.20132.29.camel@localhost.localdomain> On Thu, 2008-07-24 at 22:11 +0100, John Levon wrote: > On Thu, Jul 24, 2008 at 01:46:32PM -0700, David Lutterkort wrote: > > > Haven't checked myself, but are you sure that in the Relax-NG '.' and > > '+' retain their special meaning inside character classes ? In some > > Yep: > > xenbld:virt-convert $ grep '' suse.hvm.virt-image.xml > SUSE_Linux > xenbld:virt-convert $ xmllint --relaxng doc/image.rng suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' > xenbld:virt-convert $ vi doc/image.rng # . -> \. > xenbld:virt-convert $ xmllint --relaxng doc/image.rng > suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' > suse.hvm.virt-image.xml:3: element name: Relax-NG validity error : Error validating datatype string This is very weird. The image.rng that's upstream has genericName [A-Za-z0-9_.:/+-]+ When I run 'xmllint --relaxng image.rng --noout image.xml' I do get a validation failure when I put 'my vm' in there. After playing with it some more, it seems that your patch does at the very least not break anything - no idea where the observed differences in xmllint behavior come from. But anyway: ACK David From levon at movementarian.org Thu Jul 24 23:30:57 2008 From: levon at movementarian.org (John Levon) Date: Fri, 25 Jul 2008 00:30:57 +0100 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <1216938381.20132.29.camel@localhost.localdomain> References: <4b889eda816bdb1b3bff.1216917478@xenbld> <1216932392.20132.21.camel@localhost.localdomain> <20080724211126.GB5160@totally.trollied.org.uk> <1216938381.20132.29.camel@localhost.localdomain> Message-ID: <20080724233057.GA20002@totally.trollied.org.uk> On Thu, Jul 24, 2008 at 03:26:21PM -0700, David Lutterkort wrote: > > xenbld:virt-convert $ grep '' suse.hvm.virt-image.xml > > SUSE_Linux > > xenbld:virt-convert $ xmllint --relaxng doc/image.rng suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' > > xenbld:virt-convert $ vi doc/image.rng # . -> \. > > xenbld:virt-convert $ xmllint --relaxng doc/image.rng > > suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' > > suse.hvm.virt-image.xml:3: element name: Relax-NG validity error : Error validating datatype string > > This is very weird. The image.rng that's upstream has genericName > > > [A-Za-z0-9_.:/+-]+ > > > When I run 'xmllint --relaxng image.rng --noout image.xml' I do get a > validation failure when I put 'my vm' in there. Weird. $ xmllint --version xmllint: using libxml version 20631 compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib (on Solaris). What about you? regards john From markybob at gmail.com Fri Jul 25 08:25:57 2008 From: markybob at gmail.com (Marcos Pinto) Date: Fri, 25 Jul 2008 03:25:57 -0500 Subject: [et-mgmt-tools] ctrl+ in client Message-ID: <48898e55.395c220a.1273.493a@mx.google.com> I currently use Virtual Manager on Linux to run a Win XP (kvm) vm. The more frustrating thing that I've run into is that ctrl+w closes the virtual manager windows, instead of the app/folder inside the vm, which would be the expected result. Is there a way to not have virtual manager intercept certain keyboard commands, such as that? It's driving me crazy :P Thanks, Marcos From drew.einhorn at gmail.com Fri Jul 25 14:19:55 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Fri, 25 Jul 2008 08:19:55 -0600 Subject: [et-mgmt-tools] Re: remote virtual terminals In-Reply-To: References: Message-ID: On Thu, Jul 24, 2008 at 8:05 AM, Brian McKee wrote: > On Wed, Jul 23, 2008 at 3:40 PM, drew einhorn > wrote: > > I need to do Ctl-Alt-Fn to access alternate Virtual Consoles on the virsh > > console > > on the DomU to troubleshoot the DHCP issue. But the Hardy laptop is > > catching > > the Ctrl-Alt-Fn and presenting alternets Virtual Consoles on the laptop > > instead of > > shoving them through the ssh connection to the remote virsh console. > > I only vaguely followed that - but what about `chvt` ? > It looks like Ctrl-Alt-Fn is normally bound to: chvt n on the my Hardy laptop. When the xterm with the ssh session to the remote xen dom0 has focus, I need to override that binding somehow. Instead of Ctrl-Alt-Fn changing the virtual consoles on the local laptop. I want it sent over the ssh connection to the remote dom0 session. Where it can be processed by the virsh runnning in dom0 presenting a domU console. The domU is in early stages of the RHEL5 installer and my idea of tweaking the key bindings isn't going to work. > > Brian > > -- > ubuntu-users mailing list > ubuntu-users at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-users > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.levon at sun.com Fri Jul 25 15:53:58 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Fri, 25 Jul 2008 08:53:58 -0700 Subject: [et-mgmt-tools] [PATCH] virt-convert: more error checking Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1217001163 25200 # Node ID c0bd4e747433ae4ab8ade954ed0b95c521661147 # Parent 9bf9f0bcb2bcc3d31b82dda7abb46ecc8f04dc8a virt-convert: more error checking Improve the error checking a little. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -98,12 +98,16 @@ def parse_args(): opts.error(("No output handler for format \"%s\"" % options.output_format)) + if not os.access(args[0], os.R_OK): + opts.error("Couldn't access input argument \"%s\"\n" % args[0]) + sys.exit(1) + if not options.input_format: try: (args[0], options.input_format) = formats.find_input(args[0]) except StandardError, e: opts.error("Couldn't determine input format for \"%s\": %s" % - (args[0], e.message)) + (args[0], e)) sys.exit(1) if options.input_format not in formats.formats(): @@ -166,7 +170,7 @@ def main(): sys.exit(1) except Exception, e: logging.error("Couldn't import file \"%s\": %s" % - (options.input_file, e.message)) + (options.input_file, e)) sys.exit(1) if options.paravirt: @@ -231,14 +235,14 @@ def main(): cleanup("Couldn't convert disks: %s" % e.strerror, options, vmdef, clean) except RuntimeError, e: - cleanup("Couldn't convert disks: %s" % e.message, options, vmdef, clean) + cleanup("Couldn't convert disks: %s" % e, options, vmdef, clean) try: clean += [ options.output_file ] outp.export_file(vmdef, options.output_file) except ValueError, e: cleanup("Couldn't export to file \"%s\": %s" % - (options.output_file, e.message), options, vmdef, clean) + (options.output_file, e), options, vmdef, clean) verbose(options, "Done.") From john.levon at sun.com Fri Jul 25 15:54:09 2008 From: john.levon at sun.com (john.levon at sun.com) Date: Fri, 25 Jul 2008 08:54:09 -0700 Subject: [et-mgmt-tools] [PATCH] virt-convert: vdisk fixes Message-ID: <004b1455bb21116bc6ae.1217001249@xenbld> # HG changeset patch # User john.levon at sun.com # Date 1217001227 25200 # Node ID 004b1455bb21116bc6ae83a8257b68d4f04cd732 # Parent c0bd4e747433ae4ab8ade954ed0b95c521661147 virt-convert: vdisk fixes Update the vdisk code for new vdisk behaviour. Signed-off-by: John Levon diff --git a/virtconv/diskcfg.py b/virtconv/diskcfg.py --- a/virtconv/diskcfg.py +++ b/virtconv/diskcfg.py @@ -18,9 +18,12 @@ # MA 02110-1301 USA. # +import popen2 import shutil import errno +import sys import os +import re DISK_FORMAT_NONE = 0 DISK_FORMAT_RAW = 1 @@ -32,7 +35,7 @@ DISK_TYPE_ISO = 2 DISK_TYPE_ISO = 2 disk_suffixes = { - DISK_FORMAT_RAW: ".img", + DISK_FORMAT_RAW: ".raw", DISK_FORMAT_VMDK: ".vmdk", DISK_FORMAT_VDISK: ".vdisk.xml", } @@ -60,6 +63,15 @@ def ensuredirs(path): except OSError, e: if e.errno != errno.EEXIST: raise + +def run_cmd(cmd): + """ + Return the exit status and output to stdout and stderr. + """ + proc = popen2.Popen3(cmd, capturestderr=True) + proc.tochild.close() + ret = proc.wait() + return ret, proc.fromchild.readlines(), proc.childerr.readlines() class disk(object): """Definition of an individual disk instance.""" @@ -114,15 +126,27 @@ class disk(object): if need_copy: if out_format == DISK_FORMAT_VDISK: - stdin, stdout = os.popen2(["/usr/bin/vdiskadm", "import", "-n", - "-f", "-t", qemu_formats[self.format], - "\"%s\"" % os.path.join(indir, self.path)]) - paths = stdout.readlines() - stdin.close() - stdout.close() - for path in paths: - self.copy_file(os.path.join(indir, path), - os.path.join(outdir, path)) + # copy any sub-files for the disk as well as the disk + # itself + ret, stdout, stderr = run_cmd(["/usr/lib/xen/bin/vdiskadm", "import", + "-npqf", os.path.join(indir, self.path)]) + + if ret != 0: + raise RuntimeError("Disk conversion failed with " + "exit status %d: %s" % (ret, "".join(stderr))) + if len(stderr): + print >> sys.stderr, stderr + + stubpath = os.path.dirname(self.path) + + for item in stdout: + type, path = item.strip().split(':', 1) + if not (type == "snapshot" or type == "file"): + continue + infile = os.path.join(indir, stubpath, path) + outfile = os.path.join(outdir, stubpath, path) + self.copy_file(infile, outfile) + return need_convert # this is not correct for all VMDK files, but it will have @@ -156,27 +180,63 @@ class disk(object): absin = os.path.join(indir, relin) absout = os.path.join(outdir, relout) - ensuredirs(absout) - - if out_format == DISK_FORMAT_VDISK: - convert_cmd = ("""/usr/bin/vdiskadm import -t %s "%s" "%s" """ % - (qemu_formats[out_format], absin, absout)) - elif out_format == DISK_FORMAT_RAW: - convert_cmd = ("""qemu-img convert -O %s "%s" "%s" """ % - (qemu_formats[out_format], absin, absout)) - else: + if not (out_format == DISK_FORMAT_VDISK or + out_format == DISK_FORMAT_RAW): raise NotImplementedError("Cannot convert to disk format %s" % output_format) - self.clean += [ absout ] - - ret = os.system(convert_cmd) + ensuredirs(absout) + + if out_format != DISK_FORMAT_VDISK: + + self.clean += [ absout ] + + ret, stdout, stderr = run_cmd(["qemu-img", "convert", "-O", + qemu_formats[out_format], absin, absout]) + if ret != 0: + raise RuntimeError("Disk conversion failed with " + "exit status %d: %s" % (ret, "".join(stderr))) + if len(stderr): + print >> sys.stderr, stderr + + self.path = relout + self.format = out_format + return + + # + # The presumption is that the top-level disk name can't contain + # spaces, but the sub-disks can. We don't want to break an + # existing config if we're doing it in-place, so be careful + # about copying versus moving. + # + spath = re.sub(r'\s', '_', relin) + if spath != relin: + infile = os.path.join(outdir, relin) + outfile = os.path.join(outdir, spath) + if indir == outdir: + shutil.copy(infile, outfile) + else: + shutil.move(infile, outfile) + self.path = spath + relin = spath + + ret, stdout, stderr = run_cmd(["/usr/lib/xen/bin/vdiskadm", "import", + "-fp", os.path.join(outdir, relin)]) + if ret != 0: - raise RuntimeError("Disk conversion failed with exit status %d" - % ret) - - self.path = relout - self.format = out_format + raise RuntimeError("Disk conversion failed with " + "exit status %d: %s" % (ret, "".join(stderr))) + if len(stderr): + print >> sys.stderr, stderr + + stubpath = os.path.dirname(relin) + + for item in stdout: + type, path = item.strip().split(':', 1) + if type == "store": + path = os.path.join(stubpath, path) + self.clean += [ os.path.join(outdir, path) ] + self.format = out_format def disk_formats(): """ From crobinso at redhat.com Fri Jul 25 16:01:15 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 25 Jul 2008 12:01:15 -0400 Subject: [et-mgmt-tools] [RFC] virtinst: build libvirt storage xml In-Reply-To: <20080724121826.GY1138@redhat.com> References: <4887538C.7090508@redhat.com> <20080724121826.GY1138@redhat.com> Message-ID: <4889F8CB.6040500@redhat.com> Daniel P. Berrange wrote: >> The general workflow is as follows: >> >> ========================================= >> import virtinst.Storage.StoragePool as sp >> >> # This gives the appropriate class for the specified pool type >> pool_class = sp.get_pool_class(sp.TYPE_FOO) >> >> # Only required params are a conn/uri and name. Default formats >> # and target paths have default values, but source paths/ >> # devices and hostnames obviously have no sensible default, but >> # they still aren't required for object instantiation >> pool = pool_class(name="foo", uri="xen:///") > > Should proably allow a existing connection to be passed in, otherwise > this class has to deal with authentication issues too. > I didn't show it in the example, but passing a connection is allowed. On a side note, we should add support for openAuth in virtinst, everything is just hardcoded to use libvirt.open at the moment. - Cole From crobinso at redhat.com Fri Jul 25 16:02:05 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 25 Jul 2008 12:02:05 -0400 Subject: [et-mgmt-tools] [PATCH] virt-install: add --wait option In-Reply-To: <20080724121706.GX1138@redhat.com> References: <4887535B.1090104@redhat.com> <20080724121706.GX1138@redhat.com> Message-ID: <4889F8FD.5020105@redhat.com> Daniel P. Berrange wrote: > On Wed, Jul 23, 2008 at 11:50:51AM -0400, Cole Robinson wrote: >> The attached patch adds a --wait option to virt-install, which >> forces the app to watch the install for a specified number >> of minutes. If the time limit is exceeded, we simply exit >> the app, leaving the domain in whatever state it is in. If >> the vm shuts down as expected, the app continues as usual. >> >> The time limit is regardless of whether a console has been >> specified or if one has already closed. A negative value >> implies waiting indefinitely, and a value of 0 is the same >> as not specifying --wait at all. > > This looks reasonable to me. The only comment I'd have is wrt > to its interaction with --noautoconsole. Perhaps '--wait=0' > should imply --noautoconsole, because otherwise it'd still > actually wait. > > > Daniel That seems reasonable. I'll make that adjustment and commit. Thanks, Cole From berrange at redhat.com Fri Jul 25 16:07:03 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 25 Jul 2008 17:07:03 +0100 Subject: [et-mgmt-tools] [RFC] virtinst: build libvirt storage xml In-Reply-To: <4889F8CB.6040500@redhat.com> References: <4887538C.7090508@redhat.com> <20080724121826.GY1138@redhat.com> <4889F8CB.6040500@redhat.com> Message-ID: <20080725160703.GB15410@redhat.com> On Fri, Jul 25, 2008 at 12:01:15PM -0400, Cole Robinson wrote: > Daniel P. Berrange wrote: > >> The general workflow is as follows: > >> > >> ========================================= > >> import virtinst.Storage.StoragePool as sp > >> > >> # This gives the appropriate class for the specified pool type > >> pool_class = sp.get_pool_class(sp.TYPE_FOO) > >> > >> # Only required params are a conn/uri and name. Default formats > >> # and target paths have default values, but source paths/ > >> # devices and hostnames obviously have no sensible default, but > >> # they still aren't required for object instantiation > >> pool = pool_class(name="foo", uri="xen:///") > > > > Should proably allow a existing connection to be passed in, otherwise > > this class has to deal with authentication issues too. > > > > I didn't show it in the example, but passing a connection is allowed. > > On a side note, we should add support for openAuth in virtinst, > everything is just hardcoded to use libvirt.open at the moment. No, that's exactly why we shouldn't take a URI. openAuth requires user interaction, so that's unavoidably application specific. We just need a helper in virtinst/cli.py for the command line tools to use to create their connection object, and virt-manager already knows how to do authentication. So everything should just pass ina connection object instead of URI. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From dlutter at redhat.com Fri Jul 25 16:15:13 2008 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 25 Jul 2008 09:15:13 -0700 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <20080724233057.GA20002@totally.trollied.org.uk> References: <4b889eda816bdb1b3bff.1216917478@xenbld> <1216932392.20132.21.camel@localhost.localdomain> <20080724211126.GB5160@totally.trollied.org.uk> <1216938381.20132.29.camel@localhost.localdomain> <20080724233057.GA20002@totally.trollied.org.uk> Message-ID: <1217002513.20132.48.camel@localhost.localdomain> On Fri, 2008-07-25 at 00:30 +0100, John Levon wrote: > On Thu, Jul 24, 2008 at 03:26:21PM -0700, David Lutterkort wrote: > > > > xenbld:virt-convert $ grep '' suse.hvm.virt-image.xml > > > SUSE_Linux > > > xenbld:virt-convert $ xmllint --relaxng doc/image.rng suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' > > > xenbld:virt-convert $ vi doc/image.rng # . -> \. > > > xenbld:virt-convert $ xmllint --relaxng doc/image.rng > > > suse.hvm.virt-image.xml 2>&1 | grep 'Error validating' > > > suse.hvm.virt-image.xml:3: element name: Relax-NG validity error : Error validating datatype string > > > > This is very weird. The image.rng that's upstream has genericName > > > > > > [A-Za-z0-9_.:/+-]+ > > > > > > When I run 'xmllint --relaxng image.rng --noout image.xml' I do get a > > validation failure when I put 'my vm' in there. > > Weird. > > $ xmllint --version > xmllint: using libxml version 20631 > compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 > FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv > ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug > Zlib xmllint: using libxml version 20632 compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib http://xmlsoft.org/news.html lists a bugfix for 2.6.32 about "regexp bug with '.' (Andrew Tosh)". The full entry from the ChangeLog is xmlregexp.c: apply patch from Andrew Tosh to fix behaviour when '.' is used in a posCharGroup That should explain the difference. David From crobinso at redhat.com Fri Jul 25 16:27:29 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 25 Jul 2008 12:27:29 -0400 Subject: [et-mgmt-tools] [RFC] virtinst: build libvirt storage xml In-Reply-To: <20080725160703.GB15410@redhat.com> References: <4887538C.7090508@redhat.com> <20080724121826.GY1138@redhat.com> <4889F8CB.6040500@redhat.com> <20080725160703.GB15410@redhat.com> Message-ID: <4889FEF1.2090403@redhat.com> Daniel P. Berrange wrote: > On Fri, Jul 25, 2008 at 12:01:15PM -0400, Cole Robinson wrote: >> Daniel P. Berrange wrote: >> >> The general workflow is as follows: >>>> ========================================= >>>> import virtinst.Storage.StoragePool as sp >>>> >>>> # This gives the appropriate class for the specified pool type >>>> pool_class = sp.get_pool_class(sp.TYPE_FOO) >>>> >>>> # Only required params are a conn/uri and name. Default formats >>>> # and target paths have default values, but source paths/ >>>> # devices and hostnames obviously have no sensible default, but >>>> # they still aren't required for object instantiation >>>> pool = pool_class(name="foo", uri="xen:///") >>> Should proably allow a existing connection to be passed in, otherwise >>> this class has to deal with authentication issues too. >>> >> I didn't show it in the example, but passing a connection is allowed. >> >> On a side note, we should add support for openAuth in virtinst, >> everything is just hardcoded to use libvirt.open at the moment. > > No, that's exactly why we shouldn't take a URI. openAuth requires user > interaction, so that's unavoidably application specific. We just need > a helper in virtinst/cli.py for the command line tools to use to create > their connection object, and virt-manager already knows how to do > authentication. So everything should just pass ina connection object > instead of URI. > > Daniel Ahh okay, that makes sense. I'll remove the option to pass a URI then, since we really shouldn't even encourage passing a URI and expecting the library to open it. - Cole From levon at movementarian.org Fri Jul 25 16:31:59 2008 From: levon at movementarian.org (John Levon) Date: Fri, 25 Jul 2008 17:31:59 +0100 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <1217002513.20132.48.camel@localhost.localdomain> References: <4b889eda816bdb1b3bff.1216917478@xenbld> <1216932392.20132.21.camel@localhost.localdomain> <20080724211126.GB5160@totally.trollied.org.uk> <1216938381.20132.29.camel@localhost.localdomain> <20080724233057.GA20002@totally.trollied.org.uk> <1217002513.20132.48.camel@localhost.localdomain> Message-ID: <20080725163159.GC23570@totally.trollied.org.uk> On Fri, Jul 25, 2008 at 09:15:13AM -0700, David Lutterkort wrote: > xmlregexp.c: apply patch from Andrew Tosh to fix behaviour > when '.' is used in a posCharGroup > > That should explain the difference. Hah, indeed. Of course we still want my patch for older libxml, I think. regards john From berrange at redhat.com Fri Jul 25 16:34:51 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 25 Jul 2008 17:34:51 +0100 Subject: [et-mgmt-tools] [RFC] virtinst: build libvirt storage xml In-Reply-To: <4889FEF1.2090403@redhat.com> References: <4887538C.7090508@redhat.com> <20080724121826.GY1138@redhat.com> <4889F8CB.6040500@redhat.com> <20080725160703.GB15410@redhat.com> <4889FEF1.2090403@redhat.com> Message-ID: <20080725163451.GE15410@redhat.com> On Fri, Jul 25, 2008 at 12:27:29PM -0400, Cole Robinson wrote: > Daniel P. Berrange wrote: > > On Fri, Jul 25, 2008 at 12:01:15PM -0400, Cole Robinson wrote: > >> Daniel P. Berrange wrote: > >> >> The general workflow is as follows: > >>>> ========================================= > >>>> import virtinst.Storage.StoragePool as sp > >>>> > >>>> # This gives the appropriate class for the specified pool type > >>>> pool_class = sp.get_pool_class(sp.TYPE_FOO) > >>>> > >>>> # Only required params are a conn/uri and name. Default formats > >>>> # and target paths have default values, but source paths/ > >>>> # devices and hostnames obviously have no sensible default, but > >>>> # they still aren't required for object instantiation > >>>> pool = pool_class(name="foo", uri="xen:///") > >>> Should proably allow a existing connection to be passed in, otherwise > >>> this class has to deal with authentication issues too. > >>> > >> I didn't show it in the example, but passing a connection is allowed. > >> > >> On a side note, we should add support for openAuth in virtinst, > >> everything is just hardcoded to use libvirt.open at the moment. > > > > No, that's exactly why we shouldn't take a URI. openAuth requires user > > interaction, so that's unavoidably application specific. We just need > > a helper in virtinst/cli.py for the command line tools to use to create > > their connection object, and virt-manager already knows how to do > > authentication. So everything should just pass ina connection object > > instead of URI. > > > > Daniel > > Ahh okay, that makes sense. I'll remove the option to pass a URI then, > since we really shouldn't even encourage passing a URI and expecting > the library to open it. Just don't remove it from the existing Guest modules, because Koan is relying on this API to remain stable & since Koan is local only it doesn't have to worry about auth. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Fri Jul 25 16:41:31 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 25 Jul 2008 12:41:31 -0400 Subject: [et-mgmt-tools] [RFC] virtinst: build libvirt storage xml In-Reply-To: <20080725163451.GE15410@redhat.com> References: <4887538C.7090508@redhat.com> <20080724121826.GY1138@redhat.com> <4889F8CB.6040500@redhat.com> <20080725160703.GB15410@redhat.com> <4889FEF1.2090403@redhat.com> <20080725163451.GE15410@redhat.com> Message-ID: <488A023B.8000903@redhat.com> Daniel P. Berrange wrote: >>> No, that's exactly why we shouldn't take a URI. openAuth requires user >>> interaction, so that's unavoidably application specific. We just need >>> a helper in virtinst/cli.py for the command line tools to use to create >>> their connection object, and virt-manager already knows how to do >>> authentication. So everything should just pass ina connection object >>> instead of URI. >>> >>> Daniel >> Ahh okay, that makes sense. I'll remove the option to pass a URI then, >> since we really shouldn't even encourage passing a URI and expecting >> the library to open it. > > Just don't remove it from the existing Guest modules, because Koan is > relying on this API to remain stable & since Koan is local only it > doesn't have to worry about auth. > > Daniel Right understandably we need to maintain the existing expected behavior. - Cole From dlutter at redhat.com Sat Jul 26 01:43:36 2008 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 25 Jul 2008 18:43:36 -0700 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <20080725163159.GC23570@totally.trollied.org.uk> References: <4b889eda816bdb1b3bff.1216917478@xenbld> <1216932392.20132.21.camel@localhost.localdomain> <20080724211126.GB5160@totally.trollied.org.uk> <1216938381.20132.29.camel@localhost.localdomain> <20080724233057.GA20002@totally.trollied.org.uk> <1217002513.20132.48.camel@localhost.localdomain> <20080725163159.GC23570@totally.trollied.org.uk> Message-ID: <1217036616.23702.6.camel@localhost.localdomain> On Fri, 2008-07-25 at 17:31 +0100, John Levon wrote: > On Fri, Jul 25, 2008 at 09:15:13AM -0700, David Lutterkort wrote: > > > xmlregexp.c: apply patch from Andrew Tosh to fix behaviour > > when '.' is used in a posCharGroup > > > > That should explain the difference. > > Hah, indeed. Of course we still want my patch for older libxml, I think. Agreed. David From crobinso at redhat.com Mon Jul 28 15:05:20 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 28 Jul 2008 11:05:20 -0400 Subject: [et-mgmt-tools] [PATCH] Fix Relax-NG pattern matching In-Reply-To: <20080725163159.GC23570@totally.trollied.org.uk> References: <4b889eda816bdb1b3bff.1216917478@xenbld> <1216932392.20132.21.camel@localhost.localdomain> <20080724211126.GB5160@totally.trollied.org.uk> <1216938381.20132.29.camel@localhost.localdomain> <20080724233057.GA20002@totally.trollied.org.uk> <1217002513.20132.48.camel@localhost.localdomain> <20080725163159.GC23570@totally.trollied.org.uk> Message-ID: <488DE030.1020301@redhat.com> John Levon wrote: > On Fri, Jul 25, 2008 at 09:15:13AM -0700, David Lutterkort wrote: > >> xmlregexp.c: apply patch from Andrew Tosh to fix behaviour >> when '.' is used in a posCharGroup >> >> That should explain the difference. > > Hah, indeed. Of course we still want my patch for older libxml, I think. > > regards > john > Seems like it can't hurt. Applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=2c0badd42d08 Thanks, Cole From crobinso at redhat.com Mon Jul 28 15:05:46 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 28 Jul 2008 11:05:46 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: vdisk fixes In-Reply-To: <004b1455bb21116bc6ae.1217001249@xenbld> References: <004b1455bb21116bc6ae.1217001249@xenbld> Message-ID: <488DE04A.2080609@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1217001227 25200 > # Node ID 004b1455bb21116bc6ae83a8257b68d4f04cd732 > # Parent c0bd4e747433ae4ab8ade954ed0b95c521661147 > virt-convert: vdisk fixes > > Update the vdisk code for new vdisk behaviour. > > Signed-off-by: John Levon > Applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=15bf41d90c7a Thanks, Cole From crobinso at redhat.com Mon Jul 28 15:06:35 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 28 Jul 2008 11:06:35 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: more error checking In-Reply-To: References: Message-ID: <488DE07B.8050801@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1217001163 25200 > # Node ID c0bd4e747433ae4ab8ade954ed0b95c521661147 > # Parent 9bf9f0bcb2bcc3d31b82dda7abb46ecc8f04dc8a > virt-convert: more error checking > > Improve the error checking a little. > > Signed-off-by: John Levon > Applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=1f02236d9aee Thanks, Cole From crobinso at redhat.com Mon Jul 28 15:51:28 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 28 Jul 2008 11:51:28 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show sound devices Message-ID: <488DEB00.2070600@redhat.com> The attached patch teaches virt-manager how to parse sound device xml for virtual machines. Each separate will show up as a separate device in the VM details listing. The patch also implements deleting these devices. I put a screenshot up that should explain most of the changes: http://crobinso.fedorapeople.org/virt-manager/vmm-sound.png Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-parse-sound-devs-patch URL: From crobinso at redhat.com Mon Jul 28 15:51:49 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 28 Jul 2008 11:51:49 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial/parallel devices Message-ID: <488DEB15.4090302@redhat.com> The attached patch teaches virt-manager how to parse VM character devices, showing them in the details section. This patch also implements removing these devices. There are a couple quirks though: 1) All the possible character device xml properties aren't accounted for. This only parses target port, device type, and source path. I figure this covers the common cases, and is easily expandable. 2) Explicit entries are only set for serial and parallel devices, not console devices. Since by default, console is really just a duplicate of the first serial device, we try to detect this and label said serial device as appropriately (seen in the second screen shot). This simplifies things a good deal, and makes deleting easier, since in order to remove the console or first serial device, both xml blocks need to be removed simultaneously (not sure if this is a libvirt bug or not). I've posted a couple screenshots to give a better idea: Parallel device: http://crobinso.fedorapeople.org/virt-manager/vmm-parallel.png Serial device that is also the console device: http://crobinso.fedorapeople.org/virt-manager/vmm-serial.png Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-parse-char-devs-patch URL: From mdehaan at redhat.com Mon Jul 28 21:48:36 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 28 Jul 2008 17:48:36 -0400 Subject: [et-mgmt-tools] Using libvirt-remote with python-virtinst? Message-ID: <488E3EB4.8090409@redhat.com> Today I tried using a remote connection string within koan. The idea here is to be able to use koan against boxes that have libvirtd installed but do not have koan installed. guest = virtinst.FullVirtGuest(hypervisorURI="qemu+ssh://root at drwily.rdu.redhat.com/system", ...) This works fine up until the point where it wants to create the disk. I heard on #ovirt that there may be some work being done to make the API of python-virtinst be smart enough to be able to create remote disks? If so, that would be very cool to have, as it would mean we could do cobbler-based installs of virtual machines with a minimum of installed tooling on the guest. --Michael From berrange at redhat.com Tue Jul 29 08:35:58 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 29 Jul 2008 09:35:58 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: show sound devices In-Reply-To: <488DEB00.2070600@redhat.com> References: <488DEB00.2070600@redhat.com> Message-ID: <20080729083558.GL32498@redhat.com> On Mon, Jul 28, 2008 at 11:51:28AM -0400, Cole Robinson wrote: > The attached patch teaches virt-manager how to parse > sound device xml for virtual machines. Each separate > will show up as a separate > device in the VM details listing. The patch also > implements deleting these devices. ACK this is good. > > I put a screenshot up that should explain most of the > changes: > > http://crobinso.fedorapeople.org/virt-manager/vmm-sound.png We sooooo badly need to find us a graphic designer who can build a complete set of proper icons for CPU, memory, disk, NIC, sound, input, PCI and USB devices. The icons we use currently just look rubbish - i'm inclined to say we should get rid of them unless we can get good graphics because they're not really adding value anymore. > diff -r f4c491621a10 -r 8a86b6ed3a80 src/virtManager/details.py > --- a/src/virtManager/details.py Wed Jul 23 16:23:56 2008 -0400 > +++ b/src/virtManager/details.py Wed Jul 23 17:24:12 2008 -0400 > @@ -55,6 +55,7 @@ > HW_LIST_TYPE_NIC = 4 > HW_LIST_TYPE_INPUT = 5 > HW_LIST_TYPE_GRAPHICS = 6 > +HW_LIST_TYPE_SOUND = 7 > > # Console pages > PAGE_UNAVAILABLE = 0 > @@ -252,6 +253,7 @@ > "on_config_network_remove_clicked": self.remove_network, > "on_config_input_remove_clicked": self.remove_input, > "on_config_graphics_remove_clicked": self.remove_graphics, > + "on_config_sound_remove_clicked": self.remove_sound, > "on_add_hardware_button_clicked": self.add_hardware, > > "on_details_menu_view_fullscreen_activate": self.toggle_fullscreen, > @@ -536,6 +538,8 @@ > self.refresh_input_page() > elif pagetype == HW_LIST_TYPE_GRAPHICS: > self.refresh_graphics_page() > + elif pagetype == HW_LIST_TYPE_SOUND: > + self.refresh_sound_page() > elif pagetype == HW_LIST_TYPE_BOOT: > self.refresh_boot_page() > self.window.get_widget("config-boot-options-apply").set_sensitive(False) > @@ -720,6 +724,8 @@ > self.refresh_input_page() > elif pagetype == HW_LIST_TYPE_GRAPHICS: > self.refresh_graphics_page() > + elif pagetype == HW_LIST_TYPE_SOUND: > + self.refresh_sound_page() > > def refresh_summary(self): > self.window.get_widget("overview-cpu-usage-text").set_text("%d %%" % self.vm.cpu_time_percentage()) > @@ -889,6 +895,21 @@ > self.window.get_widget("config-input-remove").set_sensitive(False) > else: > self.window.get_widget("config-input-remove").set_sensitive(True) > + > + def refresh_sound_page(self): > + vmlist = self.window.get_widget("hw-list") > + selection = vmlist.get_selection() > + active = selection.get_selected() > + if active[1] is None: > + return > + sound = active[0].get_value(active[1], HW_LIST_COL_DEVICE) > + self.window.get_widget("sound-model").set_text(sound[3]) > + > + # Can't remove sound dev from live guest > + if self.vm.is_active(): > + self.window.get_widget("config-sound-remove").set_sensitive(False) > + else: > + self.window.get_widget("config-sound-remove").set_sensitive(True) > > def refresh_boot_page(self): > # Refresh autostart > @@ -1296,6 +1317,18 @@ > self.remove_device(xml) > self.refresh_resources() > > + def remove_sound(self, src): > + vmlist = self.window.get_widget("hw-list") > + selection = vmlist.get_selection() > + active = selection.get_selected() > + if active[1] is None: > + return > + sound = active[0].get_value(active[1], HW_LIST_COL_DEVICE) > + > + xml = "" % sound[3] > + self.remove_device(xml) > + self.refresh_resources() > + > def prepare_hw_list(self): > hw_list_model = gtk.ListStore(str, str, int, gtk.gdk.Pixbuf, int, gobject.TYPE_PYOBJECT) > self.window.get_widget("hw-list").set_model(hw_list_model) > @@ -1426,6 +1459,25 @@ > if missing: > hw_list_model.insert(insertAt, [_("Display"), gtk.STOCK_SELECT_COLOR, gtk.ICON_SIZE_LARGE_TOOLBAR, None, HW_LIST_TYPE_GRAPHICS, graphic]) > > + # Populate list of sound devices > + currentSounds = {} > + for sound in self.vm.get_sound_devices(): > + missing = True > + insertAt = 0 > + currentSounds[sound[3]] = 1 > + for row in hw_list_model: > + if row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_SOUND and \ > + row[HW_LIST_COL_DEVICE][3] == sound[3]: > + # Update metadata > + row[HW_LIST_COL_DEVICE] = sound > + missing = False > + > + if row[HW_LIST_COL_TYPE] <= HW_LIST_TYPE_SOUND: > + insertAt = insertAt + 1 > + # Add in row > + if missing: > + hw_list_model.insert(insertAt, [_("Sound: %s" % sound[3]), gtk.STOCK_MEDIA_PLAY, gtk.ICON_SIZE_LARGE_TOOLBAR, None, HW_LIST_TYPE_SOUND, sound]) > + > # Now remove any no longer current devs > devs = range(len(hw_list_model)) > devs.reverse() > @@ -1441,6 +1493,9 @@ > elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_INPUT and not currentInputs.has_key(row[HW_LIST_COL_DEVICE][3]): > removeIt = True > elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_GRAPHICS and not currentGraphics.has_key(row[HW_LIST_COL_DEVICE][3]): > + removeIt = True > + elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_SOUND and not \ > + currentSounds.has_key(row[HW_LIST_COL_DEVICE][3]): If we're going to break long lines, break all of them in that conditional :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 29 08:39:33 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 29 Jul 2008 09:39:33 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial/parallel devices In-Reply-To: <488DEB15.4090302@redhat.com> References: <488DEB15.4090302@redhat.com> Message-ID: <20080729083933.GM32498@redhat.com> On Mon, Jul 28, 2008 at 11:51:49AM -0400, Cole Robinson wrote: > The attached patch teaches virt-manager how to parse VM > character devices, showing them in the details section. > This patch also implements removing these devices. > > There are a couple quirks though: > > 1) All the possible character device xml properties > aren't accounted for. This only parses target port, > device type, and source path. I figure this covers > the common cases, and is easily expandable. > > 2) Explicit entries are only set for serial and parallel > devices, not console devices. Since by default, console > is really just a duplicate of the first serial device, > we try to detect this and label said serial device as > appropriately (seen in the second screen shot). > This simplifies things a good deal, and makes deleting > easier, since in order to remove the console or > first serial device, both xml blocks need to be removed > simultaneously (not sure if this is a libvirt bug or not). I think that is probably a bug. Can you re-test with the latest CVS snapshot of libvirt where I've changed the handling a little bit. Basically you should never need to add or remove a 'console' device explicitly. Either it is there permanently (eg, Xen PV always has a console), or it is automatically added/removed when the first serial device is added or removed. > diff -r 8ff3fe2b729e -r 2bbb1937e47b src/virtManager/details.py > --- a/src/virtManager/details.py Fri Jul 18 21:34:13 2008 -0400 > +++ b/src/virtManager/details.py Thu Jul 24 14:41:42 2008 -0400 > @@ -56,6 +56,7 @@ > HW_LIST_TYPE_INPUT = 5 > HW_LIST_TYPE_GRAPHICS = 6 > HW_LIST_TYPE_SOUND = 7 > +HW_LIST_TYPE_CHAR = 8 > > # Console pages > PAGE_UNAVAILABLE = 0 > @@ -254,6 +255,7 @@ > "on_config_input_remove_clicked": self.remove_input, > "on_config_graphics_remove_clicked": self.remove_graphics, > "on_config_sound_remove_clicked": self.remove_sound, > + "on_config_char_remove_clicked": self.remove_char, > "on_add_hardware_button_clicked": self.add_hardware, > > "on_details_menu_view_fullscreen_activate": self.toggle_fullscreen, > @@ -541,6 +543,8 @@ > self.refresh_graphics_page() > elif pagetype == HW_LIST_TYPE_SOUND: > self.refresh_sound_page() > + elif pagetype == HW_LIST_TYPE_CHAR: > + self.refresh_char_page() > elif pagetype == HW_LIST_TYPE_BOOT: > self.refresh_boot_page() > self.window.get_widget("config-boot-options-apply").set_sensitive(False) > @@ -727,6 +731,8 @@ > self.refresh_graphics_page() > elif pagetype == HW_LIST_TYPE_SOUND: > self.refresh_sound_page() > + elif pagetype == HW_LIST_TYPE_CHAR: > + self.refresh_char_page() > > def refresh_summary(self): > self.window.get_widget("overview-cpu-usage-text").set_text("%d %%" % self.vm.cpu_time_percentage()) > @@ -911,6 +917,26 @@ > self.window.get_widget("config-sound-remove").set_sensitive(False) > else: > self.window.get_widget("config-sound-remove").set_sensitive(True) > + > + def refresh_char_page(self): > + vmlist = self.window.get_widget("hw-list") > + selection = vmlist.get_selection() > + active = selection.get_selected() > + if active[1] is None: > + return > + char = active[0].get_value(active[1], HW_LIST_COL_DEVICE) > + typelabel = "%s Device %s" % (char[0].capitalize(), > + char[5] and _("(Primary Console)") or "") > + self.window.get_widget("char-type").set_markup(typelabel) > + self.window.get_widget("char-dev-type").set_text(char[1] or "-") > + self.window.get_widget("char-target-port").set_text(char[2]) > + self.window.get_widget("char-source-path").set_text(char[4] or "-") > + > + # Can't remove char dev from live guest > + if self.vm.is_active(): > + self.window.get_widget("config-char-remove").set_sensitive(False) > + else: > + self.window.get_widget("config-char-remove").set_sensitive(True) > > def refresh_boot_page(self): > # Refresh autostart > @@ -1330,6 +1356,20 @@ > self.remove_device(xml) > self.refresh_resources() > > + def remove_char(self, src): > + vmlist = self.window.get_widget("hw-list") > + selection = vmlist.get_selection() > + active = selection.get_selected() > + if active[1] is None: > + return > + char = active[0].get_value(active[1], HW_LIST_COL_DEVICE) > + > + xml = "<%s>\n" % char[0] + \ > + " \n" % char[2] + \ > + "" % char[0] > + self.remove_device(xml) > + self.refresh_resources() > + > def prepare_hw_list(self): > hw_list_model = gtk.ListStore(str, str, int, gtk.gdk.Pixbuf, int, gobject.TYPE_PYOBJECT) > self.window.get_widget("hw-list").set_model(hw_list_model) > @@ -1479,6 +1519,27 @@ > if missing: > hw_list_model.insert(insertAt, [_("Sound: %s" % sound[3]), gtk.STOCK_MEDIA_PLAY, gtk.ICON_SIZE_LARGE_TOOLBAR, None, HW_LIST_TYPE_SOUND, sound]) > > + > + # Populate list of char devices > + currentChars = {} > + for char in self.vm.get_char_devices(): > + missing = True > + insertAt = 0 > + currentChars[char[3]] = 1 > + for row in hw_list_model: > + if row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_CHAR and \ > + row[HW_LIST_COL_DEVICE][3] == char[3]: > + # Update metadata > + row[HW_LIST_COL_DEVICE] = char > + missing = False > + > + if row[HW_LIST_COL_TYPE] <= HW_LIST_TYPE_CHAR: > + insertAt = insertAt + 1 > + # Add in row > + if missing: > + hw_list_model.insert(insertAt, ["%s %s" % (char[0].capitalize(), char[2]), gtk.STOCK_CONNECT, gtk.ICON_SIZE_LARGE_TOOLBAR, None, HW_LIST_TYPE_CHAR, char]) > + > + > # Now remove any no longer current devs > devs = range(len(hw_list_model)) > devs.reverse() > @@ -1497,6 +1558,9 @@ > removeIt = True > elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_SOUND and not \ > currentSounds.has_key(row[HW_LIST_COL_DEVICE][3]): > + removeIt = True > + elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_CHAR and not \ > + currentChars.has_key(row[HW_LIST_COL_DEVICE][3]): > removeIt = True > > if removeIt: > diff -r 8ff3fe2b729e -r 2bbb1937e47b src/virtManager/domain.py > --- a/src/virtManager/domain.py Fri Jul 18 21:34:13 2008 -0400 > +++ b/src/virtManager/domain.py Thu Jul 24 14:41:42 2008 -0400 > @@ -702,6 +702,46 @@ > > return self._parse_device_xml(_parse_sound_devs) > > + def get_char_devices(self): > + def _parse_char_devs(ctx): > + chars = [] > + devs = [] > + cons = ctx.xpathEval("/domain/devices/console") > + devs.extend(ctx.xpathEval("/domain/devices/parallel")) > + devs.extend(ctx.xpathEval("/domain/devices/serial")) > + > + # Since there is only one 'console' device ever in the xml > + # find its port (if present) > + cons_port = None > + for node in cons: > + for child in node.children: > + if child.name == "target": > + cons_port = child.prop("port") > + > + for node in devs: > + char_type = node.name > + dev_type = node.prop("type") > + target_port = None > + source_path = None > + console_dev = False > + > + for child in node.children: > + if child.name == "target": > + target_port = child.prop("port") > + if child.name == "source": > + source_path = child.prop("path") > + > + if node.name == "serial" and target_port == cons_port: > + # Console is just a dupe of this serial device > + console_dev = True > + > + chars.append([char_type, dev_type, target_port, > + "%s:%s" % (char_type, target_port), > + source_path, console_dev]) > + return chars > + > + return self._parse_device_xml(_parse_char_devs) > + > def _parse_device_xml(self, parse_function): > doc = None > ctx = None > @@ -803,6 +843,30 @@ > if len(model) > 0 and model[0].content != None: > logging.debug("Looking for type %s" % model[0].content) > ret = ctx.xpathEval("/domain/devices/sound[@model='%s']" % model[0].content) > + > + elif dev_type == "parallel" or dev_type == "console" or \ > + dev_type == "serial": > + port = dev_ctx.xpathEval("/%s/target/@port" % dev_type) > + if port and len(port) > 0 and port[0].content != None: > + logging.debug("Looking for %s w/ port %s" % (dev_type, > + port)) > + ret = ctx.xpathEval("/domain/devices/%s[target/@port='%s']" % (dev_type, port[0].content)) > + > + # If serial and console are both present, console is > + # probably (always?) just a dup of the 'primary' serial > + # device. Try and find an associated console device with > + # the same port and remove that as well, otherwise the > + # removal doesn't go through > + if dev_type == "serial": > + cons_ret = ctx.xpathEval("/domain/devices/console[target/@port='%s']" % port[0].content) > + if cons_ret and len(cons_ret) > 0: > + logging.debug("Also removing console device " > + "associated with serial dev.") > + cons_ret[0].unlinkNode() > + cons_ret[0].freeNode() > + else: > + logging.debug("No console device found associated " > + "with passed serial devices") > > else: > raise RuntimeError, _("Unknown device type device type '%s'" % > diff -r 8ff3fe2b729e -r 2bbb1937e47b src/vmm-details.glade > --- a/src/vmm-details.glade Fri Jul 18 21:34:13 2008 -0400 > +++ b/src/vmm-details.glade Thu Jul 24 14:41:42 2008 -0400 > @@ -1550,7 +1550,7 @@ > > True > True > - 200 > + 230 > > > > @@ -4658,6 +4658,299 @@ > tab > > > + > + > + > + True > + False > + 0 > + > + > + > + True > + 0 > + 0.5 > + GTK_SHADOW_NONE > + > + > + > + True > + 0.5 > + 0.5 > + 1 > + 1 > + 0 > + 0 > + 12 > + 0 > + > + > + > + 3 > + True > + 3 > + 2 > + False > + 3 > + 3 > + > + > + > + True > + Device Type: > + False > + False > + GTK_JUSTIFY_LEFT > + False > + False > + 1 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + 0 > + 1 > + 0 > + 1 > + fill > + > + > + > + > + > + > + True > + Target Port: > + False > + False > + GTK_JUSTIFY_LEFT > + False > + False > + 1 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + 0 > + 1 > + 1 > + 2 > + fill > + > + > + > + > + > + > + True > + Source Path: > + False > + False > + GTK_JUSTIFY_LEFT > + False > + False > + 1 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + 0 > + 1 > + 2 > + 3 > + fill > + > + > + > + > + > + > + True > + label506 > + False > + False > + GTK_JUSTIFY_LEFT > + False > + False > + 0 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + 1 > + 2 > + 0 > + 1 > + fill > + > + > + > + > + > + > + True > + label507 > + False > + False > + GTK_JUSTIFY_LEFT > + False > + False > + 0 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + 1 > + 2 > + 1 > + 2 > + fill > + > + > + > + > + > + > + True > + label508 > + False > + False > + GTK_JUSTIFY_LEFT > + False > + False > + 0 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + 1 > + 2 > + 2 > + 3 > + fill > + > + > + > + > + > + > + > + > + > + > + True > + <b>insert type</b> > + False > + True > + GTK_JUSTIFY_LEFT > + False > + False > + 0.5 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + label_item > + > + > + > + > + 15 > + True > + True > + > + > + > + > + > + 6 > + True > + GTK_BUTTONBOX_END > + 0 > + > + > + > + True > + True > + True > + gtk-remove > + True > + GTK_RELIEF_NORMAL > + True > + > + > + > + > + > + 0 > + False > + True > + > + > + > + > + False > + True > + > + > + > + > + > + True > + Char > + False > + False > + GTK_JUSTIFY_LEFT > + False > + False > + 0.5 > + 0.5 > + 0 > + 0 > + PANGO_ELLIPSIZE_NONE > + -1 > + False > + 0 > + > + > + tab > + > + > > > True > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Jul 29 08:50:18 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 29 Jul 2008 09:50:18 +0100 Subject: [et-mgmt-tools] Using libvirt-remote with python-virtinst? In-Reply-To: <488E3EB4.8090409@redhat.com> References: <488E3EB4.8090409@redhat.com> Message-ID: <20080729085018.GP32498@redhat.com> On Mon, Jul 28, 2008 at 05:48:36PM -0400, Michael DeHaan wrote: > Today I tried using a remote connection string within koan. The idea > here is to be able to use koan against boxes that have libvirtd > installed but do not have koan installed. > > guest = > virtinst.FullVirtGuest(hypervisorURI="qemu+ssh://root at drwily.rdu.redhat.com/system", > ...) > > This works fine up until the point where it wants to create the disk. > > I heard on #ovirt that there may be some work being done to make the API > of python-virtinst be smart enough to be able to create remote disks? It needs virtinst to be fully ported to use the storage APIs, which is something Cole is working on right now. There's probably a few other places where we still hit local machine state, but that can be cleaned up by use of the capabilities XML and other libvirt APIs (eg BlockPeek to check for MBR signature). Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Tue Jul 29 11:45:02 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 29 Jul 2008 07:45:02 -0400 Subject: [et-mgmt-tools] Using libvirt-remote with python-virtinst? In-Reply-To: <20080729085018.GP32498@redhat.com> References: <488E3EB4.8090409@redhat.com> <20080729085018.GP32498@redhat.com> Message-ID: <488F02BE.7070002@redhat.com> Daniel P. Berrange wrote: > On Mon, Jul 28, 2008 at 05:48:36PM -0400, Michael DeHaan wrote: > >> Today I tried using a remote connection string within koan. The idea >> here is to be able to use koan against boxes that have libvirtd >> installed but do not have koan installed. >> >> guest = >> virtinst.FullVirtGuest(hypervisorURI="qemu+ssh://root at drwily.rdu.redhat.com/system", >> ...) >> >> This works fine up until the point where it wants to create the disk. >> >> I heard on #ovirt that there may be some work being done to make the API >> of python-virtinst be smart enough to be able to create remote disks? >> > > It needs virtinst to be fully ported to use the storage APIs, which is > something Cole is working on right now. There's probably a few other > places where we still hit local machine state, but that can be cleaned > up by use of the capabilities XML and other libvirt APIs (eg BlockPeek > to check for MBR signature). > > Daniel > Excellent. I heard a bit of this from Hugh, but we wanted to confirm it would work like this. I'll stay tuned. --Michael From crobinso at redhat.com Tue Jul 29 13:53:50 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 29 Jul 2008 09:53:50 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show sound devices In-Reply-To: <20080729083558.GL32498@redhat.com> References: <488DEB00.2070600@redhat.com> <20080729083558.GL32498@redhat.com> Message-ID: <488F20EE.9040307@redhat.com> Daniel P. Berrange wrote: > On Mon, Jul 28, 2008 at 11:51:28AM -0400, Cole Robinson wrote: >> The attached patch teaches virt-manager how to parse >> sound device xml for virtual machines. Each separate >> will show up as a separate >> device in the VM details listing. The patch also >> implements deleting these devices. > > ACK this is good. > >> I put a screenshot up that should explain most of the >> changes: >> >> http://crobinso.fedorapeople.org/virt-manager/vmm-sound.png > > We sooooo badly need to find us a graphic designer who can build > a complete set of proper icons for CPU, memory, disk, NIC, sound, > input, PCI and USB devices. The icons we use currently just look > rubbish - i'm inclined to say we should get rid of them unless > we can get good graphics because they're not really adding value > anymore. > The new UI designs (which have stalled a bit) came bundled with the promise of new icons, so this is at least on the radar. >> @@ -1441,6 +1493,9 @@ >> elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_INPUT and not currentInputs.has_key(row[HW_LIST_COL_DEVICE][3]): >> removeIt = True >> elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_GRAPHICS and not currentGraphics.has_key(row[HW_LIST_COL_DEVICE][3]): >> + removeIt = True >> + elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_SOUND and not \ >> + currentSounds.has_key(row[HW_LIST_COL_DEVICE][3]): > > If we're going to break long lines, break all of them in that > conditional :-) > I'll fix this when I commit. Thanks, Cole From crobinso at redhat.com Tue Jul 29 13:54:26 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 29 Jul 2008 09:54:26 -0400 Subject: [et-mgmt-tools] Using libvirt-remote with python-virtinst? In-Reply-To: <20080729085018.GP32498@redhat.com> References: <488E3EB4.8090409@redhat.com> <20080729085018.GP32498@redhat.com> Message-ID: <488F2112.4000100@redhat.com> Daniel P. Berrange wrote: > On Mon, Jul 28, 2008 at 05:48:36PM -0400, Michael DeHaan wrote: >> Today I tried using a remote connection string within koan. The idea >> here is to be able to use koan against boxes that have libvirtd >> installed but do not have koan installed. >> >> guest = >> virtinst.FullVirtGuest(hypervisorURI="qemu+ssh://root at drwily.rdu.redhat.com/system", >> ...) >> >> This works fine up until the point where it wants to create the disk. >> >> I heard on #ovirt that there may be some work being done to make the API >> of python-virtinst be smart enough to be able to create remote disks? > > It needs virtinst to be fully ported to use the storage APIs, which is > something Cole is working on right now. There's probably a few other > places where we still hit local machine state, but that can be cleaned > up by use of the capabilities XML and other libvirt APIs (eg BlockPeek > to check for MBR signature). > > Daniel Just FYI, that is what I've been particularly working on this week. I'll probably have a working RFC to post by Wednesday so we can discuss any actual cli and api extensions. - Cole From RAYELLA at ccbcmd.edu Tue Jul 29 16:18:28 2008 From: RAYELLA at ccbcmd.edu (Ayella, Robert) Date: Tue, 29 Jul 2008 12:18:28 -0400 Subject: [et-mgmt-tools] rt Message-ID: <32AA4C7763CB33479AF73581514D57EB070F02FC@cwe.ccbc.ccbcmd.edu> rt Bob Ayella Coordinator - Network Technology, Operating Systems, and IT Support CCBC School of Applied and Information Technology, Catonsville Campus rayella at ccbcmd.edu ph: 410-869-7122 or 410-455-4444 fax: 410-455-4744 -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Tue Jul 29 16:28:18 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 29 Jul 2008 12:28:18 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial/parallel devices In-Reply-To: <20080729083933.GM32498@redhat.com> References: <488DEB15.4090302@redhat.com> <20080729083933.GM32498@redhat.com> Message-ID: <488F4522.2070604@redhat.com> Daniel P. Berrange wrote: > On Mon, Jul 28, 2008 at 11:51:49AM -0400, Cole Robinson wrote: >> The attached patch teaches virt-manager how to parse VM >> character devices, showing them in the details section. >> This patch also implements removing these devices. >> >> There are a couple quirks though: >> >> 1) All the possible character device xml properties >> aren't accounted for. This only parses target port, >> device type, and source path. I figure this covers >> the common cases, and is easily expandable. >> >> 2) Explicit entries are only set for serial and parallel >> devices, not console devices. Since by default, console >> is really just a duplicate of the first serial device, >> we try to detect this and label said serial device as >> appropriately (seen in the second screen shot). >> This simplifies things a good deal, and makes deleting >> easier, since in order to remove the console or >> first serial device, both xml blocks need to be removed >> simultaneously (not sure if this is a libvirt bug or not). > > I think that is probably a bug. Can you re-test with the latest > CVS snapshot of libvirt where I've changed the handling a little > bit. Basically you should never need to add or remove a 'console' > device explicitly. Either it is there permanently (eg, Xen PV > always has a console), or it is automatically added/removed when > the first serial device is added or removed. > > Cool, things seem to work with current upstream. As far as the virt-manager code though, do you think it's a reasonable approach (don't have an explicit console entry)? Thanks, Cole From berrange at redhat.com Tue Jul 29 16:51:54 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 29 Jul 2008 17:51:54 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial/parallel devices In-Reply-To: <488F4522.2070604@redhat.com> References: <488DEB15.4090302@redhat.com> <20080729083933.GM32498@redhat.com> <488F4522.2070604@redhat.com> Message-ID: <20080729165154.GI32498@redhat.com> On Tue, Jul 29, 2008 at 12:28:18PM -0400, Cole Robinson wrote: > Daniel P. Berrange wrote: > > On Mon, Jul 28, 2008 at 11:51:49AM -0400, Cole Robinson wrote: > >> The attached patch teaches virt-manager how to parse VM > >> character devices, showing them in the details section. > >> This patch also implements removing these devices. > >> > >> There are a couple quirks though: > >> > >> 1) All the possible character device xml properties > >> aren't accounted for. This only parses target port, > >> device type, and source path. I figure this covers > >> the common cases, and is easily expandable. > >> > >> 2) Explicit entries are only set for serial and parallel > >> devices, not console devices. Since by default, console > >> is really just a duplicate of the first serial device, > >> we try to detect this and label said serial device as > >> appropriately (seen in the second screen shot). > >> This simplifies things a good deal, and makes deleting > >> easier, since in order to remove the console or > >> first serial device, both xml blocks need to be removed > >> simultaneously (not sure if this is a libvirt bug or not). > > > > I think that is probably a bug. Can you re-test with the latest > > CVS snapshot of libvirt where I've changed the handling a little > > bit. Basically you should never need to add or remove a 'console' > > device explicitly. Either it is there permanently (eg, Xen PV > > always has a console), or it is automatically added/removed when > > the first serial device is added or removed. > > Cool, things seem to work with current upstream. > > As far as the virt-manager code though, do you think it's a reasonable > approach (don't have an explicit console entry)? This a little bit of an annoying part due to the way we had to maintain backwards comaptability with the XML format. You can skip the 'console' entry if-and-only-if there is at least one serial device. If there's no serial device, you'll need to explicitly list the console. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Wed Jul 30 20:37:35 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 30 Jul 2008 16:37:35 -0400 Subject: [et-mgmt-tools] [RFC] virt-install: remote guest creation Message-ID: <4890D10F.1030706@redhat.com> I've taken a stab at getting remote guest creation up and running for virt-install. Most of the existing code translates well to the remote case, but the main issue is storage: how does the user tell us where to create and find existing storage/media, and how can we usefully validate this info. The libvirt storage API is the lower level mechanism that allows this fun stuff to happen, its really just a matter of choosing a sane interface for it all. The two interface problems we have are: - Changes to VirtualDisk to handle storage apis - Changes to virt-install cli to allow specifying storage info For VirtualDisk, I added two options - volobj : a libvirt virStorageVol instance - volinstall : a virtinst StorageVolume instance If the user wants the VirtualDisk to use existing storage, they will need to query libvirt for the virStorageVol and pass this to the VirtualDisk, which will take care of the rest. If the user wants to create a new managed volume, they populate a StorageVolume object (posted earlier but not yet committed) and pass this VirtualDisk. VirtualDisk will map the setup and is_size_conflict commands as appropriate, so all current infrastructure will just work. Now there wasn't a lot of functionality that needed to be added to accomplish this, but VirtualDisk was becoming unmaintainable so I took this opportunity to break it out into it's own file and clean it up quite a bit. I also added a parent VirtualDevice class which I will move all the other device classes over to in the future, but it's not an immediate priority. The other choices here are to offload looking up storage volumes to VirtualDisk, or maybe add an option to attempt to lookup the 'path' parameter as a storage volume if we are on a remote connection. These could just be options added later though. The next piece is how the interface changes for virt-install. Here are the storage use cases we now have: 1) use existing non-managed (local) disk - signified by --file /some/real/path 2) create non-managed (local) disk - signified by --file /some/real/dir/idontexist 3) create managed disk - all we would really need is the pool name to install on. 4) use existing managed disk - could be a pool name, vol name combo, or perhaps even an absolute path representing a volume. 5) use existing non-managed media (cdrom) - signified by --cdrom /some/real/path 6) use existing managed media - same syntax as existing managed disk The options I see are: A) overload existing options (--file, --cdrom): we can detect we are using a remote connection, and try to lookup a passed path as a volume. if the user wants to specify pool/vol by name, we can use something like 'poolname:volname' for some reasonable delimiter. however this could collide with some legitimate storage names so it may not feasible. We could always get fancy and allow escaping characters though. B) Add extra options. To completely get away without having to add some 'poolname:volname' type format as above, we would probably need a --pool-name and --vol-name, and someway to indicate that we want these for cdrom media as well :/ I've currently been testing this with a hacked up version of A. The only remaining issue is some trouble with Guest objects expecting the install location to be local, but I'm still playing with that. Attached are the new VirtualDisk and VirtualDevice files, this all works and passes validation testing but I haven't given it any real polish yet. Any feedback is appreciated. Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: VirtualDevice.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: VirtualDisk.py URL: From mdehaan at redhat.com Wed Jul 30 21:17:58 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 Jul 2008 17:17:58 -0400 Subject: [et-mgmt-tools] [RFC] virt-install: remote guest creation In-Reply-To: <4890D10F.1030706@redhat.com> References: <4890D10F.1030706@redhat.com> Message-ID: <4890DA86.1080806@redhat.com> Cole Robinson wrote: > I've taken a stab at getting remote guest creation up and running > for virt-install. Most of the existing code translates well to the > remote case, but the main issue is storage: how does the user tell > us where to create and find existing storage/media, and how can we > usefully validate this info. The libvirt storage API is the lower > level mechanism that allows this fun stuff to happen, its really > just a matter of choosing a sane interface for it all. > > The two interface problems we have are: > > - Changes to VirtualDisk to handle storage apis > - Changes to virt-install cli to allow specifying storage info > > For VirtualDisk, I added two options > - volobj : a libvirt virStorageVol instance > - volinstall : a virtinst StorageVolume instance > Do you have examples of what this might look like for VirtualDisk? I'm interested in teaching koan how to install on remote hosts. > If the user wants the VirtualDisk to use existing storage, they > will need to query libvirt for the virStorageVol and pass this > to the VirtualDisk, which will take care of the rest. > Basically the use cases I care about are: Install to a specific path and/or filename Install to an existing partition Install to a new partition in an existing LVM volume group. As koan needed to do this before the storage stuff (IIRC) I have code in koan to manage LVM. I'll need to keep it around for support of RHEL 5.older and F8-previous, so if the new stuff works relatively the same that would be great. Basically if I can pass in a path or LVM volume group name, I'm happy. Needing to grok any XML would make me unhappy :) > If the user wants to create a new managed volume, they populate > a StorageVolume object (posted earlier but not yet committed) > and pass this VirtualDisk. VirtualDisk will map the setup and > is_size_conflict commands as appropriate, so all current > infrastructure will just work. > > Now there wasn't a lot of functionality that needed to be added > to accomplish this, but VirtualDisk was becoming unmaintainable > so I took this opportunity to break it out into it's own file > and clean it up quite a bit. I also added a parent VirtualDevice > class which I will move all the other device classes over to in > the future, but it's not an immediate priority. > > The other choices here are to offload looking up storage volumes > to VirtualDisk, or maybe add an option to attempt to lookup > the 'path' parameter as a storage volume if we are on a remote > connection. These could just be options added later though. > > > The next piece is how the interface changes for virt-install. > Here are the storage use cases we now have: > > 1) use existing non-managed (local) disk > - signified by --file /some/real/path > > 2) create non-managed (local) disk > - signified by --file /some/real/dir/idontexist > What is "managed vs unmanaged" here? > 3) create managed disk > - all we would really need is the pool name to install on. > What's a pool in context here? I'm basically trying to make sure this is usable without requiring ovirt. > 4) use existing managed disk > - could be a pool name, vol name combo, or perhaps > even an absolute path representing a volume. > a volume group name is good. A path to a volume group is ok too as we know that just lives under /dev/mapper and is easy to get to. > 5) use existing non-managed media (cdrom) > - signified by --cdrom /some/real/path > > 6) use existing managed media > - same syntax as existing managed disk > > The options I see are: > > A) overload existing options (--file, --cdrom): we can detect we > are using a remote connection, and try to lookup a passed path > as a volume. if the user wants to specify pool/vol by name, we > can use something like 'poolname:volname' for some reasonable > delimiter. however this could collide with some legitimate > storage names so it may not feasible. We could always get > fancy and allow escaping characters though. > IMHO, autodetection would be very nice if it worked just like it was a path on the remote system and the only difference was that you were using a different connection string. This makes remote work as close to local as possible. If that's not doable that's ok. > B) Add extra options. To completely get away without having to > add some 'poolname:volname' type format as above, we would > probably need a --pool-name and --vol-name, and someway to > indicate that we want these for cdrom media as well :/ > Again, I'm not sure what a "pool" here in context of this library. LVMs, mount points, I get :) Hope that helps? --Michael > I've currently been testing this with a hacked up version of A. > > The only remaining issue is some trouble with Guest objects > expecting the install location to be local, but I'm still > playing with that. > > Attached are the new VirtualDisk and VirtualDevice files, this > all works and passes validation testing but I haven't given it > any real polish yet. > > Any feedback is appreciated. > > Thanks, > Cole > > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From crobinso at redhat.com Wed Jul 30 21:53:22 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 30 Jul 2008 17:53:22 -0400 Subject: [et-mgmt-tools] [RFC] virt-install: remote guest creation In-Reply-To: <4890DA86.1080806@redhat.com> References: <4890D10F.1030706@redhat.com> <4890DA86.1080806@redhat.com> Message-ID: <4890E2D2.8070001@redhat.com> Michael DeHaan wrote: > Cole Robinson wrote: >> I've taken a stab at getting remote guest creation up and running >> for virt-install. Most of the existing code translates well to the >> remote case, but the main issue is storage: how does the user tell >> us where to create and find existing storage/media, and how can we >> usefully validate this info. The libvirt storage API is the lower >> level mechanism that allows this fun stuff to happen, its really >> just a matter of choosing a sane interface for it all. >> >> The two interface problems we have are: >> >> - Changes to VirtualDisk to handle storage apis >> - Changes to virt-install cli to allow specifying storage info >> >> For VirtualDisk, I added two options >> - volobj : a libvirt virStorageVol instance >> - volinstall : a virtinst StorageVolume instance >> > > Do you have examples of what this might look like for VirtualDisk? I'm > interested in teaching koan how to install on remote hosts. I've attached a pretty ugly script I was using just to basically test this stuff at first. It has hardcoded values specific to my machine so it won't work if you run it. However it has an example that covers both of the above cases. Please read my below comments though regarding the libvirt storage apis. > >> If the user wants the VirtualDisk to use existing storage, they >> will need to query libvirt for the virStorageVol and pass this >> to the VirtualDisk, which will take care of the rest. >> > Basically the use cases I care about are: > > Install to a specific path and/or filename > Install to an existing partition > Install to a new partition in an existing LVM volume group. > > As koan needed to do this before the storage stuff (IIRC) I have code in > koan to manage LVM. I'll need to keep it around for support of RHEL > 5.older and F8-previous, so if the new stuff works relatively the same > that would be great. > > Basically if I can pass in a path or LVM volume group name, I'm happy. > Needing to grok any XML would make me unhappy :) There won't be any need to mess with xml here. >> >> The next piece is how the interface changes for virt-install. >> Here are the storage use cases we now have: >> >> 1) use existing non-managed (local) disk >> - signified by --file /some/real/path >> >> 2) create non-managed (local) disk >> - signified by --file /some/real/dir/idontexist >> > > What is "managed vs unmanaged" here? Managed = Libvirt storage APIs. The libvirt storage APIs are how we know what exists on remote systems, and how we tell remote systems to create this file with this format, or that partition with that size, etc. The 'pool' and 'volume' terminology is all part of this. http://libvirt.org/storage.html The gist of it is: A 'pool' is some resource that can be carved up into units to be used directly by VMs. Pool types are a directory, nfs mount, filesystem mount (all carved into flat files), lvm volgroup, raw disk devices (carved into smaller blk devs), and iscsi (which creation isn't supported on). A 'volume' is the carved up unit, directly usable as storage for a VM. All this remote guest creation stuff won't 'just work' if the user passes the correct parameters, the remote host will have to be configured in advance to teach libvirt about what storage is available. This could either be done on the command line using virsh pool-create-as, or use virt-manager and use wizards to do all this fun stuff (not posted yet. 95% completed and working, just hasn't been polished up, and it's dependent on some not committed virtinst work). We should probably have libvirt set up a default storage pool for /var/lib/libvirt/images so that there would be a typical out of the box option for users. - Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtdisk-test.py URL: From mdehaan at redhat.com Wed Jul 30 22:00:12 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 Jul 2008 18:00:12 -0400 Subject: [et-mgmt-tools] [RFC] virt-install: remote guest creation In-Reply-To: <4890E2D2.8070001@redhat.com> References: <4890D10F.1030706@redhat.com> <4890DA86.1080806@redhat.com> <4890E2D2.8070001@redhat.com> Message-ID: <4890E46C.6050909@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Cole Robinson wrote: >> >>> I've taken a stab at getting remote guest creation up and running >>> for virt-install. Most of the existing code translates well to the >>> remote case, but the main issue is storage: how does the user tell >>> us where to create and find existing storage/media, and how can we >>> usefully validate this info. The libvirt storage API is the lower >>> level mechanism that allows this fun stuff to happen, its really >>> just a matter of choosing a sane interface for it all. >>> >>> The two interface problems we have are: >>> >>> - Changes to VirtualDisk to handle storage apis >>> - Changes to virt-install cli to allow specifying storage info >>> >>> For VirtualDisk, I added two options >>> - volobj : a libvirt virStorageVol instance >>> - volinstall : a virtinst StorageVolume instance >>> >>> >> Do you have examples of what this might look like for VirtualDisk? I'm >> interested in teaching koan how to install on remote hosts. >> > > I've attached a pretty ugly script I was using just to basically test > this stuff at first. It has hardcoded values specific to my machine > so it won't work if you run it. However it has an example that covers > both of the above cases. > > Please read my below comments though regarding the libvirt storage > apis. > > >>> If the user wants the VirtualDisk to use existing storage, they >>> will need to query libvirt for the virStorageVol and pass this >>> to the VirtualDisk, which will take care of the rest. >>> >>> >> Basically the use cases I care about are: >> >> Install to a specific path and/or filename >> Install to an existing partition >> Install to a new partition in an existing LVM volume group. >> >> As koan needed to do this before the storage stuff (IIRC) I have code in >> koan to manage LVM. I'll need to keep it around for support of RHEL >> 5.older and F8-previous, so if the new stuff works relatively the same >> that would be great. >> >> Basically if I can pass in a path or LVM volume group name, I'm happy. >> Needing to grok any XML would make me unhappy :) >> > > There won't be any need to mess with xml here. > > > > Excellent! >>> The next piece is how the interface changes for virt-install. >>> Here are the storage use cases we now have: >>> >>> 1) use existing non-managed (local) disk >>> - signified by --file /some/real/path >>> >>> 2) create non-managed (local) disk >>> - signified by --file /some/real/dir/idontexist >>> >>> >> What is "managed vs unmanaged" here? >> > > Managed = Libvirt storage APIs. The libvirt storage APIs are how > we know what exists on remote systems, and how we tell remote > systems to create this file with this format, or that partition > with that size, etc. > > The 'pool' and 'volume' terminology is all part of this. > > http://libvirt.org/storage.html > > The gist of it is: > > A 'pool' is some resource that can be carved up into units to be > used directly by VMs. Pool types are a directory, nfs mount, > filesystem mount (all carved into flat files), lvm volgroup, > raw disk devices (carved into smaller blk devs), and iscsi > (which creation isn't supported on). > > A 'volume' is the carved up unit, directly usable as storage for > a VM. > > All this remote guest creation stuff won't 'just work' if the user > passes the correct parameters, the remote host will have to be > configured in advance to teach libvirt about what storage is > available. This could either be done on the command line using > virsh pool-create-as, or use virt-manager and use wizards to > do all this fun stuff (not posted yet. 95% completed and > working, just hasn't been polished up, and it's dependent on > some not committed virtinst work). > Here's what I think would be an interesting use case: I'm looking to teach koan to do this fully-remotely. The idea is that you have a provisioning server and you want to be able to remotely declare what you want to have it it can help make it come into reality. So in the WebUI for "cobbler system add", I have a button now that says "Save". I want to be able to have another button that says "Save & Create On Host" and you could type in what host. Obviously, the command line for cobbler is where most people would be using it, but that's another example of how this could be seen to work. > We should probably have libvirt set up a default storage > pool for /var/lib/libvirt/images so that there would be > a typical out of the box option for users. > That would be very good. If I can do the pool-add stuff remotely via libvirt-remote that would also be nice, though if I have to do it over SSH that is just the same as we'd be using the SSH version of libvirt-remote most likely anyway. I'm pretty sure that either way we can get it to work for a heavily scriptable remote-deploy API kind of solution. Neat. > - Cole > > > From crobinso at redhat.com Thu Jul 31 15:09:37 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 31 Jul 2008 11:09:37 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show sound devices In-Reply-To: <488F20EE.9040307@redhat.com> References: <488DEB00.2070600@redhat.com> <20080729083558.GL32498@redhat.com> <488F20EE.9040307@redhat.com> Message-ID: <4891D5B1.90702@redhat.com> Cole Robinson wrote: > Daniel P. Berrange wrote: >> On Mon, Jul 28, 2008 at 11:51:28AM -0400, Cole Robinson wrote: >>> The attached patch teaches virt-manager how to parse >>> sound device xml for virtual machines. Each separate >>> will show up as a separate >>> device in the VM details listing. The patch also >>> implements deleting these devices. >> ACK this is good. >> >>> I put a screenshot up that should explain most of the >>> changes: >>> >>> http://crobinso.fedorapeople.org/virt-manager/vmm-sound.png >> We sooooo badly need to find us a graphic designer who can build >> a complete set of proper icons for CPU, memory, disk, NIC, sound, >> input, PCI and USB devices. The icons we use currently just look >> rubbish - i'm inclined to say we should get rid of them unless >> we can get good graphics because they're not really adding value >> anymore. >> > > The new UI designs (which have stalled a bit) came bundled with the > promise of new icons, so this is at least on the radar. > > > >>> @@ -1441,6 +1493,9 @@ >>> elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_INPUT and not currentInputs.has_key(row[HW_LIST_COL_DEVICE][3]): >>> removeIt = True >>> elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_GRAPHICS and not currentGraphics.has_key(row[HW_LIST_COL_DEVICE][3]): >>> + removeIt = True >>> + elif row[HW_LIST_COL_TYPE] == HW_LIST_TYPE_SOUND and not \ >>> + currentSounds.has_key(row[HW_LIST_COL_DEVICE][3]): >> If we're going to break long lines, break all of them in that >> conditional :-) >> > I've committed this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=99c9beca2a3c Thanks, Cole From crobinso at redhat.com Thu Jul 31 15:29:43 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 31 Jul 2008 11:29:43 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial/parallel devices In-Reply-To: <20080729165154.GI32498@redhat.com> References: <488DEB15.4090302@redhat.com> <20080729083933.GM32498@redhat.com> <488F4522.2070604@redhat.com> <20080729165154.GI32498@redhat.com> Message-ID: <4891DA67.5010907@redhat.com> Daniel P. Berrange wrote: > On Tue, Jul 29, 2008 at 12:28:18PM -0400, Cole Robinson wrote: >> Daniel P. Berrange wrote: >>> On Mon, Jul 28, 2008 at 11:51:49AM -0400, Cole Robinson wrote: >>>> The attached patch teaches virt-manager how to parse VM >>>> character devices, showing them in the details section. >>>> This patch also implements removing these devices. >>>> >>>> There are a couple quirks though: >>>> >>>> 1) All the possible character device xml properties >>>> aren't accounted for. This only parses target port, >>>> device type, and source path. I figure this covers >>>> the common cases, and is easily expandable. >>>> >>>> 2) Explicit entries are only set for serial and parallel >>>> devices, not console devices. Since by default, console >>>> is really just a duplicate of the first serial device, >>>> we try to detect this and label said serial device as >>>> appropriately (seen in the second screen shot). >>>> This simplifies things a good deal, and makes deleting >>>> easier, since in order to remove the console or >>>> first serial device, both xml blocks need to be removed >>>> simultaneously (not sure if this is a libvirt bug or not). >>> I think that is probably a bug. Can you re-test with the latest >>> CVS snapshot of libvirt where I've changed the handling a little >>> bit. Basically you should never need to add or remove a 'console' >>> device explicitly. Either it is there permanently (eg, Xen PV >>> always has a console), or it is automatically added/removed when >>> the first serial device is added or removed. >> >> Cool, things seem to work with current upstream. >> >> As far as the virt-manager code though, do you think it's a reasonable >> approach (don't have an explicit console entry)? > > This a little bit of an annoying part due to the way we had to maintain > backwards comaptability with the XML format. You can skip the 'console' > entry if-and-only-if there is at least one serial device. If there's > no serial device, you'll need to explicitly list the console. > Okay, i've committed this. The PV consoles will now be explictly listed. I left the special case "remove console and serial at the same time" code in incase this is released before a new libvirt spin. http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=66ace61933db Thanks, Cole From garich at ptd.net Thu Jul 31 19:55:18 2008 From: garich at ptd.net (Gary Richardson) Date: Thu, 31 Jul 2008 15:55:18 -0400 Subject: [et-mgmt-tools] problem with virt-manager Message-ID: <489218A6.1060606@ptd.net> Running virt-manager on my Fedora 9 system running kernel: 2.6.26-0.115.rc9.git2.fc10.x86_64 SMP I get the following error: gar xp]# virt-manager Traceback (most recent call last): File "/usr/share/virt-manager/virt-manager.py", line 310, in main() File "/usr/share/virt-manager/virt-manager.py", line 239, in main gtk.gdk.threads_init() SystemError: error return without exception set What prerequisites may be required that I might be missing? -- Gary Richardson Richardson Janitorial and More www.nodirtyfloors.com