From shemminger at vyatta.com Sun Feb 1 05:29:09 2009 From: shemminger at vyatta.com (Stephen Hemminger) Date: Sat, 31 Jan 2009 21:29:09 -0800 Subject: [et-mgmt-tools] Re: virt-manager broken by bind(0) in net-next. In-Reply-To: <498349F7.4050300@cosmosbay.com> References: <20090130112125.GA9908@ioremap.net> <20090130125337.GA7155@gondor.apana.org.au> <20090130095737.103edbff@extreme> <498349F7.4050300@cosmosbay.com> Message-ID: <20090131212909.3ce7a28a@extreme> On Fri, 30 Jan 2009 19:41:59 +0100 Eric Dumazet wrote: > Stephen Hemminger a ?crit : > > On Fri, 30 Jan 2009 23:53:37 +1100 > > Herbert Xu wrote: > > > >> Evgeniy Polyakov wrote: > >>> So it is not explicit bind call, but port autoselection in the > >>> connect(). Can you check what errno is returned? > >>> Did I understand it right, that connect fails, you try different > >>> address, but then suddenly all those sockets become 'alive'? > >> Yes, I think a good strace vs. a bad strace would be really helpful > >> in these cases. > >> > >> Thanks, > > > > I have the strace but it comes up no different. > > What is different is that in the broken case (net-next), I see > > IPV6 being used: > > > > State Recv-Q Send-Q Local Address:Port Peer Address:Port > > ESTAB 23769 0 ::ffff:127.0.0.1:5900 ::ffff:127.0.0.1:55987 > > ESTAB 0 0 127.0.0.1:55987 127.0.0.1:5900 > > > > and in the working case (2.6.29-rc3), IPV4 is being used > > State Recv-Q Send-Q Local Address:Port Peer Address:Port > > ESTAB 0 0 127.0.0.1:58894 127.0.0.1:5901 > > ESTAB 0 0 127.0.0.1:5901 127.0.0.1:58894 > > > > Reviewing commit a9d8f9110d7e953c2f2b521087a4179677843c2a > > I see use of a hashinfo->bsockets field that : > > - lacks proper lock/synchronization > - suffers from cache line ping pongs on SMP > > Also there might be a problem at line 175 > > if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { > spin_unlock(&head->lock); > goto again; > > If we entered inet_csk_get_port() with a non null snum, we can "goto again" > while it was not expected. > > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c > index df8e72f..752c6b2 100644 > --- a/net/ipv4/inet_connection_sock.c > +++ b/net/ipv4/inet_connection_sock.c > @@ -172,7 +172,8 @@ tb_found: > } else { > ret = 1; > if (inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb)) { > - if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { > + if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && > + smallest_size == -1 && --attempts >= 0) { > spin_unlock(&head->lock); > goto again; > } > > That didn't fix it. From shemminger at vyatta.com Sun Feb 1 05:58:50 2009 From: shemminger at vyatta.com (Stephen Hemminger) Date: Sat, 31 Jan 2009 21:58:50 -0800 Subject: [et-mgmt-tools] Re: virt-manager broken by bind(0) in net-next. In-Reply-To: <20090130215008.GB12210@ioremap.net> References: <20090130112125.GA9908@ioremap.net> <20090130125337.GA7155@gondor.apana.org.au> <20090130095737.103edbff@extreme> <498349F7.4050300@cosmosbay.com> <20090130215008.GB12210@ioremap.net> Message-ID: <20090131215850.3dfc29fb@extreme> On Sat, 31 Jan 2009 00:50:08 +0300 Evgeniy Polyakov wrote: > On Fri, Jan 30, 2009 at 07:41:59PM +0100, Eric Dumazet (dada1 at cosmosbay.com) wrote: > > Reviewing commit a9d8f9110d7e953c2f2b521087a4179677843c2a > > > > I see use of a hashinfo->bsockets field that : > > > > - lacks proper lock/synchronization > > It should contain rough number of sockets, there is no need to be very > precise because of this hueristic. > > > - suffers from cache line ping pongs on SMP > > I used free alignment slot so that socket structure would not be > icreased. > > > Also there might be a problem at line 175 > > > > if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { > > spin_unlock(&head->lock); > > goto again; > > > > If we entered inet_csk_get_port() with a non null snum, we can "goto again" > > while it was not expected. > > > > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c > > index df8e72f..752c6b2 100644 > > --- a/net/ipv4/inet_connection_sock.c > > +++ b/net/ipv4/inet_connection_sock.c > > @@ -172,7 +172,8 @@ tb_found: > > } else { > > ret = 1; > > if (inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb)) { > > - if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { > > + if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && > > + smallest_size == -1 && --attempts >= 0) { > > I think it should be smallest_size != -1, since we really want to goto > to the again label when hueristic is used, which in turn changes > smallest_size. > Yes, this fixes the problem, not sure who wants the honors for sending a signed off version. --- a/net/ipv4/inet_connection_sock.c 2009-01-31 21:18:45.433239861 -0800 +++ b/net/ipv4/inet_connection_sock.c 2009-01-31 21:30:14.720825414 -0800 @@ -172,7 +172,8 @@ tb_found: } else { ret = 1; if (inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb)) { - if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { + if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && + smallest_size != -1 && --attempts >= 0) { spin_unlock(&head->lock); goto again; } From john.levon at sun.com Wed Feb 4 22:23:31 2009 From: john.levon at sun.com (john.levon at sun.com) Date: Wed, 04 Feb 2009 14:23:31 -0800 Subject: [et-mgmt-tools] [PATCH] Clean up help message for --livecd Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1233786168 28800 # Node ID b56aabae9044c5390c7d51c0f468302b5bacf376 # Parent 446816fe543fdb43d991d4b8fae0e14a155d1c26 Clean up help message for --livecd Signed-off-by: John Levon diff --git a/virt-install b/virt-install --- a/virt-install +++ b/virt-install @@ -389,7 +389,7 @@ def parse_args(): insg.add_option("", "--pxe", action="store_true", dest="pxe", help=_("Boot from the network using the PXE protocol")) insg.add_option("", "--livecd", action="store_true", dest="livecd", - help=_("Treat the CDROM media is a LiveCD")) + help=_("Treat the CD-ROM media as a Live CD")) insg.add_option("-x", "--extra-args", type="string", dest="extra", default="", help=_("Additional arguments to pass to the kernel " From sakaia at jp.fujitsu.com Thu Feb 5 05:45:12 2009 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Thu, 05 Feb 2009 14:45:12 +0900 Subject: [et-mgmt-tools] Question about virt-viewer connection when guest reboots Message-ID: <20090205054513.A4B0418064@m021.s.css.fujitsu.com> Hi, I have a question about virt-viewer connection when guest reboots. As you know, when guest reboots, virt-viewer destroyed. Is there any way to keep virt-viewer running over guest reboots? Thanks Atsushi SAKAI From berrange at redhat.com Thu Feb 5 11:03:35 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Feb 2009 11:03:35 +0000 Subject: [et-mgmt-tools] Question about virt-viewer connection when guest reboots In-Reply-To: <20090205054513.A4B0418064@m021.s.css.fujitsu.com> References: <20090205054513.A4B0418064@m021.s.css.fujitsu.com> Message-ID: <20090205110335.GE2759@redhat.com> On Thu, Feb 05, 2009 at 02:45:12PM +0900, Atsushi SAKAI wrote: > Hi, > > I have a question about virt-viewer connection when guest reboots. > As you know, when guest reboots, virt-viewer destroyed. > > Is there any way to keep virt-viewer running over guest reboots? The current unreleased code in the repository supports waiting for the guest to start up again. I've got a few more things to fix in that before release, but it'll be in Fedora 11 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 john.levon at sun.com Thu Feb 5 19:20:15 2009 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 05 Feb 2009 11:20:15 -0800 Subject: [et-mgmt-tools] [PATCH] Default --wait to 120 minutes for Windows Message-ID: # HG changeset patch # User john.levon at sun.com # Date 1233861322 28800 # Node ID e72836e9f581e0761ba9ed3253397b1b51affc7e # Parent 7c38f808054c83211e428178baa4dda597815ba0 Default --wait to 120 minutes for Windows If we're installing a Windows guest, it will reboot during the installation. Default to waiting in this case so virt-install is still around to manage the reboot. Signed-off-by: John Levon diff --git a/virt-install b/virt-install --- a/virt-install +++ b/virt-install @@ -620,18 +620,26 @@ def main(): else: return txt_console(dom, options.connect) - wait = False - wait_time = 0 + # There are two main cases we care about: + # + # Scripts: these should specify --wait always, maintaining the + # semantics of virt-install exit implying the domain has finished + # installing. + # + # Interactive: If this is a continue_inst domain, we default to + # waiting. Otherwise, we can exit before the domain has finished + # installing. Passing --wait will give the above semantics. + # + wait = continue_inst + wait_time = 120 * 60 + if options.wait: wait = True wait_time = options.wait * 60 - if wait is True and wait_time == 0: - # wait == 0 implies noautoconsole - options.autoconsole = False - if options.autoconsole is False: conscb = None + wait = False else: conscb = show_console @@ -678,7 +686,7 @@ def main(): ((wait_time > 0) and (_(" %d minutes") % (int(wait_time) / 60)) or "") + \ - " for domain to shutdown.") + " for domain to complete installation.") while True: if domain_is_shutdown(dom): print _("Domain has shutdown. Continuing.") From john.levon at sun.com Thu Feb 5 19:21:40 2009 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 05 Feb 2009 11:21:40 -0800 Subject: [et-mgmt-tools] [PATCH] Kill console process if control-C is pressed Message-ID: <43ef4509832aea50d481.1233861700@xenbld.SFBay.Sun.COM> # HG changeset patch # User john.levon at sun.com # Date 1233790091 28800 # Node ID 43ef4509832aea50d4812aa33fa46a1f650c196d # Parent 507b2f948f3b1f4a1a844493e4de67a1f8938f6c Kill console process if control-C is pressed Signed-off-by: John Levon diff --git a/virt-install b/virt-install --- a/virt-install +++ b/virt-install @@ -709,6 +709,9 @@ def main(): print _("Guest installation complete... restarting guest.") dom.create() guest.connect_console(conscb) + except KeyboardInterrupt, e: + guest.terminate_console() + print _("Guest install interrupted.") except RuntimeError, e: fail(e) except SystemExit, e: diff --git a/virtinst/Guest.py b/virtinst/Guest.py --- a/virtinst/Guest.py +++ b/virtinst/Guest.py @@ -36,8 +36,8 @@ import osdict import osdict from VirtualDisk import VirtualDisk from virtinst import _virtinst as _ - import logging +import signal XEN_SCRATCH="/var/lib/xen" LIBVIRT_SCRATCH="/var/lib/libvirt/boot" @@ -550,6 +550,7 @@ class Guest(object): self._vcpus = None self._cpuset = None self._graphics_dev = None + self._consolechild = None self._os_type = None self._os_variant = None @@ -940,6 +941,7 @@ class Guest(object): wait=True): """Do the startup of the guest installation.""" self.validate_parms() + self._consolechild = None if meter is None: # BaseMeter does nothing, but saves a lot of null checking @@ -1002,6 +1004,7 @@ class Guest(object): if consolecb: logging.debug("Launching console callback") child = consolecb(self.domain) + self._consolechild = child boot_xml = self.get_config_xml(install = False) logging.debug("Saving XML boot config:\n%s" % boot_xml) @@ -1038,6 +1041,7 @@ class Guest(object): if consolecb: logging.debug("Launching console callback") child = consolecb(self.domain) + self._consolechild = child if child and wait: # if we connected the console, wait for it to finish try: @@ -1102,6 +1106,10 @@ class Guest(object): raise RuntimeError(_("Invalid dictionary entry for device '%s %s'" % \ (device_key, param))) + def terminate_console(self): + if self._consolechild: + os.kill(self._consolechild, signal.SIGKILL) + def _wait_for_domain(conn, name): # sleep in .25 second increments until either a) we get running # domain ID or b) it's been 5 seconds. this is so that From berrange at redhat.com Thu Feb 5 20:12:58 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Feb 2009 20:12:58 +0000 Subject: [et-mgmt-tools] [PATCH] Default --wait to 120 minutes for Windows In-Reply-To: References: Message-ID: <20090205201258.GA574@redhat.com> On Thu, Feb 05, 2009 at 11:20:15AM -0800, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1233861322 28800 > # Node ID e72836e9f581e0761ba9ed3253397b1b51affc7e > # Parent 7c38f808054c83211e428178baa4dda597815ba0 > Default --wait to 120 minutes for Windows > > If we're installing a Windows guest, it will reboot during the > installation. Default to waiting in this case so virt-install is still > around to manage the reboot. Shouldn't we even just wait forever in this case ? That's kind of what the 'continue' flag was intended to mean IIRC. Dainiel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Thu Feb 5 20:15:20 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Feb 2009 20:15:20 +0000 Subject: [et-mgmt-tools] [PATCH] Kill console process if control-C is pressed In-Reply-To: <43ef4509832aea50d481.1233861700@xenbld.SFBay.Sun.COM> References: <43ef4509832aea50d481.1233861700@xenbld.SFBay.Sun.COM> Message-ID: <20090205201520.GB574@redhat.com> On Thu, Feb 05, 2009 at 11:21:40AM -0800, john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1233790091 28800 > # Node ID 43ef4509832aea50d4812aa33fa46a1f650c196d > # Parent 507b2f948f3b1f4a1a844493e4de67a1f8938f6c > Kill console process if control-C is pressed We don't want to kill the console if it is a text mode console installer, because we should have ability to trigger a Ctrl-C in the guest OS/console itself. eg, if doing a Fedora install and you swiched Alt+F2 to the anaconda shell, you need to be able to Ctrl+C shell commands there If we spawned the graphical (virt-viewer) console, then handling Ctrl+C is fine. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From levon at movementarian.org Thu Feb 5 21:46:05 2009 From: levon at movementarian.org (John Levon) Date: Thu, 5 Feb 2009 16:46:05 -0500 Subject: [et-mgmt-tools] [PATCH] Default --wait to 120 minutes for Windows In-Reply-To: <20090205201258.GA574@redhat.com> References: <20090205201258.GA574@redhat.com> Message-ID: <20090205214605.GB13609@movementarian.org> On Thu, Feb 05, 2009 at 08:12:58PM +0000, Daniel P. Berrange wrote: > > Default --wait to 120 minutes for Windows > > > > If we're installing a Windows guest, it will reboot during the > > installation. Default to waiting in this case so virt-install is still > > around to manage the reboot. > > Shouldn't we even just wait forever in this case ? That's kind > of what the 'continue' flag was intended to mean IIRC. That'd be fine by me, Cole? regards john From levon at movementarian.org Thu Feb 5 21:47:00 2009 From: levon at movementarian.org (John Levon) Date: Thu, 5 Feb 2009 16:47:00 -0500 Subject: [et-mgmt-tools] [PATCH] Kill console process if control-C is pressed In-Reply-To: <20090205201520.GB574@redhat.com> References: <43ef4509832aea50d481.1233861700@xenbld.SFBay.Sun.COM> <20090205201520.GB574@redhat.com> Message-ID: <20090205214700.GC13609@movementarian.org> On Thu, Feb 05, 2009 at 08:15:20PM +0000, Daniel P. Berrange wrote: > > Kill console process if control-C is pressed > > We don't want to kill the console if it is a text mode console > installer, because we should have ability to trigger a Ctrl-C in > the guest OS/console itself. eg, if doing a Fedora install and If it's text mode installer, then virt-install won't even see the control-C, right? regards john From fabian-buettner at gmx.de Thu Feb 5 22:33:31 2009 From: fabian-buettner at gmx.de (=?utf-8?Q?Fabian_B=C3=BCttner?=) Date: Thu, 05 Feb 2009 23:33:31 +0100 Subject: [et-mgmt-tools] heya, Message-ID: I am new here to this mailing list and wanted to ask if there's something like a plasmoid for kde 4 in the makings? regards, fab From berrange at redhat.com Fri Feb 6 10:38:08 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 6 Feb 2009 10:38:08 +0000 Subject: [et-mgmt-tools] [PATCH] Kill console process if control-C is pressed In-Reply-To: <20090205214700.GC13609@movementarian.org> References: <43ef4509832aea50d481.1233861700@xenbld.SFBay.Sun.COM> <20090205201520.GB574@redhat.com> <20090205214700.GC13609@movementarian.org> Message-ID: <20090206103808.GA18504@redhat.com> On Thu, Feb 05, 2009 at 04:47:00PM -0500, John Levon wrote: > On Thu, Feb 05, 2009 at 08:15:20PM +0000, Daniel P. Berrange wrote: > > > > Kill console process if control-C is pressed > > > > We don't want to kill the console if it is a text mode console > > installer, because we should have ability to trigger a Ctrl-C in > > the guest OS/console itself. eg, if doing a Fedora install and > > If it's text mode installer, then virt-install won't even see the > control-C, right? Oh, actually that's probably right. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Fri Feb 6 17:00:03 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 06 Feb 2009 12:00:03 -0500 Subject: [et-mgmt-tools] Re: [libvirt] storage error In-Reply-To: <498C09CC.9040800@lfarkas.org> References: <498C09CC.9040800@lfarkas.org> Message-ID: <498C6C93.9090808@redhat.com> Farkas Levente wrote: Moving to et-mgmt-tools. > hi, > first of all i don't know which is the right list for this. since it's > created by virt-manager, but the error says libvirtError. > anyway another error during a new guest install. > ------------------------------------------- > [Fri, 06 Feb 2009 10:54:14 virt-manager 32039] DEBUG (error:76) Uncaught > Error: Uncaught error validating input: cannot open volume > '/var/lib/libvirt/images/fedora-i386.img': No such file or directory : Trac > eback (most recent call last): > File "/usr/share/virt-manager/virtManager/create.py", line 301, in forward > if(self.validate(notebook.get_current_page()) != True): > File "/usr/share/virt-manager/virtManager/create.py", line 1004, in > validate > conn=self._guest.conn) > File "/usr/lib/python2.4/site-packages/virtinst/VirtualDisk.py", line > 166, in __init__ > self.__validate_params() > File "/usr/lib/python2.4/site-packages/virtinst/VirtualDisk.py", line > 492, in __validate_params > self.__set_dev_type() > File "/usr/lib/python2.4/site-packages/virtinst/VirtualDisk.py", line > 290, in __set_dev_type > t = self.vol_object.info()[0] > File "/usr/lib64/python2.4/site-packages/libvirt.py", line 947, in info > if ret is None: raise libvirtError ('virStorageVolGetInfo() failed', > vol=self) > libvirtError: cannot open volume > '/var/lib/libvirt/images/fedora-i386.img': No such file or directory > ------------------------------------------- > the current situation i'm not able to install any new guests:-( > Can you attach: ~/.virt-manager/virt-manager.log output of 'virsh pool-list --all' output of 'virsh vol-list default' All after a failure like the above. Also, what distro are you using? Thanks, Cole From crobinso at redhat.com Fri Feb 6 18:50:48 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 06 Feb 2009 13:50:48 -0500 Subject: [et-mgmt-tools] [PATCH] Default --wait to 120 minutes for Windows In-Reply-To: References: Message-ID: <498C8688.2020401@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1233861322 28800 > # Node ID e72836e9f581e0761ba9ed3253397b1b51affc7e > # Parent 7c38f808054c83211e428178baa4dda597815ba0 > Default --wait to 120 minutes for Windows > > If we're installing a Windows guest, it will reboot during the > installation. Default to waiting in this case so virt-install is still > around to manage the reboot. > > Signed-off-by: John Levon > > diff --git a/virt-install b/virt-install > --- a/virt-install > +++ b/virt-install > @@ -620,18 +620,26 @@ def main(): > else: > return txt_console(dom, options.connect) > > - wait = False > - wait_time = 0 > + # There are two main cases we care about: > + # > + # Scripts: these should specify --wait always, maintaining the > + # semantics of virt-install exit implying the domain has finished > + # installing. > + # > + # Interactive: If this is a continue_inst domain, we default to > + # waiting. Otherwise, we can exit before the domain has finished > + # installing. Passing --wait will give the above semantics. > + # > + wait = continue_inst > + wait_time = 120 * 60 > + Making this 'wait indefinitely' is fine by me. > if options.wait: > wait = True > wait_time = options.wait * 60 > > - if wait is True and wait_time == 0: > - # wait == 0 implies noautoconsole > - options.autoconsole = False > - > if options.autoconsole is False: > conscb = None > + wait = False I don't think the above line is correct. 'wait 0' is supposed to be equivalent to 'noautoconsole', but 'noautoconsole' shouldn't disable any explicit wait value. Though currently wait 0 still throws a console up (which is a bug: 'if options.wait' should be 'if options.wait == None'). Aside from that, the patch looks good. Thanks, Cole From crobinso at redhat.com Fri Feb 6 18:54:06 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 06 Feb 2009 13:54:06 -0500 Subject: [et-mgmt-tools] [PATCH] Clean up help message for --livecd In-Reply-To: References: Message-ID: <498C874E.4080700@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1233786168 28800 > # Node ID b56aabae9044c5390c7d51c0f468302b5bacf376 > # Parent 446816fe543fdb43d991d4b8fae0e14a155d1c26 > Clean up help message for --livecd > > Signed-off-by: John Levon Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/5c35b7e74947 - Cole From crobinso at redhat.com Fri Feb 6 18:57:41 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 06 Feb 2009 13:57:41 -0500 Subject: [et-mgmt-tools] [PATCH] Default --wait to 120 minutes for Windows In-Reply-To: <498C8688.2020401@redhat.com> References: <498C8688.2020401@redhat.com> Message-ID: <498C8825.20307@redhat.com> Cole Robinson wrote: > john.levon at sun.com wrote: >> # HG changeset patch >> # User john.levon at sun.com >> # Date 1233861322 28800 >> # Node ID e72836e9f581e0761ba9ed3253397b1b51affc7e >> # Parent 7c38f808054c83211e428178baa4dda597815ba0 >> Default --wait to 120 minutes for Windows >> >> If we're installing a Windows guest, it will reboot during the >> installation. Default to waiting in this case so virt-install is still >> around to manage the reboot. >> >> Signed-off-by: John Levon >> >> diff --git a/virt-install b/virt-install >> --- a/virt-install >> +++ b/virt-install >> @@ -620,18 +620,26 @@ def main(): >> else: >> return txt_console(dom, options.connect) >> >> - wait = False >> - wait_time = 0 >> + # There are two main cases we care about: >> + # >> + # Scripts: these should specify --wait always, maintaining the >> + # semantics of virt-install exit implying the domain has finished >> + # installing. >> + # >> + # Interactive: If this is a continue_inst domain, we default to >> + # waiting. Otherwise, we can exit before the domain has finished >> + # installing. Passing --wait will give the above semantics. >> + # >> + wait = continue_inst >> + wait_time = 120 * 60 >> + > > Making this 'wait indefinitely' is fine by me. > >> if options.wait: >> wait = True >> wait_time = options.wait * 60 >> >> - if wait is True and wait_time == 0: >> - # wait == 0 implies noautoconsole >> - options.autoconsole = False >> - >> if options.autoconsole is False: >> conscb = None >> + wait = False > > I don't think the above line is correct. 'wait 0' is supposed to be > equivalent to 'noautoconsole', but 'noautoconsole' shouldn't disable any > explicit wait value. > > Though currently wait 0 still throws a console up (which is a bug: 'if > options.wait' should be 'if options.wait == None'). > > Aside from that, the patch looks good. > Oops, I just accidentally applied a version with the indefinite wait, but not the autoconsole change. If you agree with the above, I'll just commit the fix for it. Thanks, Cole From crobinso at redhat.com Fri Feb 6 18:58:03 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 06 Feb 2009 13:58:03 -0500 Subject: [et-mgmt-tools] [PATCH] Kill console process if control-C is pressed In-Reply-To: <43ef4509832aea50d481.1233861700@xenbld.SFBay.Sun.COM> References: <43ef4509832aea50d481.1233861700@xenbld.SFBay.Sun.COM> Message-ID: <498C883B.8050304@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User john.levon at sun.com > # Date 1233790091 28800 > # Node ID 43ef4509832aea50d4812aa33fa46a1f650c196d > # Parent 507b2f948f3b1f4a1a844493e4de67a1f8938f6c > Kill console process if control-C is pressed > Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/f9800a2a6a89 - Cole From crobinso at redhat.com Fri Feb 6 19:14:09 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 06 Feb 2009 14:14:09 -0500 Subject: [et-mgmt-tools] don't show ui dialogs in construction time In-Reply-To: References: Message-ID: <498C8C01.6030602@redhat.com> Vitaly Mayatskikh wrote: > Hi! > > There are calls to hide_all() method after construction of vmm-manager > and vmm-details dialogs to prevent possible flickering during > appending more elements to these dialogs. However, it is possible to > declare visibility property in xml files and to prevent libglade to > show dialogs automatically. > Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/f9c2636a8a32 - Cole From radek at eadresa.cz Fri Feb 6 19:37:58 2009 From: radek at eadresa.cz (Radek Hladik) Date: Fri, 06 Feb 2009 20:37:58 +0100 Subject: [et-mgmt-tools] Virt-manager and qemu logging Message-ID: <498C9196.5050200@eadresa.cz> Hi, I am using virt-manager+libvirt+kvmqemu and I noticed today that when virt-manager is running and polling VMs stats libvirt log in /var/log/libivrt/qemu/vmname is filling with messages like info blockstats ide0-hd0: rd_bytes=16710828032 wr_bytes=2248787148 8 rd_operations=382576 wr_oper ations=1579878 ide1-cd0: rd_bytes=936448 wr_bytes=0 rd_operations=456 wr_operations=0 floppy0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 sd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 is this needed for virt-manager to poll the info or have I only forgotten to disable some debugging somewhere? I tried to change loging parameter in libvirt.conf but that had no effect (I didnt restart the VMs though). Radek P.S. kvm-83-2.fc11.x86_64 libvirt-0.6.0-1.fc11.x86_64 virt-manager-0.6.1-1.fc11.x86_64 qemu-0.9.1-12.fc11.x86_64 From crobinso at redhat.com Fri Feb 6 19:43:48 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 06 Feb 2009 14:43:48 -0500 Subject: [et-mgmt-tools] Virt-manager and qemu logging In-Reply-To: <498C9196.5050200@eadresa.cz> References: <498C9196.5050200@eadresa.cz> Message-ID: <498C92F4.8050106@redhat.com> Radek Hladik wrote: > Hi, > I am using virt-manager+libvirt+kvmqemu and I noticed today that when > virt-manager is running and polling VMs stats libvirt log in > /var/log/libivrt/qemu/vmname is filling with messages like > > info blockstats > ide0-hd0: rd_bytes=16710828032 > wr_bytes=2248787148 8 rd_operations=382576 > wr_oper > ations=1579878 > ide1-cd0: rd_bytes=936448 wr_bytes=0 rd_operations=456 wr_operations=0 > floppy0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 > sd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 > > > is this needed for virt-manager to poll the info or have I only > forgotten to disable some debugging somewhere? I tried to change loging > parameter in libvirt.conf but that had no effect (I didnt restart the > VMs though). > If disk polling is enabled in virt-manager, those messages will be logged by libvirt. They are coming from the qemu monitor every time disk stats info is requested. As far as I know there is no way to disable logging these messages, though it would certainly be handy since they will quickly take up a lot of room if virt-manager is left running. You can disable disk polling in virt-manager via Edit->Preferences - Cole From berrange at redhat.com Fri Feb 6 19:50:53 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 6 Feb 2009 19:50:53 +0000 Subject: [et-mgmt-tools] Virt-manager and qemu logging In-Reply-To: <498C9196.5050200@eadresa.cz> References: <498C9196.5050200@eadresa.cz> Message-ID: <20090206195053.GA7528@redhat.com> On Fri, Feb 06, 2009 at 08:37:58PM +0100, Radek Hladik wrote: > Hi, > I am using virt-manager+libvirt+kvmqemu and I noticed today that > when virt-manager is running and polling VMs stats libvirt log in > /var/log/libivrt/qemu/vmname is filling with messages like > > info blockstats > ide0-hd0: rd_bytes=16710828032 > wr_bytes=2248787148 8 rd_operations=382576 > wr_oper > ations=1579878 > ide1-cd0: rd_bytes=936448 wr_bytes=0 rd_operations=456 wr_operations=0 > floppy0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 > sd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 > > > is this needed for virt-manager to poll the info or have I only > forgotten to disable some debugging somewhere? I tried to change loging > parameter in libvirt.conf but that had no effect (I didnt restart the > VMs though). It is not really virt-manager's fault - its just monitoring disk & net I/O stats. The problem is libvirt logging every single monitor command it runs to that file. This needs to be removed, and replaced with calls to VIR_DEBUG() which is a logging API that's disabled by default 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 radek at eadresa.cz Fri Feb 6 20:44:32 2009 From: radek at eadresa.cz (Radek Hladik) Date: Fri, 06 Feb 2009 21:44:32 +0100 Subject: [et-mgmt-tools] Virt-manager and qemu logging In-Reply-To: <498C92F4.8050106@redhat.com> References: <498C9196.5050200@eadresa.cz> <498C92F4.8050106@redhat.com> Message-ID: <498CA130.4060008@eadresa.cz> Cole Robinson napsal(a): > Radek Hladik wrote: >> Hi, >> I am using virt-manager+libvirt+kvmqemu and I noticed today that when >> virt-manager is running and polling VMs stats libvirt log in >> /var/log/libivrt/qemu/vmname is filling with messages like >> >> info blockstats >> ide0-hd0: rd_bytes=16710828032 >> wr_bytes=2248787148 8 rd_operations=382576 >> wr_oper >> ations=1579878 >> ide1-cd0: rd_bytes=936448 wr_bytes=0 rd_operations=456 wr_operations=0 >> floppy0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 >> sd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 >> >> >> is this needed for virt-manager to poll the info or have I only >> forgotten to disable some debugging somewhere? I tried to change loging >> parameter in libvirt.conf but that had no effect (I didnt restart the >> VMs though). >> > > If disk polling is enabled in virt-manager, those messages will be > logged by libvirt. They are coming from the qemu monitor every time disk > stats info is requested. As far as I know there is no way to disable > logging these messages, though it would certainly be handy since they > will quickly take up a lot of room if virt-manager is left running. > > You can disable disk polling in virt-manager via Edit->Preferences > > - Cole I left virt-manager running for about a day and it grew to cca 100MB per VM. I will probably set up more drastic rotation or disable the logging at all somehow... Thanks for your answer. Radek From agx at sigxcpu.org Sat Feb 7 20:34:06 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 7 Feb 2009 21:34:06 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: remove disambiguity in "free space" dialog Message-ID: <20090207203406.GA18598@bogon.ms20.nix> Hi, the dialog explaining that there's not enough free space for the device available leaves a "yes/no" choice without giving a hint what is being chosen. Possible fix attached. This Debian Bug: http://bugs.debian.org/514324 Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: yes_no.diff Type: text/x-diff Size: 1068 bytes Desc: not available URL: From agx at sigxcpu.org Sat Feb 7 22:56:31 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 7 Feb 2009 23:56:31 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: don't drop .local for zeroconf Message-ID: <20090207225631.GA6830@bogon.ms20.nix> Hi, we currently drop ".local" from zeroconf hostnames leading to name lookup failures. I wonder why this is being done in the first place? Attached patch removes it which makes libvirt daemons discovered via avahi work for me. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: dont-drop-.local.patch Type: text/x-diff Size: 472 bytes Desc: not available URL: From markmc at redhat.com Mon Feb 9 08:21:29 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 09 Feb 2009 08:21:29 +0000 Subject: [et-mgmt-tools] [PATCH] virt-manager: remove disambiguity in "free space" dialog In-Reply-To: <20090207203406.GA18598@bogon.ms20.nix> References: <20090207203406.GA18598@bogon.ms20.nix> Message-ID: <1234167689.13728.7.camel@blaa> Hi Guido, On Sat, 2009-02-07 at 21:34 +0100, Guido G?nther wrote: > - res = self.err.yes_no(_("Not Enough Free Space"), ret[1]) > + res = self.err.yes_no(_("Not Enough Free Space"), _("%s. Continue anyway?") % ret[1]) > if not res: > return False See the GNOME HIG: http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#alert-button-order I think what you want here is to change the buttons to Cancel/Continue - i.e. a Cancel button and an affirmative verb button. Cheers, Mark. From levon at movementarian.org Mon Feb 9 13:37:32 2009 From: levon at movementarian.org (John Levon) Date: Mon, 9 Feb 2009 08:37:32 -0500 Subject: [et-mgmt-tools] [PATCH] Default --wait to 120 minutes for Windows In-Reply-To: <498C8688.2020401@redhat.com> References: <498C8688.2020401@redhat.com> Message-ID: <20090209133732.GA25903@movementarian.org> On Fri, Feb 06, 2009 at 01:50:48PM -0500, Cole Robinson wrote: > > if options.autoconsole is False: > > conscb = None > > + wait = False > > I don't think the above line is correct. 'wait 0' is supposed to be > equivalent to 'noautoconsole', but 'noautoconsole' shouldn't disable any > explicit wait value. Yes, this bit is wrong, I'm not sure how it got into the patch to be honest :) thanks john From crobinso at redhat.com Mon Feb 9 14:39:50 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 09 Feb 2009 09:39:50 -0500 Subject: [et-mgmt-tools] [PATCH] Default --wait to 120 minutes for Windows In-Reply-To: <20090209133732.GA25903@movementarian.org> References: <498C8688.2020401@redhat.com> <20090209133732.GA25903@movementarian.org> Message-ID: <49904036.7030003@redhat.com> John Levon wrote: > On Fri, Feb 06, 2009 at 01:50:48PM -0500, Cole Robinson wrote: > >>> if options.autoconsole is False: >>> conscb = None >>> + wait = False >> I don't think the above line is correct. 'wait 0' is supposed to be >> equivalent to 'noautoconsole', but 'noautoconsole' shouldn't disable any >> explicit wait value. > > Yes, this bit is wrong, I'm not sure how it got into the patch to be > honest :) > Okay, fixed now. Thanks, Cole From crobinso at redhat.com Mon Feb 9 14:58:55 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 09 Feb 2009 09:58:55 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: don't drop .local for zeroconf In-Reply-To: <20090207225631.GA6830@bogon.ms20.nix> References: <20090207225631.GA6830@bogon.ms20.nix> Message-ID: <499044AF.6000009@redhat.com> Guido G?nther wrote: > Hi, > we currently drop ".local" from zeroconf hostnames leading to name > lookup failures. I wonder why this is being done in the first place? > Attached patch removes it which makes libvirt daemons discovered via > avahi work for me. > Cheers, > -- Guido > > Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/1144683a4413 I'm pretty sure the first round of patches for the avahi support was using the hostname as the list entry, and I was dropping '.local' since it seemed like extraneous info (stripping it doesn't cause problems here). Clearly I was wrong though :) Thanks, Cole From crobinso at redhat.com Mon Feb 9 20:08:32 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 09 Feb 2009 15:08:32 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: merge VM 'Overview' with hardware list Message-ID: <49908D40.8040405@redhat.com> Hi all, The attached patch breaks out the info in the VM 'Overview' tab into list entries in the VM hardware list. Two entries are added: an 'Overview' entry (containing name, UUID, and current state), and a 'Performance' entry (containing all the VM stats graphs). The hardware tab is renamed to 'Details' since it encompasses a bit more info now. Some screenshots: http://crobinso.fedorapeople.org/virt-manager/vmm-overview-merge1.png http://crobinso.fedorapeople.org/virt-manager/vmm-overview-merge2.png The patch actually just shows the code change. I left out the 4000+ glade diff since it is largely mechanical and not worth reviewing directly. Any comments appreciated. Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-overview-merge.patch Type: text/x-patch Size: 5031 bytes Desc: not available URL: From crobinso at redhat.com Mon Feb 9 22:04:36 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 09 Feb 2009 17:04:36 -0500 Subject: [et-mgmt-tools] FYI: Some virtinst code reorganization Message-ID: <4990A874.1030003@redhat.com> Hi all, Just a heads up that I committed some changes to virtinst that reorganize the code a bit, breaking some classes out into their own files. The changes are: >From Guest.py: Break out VirtualAudio to VirtualAudio.py Break out VirtualGraphics to VirtualGraphics.py Break out VirtualNetworkInterface to VirtualNetworkInterface.py Break out Installer to Installer.py >From DistroManager.py: Break out PXEInstaller to PXEInstaller.py Move distro fetch helpers to OSDistro Rename DistroManager.py to DistroInstaller.py Hopefully it doesn't cause any headaches. It's immediately nicer when trying to alter the bigger classes like Guest, Installer, and DistroInstaller. Thanks, Cole From levon at movementarian.org Tue Feb 10 02:45:17 2009 From: levon at movementarian.org (John Levon) Date: Mon, 9 Feb 2009 21:45:17 -0500 Subject: [et-mgmt-tools] FYI: Some virtinst code reorganization In-Reply-To: <4990A874.1030003@redhat.com> References: <4990A874.1030003@redhat.com> Message-ID: <20090210024517.GA27823@movementarian.org> On Mon, Feb 09, 2009 at 05:04:36PM -0500, Cole Robinson wrote: > Just a heads up that I committed some changes to virtinst that > reorganize the code a bit, breaking some classes out into their own > files. The changes are: Much nicer, thanks. john From christopher.dale at incommon.us Wed Feb 11 18:56:44 2009 From: christopher.dale at incommon.us (Christopher Dale) Date: Wed, 11 Feb 2009 13:56:44 -0500 Subject: [et-mgmt-tools] Is it possible / wishlist Message-ID: <8d7909890902111056t2bdfb94t938515081e7d7052@mail.gmail.com> What is the proscribed method for virt-clone if the target you want to use is a snapshot, not a cloned image? -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Wed Feb 11 21:37:18 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 11 Feb 2009 16:37:18 -0500 Subject: [et-mgmt-tools] Is it possible / wishlist In-Reply-To: <8d7909890902111056t2bdfb94t938515081e7d7052@mail.gmail.com> References: <8d7909890902111056t2bdfb94t938515081e7d7052@mail.gmail.com> Message-ID: <4993450E.5060109@redhat.com> Christopher Dale wrote: > What is the proscribed method for virt-clone if the target you want to > use is a snapshot, not a cloned image? > virt-clone doesn't have any snapshot support at the moment. Libvirt's storage support now has some snapshot awareness (though I'm not fully certain yet how it all works). If libvirt eventually gets a storage volume clone API, we could probably tie the two together and offer an option to use a snapshot as a clone, rather than a full device duplication. - Cole From christopher.dale at incommon.us Thu Feb 12 03:21:35 2009 From: christopher.dale at incommon.us (Christopher Dale) Date: Wed, 11 Feb 2009 22:21:35 -0500 Subject: [et-mgmt-tools] Is it possible / wishlist In-Reply-To: <4993450E.5060109@redhat.com> References: <8d7909890902111056t2bdfb94t938515081e7d7052@mail.gmail.com> <4993450E.5060109@redhat.com> Message-ID: <8d7909890902111921t2e858850o76a314d959d15724@mail.gmail.com> Thanks Cole. It would be a very useful feature for building clusters on laptops. On Wed, Feb 11, 2009 at 4:37 PM, Cole Robinson wrote: > Christopher Dale wrote: > > What is the proscribed method for virt-clone if the target you want to > > use is a snapshot, not a cloned image? > > > > virt-clone doesn't have any snapshot support at the moment. > > Libvirt's storage support now has some snapshot awareness (though I'm > not fully certain yet how it all works). If libvirt eventually gets a > storage volume clone API, we could probably tie the two together and > offer an option to use a snapshot as a clone, rather than a full device > duplication. > > - Cole > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Thu Feb 12 14:53:47 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 12 Feb 2009 09:53:47 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: merge VM 'Overview' with hardware list In-Reply-To: <49908D40.8040405@redhat.com> References: <49908D40.8040405@redhat.com> Message-ID: <499437FB.8060107@redhat.com> Cole Robinson wrote: > Hi all, > > The attached patch breaks out the info in the VM 'Overview' tab into > list entries in the VM hardware list. Two entries are added: an > 'Overview' entry (containing name, UUID, and current state), and a > 'Performance' entry (containing all the VM stats graphs). The hardware > tab is renamed to 'Details' since it encompasses a bit more info now. > > Some screenshots: > > http://crobinso.fedorapeople.org/virt-manager/vmm-overview-merge1.png > http://crobinso.fedorapeople.org/virt-manager/vmm-overview-merge2.png > > The patch actually just shows the code change. I left out the 4000+ > glade diff since it is largely mechanical and not worth reviewing directly. > I've pushed this now. Thanks, Cole From tomackell at duke-energy.com Thu Feb 12 17:24:57 2009 From: tomackell at duke-energy.com (Mackell, Thomas O) Date: Thu, 12 Feb 2009 12:24:57 -0500 Subject: [et-mgmt-tools] How to get the IP address of Virtual Machines Message-ID: We have several virtual guests running. Is there a way to get the guests virtual machines ip addresses ? We build the virtual machine using virt-install. We are using DHCP for the temporary ip addresses. After the machines is built, we currently use the virt-manager to open a console, do an ifconfig eth0 to get the machines ip address, is there an easier way to do this. Hopefully from the Dom 0 logon session. Currently running RHEL 5.3 os, the virtual machines are various version of Redhat and Fedora, Centos etc. Thanks in Advance, Thomas Mackell IM OSS UNIX/VMS Server Design & Support -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 862 bytes Desc: image001.gif URL: From john.levon at sun.com Thu Feb 12 18:50:53 2009 From: john.levon at sun.com (john.levon at sun.com) Date: Thu, 12 Feb 2009 10:50:53 -0800 Subject: [et-mgmt-tools] [PATCH] Fix virt-convert osdict usage Message-ID: # HG changeset patch # User John Levon # Date 1234463799 28800 # Node ID d8c2fc154a87724c4b9ed04a61e8a4f211b30b46 # Parent e89c559da3ff95fa3ce52e55233023e25e05752a Fix virt-convert osdict usage Signed-off-by: John Levon diff --git a/virtconv/parsers/virtimage.py b/virtconv/parsers/virtimage.py --- a/virtconv/parsers/virtimage.py +++ b/virtconv/parsers/virtimage.py @@ -88,7 +88,7 @@ def export_os_params(vm): # ImageParser?) should handle this info ostype = fv._OS_TYPES.get(vm.os_type) if ostype: - osvariant = ostype.variants.get(vm.os_variant) + osvariant = ostype.get('variants').get(vm.os_variant) def get_os_val(key, default): val = None From crobinso at redhat.com Thu Feb 12 18:56:36 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 12 Feb 2009 13:56:36 -0500 Subject: [et-mgmt-tools] [PATCH] Fix virt-convert osdict usage In-Reply-To: References: Message-ID: <499470E4.5040600@redhat.com> john.levon at sun.com wrote: > # HG changeset patch > # User John Levon > # Date 1234463799 28800 > # Node ID d8c2fc154a87724c4b9ed04a61e8a4f211b30b46 > # Parent e89c559da3ff95fa3ce52e55233023e25e05752a > Fix virt-convert osdict usage > > Signed-off-by: John Levon > Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/d8c2fc154a87 - Cole From crobinso at redhat.com Thu Feb 12 19:00:11 2009 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 12 Feb 2009 14:00:11 -0500 Subject: [et-mgmt-tools] How to get the IP address of Virtual Machines In-Reply-To: References: Message-ID: <499471BB.4080200@redhat.com> Mackell, Thomas O wrote: > We have several virtual guests running. Is there a way to get the guests virtual machines ip addresses ? > We build the virtual machine using virt-install. We are using DHCP for the temporary ip addresses. > After the machines is built, we currently use the virt-manager to open a console, do an ifconfig eth0 to get the machines ip address, is there an easier way to do this. Hopefully from the Dom 0 logon session. > Currently running RHEL 5.3 os, the virtual machines are various version of Redhat and Fedora, Centos etc. > You can try checking out the virt-mem suite: http://et.redhat.com/~rjones/virt-mem/ There's a tool 'virt-ifconfig' that can be run on the host, and can show a VM's net config. This stuff doesn't come in RHEL, so you'll have to build it yourself. - Cole From takatom at jp.fujitsu.com Fri Feb 13 04:06:07 2009 From: takatom at jp.fujitsu.com (Takahashi Tomohiro) Date: Fri, 13 Feb 2009 13:06:07 +0900 Subject: [et-mgmt-tools] [PATCH][virt-manager] Enable "Ctrl+Alt+Delete" to GuestOS from Virtual, Machine console menu. Message-ID: <4994F1AF.2090700@jp.fujitsu.com> Hi, Virtual Machine Console can not send "Ctrl+Alt+Delete" to GuestOS from menu [Send key]-[Ctrl+Alt+Delete]. and "Ctrl+Alt+Backspace" to GuestOS from menu [Send key]-[Ctrl+Alt+Backspace]. This patch fix this issue. Signed-off-by: Tomohiro Takahashi Thanks, Tomohiro Takahashi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: send_key.patch URL: From agx at sigxcpu.org Fri Feb 13 12:13:05 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 13 Feb 2009 13:13:05 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: remove disambiguity in "free space" dialog In-Reply-To: <1234167689.13728.7.camel@blaa> References: <20090207203406.GA18598@bogon.ms20.nix> <1234167689.13728.7.camel@blaa> Message-ID: <20090213121305.GA20791@bogon.ms20.nix> On Mon, Feb 09, 2009 at 08:21:29AM +0000, Mark McLoughlin wrote: > Hi Guido, > > On Sat, 2009-02-07 at 21:34 +0100, Guido G?nther wrote: > > - res = self.err.yes_no(_("Not Enough Free Space"), ret[1]) > > + res = self.err.yes_no(_("Not Enough Free Space"), _("%s. Continue anyway?") % ret[1]) > > if not res: > > return False > > See the GNOME HIG: > > http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#alert-button-order > > I think what you want here is to change the buttons to Cancel/Continue - > i.e. a Cancel button and an affirmative verb button. I've changed this to "Ok/Cancel" in the attached patch. A simple Ok looks more obvious to me in this case since I'd be unsure to continue with what (it's not creating wizard in the case of add_hardware) and the only thing the user has to do is to acknowledge. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manger_ok-cancel.diff Type: text/x-diff Size: 2267 bytes Desc: not available URL: From agx at sigxcpu.org Fri Feb 13 13:53:54 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 13 Feb 2009 14:53:54 +0100 Subject: [et-mgmt-tools] [PATCH]: virt-manager: Hint about ssh-askpass Message-ID: <20090213135354.GA23194@bogon.ms20.nix> Hi, this came in via: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513599 It adds a hint about ssh-askpass if using ssh protocoll fails. Patch by Sebastian Andrzej Siewior. Cheers, -- Guido -------------- next part -------------- diff -r e03490a72a2e src/virtManager/connection.py --- a/src/virtManager/connection.py Mon Feb 09 14:55:18 2009 -0500 +++ b/src/virtManager/connection.py Fri Feb 13 14:50:42 2009 +0100 @@ -431,13 +431,19 @@ else: self.state = self.STATE_DISCONNECTED + if self.uri.find("+ssh://") > 0: + hint = "\nMaybe you need to install ssh-askpass " + \ + "in order to authenticate." + else: + hint = "" + (_type, value, stacktrace) = open_error # Detailed error message, in English so it can be Googled. self.connectError = \ ("Unable to open connection to hypervisor URI '%s':\n" % str(self.uri)) + \ str(_type) + " " + str(value) + "\n" + \ - traceback.format_exc (stacktrace) + traceback.format_exc (stacktrace) + hint logging.error(self.connectError) # We want to kill off this thread asap, so schedule a gobject From crobinso at redhat.com Tue Feb 17 00:41:55 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 16 Feb 2009 19:41:55 -0500 Subject: [et-mgmt-tools] [PATCH] Add 'fullscreen only' VNC scaling option Message-ID: <499A07D3.2070207@redhat.com> The attached patch adds an extra scaling option for a VM's VNC connection: 'Fullscreen Only'. This required breaking out the UI into radio buttons rather than a simple boolean checkbox. Screenshot here: http://fedorapeople.org/~crobinso/virt-manager/vmm-details-scale.png Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-scale-fullscreen-only.patch Type: text/x-diff Size: 7725 bytes Desc: not available URL: From crobinso at redhat.com Tue Feb 17 00:42:15 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 16 Feb 2009 19:42:15 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: Add global VNC scaling preference Message-ID: <499A07E7.3060006@redhat.com> The attached patch adds a global preference to the 'Preferences' dialog for the default VNC scaling value. The new default for all VMs is 'Fullscreen Only': since scaling isn't required for day to day use, and there is a performance penalty, it should be opt in by default. All VMs abide this global pref, but can override it in their details window. However this overwritten value will be forgotten once the virt-manager is restarted (still working on adding per-vm preferences). Screenshot here: http://fedorapeople.org/~crobinso/virt-manager/vmm-prefs-scaling.png Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-global-scale-prefs.patch Type: text/x-diff Size: 33197 bytes Desc: not available URL: From crobinso at redhat.com Tue Feb 17 00:51:02 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 16 Feb 2009 19:51:02 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: remove disambiguity in "free space" dialog In-Reply-To: <20090213121305.GA20791@bogon.ms20.nix> References: <20090207203406.GA18598@bogon.ms20.nix> <1234167689.13728.7.camel@blaa> <20090213121305.GA20791@bogon.ms20.nix> Message-ID: <499A09F6.3050903@redhat.com> Guido G?nther wrote: > On Mon, Feb 09, 2009 at 08:21:29AM +0000, Mark McLoughlin wrote: >> Hi Guido, >> >> On Sat, 2009-02-07 at 21:34 +0100, Guido G?nther wrote: >>> - res = self.err.yes_no(_("Not Enough Free Space"), ret[1]) >>> + res = self.err.yes_no(_("Not Enough Free Space"), _("%s. Continue anyway?") % ret[1]) >>> if not res: >>> return False >> See the GNOME HIG: >> >> http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#alert-button-order >> >> I think what you want here is to change the buttons to Cancel/Continue - >> i.e. a Cancel button and an affirmative verb button. > I've changed this to "Ok/Cancel" in the attached patch. A simple Ok > looks more obvious to me in this case since I'd be unsure to continue > with what (it's not creating wizard in the case of add_hardware) and the > only thing the user has to do is to acknowledge. > -- Guido > Thanks, applied now: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/60940c2af2db - Cole From crobinso at redhat.com Tue Feb 17 00:51:56 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 16 Feb 2009 19:51:56 -0500 Subject: [et-mgmt-tools] [PATCH][virt-manager] Enable "Ctrl+Alt+Delete" to GuestOS from Virtual, Machine console menu. In-Reply-To: <4994F1AF.2090700@jp.fujitsu.com> References: <4994F1AF.2090700@jp.fujitsu.com> Message-ID: <499A0A2C.9070606@redhat.com> Takahashi Tomohiro wrote: > Hi, > > Virtual Machine Console can not send > "Ctrl+Alt+Delete" to GuestOS from menu [Send key]-[Ctrl+Alt+Delete]. > and > "Ctrl+Alt+Backspace" to GuestOS from menu [Send key]-[Ctrl+Alt+Backspace]. > > This patch fix this issue. > > Signed-off-by: Tomohiro Takahashi > Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/e0f0b017caa9 - Cole From sukadev at linux.vnet.ibm.com Wed Feb 18 03:10:48 2009 From: sukadev at linux.vnet.ibm.com (Sukadev Bhattiprolu) Date: Tue, 17 Feb 2009 19:10:48 -0800 Subject: [et-mgmt-tools] libvirt/vit-manager with custom kernel Message-ID: <20090218031048.GA371@us.ibm.com> I am running virt-manager and kvm on a T61p laptop running Ubuntu 8.04. I am able to create and run Fedora10 kvm image fine from within the virt-manager (Attached 'working.xml' file shows the dumpxml output of this guest image). I am trying to run this same image with a custom 2.6.28 kernel. I tried adding following lines to the section of the 'working.xml' file. 8a9,10 > /home/suka/vm/kernels/vmlinuz-2.6.28 > "ro root=UUID=fa22e974-699a-4c9a-9e7f-62c138642239 debug" The guest seems to start up when I when run: $ sudo virsh create new.xml and I can see kvm running as follows: $ ps -f |grep kvm root 3040 6035 99 17:02 ? 00:08:21 /usr/bin/kvm -M pc -m 512 -smp 2 -monitor pty -kernel /home/linux/vm/kernels/vmlinuz-2.6.28 -append "ro root=UUID=fa22e974-699a-4c9a-9e7f-62c138642239 debug" -drive file=/home/linux/vm/fc10.img,if=ide,boot=on -net nic,macaddr=00:16:3e:0d:ca:1c,vlan=0 -net tap,fd=12,script=,vlan=0 -usb -vnc 127.0.0.1:0 But when I connect to console: $ vncviewer 127.0.0.1:0 I just see "serial0 console" in the vncviewer and nothing happens. I believe the 'vmlinuz-2.6.28' kernel is fine, since I can boot it with following kvm command line $ /usr/bin/kvm \ -kernel /home/linux/vm/kernels/vmlinuz-2.6.28 -smp 8 -m 1024 \ -append "debug ro console=ttyS0 root=/dev/sda1" \ -hda /home/linux/vm/fc10.img -no-reboot -vnc :9 \ -redir tcp:2209::22 -serial telnet::2009,server But the same kernel in the virt-manager/libvirt just hangs. virt-manager shows that the 'guest' is using about 50% CPU and memory but nothing really seems to be happening. I checked ~/.virt-manager/*log, /var/log/messages and dmesg on the host (T61p). Only message I found, repeated several times was in dmesg: 'vcpu not ready for apic_round_robin' Are there other log files I should check or is there a way to have kvm print out more useful info on what is happening ? Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: working.xml Type: application/xml Size: 858 bytes Desc: working.xml URL: From crobinso at redhat.com Wed Feb 18 03:20:46 2009 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 17 Feb 2009 22:20:46 -0500 Subject: [et-mgmt-tools] libvirt/vit-manager with custom kernel In-Reply-To: <20090218031048.GA371@us.ibm.com> References: <20090218031048.GA371@us.ibm.com> Message-ID: <499B7E8E.6070304@redhat.com> Sukadev Bhattiprolu wrote: > > I am running virt-manager and kvm on a T61p laptop running Ubuntu 8.04. > > I am able to create and run Fedora10 kvm image fine from within the > virt-manager (Attached 'working.xml' file shows the dumpxml output > of this guest image). > > I am trying to run this same image with a custom 2.6.28 kernel. I tried > adding following lines to the section of the 'working.xml' file. > > 8a9,10 >> /home/suka/vm/kernels/vmlinuz-2.6.28 >> "ro root=UUID=fa22e974-699a-4c9a-9e7f-62c138642239 debug" > > The guest seems to start up when I when run: > > $ sudo virsh create new.xml > > and I can see kvm running as follows: > > $ ps -f |grep kvm > root 3040 6035 99 17:02 ? 00:08:21 /usr/bin/kvm -M pc -m 512 -smp 2 -monitor pty -kernel /home/linux/vm/kernels/vmlinuz-2.6.28 -append "ro root=UUID=fa22e974-699a-4c9a-9e7f-62c138642239 debug" -drive file=/home/linux/vm/fc10.img,if=ide,boot=on -net nic,macaddr=00:16:3e:0d:ca:1c,vlan=0 -net tap,fd=12,script=,vlan=0 -usb -vnc 127.0.0.1:0 > > But when I connect to console: > > $ vncviewer 127.0.0.1:0 > > I just see "serial0 console" in the vncviewer and nothing happens. > > I believe the 'vmlinuz-2.6.28' kernel is fine, since I can boot it with > following kvm command line > > $ /usr/bin/kvm \ > -kernel /home/linux/vm/kernels/vmlinuz-2.6.28 -smp 8 -m 1024 \ > -append "debug ro console=ttyS0 root=/dev/sda1" \ > -hda /home/linux/vm/fc10.img -no-reboot -vnc :9 \ > -redir tcp:2209::22 -serial telnet::2009,server > > But the same kernel in the virt-manager/libvirt just hangs. virt-manager > shows that the 'guest' is using about 50% CPU and memory but nothing > really seems to be happening. > > I checked ~/.virt-manager/*log, /var/log/messages and dmesg on the host (T61p). > Only message I found, repeated several times was in dmesg: > > 'vcpu not ready for apic_round_robin' > > Are there other log files I should check or is there a way to have kvm > print out more useful info on what is happening ? > I think you listed about as much info as there is to gather. If the guest is spinning the cpu like that, my guess is something is wrong with the qemu invocation. The libvirt generated command line and the one you are using manually have quite a few differences in them. I would run the libvirt generated command manually, verify that it fails, and start working your way back towards the original command line option by option to see if you can determine the culprit. Start first with the kernel arguments, then maybe mem + smp values, etc. etc. Thanks, Cole From mvliet at uvic.ca Wed Feb 18 18:41:33 2009 From: mvliet at uvic.ca (Matt Vliet) Date: Wed, 18 Feb 2009 10:41:33 -0800 Subject: [et-mgmt-tools] virt-manager rpm build error Message-ID: <499C565D.9000202@uvic.ca> Hello, I was looking for a pointer in the right direction on fixing an error I am getting when trying to build an rpm of virt-manager. I have tried both... rpmbuild -tb virt-manager-0.6.1.tar.gz and... make rpm (on the unzipped tree) and both of these result in the following error. I don't seem to have any missing dependencies that I know about, because I can do a ./configure and make install on the source and it works just fine. I'm on a Scientific Linux 5.2 (rhel clone). Any pointers would be helpful, Thanks, Matt V. ...... make[2]: Leaving directory `/usr/src/redhat/BUILD/virt-manager-0.6.1' make[1]: Leaving directory `/usr/src/redhat/BUILD/virt-manager-0.6.1' + rm -f /var/tmp/virt-manager-0.6.1-1-root-root/usr/lib/virt-manager/sparkline.a + rm -f /var/tmp/virt-manager-0.6.1-1-root-root/usr/lib/virt-manager/sparkline.la + /usr/lib/rpm/find-lang.sh /var/tmp/virt-manager-0.6.1-1-root-root virt-manager + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-static-archive + /usr/lib/rpm/brp-strip-comment-note Processing files: virt-manager-0.6.1-1 error: File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/*.pyc error: File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/*.pyo error: File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/virtManager/*.pyc error: File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/virtManager/*.pyo Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.69465 + umask 022 + cd /usr/src/redhat/BUILD + cd virt-manager-0.6.1 + DOCDIR=/var/tmp/virt-manager-0.6.1-1-root-root/usr/share/doc/virt-manager-0.6.1 + export DOCDIR + rm -rf /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/doc/virt-manager-0.6.1 + /bin/mkdir -p /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/doc/virt-manager-0.6.1 + cp -pr README COPYING COPYING-DOCS AUTHORS ChangeLog NEWS /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/doc/virt-manager-0.6.1 + exit 0 RPM build errors: File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/*.pyc File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/*.pyo File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/virtManager/*.pyc File not found by glob: /var/tmp/virt-manager-0.6.1-1-root-root/usr/share/virt-manager/virtManager/*.pyo From crobinso at redhat.com Thu Feb 19 02:40:08 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 18 Feb 2009 21:40:08 -0500 Subject: [et-mgmt-tools] [PATCH] virt-clone --original-xml option Message-ID: <499CC688.2020800@redhat.com> Hi all, The attached patch adds a new command line option to virt-clone: --original-xml. This allows the user to specify the guest to clone as an xml file, rather than require the use of a guest defined on the current connection. The backend code in CloneManager is already present (I recently added it to help build up a test suite). Any input (option name, docs, etc) appreciated. Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-clone-original-xml.patch Type: text/x-diff Size: 3563 bytes Desc: not available URL: From crobinso at redhat.com Thu Feb 19 02:42:48 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 18 Feb 2009 21:42:48 -0500 Subject: [et-mgmt-tools] [PATCH 0/2] Add virt-install --import option Message-ID: <499CC728.8060101@redhat.com> Hi all, The followin patches add a new option to virt-install: --import. The option wraps a new installer, which is used to build a guest around an existing disk image, skipping the OS install step. The patches are: 1 - Add new ImportInstaller class 2 - Add virt-install --import option Any comments appreciated. Thanks, Cole From crobinso at redhat.com Thu Feb 19 02:43:39 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 18 Feb 2009 21:43:39 -0500 Subject: [et-mgmt-tools] [PATCH 1/2] Add new ImportInstaller class In-Reply-To: <499CC728.8060101@redhat.com> References: <499CC728.8060101@redhat.com> Message-ID: <499CC75B.9000203@redhat.com> This patch adds a new ImportInstaller class, as well as test suite changes to exercise the new code. Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-import-installer.patch Type: text/x-diff Size: 8710 bytes Desc: not available URL: From crobinso at redhat.com Thu Feb 19 02:44:44 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 18 Feb 2009 21:44:44 -0500 Subject: [et-mgmt-tools] [PATCH 2/2] Add virt-install --import option In-Reply-To: <499CC728.8060101@redhat.com> References: <499CC728.8060101@redhat.com> Message-ID: <499CC79C.2050301@redhat.com> This patch adds the --import option to virt-install. --import is a new install method, which arranges for the guest to boot off the first specified storage device. So, given an existing disk image '/home/user/myvm.img', an example command line could be: virt-install --name myvm --ram 512 \ --disk path=/home/user/myvm.img --import Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-import-option.patch Type: text/x-diff Size: 5088 bytes Desc: not available URL: From John.Dickson at qwest.com Thu Feb 19 12:41:58 2009 From: John.Dickson at qwest.com (Dickson, John) Date: Thu, 19 Feb 2009 05:41:58 -0700 Subject: [et-mgmt-tools] Dell 6850 Message-ID: Ah my first post. I have a Dell 6850 that fails to boot the virt-p2v disc. Anyone have any ideas? The system locks up. John Dickson Qwest Corporation Sr. Technical Support Engineer 402-691-1870 This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Dickson, John.vcf Type: text/x-vcard Size: 373 bytes Desc: Dickson, John.vcf URL: From agx at sigxcpu.org Thu Feb 19 15:11:34 2009 From: agx at sigxcpu.org (=?ISO-8859-1?Q?Guido_G=FCnther?=) Date: Thu, 19 Feb 2009 16:11:34 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: make fullscreen mode Message-ID: <499D76A6.2080805@sigxcpu.org> Hi, when a VM uses a video mode that is larger than the mode of the host running virt-manager fullscreen mode isn't particular useful at the moment. Since there are no scroll bars (due to _force_resize), parts of the screen simply get cut off. Attached patch sets the size of the vnc widget to the actual screen size (minus the height of the menu bar) when switching to fullscreen mode with scaling enabled. This makes things work much better for me. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: fullscreen.diff Type: text/x-patch Size: 1166 bytes Desc: not available URL: From agx at sigxcpu.org Thu Feb 19 15:18:13 2009 From: agx at sigxcpu.org (=?ISO-8859-1?Q?Guido_G=FCnther?=) Date: Thu, 19 Feb 2009 16:18:13 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: gtk-vnc 0.3.8 handles rescaling with compiz Message-ID: <499D7835.8060907@sigxcpu.org> Hi, gtk-vnc 0.3.8 handle compositioning so scaling can be used in that case too. Cheers, -- Guido P.S.: if this is o.k. the spec file needs a bump in the gtk-vnc version too. -------------- next part -------------- A non-text attachment was scrubbed... Name: composite_dont_care.diff Type: text/x-patch Size: 842 bytes Desc: not available URL: From josir at globo.com Fri Feb 20 00:04:55 2009 From: josir at globo.com (Josir Cardoso Gomes) Date: Thu, 19 Feb 2009 21:04:55 -0300 Subject: [et-mgmt-tools] Re: et-mgmt-tools Digest, Vol 30, Issue 15 In-Reply-To: <20090219170038.7A19561AACB@hormel.redhat.com> References: <20090219170038.7A19561AACB@hormel.redhat.com> Message-ID: Hi folks, Fresh Ubuntu 8.04 64bits / virt-manager (0.5.3) from regular repositories. 1) I created some KVM VMs with virsh define but I can't see them on virt-manager. What am I doing wrong ? 2) I know that virt-manager has a 0.6.0 version but I could not find a valid package for debian/ubuntu. I tried also to install from tar.gz but I got everything messed up. Does somebody know a package that I can run on Ubuntu 8.04 ? Thanks in advance, Josir Gomes -------------- next part -------------- An HTML attachment was scrubbed... URL: From josir at globo.com Sun Feb 22 12:57:18 2009 From: josir at globo.com (Josir Gomes) Date: Sun, 22 Feb 2009 09:57:18 -0300 Subject: [et-mgmt-tools] VMs do not show up in virt-manager - Ubuntu Message-ID: <49A14BAE.6010808@globo.com> Hi folks, I created some KVM VMs with "virsh define" I can open it with virt-viewer and vms are working fine. But I can't see them on virt-manager. What am I doing wrong ? The configuration is not automatic? Host: Ubuntu 8.04 64bits Guests: ubuntu 8.04 64bits virt-manager (0.5.3) Sorry for the "subject" on my last post - it was late and I was not really awaken... :( Thanks in advance, Josir Gomes From crobinso at redhat.com Sun Feb 22 17:11:26 2009 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 22 Feb 2009 12:11:26 -0500 Subject: [et-mgmt-tools] VMs do not show up in virt-manager - Ubuntu In-Reply-To: <49A14BAE.6010808@globo.com> References: <49A14BAE.6010808@globo.com> Message-ID: <49A1873E.7040105@redhat.com> Josir Gomes wrote: > Hi folks, > > I created some KVM VMs with "virsh define" > I can open it with virt-viewer and vms are working fine. > > But I can't see them on virt-manager. What am I doing wrong ? > The configuration is not automatic? > > Host: Ubuntu 8.04 64bits > Guests: ubuntu 8.04 64bits > virt-manager (0.5.3) > My guess is you aren't using the same URI between the two. To see the libvirt URI you are using from virt-manager: Run virt-manager Double click the connection row whose URI you want to see Edit->Connection Details To see the libvirt URI you are using with virsh: Run 'virsh uri' Hope that helps, Cole From crobinso at redhat.com Sun Feb 22 20:34:44 2009 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 22 Feb 2009 15:34:44 -0500 Subject: [et-mgmt-tools] Re: Patch to python-virtinst to allow it to choose svirt labels In-Reply-To: <499EFBEF.9090906@redhat.com> References: <499EFBEF.9090906@redhat.com> Message-ID: <49A1B6E4.3060604@redhat.com> Daniel J Walsh wrote: The patch didn't apply to latest upstream (there has been a lot of code movement recently). I rediffed the patch to apply against current tip, and made a few minor changes that don't change the overall result (mentioned below). > Also found at least one big bug in python-virtinst, VirtualDisk.py was > dropping the "/" between dirname and basename of installation object, > when you told it to create the object. > This is already fixed upstream. You also had a minor bug fix in the Installer class that is fixed as well, so I dropped both pieces. > I think we want to have a big switch stored in libvirt somewhere saying > whether or not we want isolated virtual machines. > I think this should really be at the management tool level (i.e, virt-manager). libvirt should be dumb in this respect, being passed a label via the xml and doing with it what it's told. I figure, virt-manager can have an option in Edit->Preferences, something like "Isolate virtual machines with SELinux". Defaults to on. If selinux isn't running, we disable the option with a tooltip explaining why (or maybe hide it altogether). If the option is enabled, virt-manager will assign labels to VMs at install time, and check all active connections to avoid label collisions. More advanced behavior can come later (assigning specific labels, some sort of collision resolution with VMs on new connections, etc.) Updated patch attached, I'll reply with patch specific comments later. Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virtinst-0.400.1-svirt-02.patch Type: text/x-diff Size: 5741 bytes Desc: not available URL: From crobinso at redhat.com Sun Feb 22 21:53:17 2009 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 22 Feb 2009 16:53:17 -0500 Subject: [et-mgmt-tools] Re: Patch to python-virtinst to allow it to choose svirt labels In-Reply-To: <49A1B6E4.3060604@redhat.com> References: <499EFBEF.9090906@redhat.com> <49A1B6E4.3060604@redhat.com> Message-ID: <49A1C94D.1010005@redhat.com> Cole Robinson wrote: > Daniel J Walsh wrote: > > > Updated patch attached, I'll reply with patch specific comments later. > > Thanks, > Cole > Two major pieces missing from this patch: 1) Some way to skip all this. If selinux isn't enabled on the host, or the user doesn't request labeling, we shouldn't do the work. 2) Support in CapabilitiesParser for the host security policy, otherwise we have no way of knowing if selinux is enabled on a remote host. > diff -r 026a37ccd417 virtinst/Guest.py > --- a/virtinst/Guest.py Sat Feb 21 14:36:07 2009 -0500 > +++ b/virtinst/Guest.py Sat Feb 21 15:09:49 2009 -0500 > @@ -27,6 +27,8 @@ > import libvirt > import CapabilitiesParser > import VirtualGraphics > +import selinux This import should be moved into gen_seclabels, and probably wrapped in a try...except block, and if the import fails (libselinux-python isn't isntalled) we just skip adding the labels to the xml. This will make it easier for other distros who may not want the selinux support to avoid problems. > +import random > > import osdict > from virtinst import _virtinst as _ > @@ -71,6 +73,8 @@ > self._cpuset = None > self._graphics_dev = None > self._consolechild = None > + self._seclabel = None > + self._imagelabel = None > > self._os_type = None > self._os_variant = None > @@ -101,6 +105,16 @@ > > self._caps = CapabilitiesParser.parse(self.conn.getCapabilities()) > > + (self.default_seclabel, > + self.default_imagelabel) = self._default_seclabels() > + > + while self._seclabel == None: > + seclabel, imagelabel = self.gen_seclabels() > + if self.is_conflict_seclabel(self.conn, seclabel): > + continue > + self.set_seclabel(seclabel) > + self.set_imagelabel(imagelabel) > + > > def get_installer(self): > return self._installer > @@ -110,6 +124,20 @@ > self._installer = val > installer = property(get_installer, set_installer) > > + # Security context used to secure guest image > + def get_imagelabel(self): > + return self._imagelabel > + def set_imagelabel(self, val): > + self._imagelabel = val > + imagelabel = property(get_imagelabel, set_imagelabel) > + > + # Security context used to secure guest process > + def get_seclabel(self): > + return self._seclabel > + def set_seclabel(self, val): > + self._seclabel = val > + seclabel = property(get_seclabel, set_seclabel) > + > # Domain name of the guest > def get_name(self): > return self._name > @@ -407,6 +435,19 @@ > xml = _util.xml_append(xml, sound_dev.get_xml_config()) > return xml > > + def _get_seclabel_xml(self): > + xml = "" > + if self._seclabel != None: > + xml = """ > + > + > + %s > + > +""" % ( self._seclabel, self._imagelabel) > + print xml > + return xml > + > + This doesn't look like it matches the latest svirt libvirt patches: I don't see an tag in those. > def _get_device_xml(self, install=True): > xml = "" > > @@ -494,6 +535,7 @@ > > %(devices)s > > + %(secxml)s > > """ % { "type": self.type, > "name": self.name, \ > @@ -504,7 +546,8 @@ > "maxramkb": self.maxmemory * 1024, \ > "devices": self._get_device_xml(install), \ > "osblob": osblob, \ > - "action": action } > + "action": action, > + "secxml": self._get_seclabel_xml()} > > > def start_install(self, consolecb=None, meter=None, removeOld=False, > @@ -537,6 +580,8 @@ > """Ensure that devices are setup""" > for disk in self._install_disks: > disk.setup(progresscb) > + # Not sure of this, might want to put this in VirtualDisk class > + selinux.setfilecon(disk.path, self._imagelabel) Yes, this should be in the VirtualDisk class, in the setup method. VirtualDisk would also need an imagelabel attribute in that case. It may be nice to also keep the Guest one, rather than force the user to fill in the imagelabel for every VirtualDisk object being added. Either way, this will break the remote case as is. > for nic in self._install_nics: > nic.setup(self.conn) > > @@ -631,6 +676,80 @@ > if self.domain is not None: > raise RuntimeError, _("Domain has already been started!") > > + def _default_seclabels(self): > + try: > + fd = open(selinux.selinux_virtual_domain_context_path(), 'r') > + except OSError, (err_no, msg): > + raise RuntimeError(_("Failed to find SELinux virtual domains " > + "context: %s: %s %s" % > + (selinux.selinux_virtual_domain_context_path(), > + err_no, msg))) > + > + label = fd.read() > + fd.close() > + try: > + fd = open(selinux.selinux_virtual_image_context_path(), 'r') > + except OSError, (err_no, msg): > + raise RuntimeError(_("Failed to find SELinux virtual image " > + "context: %s: %s %s" % > + (selinux.selinux_virtual_domain_context_path(), > + err_no, msg))) > + What version of libselinux-python were these functions added in? They don't seem present on F9 at least. Also, this labeling would only be relevant on the local host. Maybe this info should be exposed by libvirt capabilities? If we do get this info from capabilities, then we may as well just remove the dependency on libselinux-python, and just use 'chcon' directly. The rest looks reasonable. Thanks, Cole From jmandawg at hotmail.com Sun Feb 22 22:31:57 2009 From: jmandawg at hotmail.com (jmandawg) Date: Sun, 22 Feb 2009 17:31:57 -0500 Subject: [et-mgmt-tools] attach hot usb device Message-ID: Hi, Quick question, since I can't get to the qemu monitor anymore, how do I hot add a usb device (smartphone)? Is it possible to do through virsh? Thanks, -J -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Sun Feb 22 23:08:45 2009 From: crobinso at redhat.com (Cole Robinson) Date: Sun, 22 Feb 2009 18:08:45 -0500 Subject: [et-mgmt-tools] attach hot usb device In-Reply-To: References: Message-ID: <49A1DAFD.5030303@redhat.com> cc-ing libvir-list (future libvirt questions should be directed there) jmandawg wrote: > Hi, > > > > Quick question, since I can?t get to the qemu monitor anymore, how do I > hot add a usb device (smartphone)? > > Is it possible to do through virsh? > Sure: - Use 'lsusb' to determine the bus and device. Example listing looks like: Bus 001 Device 006: ID 0781:5151 SanDisk Corp. Cruzer Micro 256/512MB Flash Drive - Put hostdev xml in a file: cat << __EOF__ > usb.xml
__EOF__ - Run 'virsh attach-device {VMNAME} usb.xml' on a running VM. Hope that helps, Cole From jmandawg at hotmail.com Mon Feb 23 01:47:39 2009 From: jmandawg at hotmail.com (jmandawg) Date: Sun, 22 Feb 2009 20:47:39 -0500 Subject: [et-mgmt-tools] attach hot usb device In-Reply-To: <49A1DAFD.5030303@redhat.com> References: <49A1DAFD.5030303@redhat.com> Message-ID: No go for me, maybe I'm running the wrong version of virsh? virsh # attach-device XPJohn usbPhone2.xml libvir: QEMU error : unknown device type error: Failed to attach device from usbPhone2.xml virsh # version Compiled against library: libvir 0.4.0 Using library: libvir 0.4.0 Using API: QEMU 0.4.0 Running hypervisor: QEMU 0.9.1 [root at e6400:/etc/libvirt/ 482]$virsh list Connecting to uri: qemu:///system Id Name State ---------------------------------- 1 XPJohn running 2 ubuntuVNC running 3 webserver running 4 XPTest running [root at e6400:/etc/libvirt/ 481]$lsusb Bus 007 Device 004: ID 0bb4:0b2e High Tech Computer Corp. Bus 007 Device 001: ID 0000:0000 Bus 006 Device 001: ID 0000:0000 Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 [root at e6400:/etc/libvirt/ 481]$cat usbPhone2.xml
What am I doing wrong? -Jay > -----Original Message----- > From: Cole Robinson [mailto:crobinso at redhat.com] > Sent: Sunday, February 22, 2009 6:09 PM > To: Fedora/Linux Management Tools > Cc: Libvirt; jmandawg at hotmail.com > Subject: Re: [et-mgmt-tools] attach hot usb device > > cc-ing libvir-list (future libvirt questions should be directed there) > > jmandawg wrote: > > Hi, > > > > > > > > Quick question, since I can't get to the qemu monitor anymore, how do I > > hot add a usb device (smartphone)? > > > > Is it possible to do through virsh? > > > > Sure: > > - Use 'lsusb' to determine the bus and device. Example listing looks like: > > Bus 001 Device 006: ID 0781:5151 SanDisk Corp. Cruzer Micro 256/512MB > Flash Drive > > - Put hostdev xml in a file: > > cat << __EOF__ > usb.xml > > >
> > > __EOF__ > > - Run 'virsh attach-device {VMNAME} usb.xml' on a running VM. > > Hope that helps, > Cole From crobinso at redhat.com Mon Feb 23 12:42:40 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 07:42:40 -0500 Subject: [et-mgmt-tools] attach hot usb device In-Reply-To: References: <49A1DAFD.5030303@redhat.com> Message-ID: <49A299C0.5090107@redhat.com> jmandawg wrote: > No go for me, maybe I'm running the wrong version of virsh? > > virsh # attach-device XPJohn usbPhone2.xml > libvir: QEMU error : unknown device type > error: Failed to attach device from usbPhone2.xml > > virsh # version > Compiled against library: libvir 0.4.0 > Using library: libvir 0.4.0 > Using API: QEMU 0.4.0 > Running hypervisor: QEMU 0.9.1 > You need libvirt version 0.5.0 or later. Thanks, Cole From jmandawg at hotmail.com Mon Feb 23 12:58:14 2009 From: jmandawg at hotmail.com (jmandawg) Date: Mon, 23 Feb 2009 07:58:14 -0500 Subject: [et-mgmt-tools] attach hot usb device In-Reply-To: <49A299C0.5090107@redhat.com> References: <49A1DAFD.5030303@redhat.com> <49A299C0.5090107@redhat.com> Message-ID: Ok, Thanks. I'm using Ubuntu so I guess I will have to compile it myself. Thanks again, -J > -----Original Message----- > From: Cole Robinson [mailto:crobinso at redhat.com] > Sent: Monday, February 23, 2009 7:43 AM > To: jmandawg > Cc: 'Fedora/Linux Management Tools'; 'Libvirt' > Subject: Re: [et-mgmt-tools] attach hot usb device > > jmandawg wrote: > > No go for me, maybe I'm running the wrong version of virsh? > > > > virsh # attach-device XPJohn usbPhone2.xml > > libvir: QEMU error : unknown device type > > error: Failed to attach device from usbPhone2.xml > > > > virsh # version > > Compiled against library: libvir 0.4.0 > > Using library: libvir 0.4.0 > > Using API: QEMU 0.4.0 > > Running hypervisor: QEMU 0.9.1 > > > > You need libvirt version 0.5.0 or later. > > Thanks, > Cole From stephan at fishycam.com Mon Feb 23 15:48:24 2009 From: stephan at fishycam.com (Stephan) Date: Mon, 23 Feb 2009 15:48:24 +0000 Subject: [et-mgmt-tools] Can't create new machines using virt-image - missing something obvious, likely user error... Message-ID: Hi, Thanks to the help from before and documentation all over the place, I'm now using libvirt, KVM, virt-install and vmbuilder from Ubuntu, everything is going really well (so thanks for that). The next thing I've been trying is getting Windows XP virtualised. I have managed now and have a virtual machine defined in libvirt, that's all fine. So now what I'd like to do is prepare an XML file and a hard drive image that I can send on DVD to the other offices at work for them to install using virt-image. Here's my XML for virt-image: testimage x86_64 4 262144 and I'm trying to get that working using: virt-image --vnc mytestimage.xml When I run that, I get "Error parsing 'mytestimage.xml': Disk entry for 'xpvmimage.raw' not found" My image is actually in qcow format (now qcow2). I've tried using qcow and raw with no luck. The xpvmimage.raw is in the same directory I'm running the command from and the same place as the xml so I don't think it's just that it can't find the file. I'm fairly sure that I'm missing some vital information here... Hopefully someone on the list can point out where I'm going wrong. I'm pretty sure this isn't a fault with the code, I'm just doing it wrong or not understanding. Is there a special format for these hard drive images I should be using? I was thinking I'd just copy the .qcow (or convert it to .raw) and that would be alright. Thanks for your help. Stephan From stephan at fishycam.com Mon Feb 23 15:53:41 2009 From: stephan at fishycam.com (Stephan) Date: Mon, 23 Feb 2009 15:53:41 +0000 Subject: [et-mgmt-tools] Can't create new machines using virt-image - missing something obvious, likely user error... In-Reply-To: References: Message-ID: <91402b8f6ee466c49d7c92c82aecd19e@crimefightingrabbit.com> Actually my e-mail was horribly unclear. What I meant to write is that I've tried both .raw and .qcow with no luck. Thanks again, Stephan From crobinso at redhat.com Mon Feb 23 16:16:00 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 11:16:00 -0500 Subject: [et-mgmt-tools] Can't create new machines using virt-image - missing something obvious, likely user error... In-Reply-To: References: Message-ID: <49A2CBC0.4010602@redhat.com> Stephan wrote: > Hi, > > Thanks to the help from before and documentation all over the place, I'm > now using libvirt, KVM, virt-install and vmbuilder from Ubuntu, everything > is going really well (so thanks for that). > > The next thing I've been trying is getting Windows XP virtualised. I have > managed now and have a virtual machine defined in libvirt, that's all fine. > > So now what I'd like to do is prepare an XML file and a hard drive image > that I can send on DVD to the other offices at work for them to install > using virt-image. > Cool! > Here's my XML for virt-image: > > > testimage > > > > x86_64 > > > > > > > > > > > 4 > 262144 > > > > > > > > > The problem is with the above xml: it isn't formatted correctly. For every entry in the block, there needs to be a entry in the block. Check out man 5 virt-image for more detailed info, and an example config. One feature that would help you in this case is the ability to specify the OS type and variant (either via the virt-image cli or in the image format). Otherwise, the VM clock setting will be incorrect for windows VMs (utc instead of localtime). Unfortunately that feature doesn't exist yet :( Hope that helps! Cole From stephan at fishycam.com Mon Feb 23 16:34:02 2009 From: stephan at fishycam.com (Stephan) Date: Mon, 23 Feb 2009 16:34:02 +0000 Subject: [et-mgmt-tools] Can't create new machines using virt-image - missing something obvious, likely user error... In-Reply-To: <49A2CBC0.4010602@redhat.com> References: <49A2CBC0.4010602@redhat.com> Message-ID: > Hope that helps! > Cole Yes, that did thanks. It's now working :-) I had misunderstood the way the files worked. I thought one was a source image and one was a destination. duh... Thanks again, Stephan From crobinso at redhat.com Tue Feb 24 00:05:09 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 19:05:09 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: make fullscreen mode In-Reply-To: <499D76A6.2080805@sigxcpu.org> References: <499D76A6.2080805@sigxcpu.org> Message-ID: <49A339B5.5040101@redhat.com> Guido G?nther wrote: > Hi, > when a VM uses a video mode that is larger than the mode of the host > running virt-manager fullscreen mode isn't particular useful at the > moment. Since there are no scroll bars (due to _force_resize), parts of > the screen simply get cut off. Attached patch sets the size of the vnc > widget to the actual screen size (minus the height of the menu bar) when > switching to fullscreen mode with scaling enabled. This makes things > work much better for me. Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/8176c489cd55 - Cole From crobinso at redhat.com Tue Feb 24 00:06:12 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 19:06:12 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: gtk-vnc 0.3.8 handles rescaling with compiz In-Reply-To: <499D7835.8060907@sigxcpu.org> References: <499D7835.8060907@sigxcpu.org> Message-ID: <49A339F4.3090902@redhat.com> Guido G?nther wrote: > Hi, > gtk-vnc 0.3.8 handle compositioning so scaling can be used in that case > too. > Cheers, > -- Guido > A similar change was pulled in with my other scaling changes. > P.S.: if this is o.k. the spec file needs a bump in the gtk-vnc version > too. Doh, good call :) Applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/89355e738db6 Thanks, Cole From crobinso at redhat.com Tue Feb 24 00:06:50 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 19:06:50 -0500 Subject: [et-mgmt-tools] [PATCH 0/2] Add virt-install --import option In-Reply-To: <499CC728.8060101@redhat.com> References: <499CC728.8060101@redhat.com> Message-ID: <49A33A1A.9030100@redhat.com> Cole Robinson wrote: > Hi all, > > The followin patches add a new option to virt-install: --import. The > option wraps a new installer, which is used to build a guest around an > existing disk image, skipping the OS install step. > > The patches are: > > 1 - Add new ImportInstaller class > 2 - Add virt-install --import option > These are applied now. Thanks, Cole From crobinso at redhat.com Tue Feb 24 00:07:13 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 19:07:13 -0500 Subject: [et-mgmt-tools] [PATCH] virt-clone --original-xml option In-Reply-To: <499CC688.2020800@redhat.com> References: <499CC688.2020800@redhat.com> Message-ID: <49A33A31.8000404@redhat.com> Cole Robinson wrote: > Hi all, > > The attached patch adds a new command line option to virt-clone: > --original-xml. This allows the user to specify the guest to clone as an > xml file, rather than require the use of a guest defined on the current > connection. The backend code in CloneManager is already present (I > recently added it to help build up a test suite). > This is applied now. Thanks, Cole From crobinso at redhat.com Tue Feb 24 00:07:56 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 19:07:56 -0500 Subject: [et-mgmt-tools] [PATCH] Add 'fullscreen only' VNC scaling option In-Reply-To: <499A07D3.2070207@redhat.com> References: <499A07D3.2070207@redhat.com> Message-ID: <49A33A5C.3020005@redhat.com> Cole Robinson wrote: > The attached patch adds an extra scaling option for a VM's VNC > connection: 'Fullscreen Only'. This required breaking out the UI into > radio buttons rather than a simple boolean checkbox. > Applied now. Thanks, Cole From crobinso at redhat.com Tue Feb 24 00:08:08 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 23 Feb 2009 19:08:08 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: Add global VNC scaling preference In-Reply-To: <499A07E7.3060006@redhat.com> References: <499A07E7.3060006@redhat.com> Message-ID: <49A33A68.4000006@redhat.com> Cole Robinson wrote: > The attached patch adds a global preference to the 'Preferences' dialog > for the default VNC scaling value. The new default for all VMs is > 'Fullscreen Only': since scaling isn't required for day to day use, and > there is a performance penalty, it should be opt in by default. > > All VMs abide this global pref, but can override it in their details > window. However this overwritten value will be forgotten once the > virt-manager is restarted (still working on adding per-vm preferences). > Applied now. Thanks, Cole From josir at globo.com Wed Feb 25 11:30:52 2009 From: josir at globo.com (Josir Gomes) Date: Wed, 25 Feb 2009 08:30:52 -0300 Subject: [et-mgmt-tools] VMs do not show up in virt-manager - Ubuntu Message-ID: <49A52BEC.9010907@globo.com> > > I created some KVM VMs with "virsh define" > > I can open it with virt-viewer and vms are working fine. > > > > But I can't see them on virt-manager. What am I doing wrong ? > > The configuration is not automatic? > > > > Host: Ubuntu 8.04 64bits > > Guests: ubuntu 8.04 64bits > > virt-manager (0.5.3) > > > My guess is you aren't using the same URI between the two. To see the libvirt URI you are using from virt-manager: Run virt-manager Double click the connection row whose URI you want to see Edit->Connection Details To see the libvirt URI you are using with virsh: Run 'virsh uri' Hope that helps, Cole -------------------------------------- Hi Cole, your tip works perfectly. Thanks a lot! The connection was set to qemu:///sessions. When I change to localhost on virt-manager, it worked. Default URI should be qemu:///system Now I can see running VMs, but I can't see their definition in order to start them using exclusively virt-manager. How can I achieve this ? And where this virt-manager settings were stored ? Thanks again. Josir. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rssjames at googlemail.com Wed Feb 25 12:03:47 2009 From: rssjames at googlemail.com (Rob James) Date: Wed, 25 Feb 2009 12:03:47 +0000 Subject: [et-mgmt-tools] Making labels selectable in properties dialog Message-ID: <5e5815d10902250403l780aae6bw11a4302e5c103adc@mail.gmail.com> Hi all, i was trying to make a label in the properties dialog selectable to make it easy to copy and paste the value (specifically the "source path" value under Disk). I tried using glade-2 to do it which works but seems to screw up the alignment of pretty much everything else. Is there something obvious I'm doing wrong? -R From crobinso at redhat.com Wed Feb 25 13:46:42 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 25 Feb 2009 08:46:42 -0500 Subject: [et-mgmt-tools] Making labels selectable in properties dialog In-Reply-To: <5e5815d10902250403l780aae6bw11a4302e5c103adc@mail.gmail.com> References: <5e5815d10902250403l780aae6bw11a4302e5c103adc@mail.gmail.com> Message-ID: <49A54BC2.3070403@redhat.com> Rob James wrote: > Hi all, i was trying to make a label in the properties dialog > selectable to make it easy to copy and paste the value (specifically > the "source path" value under Disk). I tried using glade-2 to do it > which works but seems to screw up the alignment of pretty much > everything else. Is there something obvious I'm doing wrong? > Yes, we use glade-3 nowadays for the UI. Going backwards seems to mess up all the UI alignment. Give glade-3 a shot and see how it goes. Thanks, Cole From rssjames at googlemail.com Wed Feb 25 17:02:39 2009 From: rssjames at googlemail.com (Rob James) Date: Wed, 25 Feb 2009 17:02:39 +0000 Subject: [et-mgmt-tools] Making labels selectable in properties dialog In-Reply-To: <49A54BC2.3070403@redhat.com> References: <5e5815d10902250403l780aae6bw11a4302e5c103adc@mail.gmail.com> <49A54BC2.3070403@redhat.com> Message-ID: <5e5815d10902250902p1496e9c6y69d95cb8044c6a4d@mail.gmail.com> Ah, OK, that seems better. I've attached the bundle for the patch. Would you be able to review for me? i wasn't able to test against head though as when compiling the hg source here it won't show the details page ('NoneType' object is not iterable). On Wed, Feb 25, 2009 at 1:46 PM, Cole Robinson wrote: > Rob James wrote: >> Hi all, i was trying to make a label in the properties dialog >> selectable to make it easy to copy and paste the value (specifically >> the "source path" value under Disk). I tried using glade-2 to do it >> which works but seems to screw up the alignment of pretty much >> everything else. Is there something obvious I'm doing wrong? >> > > Yes, we use glade-3 nowadays for the UI. Going backwards seems to mess > up all the UI alignment. > > Give glade-3 a shot and see how it goes. > > Thanks, > Cole > > -------------- next part -------------- A non-text attachment was scrubbed... Name: select-props.hg Type: application/octet-stream Size: 4010 bytes Desc: not available URL: From ben at nerp.net Thu Feb 26 02:11:57 2009 From: ben at nerp.net (Ben Kochie) Date: Wed, 25 Feb 2009 18:11:57 -0800 (PST) Subject: [et-mgmt-tools] Support for kvm/qemu cache mode Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Libvirt now supports an xml bit to select qemu cache types. It would be nice to select this with -disk in virt-install. I've started looking at the VirtualDisk.py source to see where something like that would go. If anyone is working on this, or has ideas, please let me know. I was thinking the virt-install command would look like: virt-install -disk "path=/path/to/dev,cache=writethrough" - -ben "UNIX is user-friendly, it's just picky about its friends." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJpfpvfYg2asD844oRAv7FAJwI7DXtf4IthPTLi7xI69w84lHTYwCcCiZc /U1nRqKKLPee+Vhu/DGwLek= =O/Yh -----END PGP SIGNATURE----- From crobinso at redhat.com Thu Feb 26 04:03:49 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 25 Feb 2009 23:03:49 -0500 Subject: [et-mgmt-tools] Support for kvm/qemu cache mode In-Reply-To: References: Message-ID: <49A614A5.7060506@redhat.com> Ben Kochie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Libvirt now supports an xml bit to select qemu cache types. > > > > > > > > It would be nice to select this with -disk in virt-install. Cool! Sounds good. > started looking at the VirtualDisk.py source to see where something like > that would go. If anyone is working on this, or has ideas, please let > me know. > Following existing convention should be sufficient. Add cache as a VirtualDisk __init__ parameter, setup a simple set_*/get_* property, and if it's present, encorporate it the xml in get_config_xml. You could also add some validation tests in tests/validation.py. > I was thinking the virt-install command would look like: > > virt-install -disk "path=/path/to/dev,cache=writethrough" Looks good to me. Please be sure to include documentation in man/en/virt-install.pod (don't worry about actually generating the man page). Thanks, Cole From lugs at linuxmaker.de Thu Feb 26 09:44:12 2009 From: lugs at linuxmaker.de (lugs at linuxmaker.de) Date: Thu, 26 Feb 2009 10:44:12 +0100 Subject: [et-mgmt-tools] Configuration of the virt-manager Message-ID: <200902261044.12753.lugs@linuxmaker.de> Hello, I'm looking now already since days after the configuration of virt-manager on Debian, but found nothing on the internet or any literature. I now have a machine on Debian/Lenny with KVM and wants use here virtual machines on logical volumes. With virt-manager should indeed be a breeze, but it is not, because the configuration of virt-manager is still opaque to me. If I have virt-manager and the traces on the workstation installed the program I want to start now, I get the messages Unable to open connection to hypervisor URI 'qemu+ssh://192.168.0.3/system': Die Verbindung wurde vom Kommunikationspartner zur?ckgesetzt Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 486, in _open_thread None], flags) File "/usr/lib/python2.5/site-packages/libvirt.py", line 99, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: Die Verbindung wurde vom Kommunikationspartner zur?ckgesetzt I assume that the /etc/libvirt/libvirtd.conf on the workstation and possibly on the KVM-server must be configured accordingly. But now I don't know how. Also tell me the URI syntax not so much. Is what I intend "qemu + ssh: / /" the right thing? Have I "/ system" on 192.168.0.3 to establish or it is a directory or it is a service? So I would have a little more explanatory information very grateful, as what man virt-manager or info virt-manager offer. And the Internet unfortunately, also provides not so much. Many thanks Andreas From crobinso at redhat.com Fri Feb 27 22:50:15 2009 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 27 Feb 2009 17:50:15 -0500 Subject: [et-mgmt-tools] RFC: virt-manager: Redesigned 'New VM' wizard Message-ID: <49A86E27.20605@redhat.com> Hi all, The current 'New VM' wizard has clearly started to show its age. The original design was largely based on xen specific assumptions and the state of libvirt/virtinst at the time: many of those assumptions don't apply today, or require a bit more thought since we now support both xen and qemu based VMs. You can find a patch for a new implementation of the 'New VM' wizard here: http://fedorapeople.org/~crobinso/virt-manager/newvm2/virt-manager-newvm-01.patch I hope you'll agree it's a much simpler and usable layout, without sacrificing functionality (even laying the groundwork for future improvements). This design was largely done by Tim Allen (former Red Hatter) and Jeremy Perry (current Red Hatter), so a big thank you to them. One of the biggest changes from the old design is that we don't ask upfront about paravirt vs. fullvirt, VM architecture, or qemu vs. kvm vs. xenner. For new users, this has been an endless pain point ("Why can't I install a PV kvm guest?" among others) and is really a distinction we don't need to force on people upfront: we are certainly in a position to choose sensible defaults (and for kvm, paravirt/virtio has always been setup in the background depending on what OS version is being installed). The logic for the defaults is as follows: - For the qemu libvirt driver, use the first available of the following: kvm, plain qemu, xenner. - For the xen libvirt driver, use paravirt if the user selects a URL install and the tree supports it, otherwise use fullvirt. - Always default to the host architecture for new VMs. We allow the user to deviate from these defaults in the final screen under the 'Advanced Options' section. Also, you'll notice there is a generic 'Computer' icon in the wizard header: this will soon be replaced by a custom icon. So, some screenshots! Page 1: VM Name and Install method http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg1-1.png http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg1-2.png We totally scrapped the 'intro' page: I don't think anyone will miss it. Having the 'name' box occupy an entire page by itself was also a bit overkill, so we did away with that as well. The one new piece here is the option to choose the libvirt connection to install on. Rather than have the 'New' button on the main manager window be conditionally sensitive, the user can now always launch the wizard, choosing the connection from there. If there is only 1 active connection, the drop down will appear as a label. Page 2: Install media info http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg2-local.png http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg2-url.png http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg2-pxe.png Pending what the user chooses on page 1, the appropriate screen will be shown on page 2. This hasn't deviated much from the current options: the one difference is that the OS Type/Variant drop downs will always be here. This will allow us in the future to offer automatic distro detection per selected install media (we may have this for URL installs by the time the release goes out). Since PXE installs require no extra input, the screen will only have the OS Type/Variant option listed. Page 3: CPU + Mem details http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg3-1.png We dropped the max memory vs. default memory split in the existing wizard: this doesn't have much meaning the qemu/kvm world, and even for xen isn't something that needs to be asked up front. The user can always change it later. Also, rather than list tons of warning information about overcommitting vcpus, we simply cap the amount at the number available on the host. If for some reason a user wants to allocate more than the host amount of virtual cpus to a VM (say for development purposes) it can easily be done post-install. Page 4: Storage http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg4-1.png The main change here is that we removed the block device vs. file device dichotomy: we are pretty capable of determining this distinction behind the scenes. The option is also now available to skip adding storage altogether: this is useful in the case of Live CDs or diskless PXE booting. When adding storage though, the two options are now: 1 - "Create a disk image on the computer's hard drive": We set up a libvirt storage pool behind the scenes to point to the default location (if using PolicyKit or running as root, this is /var/lib/libvirt/images) and allocate a disk image based on the requested size. In the future, the default location will be configurable with a global preference. 2 - "Use managed or other existing storage" : This allows pointing to an existing path, or provisioning more complex storage on demand (this is dependent on a libvirt storage API aware browser dialog, which is ongoing work. For the time being, this just launches a local GTK file browser). The one piece not shown here is the option to choose sparse Vs. non-sparse. We will be putting this back in before the final version is done. Page 5: Summary and Advanced Options http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-1.png http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-2.png http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-3.png 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. For networking, the default is: - A bridge device if any exist, else - Virtual Network 'default' (comes out of the box with libvirt), else - First available virtual network, else - no networking! This logic will be globally configurable at some point, if you wanted to use a specific bridge device or virtual network for all new VMs. We also decided to put all the available networking options into 1 drop down, rather than have 2 separate sections for bridges vs. virtual networking. I think that covers all the significant bits, hopefully other than that the screenshots speak for themselves. Any feedback is appreciated: none of this set in stone. Thanks, Cole From agx at sigxcpu.org Sat Feb 28 18:19:09 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 28 Feb 2009 19:19:09 +0100 Subject: [et-mgmt-tools] virt-manager: acquire kerberos tgt Message-ID: <20090228181909.GA7612@bogon.ms20.nix> Hi, recent krb5-auth-dialog svn has a dbus interface which can be used to acquire a tgt. Here's a simple patch for virt-manager to use it: http://honk.sigxcpu.org/unsorted-patches/virt-manager_acquire-tgt.diff Cheers, -- Guido