From crobinso at redhat.com Tue Sep 2 16:22:40 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 02 Sep 2008 12:22:40 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: Use avahi to poll for local servers In-Reply-To: <48AF0D93.8020205@redhat.com> References: <48A99512.8080704@redhat.com> <48AF0D93.8020205@redhat.com> Message-ID: <48BD6850.4060006@redhat.com> Cole Robinson wrote: > Cole Robinson wrote: >> The attached patch adds support for avahi polling >> to the virt-manager 'Open Connection' dialog. >> libvirtd advertises itself via avahi so we get the >> hard stuff for free :). To test this you will need >> to make sure Multicast DNS (mDNS, port 5353 udp) is >> open on your machine. >> > > Second cut of this patch. Issues resolved: > > - Removed the check box, unconditionally poll for > connections if the user selects a remote conn > option. > > - Only use advertised 'name' as the list entry. > > - Don't add duplicate list entries. > > - If creating the initial avahi dbus interface > fails, just disable all polling, and never > activate the connection list. > > - Sort list entries alphabetically by default, > and add ability to sort ascend/descend > I've committed this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=d4e006ee6227 Thanks, Cole From crobinso at redhat.com Tue Sep 2 16:23:23 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 02 Sep 2008 12:23:23 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: Option to add sound device for vm create In-Reply-To: <48A4D50E.50609@redhat.com> References: <48A4D50E.50609@redhat.com> Message-ID: <48BD687B.6090501@redhat.com> Cole Robinson wrote: > The attached patch adds options to virt-manager's preferences > section for adding an audio device to new VMs. > > The new option defaults to adding audio for all new local > VMs, but skipping audio for remote VMs. > > I opted for the preferences screen approach since it seems > like the type of thing users will either always or never > want, and the new VM wizard is kind of cluttered as it is. > > Couple of screenshots: > > http://fedorapeople.org/~crobinso/virt-manager/virt-manager-sound-prefs.png > http://fedorapeople.org/~crobinso/virt-manager/virt-manager-sound-summary.png > > Thanks, > Cole > > I've committed this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=138ad06915c4 Thanks, Cole From crobinso at redhat.com Fri Sep 5 11:56:01 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 05 Sep 2008 07:56:01 -0400 Subject: [et-mgmt-tools] Heads Up: virt-manager + virtinst releases pending Message-ID: <48C11E51.1080702@redhat.com> Hi all, just wanted to send out a note that new releases for virt-manager and virtinst are close. Fedora 10 beta freeze is next Tuesday, September 9th, so We will probably push new releases on either Monday or early Tuesday. So if anyone has any pending patches, or some small thing they would really like to see fixed, please post about it soon and we can try to fit it in. Thanks, Cole From irraz.rulez at gmail.com Fri Sep 5 12:25:33 2008 From: irraz.rulez at gmail.com (irraz rulez) Date: Fri, 5 Sep 2008 14:25:33 +0200 Subject: [et-mgmt-tools] error bad superblock on /dev/mapper/debian-root In-Reply-To: References: Message-ID: Hi, My system root is in /dev/mapper/debian-root but virt-p2v-0.9.7 result error: mount '/dev/debian/root' /mnt/root mount: wrong fs type, bad option, bad superblock on /dev/mapper/debian-root, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Command failed: mount '/dev/debian/root' /mnt/root ~$ mount /dev/mapper/debian-root on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/hda1 on /boot type ext3 (rw) /dev/mapper/debian-home on /home type ext3 (rw) /dev/mapper/debian-tmp on /tmp type ext3 (rw) /dev/mapper/debian-usr on /usr type ext3 (rw) /dev/mapper/debian-var on /var type ext3 (rw) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) Can you help me, please? -- irraz -- ::[ 1rr4c10n4l ]:: web: www.lacuevadelchivo.com jabber/msn: irraz.rulez (at) gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: virt.log Type: text/x-log Size: 3001 bytes Desc: not available URL: From crobinso at redhat.com Fri Sep 5 14:16:28 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 05 Sep 2008 10:16:28 -0400 Subject: [et-mgmt-tools] [PATCH] virt-install: use --disk to specify size and sparse Message-ID: <48C13F3C.2060606@redhat.com> The attached patch expands the options that can be lumped onto virt-install's new --disk option to specify size of new storage, and whether we want to create it as sparse. The format for these options is: --disk path=/some/new/file,size=5,sparse=true|false This acts similar to the current options: if the file doesn't exist, size is required, and we default to sparse=True if it isn't specified. This effectively deprecates --file, --file-size, and --nonsparse, and in my opinion is much simpler. It also helps overcome some problems we had with the original options for cases of specifying multiple disks: there was no way to specify one sparse disk and one nonsparse disk, and generally specifying multiple disks was unclear and a pain. I also added a manpage section for the --disk option. Any comments appreciated. Thanks, Cole -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-disk-option-size-patch URL: From berrange at redhat.com Fri Sep 5 15:16:32 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 5 Sep 2008 16:16:32 +0100 Subject: [et-mgmt-tools] Heads Up: virt-manager + virtinst releases pending In-Reply-To: <48C11E51.1080702@redhat.com> References: <48C11E51.1080702@redhat.com> Message-ID: <20080905151632.GN22542@redhat.com> On Fri, Sep 05, 2008 at 07:56:01AM -0400, Cole Robinson wrote: > Hi all, just wanted to send out a note that new releases > for virt-manager and virtinst are close. > > Fedora 10 beta freeze is next Tuesday, September 9th, so > We will probably push new releases on either Monday or early > Tuesday. Good plan - we'rll be doing a libvirt release before tuesday too, so you can increment the Requires: libvirt to be >= 0.4.5 to ensure all your libvirt fixes are pulled into as deps. 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 Fri Sep 5 15:17:34 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 5 Sep 2008 16:17:34 +0100 Subject: [et-mgmt-tools] [PATCH] virt-install: use --disk to specify size and sparse In-Reply-To: <48C13F3C.2060606@redhat.com> References: <48C13F3C.2060606@redhat.com> Message-ID: <20080905151734.GO22542@redhat.com> On Fri, Sep 05, 2008 at 10:16:28AM -0400, Cole Robinson wrote: > The attached patch expands the options that can be > lumped onto virt-install's new --disk option to > specify size of new storage, and whether we want to > create it as sparse. > > The format for these options is: > > --disk path=/some/new/file,size=5,sparse=true|false > > This acts similar to the current options: if the file > doesn't exist, size is required, and we default to > sparse=True if it isn't specified. > > This effectively deprecates --file, --file-size, and > --nonsparse, and in my opinion is much simpler. It also > helps overcome some problems we had with the original > options for cases of specifying multiple disks: there > was no way to specify one sparse disk and one nonsparse > disk, and generally specifying multiple disks was > unclear and a pain. > > I also added a manpage section for the --disk option. Great - this all looks good to me. 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 kwilliams at renditionsoftware.com Fri Sep 5 15:42:28 2008 From: kwilliams at renditionsoftware.com (Kay Williams) Date: Fri, 05 Sep 2008 08:42:28 -0700 Subject: [et-mgmt-tools] Re: [libvirt] virt-install and custom distros In-Reply-To: <48A5E710.8040209@redhat.com> References: <48A5DEBC.8070302@renditionsoftware.com> <48A5E710.8040209@redhat.com> Message-ID: <48C15364.5060008@renditionsoftware.com> Can the issue be addressed in the upcoming virtinst release? Cole Robinson wrote: > Kay Williams wrote: >> We have an application that builds custom distributions based on RHEL, CentOS or >> Fedora. We would like to install these over the network using virt-install, but >> we've run into an issue with the distro check logic. Specifically, virt-install >> fails unless it finds a string "Red Hat Enterprise Linux", "Fedora" or "CentOS" >> within the family field of the .treeinfo file. >> >> Our application currently sets the family field to the user-provided distro name >> (see below). We have avoided using the base distro name given trademark concerns. >> >> [general] >> family = >> variant = >> >> We can get virt-install to pass the distro check by setting the family name to >> one of the accepted values, e.g. >> >> [general] >> family = Fedora >> variant = [user provided distro name] >> >> Is this the expected/desired use for the family and variant fields? Or is there >> another approach we should consider? >> >> Thanks, >> Kay > > (cc-ing et-mgmt-tools, since that is the list for virt-install/ > virt-manager) > > We shouldn't be failing if the family/variant is unknown: it's really > just a convenience check. We can just assume it's an unknown distro > and continue on, checking for [images-xen] and so on.. The code may > need to be reworked a bit to accomodate this. > > Although we don't do it at the moment, I could see us in the future > using this family/variant value to check our internal db on whether > to set up virtio and other specific settings. So using custom values > here may not allow virt-install to choose an optimal config, but we > should still try and let the install proceed. > > - Cole > > From crobinso at redhat.com Fri Sep 5 16:32:29 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 05 Sep 2008 12:32:29 -0400 Subject: [et-mgmt-tools] Re: [libvirt] virt-install and custom distros In-Reply-To: <48C15364.5060008@renditionsoftware.com> References: <48A5DEBC.8070302@renditionsoftware.com> <48A5E710.8040209@redhat.com> <48C15364.5060008@renditionsoftware.com> Message-ID: <48C15F1D.4030501@redhat.com> Kay Williams wrote: > Can the issue be addressed in the upcoming virtinst release? > Sure, I'll take a look at it by Monday. Thanks, Cole > Cole Robinson wrote: >> Kay Williams wrote: >>> We have an application that builds custom distributions based on RHEL, CentOS or >>> Fedora. We would like to install these over the network using virt-install, but >>> we've run into an issue with the distro check logic. Specifically, virt-install >>> fails unless it finds a string "Red Hat Enterprise Linux", "Fedora" or "CentOS" >>> within the family field of the .treeinfo file. >>> >>> Our application currently sets the family field to the user-provided distro name >>> (see below). We have avoided using the base distro name given trademark concerns. >>> >>> [general] >>> family = >>> variant = >>> >>> We can get virt-install to pass the distro check by setting the family name to >>> one of the accepted values, e.g. >>> >>> [general] >>> family = Fedora >>> variant = [user provided distro name] >>> >>> Is this the expected/desired use for the family and variant fields? Or is there >>> another approach we should consider? >>> >>> Thanks, >>> Kay >> (cc-ing et-mgmt-tools, since that is the list for virt-install/ >> virt-manager) >> >> We shouldn't be failing if the family/variant is unknown: it's really >> just a convenience check. We can just assume it's an unknown distro >> and continue on, checking for [images-xen] and so on.. The code may >> need to be reworked a bit to accomodate this. >> >> Although we don't do it at the moment, I could see us in the future >> using this family/variant value to check our internal db on whether >> to set up virtio and other specific settings. So using custom values >> here may not allow virt-install to choose an optimal config, but we >> should still try and let the install proceed. >> >> - Cole >> >> From crobinso at redhat.com Fri Sep 5 21:06:22 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 05 Sep 2008 17:06:22 -0400 Subject: [et-mgmt-tools] [PATCH] virt-install: use --disk to specify size and sparse In-Reply-To: <20080905151734.GO22542@redhat.com> References: <48C13F3C.2060606@redhat.com> <20080905151734.GO22542@redhat.com> Message-ID: <48C19F4E.9010909@redhat.com> Daniel P. Berrange wrote: > On Fri, Sep 05, 2008 at 10:16:28AM -0400, Cole Robinson wrote: >> The attached patch expands the options that can be >> lumped onto virt-install's new --disk option to >> specify size of new storage, and whether we want to >> create it as sparse. >> >> The format for these options is: >> >> --disk path=/some/new/file,size=5,sparse=true|false >> >> This acts similar to the current options: if the file >> doesn't exist, size is required, and we default to >> sparse=True if it isn't specified. >> >> This effectively deprecates --file, --file-size, and >> --nonsparse, and in my opinion is much simpler. It also >> helps overcome some problems we had with the original >> options for cases of specifying multiple disks: there >> was no way to specify one sparse disk and one nonsparse >> disk, and generally specifying multiple disks was >> unclear and a pain. >> >> I also added a manpage section for the --disk option. > > Great - this all looks good to me. > > Daniel Thanks, I've committed this: http://hg.et.redhat.com/virt/applications/virtinst--devel - Cole From erenoglu at gmail.com Sat Sep 6 14:54:01 2008 From: erenoglu at gmail.com (Emre Erenoglu) Date: Sat, 6 Sep 2008 16:54:01 +0200 Subject: [et-mgmt-tools] virtio support in libvirt and virt-manager? Message-ID: Hi everybody, Would anybody know when virtio will be supported in libvirt and virt-manager? For the moment, I can only use virtio enabled guests after editing the xml config files by hand and importing into virsh. For further info, please see: http://kvm.qumranet.com/kvmwiki/Virtio Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From erenoglu at gmail.com Sat Sep 6 14:54:01 2008 From: erenoglu at gmail.com (Emre Erenoglu) Date: Sat, 6 Sep 2008 16:54:01 +0200 Subject: [et-mgmt-tools] virtio support in libvirt and virt-manager? Message-ID: Hi everybody, Would anybody know when virtio will be supported in libvirt and virt-manager? For the moment, I can only use virtio enabled guests after editing the xml config files by hand and importing into virsh. For further info, please see: http://kvm.qumranet.com/kvmwiki/Virtio Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Sat Sep 6 21:17:55 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 6 Sep 2008 22:17:55 +0100 Subject: [et-mgmt-tools] virtio support in libvirt and virt-manager? In-Reply-To: References: Message-ID: <20080906211755.GA15383@redhat.com> On Sat, Sep 06, 2008 at 04:54:01PM +0200, Emre Erenoglu wrote: > Hi everybody, > > Would anybody know when virtio will be supported in libvirt and > virt-manager? > > For the moment, I can only use virtio enabled guests after editing the xml > config files by hand and importing into virsh. libvirt supports it as of 0.4.4. For networks add to the section. For disks change the target element to virt-manager will support it in the very near future, automatically enabling virtio for disks we know include 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 erenoglu at gmail.com Sat Sep 6 21:55:54 2008 From: erenoglu at gmail.com (Emre Erenoglu) Date: Sat, 6 Sep 2008 23:55:54 +0200 Subject: [et-mgmt-tools] virtio support in libvirt and virt-manager? In-Reply-To: <20080906211755.GA15383@redhat.com> References: <20080906211755.GA15383@redhat.com> Message-ID: Hi Daniel, On Sat, Sep 6, 2008 at 11:17 PM, Daniel P. Berrange wrote: > libvirt supports it as of 0.4.4. For networks add > to the section. For disks change the target element to > Thanks, this is how I use it today. > > virt-manager will support it in the very near future, automatically > enabling > virtio for disks we know include it Will it also work in the virt-manager GUI when I create a new guest from scratch? (not with a template etc.). I would like to be able to choose "virtio" as disk device model as well as the ethernet device. Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Sun Sep 7 12:04:00 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 7 Sep 2008 13:04:00 +0100 Subject: [et-mgmt-tools] virtio support in libvirt and virt-manager? In-Reply-To: References: <20080906211755.GA15383@redhat.com> Message-ID: <20080907120400.GB12055@redhat.com> On Sat, Sep 06, 2008 at 11:55:54PM +0200, Emre Erenoglu wrote: > Hi Daniel, > > On Sat, Sep 6, 2008 at 11:17 PM, Daniel P. Berrange wrote: > > > libvirt supports it as of 0.4.4. For networks add > > to the section. For disks change the target element to > > > > > Thanks, this is how I use it today. > > > > > virt-manager will support it in the very near future, automatically > > enabling > > virtio for disks we know include it > > > Will it also work in the virt-manager GUI when I create a new guest from > scratch? (not with a template etc.). I would like to be able to choose > "virtio" as disk device model as well as the ethernet device. Our design paradigm / goal is not to provide this kind of level of detail in the UI. The choice of IDE vs SCSI vs VirtIO vs Xen PV is determined automatically when you choose the OS Type & OS Variant. eg, if you choose Fedora >= 9, then we know that we should use VirtIO. 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 erenoglu at gmail.com Sun Sep 7 14:33:21 2008 From: erenoglu at gmail.com (Emre Erenoglu) Date: Sun, 7 Sep 2008 16:33:21 +0200 Subject: [et-mgmt-tools] virtio support in libvirt and virt-manager? In-Reply-To: <20080907120400.GB12055@redhat.com> References: <20080906211755.GA15383@redhat.com> <20080907120400.GB12055@redhat.com> Message-ID: Hi Again Daniel, On Sun, Sep 7, 2008 at 2:04 PM, Daniel P. Berrange wrote: > Our design paradigm / goal is not to provide this kind of level of > detail in the UI. The choice of IDE vs SCSI vs VirtIO vs Xen PV is > determined automatically when you choose the OS Type & OS Variant. > eg, if you choose Fedora >= 9, then we know that we should use VirtIO. > Thanks for the response. I understand the design decision. As you know, there are many distributions around, and not all are listed in the OS Type&Variant, such as my virtio supported distro Pardus. May I ask: 1) Will we have a choice such as "generic virtio enabled distribution" in the Linux os variants? 2) If we are installing Windows and then we'll install KVM paravirtual virtio drivers, how shall we do? 3) What if a generic distro is installed without virtio first, but then can become virtio-enabled by an initrd configuration file? Thanks a lot, -- Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Sun Sep 7 18:31:52 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 07 Sep 2008 14:31:52 -0400 Subject: [et-mgmt-tools] virtio support in libvirt and virt-manager? In-Reply-To: References: <20080906211755.GA15383@redhat.com> <20080907120400.GB12055@redhat.com> Message-ID: <48C41E18.2060604@redhat.com> Emre Erenoglu wrote: > Hi Again Daniel, > > > On Sun, Sep 7, 2008 at 2:04 PM, Daniel P. Berrange > > wrote: > > Our design paradigm / goal is not to provide this kind of level of > detail in the UI. The choice of IDE vs SCSI vs VirtIO vs Xen PV is > determined automatically when you choose the OS Type & OS Variant. > eg, if you choose Fedora >= 9, then we know that we should use VirtIO. > > > Thanks for the response. I understand the design decision. As you > know, there are many distributions around, and not all are listed in > the OS Type&Variant, such as my virtio supported distro Pardus. May I ask: > > 1) Will we have a choice such as "generic virtio enabled distribution" > in the Linux os variants? Something along these lines probably isn't a bad idea. If virtio capabilities are available in all kernels past 2.6.foo, then we will definitely want something like this, maybe just worded in a different way. > 2) If we are installing Windows and then we'll install KVM paravirtual > virtio drivers, how shall we do? > 3) What if a generic distro is installed without virtio first, but > then can become virtio-enabled by an initrd configuration file? > Current upstream virt-manager will allow you to add a virtio disk to an existing guest: you just choose the virtio option from the device type drop down that also includes scsi, ide disk, floppy, etc. There is no option to choose a network device model when adding a nic to an existing guest, though this isn't something I'd be opposed to adding. But as far as install time is concerned, the distro dictionary is really the way to solve this. Thanks, Cole From fj0588di at aa.jp.fujitsu.com Mon Sep 8 09:12:17 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Mon, 8 Sep 2008 18:12:17 +0900 Subject: [et-mgmt-tools] [RFC][PATCH] virt-manager calls migration API Message-ID: <200809081812.HDI21360.6EJ90KG9@aa.jp.fujitsu.com> Hi, I just make the proto patch that calls migration API from virt-manager. Form unity point of view, This proto patch adds Migrate in as same layer as operations for the Domain. Fisrt, this patch adds "Migrate" to the right-click menu when selected a domain. Run Run Pause Pause Shutdown Shutdown --------- ---> -------- Open(O) Migrate -------- Open(O) When "Migrate" selected, it goes on new window open which shows available(have been connecting) hosts. Of course, I have been knowing that there is Drag&Drop way. By the way, (1)It is necessary to migrate a domain that users modify an environmental setting. (ex. for XenD xend-config, ...) And (2)I think it that is necessary to improve usability that there is "precheking" beofre migrating. (ex. same cpu family/processor number?, enough free memory?, ...) Do you already have a idea that virt-manager servies above (1)(2) ? Finally, I understand that migrated domain's state switches Running and Shutoff alternately, because current virt-maneger manages domains by UUID. Is there a plan that this problem is solved? virtManager/domain.py | 27 ++++++ virtManager/engine.py | 82 ++++++++++++++++++++ virtManager/hostlist.py | 172 ++++++++++++++++++++++++++++++++++++++++++ virtManager/manager.py | 27 ++!!!! vmm-hostlist.glade | 195 ++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 488 insertions(+), 15 modifications(!) Thanks, Shigeki Sakamoto. -------------- next part -------------- A non-text attachment was scrubbed... Name: migrate.patch Type: application/octet-stream Size: 26975 bytes Desc: not available URL: From sakaia at jp.fujitsu.com Mon Sep 8 11:10:17 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Mon, 08 Sep 2008 20:10:17 +0900 Subject: [et-mgmt-tools] Question about virt-viewer build trouble Message-ID: <200809081110.m88BAJEr031285@fjmscan501.ms.jp.fujitsu.com> Hi, Dan Why following messages are appeared? distributed gtkvnc is 0.3.7 now. http://builder.virt-manager.org/module-virt-viewer--devel.html checking for GTKVNC... configure: error: Package requirements (gtk-vnc-1.0 >= 0.3.5) were not met: Requested 'gtk-vnc-1.0 >= 0.3.5' but version of GTK-VNC is 0.3.4 c.f. I saw this troble from week ago. Thanks Atsushi SAKAI From berrange at redhat.com Mon Sep 8 11:16:22 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 8 Sep 2008 12:16:22 +0100 Subject: [et-mgmt-tools] Question about virt-viewer build trouble In-Reply-To: <200809081110.m88BAJEr031285@fjmscan501.ms.jp.fujitsu.com> References: <200809081110.m88BAJEr031285@fjmscan501.ms.jp.fujitsu.com> Message-ID: <20080908111622.GH2315@redhat.com> On Mon, Sep 08, 2008 at 08:10:17PM +0900, Atsushi SAKAI wrote: > Hi, Dan > > Why following messages are appeared? > distributed gtkvnc is 0.3.7 now. > > http://builder.virt-manager.org/module-virt-viewer--devel.html > checking for GTKVNC... configure: error: Package requirements (gtk-vnc-1.0 >= 0.3.5) were not met: > > Requested 'gtk-vnc-1.0 >= 0.3.5' but version of GTK-VNC is 0.3.4 I upgraded the build machine from Fedora 6, to Fedora 9. Unfortunately the new rpmbuild in Fedora 9 overrides the PKG_CONFIG_PATH set by the autobuild server so that it doesn't find GTK-VNC built earlier :-( I'm still trying to figure out how to fix this.. It isn't a virt-viewer/gtk-vnc problem at least - just a build system thing 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 erenoglu at gmail.com Mon Sep 8 12:01:59 2008 From: erenoglu at gmail.com (Emre Erenoglu) Date: Mon, 8 Sep 2008 14:01:59 +0200 Subject: [et-mgmt-tools] Question about virt-viewer build trouble In-Reply-To: <20080908111622.GH2315@redhat.com> References: <200809081110.m88BAJEr031285@fjmscan501.ms.jp.fujitsu.com> <20080908111622.GH2315@redhat.com> Message-ID: Hi, Thinking that it may be related, in my Pardus 2008 system, virtinstall --> installed in /usr (no configure script, nor make, thus no possibility to install it in /usr/local) gtk-vnc --> installed in /usr/local virt-manager --> installed in /usr/local In this case, virt-manager does not run claiming that gtk-vnc is not installed. Emre On Mon, Sep 8, 2008 at 1:16 PM, Daniel P. Berrange wrote: > On Mon, Sep 08, 2008 at 08:10:17PM +0900, Atsushi SAKAI wrote: > > Hi, Dan > > > > Why following messages are appeared? > > distributed gtkvnc is 0.3.7 now. > > > > http://builder.virt-manager.org/module-virt-viewer--devel.html > > checking for GTKVNC... configure: error: Package requirements > (gtk-vnc-1.0 >= 0.3.5) were not met: > > > > Requested 'gtk-vnc-1.0 >= 0.3.5' but version of GTK-VNC is 0.3.4 > > I upgraded the build machine from Fedora 6, to Fedora 9. Unfortunately > the new rpmbuild in Fedora 9 overrides the PKG_CONFIG_PATH set by the > autobuild server so that it doesn't find GTK-VNC built earlier :-( I'm > still trying to figure out how to fix this.. > > It isn't a virt-viewer/gtk-vnc problem at least - just a build system thing > > 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 > :| > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Mon Sep 8 15:03:55 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 08 Sep 2008 11:03:55 -0400 Subject: [et-mgmt-tools] Re: [libvirt] virt-install and custom distros In-Reply-To: <48C15364.5060008@renditionsoftware.com> References: <48A5DEBC.8070302@renditionsoftware.com> <48A5E710.8040209@redhat.com> <48C15364.5060008@renditionsoftware.com> Message-ID: <48C53EDB.5020907@redhat.com> Kay Williams wrote: > Cole Robinson wrote: >> Kay Williams wrote: >>> We have an application that builds custom distributions based on RHEL, CentOS or >>> Fedora. We would like to install these over the network using virt-install, but >>> we've run into an issue with the distro check logic. Specifically, virt-install >>> fails unless it finds a string "Red Hat Enterprise Linux", "Fedora" or "CentOS" >>> within the family field of the .treeinfo file. >>> >>> Our application currently sets the family field to the user-provided distro name >>> (see below). We have avoided using the base distro name given trademark concerns. >>> >>> [general] >>> family = >>> variant = >>> >>> We can get virt-install to pass the distro check by setting the family name to >>> one of the accepted values, e.g. >>> >>> [general] >>> family = Fedora >>> variant = [user provided distro name] >>> >>> Is this the expected/desired use for the family and variant fields? Or is there >>> another approach we should consider? >>> >>> Thanks, >>> Kay Okay, this should work now: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=0080e4c6652f We won't detect the custom distro as Fedora, but we can still boot off of it by parsing it's treeinfo for the relevant paths or just polling known tree locations for media. Let me know if there are any problems. Thanks, Cole From rlaager at wiktel.com Tue Sep 9 18:59:39 2008 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 09 Sep 2008 13:59:39 -0500 Subject: [et-mgmt-tools] Looking for Guidance on Various virt-manager Bug Reports Message-ID: <1220986779.25115.15.camel@watermelon.coderich.net> A few weeks ago, I re-installed a server with Ubuntu Hardy and thus started using virt-manager for the first time. Previously, we were using VMWare Server. FWIW, we only have a couple of virtual machines running at the moment. In doing so, I filed a pile of bug reports. Some of these are trivial text nitpicks. Some are feature suggestions, etc. I'm looking for feedback on them. I should be able to write patches for at least the trivial stuff here, if not some of the more in-depth things, but I want to know that the *ideas* are good before I waste time implementing. (And, if they're stupid, let's close some bug reports!) You should be able to see them at the URL below. I used tinyurl because the Launchpad URL was several lines long when wrapped. http://tinyurl.com/6cwp7f I'll take comments here or on the bug reports, whichever you would prefer. Thanks, Richard P.S. If some of these are distro-specific, I understand. The distro maintainer is short on time and suggested I come here because he can't afford to deviate from upstream much. Plus, many or most of these will apply upstream. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From crobinso at redhat.com Tue Sep 9 19:30:41 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 09 Sep 2008 15:30:41 -0400 Subject: [et-mgmt-tools] Looking for Guidance on Various virt-manager Bug Reports In-Reply-To: <1220986779.25115.15.camel@watermelon.coderich.net> References: <1220986779.25115.15.camel@watermelon.coderich.net> Message-ID: <48C6CEE1.2000905@redhat.com> Richard Laager wrote: > A few weeks ago, I re-installed a server with Ubuntu Hardy and thus > started using virt-manager for the first time. Previously, we were using > VMWare Server. FWIW, we only have a couple of virtual machines running > at the moment. > > In doing so, I filed a pile of bug reports. Some of these are trivial > text nitpicks. Some are feature suggestions, etc. I'm looking for > feedback on them. I should be able to write patches for at least the > trivial stuff here, if not some of the more in-depth things, but I want > to know that the *ideas* are good before I waste time implementing. > (And, if they're stupid, let's close some bug reports!) > > You should be able to see them at the URL below. I used tinyurl because > the Launchpad URL was several lines long when wrapped. > http://tinyurl.com/6cwp7f > > I'll take comments here or on the bug reports, whichever you would > prefer. > > Thanks, > Richard > > P.S. If some of these are distro-specific, I understand. The distro > maintainer is short on time and suggested I come here because he can't > afford to deviate from upstream much. Plus, many or most of these will > apply upstream. > Hi Richard, thanks for showing interest in fixing these issues. I skimmed through the list of bugs. Most of the default choice and wording nits are certainly valid, and I'm sure most apply upstream, so I'd be glad to take them. Some of the others are already fixed upstream (virDomainDetachDevice error, adding virtio disks post install, shutdown -> force poweroff). In general, for non-critical bugs or feature suggestions, I would suggest filing them with us upstream, under the 'Virtualization' component in bugzilla.redhat.com. Ubuntu doesn't deviate much from upstream for these tools so any issues they have are probably relevant here. That way things are centralized for the upstream developers as well == more attention to the report. Thanks, Cole From rlaager at wiktel.com Tue Sep 9 20:30:45 2008 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 09 Sep 2008 15:30:45 -0500 Subject: [et-mgmt-tools] Looking for Guidance on Various virt-manager Bug Reports In-Reply-To: <48C6CEE1.2000905@redhat.com> References: <1220986779.25115.15.camel@watermelon.coderich.net> <48C6CEE1.2000905@redhat.com> Message-ID: <1220992245.25115.38.camel@watermelon.coderich.net> On Tue, 2008-09-09 at 15:30 -0400, Cole Robinson wrote: > Some of the others are already fixed upstream > virDomainDetachDevice error, Okay, marked as such in Launchpad. > adding virtio disks post install, Do you have a bug number for this one? I see #457055 [0], but that seems to indicate you just want to auto-detect it. Has the use case of Windows been covered? For example, I said in [1] that "...You need to tell KVM to use virtio, but that wouldn't be a sane default for Windows because it doesn't ship those drivers out of the box." > shutdown -> force poweroff Do you have a reference for this? If not, is this doing an ACPI shutdown? If so, what does it do for a Windows XP guest (which, at least in the past, required ACPI be turned off or it'll use 100% CPU)? Has the UI been updated to say "Shutdown" (and/or "Power Off") instead of "Destroy"? > In general, for non-critical bugs or feature suggestions, I would > suggest filing them with us upstream, under the 'Virtualization' > component in bugzilla.redhat.com. I don't mean to be nitpicky here, but you mean "Virtualization Tools", right? I just want to make sure I have the right component. Thanks, Richard [0] https://bugzilla.redhat.com/show_bug.cgi?id=457055 [1] https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/218574/comments/10 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From crobinso at redhat.com Tue Sep 9 20:49:27 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 09 Sep 2008 16:49:27 -0400 Subject: [et-mgmt-tools] Looking for Guidance on Various virt-manager Bug Reports In-Reply-To: <1220992245.25115.38.camel@watermelon.coderich.net> References: <1220986779.25115.15.camel@watermelon.coderich.net> <48C6CEE1.2000905@redhat.com> <1220992245.25115.38.camel@watermelon.coderich.net> Message-ID: <48C6E157.8070302@redhat.com> Richard Laager wrote: > On Tue, 2008-09-09 at 15:30 -0400, Cole Robinson wrote: >> Some of the others are already fixed upstream > >> virDomainDetachDevice error, > > Okay, marked as such in Launchpad. > >> adding virtio disks post install, > > Do you have a bug number for this one? I see #457055 [0], but that seems > to indicate you just want to auto-detect it. Has the use case of Windows > been covered? For example, I said in [1] that "...You need to tell KVM > to use virtio, but that wouldn't be a sane default for Windows because > it doesn't ship those drivers out of the box." No, there is no bug number tracking this specific issue. Here is the upstream commit: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=0240dcdfef74 This allow adding a virtio to a disk via the 'Add Hardware' wizard: 'virtio disk' is now an option in the device type drop down when adding storage. There is no analogous option for networking (yet). So there is both an install time option (choosing a distro that supports virtio out of the box) and a post install option (adding the virtio disk after the fact). > >> shutdown -> force poweroff > > Do you have a reference for this? If not, is this doing an ACPI > shutdown? If so, what does it do for a Windows XP guest (which, at least > in the past, required ACPI be turned off or it'll use 100% CPU)? Has the > UI been updated to say "Shutdown" (and/or "Power Off") instead of > "Destroy"? 'shutdown' requests an ACPI shutdown from qemu/kvm. If ACPI isn't enabled in the guest, I don't know what the behavior is at the qemu level, but libvirt/virt-manager does nothing differently. Force Poweroff in current upstream maps to Destroy: it's just more clearly worded. > >> In general, for non-critical bugs or feature suggestions, I would >> suggest filing them with us upstream, under the 'Virtualization' >> component in bugzilla.redhat.com. > > I don't mean to be nitpicky here, but you mean "Virtualization Tools", > right? I just want to make sure I have the right component. > Yes, sorry, the correct 'product' is 'Virtualization Tools' Thanks, Cole From berrange at redhat.com Tue Sep 9 21:42:11 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 9 Sep 2008 22:42:11 +0100 Subject: [et-mgmt-tools] Looking for Guidance on Various virt-manager Bug Reports In-Reply-To: <1220986779.25115.15.camel@watermelon.coderich.net> References: <1220986779.25115.15.camel@watermelon.coderich.net> Message-ID: <20080909214211.GB32275@redhat.com> On Tue, Sep 09, 2008 at 01:59:39PM -0500, Richard Laager wrote: > A few weeks ago, I re-installed a server with Ubuntu Hardy and thus > started using virt-manager for the first time. Previously, we were using > VMWare Server. FWIW, we only have a couple of virtual machines running > at the moment. > > In doing so, I filed a pile of bug reports. Some of these are trivial > text nitpicks. Some are feature suggestions, etc. I'm looking for > feedback on them. I should be able to write patches for at least the > trivial stuff here, if not some of the more in-depth things, but I want > to know that the *ideas* are good before I waste time implementing. > (And, if they're stupid, let's close some bug reports!) > > You should be able to see them at the URL below. I used tinyurl because > the Launchpad URL was several lines long when wrapped. > http://tinyurl.com/6cwp7f > > I'll take comments here or on the bug reports, whichever you would > prefer. > > Thanks, > Richard > > P.S. If some of these are distro-specific, I understand. The distro > maintainer is short on time and suggested I come here because he can't > afford to deviate from upstream much. Plus, many or most of these will > apply upstream. Basically my guidance for filing bug reports depends on how much time & skill the bug reporter has to spend. If you can only spare time to report the bug and need someone else to work through getting it fixed upstream then file it with your OS distro & let their maintainers deal with it. If you have the free time or technical skill & interest to actually work on a fix yourself, then file it directly with in the upstream project's bug tracker. The latter will ensure it gets into upstream codebase at the soonest opportunity, though the OS distro will likely then wait till next upstream release till they pull the fix in. As to whether its a distro specific bug or not - just use your reasonable judgement - the worst that can happen is that bug can be moved from the distro to upstream bug tracker, or vica-verca. Just getting a bug report filed is the most important bit so there's somewhere to track the issue. 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 crobinso at redhat.com Wed Sep 10 20:21:42 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 10 Sep 2008 16:21:42 -0400 Subject: [et-mgmt-tools] ANNOUNCE: New release virt-manager 0.6.0 Message-ID: <48C82C56.4000904@redhat.com> I'm happy to announce a new virt-manager release, version 0.6.0. The release can be downloaded from: http://virt-manager.org/download.html The direct download link is: http://virt-manager.org/download/sources/virt-manager/virt-manager-0.6.0.tar.gz This release includes: - Remote storage management and provisioning: View, add, remove, and provision libvirt managed storage. Attach managed storage to a remote VM. - Remote VM installation support: Install from managed media (cdrom) or PXE. Simple install time storage provisioning. - VM details and console windows merged: each VM is now represented by a single tabbed window. - Use Avahi to list libvirtd instances on network. - Hypervisor Autoconnect: Option to connect to hypervisor at virt-manager start up. - Option to add sound device emulation when creating new guests. - Virtio and USB options when adding a disk device. - Allow viewing and removing VM sound, serial, parallel, and console devices. - Specifying a specific keymap when adding display device. - Allow app to keep running with only a VM window open. - Allow limiting amount of stored stats history. - Numerous bug fixes and minor improvements. Thanks to everyone who has contributed to this release through testing, bug reporting, submitting patches, and otherwise sending in feedback! Thanks, Cole From crobinso at redhat.com Wed Sep 10 20:23:27 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 10 Sep 2008 16:23:27 -0400 Subject: [et-mgmt-tools] ANNOUNCE: New release virtinst 0.400.0 Message-ID: <48C82CBF.4080807@redhat.com> I'm happy to announce a new virtinst release, version 0.400.0. It can be downloaded at: http://virt-manager.org/download.html The direct link is: http://virt-manager.org/download/sources/virtinst/virtinst-0.400.0.tar.gz New in this release: - New tool 'virt-convert': Allows converting between different types of virt configuration files. Currently only supports vmx -> virt-image. - New tool 'virt-pack': Converts virt-image xml format to vmx and packs in a tar.gz. (Note this will likely be merged with virt-convert in the future). - virt-install: Support for remote VM installation. Can use install media and disk images on remote host if shared via libvirt. Allows provisioning storage on remote pools. - virt-install new options: new --wait option, allows putting a hard time limit on installs. new --sound option, to create VM with soundcard emulation. new --disk option, allows specifying media as a path, storage volume, or a pool to provision storage on, device type, and several other options. Deprecates --file, --size, --nonsparse. new --prompt option. Input prompting is no longer the default, this option turns it back on. - virt-install: allow setting cpu pinning information for qemu/kvm VMs. - virt-install: numa support via --cpuset=auto option. - virt-image: --replace option to overwrite existing VM image file. - virt-image: support multiple network interfaces in virt-image format. - use virtio disk/net drivers if chosen os entry supports it (Fedora 9/10, Ubuntu Hardy). - Numerous bug fixes and minor improvements. Thanks to everyone who has contributed to this release whether by testing, bug reporting, submitting patches, and otherwise sending feedback! Thanks, Cole From jboggs at redhat.com Fri Sep 12 18:15:01 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 12 Sep 2008 14:15:01 -0400 Subject: [et-mgmt-tools] [patch] virtinst--devel - virt-convert error Message-ID: <48CAB1A5.7090201@redhat.com> Look like the release after .300 had OS_TYPES renamed to _OS_TYPES in FullVirtGuest.py creating this error for virt-convert ['(VMDK) image open: flags=0x2 filename=/home/jboggs/vmware/OSX/OSX-0.vmdk\n'] ERROR type object 'FullVirtGuest' has no attribute 'OS_TYPES' Traceback (most recent call last): File "/usr/bin/virt-convert", line 252, in main() File "/usr/bin/virt-convert", line 242, in main outp.export_file(vmdef, options.output_file) File "/usr/lib/python2.5/site-packages/virtconv/parsers/virtimage.py", line 225, in export_file acpi, apic = export_os_params(vm) File "/usr/lib/python2.5/site-packages/virtconv/parsers/virtimage.py", line 86, in export_os_params ostype = fv.OS_TYPES.get(vm.os_type) AttributeError: type object 'FullVirtGuest' has no attribute 'OS_TYPES' -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-os_types.patch Type: text/x-patch Size: 405 bytes Desc: not available URL: From crobinso at redhat.com Fri Sep 12 19:00:13 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 12 Sep 2008 15:00:13 -0400 Subject: [et-mgmt-tools] [patch] virtinst--devel - virt-convert error In-Reply-To: <48CAB1A5.7090201@redhat.com> References: <48CAB1A5.7090201@redhat.com> Message-ID: <48CABC3D.4060804@redhat.com> Joey Boggs wrote: > Look like the release after .300 had OS_TYPES renamed to _OS_TYPES in > FullVirtGuest.py creating this error for virt-convert > Ahh, foo. I explicitly renamed this so that the structure was private and no users of the API would be accessing it directly, so that we could change the internal format of OS_TYPES without repercussions. I forgot to check virtconv for uses though :( Eventually the os dictionary should be moved out of the fullvirtguest class and be a virtinst global thing, that any pieces of the library can access. Also the virtimage format should handle this os type/variant natively so we don't need to do any lookup on the virt-convert side. Anyways, I've applied this patch, with a big TODO for the above cases. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=1021d9c89a74 Thanks, Cole From corman at cormander.com Fri Sep 12 20:16:27 2008 From: corman at cormander.com (Corey Henderson) Date: Fri, 12 Sep 2008 14:16:27 -0600 (MDT) Subject: [et-mgmt-tools] fix for suse install on virtinst 0.3 Message-ID: <55430.65.116.116.6.1221250587.squirrel@webmail.ravencore.com> Hello, I'm running a CentOS 5.2 xen dom0 with opensuse 10.3 paravirutalized guests. I've been using my own installation script in the past, but have decided to give virt-install a whirl with autoyast. It got to the point where it downloads the ls-lR.gz file and looks for the kernel RPM, and fails. Looking at the code, I was a little puzzled as to why it's trying to extract a kernel rpm and built an initrd when one already exists in the opensuse 10.3 install tree.... so I wrote a quick patch that basically just removed the wacky code and added the paths: + kernelpath = "boot/i386/vmlinuz-xenpae" + initrdpath = "boot/i386/initrd-xenpae" (this is obviously just for i386, might want to do something a little more elaborate to detect if arch is x86_64) This patch is against the CentOS 5.2 distribution package: python-virtinst-0.300.2-8.el5 and it works for me beautifully now. Feedback is welcome. Thanks! -- Corey -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OSDistro.suse.patch.txt URL: From berrange at redhat.com Fri Sep 12 21:49:43 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 12 Sep 2008 22:49:43 +0100 Subject: [et-mgmt-tools] fix for suse install on virtinst 0.3 In-Reply-To: <55430.65.116.116.6.1221250587.squirrel@webmail.ravencore.com> References: <55430.65.116.116.6.1221250587.squirrel@webmail.ravencore.com> Message-ID: <20080912214943.GA24727@redhat.com> On Fri, Sep 12, 2008 at 02:16:27PM -0600, Corey Henderson wrote: > Hello, > > I'm running a CentOS 5.2 xen dom0 with opensuse 10.3 paravirutalized > guests. I've been using my own installation script in the past, but have > decided to give virt-install a whirl with autoyast. > > It got to the point where it downloads the ls-lR.gz file and looks for the > kernel RPM, and fails. > > Looking at the code, I was a little puzzled as to why it's trying to > extract a kernel rpm and built an initrd when one already exists in the > opensuse 10.3 install tree.... so I wrote a quick patch that basically > just removed the wacky code and added the paths: This must be new change. Historically SUSE never provided pre-built kernel/initrds for Xen installation. So, deleteing this code is not the correct approach. It should first probe for the pre-built image paths, and fallback to the existing code if those are missing. > + kernelpath = "boot/i386/vmlinuz-xenpae" > + initrdpath = "boot/i386/initrd-xenpae" > > (this is obviously just for i386, might want to do something a little more > elaborate to detect if arch is x86_64) On a i386 host, it obviously only needs to look for the i386 directory, but on a x86_64 host, it would need to look for both x86_64 and then try the i386 dir if that fails. 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 erenoglu at gmail.com Sat Sep 13 14:09:56 2008 From: erenoglu at gmail.com (Emre Erenoglu) Date: Sat, 13 Sep 2008 16:09:56 +0200 Subject: [et-mgmt-tools] virt-manager 0.6.0 problem in install script for omf.make ? Message-ID: Hi, I was trying to install virt-manager for my distro (Pardus 2008). However, I faced a strange issue, possibly a bug, maybe in virt-manager, maybe in Pardus itself: *Introduction:* Pardus 2008's scrollkeeper keeps the state data in the following directories: emre at voyager virt-manager-0.6.0 $ scrollkeeper-config --localstatedir /var emre at voyager virt-manager-0.6.0 $ scrollkeeper-config --pkglocalstatedir /var/scrollkeeper However, when the build is completed and install script starts, the turn comes to the following section in omf.make file: install-data-hook-omf: $(mkinstalldirs) $(DESTDIR)$(omf_dest_dir) for file in $(omffile); do \ $(INSTALL_DATA) $$file.out $(DESTDIR)$(omf_dest_dir)/$$file; \ done -scrollkeeper-update -p $(scrollkeeper_localstate_dir) -o $(DESTDIR)$(omf_dest_dir) This scrollkeeper-update command segfaults at this stage. I found that the command issued during the package build/install is: scrollkeeper-update -p /var/lib/scrollkeeper -o /var/pisi/virt-manager-0.6.0-1/install/usr/share/omf/virt-manager This shows that the statedir is /var/lib/scrollkeeper instead of the /var/scrollkeeper. Do you have an idea why this can happen? Note: It also segfaults when I do an install to /usr/local (Default), giving another segfault with this command: scrollkeeper-update -p /usr/local/var/scrollkeeper -o /usr/local/share/omf/virt-manager Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From onion at garlic.com Sat Sep 13 22:20:32 2008 From: onion at garlic.com (Roy) Date: Sat, 13 Sep 2008 15:20:32 -0700 Subject: [et-mgmt-tools] Create option missing from virt-manager Message-ID: <48CC3CB0.3080807@garlic.com> I am running virt-manager on CentOS 5.2 system. It will not allow me to create a virtual machine. The option is missing from the "File" menu. The command virt-manager --show-domain-creator just returns to the command line The version that installs is 0.5.3. I also built 0.5.4 with similar results Any ideas? Roy From crobinso at redhat.com Sun Sep 14 20:41:46 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 14 Sep 2008 16:41:46 -0400 Subject: [et-mgmt-tools] fix for suse install on virtinst 0.3 In-Reply-To: <55430.65.116.116.6.1221250587.squirrel@webmail.ravencore.com> References: <55430.65.116.116.6.1221250587.squirrel@webmail.ravencore.com> Message-ID: <48CD770A.4080809@redhat.com> Corey Henderson wrote: > Hello, > > I'm running a CentOS 5.2 xen dom0 with opensuse 10.3 paravirutalized > guests. I've been using my own installation script in the past, but have > decided to give virt-install a whirl with autoyast. > > It got to the point where it downloads the ls-lR.gz file and looks for the > kernel RPM, and fails. > > Looking at the code, I was a little puzzled as to why it's trying to > extract a kernel rpm and built an initrd when one already exists in the > opensuse 10.3 install tree.... so I wrote a quick patch that basically > just removed the wacky code and added the paths: > > + kernelpath = "boot/i386/vmlinuz-xenpae" > + initrdpath = "boot/i386/initrd-xenpae" > > (this is obviously just for i386, might want to do something a little more > elaborate to detect if arch is x86_64) > > This patch is against the CentOS 5.2 distribution package: > python-virtinst-0.300.2-8.el5 and it works for me beautifully now. > > Feedback is welcome. > > Thanks! > Hi Corey, Thanks for the patch, though current virtinst release 0.400.0 should have this fixed, I updated the suse kernel fetching to work with their latest tree structure a couple months ago. Check out https://bugzilla.redhat.com/show_bug.cgi?id=449129 , this is being tracked for RHEL 5.3, and there is a patch in that bug that should fix your problems. If it doesn't, please follow up in the bug report. Thanks, Cole From crobinso at redhat.com Sun Sep 14 20:47:51 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 14 Sep 2008 16:47:51 -0400 Subject: [et-mgmt-tools] Create option missing from virt-manager In-Reply-To: <48CC3CB0.3080807@garlic.com> References: <48CC3CB0.3080807@garlic.com> Message-ID: <48CD7877.3090405@redhat.com> Roy wrote: > I am running virt-manager on CentOS 5.2 system. It will not allow me to > create a virtual machine. The option is missing from the "File" menu. > Hmm, what exactly do you mean 'not allow'? Also, there is no option under the file menu to add a new VM, this is typically launched by the 'New' button on the bottom row of the main virt-manager window. You first need to connect to the hypervisor for this to be active though, so right click on the entry the 'Xen' entry and hit 'Connect'. The new button should now be sensitive. > The command > > virt-manager --show-domain-creator > > This is known busted in 5.2, there is a bug filed for this to be fixed but it hasn't been determined yet if this will be fixed for 5.3. Thanks, Cole From crobinso at redhat.com Sun Sep 14 21:09:31 2008 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 14 Sep 2008 17:09:31 -0400 Subject: [et-mgmt-tools] virt-manager 0.6.0 problem in install script for omf.make ? In-Reply-To: References: Message-ID: <48CD7D8B.6040607@redhat.com> Emre Erenoglu wrote: > Hi, > > I was trying to install virt-manager for my distro (Pardus 2008). > However, I faced a strange issue, possibly a bug, maybe in > virt-manager, maybe in Pardus itself: > > *Introduction:* > Pardus 2008's scrollkeeper keeps the state data in the following > directories: > > emre at voyager virt-manager-0.6.0 $ scrollkeeper-config --localstatedir > /var > emre at voyager virt-manager-0.6.0 $ scrollkeeper-config --pkglocalstatedir > /var/scrollkeeper > > However, when the build is completed and install script starts, the > turn comes to the following section in omf.make file: > > install-data-hook-omf: > $(mkinstalldirs) $(DESTDIR)$(omf_dest_dir) > for file in $(omffile); do \ > $(INSTALL_DATA) $$file.out > $(DESTDIR)$(omf_dest_dir)/$$file; \ > done > -scrollkeeper-update -p $(scrollkeeper_localstate_dir) -o > $(DESTDIR)$(omf_dest_dir) > > This scrollkeeper-update command segfaults at this stage. I found that > the command issued during the package build/install is: > > scrollkeeper-update -p /var/lib/scrollkeeper -o > /var/pisi/virt-manager-0.6.0-1/install/usr/share/omf/virt-manager > > This shows that the statedir is /var/lib/scrollkeeper instead of the > /var/scrollkeeper. > > Do you have an idea why this can happen? > Seems like configure is thinking the intended localstatedir is /var/lib. Try running configure with '--localstatedir=/var' > Note: It also segfaults when I do an install to /usr/local (Default), > giving another segfault with this command: > scrollkeeper-update -p /usr/local/var/scrollkeeper -o > /usr/local/share/omf/virt-manager > If that command segfaults, it must be a scrollkeeper issue. Maybe we are feeding it invalid input in some manner. I'd recommend filing a bug with your distro. Let us know if you get it to work, Cole From erenoglu at gmail.com Sun Sep 14 21:23:14 2008 From: erenoglu at gmail.com (Emre Erenoglu) Date: Sun, 14 Sep 2008 23:23:14 +0200 Subject: [et-mgmt-tools] virt-manager 0.6.0 problem in install script for omf.make ? In-Reply-To: <48CD7D8B.6040607@redhat.com> References: <48CD7D8B.6040607@redhat.com> Message-ID: Hi, On Sun, Sep 14, 2008 at 11:09 PM, Cole Robinson wrote: > > Seems like configure is thinking the intended localstatedir is > /var/lib. Try running configure with '--localstatedir=/var' > I will try that. > > If that command segfaults, it must be a scrollkeeper issue. > Maybe we are feeding it invalid input in some manner. > I'd recommend filing a bug with your distro. > Well I talked with the developers of my distro. They said using "scrollkeeper" in "make install" script would not be a best thing to do. They said if the necessary files are placed in /usr/share then a special script runs automatically at package install and adds them to the scrollkeeper database. Thus, I'm thinking of commenting out these lines (scrollkeeper-update) for generating the distro package and let the distro take care of scrollkeeper. -- Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From maikel at housenation.nl Mon Sep 15 06:18:57 2008 From: maikel at housenation.nl (=?utf-8?Q?Maikel_Doll=C3=A9?=) Date: Mon, 15 Sep 2008 08:18:57 +0200 (CEST) Subject: [et-mgmt-tools] virt-manager 0.6.0 In-Reply-To: <1362274.81221459231643.JavaMail.root@mail.housenation.nl> Message-ID: <28145797.101221459537304.JavaMail.root@mail.housenation.nl> Hi all, I am new to this list so I do it the right way! :-) I was used to use virt-manager from the Redhat repositories and that worked flawless (I think it was virt-manager 0.5.2), but after a yum update I recieved version 0.5.4 and then I got problems starting virt-manager. I start virt-manager over X11 because my server is in a datacenter and I don't have direct access. After compiling virt-manager 0.6.0 I still have the problem as I had in 0.5.4. Maybe you guys can help me out on this one. OS: Fedora 8 Guest OS: Fedora 9 Error after starten virt-manager: ImportError: cannot import name Storage If you need the full trace let me know but as I can see there is nothing that really matters (but I can be wrong ofc). Thx in advance! Maikel -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Mon Sep 15 10:32:24 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 15 Sep 2008 06:32:24 -0400 Subject: [et-mgmt-tools] virt-manager 0.6.0 In-Reply-To: <28145797.101221459537304.JavaMail.root@mail.housenation.nl> References: <28145797.101221459537304.JavaMail.root@mail.housenation.nl> Message-ID: <48CE39B8.1010707@redhat.com> Maikel Doll? wrote: > Hi all, > > I am new to this list so I do it the right way! :-) > > I was used to use virt-manager from the Redhat repositories and that > worked flawless (I think it was virt-manager 0.5.2), but after a yum > update I recieved version 0.5.4 and then I got problems starting > virt-manager. I start virt-manager over X11 because my server is in a > datacenter and I don't have direct access. > > After compiling virt-manager 0.6.0 I still have the problem as I had > in 0.5.4. Maybe you guys can help me out on this one. > > OS: Fedora 8 > Guest OS: Fedora 9 > > Error after starten virt-manager: > > ImportError: cannot import name Storage > > > If you need the full trace let me know but as I can see there is > nothing that really matters (but I can be wrong ofc). > > Thx in advance! > > Maikel > If you install the latest virtinst package 0.400.0 on the same machine as virt-manager that should fix the problem. Generally virt-manager is tied closely with new virtinst releases as well, so it's a good idea to always install the two together. http://virt-manager.org/download.html Thanks, Cole From levon at movementarian.org Mon Sep 15 21:31:27 2008 From: levon at movementarian.org (John Levon) Date: Mon, 15 Sep 2008 22:31:27 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: remove -t option Message-ID: <20080915213127.GA15066@totally.trollied.org.uk> # HG changeset patch # User john.levon at sun.com # Date 1221514080 -3600 # Node ID 15cdf039c358895c192f92a6746836b00c16bb56 # Parent e069659bf07f752c7b4748f41dcd2beb926459ce virt-convert: remove -t option This never did anything, and is undocumented. Signed-off-by: John Levon diff --git a/virt-convert b/virt-convert --- a/virt-convert +++ b/virt-convert @@ -44,8 +44,6 @@ 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")) opts.add_option("-d", "--debug", action="store_true", dest="debug", help=("Print debugging information")) opts.add_option("-i", "--input-format", action="store", From levon at movementarian.org Tue Sep 16 13:47:21 2008 From: levon at movementarian.org (John Levon) Date: Tue, 16 Sep 2008 14:47:21 +0100 Subject: [et-mgmt-tools] [PATCH] virt-convert: make VMX parser case insensitive Message-ID: <20080916134721.GB17815@totally.trollied.org.uk> # HG changeset patch # User john.levon at sun.com # Date 1221572750 -3600 # Node ID 8ff0e8ca4eb05063bb9c689ef159f4f601dddd7a # Parent 15cdf039c358895c192f92a6746836b00c16bb56 virt-convert: make VMX parser case insensitive VMWare tools apparently don't care, so neither should we. Some VMX generators don't use the proper case with keys such as 'fileName'. Signed-off-by: John Levon diff --git a/virtconv/parsers/vmx.py b/virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py +++ b/virtconv/parsers/vmx.py @@ -42,13 +42,13 @@ 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": + if key == "virtualdev": + vm.netdevs[inst].driver = value + 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 + vm.netdevs[inst].mac = value def parse_disk_entry(vm, fullkey, value): """ @@ -78,19 +78,17 @@ vm.disks[devid] = diskcfg.disk(bus = bus, type = diskcfg.DISK_TYPE_DISK) - if key == "deviceType": + 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": + 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 - -import re class vmx_parser(formats.parser): """ @@ -147,7 +145,7 @@ for (line_nr, line) in enumerate(lines): try: before_eq, after_eq = line.split("=", 1) - key = before_eq.strip() + key = before_eq.strip().lower() value = after_eq.strip().strip('"') config[key] = value @@ -164,13 +162,13 @@ continue # vmx files often have dross left in path for CD entries - if (disk.path == "auto detect" or + if (disk.path.lower() == "auto detect" or not os.path.exists(disk.path)): vm.disks[devid].path = None - if not config.get("displayName"): + if not config.get("displayname"): raise ValueError("No displayName defined in \"%s\"" % input_file) - vm.name = config.get("displayName") + vm.name = config.get("displayname") vm.memory = config.get("memsize") vm.description = config.get("annotation") From crobinso at redhat.com Tue Sep 16 18:25:04 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 16 Sep 2008 14:25:04 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: make VMX parser case insensitive In-Reply-To: <20080916134721.GB17815@totally.trollied.org.uk> References: <20080916134721.GB17815@totally.trollied.org.uk> Message-ID: <48CFFA00.6050101@redhat.com> John Levon wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1221572750 -3600 > # Node ID 8ff0e8ca4eb05063bb9c689ef159f4f601dddd7a > # Parent 15cdf039c358895c192f92a6746836b00c16bb56 > virt-convert: make VMX parser case insensitive > > VMWare tools apparently don't care, so neither should we. Some VMX > generators don't use the proper case with keys such as 'fileName'. > > Signed-off-by: John Levon > Applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=692e4d0ce7d6 Thanks, Cole From crobinso at redhat.com Tue Sep 16 18:25:35 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 16 Sep 2008 14:25:35 -0400 Subject: [et-mgmt-tools] [PATCH] virt-convert: remove -t option In-Reply-To: <20080915213127.GA15066@totally.trollied.org.uk> References: <20080915213127.GA15066@totally.trollied.org.uk> Message-ID: <48CFFA1F.8020801@redhat.com> John Levon wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1221514080 -3600 > # Node ID 15cdf039c358895c192f92a6746836b00c16bb56 > # Parent e069659bf07f752c7b4748f41dcd2beb926459ce > virt-convert: remove -t option > > This never did anything, and is undocumented. > Applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=e362f5306b26 Thanks, Cole From atodorov at redhat.com Thu Sep 18 07:06:33 2008 From: atodorov at redhat.com (Alexander Todorov) Date: Thu, 18 Sep 2008 10:06:33 +0300 Subject: [et-mgmt-tools] [PATCH] Error in virt-manager man page Message-ID: <48D1FDF9.8020601@redhat.com> Good morning all, there's a small error in the man page for virt-manager. The synopsis says virt-viewer instead of virt-manager. diff -r f33e457579af man/virt-manager.pod --- a/man/virt-manager.pod Tue Sep 16 16:51:43 2008 -0400 +++ b/man/virt-manager.pod Thu Sep 18 09:59:49 2008 +0300 @@ -5,7 +5,7 @@ virt-manager - display the virtual machi =head1 SYNOPSIS -B [OPTIONS] +B [OPTIONS] =head1 DESCRIPTION Thanks, Alexander. From fj0588di at aa.jp.fujitsu.com Fri Sep 19 09:43:37 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Fri, 19 Sep 2008 18:43:37 +0900 Subject: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH] virt-manager calls migration API In-Reply-To: <200809112004.FEC57380.J0G9K96E@aa.jp.fujitsu.com> References: <200809081809.GFC73482.699JGEK0@aa.jp.fujitsu.com> <48C4EF66.9070400@redhat.com> <200809112004.FEC57380.J0G9K96E@aa.jp.fujitsu.com> Message-ID: <200809191843.GCG69223.96J09KGE@aa.jp.fujitsu.com> > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > development happens, > > OK. For this, I tried to hear in et-mgmt-list. > I'm sorry to be pressing, but would you give me a comment on this patch for going on the next step to migrate from virt-manager ? I attached screenshots this patch shows. Thanks, Shigeki Sakamoto. > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > development happens, > > OK. For this, I tried to hear in et-mgmt-list. > > > I sent an e-mail last month with proposals for doing this within libvirt. I put > > up all of the information I have in the libvirt wiki here: > > > > http://wiki.libvirt.org/page/TodoPreMigrationChecks > > Thank you for your information. I see above libvirt wiki and I have a few > idea adding checks within libvirt. These point of view are Guest and Host sanity > in BASIC CHECKS. How about this points ? > > 1)Guest sanity is checking whether already existing or not on the destination. > Otherwise the uniqueness of the domain(UUID, name) are lost. > * I think that it is right to check this in libvirt. How do you think this ? > > 2)Host sanity is checking whether a migration flag is ON at each virtualization. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: HostList.jpg Type: image/jpeg Size: 58821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PopupMenu.jpg Type: image/jpeg Size: 54508 bytes Desc: not available URL: From berrange at redhat.com Fri Sep 19 10:07:27 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 19 Sep 2008 11:07:27 +0100 Subject: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH] virt-manager calls migration API In-Reply-To: <200809191843.GCG69223.96J09KGE@aa.jp.fujitsu.com> References: <200809081809.GFC73482.699JGEK0@aa.jp.fujitsu.com> <48C4EF66.9070400@redhat.com> <200809112004.FEC57380.J0G9K96E@aa.jp.fujitsu.com> <200809191843.GCG69223.96J09KGE@aa.jp.fujitsu.com> Message-ID: <20080919100727.GM18194@redhat.com> On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote: > > > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > > development happens, > > > > OK. For this, I tried to hear in et-mgmt-list. > > > > I'm sorry to be pressing, but would you give me a comment on this patch for > going on the next step to migrate from virt-manager ? > I attached screenshots this patch shows. I think rather than having it popup a new window with a list of hosts to migrate to, you could just have a sub-menu where you choose the destination host directly. eg, right-click | +- Run Pause Shutdown -------- Migrate ----> host1.example.com host2.example.com host3.example.com ...etc... When the user selects one of these hosts, it'd popup a confirmation window, and do the neccessary migration checks, and then allow the admin to confirm to start the migration. > > > I sent an e-mail last month with proposals for doing this within libvirt. I put > > > up all of the information I have in the libvirt wiki here: > > > > > > http://wiki.libvirt.org/page/TodoPreMigrationChecks > > > > Thank you for your information. I see above libvirt wiki and I have a few > > idea adding checks within libvirt. These point of view are Guest and Host sanity > > in BASIC CHECKS. How about this points ? > > > > 1)Guest sanity is checking whether already existing or not on the destination. > > Otherwise the uniqueness of the domain(UUID, name) are lost. > > * I think that it is right to check this in libvirt. How do you think this ? Yes, checking for name/uuid uniqueness has to be done inside libvirt by each hypervisor driver according to their own rules. > > 2)Host sanity is checking whether a migration flag is ON at each virtualization. virt-manager will need to check the kind of things on the TodoPreMigrationChecks wiki page. 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 bperkins at redhat.com Fri Sep 19 23:23:22 2008 From: bperkins at redhat.com (Brandon Perkins) Date: Fri, 19 Sep 2008 19:23:22 -0400 Subject: [et-mgmt-tools] virt-p2v and linux software raid. Message-ID: <48D4346A.8060106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I was in the process of moving a server using virt-p2v this evening, when I came across the issue described at: https://www.redhat.com/archives/et-mgmt-tools/2008-February/msg00037.html https://www.redhat.com/archives/et-mgmt-tools/2008-February/msg00038.html https://www.redhat.com/archives/et-mgmt-tools/2008-February/msg00039.html https://www.redhat.com/archives/et-mgmt-tools/2008-February/msg00040.html I was wondering if there is any progress on getting linux software raid support. I'm not really qualified to help with patches, but I'd be more than happy to test any patches to get this functionality in. It appears I have a similar setup where I have three physical drives, three identical partitions in a software RAID-1 (/boot), three identical partitions for swap, and three identical partitions in a software RAID-5 (/). And of course it bails out because it doesn't understand the software raid type. If there is a bug, or anything I can do to help on this front, please let me know, as this has thrown a bit of a monkey-wrench into a migration plan that I had, but could not test until now. Thanks! Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFI1DRphwQhj8l1t/cRAgNYAKC6tDrhf8geiMo2tl7dBsWAePjhQACZAfJF F7iQ1A64eWV8j6fHGUY3rAI= =IwCs -----END PGP SIGNATURE----- From rdtennent at gmail.com Sat Sep 20 16:48:15 2008 From: rdtennent at gmail.com (Bob Tennent) Date: Sat, 20 Sep 2008 12:48:15 -0400 Subject: [et-mgmt-tools] -parallel supported? Message-ID: <48d5294f.Ult18thKiCcp1dcG%rdtennent@gmail.com> qemu-kvm has a -parallel option for attaching a parallel port to a guest. Does virt-manager support this? I'm running version 0.5.3-2.fc8. Bob T. From agx at sigxcpu.org Mon Sep 22 11:11:23 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Mon, 22 Sep 2008 13:11:23 +0200 Subject: [et-mgmt-tools] [PATCH] virtinst: create scratchdir if it doesn't exisst Message-ID: <20080922111123.GA28868@bogon.ms20.nix> Hi, subject basically says it all. Please apply if you see fit. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: create-scratch-dir.patch Type: text/x-diff Size: 738 bytes Desc: not available URL: From agx at sigxcpu.org Mon Sep 22 11:12:35 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Mon, 22 Sep 2008 13:12:35 +0200 Subject: [et-mgmt-tools] fix scratchdir for non-root users Message-ID: <20080922111235.GB28868@bogon.ms20.nix> Hi, When running as non root we don't have write access to /var/lib/libvirt. Please apply if you see fit, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-scratchdir-for-non-root.patch Type: text/x-diff Size: 773 bytes Desc: not available URL: From crobinso at redhat.com Mon Sep 22 13:31:19 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 22 Sep 2008 09:31:19 -0400 Subject: [et-mgmt-tools] -parallel supported? In-Reply-To: <48d5294f.Ult18thKiCcp1dcG%rdtennent@gmail.com> References: <48d5294f.Ult18thKiCcp1dcG%rdtennent@gmail.com> Message-ID: <48D79E27.2030301@redhat.com> Bob Tennent wrote: > qemu-kvm has a -parallel option for attaching a parallel port to a > guest. Does virt-manager support this? I'm running version 0.5.3-2.fc8. > > Bob T. > virt-manager currently does not have support for adding parallel devices to guests, though this is supported at the libvirt level. So, using virsh, you can add a parallel device to an existing VM. Check out http://libvirt.org/formatdomain.html#elementsConsole for xml examples. There will likely be a 'Add Character Device' wizard in virt-manager down the line, no official timeline yet though. Thanks, Cole From crobinso at redhat.com Mon Sep 22 14:55:03 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 22 Sep 2008 10:55:03 -0400 Subject: [et-mgmt-tools] [PATCH] Error in virt-manager man page In-Reply-To: <48D1FDF9.8020601@redhat.com> References: <48D1FDF9.8020601@redhat.com> Message-ID: <48D7B1C7.2050507@redhat.com> Alexander Todorov wrote: > Good morning all, > there's a small error in the man page for virt-manager. The synopsis says > virt-viewer instead of virt-manager. > Thanks, applied upstream: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=12ebbffb5900 - Cole From crobinso at redhat.com Mon Sep 22 15:08:44 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 22 Sep 2008 11:08:44 -0400 Subject: [et-mgmt-tools] fix scratchdir for non-root users In-Reply-To: <20080922111235.GB28868@bogon.ms20.nix> References: <20080922111235.GB28868@bogon.ms20.nix> Message-ID: <48D7B4FC.5080807@redhat.com> Guido G?nther wrote: > Hi, > When running as non root we don't have write access to /var/lib/libvirt. > Please apply if you see fit, > -- Guido > Patch looks good, though I'd rather use ~/.virtinst as the root rather that ~/.libvirt, since the former is already used for logs and such. Any objections? Thanks, Cole From crobinso at redhat.com Mon Sep 22 15:11:53 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 22 Sep 2008 11:11:53 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst: create scratchdir if it doesn't exisst In-Reply-To: <20080922111123.GA28868@bogon.ms20.nix> References: <20080922111123.GA28868@bogon.ms20.nix> Message-ID: <48D7B5B9.10607@redhat.com> Guido G?nther wrote: > Hi, > subject basically says it all. Please apply if you see fit. > -- Guido > > Applied, thanks: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=c6a767b4d632 - Cole From agx at sigxcpu.org Mon Sep 22 15:23:12 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Mon, 22 Sep 2008 17:23:12 +0200 Subject: [et-mgmt-tools] fix scratchdir for non-root users In-Reply-To: <48D7B4FC.5080807@redhat.com> References: <20080922111235.GB28868@bogon.ms20.nix> <48D7B4FC.5080807@redhat.com> Message-ID: <20080922152312.GA27534@bogon.ms20.nix> On Mon, Sep 22, 2008 at 11:08:44AM -0400, Cole Robinson wrote: > Patch looks good, though I'd rather use ~/.virtinst as the > root rather that ~/.libvirt, since the former is already > used for logs and such. Any objections? No, that's even better. -- Guido From crobinso at redhat.com Mon Sep 22 15:33:42 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 22 Sep 2008 11:33:42 -0400 Subject: [et-mgmt-tools] fix scratchdir for non-root users In-Reply-To: <20080922152312.GA27534@bogon.ms20.nix> References: <20080922111235.GB28868@bogon.ms20.nix> <48D7B4FC.5080807@redhat.com> <20080922152312.GA27534@bogon.ms20.nix> Message-ID: <48D7BAD6.7020303@redhat.com> Guido G?nther wrote: > On Mon, Sep 22, 2008 at 11:08:44AM -0400, Cole Robinson wrote: >> Patch looks good, though I'd rather use ~/.virtinst as the >> root rather that ~/.libvirt, since the former is already >> used for logs and such. Any objections? > No, that's even better. > -- Guido Okay, fixed up patch applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=8f48969778e6 Thanks, Cole From jboggs at redhat.com Mon Sep 22 16:25:42 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 22 Sep 2008 12:25:42 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output Message-ID: <48D7C706.5050607@redhat.com> This will replace the virt-pack command and supplemental Unware.py file and integrate them into virt-convert directly as a module. I'll create a patch to remove the deprecated files once tested by others. Other notes, only supports raw disks, adding in qcow support should be fairly easy, just wanted to get this out the door first. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-convert-vmware-conversion-module-9-22-1207.ptch URL: From agx at sigxcpu.org Mon Sep 22 15:58:51 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Mon, 22 Sep 2008 17:58:51 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: network devices vs qemu:///session Message-ID: <20080922155851.GA27945@bogon.ms20.nix> Hi, I might be completely of track here but isn't the logic virt-manger uses to determine the network devices one can add a bit bogus: Currently it's based on the uid of the user, shouldn't this be based on the connection type instead? Otherwise a user can't add multiple nics to qemu:///system he's otherwise authorized to change in every way. Possible patch attached. Chees, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: network-qemu-session.diff Type: text/x-diff Size: 3265 bytes Desc: not available URL: From berrange at redhat.com Mon Sep 22 16:34:02 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 22 Sep 2008 17:34:02 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: network devices vs qemu:///session In-Reply-To: <20080922155851.GA27945@bogon.ms20.nix> References: <20080922155851.GA27945@bogon.ms20.nix> Message-ID: <20080922163402.GB2661@redhat.com> On Mon, Sep 22, 2008 at 05:58:51PM +0200, Guido G?nther wrote: > Hi, > I might be completely of track here but isn't the logic virt-manger uses > to determine the network devices one can add a bit bogus: > > Currently it's based on the uid of the user, shouldn't this be based on > the connection type instead? Otherwise a user can't add multiple nics to > qemu:///system he's otherwise authorized to change in every way. Yes, that is one of the things that needs clearing up now you can securely connect to qemu:///system and provision as non-root. Ideally we'd expose much more of this in the hypervisor capabilities output, so you wouldn't need to test qemu:///session, but your patch is an improvement none the less. 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 Sep 22 21:16:16 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 22 Sep 2008 17:16:16 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48D7C706.5050607@redhat.com> References: <48D7C706.5050607@redhat.com> Message-ID: <48D80B20.7010609@redhat.com> Joey Boggs wrote: > This will replace the virt-pack command and supplemental Unware.py file > and integrate them into virt-convert directly as a module. > > I'll create a patch to remove the deprecated files once tested by others. > > Other notes, only supports raw disks, adding in qcow support should be > fairly easy, just wanted to get this out the door first. > > > diff -r f87154697807 virt-convert > --- a/virt-convert Thu Sep 18 16:44:30 2008 -0400 > +++ b/virt-convert Mon Sep 22 12:17:55 2008 -0400 > @@ -49,8 +49,7 @@ > opts.add_option("-i", "--input-format", action="store", > 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'")) > + dest="output_format", help=("Output format, e.g. 'virt-image / vmware'")) Since we are using 'vmx' as an input format type, we should probably also use it as the name of the output format (not 'vmware'). > 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", > @@ -89,6 +88,10 @@ > else: > options.output_file = args[1] > options.output_dir = os.path.dirname(os.path.realpath(args[1])) > + > + if not options.output_format: > + opts.error("Output format must be specified") > + sys.exit(1) > > if options.output_format not in formats.formats(): > opts.error(("Unknown output format \"%s\"" % options.output_format)) > @@ -170,7 +173,6 @@ > logging.error("Couldn't import file \"%s\": %s" % > (options.input_file, e)) > sys.exit(1) > - > if options.paravirt: > vmdef.type = vmcfg.VM_TYPE_PV > else: > @@ -214,11 +216,13 @@ > try: > for d in vmdef.disks.values(): > format = options.disk_format > - > # VMDK disks on Solaris converted to vdisk by default > if (d.format == diskcfg.DISK_FORMAT_VMDK and > not format and vmcfg.host() == "SunOS"): > format = "vdisk" > + > + if options.output_format == "vmware": > + format = "vmdk" > s/vmware/vmx/ > if not format: > format = "raw" > diff -r f87154697807 virtconv/diskcfg.py > --- a/virtconv/diskcfg.py Thu Sep 18 16:44:30 2008 -0400 > +++ b/virtconv/diskcfg.py Mon Sep 22 12:17:55 2008 -0400 > @@ -181,7 +181,7 @@ > absout = os.path.join(outdir, relout) > > if not (out_format == DISK_FORMAT_VDISK or > - out_format == DISK_FORMAT_RAW): > + out_format == DISK_FORMAT_RAW or out_format == DISK_FORMAT_VMDK): > raise NotImplementedError("Cannot convert to disk format %s" % > output_format) > > diff -r f87154697807 virtconv/parsers/virtimage.py > --- a/virtconv/parsers/virtimage.py Thu Sep 18 16:44:30 2008 -0400 > +++ b/virtconv/parsers/virtimage.py Mon Sep 22 12:17:55 2008 -0400 > @@ -21,10 +21,13 @@ > import virtconv.formats as formats > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > +import virtconv.netdevcfg as netdevcfg > import virtinst.FullVirtGuest as fv > - > +import virtinst.ImageParser > +from optparse import OptionParser, OptionValueError Doesn't look like optparse imports need to be here. > from xml.sax.saxutils import escape > from string import ascii_letters > +import os > import re > > pv_boot_template = """ > @@ -183,16 +186,23 @@ > """ > name = "virt-image" > suffix = ".virt-image.xml" > - can_import = False > + can_import = True > can_export = True > - can_identify = False > + can_identify = True > > @staticmethod > def identify_file(input_file): > """ > Return True if the given file is of this format. > + Not able to guarantee is on the top line rather than a blankline > """ > - raise NotImplementedError > + infile = open(input_file, "r") > + line = infile > + for line in line.readlines(): > + if re.match(r'^', line): > + return True > + infile.close() > + > Hmm, might it be better just to do ImageParser.parse_file here, and if it throws an exception, log it and return False? > @staticmethod > def import_file(input_file): > @@ -200,7 +210,44 @@ > Import a configuration file. Raises if the file couldn't be > opened, or parsing otherwise failed. > """ > - raise NotImplementedError > + vm = vmcfg.vm() > + config = virtinst.ImageParser.parse_file(input_file) > + domain = config.domain > + boot = domain.boots[0] > + > + if not config.name: > + raise ValueError("No Name defined in \"%s\"" % input_file) > + vm.name = config.name > + vm.memory = config.domain.memory > + if config.descr: > + vm.description = config.descr > + vm.nr_vcpus = config.domain.vcpu > + > + bus="scsi" > + diskinst = 0 > + devid = (bus, diskinst) > + > + for d in boot.drives: > + disk = d.disk > + if disk.format == "raw": > + disk.format = diskcfg.DISK_FORMAT_RAW > + else: > + raise ValueError("%s is not a supported disk format" % disk.format) > + > + vm.disks[devid] = diskcfg.disk(bus = bus, > + type = diskcfg.DISK_TYPE_DISK) > + vm.disks[devid].format = disk.format > + vm.disks[devid].path = disk.file > + diskinst = diskinst + 1 > + > + nics = domain.interface > + nicinst = 0 > + while nicinst < nics: > + vm.netdevs[nicinst] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) > + nicinst = nicinst + 1 > + """ Eventually need to add support for mac addresses if given""" > + vm.validate() > + return vm > Looks fine. > @staticmethod > def export_file(vm, output_file): > diff -r f87154697807 virtconv/parsers/vmx.py > --- a/virtconv/parsers/vmx.py Thu Sep 18 16:44:30 2008 -0400 > +++ b/virtconv/parsers/vmx.py Mon Sep 22 12:17:55 2008 -0400 > @@ -22,7 +22,8 @@ > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > import virtconv.netdevcfg as netdevcfg > - > +import time > +import sys > import re > import os > > @@ -97,10 +98,10 @@ > resource being http://sanbarrow.com/vmx.html > """ > > - name = "vmx" > + name = "vmware" Drop this change, it would break passing 'vmx' as the input format which is current behavior. > suffix = ".vmx" > can_import = True > - can_export = False > + can_export = True > can_identify = True > > @staticmethod > @@ -160,7 +161,7 @@ > 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.lower() == "auto detect" or > not os.path.exists(disk.path)): > @@ -188,6 +189,142 @@ > exception on failure to write the output file. > """ > > - raise NotImplementedError > + _VMX_MAIN_TEMPLATE = """#!/usr/bin/vmplayer > + > +# Generated %(now)s by %(progname)s > +# http://virt-manager.et.redhat.com/ > + > +# This is a Workstation 5 or 5.5 config file > +# It can be used with Player > +config.version = "8" > +virtualHW.version = "4" > + > +# Selected operating system for your virtual machine > +guestOS = "other" > + > +# displayName is your own name for the virtual machine > +displayName = "%(/image/name)s" > + > +# These fields are free text description fields > +annotation = "%(/image/description)s" > +guestinfo.vmware.product.long = "%(/image/label)s" > +guestinfo.vmware.product.url = "http://virt-manager.et.redhat.com/" > +guestinfo.vmware.product.class = "virtual machine" > + > +# Number of virtual CPUs. Your virtual machine will not > +# work if this number is higher than the number of your physical CPUs > +numvcpus = "%(/image/devices/vcpu)s" > + > +# Memory size and other memory settings > +memsize = "%(/image/devices/memory)d" > +MemAllowAutoScaleDown = "FALSE" > +MemTrimRate = "-1" > + > +# Unique ID for the virtual machine will be created > +uuid.action = "create" > + > +## For appliances where tools are installed already, this should really > +## be false, but we don't have that ionfo in the metadata > +# Remind to install VMware Tools > +# This setting has no effect in VMware Player > +tools.remindInstall = "TRUE" > + > +# Startup hints interfers with automatic startup of a virtual machine > +# This setting has no effect in VMware Player > +hints.hideAll = "TRUE" > + > +# Enable time synchronization between computer > +# and virtual machine > +tools.syncTime = "TRUE" > + > +# First serial port, physical COM1 is not available > +serial0.present = "FALSE" > + > +# Optional second serial port, physical COM2 is not available > +serial1.present = "FALSE" > + > +# First parallell port, physical LPT1 is not available > +parallel0.present = "FALSE" > + > +# Logging > +# This config activates logging, and keeps last log > +logging = "TRUE" > +log.fileName = "%(/image/name)s.log" > +log.append = "TRUE" > +log.keepOld = "3" > + > +# These settings decides interaction between your > +# computer and the virtual machine > +isolation.tools.hgfs.disable = "FALSE" > +isolation.tools.dnd.disable = "FALSE" > +isolation.tools.copy.enable = "TRUE" > +isolation.tools.paste.enabled = "TRUE" > + > +# Settings for physical floppy drive > +floppy0.present = "FALSE" > +""" > + > + > + > + _VMX_ETHERNET_TEMPLATE = """ > +ethernet%(dev)s.present = "TRUE" > +ethernet%(dev)s.connectionType = "nat" > +ethernet%(dev)s.addressType = "generated" > +ethernet%(dev)s.generatedAddressOffset = "0" > +ethernet%(dev)s.autoDetect = "TRUE" > +""" > + > + _VMX_IDE_TEMPLATE = """ > +# IDE disk > +ide%(dev)s.present = "TRUE" > +ide%(dev)s.fileName = "%(disk_filename)s" > +ide%(dev)s.mode = "persistent" > +ide%(dev)s.startConnected = "TRUE" > +ide%(dev)s.writeThrough = "TRUE" > +""" I'd prefer if these were moved out of the class definition. For example, how they are listed in the virt-image parser file. > + """ Cleanup spaces and multiple lines""" > + vm.description = vm.description.strip() > + vm.description = vm.description.replace("\n","|") > + vmx_out_template = [] > + vmx_dict = { > + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), > + "progname": os.path.basename(sys.argv[0]), > + "/image/name": vm.name, > + "/image/description": vm.description or "None", > + "/image/label": vm.name, > + "/image/devices/vcpu" : vm.nr_vcpus, > + "/image/devices/memory": long(vm.memory)/1024 > + } > + vmx_out = _VMX_MAIN_TEMPLATE % vmx_dict > + vmx_out_template.append(vmx_out) > + > + disk_out_template = [] > + diskcount = 0 > + for disk in vm.disks: > + ide_count = 0 > + dev = "%d:%d" % (ide_count / 2, ide_count % 2) > + disk_dict = { > + "dev": dev, > + "disk_filename" : vm.disks[disk].path > + } > + disk_out = _VMX_IDE_TEMPLATE % disk_dict > + disk_out_template.append(disk_out) > + diskcount = diskcount + 1 > + > + eth_out_template = [] > + if len(vm.netdevs): > + for devnum in vm.netdevs: > + eth_dict = { > + "dev" : devnum > + } > + eth_out = _VMX_ETHERNET_TEMPLATE % eth_dict > + eth_out_template.append(eth_out) > + > + outfile = open(output_file, "w") > + outfile.writelines(vmx_out_template) > + outfile.writelines(disk_out_template) > + outfile.writelines(eth_out_template) > + outfile.close() > + > Now, I'm pretty ignorant of how vmx files work, but wasn't virt-pack writing separate descriptor files for each disk? The above just seems to lump them in the same file, is that fine? Also, can you rediff the patch against latest upstream? I made some small changes to the virtconv stuff that will collide with a couple sections of this patch, nothing major though. Thanks, Cole From rdtennent at gmail.com Mon Sep 22 21:57:15 2008 From: rdtennent at gmail.com (Bob Tennent) Date: Mon, 22 Sep 2008 17:57:15 -0400 Subject: [et-mgmt-tools] -parallel supported? Message-ID: <48d814bb.mR6+9/A0pJWI35mk%rdtennent@gmail.com> >|> qemu-kvm has a -parallel option for attaching a parallel port to a >|> guest. Does virt-manager support this? I'm running version >|> 0.5.3-2.fc8. >| >|virt-manager currently does not have support for adding >|parallel devices to guests, though this is supported at >|the libvirt level. So, using virsh, you can add a parallel >|device to an existing VM. Check out >|http://libvirt.org/formatdomain.html#elementsConsole for >|xml examples. Thanks. I added to the section of the relevant file in /etc/libvirt/qemu. The parallel "hardware" shows up in virt-manager, but with - as the source path; running the domain yields Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 531, in run_domain vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 380, in startup self.vm.create() File "/usr/lib/python2.5/site-packages/libvirt.py", line 262, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error Timed out while reading console startup output Same result if I use . If I remove the parallel "hardware" in the virt-manager, the guest starts up OK. I'm now running libvirt-0.4.5-2.fc8 virt-manager-0.6.0-1.fc8 on the host. Bob T. From atodorov at redhat.com Tue Sep 23 07:38:53 2008 From: atodorov at redhat.com (Alexander Todorov) Date: Tue, 23 Sep 2008 10:38:53 +0300 Subject: [et-mgmt-tools] What are Xen CDROM limits? Message-ID: <48D89D0D.1080008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, I need to be able to attach multiple ISO images to a Xen DomU (hvm) at the same time. Using the UI of virt-manager I was able to attach 3 ISO files as IDE CDROM devices. The 4th failed. IIRC VMWare is capable of more. Is 3 the limit and if yes why? Is this limit higher with KVM or other virtualization technology? Thanks, Alexander. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFI2J0Mhmd3WOiFct4RCqgMAJwOZHX5DK300imLgYGySgMjOwubyQCgii7W QlfuzPqBIf7YSK8yVc/9sI0= =wj// -----END PGP SIGNATURE----- From berrange at redhat.com Tue Sep 23 08:24:47 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 23 Sep 2008 09:24:47 +0100 Subject: [et-mgmt-tools] -parallel supported? In-Reply-To: <48d814bb.mR6+9/A0pJWI35mk%rdtennent@gmail.com> References: <48d814bb.mR6+9/A0pJWI35mk%rdtennent@gmail.com> Message-ID: <20080923082447.GC10681@redhat.com> On Mon, Sep 22, 2008 at 05:57:15PM -0400, Bob Tennent wrote: > >|> qemu-kvm has a -parallel option for attaching a parallel port to a > >|> guest. Does virt-manager support this? I'm running version > >|> 0.5.3-2.fc8. > >| > >|virt-manager currently does not have support for adding > >|parallel devices to guests, though this is supported at > >|the libvirt level. So, using virsh, you can add a parallel > >|device to an existing VM. Check out > >|http://libvirt.org/formatdomain.html#elementsConsole for > >|xml examples. > > Thanks. I added > > > > > > > to the section of the relevant file in /etc/libvirt/qemu. The > parallel "hardware" shows up in virt-manager, but with - as the source > path; running the domain yields > libvirtError: internal error Timed out while reading console startup > output > > Same result if I use . If I remove the > parallel "hardware" in the virt-manager, the guest starts up OK. Your XML syntax is wrong. You specified a 'pty' but then gave it a real path which doesn't make sense. You want type='dev' instead, and the element is redundant - that's an output only element at this time. So, eg 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 Sep 23 08:53:33 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 23 Sep 2008 09:53:33 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48D80B20.7010609@redhat.com> References: <48D7C706.5050607@redhat.com> <48D80B20.7010609@redhat.com> Message-ID: <20080923085333.GF10681@redhat.com> On Mon, Sep 22, 2008 at 05:16:16PM -0400, Cole Robinson wrote: > Joey Boggs wrote: > > This will replace the virt-pack command and supplemental Unware.py file > > and integrate them into virt-convert directly as a module. > > > > I'll create a patch to remove the deprecated files once tested by others. > > > > Other notes, only supports raw disks, adding in qcow support should be > > fairly easy, just wanted to get this out the door first. > > > > > > > diff -r f87154697807 virt-convert > > --- a/virt-convert Thu Sep 18 16:44:30 2008 -0400 > > +++ b/virt-convert Mon Sep 22 12:17:55 2008 -0400 > > @@ -49,8 +49,7 @@ > > opts.add_option("-i", "--input-format", action="store", > > 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'")) > > + dest="output_format", help=("Output format, e.g. 'virt-image / vmware'")) > > Since we are using 'vmx' as an input format type, we > should probably also use it as the name of the output > format (not 'vmware'). Yes that's a good idea - you never know if vmware will introduce a new non-vmx format, so using 'vmx' makes it clearer which we're talking about. 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 Tue Sep 23 13:46:41 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 23 Sep 2008 09:46:41 -0400 Subject: [et-mgmt-tools] What are Xen CDROM limits? In-Reply-To: <48D89D0D.1080008@redhat.com> References: <48D89D0D.1080008@redhat.com> Message-ID: <48D8F341.9080807@redhat.com> Alexander Todorov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi all, > I need to be able to attach multiple ISO images to a Xen DomU (hvm) at the same > time. Using the UI of virt-manager I was able to attach 3 ISO files as IDE CDROM > devices. The 4th failed. IIRC VMWare is capable of more. > > Is 3 the limit and if yes why? Is this limit higher with KVM or other > virtualization technology? > Xen uses a forked qemu for HVM device emulation. At least on RHEL, the version of qemu they are roughly using only allows attaching IDE disks, which is limited to four max. Newer qemu (and kvm by extension) allow attaching scsi disks and cdroms, which support a much larger number of devices. This is available in F9 and later. There is support in libvirt for adding scsi cdroms, though the option isn't listed in virt-manager yet. Hope that helps, Cole From rdtennent at gmail.com Tue Sep 23 14:55:58 2008 From: rdtennent at gmail.com (Bob Tennent) Date: Tue, 23 Sep 2008 10:55:58 -0400 Subject: [et-mgmt-tools] -parallel supported? Message-ID: <48d9037e.i/0lVbVwt4qc6/cp%rdtennent@gmail.com> >|> >|Check out >|> >|http://libvirt.org/formatdomain.html#elementsConsole for >|> >|xml examples. >|> >|> I added >|> >|> >|> >|> >|> >|> >|> to the section of the relevant file in /etc/libvirt/qemu. The >|> parallel "hardware" shows up in virt-manager, but with - as the source >|> path; running the domain yields >| >|> libvirtError: internal error Timed out while reading console startup >|> output >|> >|> Same result if I use . If I remove the >|> parallel "hardware" in the virt-manager, the guest starts up OK. >| >|Your XML syntax is wrong. You specified a 'pty' but then gave it a >|real path which doesn't make sense. You want type='dev' instead, >|and the element is redundant - that's an output only >|element at this time. So, eg >| >| >| >| >| The example syntax at the libvirt.org site I was directed to is so that should be corrected if it's "wrong". Bob T. From jboggs at redhat.com Tue Sep 23 16:09:12 2008 From: jboggs at redhat.com (Joseph Boggs) Date: Tue, 23 Sep 2008 12:09:12 -0400 (EDT) Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <1316019860.3000441222186146474.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> virt-pack was creating a wrapper file for each disk rather than converting it. If we were to convert an image once and then try to reconvert that image to another format it will fail based on that wrapper file not being the actual disk. We can write an exception to handle this. It works perfectly in vmware to redirect it to the raw file with the appropriate properties but conflicts with qemu-img for now. It was more of a way to package multiple configurations using the same disk image file. Rediffed against current changeset 600 and conflicts resolved with the vmware to vmx changes reverted. Cole Robinson wrote: > Joey Boggs wrote: > >> This will replace the virt-pack command and supplemental Unware.py file >> and integrate them into virt-convert directly as a module. >> >> I'll create a patch to remove the deprecated files once tested by others. >> >> Other notes, only supports raw disks, adding in qcow support should be >> fairly easy, just wanted to get this out the door first. >> >> >> > > >> diff -r f87154697807 virt-convert >> --- a/virt-convert Thu Sep 18 16:44:30 2008 -0400 >> +++ b/virt-convert Mon Sep 22 12:17:55 2008 -0400 >> @@ -49,8 +49,7 @@ >> opts.add_option("-i", "--input-format", action="store", >> 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'")) >> + dest="output_format", help=("Output format, e.g. 'virt-image / vmware'")) >> > > Since we are using 'vmx' as an input format type, we > should probably also use it as the name of the output > format (not 'vmware'). > > >> 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", >> @@ -89,6 +88,10 @@ >> else: >> options.output_file = args[1] >> options.output_dir = os.path.dirname(os.path.realpath(args[1])) >> + >> + if not options.output_format: >> + opts.error("Output format must be specified") >> + sys.exit(1) >> >> if options.output_format not in formats.formats(): >> opts.error(("Unknown output format \"%s\"" % options.output_format)) >> @@ -170,7 +173,6 @@ >> logging.error("Couldn't import file \"%s\": %s" % >> (options.input_file, e)) >> sys.exit(1) >> - >> if options.paravirt: >> vmdef.type = vmcfg.VM_TYPE_PV >> else: >> @@ -214,11 +216,13 @@ >> try: >> for d in vmdef.disks.values(): >> format = options.disk_format >> - >> # VMDK disks on Solaris converted to vdisk by default >> if (d.format == diskcfg.DISK_FORMAT_VMDK and >> not format and vmcfg.host() == "SunOS"): >> format = "vdisk" >> + >> + if options.output_format == "vmware": >> + format = "vmdk" >> >> > > s/vmware/vmx/ > > >> if not format: >> format = "raw" >> diff -r f87154697807 virtconv/diskcfg.py >> --- a/virtconv/diskcfg.py Thu Sep 18 16:44:30 2008 -0400 >> +++ b/virtconv/diskcfg.py Mon Sep 22 12:17:55 2008 -0400 >> @@ -181,7 +181,7 @@ >> absout = os.path.join(outdir, relout) >> >> if not (out_format == DISK_FORMAT_VDISK or >> - out_format == DISK_FORMAT_RAW): >> + out_format == DISK_FORMAT_RAW or out_format == DISK_FORMAT_VMDK): >> raise NotImplementedError("Cannot convert to disk format %s" % >> output_format) >> >> diff -r f87154697807 virtconv/parsers/virtimage.py >> --- a/virtconv/parsers/virtimage.py Thu Sep 18 16:44:30 2008 -0400 >> +++ b/virtconv/parsers/virtimage.py Mon Sep 22 12:17:55 2008 -0400 >> @@ -21,10 +21,13 @@ >> import virtconv.formats as formats >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> +import virtconv.netdevcfg as netdevcfg >> import virtinst.FullVirtGuest as fv >> - >> +import virtinst.ImageParser >> +from optparse import OptionParser, OptionValueError >> > > Doesn't look like optparse imports need to be here. > > >> from xml.sax.saxutils import escape >> from string import ascii_letters >> +import os >> import re >> >> pv_boot_template = """ >> @@ -183,16 +186,23 @@ >> """ >> name = "virt-image" >> suffix = ".virt-image.xml" >> - can_import = False >> + can_import = True >> can_export = True >> - can_identify = False >> + can_identify = True >> >> @staticmethod >> def identify_file(input_file): >> """ >> Return True if the given file is of this format. >> + Not able to guarantee is on the top line rather than a blankline >> """ >> - raise NotImplementedError >> + infile = open(input_file, "r") >> + line = infile >> + for line in line.readlines(): >> + if re.match(r'^', line): >> + return True >> + infile.close() >> + >> >> > > Hmm, might it be better just to do ImageParser.parse_file here, > and if it throws an exception, log it and return False? > > >> @staticmethod >> def import_file(input_file): >> @@ -200,7 +210,44 @@ >> Import a configuration file. Raises if the file couldn't be >> opened, or parsing otherwise failed. >> """ >> - raise NotImplementedError >> + vm = vmcfg.vm() >> + config = virtinst.ImageParser.parse_file(input_file) >> + domain = config.domain >> + boot = domain.boots[0] >> + >> + if not config.name: >> + raise ValueError("No Name defined in \"%s\"" % input_file) >> + vm.name = config.name >> + vm.memory = config.domain.memory >> + if config.descr: >> + vm.description = config.descr >> + vm.nr_vcpus = config.domain.vcpu >> + >> + bus="scsi" >> + diskinst = 0 >> + devid = (bus, diskinst) >> + >> + for d in boot.drives: >> + disk = d.disk >> + if disk.format == "raw": >> + disk.format = diskcfg.DISK_FORMAT_RAW >> + else: >> + raise ValueError("%s is not a supported disk format" % disk.format) >> + >> + vm.disks[devid] = diskcfg.disk(bus = bus, >> + type = diskcfg.DISK_TYPE_DISK) >> + vm.disks[devid].format = disk.format >> + vm.disks[devid].path = disk.file >> + diskinst = diskinst + 1 >> + >> + nics = domain.interface >> + nicinst = 0 >> + while nicinst < nics: >> + vm.netdevs[nicinst] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) >> + nicinst = nicinst + 1 >> + """ Eventually need to add support for mac addresses if given""" >> + vm.validate() >> + return vm >> >> > > Looks fine. > > >> @staticmethod >> def export_file(vm, output_file): >> diff -r f87154697807 virtconv/parsers/vmx.py >> --- a/virtconv/parsers/vmx.py Thu Sep 18 16:44:30 2008 -0400 >> +++ b/virtconv/parsers/vmx.py Mon Sep 22 12:17:55 2008 -0400 >> @@ -22,7 +22,8 @@ >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> import virtconv.netdevcfg as netdevcfg >> - >> +import time >> +import sys >> import re >> import os >> >> @@ -97,10 +98,10 @@ >> resource being http://sanbarrow.com/vmx.html >> """ >> >> - name = "vmx" >> + name = "vmware" >> > > Drop this change, it would break passing 'vmx' as the input > format which is current behavior. > > >> suffix = ".vmx" >> can_import = True >> - can_export = False >> + can_export = True >> can_identify = True >> >> @staticmethod >> @@ -160,7 +161,7 @@ >> 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.lower() == "auto detect" or >> not os.path.exists(disk.path)): >> @@ -188,6 +189,142 @@ >> exception on failure to write the output file. >> """ >> >> - raise NotImplementedError >> + _VMX_MAIN_TEMPLATE = """#!/usr/bin/vmplayer >> + >> +# Generated %(now)s by %(progname)s >> +# http://virt-manager.et.redhat.com/ >> + >> +# This is a Workstation 5 or 5.5 config file >> +# It can be used with Player >> +config.version = "8" >> +virtualHW.version = "4" >> + >> +# Selected operating system for your virtual machine >> +guestOS = "other" >> + >> +# displayName is your own name for the virtual machine >> +displayName = "%(/image/name)s" >> + >> +# These fields are free text description fields >> +annotation = "%(/image/description)s" >> +guestinfo.vmware.product.long = "%(/image/label)s" >> +guestinfo.vmware.product.url = "http://virt-manager.et.redhat.com/" >> +guestinfo.vmware.product.class = "virtual machine" >> + >> +# Number of virtual CPUs. Your virtual machine will not >> +# work if this number is higher than the number of your physical CPUs >> +numvcpus = "%(/image/devices/vcpu)s" >> + >> +# Memory size and other memory settings >> +memsize = "%(/image/devices/memory)d" >> +MemAllowAutoScaleDown = "FALSE" >> +MemTrimRate = "-1" >> + >> +# Unique ID for the virtual machine will be created >> +uuid.action = "create" >> + >> +## For appliances where tools are installed already, this should really >> +## be false, but we don't have that ionfo in the metadata >> +# Remind to install VMware Tools >> +# This setting has no effect in VMware Player >> +tools.remindInstall = "TRUE" >> + >> +# Startup hints interfers with automatic startup of a virtual machine >> +# This setting has no effect in VMware Player >> +hints.hideAll = "TRUE" >> + >> +# Enable time synchronization between computer >> +# and virtual machine >> +tools.syncTime = "TRUE" >> + >> +# First serial port, physical COM1 is not available >> +serial0.present = "FALSE" >> + >> +# Optional second serial port, physical COM2 is not available >> +serial1.present = "FALSE" >> + >> +# First parallell port, physical LPT1 is not available >> +parallel0.present = "FALSE" >> + >> +# Logging >> +# This config activates logging, and keeps last log >> +logging = "TRUE" >> +log.fileName = "%(/image/name)s.log" >> +log.append = "TRUE" >> +log.keepOld = "3" >> + >> +# These settings decides interaction between your >> +# computer and the virtual machine >> +isolation.tools.hgfs.disable = "FALSE" >> +isolation.tools.dnd.disable = "FALSE" >> +isolation.tools.copy.enable = "TRUE" >> +isolation.tools.paste.enabled = "TRUE" >> + >> +# Settings for physical floppy drive >> +floppy0.present = "FALSE" >> +""" >> + >> + >> + >> + _VMX_ETHERNET_TEMPLATE = """ >> +ethernet%(dev)s.present = "TRUE" >> +ethernet%(dev)s.connectionType = "nat" >> +ethernet%(dev)s.addressType = "generated" >> +ethernet%(dev)s.generatedAddressOffset = "0" >> +ethernet%(dev)s.autoDetect = "TRUE" >> +""" >> + >> + _VMX_IDE_TEMPLATE = """ >> +# IDE disk >> +ide%(dev)s.present = "TRUE" >> +ide%(dev)s.fileName = "%(disk_filename)s" >> +ide%(dev)s.mode = "persistent" >> +ide%(dev)s.startConnected = "TRUE" >> +ide%(dev)s.writeThrough = "TRUE" >> +""" >> > > I'd prefer if these were moved out of the class definition. For > example, how they are listed in the virt-image parser file. > > >> + """ Cleanup spaces and multiple lines""" >> + vm.description = vm.description.strip() >> + vm.description = vm.description.replace("\n","|") >> + vmx_out_template = [] >> + vmx_dict = { >> + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), >> + "progname": os.path.basename(sys.argv[0]), >> + "/image/name": vm.name, >> + "/image/description": vm.description or "None", >> + "/image/label": vm.name, >> + "/image/devices/vcpu" : vm.nr_vcpus, >> + "/image/devices/memory": long(vm.memory)/1024 >> + } >> + vmx_out = _VMX_MAIN_TEMPLATE % vmx_dict >> + vmx_out_template.append(vmx_out) >> + >> + disk_out_template = [] >> + diskcount = 0 >> + for disk in vm.disks: >> + ide_count = 0 >> + dev = "%d:%d" % (ide_count / 2, ide_count % 2) >> + disk_dict = { >> + "dev": dev, >> + "disk_filename" : vm.disks[disk].path >> + } >> + disk_out = _VMX_IDE_TEMPLATE % disk_dict >> + disk_out_template.append(disk_out) >> + diskcount = diskcount + 1 >> + >> + eth_out_template = [] >> + if len(vm.netdevs): >> + for devnum in vm.netdevs: >> + eth_dict = { >> + "dev" : devnum >> + } >> + eth_out = _VMX_ETHERNET_TEMPLATE % eth_dict >> + eth_out_template.append(eth_out) >> + >> + outfile = open(output_file, "w") >> + outfile.writelines(vmx_out_template) >> + outfile.writelines(disk_out_template) >> + outfile.writelines(eth_out_template) >> + outfile.close() >> + >> >> > > Now, I'm pretty ignorant of how vmx files work, but > wasn't virt-pack writing separate descriptor files > for each disk? The above just seems to lump them > in the same file, is that fine? > > Also, can you rediff the patch against latest upstream? > I made some small changes to the virtconv stuff that > will collide with a couple sections of this patch, > nothing major though. > > Thanks, > Cole > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-vmware-conversion-module-9-23-1153.patch Type: text/x-patch Size: 11836 bytes Desc: not available URL: From jboggs at redhat.com Wed Sep 24 18:00:35 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 24 Sep 2008 14:00:35 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst adding in disk signature support Message-ID: <48DA8043.8070007@redhat.com> This will add in disk signature support for ISV's and others folks that wish to verify the disk has not been altered prior to running virt-image. Supports md5 and sha1signatures. Sample image.xml attached -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-image-disk-signature-check-9-24-1356.patch Type: text/x-patch Size: 3672 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.xml Type: text/xml Size: 1337 bytes Desc: not available URL: From crobinso at redhat.com Wed Sep 24 18:46:37 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 24 Sep 2008 14:46:37 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst adding in disk signature support In-Reply-To: <48DA8043.8070007@redhat.com> References: <48DA8043.8070007@redhat.com> Message-ID: <48DA8B0D.8040703@redhat.com> Joey Boggs wrote: > This will add in disk signature support for ISV's and others folks that > wish to verify the disk has not been altered prior to running > virt-image. Supports md5 and sha1signatures. > > Sample image.xml attached > For the sample xml it would be nice to see an md5 example as well. > iff -r 58a909b4f71c doc/image.rng > --- a/doc/image.rng Mon Sep 22 11:32:11 2008 -0400 > +++ b/doc/image.rng Wed Sep 24 13:56:34 2008 -0400 > @@ -197,6 +197,14 @@ > > > > + > + > + > + sha1 Need to add for md5 as well. > + > + > + > + > > > > diff -r 58a909b4f71c virt-image > --- a/virt-image Mon Sep 22 11:32:11 2008 -0400 > +++ b/virt-image Wed Sep 24 13:56:34 2008 -0400 > @@ -97,6 +97,8 @@ > help=_("Number of vcpus to configure for your guest")) > parser.add_option("", "--check-cpu", action="store_true", dest="check_cpu", > help=_("Check that vcpus do not exceed physical CPUs and warn if they do.")) > + parser.add_option("", "--checksum-ignore", action="store_true", dest="checksum_ignore", > + help=_("Ignore unmatching checksum values for disk signatures.")) > > # network options > parser.add_option("-m", "--mac", type="string", > @@ -188,6 +190,10 @@ > # now let's get some of the common questions out of the way > get_name(options.name, image.name, guest) > get_memory(options.memory, image.domain.memory, guest) > + > + if not options.checksum_ignore: > + cli.check_disk_signature(image,guest) > + > cli.get_uuid(options.uuid, guest) > get_vcpus(options.vcpus, image.domain.vcpu, options.check_cpu, > guest, conn) > diff -r 58a909b4f71c virtinst/ImageParser.py > --- a/virtinst/ImageParser.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtinst/ImageParser.py Wed Sep 24 13:56:34 2008 -0400 > @@ -213,7 +213,8 @@ > self.format = xpathString(node, "@format", Disk.FORMAT_RAW) > self.size = xpathString(node, "@size") > self.use = xpathString(node, "@use", Disk.USE_SYSTEM) > - > + self.checksum = xpathString(node, "checksum") > + self.checksumtype = xpathString(node, "checksum/@type") > formats = [Disk.FORMAT_RAW, Disk.FORMAT_QCOW, Disk.FORMAT_QCOW2, Disk.FORMAT_VMDK, Disk.FORMAT_ISO] > validate (formats.count(self.format) > 0, > _("The format for disk %s must be one of %s") % > diff -r 58a909b4f71c virtinst/cli.py > --- a/virtinst/cli.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtinst/cli.py Wed Sep 24 13:56:34 2008 -0400 > @@ -352,6 +352,27 @@ > if sound: > guest.sound_devs.append(VirtualAudio(model="es1370")) > > +def check_disk_signature(image,guest): > + i = 0 > + disks = {} > + for k in image.storage.keys(): > + disks[i] = image.storage[k] > + if disks[i].checksumtype == "sha1" or disks[i].checksumtype == "md5" and not None: I'd rather not silently ignore any values that aren't in the white list of supported hash types. Probably at the image parser level, when we set checksumtype, we can raise an exception if the type is not supported. > + checksum = os.popen("/usr/bin/%ssum %s|awk {'print $1'}" % (disks[i].checksumtype,disks[i].file)) > + print _("\n\nChecking disk signature for: %s...") % disks[i].file > + checksum = checksum.read().strip() Looks like python has support for this with default modules ('sha1' and 'md5', prob don't want to use 'hashlib' since it is python 2.5 only). This would definitely be preferable to the above: we won't have to worry about binary naming on other distros, and potentially requiring dependencies, etc. etc. > + if checksum != disks[i].checksum: > + fail(_("Disk signature for %s does not match \n Expected: %s \n Received: %s\n\n To override the signature check add the --checksum-ignore option" % (disks[i].file,disks[i].checksum,checksum))) This line is huuuuuuuge :) You can cut up strings like: _("I am a very long string") as: _("I am a " "very long " "string") In the above case it probably wouldn't hurt to do it with each newline so the look in the code is similar to what the user will see. > + else: > + continue > + i = i + 1 > + else: > + if disks[i].checksumtype is None: > + continue > + else: > + fail(_("\"%s\" is an invalid disk signature type for %s" % (disks[i].checksumtype,disks[i].file))) Just as a nit, rather than escape the double quotes here, use single quotes ('%s') or wrap the whole string like """blah""", rather then mess with escapes. > + return > + > ### Option parsing > def check_before_store(option, opt_str, value, parser): > if len(value) == 0: Thanks, Cole From crobinso at redhat.com Wed Sep 24 18:58:04 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 24 Sep 2008 14:58:04 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: network devices vs qemu:///session In-Reply-To: <20080922155851.GA27945@bogon.ms20.nix> References: <20080922155851.GA27945@bogon.ms20.nix> Message-ID: <48DA8DBC.9080309@redhat.com> Guido G?nther wrote: > Hi, > I might be completely of track here but isn't the logic virt-manger uses > to determine the network devices one can add a bit bogus: > > Currently it's based on the uid of the user, shouldn't this be based on > the connection type instead? Otherwise a user can't add multiple nics to > qemu:///system he's otherwise authorized to change in every way. > > Possible patch attached. > Chees, > -- Guido > Thanks! Committed: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=92b681862b40 - Cole From crobinso at redhat.com Wed Sep 24 19:05:27 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 24 Sep 2008 15:05:27 -0400 Subject: [et-mgmt-tools] -parallel supported? In-Reply-To: <48d9037e.i/0lVbVwt4qc6/cp%rdtennent@gmail.com> References: <48d9037e.i/0lVbVwt4qc6/cp%rdtennent@gmail.com> Message-ID: <48DA8F77.7010305@redhat.com> Bob Tennent wrote: > >|> >|Check out > >|> >|http://libvirt.org/formatdomain.html#elementsConsole for > >|> >|xml examples. > >|> > >|> I added > >|> > >|> > >|> > >|> > >|> > >|> > >|> to the section of the relevant file in /etc/libvirt/qemu. The > >|> parallel "hardware" shows up in virt-manager, but with - as the source > >|> path; running the domain yields > >| > >|> libvirtError: internal error Timed out while reading console startup > >|> output > >|> > >|> Same result if I use . If I remove the > >|> parallel "hardware" in the virt-manager, the guest starts up OK. > >| > >|Your XML syntax is wrong. You specified a 'pty' but then gave it a > >|real path which doesn't make sense. You want type='dev' instead, > >|and the element is redundant - that's an output only > >|element at this time. So, eg > >| > >| > >| > >| > >| > > The example syntax at the libvirt.org site I was directed to is > > > > > > > so that should be corrected if it's "wrong". > > Bob T. > The docs clearly explain that type='pty' is for redirection to a psuedo tty, and type='dev' is for redirection to a physical device. So in that respect, the docs are not "wrong". That quoted piece is just the example of the general syntax. It is not clearly labeled as such, but probably should be. - Cole From jboggs at redhat.com Wed Sep 24 19:15:10 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 24 Sep 2008 15:15:10 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst adding in disk signature support In-Reply-To: <48DA8B0D.8040703@redhat.com> References: <48DA8043.8070007@redhat.com> <48DA8B0D.8040703@redhat.com> Message-ID: <48DA91BE.1000005@redhat.com> Just to make sure, if I move that logic for "either sha1/md5 and not None" into ImageParser right when I pull in the checksum data that would that be sufficient? Working on changing the other items >> + >> + >> + >> + >> >> >> >> diff -r 58a909b4f71c virt-image >> --- a/virt-image Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virt-image Wed Sep 24 13:56:34 2008 -0400 >> @@ -97,6 +97,8 @@ >> help=_("Number of vcpus to configure for your guest")) >> parser.add_option("", "--check-cpu", action="store_true", dest="check_cpu", >> help=_("Check that vcpus do not exceed physical CPUs and warn if they do.")) >> + parser.add_option("", "--checksum-ignore", action="store_true", dest="checksum_ignore", >> + help=_("Ignore unmatching checksum values for disk signatures.")) >> >> # network options >> parser.add_option("-m", "--mac", type="string", >> @@ -188,6 +190,10 @@ >> # now let's get some of the common questions out of the way >> get_name(options.name, image.name, guest) >> get_memory(options.memory, image.domain.memory, guest) >> + >> + if not options.checksum_ignore: >> + cli.check_disk_signature(image,guest) >> + >> cli.get_uuid(options.uuid, guest) >> get_vcpus(options.vcpus, image.domain.vcpu, options.check_cpu, >> guest, conn) >> diff -r 58a909b4f71c virtinst/ImageParser.py >> --- a/virtinst/ImageParser.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtinst/ImageParser.py Wed Sep 24 13:56:34 2008 -0400 >> @@ -213,7 +213,8 @@ >> self.format = xpathString(node, "@format", Disk.FORMAT_RAW) >> self.size = xpathString(node, "@size") >> self.use = xpathString(node, "@use", Disk.USE_SYSTEM) >> - >> + self.checksum = xpathString(node, "checksum") >> + self.checksumtype = xpathString(node, "checksum/@type") >> formats = [Disk.FORMAT_RAW, Disk.FORMAT_QCOW, Disk.FORMAT_QCOW2, Disk.FORMAT_VMDK, Disk.FORMAT_ISO] >> validate (formats.count(self.format) > 0, >> _("The format for disk %s must be one of %s") % >> diff -r 58a909b4f71c virtinst/cli.py >> --- a/virtinst/cli.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtinst/cli.py Wed Sep 24 13:56:34 2008 -0400 >> @@ -352,6 +352,27 @@ >> if sound: >> guest.sound_devs.append(VirtualAudio(model="es1370")) >> >> +def check_disk_signature(image,guest): >> + i = 0 >> + disks = {} >> + for k in image.storage.keys(): >> + disks[i] = image.storage[k] >> + if disks[i].checksumtype == "sha1" or disks[i].checksumtype == "md5" and not None: >> > > I'd rather not silently ignore any values that aren't in the > white list of supported hash types. Probably at the image > parser level, when we set checksumtype, we can raise an > exception if the type is not supported. > > From crobinso at redhat.com Wed Sep 24 19:39:20 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 24 Sep 2008 15:39:20 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst adding in disk signature support In-Reply-To: <48DA91BE.1000005@redhat.com> References: <48DA8043.8070007@redhat.com> <48DA8B0D.8040703@redhat.com> <48DA91BE.1000005@redhat.com> Message-ID: <48DA9768.7050706@redhat.com> Joey Boggs wrote: > Just to make sure, if I move that logic for "either sha1/md5 and not > None" into ImageParser right when I pull in the checksum data that would > that be sufficient? > Right, that should work. - Cole From crobinso at redhat.com Wed Sep 24 19:41:25 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 24 Sep 2008 15:41:25 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <48DA97E5.3020705@redhat.com> Joseph Boggs wrote: > virt-pack was creating a wrapper file for each disk rather than > converting it. If we were to convert an image once and then try to > reconvert that image to another format it will fail based on that > wrapper file not being the actual disk. We can write an exception to > handle this. It works perfectly in vmware to redirect it to the raw file > with the appropriate properties but conflicts with qemu-img for now. It > was more of a way to package multiple configurations using the same disk > image file. > > Rediffed against current changeset 600 and conflicts resolved with the > vmware to vmx changes reverted. > Thanks. > diff -r 58a909b4f71c virt-convert > --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 > +++ b/virt-convert Tue Sep 23 11:53:19 2008 -0400 > @@ -48,10 +48,9 @@ > 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", help=("Input format, e.g. 'vmx'")) > + dest="input_format", help=("Input format, e.g. 'vmx / virt-image'")) > opts.add_option("-o", "--output-format", action="store", > - dest="output_format", default="virt-image", > - help=("Output format, e.g. 'virt-image'")) > + dest="output_format", help=("Output format, e.g. 'virt-image / vmx'")) > 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", > @@ -211,11 +210,13 @@ > try: > for d in vmdef.disks.values(): > format = options.disk_format > - > # VMDK disks on Solaris converted to vdisk by default > if (d.format == diskcfg.DISK_FORMAT_VMDK and > not format and vmcfg.host() == "SunOS"): > format = "vdisk" > + > + if options.output_format == "vmx": > + format = "vmdk" > Hmm, I'm not sure if this is correct wrt the above code piece. Make this piece an elif with the block above it. Also, does vmx _only_ read vmdk files? If that's not the case, we shouldn't overwrite whatever the specified format may have been, just default to it if none is specified. > if not format: > format = "raw" > diff -r 58a909b4f71c virtconv/diskcfg.py > --- a/virtconv/diskcfg.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/diskcfg.py Tue Sep 23 11:53:19 2008 -0400 > @@ -181,7 +181,7 @@ > absout = os.path.join(outdir, relout) > > if not (out_format == DISK_FORMAT_VDISK or > - out_format == DISK_FORMAT_RAW): > + out_format == DISK_FORMAT_RAW or out_format == DISK_FORMAT_VMDK): > raise NotImplementedError("Cannot convert to disk format %s" % > output_format) > > diff -r 58a909b4f71c virtconv/formats.py > --- a/virtconv/formats.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/formats.py Tue Sep 23 11:53:19 2008 -0400 > @@ -44,6 +44,7 @@ > Import a configuration file. Raises if the file couldn't be > opened, or parsing otherwise failed. > """ > + print "importing file" > raise NotImplementedError > Accidentally left in? :) > @staticmethod > diff -r 58a909b4f71c virtconv/parsers/virtimage.py > --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/virtimage.py Tue Sep 23 11:53:19 2008 -0400 > @@ -21,10 +21,13 @@ > import virtconv.formats as formats > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > +import virtconv.netdevcfg as netdevcfg > import virtinst.FullVirtGuest as fv > - > +import virtinst.ImageParser as ImageParser > +from virtinst.cli import fail > from xml.sax.saxutils import escape > from string import ascii_letters > +import os > import re > > pv_boot_template = """ > @@ -75,6 +78,10 @@ > > > """ > + > +def parse_disk_entry(vm, fullkey, value): > + return > + > Hmm, if this isn't doing anything, it doesn't need to be present. It isn't an explicit part of the API. > def export_os_params(vm): > """ > @@ -183,16 +190,23 @@ > """ > name = "virt-image" > suffix = ".virt-image.xml" > - can_import = False > + can_import = True > can_export = True > - can_identify = False > + can_identify = True > > @staticmethod > def identify_file(input_file): > """ > Return True if the given file is of this format. > + Not able to guarantee is on the top line rather than a blankline > """ > - raise NotImplementedError > + infile = open(input_file, "r") > + line = infile > + for line in line.readlines(): > + if re.match(r'^', line): > + return True > + infile.close() > + > No thoughts on my previous comment? : 'Hmm, might it be better just to do ImageParser.parse_file here, and if it throws an exception, log it and return False?' I think that's the way to go. > @staticmethod > def import_file(input_file): > @@ -200,7 +214,48 @@ > Import a configuration file. Raises if the file couldn't be > opened, or parsing otherwise failed. > """ > - raise NotImplementedError > + vm = vmcfg.vm() > + try: > + config = ImageParser.parse_file(input_file) > + except Exception, e: > + fail("Couldn't import file \"%s\": %s" % (input_file, e)) > + I mentioned in a response to your other patch, but skip the quote escaping, just use single quotes. > + domain = config.domain > + boot = domain.boots[0] > + > + if not config.name: > + raise ValueError("No Name defined in \"%s\"" % input_file) > + vm.name = config.name > + vm.memory = config.domain.memory > + if config.descr: > + vm.description = config.descr > + vm.nr_vcpus = config.domain.vcpu > + > + bus="scsi" > + diskinst = 0 > + devid = (bus, diskinst) > + > + for d in boot.drives: > + disk = d.disk > + if disk.format == "raw": > + disk.format = diskcfg.DISK_FORMAT_RAW > + else: > + raise ValueError("%s is not a supported disk format" % disk.format) > + The 'Disk' class also supports vmdk, which is supported by diskcfg, so you probably want to allow that as well. Also, compare against the Disk class constants, not their values (eg. use FORMAT_RAW and FORMAT_VMDK) > + vm.disks[devid] = diskcfg.disk(bus = bus, > + type = diskcfg.DISK_TYPE_DISK) > + vm.disks[devid].format = disk.format > + vm.disks[devid].path = disk.file > + diskinst = diskinst + 1 > + > + nics = domain.interface > + nicinst = 0 > + while nicinst < nics: > + vm.netdevs[nicinst] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) > + nicinst = nicinst + 1 > + """ Eventually need to add support for mac addresses if given""" > + vm.validate() > + return vm > > @staticmethod > def export_file(vm, output_file): > diff -r 58a909b4f71c virtconv/parsers/vmx.py > --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/vmx.py Tue Sep 23 11:53:19 2008 -0400 > @@ -22,9 +22,105 @@ > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > import virtconv.netdevcfg as netdevcfg > - > +import time > +import sys > import re > import os > + > +_VMX_MAIN_TEMPLATE = """ > +#!/usr/bin/vmplayer > + > +# Generated %(now)s by %(progname)s > +# http://virt-manager.et.redhat.com/ > + > +# This is a Workstation 5 or 5.5 config file > +# It can be used with Player > +config.version = "8" > +virtualHW.version = "4" > + > +# Selected operating system for your virtual machine > +guestOS = "other" > + > +# displayName is your own name for the virtual machine > +displayName = "%(/image/name)s" > + > +# These fields are free text description fields > +annotation = "%(/image/description)s" > +guestinfo.vmware.product.long = "%(/image/label)s" > +guestinfo.vmware.product.url = "http://virt-manager.et.redhat.com/" > +guestinfo.vmware.product.class = "virtual machine" > + > +# Number of virtual CPUs. Your virtual machine will not > +# work if this number is higher than the number of your physical CPUs > +numvcpus = "%(/image/devices/vcpu)s" > + > +# Memory size and other memory settings > +memsize = "%(/image/devices/memory)d" > +MemAllowAutoScaleDown = "FALSE" > +MemTrimRate = "-1" > + > +# Unique ID for the virtual machine will be created > +uuid.action = "create" > + > +## For appliances where tools are installed already, this should really > +## be false, but we don't have that ionfo in the metadata > +# Remind to install VMware Tools > +# This setting has no effect in VMware Player > +tools.remindInstall = "TRUE" > + > +# Startup hints interfers with automatic startup of a virtual machine > +# This setting has no effect in VMware Player > +hints.hideAll = "TRUE" > + > +# Enable time synchronization between computer > +# and virtual machine > +tools.syncTime = "TRUE" > + > +# First serial port, physical COM1 is not available > +serial0.present = "FALSE" > + > +# Optional second serial port, physical COM2 is not available > +serial1.present = "FALSE" > + > +# First parallell port, physical LPT1 is not available > +parallel0.present = "FALSE" > + > +# Logging > +# This config activates logging, and keeps last log > +logging = "TRUE" > +log.fileName = "%(/image/name)s.log" > +log.append = "TRUE" > +log.keepOld = "3" > + > +# These settings decides interaction between your > +# computer and the virtual machine > +isolation.tools.hgfs.disable = "FALSE" > +isolation.tools.dnd.disable = "FALSE" > +isolation.tools.copy.enable = "TRUE" > +isolation.tools.paste.enabled = "TRUE" > + > +# Settings for physical floppy drive > +floppy0.present = "FALSE" > +""" > + > + > + Trim a couple of these lines. > +_VMX_ETHERNET_TEMPLATE = """ > +ethernet%(dev)s.present = "TRUE" > +ethernet%(dev)s.connectionType = "nat" > +ethernet%(dev)s.addressType = "generated" > +ethernet%(dev)s.generatedAddressOffset = "0" > +ethernet%(dev)s.autoDetect = "TRUE" > +""" > + > +_VMX_IDE_TEMPLATE = """ > +# IDE disk > +ide%(dev)s.present = "TRUE" > +ide%(dev)s.fileName = "%(disk_filename)s" > +ide%(dev)s.mode = "persistent" > +ide%(dev)s.startConnected = "TRUE" > +ide%(dev)s.writeThrough = "TRUE" > +""" > > def parse_netdev_entry(vm, fullkey, value): > """ > @@ -70,14 +166,13 @@ > > # 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 > @@ -100,7 +195,7 @@ > name = "vmx" > suffix = ".vmx" > can_import = True > - can_export = False > + can_export = True > can_identify = True > > @staticmethod > @@ -160,7 +255,7 @@ > 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 is None > or disk.path.lower() == "auto detect" or > @@ -180,6 +275,8 @@ > > @staticmethod > def export_file(vm, output_file): > + > + > """ > Export a configuration file. > @vm vm configuration instance Hmm, the 3/4 of the previous changes are all whitespace. Please try to minimize these in the future, they just balloon patch size and generally add nothing of value. > @@ -189,6 +286,56 @@ > exception on failure to write the output file. > """ > > - raise NotImplementedError > + """ Cleanup spaces and multiple lines""" > + vm.description = vm.description.strip() > + vm.description = vm.description.replace("\n","|") > + vmx_out_template = [] > + vmx_dict = { > + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), > + "progname": os.path.basename(sys.argv[0]), > + "/image/name": vm.name, > + "/image/description": vm.description or "None", > + "/image/label": vm.name, > + "/image/devices/vcpu" : vm.nr_vcpus, > + "/image/devices/memory": long(vm.memory)/1024 > + } > + vmx_out = _VMX_MAIN_TEMPLATE % vmx_dict > + vmx_out_template.append(vmx_out) > + > + disk_out_template = [] > + diskcount = 0 > + for disk in vm.disks: > + ide_count = 0 > + dev = "%d:%d" % (ide_count / 2, ide_count % 2) > + disk_dict = { > + "dev": dev, > + "disk_filename" : vm.disks[disk].path > + } > + disk_out = _VMX_IDE_TEMPLATE % disk_dict > + disk_out_template.append(disk_out) > + diskcount = diskcount + 1 > + > + eth_out_template = [] > + if len(vm.netdevs): > + for devnum in vm.netdevs: > + eth_dict = { > + "dev" : devnum > + } > + eth_out = _VMX_ETHERNET_TEMPLATE % eth_dict > + eth_out_template.append(eth_out) > + > + > + > + > + > + > +### write out generated templates, will sequence these better so we can write inline ### > + outfile = open(output_file, "w") > + outfile.writelines(vmx_out_template) > + outfile.writelines(disk_out_template) > + outfile.writelines(eth_out_template) > + outfile.close() > + > + #raise NotImplementedError Hmm, why all the extra newlines and strangely indented comment? Thanks, Cole From rdtennent at gmail.com Wed Sep 24 19:59:31 2008 From: rdtennent at gmail.com (Bob Tennent) Date: Wed, 24 Sep 2008 15:59:31 -0400 Subject: [et-mgmt-tools] -parallel supported? Message-ID: <48da9c23.McWt3MHw34ZAvsDN%rdtennent@gmail.com> >|> >|> I added >|> >|> >|> >|> >|> >|> >|> >|> >|> >|> >|> >|> >|> >|> to the section of the relevant file in >|/etc/libvirt/qemu. The >|> >|> parallel "hardware" shows up in virt-manager, but with - as >|the source >|> >|> path; running the domain yields >|> >| >|> >|> libvirtError: internal error Timed out while reading console >|startup >|> >|> output >|> >|> >|> >|> Same result if I use . If I remove the >|> >|> parallel "hardware" in the virt-manager, the guest starts up OK. >|> >| >|> >|Your XML syntax is wrong. You specified a 'pty' but then gave it a >|> >|real path which doesn't make sense. You want type='dev' instead, >|> >|and the element is redundant - that's an output only >|> >|element at this time. So, eg >|> >| >|> >| >|> >| >|> >| >|> >| >|> >|> The example syntax at the libvirt.org site I was directed to is >|> >|> >|> >|> >|> >|> >|> so that should be corrected if it's "wrong". >|> >| >|The docs clearly explain that type='pty' is for redirection >|to a psuedo tty, and type='dev' is for redirection to a >|physical device. So in that respect, the docs are not >|"wrong". I'd be grateful if you could point me to that documentation. I can't find any reference to the difference between type 'dev' and type 'pty' at the libvirt.org site. In any case, crashing on an incorrect type argument suggests a certain lack of robustness. >|That quoted piece is just the example of the general syntax. >|It is not clearly labeled as such, but probably should be. Your colleague suggested the example "didn't make sense." Whatever "general syntax" might be, shouldn't the example make sense? Bob T. From jboggs at redhat.com Wed Sep 24 20:08:30 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 24 Sep 2008 16:08:30 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48DA97E5.3020705@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> Message-ID: <48DA9E3E.6000304@redhat.com> Got that patch file mixed with another codebase I was playing with, I'll work on getting those changes out, as for the extra whitespace, that was copy/paste from Unware.py I'll clean those up as well and work on the other changes Cole Robinson wrote: > Joseph Boggs wrote: > > >> virt-pack was creating a wrapper file for each disk rather than >> converting it. If we were to convert an image once and then try to >> reconvert that image to another format it will fail based on that >> wrapper file not being the actual disk. We can write an exception to >> handle this. It works perfectly in vmware to redirect it to the raw file >> with the appropriate properties but conflicts with qemu-img for now. It >> was more of a way to package multiple configurations using the same disk >> image file. >> >> Rediffed against current changeset 600 and conflicts resolved with the >> vmware to vmx changes reverted. >> >> > > Thanks. > > >> diff -r 58a909b4f71c virt-convert >> --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virt-convert Tue Sep 23 11:53:19 2008 -0400 >> @@ -48,10 +48,9 @@ >> 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", help=("Input format, e.g. 'vmx'")) >> + dest="input_format", help=("Input format, e.g. 'vmx / virt-image'")) >> opts.add_option("-o", "--output-format", action="store", >> - dest="output_format", default="virt-image", >> - help=("Output format, e.g. 'virt-image'")) >> + dest="output_format", help=("Output format, e.g. 'virt-image / vmx'")) >> 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", >> @@ -211,11 +210,13 @@ >> try: >> for d in vmdef.disks.values(): >> format = options.disk_format >> - >> # VMDK disks on Solaris converted to vdisk by default >> if (d.format == diskcfg.DISK_FORMAT_VMDK and >> not format and vmcfg.host() == "SunOS"): >> format = "vdisk" >> + >> + if options.output_format == "vmx": >> + format = "vmdk" >> >> > > Hmm, I'm not sure if this is correct wrt the above > code piece. Make this piece an elif with the block > above it. > > Also, does vmx _only_ read vmdk files? If that's not > the case, we shouldn't overwrite whatever the specified > format may have been, just default to it if none is > specified. > > > >> if not format: >> format = "raw" >> diff -r 58a909b4f71c virtconv/diskcfg.py >> --- a/virtconv/diskcfg.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/diskcfg.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -181,7 +181,7 @@ >> absout = os.path.join(outdir, relout) >> >> if not (out_format == DISK_FORMAT_VDISK or >> - out_format == DISK_FORMAT_RAW): >> + out_format == DISK_FORMAT_RAW or out_format == DISK_FORMAT_VMDK): >> raise NotImplementedError("Cannot convert to disk format %s" % >> output_format) >> >> diff -r 58a909b4f71c virtconv/formats.py >> --- a/virtconv/formats.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/formats.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -44,6 +44,7 @@ >> Import a configuration file. Raises if the file couldn't be >> opened, or parsing otherwise failed. >> """ >> + print "importing file" >> raise NotImplementedError >> >> > > Accidentally left in? :) > > >> @staticmethod >> diff -r 58a909b4f71c virtconv/parsers/virtimage.py >> --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/parsers/virtimage.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -21,10 +21,13 @@ >> import virtconv.formats as formats >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> +import virtconv.netdevcfg as netdevcfg >> import virtinst.FullVirtGuest as fv >> - >> +import virtinst.ImageParser as ImageParser >> +from virtinst.cli import fail >> from xml.sax.saxutils import escape >> from string import ascii_letters >> +import os >> import re >> >> pv_boot_template = """ >> @@ -75,6 +78,10 @@ >> >> >> """ >> + >> +def parse_disk_entry(vm, fullkey, value): >> + return >> + >> >> > > Hmm, if this isn't doing anything, it doesn't need to be > present. It isn't an explicit part of the API. > > >> def export_os_params(vm): >> """ >> @@ -183,16 +190,23 @@ >> """ >> name = "virt-image" >> suffix = ".virt-image.xml" >> - can_import = False >> + can_import = True >> can_export = True >> - can_identify = False >> + can_identify = True >> >> @staticmethod >> def identify_file(input_file): >> """ >> Return True if the given file is of this format. >> + Not able to guarantee is on the top line rather than a blankline >> """ >> - raise NotImplementedError >> + infile = open(input_file, "r") >> + line = infile >> + for line in line.readlines(): >> + if re.match(r'^', line): >> + return True >> + infile.close() >> + >> >> > > No thoughts on my previous comment? : > > 'Hmm, might it be better just to do ImageParser.parse_file here, > and if it throws an exception, log it and return False?' > > I think that's the way to go. > > >> @staticmethod >> def import_file(input_file): >> @@ -200,7 +214,48 @@ >> Import a configuration file. Raises if the file couldn't be >> opened, or parsing otherwise failed. >> """ >> - raise NotImplementedError >> + vm = vmcfg.vm() >> + try: >> + config = ImageParser.parse_file(input_file) >> + except Exception, e: >> + fail("Couldn't import file \"%s\": %s" % (input_file, e)) >> + >> > > I mentioned in a response to your other patch, but skip > the quote escaping, just use single quotes. > > >> + domain = config.domain >> + boot = domain.boots[0] >> + >> + if not config.name: >> + raise ValueError("No Name defined in \"%s\"" % input_file) >> + vm.name = config.name >> + vm.memory = config.domain.memory >> + if config.descr: >> + vm.description = config.descr >> + vm.nr_vcpus = config.domain.vcpu >> + >> + bus="scsi" >> + diskinst = 0 >> + devid = (bus, diskinst) >> + >> + for d in boot.drives: >> + disk = d.disk >> + if disk.format == "raw": >> + disk.format = diskcfg.DISK_FORMAT_RAW >> + else: >> + raise ValueError("%s is not a supported disk format" % disk.format) >> + >> > > The 'Disk' class also supports vmdk, which is supported > by diskcfg, so you probably want to allow that as well. > Also, compare against the Disk class constants, not > their values (eg. use FORMAT_RAW and FORMAT_VMDK) > > >> + vm.disks[devid] = diskcfg.disk(bus = bus, >> + type = diskcfg.DISK_TYPE_DISK) >> + vm.disks[devid].format = disk.format >> + vm.disks[devid].path = disk.file >> + diskinst = diskinst + 1 >> + >> + nics = domain.interface >> + nicinst = 0 >> + while nicinst < nics: >> + vm.netdevs[nicinst] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) >> + nicinst = nicinst + 1 >> + """ Eventually need to add support for mac addresses if given""" >> + vm.validate() >> + return vm >> >> @staticmethod >> def export_file(vm, output_file): >> diff -r 58a909b4f71c virtconv/parsers/vmx.py >> --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/parsers/vmx.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -22,9 +22,105 @@ >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> import virtconv.netdevcfg as netdevcfg >> - >> +import time >> +import sys >> import re >> import os >> + >> +_VMX_MAIN_TEMPLATE = """ >> +#!/usr/bin/vmplayer >> + >> +# Generated %(now)s by %(progname)s >> +# http://virt-manager.et.redhat.com/ >> + >> +# This is a Workstation 5 or 5.5 config file >> +# It can be used with Player >> +config.version = "8" >> +virtualHW.version = "4" >> + >> +# Selected operating system for your virtual machine >> +guestOS = "other" >> + >> +# displayName is your own name for the virtual machine >> +displayName = "%(/image/name)s" >> + >> +# These fields are free text description fields >> +annotation = "%(/image/description)s" >> +guestinfo.vmware.product.long = "%(/image/label)s" >> +guestinfo.vmware.product.url = "http://virt-manager.et.redhat.com/" >> +guestinfo.vmware.product.class = "virtual machine" >> + >> +# Number of virtual CPUs. Your virtual machine will not >> +# work if this number is higher than the number of your physical CPUs >> +numvcpus = "%(/image/devices/vcpu)s" >> + >> +# Memory size and other memory settings >> +memsize = "%(/image/devices/memory)d" >> +MemAllowAutoScaleDown = "FALSE" >> +MemTrimRate = "-1" >> + >> +# Unique ID for the virtual machine will be created >> +uuid.action = "create" >> + >> +## For appliances where tools are installed already, this should really >> +## be false, but we don't have that ionfo in the metadata >> +# Remind to install VMware Tools >> +# This setting has no effect in VMware Player >> +tools.remindInstall = "TRUE" >> + >> +# Startup hints interfers with automatic startup of a virtual machine >> +# This setting has no effect in VMware Player >> +hints.hideAll = "TRUE" >> + >> +# Enable time synchronization between computer >> +# and virtual machine >> +tools.syncTime = "TRUE" >> + >> +# First serial port, physical COM1 is not available >> +serial0.present = "FALSE" >> + >> +# Optional second serial port, physical COM2 is not available >> +serial1.present = "FALSE" >> + >> +# First parallell port, physical LPT1 is not available >> +parallel0.present = "FALSE" >> + >> +# Logging >> +# This config activates logging, and keeps last log >> +logging = "TRUE" >> +log.fileName = "%(/image/name)s.log" >> +log.append = "TRUE" >> +log.keepOld = "3" >> + >> +# These settings decides interaction between your >> +# computer and the virtual machine >> +isolation.tools.hgfs.disable = "FALSE" >> +isolation.tools.dnd.disable = "FALSE" >> +isolation.tools.copy.enable = "TRUE" >> +isolation.tools.paste.enabled = "TRUE" >> + >> +# Settings for physical floppy drive >> +floppy0.present = "FALSE" >> +""" >> + >> + >> + >> > > Trim a couple of these lines. > > >> +_VMX_ETHERNET_TEMPLATE = """ >> +ethernet%(dev)s.present = "TRUE" >> +ethernet%(dev)s.connectionType = "nat" >> +ethernet%(dev)s.addressType = "generated" >> +ethernet%(dev)s.generatedAddressOffset = "0" >> +ethernet%(dev)s.autoDetect = "TRUE" >> +""" >> + >> +_VMX_IDE_TEMPLATE = """ >> +# IDE disk >> +ide%(dev)s.present = "TRUE" >> +ide%(dev)s.fileName = "%(disk_filename)s" >> +ide%(dev)s.mode = "persistent" >> +ide%(dev)s.startConnected = "TRUE" >> +ide%(dev)s.writeThrough = "TRUE" >> +""" >> >> def parse_netdev_entry(vm, fullkey, value): >> """ >> @@ -70,14 +166,13 @@ >> >> # 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 >> @@ -100,7 +195,7 @@ >> name = "vmx" >> suffix = ".vmx" >> can_import = True >> - can_export = False >> + can_export = True >> can_identify = True >> >> @staticmethod >> @@ -160,7 +255,7 @@ >> 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 is None >> or disk.path.lower() == "auto detect" or >> @@ -180,6 +275,8 @@ >> >> @staticmethod >> def export_file(vm, output_file): >> + >> + >> """ >> Export a configuration file. >> @vm vm configuration instance >> > > Hmm, the 3/4 of the previous changes are all whitespace. > Please try to minimize these in the future, they just > balloon patch size and generally add nothing of value. > > > >> @@ -189,6 +286,56 @@ >> exception on failure to write the output file. >> """ >> >> - raise NotImplementedError >> + """ Cleanup spaces and multiple lines""" >> + vm.description = vm.description.strip() >> + vm.description = vm.description.replace("\n","|") >> + vmx_out_template = [] >> + vmx_dict = { >> + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), >> + "progname": os.path.basename(sys.argv[0]), >> + "/image/name": vm.name, >> + "/image/description": vm.description or "None", >> + "/image/label": vm.name, >> + "/image/devices/vcpu" : vm.nr_vcpus, >> + "/image/devices/memory": long(vm.memory)/1024 >> + } >> + vmx_out = _VMX_MAIN_TEMPLATE % vmx_dict >> + vmx_out_template.append(vmx_out) >> + >> + disk_out_template = [] >> + diskcount = 0 >> + for disk in vm.disks: >> + ide_count = 0 >> + dev = "%d:%d" % (ide_count / 2, ide_count % 2) >> + disk_dict = { >> + "dev": dev, >> + "disk_filename" : vm.disks[disk].path >> + } >> + disk_out = _VMX_IDE_TEMPLATE % disk_dict >> + disk_out_template.append(disk_out) >> + diskcount = diskcount + 1 >> + >> + eth_out_template = [] >> + if len(vm.netdevs): >> + for devnum in vm.netdevs: >> + eth_dict = { >> + "dev" : devnum >> + } >> + eth_out = _VMX_ETHERNET_TEMPLATE % eth_dict >> + eth_out_template.append(eth_out) >> + >> + >> + >> + >> + >> + >> +### write out generated templates, will sequence these better so we can write inline ### >> + outfile = open(output_file, "w") >> + outfile.writelines(vmx_out_template) >> + outfile.writelines(disk_out_template) >> + outfile.writelines(eth_out_template) >> + outfile.close() >> + >> + #raise NotImplementedError >> > > Hmm, why all the extra newlines and strangely indented comment? > > Thanks, > Cole > From crobinso at redhat.com Wed Sep 24 20:11:56 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 24 Sep 2008 16:11:56 -0400 Subject: [et-mgmt-tools] -parallel supported? In-Reply-To: <48da9c23.McWt3MHw34ZAvsDN%rdtennent@gmail.com> References: <48da9c23.McWt3MHw34ZAvsDN%rdtennent@gmail.com> Message-ID: <48DA9F0C.4070809@redhat.com> Bob Tennent wrote: > >|> >|> I added > >|> >|> > >|> >|> > >|> >|> > >|> >|> > >|> >|> > >|> >|> > >|> >|> to the section of the relevant file in > >|/etc/libvirt/qemu. The > >|> >|> parallel "hardware" shows up in virt-manager, but with - as > >|the source > >|> >|> path; running the domain yields > >|> >| > >|> >|> libvirtError: internal error Timed out while reading console > >|startup > >|> >|> output > >|> >|> > >|> >|> Same result if I use . If I remove the > >|> >|> parallel "hardware" in the virt-manager, the guest starts up OK. > >|> >| > >|> >|Your XML syntax is wrong. You specified a 'pty' but then gave it a > >|> >|real path which doesn't make sense. You want type='dev' instead, > >|> >|and the element is redundant - that's an output only > >|> >|element at this time. So, eg > >|> >| > >|> >| > >|> >| > >|> >| > >|> >| > >|> > >|> The example syntax at the libvirt.org site I was directed to is > >|> > >|> > >|> > >|> > >|> > >|> > >|> so that should be corrected if it's "wrong". > >|> > >| > >|The docs clearly explain that type='pty' is for redirection > >|to a psuedo tty, and type='dev' is for redirection to a > >|physical device. So in that respect, the docs are not > >|"wrong". > > I'd be grateful if you could point me to that documentation. I can't > find any reference to the difference between type 'dev' and type 'pty' > at the libvirt.org site. > >From the original link I posted: http://libvirt.org/formatdomain.html#elementsConsole Scroll down and it enumerates all the different serial/parallel/ console types (starting with 'Domain Logfile'). Fifth one listed is 'Psuedo TTY', the type demonstrated in the syntax example. The one following that is 'Host device proxy', which was the type you are looking for. > In any case, crashing on an incorrect type argument suggests a Well, nothing should be crashing :) What version of libvirt are you using? I'll try to reproduce. > >|That quoted piece is just the example of the general syntax. > >|It is not clearly labeled as such, but probably should be. > > Your colleague suggested the example "didn't make sense." Whatever > "general syntax" might be, shouldn't the example make sense? > That given example does make sense, just not for your intended case of redirecting parallel output to a physical host device. - Cole From jboggs at redhat.com Wed Sep 24 20:37:50 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 24 Sep 2008 16:37:50 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst adding in disk signature support In-Reply-To: <48DA9768.7050706@redhat.com> References: <48DA8043.8070007@redhat.com> <48DA8B0D.8040703@redhat.com> <48DA91BE.1000005@redhat.com> <48DA9768.7050706@redhat.com> Message-ID: <48DAA51E.4040001@redhat.com> new patch, should have everything corrected below - md5 option in image.rng - broke up long lines - new image.xml example w/ md5 - using builtin python sha/md5 support Cole Robinson wrote: > Joey Boggs wrote: > >> Just to make sure, if I move that logic for "either sha1/md5 and not >> None" into ImageParser right when I pull in the checksum data that would >> that be sufficient? >> >> > > Right, that should work. > > - Cole > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-image-disk-signature-check-9-24-1634.patch Type: text/x-patch Size: 4440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.xml Type: text/xml Size: 1336 bytes Desc: not available URL: From rdtennent at gmail.com Wed Sep 24 21:37:49 2008 From: rdtennent at gmail.com (Bob Tennent) Date: Wed, 24 Sep 2008 17:37:49 -0400 Subject: [et-mgmt-tools] -parallel supported? Message-ID: <48dab32d.tjEg0Etp0KQQUr5Q%rdtennent@gmail.com> Thanks for the documentation reference. >|> In any case, crashing on an incorrect type argument suggests a >| >|Well, nothing should be crashing :) What version of libvirt are >|you using? I'll try to reproduce. https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00061.html |>I added |> |> |> |> |> |> |>to the section of the relevant file in /etc/libvirt/qemu. The |>parallel "hardware" shows up in virt-manager, but with - as the source |>path; running the domain yields |> |> Traceback (most recent call last): |> File "/usr/share/virt-manager/virtManager/engine.py", line 531, |> in run_domain |> vm.startup() |> File "/usr/share/virt-manager/virtManager/domain.py", line 380, |> in startup |> self.vm.create() |> File "/usr/lib/python2.5/site-packages/libvirt.py", line 262, |> in create |> if ret == -1: raise libvirtError ('virDomainCreate() failed', |> dom=self) |> libvirtError: internal error Timed out while reading console startup |> output |> |>Same result if I use . If I remove the |>parallel "hardware" in the virt-manager, the guest starts up OK. |> |>I'm now running |> |>libvirt-0.4.5-2.fc8 |>virt-manager-0.6.0-1.fc8 |> |>on the host. Bob T. From lfarkas at lfarkas.org Thu Sep 25 09:14:57 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Thu, 25 Sep 2008 11:14:57 +0200 Subject: [et-mgmt-tools] virt-manager-0.6.0-1 can't run on rhel/centos-5 Message-ID: <48DB5691.5070508@lfarkas.org> hi, it seems virt-manager-0.6.0-1 can't run on rhel/centos-5, cause: ------------------------------------- Traceback (most recent call last): File "/usr/share/virt-manager/virt-manager.py", line 346, in ? main() File "/usr/share/virt-manager/virt-manager.py", line 287, in main from virtManager.engine import vmmEngine File "/usr/share/virt-manager/virtManager/engine.py", line 31, in ? from virtManager.connection import vmmConnection File "/usr/share/virt-manager/virtManager/connection.py", line 36, in ? from virtManager.domain import vmmDomain File "/usr/share/virt-manager/virtManager/domain.py", line 669 finally: ^ SyntaxError: invalid syntax ------------------------------------- is it planed to work with python-2.4 or not? -- Levente "Si vis pacem para bellum!" From agx at sigxcpu.org Thu Sep 25 10:50:12 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 25 Sep 2008 12:50:12 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: network devices vs qemu:///session In-Reply-To: <20080922155851.GA27945@bogon.ms20.nix> References: <20080922155851.GA27945@bogon.ms20.nix> Message-ID: <20080925105012.GA6491@bogon.ms20.nix> Hi, the attached patch is a follow up. It replaces comparisions to qemu:///session with is_qemu_session - just cosmetics so we have all the logic in one place. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: qemu_session.diff Type: text/x-diff Size: 2092 bytes Desc: not available URL: From agx at sigxcpu.org Thu Sep 25 10:54:24 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 25 Sep 2008 12:54:24 +0200 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation Message-ID: <20080925105424.GB6491@bogon.ms20.nix> Hi, currently we don't check if a network is already running, when trying to create a new machine in virt-manager. Attached patch starts the network if it's not running instead of throwing an exception at the user, adresses a Debian bug [1]. Cheers, -- Guido [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499867 -------------- next part -------------- A non-text attachment was scrubbed... Name: start_net.diff Type: text/x-diff Size: 1013 bytes Desc: not available URL: From crobinso at redhat.com Thu Sep 25 11:31:31 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 25 Sep 2008 07:31:31 -0400 Subject: [et-mgmt-tools] virt-manager-0.6.0-1 can't run on rhel/centos-5 In-Reply-To: <48DB5691.5070508@lfarkas.org> References: <48DB5691.5070508@lfarkas.org> Message-ID: <48DB7693.1050500@redhat.com> Farkas Levente wrote: > hi, > it seems virt-manager-0.6.0-1 can't run on rhel/centos-5, cause: > ------------------------------------- > Traceback (most recent call last): > File "/usr/share/virt-manager/virt-manager.py", line 346, in ? > main() > File "/usr/share/virt-manager/virt-manager.py", line 287, in main > from virtManager.engine import vmmEngine > File "/usr/share/virt-manager/virtManager/engine.py", line 31, in ? > from virtManager.connection import vmmConnection > File "/usr/share/virt-manager/virtManager/connection.py", line 36, in ? > from virtManager.domain import vmmDomain > File "/usr/share/virt-manager/virtManager/domain.py", line 669 > finally: > ^ > SyntaxError: invalid syntax > ------------------------------------- > is it planed to work with python-2.4 or not? > > That was an oversight that has since been fixed upstream: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=a8cafeaa92a6 Thanks, Cole From levon at movementarian.org Thu Sep 25 14:39:50 2008 From: levon at movementarian.org (John Levon) Date: Thu, 25 Sep 2008 15:39:50 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <20080923085333.GF10681@redhat.com> References: <48D7C706.5050607@redhat.com> <48D80B20.7010609@redhat.com> <20080923085333.GF10681@redhat.com> Message-ID: <20080925143950.GA26781@totally.trollied.org.uk> On Tue, Sep 23, 2008 at 09:53:33AM +0100, Daniel P. Berrange wrote: > > > diff -r f87154697807 virt-convert > > > --- a/virt-convert Thu Sep 18 16:44:30 2008 -0400 > > > +++ b/virt-convert Mon Sep 22 12:17:55 2008 -0400 > > > @@ -49,8 +49,7 @@ > > > opts.add_option("-i", "--input-format", action="store", > > > 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'")) > > > + dest="output_format", help=("Output format, e.g. 'virt-image / vmware'")) > > > > Since we are using 'vmx' as an input format type, we > > should probably also use it as the name of the output > > format (not 'vmware'). > > Yes that's a good idea - you never know if vmware will introduce a new > non-vmx format, so using 'vmx' makes it clearer which we're talking about. They already have - OVF :) regards john From lfarkas at lfarkas.org Thu Sep 25 15:06:56 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Thu, 25 Sep 2008 17:06:56 +0200 Subject: [et-mgmt-tools] python-virtinst-0.400.0 not working on rhel/centos-5 Message-ID: <48DBA910.3060508@lfarkas.org> hi, python-virtinst-0.400.0 is not working properly on rhel/centos-5. this means if i try to create a new guest in virt-manager then nothing happened after i select the network try (ie. forward not working while back is working). if i simple downgrade to python-virtinst-0.300.3 then it's working again. there is no error message not log nothing on the console simple not happened anything. is it known and/or fixed or not? yours. -- Levente "Si vis pacem para bellum!" From crobinso at redhat.com Thu Sep 25 15:13:40 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 25 Sep 2008 11:13:40 -0400 Subject: [et-mgmt-tools] python-virtinst-0.400.0 not working on rhel/centos-5 In-Reply-To: <48DBA910.3060508@lfarkas.org> References: <48DBA910.3060508@lfarkas.org> Message-ID: <48DBAAA4.2010802@redhat.com> Farkas Levente wrote: > hi, > python-virtinst-0.400.0 is not working properly on rhel/centos-5. this > means if i try to create a new guest in virt-manager then nothing > happened after i select the network try (ie. forward not working while > back is working). if i simple downgrade to python-virtinst-0.300.3 then > it's working again. there is no error message not log nothing on the > console simple not happened anything. > is it known and/or fixed or not? > yours. > Check ~/.virt-manager/virt-manager.log and see if there is a traceback. Thanks, Cole From lfarkas at lfarkas.org Thu Sep 25 15:23:02 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Thu, 25 Sep 2008 17:23:02 +0200 Subject: [et-mgmt-tools] python-virtinst-0.400.0 not working on rhel/centos-5 In-Reply-To: <48DBAAA4.2010802@redhat.com> References: <48DBA910.3060508@lfarkas.org> <48DBAAA4.2010802@redhat.com> Message-ID: <48DBACD6.7020603@lfarkas.org> Cole Robinson wrote: > Farkas Levente wrote: >> hi, >> python-virtinst-0.400.0 is not working properly on rhel/centos-5. this >> means if i try to create a new guest in virt-manager then nothing >> happened after i select the network try (ie. forward not working while >> back is working). if i simple downgrade to python-virtinst-0.300.3 then >> it's working again. there is no error message not log nothing on the >> console simple not happened anything. >> is it known and/or fixed or not? >> yours. >> > > Check ~/.virt-manager/virt-manager.log and see if there is a > traceback. here it's: [Thu, 25 Sep 2008 17:21:44 virt-manager 30972] INFO (virt-manager:128) Application startup [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (engine:74) About to connect to uris ['qemu:///system'] [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (connection:182) Got physical device /org/freedesktop/Hal/devices/net_00_15_17_39_44_96 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (connection:234) Adding net device peth0 00:15:17:39:44:96 /sys/class/net/peth0 bridge eth0 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (connection:216) Checking for VLANs on /sys/class/net/peth0 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (connection:333) Scheduling background open thread for qemu:///system [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (connection:419) Background thread is running [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (connection:447) Background open thread complete, scheduling notify [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (connection:456) Notifying open result [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: fedora-9 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: vcdbs [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: mandrake-10 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: devel-x86-64 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: vcclient [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: vccs [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: devel-i386 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: mandrake-9 [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:408) About to append vm: windows-xp [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:398) VM mandrake-10 started [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:398) VM fedora-9 started [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:398) VM devel-i386 started [Thu, 25 Sep 2008 17:21:44 virt-manager 30973] DEBUG (manager:398) VM devel-x86-64 started [Thu, 25 Sep 2008 17:21:47 virt-manager 30973] DEBUG (Guest:395) No conn passed to Guest, opening URI 'qemu:///system' [Thu, 25 Sep 2008 17:21:52 virt-manager 30973] DEBUG (Guest:395) No conn passed to Guest, opening URI 'qemu:///system' [Thu, 25 Sep 2008 17:21:57 virt-manager 30973] DEBUG (create:835) OS Type: linux [Thu, 25 Sep 2008 17:21:57 virt-manager 30973] DEBUG (create:843) OS Variant: generic26 [Thu, 25 Sep 2008 17:22:00 virt-manager 30973] DEBUG (DistroManager:151) DistroInstaller location is a local file/path: /dev/hda [Thu, 25 Sep 2008 17:22:07 virt-manager 30973] DEBUG (VirtualDisk:389) Using self.path for VirtualDisk. [Thu, 25 Sep 2008 17:22:07 virt-manager 30973] DEBUG (VirtualDisk:399) VirtualDisk storage exists. [Thu, 25 Sep 2008 17:22:07 virt-manager 30973] DEBUG (VirtualDisk:271) Detected storage as type 'block' [Thu, 25 Sep 2008 17:22:10 virt-manager 30973] ERROR (virt-manager:141) Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 291, in forward if(self.validate(notebook.get_current_page()) != True): File "/usr/share/virt-manager/virtManager/create.py", line 1022, in validate if (self._net.countMACaddr(vms) - self._net.countMACaddr(inactive_vm)) > 0: File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 161, in countMACaddr if util.compareMAC(self.macaddr, macaddr) == 0: File "/usr/lib/python2.4/site-packages/virtinst/util.py", line 259, in compareMAC pa = p.split(":") AttributeError: 'NoneType' object has no attribute 'split' None [Thu, 25 Sep 2008 17:22:12 virt-manager 30973] ERROR (virt-manager:141) Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 291, in forward if(self.validate(notebook.get_current_page()) != True): File "/usr/share/virt-manager/virtManager/create.py", line 1022, in validate if (self._net.countMACaddr(vms) - self._net.countMACaddr(inactive_vm)) > 0: File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 161, in countMACaddr if util.compareMAC(self.macaddr, macaddr) == 0: File "/usr/lib/python2.4/site-packages/virtinst/util.py", line 259, in compareMAC pa = p.split(":") AttributeError: 'NoneType' object has no attribute 'split' None -- Levente "Si vis pacem para bellum!" From agx at sigxcpu.org Thu Sep 25 17:27:08 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 25 Sep 2008 19:27:08 +0200 Subject: [et-mgmt-tools] [PATCH]; use virtio for Debian Lenny Message-ID: <20080925172708.GA10101@bogon.ms20.nix> Hi, Lenny's installer supports virtio now, so we should use it. Please apply. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: virtio-lenny.diff Type: text/x-diff Size: 1179 bytes Desc: not available URL: From listen at call-of-ktulu.de Fri Sep 26 09:38:40 2008 From: listen at call-of-ktulu.de (Eric Duda) Date: Fri, 26 Sep 2008 11:38:40 +0200 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system Message-ID: <48DCADA0.4060001@call-of-ktulu.de> Hi all, I yesterday installed virt-manager 0.6.0 and have now problems connecting to libvirtd, I run Ubuntu Hardy, and backported libvirt 0.4.2. With the 0.6.0 release, virt-manager shows only connecting and I got the following error message in virt-manager.log: >[Fr, 26 Sep 2008 11:06:25 virt-manager 5857] ERROR (engine:167) Could >not refresh connection qemu:///system > listStoragePools() takes exactly 3 >arguments (1 given) >Traceback (most recent call last): > File "/usr/local/share/virt-manager/virtManager/engine.py", line 161, >in _tick > self.connections[uri]["connection"].tick() > File "/usr/local/share/virt-manager/virtManager/connection.py", line >878, in tick > newPools, self.pools) = self._update_pools() > File "/usr/local/share/virt-manager/virtManager/connection.py", line >710, in _update_pools > self.storage_capable = virtinst.util.is_storage_capable(self.vmm) > File "/usr/lib/python2.5/site-packages/virtinst/util.py", line 406, >in is_storage_capable > n = conn.listStoragePools() >TypeError: listStoragePools() takes exactly 3 arguments (1 given) I try both, the 0.6.0 tar download and from source repository and installed also latest virtinstall. I downgraded to libvirt 0.4.0 and everythink work, with libvirt from latest source I got the same error. Also virt-install give that error: > File "/usr/lib/python2.5/site-packages/virtinst/VirtualDisk.py", line >135, in __init__ > self.__validate_params() > File "/usr/lib/python2.5/site-packages/virtinst/VirtualDisk.py", line >313, in __validate_params > storage_capable = util.is_storage_capable(self.conn) > File "/usr/lib/python2.5/site-packages/virtinst/util.py", line 406, >in is_storage_capable > n = conn.listStoragePools() >TypeError: listStoragePools() takes exactly 3 arguments (1 given) Any suggestions? From berrange at redhat.com Fri Sep 26 09:42:23 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 26 Sep 2008 10:42:23 +0100 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <48DCADA0.4060001@call-of-ktulu.de> References: <48DCADA0.4060001@call-of-ktulu.de> Message-ID: <20080926094223.GC25341@redhat.com> On Fri, Sep 26, 2008 at 11:38:40AM +0200, Eric Duda wrote: > Hi all, > > I yesterday installed virt-manager 0.6.0 and have now problems > connecting to libvirtd, > I run Ubuntu Hardy, and backported libvirt 0.4.2. > With the 0.6.0 release, virt-manager shows only connecting and I got the > following error message in virt-manager.log: virt-manager 0.6.0 requires libvirt >= 0.4.5, hence why you get these python errors with 0.4.2. 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 listen at call-of-ktulu.de Fri Sep 26 10:47:08 2008 From: listen at call-of-ktulu.de (Eric Duda) Date: Fri, 26 Sep 2008 12:47:08 +0200 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <20080926094223.GC25341@redhat.com> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> Message-ID: <48DCBDAC.7000909@call-of-ktulu.de> Daniel P. Berrange schrieb: > On Fri, Sep 26, 2008 at 11:38:40AM +0200, Eric Duda wrote: >> Hi all, >> >> I yesterday installed virt-manager 0.6.0 and have now problems >> connecting to libvirtd, >> I run Ubuntu Hardy, and backported libvirt 0.4.2. >> With the 0.6.0 release, virt-manager shows only connecting and I got the >> following error message in virt-manager.log: > > virt-manager 0.6.0 requires libvirt >= 0.4.5, hence why you get these > python errors with 0.4.2. > > Regards, > Daniel This is a little bit crazy. I also tried it yesterday with libvirt 0.4.6 from source and build a deb, but got the same error. I installed now again the deb I yesterday build, and it works. Regards, Eric From crobinso at redhat.com Fri Sep 26 13:51:26 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 26 Sep 2008 09:51:26 -0400 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <48DCBDAC.7000909@call-of-ktulu.de> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> Message-ID: <48DCE8DE.8010707@redhat.com> Eric Duda wrote: > Daniel P. Berrange schrieb: >> On Fri, Sep 26, 2008 at 11:38:40AM +0200, Eric Duda wrote: >>> Hi all, >>> >>> I yesterday installed virt-manager 0.6.0 and have now problems >>> connecting to libvirtd, >>> I run Ubuntu Hardy, and backported libvirt 0.4.2. >>> With the 0.6.0 release, virt-manager shows only connecting and I got the >>> following error message in virt-manager.log: >> virt-manager 0.6.0 requires libvirt >= 0.4.5, hence why you get these >> python errors with 0.4.2. >> >> Regards, >> Daniel > > > This is a little bit crazy. > I also tried it yesterday with libvirt 0.4.6 from source and build a > deb, but got the same error. > I installed now again the deb I yesterday build, and it works. > It's easy to forget, but anytime you update libvirt you will need to restart libvirtd. Sounds like that could be the problem. - Cole From agx at sigxcpu.org Fri Sep 26 15:41:02 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 26 Sep 2008 17:41:02 +0200 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <48DCE8DE.8010707@redhat.com> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> <48DCE8DE.8010707@redhat.com> Message-ID: <20080926154102.GA25350@bogon.ms20.nix> On Fri, Sep 26, 2008 at 09:51:26AM -0400, Cole Robinson wrote: > It's easy to forget, but anytime you update libvirt you will > need to restart libvirtd. Sounds like that could be the problem. The Ubuntu packages are based on the Debian ones and I dropped the daemon restart from the postinst so we don't tear down all running machines - so this is likely the problem. Did anybody work on saving enough state to restart libvirtd while keeping the VMs running? If not I might give it a whirl once I find some time. -- Guido P.S.: There are packages of libvirt 0.4.6, virtinst 0.400.0 and virt-manager 0.6.0 in debian/experimental by the way, these should be easily buildable on Ubuntu From berrange at redhat.com Fri Sep 26 15:47:05 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 26 Sep 2008 16:47:05 +0100 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <20080926154102.GA25350@bogon.ms20.nix> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> <48DCE8DE.8010707@redhat.com> <20080926154102.GA25350@bogon.ms20.nix> Message-ID: <20080926154705.GB543@redhat.com> On Fri, Sep 26, 2008 at 05:41:02PM +0200, Guido G?nther wrote: > On Fri, Sep 26, 2008 at 09:51:26AM -0400, Cole Robinson wrote: > > It's easy to forget, but anytime you update libvirt you will > > need to restart libvirtd. Sounds like that could be the problem. > The Ubuntu packages are based on the Debian ones and I dropped the > daemon restart from the postinst so we don't tear down all running > machines - so this is likely the problem. > Did anybody work on saving enough state to restart libvirtd while > keeping the VMs running? If not I might give it a whirl once I find some > time. We've got this problem sorted in the 'lxc' driver and need to apply the same approach to the QEMU driver. The problem was always finding the Pseduo-TTY/PID for the monitor after restart, and associating the live config with it. We've "solved" that in LXC driver by savingt the live XML & PID to /var/run/libvirt/lxc/. It basically needs the same approach to be applied to the QEMU daemons. In addition the DNSmasq deamon needs adapting for simiarl reasons. 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 listen at call-of-ktulu.de Fri Sep 26 18:00:55 2008 From: listen at call-of-ktulu.de (Eric Duda) Date: Fri, 26 Sep 2008 20:00:55 +0200 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <48DCE8DE.8010707@redhat.com> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> <48DCE8DE.8010707@redhat.com> Message-ID: <48DD2357.7020800@call-of-ktulu.de> Cole Robinson schrieb: > Eric Duda wrote: >> Daniel P. Berrange schrieb: >>> On Fri, Sep 26, 2008 at 11:38:40AM +0200, Eric Duda wrote: >>>> Hi all, >>>> >>>> I yesterday installed virt-manager 0.6.0 and have now problems >>>> connecting to libvirtd, >>>> I run Ubuntu Hardy, and backported libvirt 0.4.2. >>>> With the 0.6.0 release, virt-manager shows only connecting and I got the >>>> following error message in virt-manager.log: >>> virt-manager 0.6.0 requires libvirt >= 0.4.5, hence why you get these >>> python errors with 0.4.2. >>> >>> Regards, >>> Daniel >> >> This is a little bit crazy. >> I also tried it yesterday with libvirt 0.4.6 from source and build a >> deb, but got the same error. >> I installed now again the deb I yesterday build, and it works. >> > > It's easy to forget, but anytime you update libvirt you will > need to restart libvirtd. Sounds like that could be the problem. > > - Cole > I did a second install on a different host, and my yesterday problem was, that I removed the libvirt-bin, libvirt0 and because of dependencies python-libvirt before installing the new packages. But without the python-libvirt package I get "ImportError: No module named libvirt" error. After my first mail I did only remove libvirt-bin, and it worked. I have now python-libvirt from Intrepid installed, and it works on both boxes. Regards, Eric From jboggs at redhat.com Fri Sep 26 20:00:57 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 26 Sep 2008 16:00:57 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export Message-ID: <48DD3F79.1010504@redhat.com> Adds disk signatures into virt-convert for virt-image format virtual machines -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-disk-signature-virtimage.patch Type: text/x-patch Size: 923 bytes Desc: not available URL: From crobinso at redhat.com Mon Sep 29 14:13:27 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 29 Sep 2008 10:13:27 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: network devices vs qemu:///session In-Reply-To: <20080925105012.GA6491@bogon.ms20.nix> References: <20080922155851.GA27945@bogon.ms20.nix> <20080925105012.GA6491@bogon.ms20.nix> Message-ID: <48E0E287.5050305@redhat.com> Guido G?nther wrote: > Hi, > the attached patch is a follow up. It replaces comparisions to > qemu:///session with is_qemu_session - just cosmetics so we have all the > logic in one place. > -- Guido > > Thanks, committed: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=47eddabcbe7c - Cole From jboggs at redhat.com Mon Sep 29 11:19:26 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 29 Sep 2008 07:19:26 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48DA97E5.3020705@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> Message-ID: <48E0B9BE.3090704@redhat.com> Made all suggested changes and cleaned up the extra whitespace Cole Robinson wrote: > Joseph Boggs wrote: > > >> virt-pack was creating a wrapper file for each disk rather than >> converting it. If we were to convert an image once and then try to >> reconvert that image to another format it will fail based on that >> wrapper file not being the actual disk. We can write an exception to >> handle this. It works perfectly in vmware to redirect it to the raw file >> with the appropriate properties but conflicts with qemu-img for now. It >> was more of a way to package multiple configurations using the same disk >> image file. >> >> Rediffed against current changeset 600 and conflicts resolved with the >> vmware to vmx changes reverted. >> >> > > Thanks. > > >> diff -r 58a909b4f71c virt-convert >> --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virt-convert Tue Sep 23 11:53:19 2008 -0400 >> @@ -48,10 +48,9 @@ >> 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", help=("Input format, e.g. 'vmx'")) >> + dest="input_format", help=("Input format, e.g. 'vmx / virt-image'")) >> opts.add_option("-o", "--output-format", action="store", >> - dest="output_format", default="virt-image", >> - help=("Output format, e.g. 'virt-image'")) >> + dest="output_format", help=("Output format, e.g. 'virt-image / vmx'")) >> 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", >> @@ -211,11 +210,13 @@ >> try: >> for d in vmdef.disks.values(): >> format = options.disk_format >> - >> # VMDK disks on Solaris converted to vdisk by default >> if (d.format == diskcfg.DISK_FORMAT_VMDK and >> not format and vmcfg.host() == "SunOS"): >> format = "vdisk" >> + >> + if options.output_format == "vmx": >> + format = "vmdk" >> >> > > Hmm, I'm not sure if this is correct wrt the above > code piece. Make this piece an elif with the block > above it. > > Also, does vmx _only_ read vmdk files? If that's not > the case, we shouldn't overwrite whatever the specified > format may have been, just default to it if none is > specified. > > > >> if not format: >> format = "raw" >> diff -r 58a909b4f71c virtconv/diskcfg.py >> --- a/virtconv/diskcfg.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/diskcfg.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -181,7 +181,7 @@ >> absout = os.path.join(outdir, relout) >> >> if not (out_format == DISK_FORMAT_VDISK or >> - out_format == DISK_FORMAT_RAW): >> + out_format == DISK_FORMAT_RAW or out_format == DISK_FORMAT_VMDK): >> raise NotImplementedError("Cannot convert to disk format %s" % >> output_format) >> >> diff -r 58a909b4f71c virtconv/formats.py >> --- a/virtconv/formats.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/formats.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -44,6 +44,7 @@ >> Import a configuration file. Raises if the file couldn't be >> opened, or parsing otherwise failed. >> """ >> + print "importing file" >> raise NotImplementedError >> >> > > Accidentally left in? :) > > >> @staticmethod >> diff -r 58a909b4f71c virtconv/parsers/virtimage.py >> --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/parsers/virtimage.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -21,10 +21,13 @@ >> import virtconv.formats as formats >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> +import virtconv.netdevcfg as netdevcfg >> import virtinst.FullVirtGuest as fv >> - >> +import virtinst.ImageParser as ImageParser >> +from virtinst.cli import fail >> from xml.sax.saxutils import escape >> from string import ascii_letters >> +import os >> import re >> >> pv_boot_template = """ >> @@ -75,6 +78,10 @@ >> >> >> """ >> + >> +def parse_disk_entry(vm, fullkey, value): >> + return >> + >> >> > > Hmm, if this isn't doing anything, it doesn't need to be > present. It isn't an explicit part of the API. > > >> def export_os_params(vm): >> """ >> @@ -183,16 +190,23 @@ >> """ >> name = "virt-image" >> suffix = ".virt-image.xml" >> - can_import = False >> + can_import = True >> can_export = True >> - can_identify = False >> + can_identify = True >> >> @staticmethod >> def identify_file(input_file): >> """ >> Return True if the given file is of this format. >> + Not able to guarantee is on the top line rather than a blankline >> """ >> - raise NotImplementedError >> + infile = open(input_file, "r") >> + line = infile >> + for line in line.readlines(): >> + if re.match(r'^', line): >> + return True >> + infile.close() >> + >> >> > > No thoughts on my previous comment? : > > 'Hmm, might it be better just to do ImageParser.parse_file here, > and if it throws an exception, log it and return False?' > > I think that's the way to go. > > >> @staticmethod >> def import_file(input_file): >> @@ -200,7 +214,48 @@ >> Import a configuration file. Raises if the file couldn't be >> opened, or parsing otherwise failed. >> """ >> - raise NotImplementedError >> + vm = vmcfg.vm() >> + try: >> + config = ImageParser.parse_file(input_file) >> + except Exception, e: >> + fail("Couldn't import file \"%s\": %s" % (input_file, e)) >> + >> > > I mentioned in a response to your other patch, but skip > the quote escaping, just use single quotes. > > >> + domain = config.domain >> + boot = domain.boots[0] >> + >> + if not config.name: >> + raise ValueError("No Name defined in \"%s\"" % input_file) >> + vm.name = config.name >> + vm.memory = config.domain.memory >> + if config.descr: >> + vm.description = config.descr >> + vm.nr_vcpus = config.domain.vcpu >> + >> + bus="scsi" >> + diskinst = 0 >> + devid = (bus, diskinst) >> + >> + for d in boot.drives: >> + disk = d.disk >> + if disk.format == "raw": >> + disk.format = diskcfg.DISK_FORMAT_RAW >> + else: >> + raise ValueError("%s is not a supported disk format" % disk.format) >> + >> > > The 'Disk' class also supports vmdk, which is supported > by diskcfg, so you probably want to allow that as well. > Also, compare against the Disk class constants, not > their values (eg. use FORMAT_RAW and FORMAT_VMDK) > > >> + vm.disks[devid] = diskcfg.disk(bus = bus, >> + type = diskcfg.DISK_TYPE_DISK) >> + vm.disks[devid].format = disk.format >> + vm.disks[devid].path = disk.file >> + diskinst = diskinst + 1 >> + >> + nics = domain.interface >> + nicinst = 0 >> + while nicinst < nics: >> + vm.netdevs[nicinst] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) >> + nicinst = nicinst + 1 >> + """ Eventually need to add support for mac addresses if given""" >> + vm.validate() >> + return vm >> >> @staticmethod >> def export_file(vm, output_file): >> diff -r 58a909b4f71c virtconv/parsers/vmx.py >> --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/parsers/vmx.py Tue Sep 23 11:53:19 2008 -0400 >> @@ -22,9 +22,105 @@ >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> import virtconv.netdevcfg as netdevcfg >> - >> +import time >> +import sys >> import re >> import os >> + >> +_VMX_MAIN_TEMPLATE = """ >> +#!/usr/bin/vmplayer >> + >> +# Generated %(now)s by %(progname)s >> +# http://virt-manager.et.redhat.com/ >> + >> +# This is a Workstation 5 or 5.5 config file >> +# It can be used with Player >> +config.version = "8" >> +virtualHW.version = "4" >> + >> +# Selected operating system for your virtual machine >> +guestOS = "other" >> + >> +# displayName is your own name for the virtual machine >> +displayName = "%(/image/name)s" >> + >> +# These fields are free text description fields >> +annotation = "%(/image/description)s" >> +guestinfo.vmware.product.long = "%(/image/label)s" >> +guestinfo.vmware.product.url = "http://virt-manager.et.redhat.com/" >> +guestinfo.vmware.product.class = "virtual machine" >> + >> +# Number of virtual CPUs. Your virtual machine will not >> +# work if this number is higher than the number of your physical CPUs >> +numvcpus = "%(/image/devices/vcpu)s" >> + >> +# Memory size and other memory settings >> +memsize = "%(/image/devices/memory)d" >> +MemAllowAutoScaleDown = "FALSE" >> +MemTrimRate = "-1" >> + >> +# Unique ID for the virtual machine will be created >> +uuid.action = "create" >> + >> +## For appliances where tools are installed already, this should really >> +## be false, but we don't have that ionfo in the metadata >> +# Remind to install VMware Tools >> +# This setting has no effect in VMware Player >> +tools.remindInstall = "TRUE" >> + >> +# Startup hints interfers with automatic startup of a virtual machine >> +# This setting has no effect in VMware Player >> +hints.hideAll = "TRUE" >> + >> +# Enable time synchronization between computer >> +# and virtual machine >> +tools.syncTime = "TRUE" >> + >> +# First serial port, physical COM1 is not available >> +serial0.present = "FALSE" >> + >> +# Optional second serial port, physical COM2 is not available >> +serial1.present = "FALSE" >> + >> +# First parallell port, physical LPT1 is not available >> +parallel0.present = "FALSE" >> + >> +# Logging >> +# This config activates logging, and keeps last log >> +logging = "TRUE" >> +log.fileName = "%(/image/name)s.log" >> +log.append = "TRUE" >> +log.keepOld = "3" >> + >> +# These settings decides interaction between your >> +# computer and the virtual machine >> +isolation.tools.hgfs.disable = "FALSE" >> +isolation.tools.dnd.disable = "FALSE" >> +isolation.tools.copy.enable = "TRUE" >> +isolation.tools.paste.enabled = "TRUE" >> + >> +# Settings for physical floppy drive >> +floppy0.present = "FALSE" >> +""" >> + >> + >> + >> > > Trim a couple of these lines. > > >> +_VMX_ETHERNET_TEMPLATE = """ >> +ethernet%(dev)s.present = "TRUE" >> +ethernet%(dev)s.connectionType = "nat" >> +ethernet%(dev)s.addressType = "generated" >> +ethernet%(dev)s.generatedAddressOffset = "0" >> +ethernet%(dev)s.autoDetect = "TRUE" >> +""" >> + >> +_VMX_IDE_TEMPLATE = """ >> +# IDE disk >> +ide%(dev)s.present = "TRUE" >> +ide%(dev)s.fileName = "%(disk_filename)s" >> +ide%(dev)s.mode = "persistent" >> +ide%(dev)s.startConnected = "TRUE" >> +ide%(dev)s.writeThrough = "TRUE" >> +""" >> >> def parse_netdev_entry(vm, fullkey, value): >> """ >> @@ -70,14 +166,13 @@ >> >> # 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 >> @@ -100,7 +195,7 @@ >> name = "vmx" >> suffix = ".vmx" >> can_import = True >> - can_export = False >> + can_export = True >> can_identify = True >> >> @staticmethod >> @@ -160,7 +255,7 @@ >> 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 is None >> or disk.path.lower() == "auto detect" or >> @@ -180,6 +275,8 @@ >> >> @staticmethod >> def export_file(vm, output_file): >> + >> + >> """ >> Export a configuration file. >> @vm vm configuration instance >> > > Hmm, the 3/4 of the previous changes are all whitespace. > Please try to minimize these in the future, they just > balloon patch size and generally add nothing of value. > > > >> @@ -189,6 +286,56 @@ >> exception on failure to write the output file. >> """ >> >> - raise NotImplementedError >> + """ Cleanup spaces and multiple lines""" >> + vm.description = vm.description.strip() >> + vm.description = vm.description.replace("\n","|") >> + vmx_out_template = [] >> + vmx_dict = { >> + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), >> + "progname": os.path.basename(sys.argv[0]), >> + "/image/name": vm.name, >> + "/image/description": vm.description or "None", >> + "/image/label": vm.name, >> + "/image/devices/vcpu" : vm.nr_vcpus, >> + "/image/devices/memory": long(vm.memory)/1024 >> + } >> + vmx_out = _VMX_MAIN_TEMPLATE % vmx_dict >> + vmx_out_template.append(vmx_out) >> + >> + disk_out_template = [] >> + diskcount = 0 >> + for disk in vm.disks: >> + ide_count = 0 >> + dev = "%d:%d" % (ide_count / 2, ide_count % 2) >> + disk_dict = { >> + "dev": dev, >> + "disk_filename" : vm.disks[disk].path >> + } >> + disk_out = _VMX_IDE_TEMPLATE % disk_dict >> + disk_out_template.append(disk_out) >> + diskcount = diskcount + 1 >> + >> + eth_out_template = [] >> + if len(vm.netdevs): >> + for devnum in vm.netdevs: >> + eth_dict = { >> + "dev" : devnum >> + } >> + eth_out = _VMX_ETHERNET_TEMPLATE % eth_dict >> + eth_out_template.append(eth_out) >> + >> + >> + >> + >> + >> + >> +### write out generated templates, will sequence these better so we can write inline ### >> + outfile = open(output_file, "w") >> + outfile.writelines(vmx_out_template) >> + outfile.writelines(disk_out_template) >> + outfile.writelines(eth_out_template) >> + outfile.close() >> + >> + #raise NotImplementedError >> > > Hmm, why all the extra newlines and strangely indented comment? > > Thanks, > Cole > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-vmware-conversion-module-9-29-1115.patch Type: text/x-patch Size: 10030 bytes Desc: not available URL: From crobinso at redhat.com Mon Sep 29 15:32:58 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 29 Sep 2008 11:32:58 -0400 Subject: [et-mgmt-tools] [PATCH]; use virtio for Debian Lenny In-Reply-To: <20080925172708.GA10101@bogon.ms20.nix> References: <20080925172708.GA10101@bogon.ms20.nix> Message-ID: <48E0F52A.5070600@redhat.com> Guido G?nther wrote: > Hi, > Lenny's installer supports virtio now, so we should use it. Please > apply. > -- Guido > > Thanks, applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=4597f79e11f0 - Cole From crobinso at redhat.com Mon Sep 29 15:43:03 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 29 Sep 2008 11:43:03 -0400 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation In-Reply-To: <20080925105424.GB6491@bogon.ms20.nix> References: <20080925105424.GB6491@bogon.ms20.nix> Message-ID: <48E0F787.4030708@redhat.com> Guido G?nther wrote: > Hi, > currently we don't check if a network is already running, when trying to > create a new machine in virt-manager. Attached patch starts the network > if it's not running instead of throwing an exception at the user, > adresses a Debian bug [1]. > Cheers, > -- Guido > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499867 > Hmm, I'm not sure if I like this idea. Assumably the network is 'off' for a reason, so if the user doesn't know any better, I'd rather not just turn it on without their potentially knowing. I think the problem here is that it isn't made clear in the drop down whether a virtual network is running or not. If we listed all the nets, but prevented the inactive ones from being selected (kind of like unbridged nics are presented) hopefully the user would get the point that they need to explicitly enable the network to use it. We could even allow selecting the inactive network and then prompt to start it. virt-manager 0.6.0 also allows setting the network's autostart value from the gui, so if the network being inactive was simply an oversight, the user can change it easily. Thanks, Cole From levon at movementarian.org Mon Sep 29 16:27:38 2008 From: levon at movementarian.org (John Levon) Date: Mon, 29 Sep 2008 17:27:38 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E0B9BE.3090704@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> Message-ID: <20080929162738.GA23144@totally.trollied.org.uk> On Mon, Sep 29, 2008 at 07:19:26AM -0400, Joey Boggs wrote: > Made all suggested changes and cleaned up the extra whitespace Cool beans. Some comments: diff -r 58a909b4f71c virt-convert --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 +++ b/virt-convert Mon Sep 29 07:17:09 2008 -0400 @@ -48,10 +48,9 @@ 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", help=("Input format, e.g. 'vmx'")) + dest="input_format", help=("Input format, e.g. 'vmx / virt-image'")) opts.add_option("-o", "--output-format", action="store", - dest="output_format", default="virt-image", - help=("Output format, e.g. 'virt-image'")) + dest="output_format", help=("Output format, e.g. 'virt-image / vmx'")) These are just examples, so why list all the formats? The existing ones should be fine. diff -r 58a909b4f71c virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 +++ b/virtconv/parsers/virtimage.py Mon Sep 29 07:17:09 2008 -0400 @@ -21,10 +21,13 @@ import virtconv.formats as formats import virtconv.vmcfg as vmcfg import virtconv.diskcfg as diskcfg +import virtconv.netdevcfg as netdevcfg import virtinst.FullVirtGuest as fv - +import virtinst.ImageParser as ImageParser +from virtinst.cli import fail Surely this isn't right - this code is "library" code and shouldn't be using fail() ? It should be re-raising the exception... + bus="scsi" Inconsistent spacing. + diskinst = 0 Isn't nr_disks a little more understandable? + devid = (bus, diskinst) This line... + + for d in boot.drives: + disk = d.disk + format = None + if disk.format == ImageParser.Disk.FORMAT_RAW: + format = diskcfg.DISK_FORMAT_RAW + elif format == ImageParser.DISK_FORMAT_VMDK: + format == diskcfg.DISK_FORMAT_VMDK + + if format is None: + raise ValueError("Unable to determine disk format") + ... should surely be here? + vm.disks[devid] = diskcfg.disk(bus = bus, + type = diskcfg.DISK_TYPE_DISK) No CD-ROM handling? + nics = domain.interface + nicinst = 0 nr_nics? :) diff -r 58a909b4f71c virtconv/parsers/vmx.py --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 +++ b/virtconv/parsers/vmx.py Mon Sep 29 07:17:09 2008 -0400 +_VMX_IDE_TEMPLATE = """ +# IDE disk +ide%(dev)s.present = "TRUE" +ide%(dev)s.fileName = "%(disk_filename)s" +ide%(dev)s.mode = "persistent" +ide%(dev)s.startConnected = "TRUE" +ide%(dev)s.writeThrough = "TRUE" +""" Hmm, above we're importing virt-image as SCSI disks, but exporting as IDE - can you clarify this? def parse_netdev_entry(vm, fullkey, value): """ @@ -70,14 +123,13 @@ # 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 I don't see these whitespace changes as improvements... @@ -180,6 +232,8 @@ @staticmethod def export_file(vm, output_file): + + ditto. @@ -188,7 +242,47 @@ Raises ValueError if configuration is not suitable, or another exception on failure to write the output file. """ + vmx_dict = { + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), + "progname": os.path.basename(sys.argv[0]), + "/image/name": vm.name, + "/image/description": vm.description or "None", + "/image/label": vm.name, + "/image/devices/vcpu" : vm.nr_vcpus, + "/image/devices/memory": long(vm.memory)/1024 It's not clear why you used such strange names for the dict's keywords? regards john From jboggs at redhat.com Mon Sep 29 19:28:04 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 29 Sep 2008 15:28:04 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <20080929162738.GA23144@totally.trollied.org.uk> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> Message-ID: <48E12C44.4080304@redhat.com> comments inline, all issues addressed other than vmdk/scsi John Levon wrote: > On Mon, Sep 29, 2008 at 07:19:26AM -0400, Joey Boggs wrote: > > >> Made all suggested changes and cleaned up the extra whitespace >> > > Cool beans. Some comments: > > diff -r 58a909b4f71c virt-convert > --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 > +++ b/virt-convert Mon Sep 29 07:17:09 2008 -0400 > @@ -48,10 +48,9 @@ > 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", help=("Input format, e.g. 'vmx'")) > + dest="input_format", help=("Input format, e.g. 'vmx / virt-image'")) > opts.add_option("-o", "--output-format", action="store", > - dest="output_format", default="virt-image", > - help=("Output format, e.g. 'virt-image'")) > + dest="output_format", help=("Output format, e.g. 'virt-image / vmx'")) > > These are just examples, so why list all the formats? The existing ones > should be fine. > > reverting changes > diff -r 58a909b4f71c virtconv/parsers/virtimage.py > --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/virtimage.py Mon Sep 29 07:17:09 2008 -0400 > @@ -21,10 +21,13 @@ > import virtconv.formats as formats > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > +import virtconv.netdevcfg as netdevcfg > import virtinst.FullVirtGuest as fv > - > +import virtinst.ImageParser as ImageParser > +from virtinst.cli import fail > > Surely this isn't right - this code is "library" code and shouldn't be > using fail() ? It should be re-raising the exception... > Not sure about this, all the other apps in virtinst use fail() now in exceptions even virt-convert, or am I misunderstanding something? > + bus="scsi" > > Inconsistent spacing. > > + diskinst = 0 > > Isn't nr_disks a little more understandable? > > + devid = (bus, diskinst) > > This line... > > + > + for d in boot.drives: > + disk = d.disk > + format = None > + if disk.format == ImageParser.Disk.FORMAT_RAW: > + format = diskcfg.DISK_FORMAT_RAW > + elif format == ImageParser.DISK_FORMAT_VMDK: > + format == diskcfg.DISK_FORMAT_VMDK > + > + if format is None: > + raise ValueError("Unable to determine disk format") > + > > ... should surely be here? > > + vm.disks[devid] = diskcfg.disk(bus = bus, > + type = diskcfg.DISK_TYPE_DISK) > > No CD-ROM handling? > > + nics = domain.interface > + nicinst = 0 > > nr_nics? :) > > > diff -r 58a909b4f71c virtconv/parsers/vmx.py > --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/vmx.py Mon Sep 29 07:17:09 2008 -0400 > +_VMX_IDE_TEMPLATE = """ > +# IDE disk > +ide%(dev)s.present = "TRUE" > +ide%(dev)s.fileName = "%(disk_filename)s" > +ide%(dev)s.mode = "persistent" > +ide%(dev)s.startConnected = "TRUE" > +ide%(dev)s.writeThrough = "TRUE" > +""" > > Hmm, above we're importing virt-image as SCSI disks, but exporting as > IDE - can you clarify this? > We can't export as scsi without qemu-img vmdk scsi support. It's in the wild and in opensuse but not upstream nor Fedora. I'll file a bugzilla on our side for it. When we add more formats the vmx ide exception will impact them if we change how they are imported on the virt-image side. Can't we import them and export them as we have available? Once we get both ide/scsi vmdk support we can identify and export in either needed format. > > def parse_netdev_entry(vm, fullkey, value): > """ > @@ -70,14 +123,13 @@ > > # 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 > > I don't see these whitespace changes as improvements... > > @@ -180,6 +232,8 @@ > > @staticmethod > def export_file(vm, output_file): > + > + > > ditto. > > @@ -188,7 +242,47 @@ > Raises ValueError if configuration is not suitable, or another > exception on failure to write the output file. > """ > + vmx_dict = { > + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), > + "progname": os.path.basename(sys.argv[0]), > + "/image/name": vm.name, > + "/image/description": vm.description or "None", > + "/image/label": vm.name, > + "/image/devices/vcpu" : vm.nr_vcpus, > + "/image/devices/memory": long(vm.memory)/1024 > > It's not clear why you used such strange names for the dict's keywords? > that was copy/past from virt-pack, all updated to new values > regards > john > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-vmware-conversion-module-9-29-1522.patch Type: text/x-patch Size: 8408 bytes Desc: not available URL: From levon at movementarian.org Mon Sep 29 19:43:39 2008 From: levon at movementarian.org (John Levon) Date: Mon, 29 Sep 2008 20:43:39 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E12C44.4080304@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> Message-ID: <20080929194339.GB23144@totally.trollied.org.uk> On Mon, Sep 29, 2008 at 03:28:04PM -0400, Joey Boggs wrote: > >+import virtinst.ImageParser as ImageParser > >+from virtinst.cli import fail > > > >Surely this isn't right - this code is "library" code and shouldn't be > >using fail() ? It should be re-raising the exception... > > Not sure about this, all the other apps in virtinst use fail() now in > exceptions even virt-convert, or am I misunderstanding something? I just grepped and didn't see that. The only fail() usages are in virtinst/cli.py. That's right and proper: library code like that in virtconv/ (or most of virtinst/) should raise exceptions to allow the caller to decide the correct behaviour (if I'm a daemon, I'd better keep running; a GUI, I'd better bring up a dialog box, etc.). > >diff -r 58a909b4f71c virtconv/parsers/vmx.py > >--- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 > >+++ b/virtconv/parsers/vmx.py Mon Sep 29 07:17:09 2008 -0400 > >+_VMX_IDE_TEMPLATE = """ > >+# IDE disk > >+ide%(dev)s.present = "TRUE" > >+ide%(dev)s.fileName = "%(disk_filename)s" > >+ide%(dev)s.mode = "persistent" > >+ide%(dev)s.startConnected = "TRUE" > >+ide%(dev)s.writeThrough = "TRUE" > >+""" > > > >Hmm, above we're importing virt-image as SCSI disks, but exporting as > >IDE - can you clarify this? > > > We can't export as scsi without qemu-img vmdk scsi support. It's in the What does this do? I had no idea that vmdk format was specific to either SCSI or IDE - how does that work? It's a fine restriction, but it seems inconsistent: why are we assuming that virt-image import is using SCSI? Wouldn't a better default be IDE? regards john From jboggs at redhat.com Mon Sep 29 20:16:52 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 29 Sep 2008 16:16:52 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <20080929194339.GB23144@totally.trollied.org.uk> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> Message-ID: <48E137B4.3090404@redhat.com> John Levon wrote: > On Mon, Sep 29, 2008 at 03:28:04PM -0400, Joey Boggs wrote: > > >>> +import virtinst.ImageParser as ImageParser >>> +from virtinst.cli import fail >>> >>> Surely this isn't right - this code is "library" code and shouldn't be >>> using fail() ? It should be re-raising the exception... >>> >> Not sure about this, all the other apps in virtinst use fail() now in >> exceptions even virt-convert, or am I misunderstanding something? >> > > I just grepped and didn't see that. The only fail() usages are in > virtinst/cli.py. That's right and proper: library code like that in > virtconv/ (or most of virtinst/) should raise exceptions to allow the > caller to decide the correct behaviour (if I'm a daemon, I'd better keep > running; a GUI, I'd better bring up a dialog box, etc.). > Cole updated it only a few days ago, here's what I'm seeing at least: grep -r "fail(" virt-convert fail("Couldn't clean up output directory \"%s\": %s" % fail("Couldn't import file \"%s\": %s" % fail("Couldn't import file \"%s\": %s" % (options.input_file, e)) fail("Could not create directory %s: %s" % > >>> diff -r 58a909b4f71c virtconv/parsers/vmx.py >>> --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 >>> +++ b/virtconv/parsers/vmx.py Mon Sep 29 07:17:09 2008 -0400 >>> +_VMX_IDE_TEMPLATE = """ >>> +# IDE disk >>> +ide%(dev)s.present = "TRUE" >>> +ide%(dev)s.fileName = "%(disk_filename)s" >>> +ide%(dev)s.mode = "persistent" >>> +ide%(dev)s.startConnected = "TRUE" >>> +ide%(dev)s.writeThrough = "TRUE" >>> +""" >>> >>> Hmm, above we're importing virt-image as SCSI disks, but exporting as >>> IDE - can you clarify this? >>> >>> >> We can't export as scsi without qemu-img vmdk scsi support. It's in the >> > > What does this do? I had no idea that vmdk format was specific to either > SCSI or IDE - how does that work? > It's specific within the disk image file itself, not just the configuration. I have no specifics other than that, but I believe it is just a block tag on the device, from looking at the qemu-img vmdk scsi support patch > It's a fine restriction, but it seems inconsistent: why are we assuming > that virt-image import is using SCSI? Wouldn't a better default be IDE? > > regards > john > Never caught that, I always assumed the disks were scsi, are they not? virt image isn't specific so I'm guessing we will need someone else to chime in and clarify this. > _______________________________________________ > 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 Mon Sep 29 20:30:24 2008 From: levon at movementarian.org (John Levon) Date: Mon, 29 Sep 2008 21:30:24 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E137B4.3090404@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> Message-ID: <20080929203024.GD23144@totally.trollied.org.uk> On Mon, Sep 29, 2008 at 04:16:52PM -0400, Joey Boggs wrote: > >>Not sure about this, all the other apps in virtinst use fail() now in > >>exceptions even virt-convert, or am I misunderstanding something? > > > >I just grepped and didn't see that. The only fail() usages are in > >virtinst/cli.py. That's right and proper: library code like that in > >virtconv/ (or most of virtinst/) should raise exceptions to allow the > >caller to decide the correct behaviour (if I'm a daemon, I'd better keep > >running; a GUI, I'd better bring up a dialog box, etc.). > > > Cole updated it only a few days ago, here's what I'm seeing at least: > > grep -r "fail(" virt-convert > > fail("Couldn't clean up output directory \"%s\": %s" % > fail("Couldn't import file \"%s\": %s" % > fail("Couldn't import file \"%s\": %s" % (options.input_file, e)) > fail("Could not create directory %s: %s" % Aren't these all in the file virt-convert? See above. I can still write my daemon and use virtconv/ code without hitting a fail. Your addition breaks that - is that clearer? regards john From crobinso at redhat.com Mon Sep 29 20:47:12 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 29 Sep 2008 16:47:12 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E137B4.3090404@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> Message-ID: <48E13ED0.70001@redhat.com> Joey Boggs wrote: > John Levon wrote: >> On Mon, Sep 29, 2008 at 03:28:04PM -0400, Joey Boggs wrote: >> >> >>>> +import virtinst.ImageParser as ImageParser >>>> +from virtinst.cli import fail >>>> >>>> Surely this isn't right - this code is "library" code and shouldn't be >>>> using fail() ? It should be re-raising the exception... >>>> >>> Not sure about this, all the other apps in virtinst use fail() now in >>> exceptions even virt-convert, or am I misunderstanding something? >>> >> I just grepped and didn't see that. The only fail() usages are in >> virtinst/cli.py. That's right and proper: library code like that in >> virtconv/ (or most of virtinst/) should raise exceptions to allow the >> caller to decide the correct behaviour (if I'm a daemon, I'd better keep >> running; a GUI, I'd better bring up a dialog box, etc.). >> > Cole updated it only a few days ago, here's what I'm seeing at least: > > grep -r "fail(" virt-convert > > fail("Couldn't clean up output directory \"%s\": %s" % > fail("Couldn't import file \"%s\": %s" % > fail("Couldn't import file \"%s\": %s" % (options.input_file, e)) > fail("Could not create directory %s: %s" % > 'fail' should only be called from command line apps, hence you will see it in the virt-* utils and virtinst/cli.py. The reason it shouldn't be used anywhere else is because it forces the app to exit. You don't want to do that from a library (aka most of virtinst/* and all of virtconv/*) because it leaves the higher level apps no way to deal with the error. > >> It's a fine restriction, but it seems inconsistent: why are we assuming >> that virt-image import is using SCSI? Wouldn't a better default be IDE? >> >> regards >> john >> > Never caught that, I always assumed the disks were scsi, are they not? > virt image isn't specific so I'm guessing we will need someone else to > chime in and clarify this. > If there isn't any specific mention of IDE or SCSI in the virt-image file, then it will end up using virtinst's default, which is IDE for fullvirt guests and xvda for paravirt. Thanks, Cole From jboggs at redhat.com Mon Sep 29 21:26:47 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 29 Sep 2008 17:26:47 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E13ED0.70001@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> Message-ID: <48E14817.1090401@redhat.com> Got it all figured out now, its set to raise an exception rather than fail() Also changed the bus to ide rather than scsi. Cole Robinson wrote: > Joey Boggs wrote: > >> John Levon wrote: >> >>> On Mon, Sep 29, 2008 at 03:28:04PM -0400, Joey Boggs wrote: >>> >>> >>> >>>>> +import virtinst.ImageParser as ImageParser >>>>> +from virtinst.cli import fail >>>>> >>>>> Surely this isn't right - this code is "library" code and shouldn't be >>>>> using fail() ? It should be re-raising the exception... >>>>> >>>>> >>>> Not sure about this, all the other apps in virtinst use fail() now in >>>> exceptions even virt-convert, or am I misunderstanding something? >>>> >>>> >>> I just grepped and didn't see that. The only fail() usages are in >>> virtinst/cli.py. That's right and proper: library code like that in >>> virtconv/ (or most of virtinst/) should raise exceptions to allow the >>> caller to decide the correct behaviour (if I'm a daemon, I'd better keep >>> running; a GUI, I'd better bring up a dialog box, etc.). >>> >>> >> Cole updated it only a few days ago, here's what I'm seeing at least: >> >> grep -r "fail(" virt-convert >> >> fail("Couldn't clean up output directory \"%s\": %s" % >> fail("Couldn't import file \"%s\": %s" % >> fail("Couldn't import file \"%s\": %s" % (options.input_file, e)) >> fail("Could not create directory %s: %s" % >> >> > > 'fail' should only be called from command line apps, hence you will > see it in the virt-* utils and virtinst/cli.py. The reason it > shouldn't be used anywhere else is because it forces the app to > exit. You don't want to do that from a library (aka most of > virtinst/* and all of virtconv/*) because it leaves the higher > level apps no way to deal with the error. > > >>> It's a fine restriction, but it seems inconsistent: why are we assuming >>> that virt-image import is using SCSI? Wouldn't a better default be IDE? >>> >>> regards >>> john >>> >>> >> Never caught that, I always assumed the disks were scsi, are they not? >> virt image isn't specific so I'm guessing we will need someone else to >> chime in and clarify this. >> >> > > If there isn't any specific mention of IDE or SCSI in the > virt-image file, then it will end up using virtinst's > default, which is IDE for fullvirt guests and xvda for > paravirt. > > Thanks, > Cole > > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-vmware-conversion-module-9-29-1722.patch Type: text/x-patch Size: 8387 bytes Desc: not available URL: From jboggs at redhat.com Tue Sep 30 14:50:59 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 30 Sep 2008 10:50:59 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst adding in disk signature support In-Reply-To: <48DAA51E.4040001@redhat.com> References: <48DA8043.8070007@redhat.com> <48DA8B0D.8040703@redhat.com> <48DA91BE.1000005@redhat.com> <48DA9768.7050706@redhat.com> <48DAA51E.4040001@redhat.com> Message-ID: <48E23CD3.6040805@redhat.com> I reworked the else condition to raise an exception in ImageParser.py rather than fail() Joey Boggs wrote: > new patch, should have everything corrected below > - md5 option in image.rng > - broke up long lines > - new image.xml example w/ md5 > - using builtin python sha/md5 support > > > Cole Robinson wrote: >> Joey Boggs wrote: >> >>> Just to make sure, if I move that logic for "either sha1/md5 and not >>> None" into ImageParser right when I pull in the checksum data that >>> would that be sufficient? >>> >>> >> >> Right, that should work. >> >> - Cole >> >> _______________________________________________ >> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-image-disk-signature-check-9-30-1045.patch Type: text/x-patch Size: 4287 bytes Desc: not available URL: From crobinso at redhat.com Tue Sep 30 16:04:13 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 12:04:13 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial consoles as tabs in 'details' window Message-ID: <48E24DFD.4050105@redhat.com> The attached patch combines the serial console window with the VM details window. Opening the serial console now appends a tab to the details view. In addition, multiple serial consoles are now supported, not just the primary/first defined console, though this still only works for 'pty' devices. The patch does three things: 1) Remove all the previous plumbing needed to keep track of the separate console window 2) Fix the vmmSerialConsole class to extend gtk.HBox, so we can reuse most of the code in a notebook tab. 3) Add all the plumbing in details.py to deal with adding and removing tabs on the fly. Screenshot of a couple tab examples: http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab1.png Screenshot of selecting which serial console to open (unsupported console types will have entries, they will just be disabled as shown): http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab2.png Screenshot of terminal right click menu. Tabs can be closed via this menu, or the 'View' menu shown in the second screenshot. http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab3.png Any comments appreciated. Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-serial-console-tab.patch Type: text/x-patch Size: 19422 bytes Desc: not available URL: From crobinso at redhat.com Tue Sep 30 16:41:12 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 12:41:12 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst adding in disk signature support In-Reply-To: <48E23CD3.6040805@redhat.com> References: <48DA8043.8070007@redhat.com> <48DA8B0D.8040703@redhat.com> <48DA91BE.1000005@redhat.com> <48DA9768.7050706@redhat.com> <48DAA51E.4040001@redhat.com> <48E23CD3.6040805@redhat.com> Message-ID: <48E256A8.3010204@redhat.com> Joey Boggs wrote: > I reworked the else condition to raise an exception in ImageParser.py > rather than fail() > Okay, a couple things: > diff -r 58a909b4f71c doc/image.rng > --- a/doc/image.rng Mon Sep 22 11:32:11 2008 -0400 > +++ b/doc/image.rng Tue Sep 30 10:47:20 2008 -0400 > @@ -197,6 +197,15 @@ > > > > + > + > + > + sha1 > + md5 > + > + > + > + > > > > diff -r 58a909b4f71c virt-image > --- a/virt-image Mon Sep 22 11:32:11 2008 -0400 > +++ b/virt-image Tue Sep 30 10:47:20 2008 -0400 > @@ -97,6 +97,8 @@ > help=_("Number of vcpus to configure for your guest")) > parser.add_option("", "--check-cpu", action="store_true", dest="check_cpu", > help=_("Check that vcpus do not exceed physical CPUs and warn if they do.")) > + parser.add_option("", "--checksum-ignore", action="store_true", dest="checksum_ignore", > + help=_("Ignore unmatching checksum values for disk signatures.")) > > # network options > parser.add_option("-m", "--mac", type="string", > @@ -188,6 +190,10 @@ > # now let's get some of the common questions out of the way > get_name(options.name, image.name, guest) > get_memory(options.memory, image.domain.memory, guest) > + > + if not options.checksum_ignore: > + cli.check_disk_signature(image,guest) > + > cli.get_uuid(options.uuid, guest) > get_vcpus(options.vcpus, image.domain.vcpu, options.check_cpu, > guest, conn) > diff -r 58a909b4f71c virtinst/ImageParser.py > --- a/virtinst/ImageParser.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtinst/ImageParser.py Tue Sep 30 10:47:20 2008 -0400 > @@ -213,7 +213,12 @@ > self.format = xpathString(node, "@format", Disk.FORMAT_RAW) > self.size = xpathString(node, "@size") > self.use = xpathString(node, "@use", Disk.USE_SYSTEM) > - > + self.checksum = xpathString(node, "checksum") > + self.checksumtype = xpathString(node, "checksum/@type") > + if self.checksumtype is None or self.checksumtype == "sha1" or self.checksumtype == "md5": > + pass Rather than hardcode these values in, we should do something like CSUM_SHA1 = "sha1" etc., then stick them in a list like the code does for formats below. > + else: > + raise ParserException("Invalid Checksum Type for %s. \n\nTo override the signature check add the --checksum-ignore option" % self.file) This error shouldn't reference --checksum-ignore, since this is part of the api, not tied to the command line. We also want to mark this as translatable. I'd suggest _("Invalid checksum type %s for file %s") > formats = [Disk.FORMAT_RAW, Disk.FORMAT_QCOW, Disk.FORMAT_QCOW2, Disk.FORMAT_VMDK, Disk.FORMAT_ISO] > validate (formats.count(self.format) > 0, > _("The format for disk %s must be one of %s") % > diff -r 58a909b4f71c virtinst/cli.py > --- a/virtinst/cli.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtinst/cli.py Tue Sep 30 10:47:20 2008 -0400 > @@ -30,6 +30,8 @@ > from virtinst import Guest, CapabilitiesParser, VirtualNetworkInterface, \ > VirtualGraphics, VirtualAudio > from virtinst import _virtinst as _ > +import sha > +import md5 > > MIN_RAM = 64 > force = False > @@ -352,6 +354,36 @@ > if sound: > guest.sound_devs.append(VirtualAudio(model="es1370")) > I think the following block might be better suited as part of the Image class. It isn't really specific to cli tools, and if anything else was built off the Image libraries they would certainly want to have the option of using this functionality as well. I'd recommend moving the actual checksum calculating as a Disk function, then add a helper to the Image class like verify_disk_checksums or something. > +def check_disk_signature(image,guest): > + i = 0 The use of 'i' here is redundant. Every loop iteration, just have a variable 'disk' that points to needs image, no reason to stick them in a dictionary that I can see. > + disks = {} > + checksum = None > + for k in image.storage.keys(): > + disks[i] = image.storage[k] > + > + if disks[i].checksumtype == "sha1": > + print _("\nChecking disk signature for: %s...") % disks[i].file > + file=open(disks[i].file,'r').read() > + checksum=sha.new(file).hexdigest() > + > + elif disks[i].checksumtype == "md5": > + print _("\nChecking disk signature for: %s...") % disks[i].file > + file=open(disks[i].file,'r').read() > + checksum=md5.new(file).hexdigest() > + else: > + if disks[i].checksumtype is None: > + return > + > + if checksum != disks[i].checksum: > + fail(_("Disk signature for %s does not match \n Expected: %s \n Received: %s" > + " \n\n To override the signature check add the --checksum-ignore option" > + % (disks[i].file,disks[i].checksum,checksum))) > + else: > + print "Disk Signature Verified" > + i = i + 1 > + > + return > + > ### Option parsing > def check_before_store(option, opt_str, value, parser): > if len(value) == 0: Thanks, Cole From crobinso at redhat.com Tue Sep 30 16:55:06 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 12:55:06 -0400 Subject: [et-mgmt-tools] python-virtinst-0.400.0 not working on rhel/centos-5 In-Reply-To: <48DBACD6.7020603@lfarkas.org> References: <48DBA910.3060508@lfarkas.org> <48DBAAA4.2010802@redhat.com> <48DBACD6.7020603@lfarkas.org> Message-ID: <48E259EA.2010203@redhat.com> Farkas Levente wrote: > Cole Robinson wrote: >> Farkas Levente wrote: >>> hi, >>> python-virtinst-0.400.0 is not working properly on rhel/centos-5. this >>> means if i try to create a new guest in virt-manager then nothing >>> happened after i select the network try (ie. forward not working while >>> back is working). if i simple downgrade to python-virtinst-0.300.3 then >>> it's working again. there is no error message not log nothing on the >>> console simple not happened anything. >>> is it known and/or fixed or not? >>> yours. >>> >> Check ~/.virt-manager/virt-manager.log and see if there is a >> traceback. > > here it's: > Try current upstream, I just committed a fix that should hopefully solve this issue. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=abc2cae7cff5 Thanks, Cole From crobinso at redhat.com Tue Sep 30 17:19:57 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 13:19:57 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E14817.1090401@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> <48E14817.1090401@redhat.com> Message-ID: <48E25FBD.3020800@redhat.com> Joey Boggs wrote: > Got it all figured out now, its set to raise an exception rather than fail() > > Also changed the bus to ide rather than scsi. > > This looks mostly ready, just a few small pieces. > diff -r 58a909b4f71c virt-convert > --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 > +++ b/virt-convert Mon Sep 29 17:22:59 2008 -0400 > @@ -217,6 +217,8 @@ > not format and vmcfg.host() == "SunOS"): > format = "vdisk" > > + elif options.output_format == "vmx": > + format = "vmdk" > if not format: > format = "raw" > > diff -r 58a909b4f71c virtconv/diskcfg.py > --- a/virtconv/diskcfg.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/diskcfg.py Mon Sep 29 17:22:59 2008 -0400 > @@ -181,7 +181,7 @@ > absout = os.path.join(outdir, relout) > > if not (out_format == DISK_FORMAT_VDISK or > - out_format == DISK_FORMAT_RAW): > + out_format == DISK_FORMAT_RAW or out_format == DISK_FORMAT_VMDK): > raise NotImplementedError("Cannot convert to disk format %s" % > output_format) > > diff -r 58a909b4f71c virtconv/parsers/virtimage.py > --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/virtimage.py Mon Sep 29 17:22:59 2008 -0400 > @@ -21,10 +21,12 @@ > import virtconv.formats as formats > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > +import virtconv.netdevcfg as netdevcfg > import virtinst.FullVirtGuest as fv > - > +import virtinst.ImageParser as ImageParser > from xml.sax.saxutils import escape > from string import ascii_letters > +import os > import re > > pv_boot_template = """ > @@ -183,16 +185,20 @@ > """ > name = "virt-image" > suffix = ".virt-image.xml" > - can_import = False > + can_import = True > can_export = True > - can_identify = False > + can_identify = True > > @staticmethod > def identify_file(input_file): > """ > Return True if the given file is of this format. > """ > - raise NotImplementedError > + try: > + image = ImageParser.parse_file(input_file) > + except ImageParser.ParserException, msg: > + return False Please log the failure here. > + return True > > @staticmethod > def import_file(input_file): > @@ -200,7 +206,52 @@ > Import a configuration file. Raises if the file couldn't be > opened, or parsing otherwise failed. > """ > - raise NotImplementedError > + vm = vmcfg.vm() > + try: > + config = ImageParser.parse_file(input_file) > + except Exception, e: > + raise Exception("Couldn't import file \"%s\": %s" % (input_file, e)) > + I'd say raise a ValueError here instead of a plain Exception. Also, just use single quotes instead of escaping the double quotes, it's simpler. > + domain = config.domain > + boot = domain.boots[0] > + > + if not config.name: > + raise ValueError("No Name defined in \"%s\"" % input_file) > + vm.name = config.name > + vm.memory = config.domain.memory > + if config.descr: > + vm.description = config.descr > + vm.nr_vcpus = config.domain.vcpu > + > + bus = "ide" > + nr_disks = 0 > + devid = (bus, nr_disks) This line is redundant. > + > + for d in boot.drives: > + disk = d.disk > + format = None > + if disk.format == ImageParser.Disk.FORMAT_RAW: > + format = diskcfg.DISK_FORMAT_RAW > + elif format == ImageParser.DISK_FORMAT_VMDK: > + format == diskcfg.DISK_FORMAT_VMDK > + > + if format is None: > + raise ValueError("Unable to determine disk format") > + devid = (bus, nr_disks) You can do away with nr_disks here if you just use len(vm.disks) > + vm.disks[devid] = diskcfg.disk(bus = bus, > + type = diskcfg.DISK_TYPE_DISK) > + vm.disks[devid].format = format > + vm.disks[devid].path = disk.file > + nr_disks = nr_disks + 1 > + > + nics = domain.interface > + nr_nics = 0 > + while nr_nics < nics: > + vm.netdevs[nr_nics] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) > + nr_nics = nr_nics + 1 I'd say ditch nr_nics and just use while nic_idx in range(0, nics): vm.netdevs[nic_idx] ... > + """ Eventually need to add support for mac addresses if given""" > + vm.validate() > + return vm > > @staticmethod > def export_file(vm, output_file): > diff -r 58a909b4f71c virtconv/parsers/vmx.py > --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/vmx.py Mon Sep 29 17:22:59 2008 -0400 > @@ -22,9 +22,62 @@ > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > import virtconv.netdevcfg as netdevcfg > - > +import time > +import sys > import re > import os > + > +_VMX_MAIN_TEMPLATE = """ > +#!/usr/bin/vmplayer > + > +# Generated %(now)s by %(progname)s > +# http://virt-manager.et.redhat.com/ > + > +# This is a Workstation 5 or 5.5 config file and can be used with Player > +config.version = "8" > +virtualHW.version = "4" > +guestOS = "other" > +displayName = "%(vm_name)s" > +annotation = "%(vm_description)s" > +guestinfo.vmware.product.long = "%(vm_name)s" > +guestinfo.vmware.product.url = "http://virt-manager.et.redhat.com/" > +guestinfo.vmware.product.class = "virtual machine" > +numvcpus = "%(vm_nr_vcpus)s" > +memsize = "%(vm_memory)d" > +MemAllowAutoScaleDown = "FALSE" > +MemTrimRate = "-1" > +uuid.action = "create" > +tools.remindInstall = "TRUE" > +hints.hideAll = "TRUE" > +tools.syncTime = "TRUE" > +serial0.present = "FALSE" > +serial1.present = "FALSE" > +parallel0.present = "FALSE" > +logging = "TRUE" > +log.fileName = "%(vm_name)s.log" > +log.append = "TRUE" > +log.keepOld = "3" > +isolation.tools.hgfs.disable = "FALSE" > +isolation.tools.dnd.disable = "FALSE" > +isolation.tools.copy.enable = "TRUE" > +isolation.tools.paste.enabled = "TRUE" > +floppy0.present = "FALSE" > +""" > +_VMX_ETHERNET_TEMPLATE = """ > +ethernet%(dev)s.present = "TRUE" > +ethernet%(dev)s.connectionType = "nat" > +ethernet%(dev)s.addressType = "generated" > +ethernet%(dev)s.generatedAddressOffset = "0" > +ethernet%(dev)s.autoDetect = "TRUE" > +""" > +_VMX_IDE_TEMPLATE = """ > +# IDE disk > +ide%(dev)s.present = "TRUE" > +ide%(dev)s.fileName = "%(disk_filename)s" > +ide%(dev)s.mode = "persistent" > +ide%(dev)s.startConnected = "TRUE" > +ide%(dev)s.writeThrough = "TRUE" > +""" > > def parse_netdev_entry(vm, fullkey, value): > """ > @@ -72,7 +125,7 @@ > # like this? > if bus == "ide": > inst = int(inst) + int(bus_nr) * 2 > - > + This is just adding trailing space. > devid = (bus, inst) > if not vm.disks.get(devid): > vm.disks[devid] = diskcfg.disk(bus = bus, > @@ -100,7 +153,7 @@ > name = "vmx" > suffix = ".vmx" > can_import = True > - can_export = False > + can_export = True > can_identify = True > > @staticmethod > @@ -160,7 +213,7 @@ > 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 is None > or disk.path.lower() == "auto detect" or > @@ -188,7 +241,46 @@ > Raises ValueError if configuration is not suitable, or another > exception on failure to write the output file. > """ > + vm.description = vm.description.strip() > + vm.description = vm.description.replace("\n","|") > + vmx_out_template = [] > + vmx_dict = { > + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), > + "progname": os.path.basename(sys.argv[0]), > + "vm_name": vm.name, > + "vm_description": vm.description or "None", > + "vm_nr_vcpus" : vm.nr_vcpus, > + "vm_memory": long(vm.memory)/1024 > + } > + vmx_out = _VMX_MAIN_TEMPLATE % vmx_dict > + vmx_out_template.append(vmx_out) > > - raise NotImplementedError > + disk_out_template = [] > + diskcount = 0 > + for disk in vm.disks: > + ide_count = 0 > + dev = "%d:%d" % (ide_count / 2, ide_count % 2) IDE count doesn't seem to be incremented here, > + disk_dict = { > + "dev": dev, > + "disk_filename" : vm.disks[disk].path > + } > + disk_out = _VMX_IDE_TEMPLATE % disk_dict > + disk_out_template.append(disk_out) > + diskcount = diskcount + 1 Diskcount isn't used. > + > + eth_out_template = [] > + if len(vm.netdevs): > + for devnum in vm.netdevs: > + eth_dict = { > + "dev" : devnum > + } > + eth_out = _VMX_ETHERNET_TEMPLATE % eth_dict > + eth_out_template.append(eth_out) > + > + outfile = open(output_file, "w") > + outfile.writelines(vmx_out_template) > + outfile.writelines(disk_out_template) > + outfile.writelines(eth_out_template) > + outfile.close() > > formats.register_parser(vmx_parser) Thanks, Cole From levon at movementarian.org Tue Sep 30 17:32:46 2008 From: levon at movementarian.org (John Levon) Date: Tue, 30 Sep 2008 18:32:46 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E25FBD.3020800@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> <48E14817.1090401@redhat.com> <48E25FBD.3020800@redhat.com> Message-ID: <20080930173246.GA31714@totally.trollied.org.uk> On Tue, Sep 30, 2008 at 01:19:57PM -0400, Cole Robinson wrote: > > @staticmethod > > def identify_file(input_file): > > """ > > Return True if the given file is of this format. > > """ > > - raise NotImplementedError > > + try: > > + image = ImageParser.parse_file(input_file) > > + except ImageParser.ParserException, msg: > > + return False > > Please log the failure here. Actually, I think this is right - we try multiple identify_file() routines until we find a sucessful one. Perhaps this code could split out "I know this is a virt-image file" from "I failed to parse this virt-image file", but I'm not sure it's worth it. regards john From jboggs at redhat.com Tue Sep 30 17:34:54 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 30 Sep 2008 13:34:54 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <20080930173246.GA31714@totally.trollied.org.uk> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> <48E14817.1090401@redhat.com> <48E25FBD.3020800@redhat.com> <20080930173246.GA31714@totally.trollied.org.uk> Message-ID: <48E2633E.6030608@redhat.com> Yep that's why I returned as false, if we log it, it will need to be "not recognized as a virt-image file, continuing...." or similiar John Levon wrote: > On Tue, Sep 30, 2008 at 01:19:57PM -0400, Cole Robinson wrote: > > >>> @staticmethod >>> def identify_file(input_file): >>> """ >>> Return True if the given file is of this format. >>> """ >>> - raise NotImplementedError >>> + try: >>> + image = ImageParser.parse_file(input_file) >>> + except ImageParser.ParserException, msg: >>> + return False >>> >> Please log the failure here. >> > > Actually, I think this is right - we try multiple identify_file() > routines until we find a sucessful one. > > Perhaps this code could split out "I know this is a virt-image file" > from "I failed to parse this virt-image file", but I'm not sure it's > worth it. > > regards > john > From crobinso at redhat.com Tue Sep 30 17:41:21 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 13:41:21 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E2633E.6030608@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> <48E14817.1090401@redhat.com> <48E25FBD.3020800@redhat.com> <20080930173246.GA31714@totally.trollied.org.uk> <48E2633E.6030608@redhat.com> Message-ID: <48E264C1.7010106@redhat.com> Joey Boggs wrote: > Yep that's why I returned as false, if we log it, it will need to be > "not recognized as a virt-image file, continuing...." or similiar > > Ah, my bad. Please ignore that piece. - Cole > John Levon wrote: >> On Tue, Sep 30, 2008 at 01:19:57PM -0400, Cole Robinson wrote: >> >> >>>> @staticmethod >>>> def identify_file(input_file): >>>> """ >>>> Return True if the given file is of this format. >>>> """ >>>> - raise NotImplementedError >>>> + try: >>>> + image = ImageParser.parse_file(input_file) >>>> + except ImageParser.ParserException, msg: >>>> + return False >>>> >>> Please log the failure here. >>> >> Actually, I think this is right - we try multiple identify_file() >> routines until we find a sucessful one. >> >> Perhaps this code could split out "I know this is a virt-image file" >> from "I failed to parse this virt-image file", but I'm not sure it's >> worth it. >> >> regards >> john >> > > _______________________________________________ > 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 Tue Sep 30 17:50:51 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 13:50:51 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48DD3F79.1010504@redhat.com> References: <48DD3F79.1010504@redhat.com> Message-ID: <48E266FB.2060705@redhat.com> Joey Boggs wrote: > Adds disk signatures into virt-convert for virt-image format virtual > machines > > Comments inline. > > diff -r 58a909b4f71c virtconv/parsers/virtimage.py > --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/virtimage.py Fri Sep 26 15:58:29 2008 -0400 > @@ -22,7 +22,7 @@ > import virtconv.vmcfg as vmcfg > import virtconv.diskcfg as diskcfg > import virtinst.FullVirtGuest as fv > - > +import sha Please keep the preceeding newline. Generally imports are grouped in some attempt at a logical manner for the sake of readability. > from xml.sax.saxutils import escape > from string import ascii_letters > import re > @@ -171,9 +171,11 @@ > type = "raw" > if disk.type == diskcfg.DISK_TYPE_ISO: > type = "iso" > + diskfile=open(path,'r').read() > + checksum=sha.new(diskfile).hexdigest() Please try to be consistent with surrounding code format. The code above is using: var = val You've added: var=val It helps code readability if spacing is reasonably consistent throughout. Hmm, so I just tried the above. What that is essentially trying to do is read the entire disk into memory, then pass it off as a giant string to the sha function. Clearly this is not a workable solution. This also applies to the virt-image hash changes as well. Haven't looked into the correct way to do it though. This is also a rather large performance drain. So at the very least it should not be the default. That said, I don't know the optimal way to expose this option, or even if we should. Is there a way that vmx files can store checksums? > storage.append( > - """\n""" % > - (path, type)) > + """\n""" > + """ %s\n \n""" % (path, type,checksum)) > > return storage, diskout Thanks, Cole From bkearney at redhat.com Tue Sep 30 17:50:10 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 30 Sep 2008 13:50:10 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E266FB.2060705@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> Message-ID: <48E266D2.2020708@redhat.com> Cole Robinson wrote: > Joey Boggs wrote: >> Adds disk signatures into virt-convert for virt-image format virtual >> machines >> >> > > Comments inline. > >> diff -r 58a909b4f71c virtconv/parsers/virtimage.py >> --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/parsers/virtimage.py Fri Sep 26 15:58:29 2008 -0400 >> @@ -22,7 +22,7 @@ >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> import virtinst.FullVirtGuest as fv >> - >> +import sha > > Please keep the preceeding newline. Generally imports are > grouped in some attempt at a logical manner for the sake > of readability. > >> from xml.sax.saxutils import escape >> from string import ascii_letters >> import re >> @@ -171,9 +171,11 @@ >> type = "raw" >> if disk.type == diskcfg.DISK_TYPE_ISO: >> type = "iso" >> + diskfile=open(path,'r').read() >> + checksum=sha.new(diskfile).hexdigest() > > Please try to be consistent with surrounding code > format. > > The code above is using: var = val > You've added: var=val > > It helps code readability if spacing is reasonably > consistent throughout. > > Hmm, so I just tried the above. What that is essentially > trying to do is read the entire disk into memory, then > pass it off as a giant string to the sha function. Clearly > this is not a workable solution. This also applies to > the virt-image hash changes as well. Haven't looked into > the correct way to do it though. > > This is also a rather large performance drain. So at the > very least it should not be the default. That said, I > don't know the optimal way to expose this option, or > even if we should. I think this will become important as we look to distribute the appliances either via RHN or on public sites. Also.. this makes us a bit more consistent with OVF. I am fine with making it off by default, and then causing the command line to turn it on. -- bk From jboggs at redhat.com Tue Sep 30 18:24:59 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 30 Sep 2008 14:24:59 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E266D2.2020708@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> Message-ID: <48E26EFB.6000602@redhat.com> >> >> >> It helps code readability if spacing is reasonably >> consistent throughout. >> >> Hmm, so I just tried the above. What that is essentially >> trying to do is read the entire disk into memory, then >> pass it off as a giant string to the sha function. Clearly >> this is not a workable solution. This also applies to >> the virt-image hash changes as well. Haven't looked into >> the correct way to do it though. >> >> This is also a rather large performance drain. So at the >> very least it should not be the default. That said, I >> don't know the optimal way to expose this option, or >> even if we should. > > I think this will become important as we look to distribute the > appliances either via RHN or on public sites. Also.. this makes us a > bit more consistent with OVF. > > I am fine with making it off by default, and then causing the command > line to turn it on. > > -- bk I'd rather it be right than kill performance and make it unusable at best, should the imagefile be bigger than the machines memory. If we outsource it to run a system command is that feasible, since we're dealing with big files? I know Cole was against that originally. I'll keep looking for a better way and cleanup the variables as well. Making it off by default is probably best too. From crobinso at redhat.com Tue Sep 30 18:33:52 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 14:33:52 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E26EFB.6000602@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> Message-ID: <48E27110.2070102@redhat.com> Joey Boggs wrote: >>> >>> It helps code readability if spacing is reasonably >>> consistent throughout. >>> >>> Hmm, so I just tried the above. What that is essentially >>> trying to do is read the entire disk into memory, then >>> pass it off as a giant string to the sha function. Clearly >>> this is not a workable solution. This also applies to >>> the virt-image hash changes as well. Haven't looked into >>> the correct way to do it though. >>> >>> This is also a rather large performance drain. So at the >>> very least it should not be the default. That said, I >>> don't know the optimal way to expose this option, or >>> even if we should. >> I think this will become important as we look to distribute the >> appliances either via RHN or on public sites. Also.. this makes us a >> bit more consistent with OVF. >> >> I am fine with making it off by default, and then causing the command >> line to turn it on. >> >> -- bk > I'd rather it be right than kill performance and make it unusable at > best, should the imagefile be bigger than the machines memory. If we > outsource it to run a system command is that feasible, since we're > dealing with big files? I know Cole was against that originally. I'll > keep looking for a better way and cleanup the variables as well. Making > it off by default is probably best too. > When I was talking about performance, I was addressing the 'correct' way to do, when the 'read into memory' piece is fixed. Even then, generating a checksum is a very slow process if you are using a large disk (I used sha1sum on a DVD iso and it took about 3-4 minutes). So in this case, turning it off by default is the thing to do, we can figure out a cli switch to enable it, but this is all dependent on determining the correct way to use the libraries. You'll just have to use a loop and read in blocks of data at a time, and keep passing it to the library to update the hash. - Cole From rjones at redhat.com Tue Sep 30 19:42:04 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 20:42:04 +0100 Subject: [et-mgmt-tools] virt-p2v and linux software raid. In-Reply-To: <48D4346A.8060106@redhat.com> References: <48D4346A.8060106@redhat.com> Message-ID: <20080930194204.GA12478@amd.home.annexia.org> On Fri, Sep 19, 2008 at 07:23:22PM -0400, Brandon Perkins wrote: > I was wondering if there is any progress on getting linux software raid > support. I'm not really qualified to help with patches, but I'd be more > than happy to test any patches to get this functionality in. It appears > I have a similar setup where I have three physical drives, three > identical partitions in a software RAID-1 (/boot), three identical > partitions for swap, and three identical partitions in a software RAID-5 > (/). And of course it bails out because it doesn't understand the > software raid type. Sorry I wasn't concentrating very hard on this list for the past couple of weeks. virt-p2v doesn't understand RAID devices at all. There's no real limitation here, it's just that you're the first person who has asked about it. Can you open a bug report, and also send the virt-p2v.log file from your attempted installation. 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 jboggs at redhat.com Tue Sep 30 21:39:13 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 30 Sep 2008 17:39:13 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E27110.2070102@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> Message-ID: <48E29C81.7040807@redhat.com> Here's a sample that works, just want to verify it's alright. Is 64MB too much/too little to read at one time? f = open("test.raw","r") m = sha.new() while 1: chunk = f.read(65536) if not chunk: break m.update(chunk) print m.hexdigest() Cole Robinson wrote: > Joey Boggs wrote: > >>>> It helps code readability if spacing is reasonably >>>> consistent throughout. >>>> >>>> Hmm, so I just tried the above. What that is essentially >>>> trying to do is read the entire disk into memory, then >>>> pass it off as a giant string to the sha function. Clearly >>>> this is not a workable solution. This also applies to >>>> the virt-image hash changes as well. Haven't looked into >>>> the correct way to do it though. >>>> >>>> This is also a rather large performance drain. So at the >>>> very least it should not be the default. That said, I >>>> don't know the optimal way to expose this option, or >>>> even if we should. >>>> >>> I think this will become important as we look to distribute the >>> appliances either via RHN or on public sites. Also.. this makes us a >>> bit more consistent with OVF. >>> >>> I am fine with making it off by default, and then causing the command >>> line to turn it on. >>> >>> -- bk >>> >> I'd rather it be right than kill performance and make it unusable at >> best, should the imagefile be bigger than the machines memory. If we >> outsource it to run a system command is that feasible, since we're >> dealing with big files? I know Cole was against that originally. I'll >> keep looking for a better way and cleanup the variables as well. Making >> it off by default is probably best too. >> >> > > When I was talking about performance, I was addressing the > 'correct' way to do, when the 'read into memory' piece is > fixed. Even then, generating a checksum is a very slow > process if you are using a large disk (I used sha1sum on > a DVD iso and it took about 3-4 minutes). > > So in this case, turning it off by default is the thing to > do, we can figure out a cli switch to enable it, but this > is all dependent on determining the correct way to use the > libraries. You'll just have to use a loop and read in blocks > of data at a time, and keep passing it to the library to > update the hash. > > - Cole > > From crobinso at redhat.com Tue Sep 30 21:43:37 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 30 Sep 2008 17:43:37 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E29C81.7040807@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> Message-ID: <48E29D89.9090806@redhat.com> Joey Boggs wrote: > Here's a sample that works, just want to verify it's alright. Is 64MB > too much/too little to read at one time? > 64MB certainly would be too much, but the below code is using 64KB :) Should be fine. > > f = open("test.raw","r") > m = sha.new() > while 1: > chunk = f.read(65536) > if not chunk: > break > m.update(chunk) > print m.hexdigest() > Thanks, Cole From jboggs at redhat.com Tue Sep 30 21:46:39 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 30 Sep 2008 17:46:39 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E29D89.9090806@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <48E29D89.9090806@redhat.com> Message-ID: <48E29E3F.0@redhat.com> hehe yeah i realized that a sec ago but didnt want to waste an email correcting myself. Cole Robinson wrote: > Joey Boggs wrote: > >> Here's a sample that works, just want to verify it's alright. Is 64MB >> too much/too little to read at one time? >> >> > > 64MB certainly would be too much, but the below code > is using 64KB :) Should be fine. > > >> f = open("test.raw","r") >> m = sha.new() >> while 1: >> chunk = f.read(65536) >> if not chunk: >> break >> m.update(chunk) >> print m.hexdigest() >> >> > > Thanks, > Cole >