From crobinso at redhat.com Thu May 7 20:29:44 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 07 May 2009 16:29:44 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst: Use openAuth to support SASL and PolicyKit Message-ID: <4A0344B8.8090304@redhat.com> The attached patch changes the virt-* cli tools to use the libvirt openAuth function for opening connections. This allows using PolicyKit and SASL auth with the tools. polkit-auth is forced to run in cli mode, so no graphical dialog will be launched. I've thought about having the --prompt flag play a role here, but since the use cases this fulfills did not previously work, there shouldn't be any chance of breaking existing uses. Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-open-auth.patch Type: text/x-patch Size: 3927 bytes Desc: not available URL: From agx at sigxcpu.org Fri May 8 09:55:17 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 8 May 2009 11:55:17 +0200 Subject: [et-mgmt-tools] [PATCH] virt-install: allow to set nic model Message-ID: <20090508095516.GA24742@bogon.ms20.nix> Hi, attached patch allows to set the nic model when running virt-install via: --network=network:default,model=virtio The argument parsing in get_network_opts is a bit overkill at the moment but this way we can add mac=... more easily later. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: nic_model.diff Type: text/x-diff Size: 5792 bytes Desc: not available URL: From agx at sigxcpu.org Fri May 8 14:49:44 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 8 May 2009 16:49:44 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: set proper parents for dialogs Message-ID: <20090508144944.GA28169@bogon.ms20.nix> Hi, the attached patch is a first attempt to make virt-manager better usable under tiling window managers like awesome[1]. The problem is that virt-manager opens dialogs without a parent set (like passing NULL as the first argument of gtk_message_dialog_new). This patch is a first attempt on fixing that for some of them. This way dialogs like the about dialog get displayed in the middle of the main window instead of floating. Does this look like the right thing to do? Cheers, -- Guido [1] http://awesome.naquadah.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: parent_dialogs.diff Type: text/x-diff Size: 4350 bytes Desc: not available URL: From crobinso at redhat.com Mon May 11 18:12:15 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 11 May 2009 14:12:15 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: set proper parents for dialogs In-Reply-To: <20090508144944.GA28169@bogon.ms20.nix> References: <20090508144944.GA28169@bogon.ms20.nix> Message-ID: <4A086A7F.1010600@redhat.com> Guido G?nther wrote: > Hi, > the attached patch is a first attempt to make virt-manager better usable > under tiling window managers like awesome[1]. The problem is that > virt-manager opens dialogs without a parent set (like passing NULL as > the first argument of gtk_message_dialog_new). This patch is a first > attempt on fixing that for some of them. This way dialogs like the about > dialog get displayed in the middle of the main window instead of > floating. Does this look like the right thing to do? > Cheers, > -- Guido > I can't claim to know the ins and outs of gtk, but this seems like the correct thing to do, and if it solves actual problems then I'm all for it. > # HG changeset patch > # User Guido G?nther > # Date 1241793452 -7200 > # Node ID 357e834adb137baf32276d013188230eb14c73de > # Parent 5b61bd10a66b91d40ad5652a8f39b14273175292 > Add a proper parent to dialogs. > > diff -r 5b61bd10a66b -r 357e834adb13 src/virtManager/about.py > --- a/src/virtManager/about.py Thu May 07 19:22:33 2009 +0100 > +++ b/src/virtManager/about.py Fri May 08 16:37:32 2009 +0200 > @@ -43,9 +43,10 @@ > "on_vmm_about_response": self.close, > }) > > - def show(self): > + def show(self, parent): > dialog = self.window.get_widget("vmm-about") > dialog.set_version(self.config.get_appversion()) > + dialog.set_transient_for(parent) > dialog.show_all() > dialog.present() > > diff -r 5b61bd10a66b -r 357e834adb13 src/virtManager/connect.py > --- a/src/virtManager/connect.py Thu May 07 19:22:33 2009 +0100 > +++ b/src/virtManager/connect.py Fri May 08 16:37:32 2009 +0200 > @@ -102,8 +102,9 @@ > self.window.get_widget("vmm-open-connection").hide() > self.stop_browse() > > - def show(self): > + def show(self, parent): > win = self.window.get_widget("vmm-open-connection") > + win.set_transient_for(parent) > win.show_all() > win.present() > self.reset_state() > diff -r 5b61bd10a66b -r 357e834adb13 src/virtManager/engine.py > --- a/src/virtManager/engine.py Thu May 07 19:22:33 2009 +0100 > +++ b/src/virtManager/engine.py Fri May 08 16:37:32 2009 +0200 > @@ -210,7 +210,7 @@ > def show_about(self): > if self.windowAbout == None: > self.windowAbout = vmmAbout(self.get_config()) > - self.windowAbout.show() > + self.windowAbout.show(self.windowManager.win) > > def show_help(self, index): > try: > @@ -221,7 +221,8 @@ > > def show_preferences(self): > if self.windowPreferences == None: > - self.windowPreferences = vmmPreferences(self.get_config()) > + self.windowPreferences = vmmPreferences(self.get_config(), > + self.windowManager.win) > self.windowPreferences.connect("action-show-help", self._do_show_help) > self.windowPreferences.show() > > @@ -239,7 +240,7 @@ > self.windowConnect = vmmConnect(self.get_config(), self) > self.windowConnect.connect("completed", self._connect_to_uri) > self.windowConnect.connect("cancelled", self._connect_cancelled) > - self.windowConnect.show() > + self.windowConnect.show(self.windowManager.win) > > def show_console(self, uri, uuid): > win = self.show_details(uri, uuid) > diff -r 5b61bd10a66b -r 357e834adb13 src/virtManager/manager.py > --- a/src/virtManager/manager.py Thu May 07 19:22:33 2009 +0100 > +++ b/src/virtManager/manager.py Fri May 08 16:37:32 2009 +0200 > @@ -119,6 +119,7 @@ > _("An unexpected error occurred")) > self.config = config > self.engine = engine > + self.win = self.window.get_widget("vmm-manager") > I'd rename this to self.topwin, since that's the more typical convention in the codebase. > self.delete_dialog = None > self.startup_error = None > @@ -343,11 +344,10 @@ > vmlist.get_selection().select_iter(vmlist.get_model().get_iter_first()) > > def show(self): > - win = self.window.get_widget("vmm-manager") > if self.is_visible(): > - win.present() > + self.win.present() > return > - win.show_all() > + self.win.show_all() > self.engine.increment_window_counter() > > if self.startup_error: > diff -r 5b61bd10a66b -r 357e834adb13 src/virtManager/preferences.py > --- a/src/virtManager/preferences.py Thu May 07 19:22:33 2009 +0100 > +++ b/src/virtManager/preferences.py Fri May 08 16:37:32 2009 +0200 > @@ -29,12 +29,13 @@ > "action-show-help": (gobject.SIGNAL_RUN_FIRST, > gobject.TYPE_NONE, [str]), > } > - def __init__(self, config): > + def __init__(self, config, parent): > self.__gobject_init__() > self.window = gtk.glade.XML(config.get_glade_dir() + "/vmm-preferences.glade", "vmm-preferences", domain="virt-manager") > self.config = config > > self.topwin = self.window.get_widget("vmm-preferences") > + self.topwin.set_transient_for(parent) > self.topwin.hide() > > self.config.on_console_popup_changed(self.refresh_console_popup) Thanks, Cole From crobinso at redhat.com Mon May 11 18:41:54 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 11 May 2009 14:41:54 -0400 Subject: [et-mgmt-tools] [PATCH] virt-install: allow to set nic model In-Reply-To: <20090508095516.GA24742@bogon.ms20.nix> References: <20090508095516.GA24742@bogon.ms20.nix> Message-ID: <4A087172.5020907@redhat.com> Guido G?nther wrote: > Hi, > attached patch allows to set the nic model when running virt-install > via: > > --network=network:default,model=virtio > > The argument parsing in get_network_opts is a bit overkill at the moment > but this way we can add mac=... more easily later. > Cheers, > -- Guido > Cool! Applied now: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/ea0fe33e53a8 - Cole From crobinso at redhat.com Mon May 11 18:48:14 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 11 May 2009 14:48:14 -0400 Subject: [et-mgmt-tools] RFC: virt-manager: Redesigned 'New VM' wizard In-Reply-To: <20090416161501.GA5337@bogon.ms20.nix> References: <49A86E27.20605@redhat.com> <20090302191203.GA8388@bogon.ms20.nix> <20090302195028.GA1372@redhat.com> <20090416161501.GA5337@bogon.ms20.nix> Message-ID: <4A0872EE.9060308@redhat.com> Guido G?nther wrote: > On Mon, Mar 02, 2009 at 07:50:28PM +0000, Daniel P. Berrange wrote: >> On Mon, Mar 02, 2009 at 08:12:03PM +0100, Guido G?nther wrote: >>> Hi Cole, >>> this all looks great. >>> On Fri, Feb 27, 2009 at 05:50:15PM -0500, Cole Robinson wrote: >>>> The summary section is pretty straight forward, no surprises here. >>>> The 'Advanced Options' section encompasses networking, hypervisor, and >>>> architecture options. The hypervisor and arch defaults were explained above. >>> An option to select disk (scsi, ide, virtio) and network adapter model >>> (e1000, ...) as advanced options would be great (still defaulting to >>> virtio if supported via the osdict) since there are some OSes that don't >>> support all hardware out of the box and there are kvm/qemu versions that >>> have problems with certain adapter types. >> If there are combinations of OS,Disk that don't work IMHO we should >> improve the OS type metadata so we don't use them. Choice of specific >> hardware models is something we really want to keep out of the new VM >> wizard, because the end user really isn't in a position to have the >> knowledge to make suitable choices. > Sometimes it's not an issue of the guest but of the hypervisor like > missing PXE roms[1]. Attached is a patch Andreas Unterkircher that adds > NIC model selection to the advanced options of the vm wizard (some code > could probably be shared with vmmAddHardware). > Cheers, > -- Guido > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521091 > Ideally this is the type of issue the OS metadata should still be able to solve, though we are far from it at the moment. Rather than adding on more UI to the 'New VM' wizard, the more general solution to problems like this is to allow a way to customize the VM before starting the install. My thought is that we can drop the user into the VM Details view, where they will then have all the functionality currently exposed by the add/remove hardware wizard. WRT the above issue, since I committed your patch to allow specifying model via virt-install, I think that's a reasonable workaround till the virt-manager work is done. Thanks, Cole From crobinso at redhat.com Mon May 11 18:52:45 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 11 May 2009 14:52:45 -0400 Subject: [et-mgmt-tools] RFC: virt-manager: Redesigned 'New VM' wizard In-Reply-To: <4A0872EE.9060308@redhat.com> References: <49A86E27.20605@redhat.com> <20090302191203.GA8388@bogon.ms20.nix> <20090302195028.GA1372@redhat.com> <20090416161501.GA5337@bogon.ms20.nix> <4A0872EE.9060308@redhat.com> Message-ID: <4A0873FD.6050008@redhat.com> Cole Robinson wrote: > Guido G?nther wrote: >> On Mon, Mar 02, 2009 at 07:50:28PM +0000, Daniel P. Berrange wrote: >>> On Mon, Mar 02, 2009 at 08:12:03PM +0100, Guido G?nther wrote: >>>> Hi Cole, >>>> this all looks great. >>>> On Fri, Feb 27, 2009 at 05:50:15PM -0500, Cole Robinson wrote: >>>>> The summary section is pretty straight forward, no surprises here. >>>>> The 'Advanced Options' section encompasses networking, hypervisor, and >>>>> architecture options. The hypervisor and arch defaults were explained above. >>>> An option to select disk (scsi, ide, virtio) and network adapter model >>>> (e1000, ...) as advanced options would be great (still defaulting to >>>> virtio if supported via the osdict) since there are some OSes that don't >>>> support all hardware out of the box and there are kvm/qemu versions that >>>> have problems with certain adapter types. >>> If there are combinations of OS,Disk that don't work IMHO we should >>> improve the OS type metadata so we don't use them. Choice of specific >>> hardware models is something we really want to keep out of the new VM >>> wizard, because the end user really isn't in a position to have the >>> knowledge to make suitable choices. >> Sometimes it's not an issue of the guest but of the hypervisor like >> missing PXE roms[1]. Attached is a patch Andreas Unterkircher that adds >> NIC model selection to the advanced options of the vm wizard (some code >> could probably be shared with vmmAddHardware). >> Cheers, >> -- Guido >> >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521091 >> > > Ideally this is the type of issue the OS metadata should still be able > to solve, though we are far from it at the moment. > Hmm, the above is wrong, I misunderstood the reported problem: OS metadata won't help if a PXE rom hasn't been installed. However, the point still stands that this shouldn't be a common case, and a more general solution to install tweaking is desired. - Cole > Rather than adding on more UI to the 'New VM' wizard, the more general > solution to problems like this is to allow a way to customize the VM > before starting the install. My thought is that we can drop the user > into the VM Details view, where they will then have all the > functionality currently exposed by the add/remove hardware wizard. > > WRT the above issue, since I committed your patch to allow specifying > model via virt-install, I think that's a reasonable workaround till the > virt-manager work is done. > > Thanks, > Cole > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From berrange at redhat.com Mon May 11 21:07:09 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 11 May 2009 22:07:09 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: set proper parents for dialogs In-Reply-To: <4A086A7F.1010600@redhat.com> References: <20090508144944.GA28169@bogon.ms20.nix> <4A086A7F.1010600@redhat.com> Message-ID: <20090511210709.GC26473@redhat.com> On Mon, May 11, 2009 at 02:12:15PM -0400, Cole Robinson wrote: > Guido G?nther wrote: > > Hi, > > the attached patch is a first attempt to make virt-manager better usable > > under tiling window managers like awesome[1]. The problem is that > > virt-manager opens dialogs without a parent set (like passing NULL as > > the first argument of gtk_message_dialog_new). This patch is a first > > attempt on fixing that for some of them. This way dialogs like the about > > dialog get displayed in the middle of the main window instead of > > floating. Does this look like the right thing to do? > > Cheers, > > -- Guido > > > > I can't claim to know the ins and outs of gtk, but this seems like the > correct thing to do, and if it solves actual problems then I'm all for it. This seems to pass in the main manager window to each of virt-manager's other windows, and uses that as the parent of the about dialog. I don't see how this will work in scenarios where the main manager window is not visible. If using gnome-terminal, for example with many terminals open, the window simply gets shown above the window I select Help->About from, and if you select 'Help -> About' from many windows, it just opens one new instance each time. I think this is simpler than trying to keep a singleton about window and making it track the manager window. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon May 11 21:10:23 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 11 May 2009 22:10:23 +0100 Subject: [et-mgmt-tools] RFC: virt-manager: Redesigned 'New VM' wizard In-Reply-To: <4A0873FD.6050008@redhat.com> References: <49A86E27.20605@redhat.com> <20090302191203.GA8388@bogon.ms20.nix> <20090302195028.GA1372@redhat.com> <20090416161501.GA5337@bogon.ms20.nix> <4A0872EE.9060308@redhat.com> <4A0873FD.6050008@redhat.com> Message-ID: <20090511211023.GD26473@redhat.com> On Mon, May 11, 2009 at 02:52:45PM -0400, Cole Robinson wrote: > Cole Robinson wrote: > > Guido G?nther wrote: > >> On Mon, Mar 02, 2009 at 07:50:28PM +0000, Daniel P. Berrange wrote: > >>> On Mon, Mar 02, 2009 at 08:12:03PM +0100, Guido G?nther wrote: > >>>> Hi Cole, > >>>> this all looks great. > >>>> On Fri, Feb 27, 2009 at 05:50:15PM -0500, Cole Robinson wrote: > >>>>> The summary section is pretty straight forward, no surprises here. > >>>>> The 'Advanced Options' section encompasses networking, hypervisor, and > >>>>> architecture options. The hypervisor and arch defaults were explained above. > >>>> An option to select disk (scsi, ide, virtio) and network adapter model > >>>> (e1000, ...) as advanced options would be great (still defaulting to > >>>> virtio if supported via the osdict) since there are some OSes that don't > >>>> support all hardware out of the box and there are kvm/qemu versions that > >>>> have problems with certain adapter types. > >>> If there are combinations of OS,Disk that don't work IMHO we should > >>> improve the OS type metadata so we don't use them. Choice of specific > >>> hardware models is something we really want to keep out of the new VM > >>> wizard, because the end user really isn't in a position to have the > >>> knowledge to make suitable choices. > >> Sometimes it's not an issue of the guest but of the hypervisor like > >> missing PXE roms[1]. Attached is a patch Andreas Unterkircher that adds > >> NIC model selection to the advanced options of the vm wizard (some code > >> could probably be shared with vmmAddHardware). > >> Cheers, > >> -- Guido > >> > >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521091 > >> > > > > Ideally this is the type of issue the OS metadata should still be able > > to solve, though we are far from it at the moment. > > > > Hmm, the above is wrong, I misunderstood the reported problem: OS > metadata won't help if a PXE rom hasn't been installed. However, the > point still stands that this shouldn't be a common case, and a more > general solution to install tweaking is desired. IMHO, if PXE rom is missing this is a QEMU or distro packaging bug. All the network adapters we use are capable of having a PXE rom in QEMU 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 agx at sigxcpu.org Mon May 11 23:04:04 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 12 May 2009 01:04:04 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: set proper parents for dialogs In-Reply-To: <20090511210709.GC26473@redhat.com> References: <20090508144944.GA28169@bogon.ms20.nix> <4A086A7F.1010600@redhat.com> <20090511210709.GC26473@redhat.com> Message-ID: <20090511230404.GA22530@bogon.ms20.nix> On Mon, May 11, 2009 at 10:07:09PM +0100, Daniel P. Berrange wrote: > This seems to pass in the main manager window to each of virt-manager's > other windows, and uses that as the parent of the about dialog. I don't > see how this will work in scenarios where the main manager window is > not visible. If using gnome-terminal, for example with many terminals How would that be possible? It seems the about dialog can only be called from the main window (or did I miss something?). Other dialogs that can be opened from different menus certainly do need more care. > open, the window simply gets shown above the window I select Help->About > from, and if you select 'Help -> About' from many windows, it just opens > one new instance each time. I think this is simpler than trying to keep > a singleton about window and making it track the manager window. I do agree iff the dialog in question can be spawned from more than one window. The main purpose of the patch was to get an idea if using set_transient_for is the right thing to do. Cheers, -- Guido From agx at sigxcpu.org Thu May 14 19:14:36 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 14 May 2009 21:14:36 +0200 Subject: [et-mgmt-tools] [PATCH] virtinst: parse /etc/default/console-setup for keymap Message-ID: <20090514191436.GA24225@bogon.ms20.nix> Hi, since recently Debian based distributions store keymap information in /etc/default/console-setup. The attached patch parses this file if no keymap is found in xorg.conf. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: console_setup.diff Type: text/x-diff Size: 1811 bytes Desc: not available URL: From david.h.vree at gmail.com Mon May 18 15:09:40 2009 From: david.h.vree at gmail.com (David H. Vree) Date: Mon, 18 May 2009 11:09:40 -0400 Subject: [et-mgmt-tools] virt-manager without KVM Message-ID: <4A117A34.9040805@gmail.com> I would like to run virt-manager on a number of Ubuntu 9.04 desktop boxes to manage virtual machines I have running on an Ubuntu Server box. However, when I select virt-manager for installation in the repo's it indirectly selects kvm as a dependency. However I do not need nor want kvm on these client workstations as all my virtual machines are on the server. Installing KVM on the client workstations loads the intel-kvm kernel module which interferes with other software running on these machines. Does virt-manager really require KVM to be running locally? Is there a way to get virt-manager up and running without KVM? From berrange at redhat.com Mon May 18 15:13:28 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 May 2009 16:13:28 +0100 Subject: [et-mgmt-tools] virt-manager without KVM In-Reply-To: <4A117A34.9040805@gmail.com> References: <4A117A34.9040805@gmail.com> Message-ID: <20090518151328.GI29795@redhat.com> On Mon, May 18, 2009 at 11:09:40AM -0400, David H. Vree wrote: > I would like to run virt-manager on a number of Ubuntu 9.04 desktop > boxes to manage virtual machines I have running on an Ubuntu Server > box. However, when I select virt-manager for installation in the repo's > it indirectly selects kvm as a dependency. However I do not need nor > want kvm on these client workstations as all my virtual machines are on > the server. Installing KVM on the client workstations loads the > intel-kvm kernel module which interferes with other software running on > these machines. > > Does virt-manager really require KVM to be running locally? Is there a > way to get virt-manager up and running without KVM? virt-manager has no direct dependancy on KVM, it simply wants libvirt. Your libvirt install exposes whatever virt technology is available (XEn, KVM, OpenVZ, etc, etc), so there should never be a need for a forced install of KVM when selecting virt-manager. Best report a bug against Ubuntu virt-manager package 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 ben at nerp.net Mon May 18 15:16:33 2009 From: ben at nerp.net (Ben Kochie) Date: Mon, 18 May 2009 08:16:33 -0700 (PDT) Subject: [et-mgmt-tools] virt-manager without KVM In-Reply-To: <4A117A34.9040805@gmail.com> References: <4A117A34.9040805@gmail.com> Message-ID: You're right, that's a dependancy problem with Ubuntu. You shouldn't need KVM just to run virt-manager. I would check out the Ubuntu bug tracking database for virt-manager and file a bug. https://bugs.launchpad.net/ubuntu/+source/virt-manager -ben "UNIX is user-friendly, it's just picky about its friends." On Mon, 18 May 2009, David H. Vree wrote: > I would like to run virt-manager on a number of Ubuntu 9.04 desktop boxes to > manage virtual machines I have running on an Ubuntu Server box. However, > when I select virt-manager for installation in the repo's it indirectly > selects kvm as a dependency. However I do not need nor want kvm on these > client workstations as all my virtual machines are on the server. Installing > KVM on the client workstations loads the intel-kvm kernel module which > interferes with other software running on these machines. > > Does virt-manager really require KVM to be running locally? Is there a way > to get virt-manager up and running without KVM? > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From david.h.vree at gmail.com Mon May 18 15:33:40 2009 From: david.h.vree at gmail.com (David H. Vree) Date: Mon, 18 May 2009 11:33:40 -0400 Subject: [et-mgmt-tools] Re: virt-manager without KVM In-Reply-To: <4A117A34.9040805@gmail.com> References: <4A117A34.9040805@gmail.com> Message-ID: <4A117FD4.3010208@gmail.com> Thanks for the quick replies. As I was composing my defect report I discovered the only defect was with me! I had Synaptic set to treat "recommends" packages as dependencies. First time I've been burned by that in 2 years.... Once I changed that setting, indeed virt-manager installed easy with only a small handful of other packages and ran perfectly. David H. Vree wrote: > I would like to run virt-manager on a number of Ubuntu 9.04 desktop > boxes to manage virtual machines I have running on an Ubuntu Server > box. However, when I select virt-manager for installation in the > repo's it indirectly selects kvm as a dependency. However I do not > need nor want kvm on these client workstations as all my virtual > machines are on the server. Installing KVM on the client workstations > loads the intel-kvm kernel module which interferes with other software > running on these machines. > > Does virt-manager really require KVM to be running locally? Is there > a way to get virt-manager up and running without KVM? From ben at nerp.net Mon May 18 15:54:36 2009 From: ben at nerp.net (Ben Kochie) Date: Mon, 18 May 2009 08:54:36 -0700 (PDT) Subject: [et-mgmt-tools] Re: virt-manager without KVM In-Reply-To: <4A117FD4.3010208@gmail.com> References: <4A117A34.9040805@gmail.com> <4A117FD4.3010208@gmail.com> Message-ID: Yes, recommends == dependancies is the default. Personally I found this default to be a mistake back when people still suggested you use dselect. But of course none of this has anything to do with virt-manager development. :) -ben "UNIX is user-friendly, it's just picky about its friends." On Mon, 18 May 2009, David H. Vree wrote: > Thanks for the quick replies. As I was composing my defect report I > discovered the only defect was with me! I had Synaptic set to treat > "recommends" packages as dependencies. First time I've been burned by that > in 2 years.... Once I changed that setting, indeed virt-manager installed > easy with only a small handful of other packages and ran perfectly. > > David H. Vree wrote: >> I would like to run virt-manager on a number of Ubuntu 9.04 desktop boxes >> to manage virtual machines I have running on an Ubuntu Server box. >> However, when I select virt-manager for installation in the repo's it >> indirectly selects kvm as a dependency. However I do not need nor want kvm >> on these client workstations as all my virtual machines are on the server. >> Installing KVM on the client workstations loads the intel-kvm kernel module >> which interferes with other software running on these machines. >> >> Does virt-manager really require KVM to be running locally? Is there a >> way to get virt-manager up and running without KVM? > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From rjones at redhat.com Tue May 19 14:23:41 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 19 May 2009 15:23:41 +0100 Subject: [et-mgmt-tools] ANNOUNCE: virt-inspector Message-ID: <20090519142341.GA14897@amd.home.annexia.org> Hi, I'm pleased to announce the first 'really working' version of virt-inspector. Source is in the libguestfs source repository: http://git.et.redhat.com/?p=libguestfs.git;a=summary Binaries are in Koji for Fedora 11 / Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=102697 (minimum version 1.0.27 required) This is a tool based around libguestfs which can inspect a virtual machine disk image and tell you some interesting things about what's inside it. Some of the things it can tell you: - What operating system(s) are installed, and what distros and versions. It currently covers RHEL releases, Fedora releases, Debian releases, and has limited support for Windows. - How disk partitions are expected to be mounted (eg. /dev/sda1 -> /boot) - What applications are installed. - What kernel(s) are installed. - What kernel modules are installed. It can produce output in plain text (as a report) or in XML (to feed into other programs). It uses libvirt (if available) to get details of inactive domains, or you can run it directly on disk images. Usage is simple: virt-inspector --xml domain > info.xml # xml report virt-inspector /path/to/disk.img | less # plain text report You can also use it as a wrapper for guestfish, so it mounts the guest disks in the correct places, eg: $ virt-inspector --fish /dev/Guests/CentOS5.img guestfish -a /dev/Guests/CentOS5.img -m /dev/VolGroup00/LogVol00:/ -m /dev/sda1:/boot $ eval `virt-inspector --fish /dev/Guests/CentOS5.img` Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help with commands 'quit' to quit the shell > mounts /dev/mapper/VolGroup00-LogVol00 /dev/sda1 > ll /boot/ total 12151 drwxr-xr-x 4 root root 1024 May 11 18:16 . drwxr-xr-x 22 root root 4096 May 19 05:06 .. -rw-r--r-- 1 root root 931546 May 7 11:05 System.map-2.6.18-128.1.10.el5 -rw-r--r-- 1 root root 931457 Jan 21 11:10 System.map-2.6.18-128.el5 -rw-r--r-- 1 root root 67942 May 7 11:05 config-2.6.18-128.1.10.el5 -rw-r--r-- 1 root root 67937 Jan 21 11:10 config-2.6.18-128.el5 [etc] To do: - Lots of testing, particularly with different guests. - Answer higher-level questions, eg. "what network drivers will this guest use?" "does this guest need a Xen hypervisor?" - Generate a libvirt XML config file (partly overlaps the functionality of new 'virsh import|export*' functions: http://www.redhat.com/archives/libvir-list/2009-April/msg00401.html ) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From agx at sigxcpu.org Wed May 20 17:27:28 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Wed, 20 May 2009 19:27:28 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: make return value check match self.get_config_keymap() Message-ID: <20090520172728.GA14502@bogon.ms20.nix> In the "Add hardware" wizard summary, the keymap field is set to "None" instead of the empty string when "Same as host" option is used. This patch was posted by Laurent L?onard to the Debian BTS. Cheers, -- Guido --- src/virtManager/addhardware.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/virtManager/addhardware.py b/src/virtManager/addhardware.py index 4648c88..de289d4 100644 --- a/src/virtManager/addhardware.py +++ b/src/virtManager/addhardware.py @@ -522,7 +522,7 @@ class vmmAddHardware(gobject.GObject): self.window.get_widget("summary-graphics-password").set_text(_("Yes")) else: self.window.get_widget("summary-graphics-password").set_text(_("No")) - if self.get_config_keymap() != "": + if self.get_config_keymap() is not None: self.window.get_widget("summary-graphics-keymap").set_text(str(self.get_config_keymap())) else: self.window.get_widget("summary-graphics-keymap").set_text(_("Same as host")) From wangjihai at huawei.com Thu May 21 09:31:56 2009 From: wangjihai at huawei.com (Arthur Wang) Date: Thu, 21 May 2009 17:31:56 +0800 Subject: [et-mgmt-tools] [vir-p2v] HELP: build iso from virt-p2v Message-ID: <200905211731562118793@huawei.com> Hello, I have a trouble when build virt-p2v-0.9.9.tar.gz to generate an iso file. Search for help I have install all the packet that virt-p2v depend on, and i run the follow commands successfully configure make rpm But when i enter "make build" command, wait minutes, i got the follow error: Setting maximal mount count to -1 Setting interval between checks to 0 seconds Error creating Live CD : Unable to download from repo : Cannot retrieve repository metadata (repomd.xml) for repository: released. Please verify its path and try again make: *** [build] error 1 Could anyone tell me where it want to get repository metadata , and which tools or command it use to get? 2009-05-21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennisml at conversis.de Mon May 25 17:45:56 2009 From: dennisml at conversis.de (Dennis J.) Date: Mon, 25 May 2009 19:45:56 +0200 Subject: [et-mgmt-tools] PV Lenny install url? Message-ID: <4A1AD954.6070802@conversis.de> Hi, I'm trying to setup a paravirtualized Debian Lenny on a Centos 5.3 host. With the virt-install that comes with centos/rhel I was only able to install it using HVM and then paravirtualizing it afterwards. Now I have compiled more recent version of libvirt and the management tools that support installing Debian Lenny directly but I'm wondering what URL I'm supposed to specify? With centos/rhel I use the path /(...)/centos/5/os/x86_64/ but Debian Lenny apparently uses a different way to organize it's repositories. What would the correct url parameter be for a Lenny 64 bit install? Regards, Dennis From vovfooo at huaweisymantec.com Tue May 26 07:57:28 2009 From: vovfooo at huaweisymantec.com (vovfooo) Date: Tue, 26 May 2009 15:57:28 +0800 Subject: [et-mgmt-tools] Problem of using virt-install to create hvm guest, thanks for help! Message-ID: <002901c9ddd7$c21764f0$6f451b0a@china.huawei.com> There is a problem need you help! When I use virt-install to create a redhat5 hvm guest on redhat5 virtualization platform, it generated a config file. ***************************************** name = "rh5_hvm" uuid = "257b4f8c-a468-2391-952e-12fd0fcae56e" maxmem = 256 memory = 256 vcpus = 1 builder = "hvm" kernel = "/usr/lib/xen/boot/hvmloader" boot = "c" pae = 1 acpi = 1 apic = 1 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib/xen/bin/qemu-dm" sdl = 0 vnc = 0 vncunused = 0 vncdisplay = "-5900" disk = [ "file:/opt/redhat5hvm.img,hda,w", ",hdc:cdrom,r" ] vif = [ "mac=00:16:3e:76:2d:bc,bridge=xenbr0,type=ioemu" ] serial = "pty" ***************************************** In this file, disk is named hda and hdc, but I do have two SATA disk sda and sdb. And finally I cann't create the guest. Here is the information of the creating process. ***************************************** [root at localhost xen]# virt-install Would you like a fully virtualized guest (yes or no)? This will allow you to run unmodified operating systems. yes What is the name of your virtual machine? rh5_hvm How much RAM should be allocated (in megabytes)? 256 What would you like to use as the disk (file path)? /opt/redhat5hvm.img Would you like to enable graphics support? (yes or no) no What is the virtual CD image, CD device or install location? ftp://129.22.0.201/pxe/rhel5_x86/ Starting install... Retrieving file .treeinfo... 0 B 00:00 Retrieving file boot.iso. 100% |=========================| 6.9 MB 00:00 Creating domain... 0 B 00:01 No console available for domain Domain installation still in progress. You can reconnect to the console to complete the installation process. ***************************************** Running "xm list", I can see the information: [root at localhost xen]# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 985 2 r----- 111.2 redhat5 1 511 1 -b---- 32.8 rh5_disk 3 255 1 -b---- 32.2 rh5_hvm 5 255 1 ------ 0.0 But when I try to login rh5_hvm using "xm console", I encountered an problem: [root at localhost xen]# xm console 5 xenconsole: Could not read tty from store: No such file or directory -------------- next part -------------- An HTML attachment was scrubbed... URL: From vovfooo at huaweisymantec.com Tue May 26 08:35:45 2009 From: vovfooo at huaweisymantec.com (vovfooo) Date: Tue, 26 May 2009 16:35:45 +0800 Subject: [et-mgmt-tools] Problem of using virt-install to create a suse10 domU PV guest Message-ID: <00d201c9dddc$f6c837b0$6f451b0a@china.huawei.com> I used virt-install to create a suse10 domU PV guest. Here is the problem: ******************************************************************* [root at localhost opt]# virt-install Would you like a fully virtualized guest (yes or no)? This will allow you to run unmodified operating systems. no What is the name of your virtual machine? suse10 How much RAM should be allocated (in megabytes)? 512 What would you like to use as the disk (file path)? /opt/suse10.img Would you like to enable graphics support? (yes or no) no What is the install location? file://129.22.0.201/pxe/suse10_sp1_x86/boot/i386 Starting install... Retrieving file .treeinfo... 0 B 00:00 Invalid URL location given: ftp://129.22.0.201/pxe/suse10_sp1_x86/boot/i386/images/xen/vmlinuz [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. Domain installation may not have been successful. If it was, you can restart your domain by running 'virsh start suse10'; otherwise, please restart your installation. Mon, 25 May 2009 15:14:17 ERROR Invalid URL location given: ftp://129.22.0.201/pxe/suse10_sp1_x86/boot/i386/images/xen/vmlinuz [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. Traceback (most recent call last): File "/usr/sbin/virt-install", line 502, in ? main() File "/usr/sbin/virt-install", line 462, in main dom = guest.start_install(conscb,progresscb) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 811, in start_install self._prepare_install(meter) File "/usr/lib/python2.4/site-packages/virtinst/ParaVirtGuest.py", line 56, in _prepare_install self._installer.prepare(guest = self, meter = meter) File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 239, in prepare self._prepare_kernel_and_initrd(guest, distro, meter) File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 209, in _prepare_kernel_and_initrd distro = distro) File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 123, in acquireKernel return store.acquireKernel(fetcher, progresscb) File "/usr/lib/python2.4/site-packages/virtinst/OSDistro.py", line 62, in acquireKernel kernel = fetcher.acquireFile(kernelpath, progresscb) File "/usr/lib/python2.4/site-packages/virtinst/ImageFetcher.py", line 88, in acquireFile raise ValueError, _("Invalid URL location given: %s %s") %\ ValueError: Invalid URL location given: ftp://129.22.0.201/pxe/suse10_sp1_x86/boot/i386/images/xen/vmlinuz [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. ******************************************************************* The target OS is Suse Enterprise Server 10, and in its directories I couldn't find images/xen/vmlinuz. Is this a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayeola at gmail.com Tue May 26 13:10:45 2009 From: jayeola at gmail.com (john maclean) Date: Tue, 26 May 2009 14:10:45 +0100 Subject: [et-mgmt-tools] PV Lenny install url? In-Reply-To: <4A1AD954.6070802@conversis.de> References: <4A1AD954.6070802@conversis.de> Message-ID: <4170c1720905260610w746c3b2fm9e4e7aa9d94923d8@mail.gmail.com> Would it better not to use debootstrap? As in create an image file, and point debootstrap to that? 2009/5/25 Dennis J. : > Hi, > I'm trying to setup a paravirtualized Debian Lenny on a Centos 5.3 host. > With the virt-install that comes with centos/rhel I was only able to install > it using HVM and then paravirtualizing it afterwards. > Now I have compiled more recent version of libvirt and the management tools > that support installing Debian Lenny directly but I'm wondering what URL I'm > supposed to specify? With centos/rhel I use the path > /(...)/centos/5/os/x86_64/ but Debian Lenny apparently uses a different way > to organize it's repositories. What would the correct url parameter be for a > Lenny 64 bit install? > > Regards, > ?Dennis > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- John Maclean 07739 171 531 MSc (DIC) Timezone: GMT From crobinso at redhat.com Tue May 26 14:38:00 2009 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 26 May 2009 10:38:00 -0400 Subject: [et-mgmt-tools] Problem of using virt-install to create hvm guest, thanks for help! In-Reply-To: <002901c9ddd7$c21764f0$6f451b0a@china.huawei.com> References: <002901c9ddd7$c21764f0$6f451b0a@china.huawei.com> Message-ID: <4A1BFEC8.8040104@redhat.com> vovfooo wrote: > There is a problem need you help! > > When I use virt-install to create a redhat5 hvm guest on redhat5 virtualization platform, it generated a config file. > ***************************************** > name = "rh5_hvm" > uuid = "257b4f8c-a468-2391-952e-12fd0fcae56e" > maxmem = 256 > memory = 256 > vcpus = 1 > builder = "hvm" > kernel = "/usr/lib/xen/boot/hvmloader" > boot = "c" > pae = 1 > acpi = 1 > apic = 1 > localtime = 0 > on_poweroff = "destroy" > on_reboot = "restart" > on_crash = "restart" > device_model = "/usr/lib/xen/bin/qemu-dm" > sdl = 0 > vnc = 0 > vncunused = 0 > vncdisplay = "-5900" > disk = [ "file:/opt/redhat5hvm.img,hda,w", ",hdc:cdrom,r" ] > vif = [ "mac=00:16:3e:76:2d:bc,bridge=xenbr0,type=ioemu" ] > serial = "pty" > ***************************************** > In this file, disk is named hda and hdc, but I do have two SATA disk sda and sdb. > > And finally I cann't create the guest. Here is the information of the creating process. > ***************************************** > [root at localhost xen]# virt-install > Would you like a fully virtualized guest (yes or no)? This will allow you to run unmodified operating systems. yes > What is the name of your virtual machine? rh5_hvm > How much RAM should be allocated (in megabytes)? 256 > What would you like to use as the disk (file path)? /opt/redhat5hvm.img > Would you like to enable graphics support? (yes or no) no > What is the virtual CD image, CD device or install location? ftp://129.22.0.201/pxe/rhel5_x86/ > > Starting install... > Retrieving file .treeinfo... 0 B 00:00 > Retrieving file boot.iso. 100% |=========================| 6.9 MB 00:00 > Creating domain... 0 B 00:01 > No console available for domain > > Domain installation still in progress. You can reconnect to > the console to complete the installation process. > ***************************************** > Running "xm list", I can see the information: > > [root at localhost xen]# xm list > Name ID Mem(MiB) VCPUs State Time(s) > Domain-0 0 985 2 r----- 111.2 > redhat5 1 511 1 -b---- 32.8 > rh5_disk 3 255 1 -b---- 32.2 > rh5_hvm 5 255 1 ------ 0.0 > > But when I try to login rh5_hvm using "xm console", I encountered an problem: > > [root at localhost xen]# xm console 5 > xenconsole: Could not read tty from store: No such file or directory > Xen HVM guests on RHEL 5.3 do not automatically have a text console set up (the way PV guests do). I'd recommend using VNC. - Cole From crobinso at redhat.com Tue May 26 14:41:49 2009 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 26 May 2009 10:41:49 -0400 Subject: [et-mgmt-tools] Problem of using virt-install to create a suse10 domU PV guest In-Reply-To: <00d201c9dddc$f6c837b0$6f451b0a@china.huawei.com> References: <00d201c9dddc$f6c837b0$6f451b0a@china.huawei.com> Message-ID: <4A1BFFAD.3000506@redhat.com> vovfooo wrote: > I used virt-install to create a suse10 domU PV guest. > Here is the problem: > ******************************************************************* > [root at localhost opt]# virt-install > Would you like a fully virtualized guest (yes or no)? This will allow you to run unmodified operating systems. no > What is the name of your virtual machine? suse10 > How much RAM should be allocated (in megabytes)? 512 > What would you like to use as the disk (file path)? /opt/suse10.img > Would you like to enable graphics support? (yes or no) no > What is the install location? file://129.22.0.201/pxe/suse10_sp1_x86/boot/i386 > > Starting install... > Retrieving file .treeinfo... 0 B 00:00 > Invalid URL location given: ftp://129.22.0.201/pxe/suse10_sp1_x86/boot/i386/images/xen/vmlinuz [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. > Domain installation may not have been > successful. If it was, you can restart your domain > by running 'virsh start suse10'; otherwise, please > restart your installation. > Mon, 25 May 2009 15:14:17 ERROR Invalid URL location given: ftp://129.22.0.201/pxe/suse10_sp1_x86/boot/i386/images/xen/vmlinuz [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. > Traceback (most recent call last): > File "/usr/sbin/virt-install", line 502, in ? > main() > File "/usr/sbin/virt-install", line 462, in main > dom = guest.start_install(conscb,progresscb) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 811, in start_install > self._prepare_install(meter) > File "/usr/lib/python2.4/site-packages/virtinst/ParaVirtGuest.py", line 56, in _prepare_install > self._installer.prepare(guest = self, meter = meter) > File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 239, in prepare > self._prepare_kernel_and_initrd(guest, distro, meter) > File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 209, in _prepare_kernel_and_initrd > distro = distro) > File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 123, in acquireKernel > return store.acquireKernel(fetcher, progresscb) > File "/usr/lib/python2.4/site-packages/virtinst/OSDistro.py", line 62, in acquireKernel > kernel = fetcher.acquireFile(kernelpath, progresscb) > File "/usr/lib/python2.4/site-packages/virtinst/ImageFetcher.py", line 88, in acquireFile > raise ValueError, _("Invalid URL location given: %s %s") %\ > ValueError: Invalid URL location given: ftp://129.22.0.201/pxe/suse10_sp1_x86/boot/i386/images/xen/vmlinuz [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. > ******************************************************************* > The target OS is Suse Enterprise Server 10, and in its directories I couldn't find images/xen/vmlinuz. Is this a bug? > What python-virtinst version are you using? There were fixes in the suse URL fetching that went into 0.300.2-12 that was shipped with RHEL 5.3. - Cole From crobinso at redhat.com Tue May 26 14:43:26 2009 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 26 May 2009 10:43:26 -0400 Subject: [et-mgmt-tools] PV Lenny install url? In-Reply-To: <4A1AD954.6070802@conversis.de> References: <4A1AD954.6070802@conversis.de> Message-ID: <4A1C000E.8010809@redhat.com> Dennis J. wrote: > Hi, > I'm trying to setup a paravirtualized Debian Lenny on a Centos 5.3 host. > With the virt-install that comes with centos/rhel I was only able to > install it using HVM and then paravirtualizing it afterwards. > Now I have compiled more recent version of libvirt and the management tools > that support installing Debian Lenny directly but I'm wondering what URL > I'm supposed to specify? With centos/rhel I use the path > /(...)/centos/5/os/x86_64/ but Debian Lenny apparently uses a different way > to organize it's repositories. What would the correct url parameter be for > a Lenny 64 bit install? > An example URL that virt-install expects: http://ftp.us.debian.org/debian/dists/etch/main/installer-i386/ However, support for debian URLs isn't available in the python-virtinst version in 5.3. You'll have to wait for 5.4. - Cole From dennisml at conversis.de Tue May 26 14:54:00 2009 From: dennisml at conversis.de (Dennis J.) Date: Tue, 26 May 2009 16:54:00 +0200 Subject: [et-mgmt-tools] PV Lenny install url? In-Reply-To: <4170c1720905260610w746c3b2fm9e4e7aa9d94923d8@mail.gmail.com> References: <4A1AD954.6070802@conversis.de> <4170c1720905260610w746c3b2fm9e4e7aa9d94923d8@mail.gmail.com> Message-ID: <4A1C0288.8070006@conversis.de> That's what I'm going to try out next. It would still be nice to be able to install a paravirtualized debian using virt-manager/virt-install though. I actually managed to find out the correct install URL in the sources: http://people.debian.org/~joeyh/d-i/ With that url virt-install retrieves kernel and initrd but after creating the domain the VM just panics during the kernel initialization. Regards, Dennis On 05/26/2009 03:10 PM, john maclean wrote: > Would it better not to use debootstrap? As in create an image file, > and point debootstrap to that? > > > > 2009/5/25 Dennis J.: >> Hi, >> I'm trying to setup a paravirtualized Debian Lenny on a Centos 5.3 host. >> With the virt-install that comes with centos/rhel I was only able to install >> it using HVM and then paravirtualizing it afterwards. >> Now I have compiled more recent version of libvirt and the management tools >> that support installing Debian Lenny directly but I'm wondering what URL I'm >> supposed to specify? With centos/rhel I use the path >> /(...)/centos/5/os/x86_64/ but Debian Lenny apparently uses a different way >> to organize it's repositories. What would the correct url parameter be for a >> Lenny 64 bit install? >> >> Regards, >> Dennis >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > > > From agx at sigxcpu.org Tue May 26 15:38:44 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 26 May 2009 17:38:44 +0200 Subject: [et-mgmt-tools] PV Lenny install url? In-Reply-To: <4A1AD954.6070802@conversis.de> References: <4A1AD954.6070802@conversis.de> Message-ID: <20090526153844.GA5536@bogon.sigxcpu.org> On Mon, May 25, 2009 at 07:45:56PM +0200, Dennis J. wrote: > Hi, > I'm trying to setup a paravirtualized Debian Lenny on a Centos 5.3 host. > With the virt-install that comes with centos/rhel I was only able to > install it using HVM and then paravirtualizing it afterwards. > Now I have compiled more recent version of libvirt and the management > tools that support installing Debian Lenny directly but I'm wondering > what URL I'm supposed to specify? With centos/rhel I use the path > /(...)/centos/5/os/x86_64/ but Debian Lenny apparently uses a different > way to organize it's repositories. What would the correct url parameter > be for a Lenny 64 bit install? Does http://honk.sigxcpu.org/con/Installing_Debian_Lenny_in_a_Xen_DomU_using_virtinst.html help? -- Guido From levon at movementarian.org Tue May 26 15:49:07 2009 From: levon at movementarian.org (John Levon) Date: Tue, 26 May 2009 11:49:07 -0400 Subject: [et-mgmt-tools] Problem of using virt-install to create a suse10 domU PV guest In-Reply-To: <4A1BFFAD.3000506@redhat.com> References: <00d201c9dddc$f6c837b0$6f451b0a@china.huawei.com> <4A1BFFAD.3000506@redhat.com> Message-ID: <20090526154907.GB1623@movementarian.org> On Tue, May 26, 2009 at 10:41:49AM -0400, Cole Robinson wrote: > What python-virtinst version are you using? There were fixes in the suse > URL fetching that went into 0.300.2-12 that was shipped with RHEL 5.3. Suse is borked generally. I needed these fixes: http://cr.opensolaris.org/~johnlev/suse-pv-support/ Note lines 548-9 in particular. This still doesn't do it for SLES10, since that not only forgets to mark the boot partition as active, it also doesn't ship a grub.conf. Suse 11.1 works after this though. regards john From dennisml at conversis.de Tue May 26 15:50:39 2009 From: dennisml at conversis.de (Dennis J.) Date: Tue, 26 May 2009 17:50:39 +0200 Subject: [et-mgmt-tools] PV Lenny install url? In-Reply-To: <20090526153844.GA5536@bogon.sigxcpu.org> References: <4A1AD954.6070802@conversis.de> <20090526153844.GA5536@bogon.sigxcpu.org> Message-ID: <4A1C0FCF.7040600@conversis.de> On 05/26/2009 05:38 PM, Guido G?nther wrote: > On Mon, May 25, 2009 at 07:45:56PM +0200, Dennis J. wrote: >> Hi, >> I'm trying to setup a paravirtualized Debian Lenny on a Centos 5.3 host. >> With the virt-install that comes with centos/rhel I was only able to >> install it using HVM and then paravirtualizing it afterwards. >> Now I have compiled more recent version of libvirt and the management >> tools that support installing Debian Lenny directly but I'm wondering >> what URL I'm supposed to specify? With centos/rhel I use the path >> /(...)/centos/5/os/x86_64/ but Debian Lenny apparently uses a different >> way to organize it's repositories. What would the correct url parameter >> be for a Lenny 64 bit install? > Does > http://honk.sigxcpu.org/con/Installing_Debian_Lenny_in_a_Xen_DomU_using_virtinst.html > help? That's what I tried after checking out the python-virtinst sources looking for the proper URL and that seems the solve the virt-install part of the problem but shortly after booting the debian installation kernel I get a panic on the guests console: ... [ 0.004000] console [tty0] enabled [ 0.004000] console [hvc0] enabled [ 0.004000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.004000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.004000] Memory: 219452k/262144k available (1999k kernel code, 41812k reserved, 1070k data, 340k init, 0k highmem) [ 0.004000] virtual kernel memory layout: [ 0.004000] fixmap : 0xf5617000 - 0xf57ff000 (1952 kB) [ 0.004000] pkmap : 0xf5200000 - 0xf5400000 (2048 kB) [ 0.004000] vmalloc : 0xd0800000 - 0xf51fe000 ( 585 MB) [ 0.004000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.004000] .init : 0xc0405000 - 0xc045a000 ( 340 kB) [ 0.004000] .data : 0xc02f3dfb - 0xc03ff968 (1070 kB) [ 0.004000] .text : 0xc0100000 - 0xc02f3dfb (1999 kB) [ 0.004000] Checking if this processor honours the WP bit even in supervisor mode...Ok. [ 0.004000] 1 multicall(s) failed: cpu 0 [ 0.004000] Pid: 0, comm: swapper Not tainted 2.6.29-2-686-bigmem #1 [ 0.004000] Call Trace: [ 0.004000] [] xen_mc_flush+0xa9/0x13f [ 0.004000] [] xen_mc_issue+0x11/0x23 [ 0.004000] [] xen_set_pud_hyper+0x5d/0x64 [ 0.004000] [] zap_low_mappings+0x2f/0x44 [ 0.004000] [] mem_init+0x2af/0x2b7 [ 0.004000] [] start_kernel+0x236/0x2de [ 0.004000] [] xen_start_kernel+0x7fb/0x803 [ 0.004000] ------------[ cut here ]------------ [ 0.004000] kernel BUG at /build/buildd-linux-2.6_2.6.29-5-i386-xtBC0n/linux-2.6-2.6.29/debian/build/source_i386_none/arch/x86/xen/multicalls.c:180! [ 0.004000] invalid opcode: 0000 [#1] SMP [ 0.004000] last sysfs file: [ 0.004000] Modules linked in: [ 0.004000] [ 0.004000] Pid: 0, comm: swapper Not taint Regards, Dennis From dennisml at conversis.de Tue May 26 16:01:13 2009 From: dennisml at conversis.de (Dennis J.) Date: Tue, 26 May 2009 18:01:13 +0200 Subject: [et-mgmt-tools] PV Lenny install url? In-Reply-To: <4A1C0288.8070006@conversis.de> References: <4A1AD954.6070802@conversis.de> <4170c1720905260610w746c3b2fm9e4e7aa9d94923d8@mail.gmail.com> <4A1C0288.8070006@conversis.de> Message-ID: <4A1C1249.2050405@conversis.de> Debootstrap doesn't seem to work either. When I try to install with: debootstrap --arch amd64 --include=linux-image-xen-amd64,grub lenny /mnt/xen Things seem to work out ok at first but at the end of the process debootstrap fails to setup grub properly with these errors in the log: subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of linux-image-xen-amd64: linux-image-xen-amd64 depends on linux-image-2.6.26-2-xen-amd64; however: Package linux-image-2.6.26-2-xen-amd64 is not configured yet. dpkg: error processing linux-image-xen-amd64 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-2.6.26-2-xen-amd64 linux-image-xen-amd64 Also I keep seeing these througout the logfile: /usr/share/debootstrap/functions: line 5: echo: write error: Broken pipe (line 5 says 'while echo "$YES" ; do : ; done') That doesn't look to healthy either (and might possibly be the real source for the problem above). Regards, Dennis On 05/26/2009 04:54 PM, Dennis J. wrote: > That's what I'm going to try out next. It would still be nice to be able > to install a paravirtualized debian using virt-manager/virt-install though. > I actually managed to find out the correct install URL in the sources: > http://people.debian.org/~joeyh/d-i/ > > With that url virt-install retrieves kernel and initrd but after > creating the domain the VM just panics during the kernel initialization. > > Regards, > Dennis > > On 05/26/2009 03:10 PM, john maclean wrote: >> Would it better not to use debootstrap? As in create an image file, >> and point debootstrap to that? >> >> >> >> 2009/5/25 Dennis J.: >>> Hi, >>> I'm trying to setup a paravirtualized Debian Lenny on a Centos 5.3 host. >>> With the virt-install that comes with centos/rhel I was only able to >>> install >>> it using HVM and then paravirtualizing it afterwards. >>> Now I have compiled more recent version of libvirt and the management >>> tools >>> that support installing Debian Lenny directly but I'm wondering what >>> URL I'm >>> supposed to specify? With centos/rhel I use the path >>> /(...)/centos/5/os/x86_64/ but Debian Lenny apparently uses a >>> different way >>> to organize it's repositories. What would the correct url parameter >>> be for a >>> Lenny 64 bit install? >>> >>> Regards, >>> Dennis >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> >> >> >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From kevin.stabel at gmail.com Wed May 27 08:55:18 2009 From: kevin.stabel at gmail.com (Kevin Stabel) Date: Wed, 27 May 2009 10:55:18 +0200 Subject: [et-mgmt-tools] virt-p2v question Message-ID: <2089F59D-78E5-4623-B906-7DA806D6C9FF@gmail.com> Hello, I have a question regarding virt-p2v. Have any of you used the resulting images in a vmware environment? If so, can you point me to some resources and/or a workflow to achieve this? Thank you, -Kevin From arayamajhi at unmc.edu Wed May 27 16:03:29 2009 From: arayamajhi at unmc.edu (Atul Rayamajhi) Date: Wed, 27 May 2009 11:03:29 -0500 Subject: [et-mgmt-tools] AUTO: Atul Rayamajhi is out of office. (returning Tue 05/26/2009) Message-ID: An HTML attachment was scrubbed... URL: From david.h.vree at gmail.com Wed May 27 19:44:18 2009 From: david.h.vree at gmail.com (David H. Vree) Date: Wed, 27 May 2009 15:44:18 -0400 Subject: [et-mgmt-tools] Importing kvm vm Message-ID: <4A1D9812.3030105@gmail.com> I am have a few kvm virtual machines that I have been running natively with kvm using commands like the following: kvm -hda mywinxp.qcow2 -m 2G -smp 2 -k en-us -name "My WinXP" -vga std -net nic -net user -soundhw all -cpu qemu64 It doesn't appear that I can put this under libvirt control via virt-manager. Do I need to use virt-install from the command line or can I just hand write the XML and put it in /etc/libvirt/qemu? From ben at nerp.net Wed May 27 20:34:42 2009 From: ben at nerp.net (Ben Kochie) Date: Wed, 27 May 2009 13:34:42 -0700 (PDT) Subject: [et-mgmt-tools] Importing kvm vm In-Reply-To: <4A1D9812.3030105@gmail.com> References: <4A1D9812.3030105@gmail.com> Message-ID: You want to write the xml, and then use virsh "create" command to read the XML and import it in. You will want to use the full path to the qcow2 file. -ben "UNIX is user-friendly, it's just picky about its friends." On Wed, 27 May 2009, David H. Vree wrote: > I am have a few kvm virtual machines that I have been running natively with > kvm using commands like the following: > > kvm -hda mywinxp.qcow2 -m 2G -smp 2 -k en-us -name "My WinXP" -vga std -net > nic -net user -soundhw all -cpu qemu64 > > It doesn't appear that I can put this under libvirt control via virt-manager. > Do I need to use virt-install from the command line or can I just hand write > the XML and put it in /etc/libvirt/qemu? > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From berrange at redhat.com Wed May 27 20:18:41 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 27 May 2009 21:18:41 +0100 Subject: [et-mgmt-tools] Importing kvm vm In-Reply-To: <4A1D9812.3030105@gmail.com> References: <4A1D9812.3030105@gmail.com> Message-ID: <20090527201840.GA12935@redhat.com> On Wed, May 27, 2009 at 03:44:18PM -0400, David H. Vree wrote: > I am have a few kvm virtual machines that I have been running natively > with kvm using commands like the following: > > kvm -hda mywinxp.qcow2 -m 2G -smp 2 -k en-us -name "My WinXP" -vga std > -net nic -net user -soundhw all -cpu qemu64 > > It doesn't appear that I can put this under libvirt control via > virt-manager. Do I need to use virt-install from the command line or > can I just hand write the XML and put it in /etc/libvirt/qemu? Try this for a starting point My WinXP 2048000 2048000 2 hvm destroy restart destroy /usr/bin/kvm Fill in a random mac address there & fix the disk path.... You'll probably want type=vnc for the graphics instead of sdl 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 quentusrex at gmail.com Wed May 27 21:28:59 2009 From: quentusrex at gmail.com (William King) Date: Wed, 27 May 2009 14:28:59 -0700 Subject: [et-mgmt-tools] broken pipe Message-ID: <4A1DB09B.50404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 version info: On workstation: virt-manager 0.6.1 libvirtd (libvirt) 0.6.1 On host: libvirtd (libvirt) 0.6.1 Error: right click on a guest, click open, get error: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 272, in show_details details = vmmDetails(self.get_config(), con.get_vm(uuid), self) File "/usr/share/virt-manager/virtManager/details.py", line 328, in __init__ self.update_widget_states(self.vm, self.vm.status()) File "/usr/share/virt-manager/virtManager/details.py", line 714, in update_widget_states self.window.get_widget("config-vcpus").set_sensitive(self.vm.is_vcpu_hotplug_capable()) File "/usr/share/virt-manager/virtManager/domain.py", line 136, in is_vcpu_hotplug_capable if self.vm.OSType() == "linux" \ File "/usr/lib/python2.6/dist-packages/libvirt.py", line 223, in OSType if ret is None: raise libvirtError ('virDomainGetOSType() failed', dom=self) libvirtError: cannot send data: Broken pipe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkodsJgACgkQZ63Azu7rahpirACeM1EejjDIpETIGp7e8mUuC3mi Pv0AoJkYbWLKfpGWmylvM/gYF0K+UQf7 =2xH8 -----END PGP SIGNATURE----- From mdehaan at redhat.com Wed May 27 22:12:08 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 27 May 2009 18:12:08 -0400 Subject: [et-mgmt-tools] Virtinst and blktap Message-ID: <4A1DBAB8.3080003@redhat.com> I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? --Michael From johnson.nh at gmail.com Thu May 28 02:18:39 2009 From: johnson.nh at gmail.com (Mark Johnson) Date: Wed, 27 May 2009 22:18:39 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1DBAB8.3080003@redhat.com> References: <4A1DBAB8.3080003@redhat.com> Message-ID: <521a4d120905271918i3f882394mb25f4f17db0c9a83@mail.gmail.com> On Wed, May 27, 2009 at 6:12 PM, Michael DeHaan wrote: > I had a user question about how they can specify blktap for Xen in Cobbler > instead of the file driver (for performance reasons) ... well, it turns out > they can't (yet). > > Under what conditions can we use blktap, and is that advisable? ? (I had > thought this might work like virtio, in which case, passing in the os > version uses a table, but it seems this may only actually depend on the host > and has no guest limitations?) > > It looks like from the virtinst code I could just call > utils.is_blktap_capable() from my libvirt-using application and if so, then > pass the driver=DRIVER_TAP options to virstinst. > > Good idea? ?Bad idea? For Solaris dom0, I have a patch that allows driver and subdriver in virt-install. If interested, I'm happy to submit it..Note, our blktap is different (vdisk). We have an additional format selection too. virt-install -p -n nevada -l /export/snv108.iso --nographics \ --noautoconsole -r 1024 \ --disk path=/export/nevada/disk0,size=10,driver=tap,subdriver=vdisk,format=vdi MRJ From agx at sigxcpu.org Thu May 28 07:29:19 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 28 May 2009 09:29:19 +0200 Subject: [et-mgmt-tools] PV Lenny install url? In-Reply-To: <4A1C0FCF.7040600@conversis.de> References: <4A1AD954.6070802@conversis.de> <20090526153844.GA5536@bogon.sigxcpu.org> <4A1C0FCF.7040600@conversis.de> Message-ID: <20090528072919.GA7878@bogon.sigxcpu.org> On Tue, May 26, 2009 at 05:50:39PM +0200, Dennis J. wrote: > [ 0.004000] kernel BUG at > /build/buildd-linux-2.6_2.6.29-5-i386-xtBC0n/linux-2.6-2.6.29/debian/build/source_i386_none/arch/x86/xen/multicalls.c:180! > [ 0.004000] invalid opcode: 0000 [#1] SMP ^^^^ - not good > [ 0.004000] last sysfs file: > [ 0.004000] Modules linked in: > [ 0.004000] > [ 0.004000] Pid: 0, comm: swapper Not taint I only used Lenny's 2.6.26 with Xen so far which works nicely. Could you check if that works for you? If it also fails this is probably a problem between the CentOS hv and Debian's PV kernel. Cheers, -- Guido From clalance at redhat.com Thu May 28 07:32:03 2009 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 28 May 2009 09:32:03 +0200 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1DBAB8.3080003@redhat.com> References: <4A1DBAB8.3080003@redhat.com> Message-ID: <4A1E3DF3.7040400@redhat.com> Michael DeHaan wrote: > I had a user question about how they can specify blktap for Xen in > Cobbler instead of the file driver (for performance reasons) ... well, > it turns out they can't (yet). > > Under what conditions can we use blktap, and is that advisable? (I had > thought this might work like virtio, in which case, passing in the os > version uses a table, but it seems this may only actually depend on the > host and has no guest limitations?) That's exactly right. It's a property of how the host OS accesses the disk on behalf of the domain, not of how the disk is presented to the domain. In fact, for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct file: access can corrupt your guest domains on host crash. The situation with FV domains is more complicated, but there, you can use file:, since it properly does flushing. > > It looks like from the virtinst code I could just call > utils.is_blktap_capable() from my libvirt-using application and if so, > then pass the driver=DRIVER_TAP options to virstinst. > > Good idea? Bad idea? The only reasonable default for Xen PV domains, in my opinion. -- Chris Lalancette From mdehaan at redhat.com Thu May 28 12:27:22 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 28 May 2009 08:27:22 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1E3DF3.7040400@redhat.com> References: <4A1DBAB8.3080003@redhat.com> <4A1E3DF3.7040400@redhat.com> Message-ID: <4A1E832A.8050602@redhat.com> Chris Lalancette wrote: > Michael DeHaan wrote: > >> I had a user question about how they can specify blktap for Xen in >> Cobbler instead of the file driver (for performance reasons) ... well, >> it turns out they can't (yet). >> >> Under what conditions can we use blktap, and is that advisable? (I had >> thought this might work like virtio, in which case, passing in the os >> version uses a table, but it seems this may only actually depend on the >> host and has no guest limitations?) >> > > That's exactly right. It's a property of how the host OS accesses the disk on > behalf of the domain, not of how the disk is presented to the domain. In fact, > for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct > file: access can corrupt your guest domains on host crash. The situation with > FV domains is more complicated, but there, you can use file:, since it properly > does flushing. > > >> It looks like from the virtinst code I could just call >> utils.is_blktap_capable() from my libvirt-using application and if so, >> then pass the driver=DRIVER_TAP options to virstinst. >> >> Good idea? Bad idea? >> > > The only reasonable default for Xen PV domains, in my opinion. > > Thanks. FWIW the default behavior of python-virtinst seems to be to /not/ use blktap, and should probably be fixed then if there's a potential corruption problem. I haven't tested command line virt-install to see what it does. From crobinso at redhat.com Thu May 28 13:02:04 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 28 May 2009 09:02:04 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1E832A.8050602@redhat.com> References: <4A1DBAB8.3080003@redhat.com> <4A1E3DF3.7040400@redhat.com> <4A1E832A.8050602@redhat.com> Message-ID: <4A1E8B4C.7090905@redhat.com> Michael DeHaan wrote: > Chris Lalancette wrote: >> Michael DeHaan wrote: >> >>> I had a user question about how they can specify blktap for Xen in >>> Cobbler instead of the file driver (for performance reasons) ... well, >>> it turns out they can't (yet). >>> >>> Under what conditions can we use blktap, and is that advisable? (I had >>> thought this might work like virtio, in which case, passing in the os >>> version uses a table, but it seems this may only actually depend on the >>> host and has no guest limitations?) >>> >> That's exactly right. It's a property of how the host OS accesses the disk on >> behalf of the domain, not of how the disk is presented to the domain. In fact, >> for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct >> file: access can corrupt your guest domains on host crash. The situation with >> FV domains is more complicated, but there, you can use file:, since it properly >> does flushing. >> >> > > >>> It looks like from the virtinst code I could just call >>> utils.is_blktap_capable() from my libvirt-using application and if so, >>> then pass the driver=DRIVER_TAP options to virstinst. >>> >>> Good idea? Bad idea? >>> >> The only reasonable default for Xen PV domains, in my opinion. >> >> > > Thanks. > > FWIW the default behavior of python-virtinst seems to be to /not/ use > blktap, and should probably be fixed then if there's a potential > corruption problem. > > I haven't tested command line virt-install to see what it does. > That default is actually set in virt-install and virt-manager, but probably should have been moved into the virtinst library a long time ago. - COle From mdehaan at redhat.com Thu May 28 13:05:14 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 28 May 2009 09:05:14 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1E8B4C.7090905@redhat.com> References: <4A1DBAB8.3080003@redhat.com> <4A1E3DF3.7040400@redhat.com> <4A1E832A.8050602@redhat.com> <4A1E8B4C.7090905@redhat.com> Message-ID: <4A1E8C0A.2020009@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Chris Lalancette wrote: >> >>> Michael DeHaan wrote: >>> >>> >>>> I had a user question about how they can specify blktap for Xen in >>>> Cobbler instead of the file driver (for performance reasons) ... well, >>>> it turns out they can't (yet). >>>> >>>> Under what conditions can we use blktap, and is that advisable? (I had >>>> thought this might work like virtio, in which case, passing in the os >>>> version uses a table, but it seems this may only actually depend on the >>>> host and has no guest limitations?) >>>> >>>> >>> That's exactly right. It's a property of how the host OS accesses the disk on >>> behalf of the domain, not of how the disk is presented to the domain. In fact, >>> for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct >>> file: access can corrupt your guest domains on host crash. The situation with >>> FV domains is more complicated, but there, you can use file:, since it properly >>> does flushing. >>> >>> >>> >> >>>> It looks like from the virtinst code I could just call >>>> utils.is_blktap_capable() from my libvirt-using application and if so, >>>> then pass the driver=DRIVER_TAP options to virstinst. >>>> >>>> Good idea? Bad idea? >>>> >>>> >>> The only reasonable default for Xen PV domains, in my opinion. >>> >>> >>> >> Thanks. >> >> FWIW the default behavior of python-virtinst seems to be to /not/ use >> blktap, and should probably be fixed then if there's a potential >> corruption problem. >> >> I haven't tested command line virt-install to see what it does. >> >> > > That default is actually set in virt-install and virt-manager, but > probably should have been moved into the virtinst library a long time ago. > > - COle > Yeah, I can't keep up very well when stuff doesn't happen there :) Should I make the fix in koan also or do you want to move it? --Michael From crobinso at redhat.com Thu May 28 13:03:36 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 28 May 2009 09:03:36 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <521a4d120905271918i3f882394mb25f4f17db0c9a83@mail.gmail.com> References: <4A1DBAB8.3080003@redhat.com> <521a4d120905271918i3f882394mb25f4f17db0c9a83@mail.gmail.com> Message-ID: <4A1E8BA8.8020708@redhat.com> Mark Johnson wrote: > On Wed, May 27, 2009 at 6:12 PM, Michael DeHaan wrote: >> I had a user question about how they can specify blktap for Xen in Cobbler >> instead of the file driver (for performance reasons) ... well, it turns out >> they can't (yet). >> >> Under what conditions can we use blktap, and is that advisable? (I had >> thought this might work like virtio, in which case, passing in the os >> version uses a table, but it seems this may only actually depend on the host >> and has no guest limitations?) >> >> It looks like from the virtinst code I could just call >> utils.is_blktap_capable() from my libvirt-using application and if so, then >> pass the driver=DRIVER_TAP options to virstinst. >> >> Good idea? Bad idea? > > For Solaris dom0, I have a patch that allows driver and subdriver in > virt-install. > If interested, I'm happy to submit it..Note, our blktap is different > (vdisk). We > have an additional format selection too. > > virt-install -p -n nevada -l /export/snv108.iso --nographics \ > --noautoconsole -r 1024 \ > --disk path=/export/nevada/disk0,size=10,driver=tap,subdriver=vdisk,format=vdi > > > MRJ Sounds like a reasonable addition to me. I'd be interested in a patch. Driver/subdriver and format should probably be two different patches though. Thanks, Cole From crobinso at redhat.com Thu May 28 13:06:13 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 28 May 2009 09:06:13 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1E8C0A.2020009@redhat.com> References: <4A1DBAB8.3080003@redhat.com> <4A1E3DF3.7040400@redhat.com> <4A1E832A.8050602@redhat.com> <4A1E8B4C.7090905@redhat.com> <4A1E8C0A.2020009@redhat.com> Message-ID: <4A1E8C45.1020605@redhat.com> Michael DeHaan wrote: > Cole Robinson wrote: >> Michael DeHaan wrote: >> >>> Chris Lalancette wrote: >>> >>>> Michael DeHaan wrote: >>>> >>>> >>>>> I had a user question about how they can specify blktap for Xen in >>>>> Cobbler instead of the file driver (for performance reasons) ... well, >>>>> it turns out they can't (yet). >>>>> >>>>> Under what conditions can we use blktap, and is that advisable? (I had >>>>> thought this might work like virtio, in which case, passing in the os >>>>> version uses a table, but it seems this may only actually depend on the >>>>> host and has no guest limitations?) >>>>> >>>>> >>>> That's exactly right. It's a property of how the host OS accesses the disk on >>>> behalf of the domain, not of how the disk is presented to the domain. In fact, >>>> for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct >>>> file: access can corrupt your guest domains on host crash. The situation with >>>> FV domains is more complicated, but there, you can use file:, since it properly >>>> does flushing. >>>> >>>> >>>> >>> >>>>> It looks like from the virtinst code I could just call >>>>> utils.is_blktap_capable() from my libvirt-using application and if so, >>>>> then pass the driver=DRIVER_TAP options to virstinst. >>>>> >>>>> Good idea? Bad idea? >>>>> >>>>> >>>> The only reasonable default for Xen PV domains, in my opinion. >>>> >>>> >>>> >>> Thanks. >>> >>> FWIW the default behavior of python-virtinst seems to be to /not/ use >>> blktap, and should probably be fixed then if there's a potential >>> corruption problem. >>> >>> I haven't tested command line virt-install to see what it does. >>> >>> >> That default is actually set in virt-install and virt-manager, but >> probably should have been moved into the virtinst library a long time ago. >> >> - COle >> > > Yeah, I can't keep up very well when stuff doesn't happen there :) > > Should I make the fix in koan also or do you want to move it? > > --Michael > I'll take a look at moving it into the library, but for back compat it wouldn't hurt to set the default in koan. The virt-install code is: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/file/5d6dc8af58b5/virt-install#l209 - Cole From mdehaan at redhat.com Thu May 28 13:11:37 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 28 May 2009 09:11:37 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1E8C45.1020605@redhat.com> References: <4A1DBAB8.3080003@redhat.com> <4A1E3DF3.7040400@redhat.com> <4A1E832A.8050602@redhat.com> <4A1E8B4C.7090905@redhat.com> <4A1E8C0A.2020009@redhat.com> <4A1E8C45.1020605@redhat.com> Message-ID: <4A1E8D89.9080303@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Cole Robinson wrote: >> >>> Michael DeHaan wrote: >>> >>> >>>> Chris Lalancette wrote: >>>> >>>> >>>>> Michael DeHaan wrote: >>>>> >>>>> >>>>> >>>>>> I had a user question about how they can specify blktap for Xen in >>>>>> Cobbler instead of the file driver (for performance reasons) ... well, >>>>>> it turns out they can't (yet). >>>>>> >>>>>> Under what conditions can we use blktap, and is that advisable? (I had >>>>>> thought this might work like virtio, in which case, passing in the os >>>>>> version uses a table, but it seems this may only actually depend on the >>>>>> host and has no guest limitations?) >>>>>> >>>>>> >>>>>> >>>>> That's exactly right. It's a property of how the host OS accesses the disk on >>>>> behalf of the domain, not of how the disk is presented to the domain. In fact, >>>>> for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct >>>>> file: access can corrupt your guest domains on host crash. The situation with >>>>> FV domains is more complicated, but there, you can use file:, since it properly >>>>> does flushing. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>>> It looks like from the virtinst code I could just call >>>>>> utils.is_blktap_capable() from my libvirt-using application and if so, >>>>>> then pass the driver=DRIVER_TAP options to virstinst. >>>>>> >>>>>> Good idea? Bad idea? >>>>>> >>>>>> >>>>>> >>>>> The only reasonable default for Xen PV domains, in my opinion. >>>>> >>>>> >>>>> >>>>> >>>> Thanks. >>>> >>>> FWIW the default behavior of python-virtinst seems to be to /not/ use >>>> blktap, and should probably be fixed then if there's a potential >>>> corruption problem. >>>> >>>> I haven't tested command line virt-install to see what it does. >>>> >>>> >>>> >>> That default is actually set in virt-install and virt-manager, but >>> probably should have been moved into the virtinst library a long time ago. >>> >>> - COle >>> >>> >> Yeah, I can't keep up very well when stuff doesn't happen there :) >> >> Should I make the fix in koan also or do you want to move it? >> >> --Michael >> >> > > I'll take a look at moving it into the library, but for back compat it > wouldn't hurt to set the default in koan. The virt-install code is: > > http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/file/5d6dc8af58b5/virt-install#l209 > > - Cole > Excellent, will do. From johnson.nh at gmail.com Thu May 28 13:28:54 2009 From: johnson.nh at gmail.com (Mark Johnson) Date: Thu, 28 May 2009 09:28:54 -0400 Subject: [et-mgmt-tools] Virtinst and blktap In-Reply-To: <4A1E8BA8.8020708@redhat.com> References: <4A1DBAB8.3080003@redhat.com> <521a4d120905271918i3f882394mb25f4f17db0c9a83@mail.gmail.com> <4A1E8BA8.8020708@redhat.com> Message-ID: <521a4d120905280628h73cd8510j2f43e5649a845c5d@mail.gmail.com> On Thu, May 28, 2009 at 9:03 AM, Cole Robinson wrote: > Mark Johnson wrote: >> >> For Solaris dom0, I have a patch that allows driver and subdriver in >> virt-install. >> If interested, I'm happy to submit it..Note, our blktap is different >> (vdisk). We >> have an additional format selection too. >> >> ? virt-install -p -n nevada -l /export/snv108.iso --nographics \ >> ? ? ?--noautoconsole -r 1024 \ >> ? ? ?--disk path=/export/nevada/disk0,size=10,driver=tap,subdriver=vdisk,format=vdi >> >> >> MRJ > > Sounds like a reasonable addition to me. I'd be interested in a patch. > Driver/subdriver and format should probably be two different patches though. OK. For now, I've attached our current patch for reference.. Not meant for submission. I'm not sure how far behind virt-install we are these days. FYI, It has more than just the tap stuff. We also support iscsi, etc.. e.g. we support the following iscsi paths... phy:iscsi:/alias/ phy:iscsi:/static/// phy:iscsi:/discover// virt-install -p -n nevada -l /export/snv108.iso --nographics \ --noautoconsole -r 1024 \ --disk path=/alias/tank/iscsi/nevada/disk0,driver=phy,subdriver=iscsi -------------- next part -------------- diff --git a/virt-install b/virt-install --- a/virt-install +++ b/virt-install @@ -81,6 +81,9 @@ sparse = True bus = None cache = None + driver = None + subdriver = None + format = None # Strip media type if path.startswith("path="): @@ -133,6 +136,12 @@ fail(_("Unknown '%s' value '%s'") % (opt_type, opt_val)) elif opt_type == "cache": cache = opt_val + elif opt_type == "driver": + driver = opt_val + elif opt_type == "subdriver": + subdriver = opt_val + elif opt_type == "format": + format = opt_val else: fail(_("Unknown --disk option '%s'.") % (opt,)) @@ -169,7 +178,7 @@ if not devtype: devtype = virtinst.VirtualDisk.DEVICE_DISK ret = (abspath, voltuple, volinst, devtype, bus, ro, shared, size, sparse, - cache) + cache, driver, subdriver, format) logging.debug("parse_disk: returning %s" % str(ret)) return ret @@ -179,13 +188,14 @@ # Get disk parameters if is_file_path: (path, voltuple, volinst, device, bus, readOnly, shared, size, - sparse, cache) = \ + sparse, cache, driver, subdriver, format) = \ (disk, None, None, virtinst.VirtualDisk.DEVICE_DISK, None, False, - False, size, sparse, None) + False, size, sparse, None, None, None, None) else: (path, voltuple, volinst, device, bus, readOnly, shared, - size, sparse, cache) = parse_disk_option(guest, disk, size) + size, sparse, cache, driver, subdriver, format) = \ + parse_disk_option(guest, disk, size) if not sparse and volinst: volinst.allocation = volinst.capacity @@ -193,7 +203,8 @@ volInstall=volinst, volName=voltuple, readOnly=readOnly, shareable=shared, device=device, bus=bus, conn=guest.conn, - driverCache=cache) + driverCache=cache, driverName=driver, + driverType=subdriver, format=format) # Default file backed PV guests to tap driver if d.type == virtinst.VirtualDisk.TYPE_FILE \ and not(hvm) and virtinst.util.is_blktap_capable(): diff --git a/virtinst/CloneManager.py b/virtinst/CloneManager.py --- a/virtinst/CloneManager.py +++ b/virtinst/CloneManager.py @@ -531,10 +531,10 @@ clone_type = IS_UNKNOWN - if (_util.is_vdisk(src_path) or - (os.path.exists(dst_path) and _util.is_vdisk(dst_path))): + if (_util.is_vdisk(src_path, None) or + (os.path.exists(dst_path) and _util.is_vdisk(dst_path, None))): - if (not _util.is_vdisk(src_path) or + if (not _util.is_vdisk(src_path, None) or os.path.exists(dst_path)): raise RuntimeError, _("copying to an existing vdisk is not" " supported") diff --git a/virtinst/Installer.py b/virtinst/Installer.py --- a/virtinst/Installer.py +++ b/virtinst/Installer.py @@ -293,7 +293,7 @@ or guest.disks[0].device != VirtualDisk.DEVICE_DISK: return True - if _util.is_vdisk(guest.disks[0].path): + if _util.is_vdisk(guest.disks[0].path, None): return True # Check for the 0xaa55 signature at the end of the MBR diff --git a/virtinst/VirtualDisk.py b/virtinst/VirtualDisk.py --- a/virtinst/VirtualDisk.py +++ b/virtinst/VirtualDisk.py @@ -28,6 +28,15 @@ import Storage from VirtualDevice import VirtualDevice from virtinst import _virtinst as _ + +def _zvol_create(path, size): + zvol = path.lstrip("/") + try: + rc = subprocess.call(['/usr/sbin/zfs', 'create', '-p', '-V', + str(size), zvol]) + return rc == 0 + except OSError: + return False def _vdisk_create(path, size, kind, sparse = True): force_fixed = "raw" @@ -83,8 +92,17 @@ DRIVER_TAP_QCOW = "qcow" DRIVER_TAP_VMDK = "vmdk" DRIVER_TAP_VDISK = "vdisk" + + DRIVER_PHY_ISCSI = "iscsi" + DRIVER_PHY_ZVOL = "zvol" + DRIVER_PHY_ZPOOL = "zpool" + DRIVER_PHY_NPIV = "npiv" + DRIVER_PHY_SAN = "san" + driver_types = [DRIVER_TAP_RAW, DRIVER_TAP_QCOW, - DRIVER_TAP_VMDK, DRIVER_TAP_VDISK] + DRIVER_TAP_VMDK, DRIVER_TAP_VDISK, + DRIVER_PHY_ISCSI, DRIVER_PHY_ZVOL, DRIVER_PHY_ZPOOL, + DRIVER_PHY_NPIV, DRIVER_PHY_SAN] CACHE_MODE_NONE = "none" CACHE_MODE_WRITETHROUGH = "writethrough" @@ -105,7 +123,7 @@ device=DEVICE_DISK, driverName=None, driverType=None, readOnly=False, sparse=True, conn=None, volObject=None, volInstall=None, volName=None, bus=None, shareable=False, - driverCache=None): + driverCache=None, format=None): """ @param path: filesystem path to the disk image. @type path: C{str} @@ -140,6 +158,8 @@ @type shareable: C{bool} @param driverCache: Disk cache mode (none, writethrough, writeback) @type driverCache: member of cache_types + @param format: driver-specific format to use during create + @type format: C{str} """ VirtualDevice.__init__(self, conn=conn) @@ -161,6 +181,7 @@ self._driverName = driverName self._driverType = driverType self.target = None + self.format = format self.set_read_only(readOnly, validate=False) self.set_sparse(sparse, validate=False) @@ -358,11 +379,13 @@ # All others should be using TYPE_BLOCK (hopefully) dtype = self.TYPE_BLOCK elif self.path: - if _util.stat_disk(self.path)[0]: + if self._driverName == self.DRIVER_PHY: + dtype = self.TYPE_BLOCK + elif _util.stat_disk(self.path)[0]: dtype = self.TYPE_FILE else: dtype = self.TYPE_BLOCK - if _util.is_vdisk(self.path): + if _util.is_vdisk(self.path, self._driverName): self._driverName = self.DRIVER_TAP self._driverType = self.DRIVER_TAP_VDISK @@ -553,7 +576,7 @@ if not create_media: # Make sure we have access to the local path if not managed_storage: - if os.path.isdir(self.path) and not _util.is_vdisk(self.path): + if os.path.isdir(self.path) and not _util.is_vdisk(self.path, self._driverName): # vdisk _is_ a directory. raise ValueError(_("The path '%s' must be a file or a " "device, not a directory") % self.path) @@ -568,7 +591,7 @@ raise ValueError, _("Cannot create storage for %s device.") % \ self.device - if not managed_storage: + if not managed_storage and not self._driverType: if self.type is self.TYPE_BLOCK: raise ValueError, _("Local block device path must exist.") self.set_type(self.TYPE_FILE, validate=False) @@ -611,6 +634,13 @@ self._set_vol_object(self.vol_install.install(meter=progresscb), validate=False) return + + elif self._driverName == self.DRIVER_PHY and self._driverType: + if self._driverType == self.DRIVER_PHY_ZVOL: + size_bytes = long(self.size * 1024L * 1024L * 1024L) + if (not _zvol_create(self.path, size_bytes)): + raise RuntimeError, _("Error creating zvol %s" % self.path) + elif (self.type == VirtualDisk.TYPE_FILE and self.path is not None and not os.path.exists(self.path)): size_bytes = long(self.size * 1024L * 1024L * 1024L) @@ -619,9 +649,11 @@ progresscb.start(filename=self.path,size=long(size_bytes), \ text=_("Creating storage file...")) - if _util.is_vdisk(self.path): + if _util.is_vdisk(self.path, self._driverName): progresscb.update(1024) - if (not _vdisk_create(self.path, size_bytes, "vmdk", + if self.format is None: + self.format = "vmdk" + if (not _vdisk_create(self.path, size_bytes, self.format, self.sparse)): raise RuntimeError, _("Error creating vdisk %s" % self.path) self._driverName = self.DRIVER_TAP diff --git a/virtinst/_util.py b/virtinst/_util.py --- a/virtinst/_util.py +++ b/virtinst/_util.py @@ -34,10 +34,12 @@ from virtinst import util from virtinst import _virtinst as _ -def is_vdisk(path): +def is_vdisk(path, driver): if not os.path.exists("/usr/sbin/vdiskadm"): return False - if not os.path.exists(path): + if driver == "tap": + return True + if driver is None and not os.path.exists(path): return True if os.path.isdir(path) and \ os.path.exists(path + "/vdisk.xml"): @@ -49,7 +51,7 @@ if not os.path.exists(path): return True, 0 - if is_vdisk(path): + if is_vdisk(path, None): size = int(commands.getoutput( "vdiskadm prop-get -p max-size " + path)) return True, size From david.h.vree at gmail.com Thu May 28 13:45:26 2009 From: david.h.vree at gmail.com (David H. Vree) Date: Thu, 28 May 2009 09:45:26 -0400 Subject: [et-mgmt-tools] Importing kvm vm In-Reply-To: <20090528073209.554A7619F10@hormel.redhat.com> References: <20090528073209.554A7619F10@hormel.redhat.com> Message-ID: <4A1E9576.10908@gmail.com> > Try this for a starting point > > > > My WinXP > 2048000 > 2048000 > 2 > > hvm > > > > > > > destroy > restart > destroy > > /usr/bin/kvm > > > > > > > > > > > > Thanks a lot, that worked. For what it is worth I tried a couple different versions of virt-install and they didn't work for different reasons that have already been reported. It would be awesome if virt-manager could provide and "import" capability someday. Keep up the good work. From berrange at redhat.com Thu May 28 13:50:27 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 28 May 2009 14:50:27 +0100 Subject: [et-mgmt-tools] Importing kvm vm In-Reply-To: <4A1E9576.10908@gmail.com> References: <20090528073209.554A7619F10@hormel.redhat.com> <4A1E9576.10908@gmail.com> Message-ID: <20090528135027.GD24488@redhat.com> On Thu, May 28, 2009 at 09:45:26AM -0400, David H. Vree wrote: > > >Try this for a starting point > > > > > > > > My WinXP > > 2048000 > > 2048000 > > 2 > > > > hvm > > > > > > > > > > > > > > destroy > > restart > > destroy > > > > /usr/bin/kvm > > > > > > > > > > > > > > > > > > > > > > > > > Thanks a lot, that worked. For what it is worth I tried a couple > different versions of virt-install and they didn't work for different > reasons that have already been reported. It would be awesome if > virt-manager could provide and "import" capability someday. Keep up the > good work. The next version of libvirt will include an API and virsh command for converting from QEMU ARGV, into libvirt XML. This is what I actually used to generate the XML I gave you above - after I had fixed the bugs your example ARGV identified in our conversion code :-) Conversion of existing KVM args into XML can't be totally automatic though - it'll likely always need some manual fine tuning, so won't be wired up into virt-manager UI. virt-manager though *should* get the ability to create a new VM with its wizard, without having to go through the installer again. 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 Thu May 28 13:56:49 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 28 May 2009 09:56:49 -0400 Subject: [et-mgmt-tools] Importing kvm vm In-Reply-To: <4A1E9576.10908@gmail.com> References: <20090528073209.554A7619F10@hormel.redhat.com> <4A1E9576.10908@gmail.com> Message-ID: <4A1E9821.1020500@redhat.com> David H. Vree wrote: >> Try this for a starting point >> >> >> >> My WinXP >> 2048000 >> 2048000 >> 2 >> >> hvm >> >> >> >> >> >> >> destroy >> restart >> destroy >> >> /usr/bin/kvm >> >> >> >> >> >> >> >> >> >> >> >> > Thanks a lot, that worked. For what it is worth I tried a couple > different versions of virt-install and they didn't work for different > reasons that have already been reported. It would be awesome if > virt-manager could provide and "import" capability someday. Keep up the > good work. > An easier way to import VMs via virt-manager is on our roadmap. FYI, this could have been done fairly easily via latest virt-install (0.400.3) as well, via the --import option: virt-install --name MyWinXP --ram 2048 --vcpus 2 --accelerate --network user --sound --sdl --import --disk path=mywinxp.qcow2 - Cole From david.h.vree at gmail.com Thu May 28 14:02:01 2009 From: david.h.vree at gmail.com (David H. Vree) Date: Thu, 28 May 2009 10:02:01 -0400 Subject: [et-mgmt-tools] Importing kvm vm In-Reply-To: <4A1E9821.1020500@redhat.com> References: <20090528073209.554A7619F10@hormel.redhat.com> <4A1E9576.10908@gmail.com> <4A1E9821.1020500@redhat.com> Message-ID: <4A1E9959.5030407@gmail.com> Cole Robinson wrote: > An easier way to import VMs via virt-manager is on our roadmap. > > FYI, this could have been done fairly easily via latest virt-install > (0.400.3) as well, via the --import option: > > virt-install --name MyWinXP --ram 2048 --vcpus 2 --accelerate --network > user --sound --sdl --import --disk path=mywinxp.qcow2 > > Every time I ran virt-install v0.400.3 I got this error: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521089 From crobinso at redhat.com Thu May 28 14:10:37 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 28 May 2009 10:10:37 -0400 Subject: [et-mgmt-tools] Importing kvm vm In-Reply-To: <4A1E9959.5030407@gmail.com> References: <20090528073209.554A7619F10@hormel.redhat.com> <4A1E9576.10908@gmail.com> <4A1E9821.1020500@redhat.com> <4A1E9959.5030407@gmail.com> Message-ID: <4A1E9B5D.5050103@redhat.com> David H. Vree wrote: > > Cole Robinson wrote: >> An easier way to import VMs via virt-manager is on our roadmap. >> >> FYI, this could have been done fairly easily via latest virt-install >> (0.400.3) as well, via the --import option: >> >> virt-install --name MyWinXP --ram 2048 --vcpus 2 --accelerate --network >> user --sound --sdl --import --disk path=mywinxp.qcow2 >> >> > Every time I ran virt-install v0.400.3 I got this error: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521089 > Hmm, looks like a distro specific bug: the offending code has never been upstream. It sounds like it is fixed in debian though, so not sure why you are still hitting it. If you are using ubuntu, I'd file a bug with them. In the meantime, the fix should be as simple as running: sudo sed -i -e "s/options.os_variant/options.distro_variant/g" /usr/bin/virt-install - Cole From jliu at liquidnet.com Thu May 28 14:18:16 2009 From: jliu at liquidnet.com (Jeff Liu) Date: Thu, 28 May 2009 10:18:16 -0400 Subject: [et-mgmt-tools] func rpms returns NULL In-Reply-To: <4A1E9B5D.5050103@redhat.com> References: <20090528073209.554A7619F10@hormel.redhat.com> <4A1E9576.10908@gmail.com> <4A1E9821.1020500@redhat.com> <4A1E9959.5030407@gmail.com> <4A1E9B5D.5050103@redhat.com> Message-ID: <26AA63832ED7774DBFB9FFB39B337C00A1254B72@nj0cech03.lnholdings.com> Just wondering if anyone can help. I'm relatively new to func, and I'm attempting to gather rpm inventory. I'm calling func's rpm module, but it's not returning any values. The target minion is running CentOS 5.2. func nj1qmlt01 call rpms inventory {'nj1qmlt01': []} I've checked /var/log/func/func.log on both the overlord and the minion, but there are no errors. I'm not sure how to turn up the debugging level. Any help would be greatly appreciated. Thanks in advance, Jeff