From berrange at redhat.com Wed Oct 1 09:46:41 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Oct 2008 10:46:41 +0100 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation In-Reply-To: <48E0F787.4030708@redhat.com> References: <20080925105424.GB6491@bogon.ms20.nix> <48E0F787.4030708@redhat.com> Message-ID: <20081001094641.GE26567@redhat.com> On Mon, Sep 29, 2008 at 11:43:03AM -0400, Cole Robinson wrote: > Guido G?nther wrote: > > Hi, > > currently we don't check if a network is already running, when trying to > > create a new machine in virt-manager. Attached patch starts the network > > if it's not running instead of throwing an exception at the user, > > adresses a Debian bug [1]. > > Cheers, > > -- Guido > > > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499867 > > > > Hmm, I'm not sure if I like this idea. Assumably the network is > 'off' for a reason, so if the user doesn't know any better, I'd > rather not just turn it on without their potentially knowing. > > I think the problem here is that it isn't made clear in the > drop down whether a virtual network is running or not. If we > listed all the nets, but prevented the inactive ones from > being selected (kind of like unbridged nics are presented) > hopefully the user would get the point that they need to > explicitly enable the network to use it. We could even allow > selecting the inactive network and then prompt to start > it. Yep, as you say, there're two problems here. When creating the VM we need to make it clear which networks are active, and which are not - but still allow selection of an inactive network. When starting a VM, we need to check fi the network is active. If it is not, we should popup a confirmation dialog informing the user, and /asking/ if we should automatically start the network at this time. 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 fj0588di at aa.jp.fujitsu.com Wed Oct 1 09:48:27 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Wed, 1 Oct 2008 18:48:27 +0900 Subject: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH] virt-managercalls migration API In-Reply-To: <20080919100727.GM18194@redhat.com> References: <200809081809.GFC73482.699JGEK0@aa.jp.fujitsu.com> <48C4EF66.9070400@redhat.com> <200809112004.FEC57380.J0G9K96E@aa.jp.fujitsu.com> <200809191843.GCG69223.96J09KGE@aa.jp.fujitsu.com> <20080919100727.GM18194@redhat.com> Message-ID: <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> Hi, Daniel Sorry for delaying response. Thank you for your suggestions. I understand. I will make the prototype patch! Thanks Shigeki Sakamoto. > On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote: > > > > > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > > > development happens, > > > > > > OK. For this, I tried to hear in et-mgmt-list. > > > > > > > I'm sorry to be pressing, but would you give me a comment on this patch for > > going on the next step to migrate from virt-manager ? > > I attached screenshots this patch shows. > > I think rather than having it popup a new window with a list of hosts to > migrate to, you could just have a sub-menu where you choose the destination > host directly. > > eg, > > right-click > | > +- Run > Pause > Shutdown > -------- > Migrate ----> host1.example.com > host2.example.com > host3.example.com > ...etc... > > When the user selects one of these hosts, it'd popup a confirmation > window, and do the neccessary migration checks, and then allow the > admin to confirm to start the migration. > > > > > I sent an e-mail last month with proposals for doing this within libvirt. I put > > > > up all of the information I have in the libvirt wiki here: > > > > > > > > http://wiki.libvirt.org/page/TodoPreMigrationChecks > > > > > > Thank you for your information. I see above libvirt wiki and I have a few > > > idea adding checks within libvirt. These point of view are Guest and Host sanity > > > in BASIC CHECKS. How about this points ? > > > > > > 1)Guest sanity is checking whether already existing or not on the destination. > > > Otherwise the uniqueness of the domain(UUID, name) are lost. > > > * I think that it is right to check this in libvirt. How do you think this ? > > Yes, checking for name/uuid uniqueness has to be done inside libvirt by > each hypervisor driver according to their own rules. > > > > 2)Host sanity is checking whether a migration flag is ON at each virtualization. > > virt-manager will need to check the kind of things on the TodoPreMigrationChecks > wiki page. > > > Daniel > -- > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From berrange at redhat.com Wed Oct 1 09:50:28 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Oct 2008 10:50:28 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial consoles as tabs in 'details' window In-Reply-To: <48E24DFD.4050105@redhat.com> References: <48E24DFD.4050105@redhat.com> Message-ID: <20081001095028.GF26567@redhat.com> On Tue, Sep 30, 2008 at 12:04:13PM -0400, Cole Robinson wrote: > The attached patch combines the serial console window > with the VM details window. Opening the serial console > now appends a tab to the details view. In addition, > multiple serial consoles are now supported, not just > the primary/first defined console, though this still > only works for 'pty' devices. > > The patch does three things: > > 1) Remove all the previous plumbing needed to keep track > of the separate console window > 2) Fix the vmmSerialConsole class to extend gtk.HBox, so > we can reuse most of the code in a notebook tab. > 3) Add all the plumbing in details.py to deal with adding > and removing tabs on the fly. > > Screenshot of a couple tab examples: > > http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab1.png > > Screenshot of selecting which serial console to open > (unsupported console types will have entries, they will > just be disabled as shown): > > http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab2.png > > Screenshot of terminal right click menu. Tabs can be > closed via this menu, or the 'View' menu shown in the > second screenshot. > > http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab3.png > > Any comments appreciated. This all basically looks good to me. Though what is the behaviour when running against a remote VM ? Do we simply not create the extra tabs, or do we create them and populate them with a message saying the serial console is not accessible ? I'd probably suggest the latter, also doing it for non-PTY devices. This gives the user reassurance that we have actually detected their serial devices, and are simply unable to access them. Eventually we can add support for connecting to at least TCP and UNIX domain sockets fairly easily. UDP probably doesn't make any sense in the context of virt-maanger, because that config is primarily for purpose of net-console logging. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Oct 1 09:54:30 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Oct 2008 10:54:30 +0100 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E29C81.7040807@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> Message-ID: <20081001095430.GG26567@redhat.com> On Tue, Sep 30, 2008 at 05:39:13PM -0400, Joey Boggs wrote: > Here's a sample that works, just want to verify it's alright. Is 64MB > too much/too little to read at one time? > > > f = open("test.raw","r") > m = sha.new() > while 1: > chunk = f.read(65536) > if not chunk: > break > m.update(chunk) > print m.hexdigest() Both md5 and sha1 are becoming obsolete, and indeed forbidden by some of the more paranoid organizations. I'd recommend we go straight to using at least sha256. Also the docs recommend using hashlib module directly, eg import hashlib m = hashlib.sha256() while 1: chunk = f.read(65536) if not chunk: break m.update(chunk) print m.hexdigest() Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Wed Oct 1 13:43:54 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 01 Oct 2008 09:43:54 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <20081001095430.GG26567@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> Message-ID: <48E37E9A.8050604@redhat.com> Daniel P. Berrange wrote: > On Tue, Sep 30, 2008 at 05:39:13PM -0400, Joey Boggs wrote: >> Here's a sample that works, just want to verify it's alright. Is 64MB >> too much/too little to read at one time? >> >> >> f = open("test.raw","r") >> m = sha.new() >> while 1: >> chunk = f.read(65536) >> if not chunk: >> break >> m.update(chunk) >> print m.hexdigest() > > Both md5 and sha1 are becoming obsolete, and indeed forbidden by some > of the more paranoid organizations. I'd recommend we go straight > to using at least sha256. Also the docs recommend using hashlib module > directly, eg > > import hashlib > > m = hashlib.sha256() > while 1: > chunk = f.read(65536) > if not chunk: > break > m.update(chunk) > print m.hexdigest() > > Daniel Yeah, the only problem with hashlib is that it's python2.5 only. But we could just catch the import error and disable the functionality if need be. As far as md5 or sha1, no comment, though we probably want to support whatever other config formats use (if any do indeed offer hash support). - Cole From crobinso at redhat.com Wed Oct 1 14:02:36 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 01 Oct 2008 10:02:36 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial consoles as tabs in 'details' window In-Reply-To: <20081001095028.GF26567@redhat.com> References: <48E24DFD.4050105@redhat.com> <20081001095028.GF26567@redhat.com> Message-ID: <48E382FC.8080003@redhat.com> Daniel P. Berrange wrote: > On Tue, Sep 30, 2008 at 12:04:13PM -0400, Cole Robinson wrote: >> The attached patch combines the serial console window >> with the VM details window. Opening the serial console >> now appends a tab to the details view. In addition, >> multiple serial consoles are now supported, not just >> the primary/first defined console, though this still >> only works for 'pty' devices. >> >> The patch does three things: >> >> 1) Remove all the previous plumbing needed to keep track >> of the separate console window >> 2) Fix the vmmSerialConsole class to extend gtk.HBox, so >> we can reuse most of the code in a notebook tab. >> 3) Add all the plumbing in details.py to deal with adding >> and removing tabs on the fly. >> >> Screenshot of a couple tab examples: >> >> http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab1.png >> >> Screenshot of selecting which serial console to open >> (unsupported console types will have entries, they will >> just be disabled as shown): >> >> http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab2.png >> >> Screenshot of terminal right click menu. Tabs can be >> closed via this menu, or the 'View' menu shown in the >> second screenshot. >> >> http://fedorapeople.org/~crobinso/virt-manager/vmm-serial-tab3.png >> >> Any comments appreciated. > > This all basically looks good to me. Though what is the behaviour > when running against a remote VM ? Do we simply not create the > extra tabs, or do we create them and populate them with a message > saying the serial console is not accessible ? I'd probably > suggest the latter, also doing it for non-PTY devices. This gives > the user reassurance that we have actually detected their serial > devices, and are simply unable to access them. > Remote and non-pty serial devices show up as an insensitive entry in the View->Serial Consoles list (see screenshot 2). I prefer the current method, rather than opening a tab indiscriminately. Some serial types will never make sense to open directly ('null', 'dev' if I understand it correctly). Other types can be supported later, so maybe it just makes sense to have a tooltip popup on the disabled list entries saying 'Type 'blah' not yet supported' or 'Remote serial not yet supported'. That way the user is sure that we see their serial device, but are explicitly rejecting it, and they can see it at a glance rather than having to open a tab. > Eventually we can add support for connecting to at least TCP and > UNIX domain sockets fairly easily. UDP probably doesn't make any > sense in the context of virt-maanger, because that config is > primarily for purpose of net-console logging. > Agreed, should be pretty painless to add the new functionality into this framework as well. Thanks, Cole From berrange at redhat.com Wed Oct 1 14:06:21 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Oct 2008 15:06:21 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial consoles as tabs in 'details' window In-Reply-To: <48E382FC.8080003@redhat.com> References: <48E24DFD.4050105@redhat.com> <20081001095028.GF26567@redhat.com> <48E382FC.8080003@redhat.com> Message-ID: <20081001140621.GN26567@redhat.com> On Wed, Oct 01, 2008 at 10:02:36AM -0400, Cole Robinson wrote: > Daniel P. Berrange wrote: > Remote and non-pty serial devices show up as an insensitive > entry in the View->Serial Consoles list (see screenshot 2). > I prefer the current method, rather than opening a tab > indiscriminately. Some serial types will never make sense to > open directly ('null', 'dev' if I understand it correctly). Ah, yes i missed that first time around. That'll do for now unless people complain in BZ. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jboggs at redhat.com Wed Oct 1 14:37:17 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 01 Oct 2008 10:37:17 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E37E9A.8050604@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> Message-ID: <48E38B1D.6040200@redhat.com> I'm done creating a sha256 hash setup should I offer more than just sha256for now? and checksum generation is off by default Here's a preview. Not sure how to catch the module import failure for hashlib though Cole Robinson wrote: > Daniel P. Berrange wrote: > >> On Tue, Sep 30, 2008 at 05:39:13PM -0400, Joey Boggs wrote: >> >>> Here's a sample that works, just want to verify it's alright. Is 64MB >>> too much/too little to read at one time? >>> >>> >>> f = open("test.raw","r") >>> m = sha.new() >>> while 1: >>> chunk = f.read(65536) >>> if not chunk: >>> break >>> m.update(chunk) >>> print m.hexdigest() >>> >> Both md5 and sha1 are becoming obsolete, and indeed forbidden by some >> of the more paranoid organizations. I'd recommend we go straight >> to using at least sha256. Also the docs recommend using hashlib module >> directly, eg >> >> import hashlib >> >> m = hashlib.sha256() >> while 1: >> chunk = f.read(65536) >> if not chunk: >> break >> m.update(chunk) >> print m.hexdigest() >> >> Daniel >> > > Yeah, the only problem with hashlib is that it's python2.5 > only. But we could just catch the import error and disable > the functionality if need be. > > As far as md5 or sha1, no comment, though we probably want > to support whatever other config formats use (if any do > indeed offer hash support). > > - Cole > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-disk-signature-virtimage-10-1-1030.patch Type: text/x-patch Size: 2853 bytes Desc: not available URL: From berrange at redhat.com Wed Oct 1 14:42:05 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Oct 2008 15:42:05 +0100 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E37E9A.8050604@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> Message-ID: <20081001144205.GA30576@redhat.com> On Wed, Oct 01, 2008 at 09:43:54AM -0400, Cole Robinson wrote: > Daniel P. Berrange wrote: > > On Tue, Sep 30, 2008 at 05:39:13PM -0400, Joey Boggs wrote: > >> Here's a sample that works, just want to verify it's alright. Is 64MB > >> too much/too little to read at one time? > >> > >> > >> f = open("test.raw","r") > >> m = sha.new() > >> while 1: > >> chunk = f.read(65536) > >> if not chunk: > >> break > >> m.update(chunk) > >> print m.hexdigest() > > > > Both md5 and sha1 are becoming obsolete, and indeed forbidden by some > > of the more paranoid organizations. I'd recommend we go straight > > to using at least sha256. Also the docs recommend using hashlib module > > directly, eg > > > > import hashlib > > > > m = hashlib.sha256() > > while 1: > > chunk = f.read(65536) > > if not chunk: > > break > > m.update(chunk) > > print m.hexdigest() > > > > Daniel > > Yeah, the only problem with hashlib is that it's python2.5 > only. But we could just catch the import error and disable > the functionality if need be. > > As far as md5 or sha1, no comment, though we probably want > to support whatever other config formats use (if any do > indeed offer hash support). I suggest then we include multiple checksums. Either a md5 or sha1 checksum which we can do everywhere, and a second sha256 checksum for stronger validation where available. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Oct 1 14:43:28 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Oct 2008 15:43:28 +0100 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E38B1D.6040200@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> Message-ID: <20081001144328.GB30576@redhat.com> On Wed, Oct 01, 2008 at 10:37:17AM -0400, Joey Boggs wrote: > I'm done creating a sha256 hash setup should I offer more than just > sha256for now? and checksum generation is off by default > > Here's a preview. Not sure how to catch the module import failure for > hashlib though If we go for doing a compulsory md5 checksum, and optional sha256 checksum with new enough python, then something like.... try: import hashlib m1 = hashlib.md5() m2 = hashlib.sha256() except: import md5 m1 = md5.new() m2 = None Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jboggs at redhat.com Wed Oct 1 16:27:46 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 01 Oct 2008 12:27:46 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <20081001144328.GB30576@redhat.com> References: <48DD3F79.1010504@redhat.com> <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> <20081001144328.GB30576@redhat.com> Message-ID: <48E3A502.6010104@redhat.com> Here's an update, will this work best or any other suggestions? try: import hashlib m1 = hashlib.md5(path) m2 = hashlib.sha256(path) except: import md5 m1 = md5.new(path) m2 = None f = open(path,"r") while 1: chunk = f.read(65536) if not chunk: break m1.update(chunk) md5checksum = m1.hexdigest() if m2: m2.update(chunk) shachecksum = m2.hexdigest() storage.append(""" %s\n""" % md5checksum) if shachecksum: storage.append(""" %s\n""" % shachecksum) storage.append(""" \n""") Daniel P. Berrange wrote: > On Wed, Oct 01, 2008 at 10:37:17AM -0400, Joey Boggs wrote: > >> I'm done creating a sha256 hash setup should I offer more than just >> sha256for now? and checksum generation is off by default >> >> Here's a preview. Not sure how to catch the module import failure for >> hashlib though >> > > If we go for doing a compulsory md5 checksum, and optional > sha256 checksum with new enough python, then something > like.... > > try: > import hashlib > m1 = hashlib.md5() > m2 = hashlib.sha256() > except: > import md5 > m1 = md5.new() > m2 = None > > > Daniel > From berrange at redhat.com Wed Oct 1 16:41:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Oct 2008 17:41:08 +0100 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E3A502.6010104@redhat.com> References: <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> <20081001144328.GB30576@redhat.com> <48E3A502.6010104@redhat.com> Message-ID: <20081001164108.GC30576@redhat.com> On Wed, Oct 01, 2008 at 12:27:46PM -0400, Joey Boggs wrote: > Here's an update, will this work best or any other suggestions? > > try: > import hashlib > m1 = hashlib.md5(path) > m2 = hashlib.sha256(path) > except: > import md5 > m1 = md5.new(path) > m2 = None > > f = open(path,"r") > while 1: > chunk = f.read(65536) > if not chunk: > break > m1.update(chunk) > md5checksum = m1.hexdigest() > > if m2: > m2.update(chunk) > shachecksum = m2.hexdigest() hexdigest() should only be called at end, outside the loop. As it stands you're computing a checksum for each chunk & resetting it Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jboggs at redhat.com Wed Oct 1 16:46:26 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 01 Oct 2008 12:46:26 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <20081001164108.GC30576@redhat.com> References: <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> <20081001144328.GB30576@redhat.com> <48E3A502.6010104@redhat.com> <20081001164108.GC30576@redhat.com> Message-ID: <48E3A962.1020601@redhat.com> That's one thing I forgot to move out of the loop before I sent it. I was still working on the handling of m2 missing prior to that and put it inside the loop for testing. Once moved should that be good to go? Daniel P. Berrange wrote: > On Wed, Oct 01, 2008 at 12:27:46PM -0400, Joey Boggs wrote: > >> Here's an update, will this work best or any other suggestions? >> >> try: >> import hashlib >> m1 = hashlib.md5(path) >> m2 = hashlib.sha256(path) >> except: >> import md5 >> m1 = md5.new(path) >> m2 = None >> >> f = open(path,"r") >> while 1: >> chunk = f.read(65536) >> if not chunk: >> break >> m1.update(chunk) >> md5checksum = m1.hexdigest() >> >> if m2: >> m2.update(chunk) >> shachecksum = m2.hexdigest() >> > > hexdigest() should only be called at end, outside > the loop. As it stands you're computing a checksum > for each chunk & resetting it > > Daniel > From jboggs at redhat.com Wed Oct 1 21:15:17 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 01 Oct 2008 17:15:17 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E3A962.1020601@redhat.com> References: <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> <20081001144328.GB30576@redhat.com> <48E3A502.6010104@redhat.com> <20081001164108.GC30576@redhat.com> <48E3A962.1020601@redhat.com> Message-ID: <48E3E865.7090601@redhat.com> Here's what I've got, moved the hexdigest() out of the loop, cleanup and more testing to verify each scenario outputs the right xml configuration data. Hope this is the final revision :) Joey Boggs wrote: > That's one thing I forgot to move out of the loop before I sent it. I > was still working on the handling of m2 missing prior to that and put > it inside the loop for testing. Once moved should that be good to go? > > Daniel P. Berrange wrote: >> On Wed, Oct 01, 2008 at 12:27:46PM -0400, Joey Boggs wrote: >> >>> Here's an update, will this work best or any other suggestions? >>> >>> try: >>> import hashlib >>> m1 = hashlib.md5(path) >>> m2 = hashlib.sha256(path) >>> except: >>> import md5 >>> m1 = md5.new(path) >>> m2 = None >>> >>> f = open(path,"r") >>> while 1: >>> chunk = f.read(65536) >>> if not chunk: >>> break >>> m1.update(chunk) >>> md5checksum = m1.hexdigest() >>> >>> if m2: >>> m2.update(chunk) >>> shachecksum = m2.hexdigest() >>> >> >> hexdigest() should only be called at end, outside >> the loop. As it stands you're computing a checksum >> for each chunk & resetting it >> >> Daniel >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-disk-signature-virtimage-10-1-1712.patch Type: text/x-patch Size: 3004 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 2 13:21:41 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 2 Oct 2008 15:21:41 +0200 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation In-Reply-To: <20081001094641.GE26567@redhat.com> References: <20080925105424.GB6491@bogon.ms20.nix> <48E0F787.4030708@redhat.com> <20081001094641.GE26567@redhat.com> Message-ID: <20081002132141.GA15878@bogon.ms20.nix> On Wed, Oct 01, 2008 at 10:46:41AM +0100, Daniel P. Berrange wrote: [..snip..] > Yep, as you say, there're two problems here. When creating the > VM we need to make it clear which networks are active, and which > are not - but still allow selection of an inactive network. > > When starting a VM, we need to check fi the network is active. If > it is not, we should popup a confirmation dialog informing the > user, and /asking/ if we should automatically start the network > at this time. Attached patch does just this - inactive networks are postfixed with " (Inactive)" and when leaving the tab you're asked if you want to start the newtork. I'd split this into two but there doesn't seem to be a hg equivalient of "git rebase -i; git reset HEAD^; git add -p" - so splitting patches is much more cumbersome or am I missing something? Cheers, -- Guido From crobinso at redhat.com Thu Oct 2 13:48:09 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 02 Oct 2008 09:48:09 -0400 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation In-Reply-To: <20081002132141.GA15878@bogon.ms20.nix> References: <20080925105424.GB6491@bogon.ms20.nix> <48E0F787.4030708@redhat.com> <20081001094641.GE26567@redhat.com> <20081002132141.GA15878@bogon.ms20.nix> Message-ID: <48E4D119.2050909@redhat.com> Guido G?nther wrote: > On Wed, Oct 01, 2008 at 10:46:41AM +0100, Daniel P. Berrange wrote: > [..snip..] >> Yep, as you say, there're two problems here. When creating the >> VM we need to make it clear which networks are active, and which >> are not - but still allow selection of an inactive network. >> >> When starting a VM, we need to check fi the network is active. If >> it is not, we should popup a confirmation dialog informing the >> user, and /asking/ if we should automatically start the network >> at this time. > Attached patch does just this - inactive networks are postfixed with > " (Inactive)" and when leaving the tab you're asked if you want to start > the newtork. Looks like you forgot to attach it :) > I'd split this into two but there doesn't seem to be a hg equivalient of > "git rebase -i; git reset HEAD^; git add -p" - so splitting patches is > much more cumbersome or am I missing something? I think my hg workflow is pretty rudimentary so I'm not sure, sorry. Thanks, Cole From berrange at redhat.com Thu Oct 2 14:35:02 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 2 Oct 2008 15:35:02 +0100 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation In-Reply-To: <20081002132141.GA15878@bogon.ms20.nix> References: <20080925105424.GB6491@bogon.ms20.nix> <48E0F787.4030708@redhat.com> <20081001094641.GE26567@redhat.com> <20081002132141.GA15878@bogon.ms20.nix> Message-ID: <20081002143502.GA12727@redhat.com> On Thu, Oct 02, 2008 at 03:21:41PM +0200, Guido G?nther wrote: > On Wed, Oct 01, 2008 at 10:46:41AM +0100, Daniel P. Berrange wrote: > [..snip..] > > Yep, as you say, there're two problems here. When creating the > > VM we need to make it clear which networks are active, and which > > are not - but still allow selection of an inactive network. > > > > When starting a VM, we need to check fi the network is active. If > > it is not, we should popup a confirmation dialog informing the > > user, and /asking/ if we should automatically start the network > > at this time. > Attached patch does just this - inactive networks are postfixed with > " (Inactive)" and when leaving the tab you're asked if you want to start > the newtork. > I'd split this into two but there doesn't seem to be a hg equivalient of > "git rebase -i; git reset HEAD^; git add -p" - so splitting patches is > much more cumbersome or am I missing something? I guess you're just doing commits straight ontop of a clone of the repo. If so I'd recommend using Mercurial's patch queue extension - it provides quilt-like functionality integrated into mercurial commands. I use it to maintain & rebase a long stack of patches - you can move up & down through the stack, rebasing at will, until you're ready to submit the patch, or formally commit it to the repository. Edit your $HOME/.hgrc and add [extensions] hgext.mq= Then you can do 'hg qinit' to start a queue, and 'hg qnew NAME' to create a new patch. You can do hg qnew multiple times to stack a series of patches, and 'hg qpop' / 'hg qpush' to move up & down through the stack, and 'hg qseries' to view the set. See 'hg help' for all the other useful commands - all prefixed with a 'q' Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From agx at sigxcpu.org Thu Oct 2 14:51:25 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 2 Oct 2008 16:51:25 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: clear model on populate_opt_media Message-ID: <20081002145125.GA18858@bogon.ms20.nix> Hi, otherwise we keep on adding the same optical devices over and over again. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: clear-opt-drive-list.diff Type: text/x-diff Size: 886 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 2 14:57:09 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 2 Oct 2008 16:57:09 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: populate_device_list on reset_state() Message-ID: <20081002145709.GA24980@bogon.ms20.nix> Hi, otherwise the device list is empty when we open the dialog. Also select the first entry. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: populate-opt-media-on-reset_state.diff Type: text/x-diff Size: 910 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 2 15:01:18 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 2 Oct 2008 17:01:18 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: populate_device_list on media_toggled() Message-ID: <20081002150118.GB24980@bogon.ms20.nix> Hi, otherwise we fill up the device list when the physical device combo box gets deactivated - also select a default entry since the combo box othewise looks empty. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: populate-opt-media-on-activate.diff Type: text/x-diff Size: 1399 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 2 15:11:59 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 2 Oct 2008 17:11:59 +0200 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation In-Reply-To: <48E4D119.2050909@redhat.com> References: <20080925105424.GB6491@bogon.ms20.nix> <48E0F787.4030708@redhat.com> <20081001094641.GE26567@redhat.com> <20081002132141.GA15878@bogon.ms20.nix> <48E4D119.2050909@redhat.com> Message-ID: <20081002151158.GA27510@bogon.ms20.nix> On Thu, Oct 02, 2008 at 09:48:09AM -0400, Cole Robinson wrote: > Looks like you forgot to attach it :) Attached now. Sorry. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: activate-network.diff Type: text/x-diff Size: 1920 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 2 17:30:25 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 2 Oct 2008 19:30:25 +0200 Subject: [et-mgmt-tools] virt-manager: exception when connecting to URI with already running VMs Message-ID: <20081002173025.GA29444@bogon.ms20.nix> Hi, when opening virt-manager and doubleclicking on the previously definded qemu:///system connection which has an already running vm I get: Traceback (most recent call last): File "/usr/local/stow/virt-manager/share/virt-manager/virtManager/details.py", line 540, in hw_selected self.refresh_config_cpu() File "/usr/local/stow/virt-manager/share/virt-manager/virtManager/details.py", line 771, in refresh_config_cpu self.window.get_widget("state-host-cpus").set_text("%d" % self.vm.get_connection().host_active_processor_count()) File "/usr/local/stow/virt-manager/share/virt-manager/virtManager/connection.py", line 615, in host_active_processor_count return self.hostinfo[2] TypeError: 'NoneType' object is unsubscriptable This does not happen when all vms are off. Reason is that we're accessing hostinfo before it has been filled in vmmConnection.tick(). Cheers, -- Guido From agx at sigxcpu.org Thu Oct 2 20:00:53 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 2 Oct 2008 22:00:53 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: don't use cpu_time and get_memory Message-ID: <20081002200053.GA30169@bogon.ms20.nix> Hi, neither cpu_time() nor get_memory() exist anymore so virt-manager throws exceptions when trying to sort columns. Use cpu_time() and current_memory_percentage() instead. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_sorting_exceptions.diff Type: text/x-diff Size: 1331 bytes Desc: not available URL: From crobinso at redhat.com Thu Oct 2 21:38:58 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 02 Oct 2008 17:38:58 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: don't use cpu_time and get_memory In-Reply-To: <20081002200053.GA30169@bogon.ms20.nix> References: <20081002200053.GA30169@bogon.ms20.nix> Message-ID: <48E53F72.5010601@redhat.com> Guido G?nther wrote: > Hi, > neither cpu_time() nor get_memory() exist anymore so virt-manager throws > exceptions when trying to sort columns. Use cpu_time() and > current_memory_percentage() instead. > Cheers, > -- Guido > > I've applied this and all your other patches. Thanks for the bug fixes! - Cole From crobinso at redhat.com Thu Oct 2 21:43:05 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 02 Oct 2008 17:43:05 -0400 Subject: [et-mgmt-tools] virt-manager: exception when connecting to URI with already running VMs In-Reply-To: <20081002173025.GA29444@bogon.ms20.nix> References: <20081002173025.GA29444@bogon.ms20.nix> Message-ID: <48E54069.2000709@redhat.com> Guido G?nther wrote: > Hi, > when opening virt-manager and doubleclicking on the previously definded > qemu:///system connection which has an already running vm I get: > > Traceback (most recent call last): > File "/usr/local/stow/virt-manager/share/virt-manager/virtManager/details.py", line 540, in hw_selected > self.refresh_config_cpu() > File "/usr/local/stow/virt-manager/share/virt-manager/virtManager/details.py", line 771, in refresh_config_cpu > self.window.get_widget("state-host-cpus").set_text("%d" % self.vm.get_connection().host_active_processor_count()) > File "/usr/local/stow/virt-manager/share/virt-manager/virtManager/connection.py", line 615, in host_active_processor_count > return self.hostinfo[2] > TypeError: 'NoneType' object is unsubscriptable > > This does not happen when all vms are off. Reason is that we're > accessing hostinfo before it has been filled in vmmConnection.tick(). Hmm, I hadn't seen this, looks like it's dependent on having the 'view console for all domains' preference option selected. I'll take a look tomorrow. Thanks, Cole From agx at sigxcpu.org Fri Oct 3 00:44:44 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 3 Oct 2008 02:44:44 +0200 Subject: [et-mgmt-tools] [PATCH]: virt-manager: start network before vm creation In-Reply-To: <48E4D119.2050909@redhat.com> References: <20080925105424.GB6491@bogon.ms20.nix> <48E0F787.4030708@redhat.com> <20081001094641.GE26567@redhat.com> <20081002132141.GA15878@bogon.ms20.nix> <48E4D119.2050909@redhat.com> Message-ID: <20081003004444.GA10181@bogon.ms20.nix> Hi, attached is a very first shot at displaying disk and network I/O in virt-manager. No nifty graphs or sparcline yet, but the numbers seem to match to what the guest sees. Is this the right way to go? Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: net_disk_io.diff Type: text/x-diff Size: 15087 bytes Desc: not available URL: From agx at sigxcpu.org Fri Oct 3 13:50:03 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 3 Oct 2008 15:50:03 +0200 Subject: [et-mgmt-tools] [PATCH/RFC]: virt-manager: display disk and network I/O statistics Message-ID: <20081003135003.GA5273@bogon.ms20.nix> Hi, attached is a more complete version of the net/disk I/O statistics patch. Screenshots are here: http://honk.sigxcpu.org/misc/vm-overview.png http://honk.sigxcpu.org/misc/vm-detail.png There's certainly lots of room for improvement. * all units are KBytes/s, that should be changeable * the GtkSparkline graphs display input only. I'd be nice to have in and out in one graph in different colors * the overview looks a bit boring, should we add sparklines there too, like for cpu usage? I've not cleaned up the disk_usage vs disk_io naming mess yet, since I'd wanted to get some feedback first. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: vmm-io.diff Type: text/x-diff Size: 27829 bytes Desc: not available URL: From crobinso at redhat.com Fri Oct 3 14:25:25 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 03 Oct 2008 10:25:25 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: show serial consoles as tabs in 'details' window In-Reply-To: <20081001140621.GN26567@redhat.com> References: <48E24DFD.4050105@redhat.com> <20081001095028.GF26567@redhat.com> <48E382FC.8080003@redhat.com> <20081001140621.GN26567@redhat.com> Message-ID: <48E62B55.7090808@redhat.com> Daniel P. Berrange wrote: > On Wed, Oct 01, 2008 at 10:02:36AM -0400, Cole Robinson wrote: >> Daniel P. Berrange wrote: >> Remote and non-pty serial devices show up as an insensitive >> entry in the View->Serial Consoles list (see screenshot 2). >> I prefer the current method, rather than opening a tab >> indiscriminately. Some serial types will never make sense to >> open directly ('null', 'dev' if I understand it correctly). > > Ah, yes i missed that first time around. That'll do for now unless > people complain in BZ. > > > Daniel Okay, this has been committed with the tooltip changes I mentioned in my previous mail. http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=163403d1f998 Thanks, Cole From crobinso at redhat.com Fri Oct 3 15:15:02 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 03 Oct 2008 11:15:02 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E3E865.7090601@redhat.com> References: <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> <20081001144328.GB30576@redhat.com> <48E3A502.6010104@redhat.com> <20081001164108.GC30576@redhat.com> <48E3A962.1020601@redhat.com> <48E3E865.7090601@redhat.com> Message-ID: <48E636F6.60107@redhat.com> Joey Boggs wrote: > Here's what I've got, moved the hexdigest() out of the loop, cleanup and > more testing to verify each scenario outputs the right xml configuration > data. > > Hope this is the final revision :) > > > > Some comments below. > diff -r 58a909b4f71c virt-convert > --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 > +++ b/virt-convert Wed Oct 01 17:12:45 2008 -0400 > @@ -64,6 +64,8 @@ > opts.add_option("", "--os-variant", type="string", dest="os_variant", > action="callback", callback=cli.check_before_store, > help=("The OS variant for fully virtualized guests, e.g. 'fedora6', 'rhel5', 'solaris10', 'win2k', 'vista'")) > + opts.add_option("", "--checksum", action="store_true", dest="checksum", > + help=("Generate a checksum for a virt-image guest")) > opts.add_option("", "--noapic", action="store_true", dest="noapic", > help=("Disables APIC for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) > opts.add_option("", "--noacpi", action="store_true", dest="noacpi", > @@ -184,6 +186,9 @@ > > unixname = vmdef.name.replace(" ", "-") > > + if options.checksum: > + vmdef.checksum = "yes" > + Rather than use a string yes/no, why not just call the variable 'use_checksum' and have it as a bool value? We probably also want to add an option like checksum_type, since it really isn't a simple yes/no option. If no type is specified, we can just whatever we deem is a sensible default. This can be worked out later though. > if not options.output_dir: > options.output_dir = unixname > try: > diff -r 58a909b4f71c virtconv/parsers/virtimage.py > --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/parsers/virtimage.py Wed Oct 01 17:12:45 2008 -0400 > @@ -171,9 +171,41 @@ > type = "raw" > if disk.type == diskcfg.DISK_TYPE_ISO: > type = "iso" > - storage.append( > - """\n""" % > - (path, type)) > + > + if vm.checksum == "yes": > + md5checksum = None > + shachecksum = None > + > + storage.append("""\n""" % (path, type)) > + > + try: > + import hashlib > + m1 = hashlib.md5(path) > + m2 = hashlib.sha256(path) > + except: > + import md5 > + m1 = md5.new(path) > + m2 = None > + > + f = open(path,"r") > + while 1: > + chunk = f.read(65536) > + if not chunk: > + break > + m1.update(chunk) > + > + if m2: > + m2.update(chunk) > + I tested the above, and it generates different checksums than the cli utils (md5sum, sha256sum). Problem seems to be that you initialize the hash with the file's pathname. Is that intentional? We should probably match the output of the cli utils, so let's make sure the hashes match for both small and large files to be sure we aren't missing anything. > + md5checksum = m1.hexdigest() > + storage.append(""" %s\n""" % md5checksum) > + > + if m2: > + shachecksum = m2.hexdigest() > + storage.append(""" %s\n""" % shachecksum) > + storage.append(""" \n""") > + else: > + storage.append("""\n""" % (path, type)) > > return storage, diskout > > diff -r 58a909b4f71c virtconv/vmcfg.py > --- a/virtconv/vmcfg.py Mon Sep 22 11:32:11 2008 -0400 > +++ b/virtconv/vmcfg.py Wed Oct 01 17:12:45 2008 -0400 > @@ -59,6 +59,7 @@ > self.noapic = None > self.os_type = None > self.os_variant = None > + self.checksum = None > > def validate(self): > """ Thanks, Cole From jboggs at redhat.com Fri Oct 3 15:32:16 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 11:32:16 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E636F6.60107@redhat.com> References: <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> <20081001144328.GB30576@redhat.com> <48E3A502.6010104@redhat.com> <20081001164108.GC30576@redhat.com> <48E3A962.1020601@redhat.com> <48E3E865.7090601@redhat.com> <48E636F6.60107@redhat.com> Message-ID: <48E63B00.9050907@redhat.com> > >> diff -r 58a909b4f71c virt-convert >> --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virt-convert Wed Oct 01 17:12:45 2008 -0400 >> @@ -64,6 +64,8 @@ >> opts.add_option("", "--os-variant", type="string", dest="os_variant", >> action="callback", callback=cli.check_before_store, >> help=("The OS variant for fully virtualized guests, e.g. 'fedora6', 'rhel5', 'solaris10', 'win2k', 'vista'")) >> + opts.add_option("", "--checksum", action="store_true", dest="checksum", >> + help=("Generate a checksum for a virt-image guest")) >> opts.add_option("", "--noapic", action="store_true", dest="noapic", >> help=("Disables APIC for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) >> opts.add_option("", "--noacpi", action="store_true", dest="noacpi", >> @@ -184,6 +186,9 @@ >> >> unixname = vmdef.name.replace(" ", "-") >> >> + if options.checksum: >> + vmdef.checksum = "yes" >> + >> > > Rather than use a string yes/no, why not just call > the variable 'use_checksum' and have it as a bool > value? > > We probably also want to add an option like > checksum_type, since it really isn't a simple > yes/no option. If no type is specified, we can > just whatever we deem is a sensible default. > This can be worked out later though. > > I'll make that change for use_checksum. Would that mean we're only generating 1 checksum by default? > >> + >> + if vm.checksum == "yes": >> + md5checksum = None >> + shachecksum = None >> + >> + storage.append("""\n""" % (path, type)) >> + >> + try: >> + import hashlib >> + m1 = hashlib.md5(path) >> + m2 = hashlib.sha256(path) >> + except: >> + import md5 >> + m1 = md5.new(path) >> + m2 = None >> + >> + f = open(path,"r") >> + while 1: >> + chunk = f.read(65536) >> + if not chunk: >> + break >> + m1.update(chunk) >> + >> + if m2: >> + m2.update(chunk) >> + >> > > I tested the above, and it generates different checksums than > the cli utils (md5sum, sha256sum). Problem seems to be that > you initialize the hash with the file's pathname. Is that > intentional? > > We should probably match the output of the cli utils, so > let's make sure the hashes match for both small and large > files to be sure we aren't missing anything. > > I just discovered that this morning when working on the appliance-creator portions of this and just removed the filename out of the hash. From crobinso at redhat.com Fri Oct 3 15:39:19 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 03 Oct 2008 11:39:19 -0400 Subject: [et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export In-Reply-To: <48E63B00.9050907@redhat.com> References: <48E266FB.2060705@redhat.com> <48E266D2.2020708@redhat.com> <48E26EFB.6000602@redhat.com> <48E27110.2070102@redhat.com> <48E29C81.7040807@redhat.com> <20081001095430.GG26567@redhat.com> <48E37E9A.8050604@redhat.com> <48E38B1D.6040200@redhat.com> <20081001144328.GB30576@redhat.com> <48E3A502.6010104@redhat.com> <20081001164108.GC30576@redhat.com> <48E3A962.1020601@redhat.com> <48E3E865.7090601@redhat.com> <48E636F6.60107@redhat.com> <48E63B00.9050907@redhat.com> Message-ID: <48E63CA7.80701@redhat.com> Joey Boggs wrote: >> >>> diff -r 58a909b4f71c virt-convert >>> --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 >>> +++ b/virt-convert Wed Oct 01 17:12:45 2008 -0400 >>> @@ -64,6 +64,8 @@ >>> opts.add_option("", "--os-variant", type="string", dest="os_variant", >>> action="callback", callback=cli.check_before_store, >>> help=("The OS variant for fully virtualized guests, e.g. 'fedora6', 'rhel5', 'solaris10', 'win2k', 'vista'")) >>> + opts.add_option("", "--checksum", action="store_true", dest="checksum", >>> + help=("Generate a checksum for a virt-image guest")) >>> opts.add_option("", "--noapic", action="store_true", dest="noapic", >>> help=("Disables APIC for fully virtualized guest (overrides value in os-type/os-variant db)"), default=False) >>> opts.add_option("", "--noacpi", action="store_true", dest="noacpi", >>> @@ -184,6 +186,9 @@ >>> >>> unixname = vmdef.name.replace(" ", "-") >>> >>> + if options.checksum: >>> + vmdef.checksum = "yes" >>> + >>> >> Rather than use a string yes/no, why not just call >> the variable 'use_checksum' and have it as a bool >> value? >> >> We probably also want to add an option like >> checksum_type, since it really isn't a simple >> yes/no option. If no type is specified, we can >> just whatever we deem is a sensible default. >> This can be worked out later though. >> >> > I'll make that change for use_checksum. Would that mean we're only > generating 1 checksum by default? Hmm, good question. Maybe just do away with use_checksum. We can have a value checksum_types, which is a list of strings. Then we can define constants like CSUM_MD5, CSUM_SHA256, etc. One of these can be CSUM_DEFAULT, which is up to the individual conversion drivers. So if the list is empty, no csum, otherwise generate a csum for every entry in the list. From jboggs at redhat.com Fri Oct 3 17:08:35 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 13:08:35 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E25FBD.3020800@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> <48E14817.1090401@redhat.com> <48E25FBD.3020800@redhat.com> Message-ID: <48E65193.20007@redhat.com> Made those few cleanups Cole Robinson wrote: > Joey Boggs wrote: > >> Got it all figured out now, its set to raise an exception rather than fail() >> >> Also changed the bus to ide rather than scsi. >> >> >> > > This looks mostly ready, just a few small pieces. > > >> diff -r 58a909b4f71c virt-convert >> --- a/virt-convert Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virt-convert Mon Sep 29 17:22:59 2008 -0400 >> @@ -217,6 +217,8 @@ >> not format and vmcfg.host() == "SunOS"): >> format = "vdisk" >> >> + elif options.output_format == "vmx": >> + format = "vmdk" >> if not format: >> format = "raw" >> >> diff -r 58a909b4f71c virtconv/diskcfg.py >> --- a/virtconv/diskcfg.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/diskcfg.py Mon Sep 29 17:22:59 2008 -0400 >> @@ -181,7 +181,7 @@ >> absout = os.path.join(outdir, relout) >> >> if not (out_format == DISK_FORMAT_VDISK or >> - out_format == DISK_FORMAT_RAW): >> + out_format == DISK_FORMAT_RAW or out_format == DISK_FORMAT_VMDK): >> raise NotImplementedError("Cannot convert to disk format %s" % >> output_format) >> >> diff -r 58a909b4f71c virtconv/parsers/virtimage.py >> --- a/virtconv/parsers/virtimage.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/parsers/virtimage.py Mon Sep 29 17:22:59 2008 -0400 >> @@ -21,10 +21,12 @@ >> import virtconv.formats as formats >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> +import virtconv.netdevcfg as netdevcfg >> import virtinst.FullVirtGuest as fv >> - >> +import virtinst.ImageParser as ImageParser >> from xml.sax.saxutils import escape >> from string import ascii_letters >> +import os >> import re >> >> pv_boot_template = """ >> @@ -183,16 +185,20 @@ >> """ >> name = "virt-image" >> suffix = ".virt-image.xml" >> - can_import = False >> + can_import = True >> can_export = True >> - can_identify = False >> + can_identify = True >> >> @staticmethod >> def identify_file(input_file): >> """ >> Return True if the given file is of this format. >> """ >> - raise NotImplementedError >> + try: >> + image = ImageParser.parse_file(input_file) >> + except ImageParser.ParserException, msg: >> + return False >> > > Please log the failure here. > > >> + return True >> >> @staticmethod >> def import_file(input_file): >> @@ -200,7 +206,52 @@ >> Import a configuration file. Raises if the file couldn't be >> opened, or parsing otherwise failed. >> """ >> - raise NotImplementedError >> + vm = vmcfg.vm() >> + try: >> + config = ImageParser.parse_file(input_file) >> + except Exception, e: >> + raise Exception("Couldn't import file \"%s\": %s" % (input_file, e)) >> + >> > > I'd say raise a ValueError here instead of a plain > Exception. Also, just use single quotes instead of > escaping the double quotes, it's simpler. > > >> + domain = config.domain >> + boot = domain.boots[0] >> + >> + if not config.name: >> + raise ValueError("No Name defined in \"%s\"" % input_file) >> + vm.name = config.name >> + vm.memory = config.domain.memory >> + if config.descr: >> + vm.description = config.descr >> + vm.nr_vcpus = config.domain.vcpu >> + >> + bus = "ide" >> + nr_disks = 0 >> + devid = (bus, nr_disks) >> > > This line is redundant. > > >> + >> + for d in boot.drives: >> + disk = d.disk >> + format = None >> + if disk.format == ImageParser.Disk.FORMAT_RAW: >> + format = diskcfg.DISK_FORMAT_RAW >> + elif format == ImageParser.DISK_FORMAT_VMDK: >> + format == diskcfg.DISK_FORMAT_VMDK >> + >> + if format is None: >> + raise ValueError("Unable to determine disk format") >> + devid = (bus, nr_disks) >> > > You can do away with nr_disks here if you just use > len(vm.disks) > > >> + vm.disks[devid] = diskcfg.disk(bus = bus, >> + type = diskcfg.DISK_TYPE_DISK) >> + vm.disks[devid].format = format >> + vm.disks[devid].path = disk.file >> + nr_disks = nr_disks + 1 >> + >> + nics = domain.interface >> + nr_nics = 0 >> + while nr_nics < nics: >> + vm.netdevs[nr_nics] = netdevcfg.netdev(type = netdevcfg.NETDEV_TYPE_UNKNOWN) >> + nr_nics = nr_nics + 1 >> > > I'd say ditch nr_nics and just use > > while nic_idx in range(0, nics): > vm.netdevs[nic_idx] ... > > >> + """ Eventually need to add support for mac addresses if given""" >> + vm.validate() >> + return vm >> >> @staticmethod >> def export_file(vm, output_file): >> diff -r 58a909b4f71c virtconv/parsers/vmx.py >> --- a/virtconv/parsers/vmx.py Mon Sep 22 11:32:11 2008 -0400 >> +++ b/virtconv/parsers/vmx.py Mon Sep 29 17:22:59 2008 -0400 >> @@ -22,9 +22,62 @@ >> import virtconv.vmcfg as vmcfg >> import virtconv.diskcfg as diskcfg >> import virtconv.netdevcfg as netdevcfg >> - >> +import time >> +import sys >> import re >> import os >> + >> +_VMX_MAIN_TEMPLATE = """ >> +#!/usr/bin/vmplayer >> + >> +# Generated %(now)s by %(progname)s >> +# http://virt-manager.et.redhat.com/ >> + >> +# This is a Workstation 5 or 5.5 config file and can be used with Player >> +config.version = "8" >> +virtualHW.version = "4" >> +guestOS = "other" >> +displayName = "%(vm_name)s" >> +annotation = "%(vm_description)s" >> +guestinfo.vmware.product.long = "%(vm_name)s" >> +guestinfo.vmware.product.url = "http://virt-manager.et.redhat.com/" >> +guestinfo.vmware.product.class = "virtual machine" >> +numvcpus = "%(vm_nr_vcpus)s" >> +memsize = "%(vm_memory)d" >> +MemAllowAutoScaleDown = "FALSE" >> +MemTrimRate = "-1" >> +uuid.action = "create" >> +tools.remindInstall = "TRUE" >> +hints.hideAll = "TRUE" >> +tools.syncTime = "TRUE" >> +serial0.present = "FALSE" >> +serial1.present = "FALSE" >> +parallel0.present = "FALSE" >> +logging = "TRUE" >> +log.fileName = "%(vm_name)s.log" >> +log.append = "TRUE" >> +log.keepOld = "3" >> +isolation.tools.hgfs.disable = "FALSE" >> +isolation.tools.dnd.disable = "FALSE" >> +isolation.tools.copy.enable = "TRUE" >> +isolation.tools.paste.enabled = "TRUE" >> +floppy0.present = "FALSE" >> +""" >> +_VMX_ETHERNET_TEMPLATE = """ >> +ethernet%(dev)s.present = "TRUE" >> +ethernet%(dev)s.connectionType = "nat" >> +ethernet%(dev)s.addressType = "generated" >> +ethernet%(dev)s.generatedAddressOffset = "0" >> +ethernet%(dev)s.autoDetect = "TRUE" >> +""" >> +_VMX_IDE_TEMPLATE = """ >> +# IDE disk >> +ide%(dev)s.present = "TRUE" >> +ide%(dev)s.fileName = "%(disk_filename)s" >> +ide%(dev)s.mode = "persistent" >> +ide%(dev)s.startConnected = "TRUE" >> +ide%(dev)s.writeThrough = "TRUE" >> +""" >> >> def parse_netdev_entry(vm, fullkey, value): >> """ >> @@ -72,7 +125,7 @@ >> # like this? >> if bus == "ide": >> inst = int(inst) + int(bus_nr) * 2 >> - >> + >> > > This is just adding trailing space. > > >> devid = (bus, inst) >> if not vm.disks.get(devid): >> vm.disks[devid] = diskcfg.disk(bus = bus, >> @@ -100,7 +153,7 @@ >> name = "vmx" >> suffix = ".vmx" >> can_import = True >> - can_export = False >> + can_export = True >> can_identify = True >> >> @staticmethod >> @@ -160,7 +213,7 @@ >> for devid, disk in vm.disks.iteritems(): >> if disk.type == diskcfg.DISK_TYPE_DISK: >> continue >> - >> + >> # vmx files often have dross left in path for CD entries >> if (disk.path is None >> or disk.path.lower() == "auto detect" or >> @@ -188,7 +241,46 @@ >> Raises ValueError if configuration is not suitable, or another >> exception on failure to write the output file. >> """ >> + vm.description = vm.description.strip() >> + vm.description = vm.description.replace("\n","|") >> + vmx_out_template = [] >> + vmx_dict = { >> + "now": time.strftime("%Y-%m-%dT%H:%M:%S %Z", time.localtime()), >> + "progname": os.path.basename(sys.argv[0]), >> + "vm_name": vm.name, >> + "vm_description": vm.description or "None", >> + "vm_nr_vcpus" : vm.nr_vcpus, >> + "vm_memory": long(vm.memory)/1024 >> + } >> + vmx_out = _VMX_MAIN_TEMPLATE % vmx_dict >> + vmx_out_template.append(vmx_out) >> >> - raise NotImplementedError >> + disk_out_template = [] >> + diskcount = 0 >> + for disk in vm.disks: >> + ide_count = 0 >> + dev = "%d:%d" % (ide_count / 2, ide_count % 2) >> > > IDE count doesn't seem to be incremented here, > > >> + disk_dict = { >> + "dev": dev, >> + "disk_filename" : vm.disks[disk].path >> + } >> + disk_out = _VMX_IDE_TEMPLATE % disk_dict >> + disk_out_template.append(disk_out) >> + diskcount = diskcount + 1 >> > > Diskcount isn't used. > > >> + >> + eth_out_template = [] >> + if len(vm.netdevs): >> + for devnum in vm.netdevs: >> + eth_dict = { >> + "dev" : devnum >> + } >> + eth_out = _VMX_ETHERNET_TEMPLATE % eth_dict >> + eth_out_template.append(eth_out) >> + >> + outfile = open(output_file, "w") >> + outfile.writelines(vmx_out_template) >> + outfile.writelines(disk_out_template) >> + outfile.writelines(eth_out_template) >> + outfile.close() >> >> formats.register_parser(vmx_parser) >> > > Thanks, > Cole > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-vmware-conversion-module-10-3-1306.patch Type: text/x-patch Size: 9167 bytes Desc: not available URL: From crobinso at redhat.com Fri Oct 3 18:26:22 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 03 Oct 2008 14:26:22 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E65193.20007@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> <48E14817.1090401@redhat.com> <48E25FBD.3020800@redhat.com> <48E65193.20007@redhat.com> Message-ID: <48E663CE.1070500@redhat.com> Joey Boggs wrote: > Made those few cleanups > > Thanks, applied now: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=ca48e58d85ec So is there any particular functionality from virt-pack that still needs to be implemented for virt-convert? Basically when will it be okay to kill off UnWare and the virt-pack binary? Thanks, Cole From jboggs at redhat.com Fri Oct 3 18:28:42 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 14:28:42 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output In-Reply-To: <48E663CE.1070500@redhat.com> References: <246345921.3000471222186152180.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <48DA97E5.3020705@redhat.com> <48E0B9BE.3090704@redhat.com> <20080929162738.GA23144@totally.trollied.org.uk> <48E12C44.4080304@redhat.com> <20080929194339.GB23144@totally.trollied.org.uk> <48E137B4.3090404@redhat.com> <48E13ED0.70001@redhat.com> <48E14817.1090401@redhat.com> <48E25FBD.3020800@redhat.com> <48E65193.20007@redhat.com> <48E663CE.1070500@redhat.com> Message-ID: <48E6645A.8080506@redhat.com> The only functionality missing was the zip file function. I'll work on adding compression types in there shortly. We can remove virt-pack and Unware.py if you think it's time to do so now. Cole Robinson wrote: > Joey Boggs wrote: > >> Made those few cleanups >> >> >> > > Thanks, applied now: > > http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=ca48e58d85ec > > So is there any particular functionality from virt-pack > that still needs to be implemented for virt-convert? > Basically when will it be okay to kill off UnWare and > the virt-pack binary? > > Thanks, > Cole > From crobinso at redhat.com Fri Oct 3 20:19:39 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 03 Oct 2008 16:19:39 -0400 Subject: [et-mgmt-tools] [PATCH/RFC]: virt-manager: display disk and network I/O statistics In-Reply-To: <20081003135003.GA5273@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> Message-ID: <48E67E5B.9000106@redhat.com> Guido G?nther wrote: > Hi, > attached is a more complete version of the net/disk I/O statistics > patch. Screenshots are here: > Awesome! Thanks for this, this has been just waiting to be implemented for a while :) > http://honk.sigxcpu.org/misc/vm-overview.png > http://honk.sigxcpu.org/misc/vm-detail.png > > There's certainly lots of room for improvement. > > * all units are KBytes/s, that should be changeable I would say let that come later. We could either add some way to make the graphs scalable on demand (if traffic exceeds X KB/sec, the scale suddenly grows). Other way would be to add an option to 'Preferences', which really needs to be broken out into sections. There's a whole bunch of prefs we could add for stats, like disabling polling outright for the different data types (since a connection with a ton of VMs will most likely have scaling issues). > * the GtkSparkline graphs display input only. I'd be nice to have in > and out in one graph in different colors Fixing up these graphs to be prettier and more useful is high on my list. I'm unfortunately not too savvy on custom widgets so there will be a bit of overhead. gnome-system-monitor has some beautiful graph widgets, though they are written in C++. > * the overview looks a bit boring, should we add sparklines there too, > like for cpu usage? Yes, I would say duplicating the spark lines like you have in the details section would be sufficient. Maybe just change the heading in the manager to be 'Disk Activity' and 'Network Activity', and if the user wants specific data rate numbers they can look at the individual vm details. A minor side comment: One of the things we've discussed offline about adding to virt-manager would be a dedicated performance view of sorts. It would be a separate window that would allow you to do all sorts of fun things with toggling and comparing vm stats on the same graph. We could probably poll for the presence of virt-top and/or virt-mem to try to scrape them for even more output. So at some point, we want to have a place for really thorough stats reporting, which takes the pressure off the current details + manager view from being really robust. > > I've not cleaned up the disk_usage vs disk_io naming mess yet, since I'd > wanted to get some feedback first. > Cheers, > -- Guido > > > # HG changeset patch > # User "Guido G?nther " > # Date 1223040670 -7200 > # Node ID de9d6daefd5ae9b6122ec316816787122d56fc1d > # Parent 0b86cdc80b2cbeb73fddccf3ea9bcbe72ef94375 > > diff -r 0b86cdc80b2c -r de9d6daefd5a src/virt-manager.schemas.in > --- a/src/virt-manager.schemas.in Thu Oct 02 19:43:42 2008 +0200 > +++ b/src/virt-manager.schemas.in Fri Oct 03 15:31:10 2008 +0200 > @@ -66,28 +66,28 @@ > > > > - /schemas/apps/::PACKAGE::/vmlist-fields/disk_usage > + /schemas/apps/::PACKAGE::/vmlist-fields/disk_io > /apps/::PACKAGE::/vmlist-fields/disk_usage > ::PACKAGE:: > bool > 0 > > > - Show disk usage in summary > - Show the disk usage field in the domain list summary view > + Show disk I/O in summary > + Show the disk I/O field in the domain list summary view > > > > > - /schemas/apps/::PACKAGE::/vmlist-fields/network_traffic > - /apps/::PACKAGE::/vmlist-fields/network_traffic > + /schemas/apps/::PACKAGE::/vmlist-fields/network_io > + /apps/::PACKAGE::/vmlist-fields/network_io > ::PACKAGE:: > bool > 0 > > > - Show network traffic in summary > - Show the network traffic field in the domain list summary view > + Show network I/O in summary > + Show the network I/O field in the domain list summary view > > > I haven't tested this, but I don't think we should rename the gconf field names. There isn't really any benefit, and instead it will just leave dead fields kicking around. Changing the description as needed shouldn't be a problem though. The rest of the code looks fine. With the above change and the sparklines in the manager window I'd be glad to take it in. Thanks, Cole From bperkins at redhat.com Sat Oct 4 03:47:30 2008 From: bperkins at redhat.com (Brandon Perkins) Date: Fri, 03 Oct 2008 23:47:30 -0400 Subject: [et-mgmt-tools] virt-p2v and linux software raid. In-Reply-To: <20080930194204.GA12478@amd.home.annexia.org> References: <48D4346A.8060106@redhat.com> <20080930194204.GA12478@amd.home.annexia.org> Message-ID: <48E6E752.8010307@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard W.M. Jones wrote: > On Fri, Sep 19, 2008 at 07:23:22PM -0400, Brandon Perkins wrote: >> I was wondering if there is any progress on getting linux software raid >> support. I'm not really qualified to help with patches, but I'd be more >> than happy to test any patches to get this functionality in. It appears >> I have a similar setup where I have three physical drives, three >> identical partitions in a software RAID-1 (/boot), three identical >> partitions for swap, and three identical partitions in a software RAID-5 >> (/). And of course it bails out because it doesn't understand the >> software raid type. > > Sorry I wasn't concentrating very hard on this list for the past > couple of weeks. > > virt-p2v doesn't understand RAID devices at all. There's no real > limitation here, it's just that you're the first person who has asked > about it. > > Can you open a bug report, and also send the virt-p2v.log file from > your attempted installation. > > Rich. > Thanks for your response! I entered the bug as you requested. If others are interested in this issue, please add yourself to the cc of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=465587 Thanks. Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFI5udRhwQhj8l1t/cRAnHAAJ4ulGOfODUIjurIiO/nU05rhN6ERgCdFjIv gVcZhVkRLpmXda+9cEWIjjs= =gfX3 -----END PGP SIGNATURE----- From agx at sigxcpu.org Sat Oct 4 20:11:57 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:11:57 +0200 Subject: [et-mgmt-tools] [PATCH/RFC]: virt-manager: display disk and network I/O statistics In-Reply-To: <48E67E5B.9000106@redhat.com> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> Message-ID: <20081004201157.GA29584@bogon.ms20.nix> On Fri, Oct 03, 2008 at 04:19:39PM -0400, Cole Robinson wrote: > I would say let that come later. We could either add some way > to make the graphs scalable on demand (if traffic exceeds X KB/sec, > the scale suddenly grows). I currently autoscale the graph to the maximum read or write transfer rate measured. This can be improved but has little point as long as the sparcline widgets don't put any units on the vertical axis. > Other way would be to add an option to 'Preferences', which really > needs to be broken out into sections. There's a whole bunch of prefs > we could add for stats, like disabling polling outright for the > different data types (since a connection with a ton of VMs will most > likely have scaling issues). Having "autoscaling" on by default and being able to set e.g. 100MBytes/s would probably be best. Disabling polling would certainly be nice too. > > * the GtkSparkline graphs display input only. I'd be nice to have in > > and out in one graph in different colors > > Fixing up these graphs to be prettier and more useful is high on > my list. I'm unfortunately not too savvy on custom widgets so there > will be a bit of overhead. gnome-system-monitor has some beautiful > graph widgets, though they are written in C++. The patch series adds some minor improvements like multiple lines in a widget and color. Maybe you can work on from that. > > > * the overview looks a bit boring, should we add sparklines there too, > > like for cpu usage? > > Yes, I would say duplicating the spark lines like you have in the > details section would be sufficient. Maybe just change the heading > in the manager to be 'Disk Activity' and 'Network Activity', and > if the user wants specific data rate numbers they can look at the > individual vm details. I've added a combined read+write sparcline to each column. However I don't bother to add this all up for the domain since there's really little to read out of it. This can certainly be added. [..snip..] > I haven't tested this, but I don't think we should rename the > gconf field names. There isn't really any benefit, and instead > it will just leave dead fields kicking around. O.k., I backed that out. > Changing the description as needed shouldn't be a problem > though. > > The rest of the code looks fine. With the above change and > the sparklines in the manager window I'd be glad to take it > in. I've split things up a little, for easier review. -- Guido From agx at sigxcpu.org Sat Oct 4 20:13:52 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:13:52 +0200 Subject: [et-mgmt-tools] [PATCH 1/9]: virt-manager: silence compiler warnings In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004201352.GA29914@bogon.ms20.nix> Hi, this patch removes unused variables, simply to silence compiler warnings. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 01_sparkline_unused_variables.patch Type: text/x-diff Size: 2412 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 4 20:15:02 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:15:02 +0200 Subject: [et-mgmt-tools] [PATCH 2/9]: virt-manager: add sparkline "filled" property In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004201502.GB29914@bogon.ms20.nix> add "filled" property so sparklines can be filled or not without recompiling -- Guido diff -r 59fd3136f525 src/graphWidgets/sparkline.c --- a/src/graphWidgets/sparkline.c Thu Oct 02 15:15:53 2008 +0200 +++ b/src/graphWidgets/sparkline.c Sat Oct 04 12:16:11 2008 +0200 @@ -41,7 +41,8 @@ enum { PROP_0, - PROP_DATAARRAY + PROP_DATAARRAY, + PROP_FILLED, }; static gpointer parent_class; @@ -88,7 +89,6 @@ priv = GTK_SPARKLINE_GET_PRIVATE (sparkline); priv->filled = TRUE; - // priv->filled = FALSE; priv->data_array = g_value_array_new(0); g_signal_connect (G_OBJECT (sparkline), "expose_event", @@ -124,6 +124,13 @@ 0, G_PARAM_READABLE | G_PARAM_WRITABLE), G_PARAM_READABLE | G_PARAM_WRITABLE)); + g_object_class_install_property (object_class, + PROP_FILLED, + g_param_spec_boolean ("filled", + "Filled", + "fill space under sparcline", + TRUE, + G_PARAM_READABLE | G_PARAM_WRITABLE)); g_type_class_add_private (object_class, sizeof (GtkSparklinePrivate)); } @@ -153,6 +160,10 @@ { case PROP_DATAARRAY: g_value_set_boxed(value, priv->data_array); + break; + + case PROP_FILLED: + g_value_set_boolean(value, priv->filled); break; default: @@ -178,6 +189,10 @@ g_value_array_free(priv->data_array); priv->data_array = g_value_array_copy(g_value_get_boxed(value)); gtk_widget_queue_draw(GTK_WIDGET(object)); + break; + + case PROP_FILLED: + priv->filled = g_value_get_boolean(value); break; default: From agx at sigxcpu.org Sat Oct 4 20:17:26 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:17:26 +0200 Subject: [et-mgmt-tools] [PATCH 3/9]: virt-manager: add sparkline "reversed" property In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004201726.GC29914@bogon.ms20.nix> add "reversed" property to process data back to front this way we don't have to reverse the list in place in python code so it's more obvious which set is which when having multiple lines (see follow up patch). -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 03_sparkline_reversed.patch Type: text/x-diff Size: 6642 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 4 20:19:11 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:19:11 +0200 Subject: [et-mgmt-tools] [PATCH 4/9]: virt-manager: allow multiple sparclines per widget In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004201911.GD29914@bogon.ms20.nix> Add num_sets property so a sparkline graph can have multiple lines all data is still stored in a 1D array so we can still use g_param_spec_double for type checking. This removes the support for non cairo builds. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 04_sparkline_multi.patch Type: text/x-diff Size: 6784 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 4 20:20:58 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:20:58 +0200 Subject: [et-mgmt-tools] [PATCH 5/9]: virt-manager: add sparkline "color" property In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004202058.GE29914@bogon.ms20.nix> Add color property so sparklines in the same widget can have different colors -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 05_sparkline_color.patch Type: text/x-diff Size: 2413 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 4 20:24:25 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:24:25 +0200 Subject: [et-mgmt-tools] [PATCH 6/9]: virt-manager: block device and network statistics In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004202425.GF29914@bogon.ms20.nix> This is the actual patch to calculate the block and net stats: Display block device I/0 and network I/O in the overview as well as in the vm details. The sparkline widget in the vm overview only draws the rx and read rates.This is fixed up by a followup patch, since this way we're independent of the sparkline patches. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 06_block_and_net_stats.patch Type: text/x-diff Size: 31547 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 4 20:28:17 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:28:17 +0200 Subject: [et-mgmt-tools] [PATCH 7/9]: virt-manager: draw rx/tx and read/write in one graph In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004202817.GG29914@bogon.ms20.nix> Draw separate sparclines for rx/tx (network) and read/write (block). Depends on the sparkline muti patch. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 07_use_sparkline_multi.patch Type: text/x-diff Size: 2720 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 4 20:30:46 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:30:46 +0200 Subject: [et-mgmt-tools] [PATCH 9/9]: virt-manager: add sparcline to vm/connection overview In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004203046.GI29914@bogon.ms20.nix> Finally display a combined sparcline for rx & tx (network) and input & output (disk) in the Network I/O and Disk I/O columns in the vm machine overview. -- Guido diff -r 134368ad3def src/virtManager/connection.py --- a/src/virtManager/connection.py Sat Oct 04 17:04:56 2008 +0200 +++ b/src/virtManager/connection.py Sat Oct 04 17:27:01 2008 +0200 @@ -1056,6 +1056,14 @@ def disk_io_rate(self): return self.disk_read_rate() + self.disk_write_rate() + + def disk_io_vector_limit(self, dummy): + """No point to accumulate unnormalized I/O for a conenction""" + return [ 0.0 ] + + def network_traffic_vector_limit(self, dummy): + """No point to accumulate unnormalized Rx/Tx for a conenction""" + return [ 0.0 ] def uuidstr(self, rawuuid): hex = ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'] diff -r 134368ad3def src/virtManager/domain.py --- a/src/virtManager/domain.py Sat Oct 04 17:04:56 2008 +0200 +++ b/src/virtManager/domain.py Sat Oct 04 17:27:01 2008 +0200 @@ -422,6 +422,14 @@ vector.append(0) return vector + def in_out_vector_limit(self, data, limit): + l = len(data)/2 + end = [l, limit][l > limit] + if l > limit: + data = data[0:end] + data[l:l+end] + d = map(lambda x,y: (x + y)/2, data[0:end], data[l:l+end]) + return d + def network_traffic_vector(self): vector = [] stats = self.record @@ -434,6 +442,9 @@ vector.append(0.0) return vector + def network_traffic_vector_limit(self, limit): + return self.in_out_vector_limit(self.network_traffic_vector(), limit) + def disk_io_vector(self): vector = [] stats = self.record @@ -445,6 +456,9 @@ else: vector.append(0.0) return vector + + def disk_io_vector_limit(self, limit): + return self.in_out_vector_limit(self.disk_io_vector(), limit) def shutdown(self): self.vm.shutdown() diff -r 134368ad3def src/virtManager/manager.py --- a/src/virtManager/manager.py Sat Oct 04 17:04:56 2008 +0200 +++ b/src/virtManager/manager.py Sat Oct 04 17:27:01 2008 +0200 @@ -863,6 +863,7 @@ cpuUsage_txt = gtk.CellRendererText() cpuUsage_img = sparkline.CellRendererSparkline() + cpuUsage_img.set_property("reversed", True) cpuUsageCol.pack_start(cpuUsage_txt, False) cpuUsageCol.pack_start(cpuUsage_img, False) cpuUsageCol.add_attribute(cpuUsage_txt, 'text', ROW_CPU) @@ -886,19 +887,27 @@ diskIOIn_txt = gtk.CellRendererText() diskIOOut_txt = gtk.CellRendererText() + diskIO_img = sparkline.CellRendererSparkline() + diskIO_img.set_property("reversed", True) diskIOCol.pack_start(diskIOIn_txt, False) diskIOCol.pack_start(diskIOOut_txt, False) + diskIOCol.pack_start(diskIO_img, False) diskIOCol.add_attribute(diskIOIn_txt, 'text', ROW_DISK_RD) diskIOCol.add_attribute(diskIOOut_txt, 'text', ROW_DISK_WR) + diskIOCol.set_cell_data_func(diskIO_img, self.disk_io_img, None) diskIOCol.set_visible(self.config.is_vmlist_disk_io_visible()) diskIOCol.set_sort_column_id(VMLIST_SORT_DISK_IO) networkTrafficIn_txt = gtk.CellRendererText() networkTrafficOut_txt = gtk.CellRendererText() + networkTraffic_img = sparkline.CellRendererSparkline() + networkTraffic_img.set_property("reversed", True) networkTrafficCol.pack_start(networkTrafficIn_txt, False) networkTrafficCol.pack_start(networkTrafficOut_txt, False) + networkTrafficCol.pack_start(networkTraffic_img, False) networkTrafficCol.add_attribute(networkTrafficIn_txt, 'text', ROW_NET_RX) networkTrafficCol.add_attribute(networkTrafficOut_txt, 'text', ROW_NET_TX) + networkTrafficCol.set_cell_data_func(networkTraffic_img, self.network_traffic_img, None) networkTrafficCol.set_visible(self.config.is_vmlist_network_traffic_visible()) networkTrafficCol.set_sort_column_id(VMLIST_SORT_NETWORK_USAGE) @@ -997,7 +1006,18 @@ if model.get_value(iter, ROW_HANDLE) is None: return data = model.get_value(iter, ROW_HANDLE).cpu_time_vector_limit(40) - data.reverse() + cell.set_property('data_array', data) + + def disk_io_img(self, column, cell, model, iter, data): + if model.get_value(iter, ROW_HANDLE) is None: + return + data = model.get_value(iter, ROW_HANDLE).disk_io_vector_limit(40) + cell.set_property('data_array', data) + + def network_traffic_img(self, column, cell, model, iter, data): + if model.get_value(iter, ROW_HANDLE) is None: + return + data = model.get_value(iter, ROW_HANDLE).network_traffic_vector_limit(40) cell.set_property('data_array', data) def start_vm(self, ignore): -------------- next part -------------- A non-text attachment was scrubbed... Name: 09_block_and_net_cellsparcline.patch Type: text/x-diff Size: 4984 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 4 20:29:22 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 4 Oct 2008 22:29:22 +0200 Subject: [et-mgmt-tools] [PATCH 8/9]: virt-manager: color sparkline for rx/tx, read/write In-Reply-To: <20081004201157.GA29584@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> Message-ID: <20081004202922.GH29914@bogon.ms20.nix> Color the rx and read sparclines red, the tx and write sparcline green. Needs the sparkline color patch. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 08_color_graph.patch Type: text/x-diff Size: 4913 bytes Desc: not available URL: From agx at sigxcpu.org Sun Oct 5 12:16:54 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sun, 5 Oct 2008 14:16:54 +0200 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <20080926154705.GB543@redhat.com> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> <48DCE8DE.8010707@redhat.com> <20080926154102.GA25350@bogon.ms20.nix> <20080926154705.GB543@redhat.com> Message-ID: <20081005121654.GA22019@bogon.ms20.nix> On Fri, Sep 26, 2008 at 04:47:05PM +0100, Daniel P. Berrange wrote: > We've got this problem sorted in the 'lxc' driver and need to apply > the same approach to the QEMU driver. The problem was always finding > the Pseduo-TTY/PID for the monitor after restart, and associating the > live config with it. We've "solved" that in LXC driver by savingt the > live XML & PID to /var/run/libvirt/lxc/. It basically needs the same > approach to be applied to the QEMU daemons. In addition the DNSmasq > deamon needs adapting for simiarl reasons. This would solve the problem of restarting libvirtd. How are we going to distinguish this from daemon shutdown on e.g. system reboot? Is the distros init script supposed to handle shutting down/suspending active domains on /etc/init.d/libvirtd stop? -- Guido From berrange at redhat.com Sun Oct 5 16:05:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 5 Oct 2008 17:05:08 +0100 Subject: [et-mgmt-tools] Virt-Manager not connecting qemu:///system In-Reply-To: <20081005121654.GA22019@bogon.ms20.nix> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> <48DCE8DE.8010707@redhat.com> <20080926154102.GA25350@bogon.ms20.nix> <20080926154705.GB543@redhat.com> <20081005121654.GA22019@bogon.ms20.nix> Message-ID: <20081005160508.GB16996@redhat.com> On Sun, Oct 05, 2008 at 02:16:54PM +0200, Guido G?nther wrote: > On Fri, Sep 26, 2008 at 04:47:05PM +0100, Daniel P. Berrange wrote: > > We've got this problem sorted in the 'lxc' driver and need to apply > > the same approach to the QEMU driver. The problem was always finding > > the Pseduo-TTY/PID for the monitor after restart, and associating the > > live config with it. We've "solved" that in LXC driver by savingt the > > live XML & PID to /var/run/libvirt/lxc/. It basically needs the same > > approach to be applied to the QEMU daemons. In addition the DNSmasq > > deamon needs adapting for simiarl reasons. > This would solve the problem of restarting libvirtd. How are we going to > distinguish this from daemon shutdown on e.g. system reboot? Is the > distros init script supposed to handle shutting down/suspending active > domains on /etc/init.d/libvirtd stop? Yep, we need to have some explicit support for shuttting down / saving active VMs on system shutdown, independant of whether the daemon restart preserves them. We can probably distinguish by picking a specific signal for orderly shutdown of the daemon + vms, vs a simple restart. I'd like all signals to preserve running VMs by default - attempting todo orderly shutdown of VMs on reciept of signal is not great because there's no way to get info on progress of shutdown, or detect/report shutdown errors. I'd also like to avoid putting any complex application logic into initscripts though. Perhaps we should have an explicit API, or a convenient virsh command to shutdown all VMs in one go. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 10:27:47 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 11:27:47 +0100 Subject: [et-mgmt-tools] [PATCH 1/9]: virt-manager: silence compiler warnings In-Reply-To: <20081004201352.GA29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201352.GA29914@bogon.ms20.nix> Message-ID: <20081006102747.GG20979@redhat.com> On Sat, Oct 04, 2008 at 10:13:52PM +0200, Guido G?nther wrote: > Hi, > this patch removes unused variables, simply to silence compiler warnings. ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 10:28:12 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 11:28:12 +0100 Subject: [et-mgmt-tools] [PATCH 2/9]: virt-manager: add sparkline "filled" property In-Reply-To: <20081004201502.GB29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201502.GB29914@bogon.ms20.nix> Message-ID: <20081006102811.GH20979@redhat.com> On Sat, Oct 04, 2008 at 10:15:02PM +0200, Guido G?nther wrote: > add "filled" property so sparklines can be filled or not without recompiling ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 10:29:47 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 11:29:47 +0100 Subject: [et-mgmt-tools] [PATCH 3/9]: virt-manager: add sparkline "reversed" property In-Reply-To: <20081004201726.GC29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201726.GC29914@bogon.ms20.nix> Message-ID: <20081006102947.GI20979@redhat.com> On Sat, Oct 04, 2008 at 10:17:26PM +0200, Guido G?nther wrote: > add "reversed" property to process data back to front > > this way we don't have to reverse the list in place in python code so > it's more obvious which set is which when having multiple lines (see > follow up patch). ACK. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 10:33:16 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 11:33:16 +0100 Subject: [et-mgmt-tools] [PATCH 4/9]: virt-manager: allow multiple sparclines per widget In-Reply-To: <20081004201911.GD29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201911.GD29914@bogon.ms20.nix> Message-ID: <20081006103316.GJ20979@redhat.com> On Sat, Oct 04, 2008 at 10:19:11PM +0200, Guido G?nther wrote: > Add num_sets property so a sparkline graph can have multiple lines > > all data is still stored in a 1D array so we can still use g_param_spec_double > for type checking. This removes the support for non cairo builds. What version of GTK first introduced support for Cairo in its widget sets. I don't want us to drop support for non-Cairo drawing if its still something people are likely to be using on older distros. The non-cairo code wasn't particularly complex / hard to maintain. Daniel > -- Guido > Add num_sets property so a sparkline graph can have multiple lines > > all data is still stored in a 1D array so we can still use g_param_spec_double > for type checking. This removes the support for non cairo builds. > > diff -r 9c478dd01da1 src/graphWidgets/sparkline.c > --- a/src/graphWidgets/sparkline.c Sat Oct 04 14:50:47 2008 +0200 > +++ b/src/graphWidgets/sparkline.c Sat Oct 04 14:51:42 2008 +0200 > @@ -44,6 +44,7 @@ > PROP_DATAARRAY, > PROP_FILLED, > PROP_REVERSED, > + PROP_NUMSETS, > }; > > static gpointer parent_class; > @@ -55,6 +56,8 @@ > { > gboolean filled; > gboolean reversed; > + gint num_sets; > + gint points_per_set; > GValueArray *data_array; > }; > > @@ -93,6 +96,8 @@ > priv->filled = TRUE; > priv->reversed = FALSE; > priv->data_array = g_value_array_new(0); > + priv->num_sets = 1; > + priv->points_per_set = 0; > > g_signal_connect (G_OBJECT (sparkline), "expose_event", > G_CALLBACK (gtk_sparkline_expose), NULL); > @@ -103,6 +108,7 @@ > { > GObjectClass *object_class = G_OBJECT_CLASS (class); > GtkWidgetClass *widget_class = GTK_WIDGET_CLASS (class); > + GParamSpec *data_array_spec; > > parent_class = g_type_class_peek_parent (class); > > @@ -114,19 +120,28 @@ > widget_class->size_request = gtk_sparkline_size_request; > //widget_class->expose_event = gtk_sparkline_expose; > > + data_array_spec = g_param_spec_double("data_array_value", > + "Data array value", > + "GValueArray element", > + 0.0, > + 100.0, > + 0, > + G_PARAM_READABLE | G_PARAM_WRITABLE); > + > g_object_class_install_property (object_class, > PROP_DATAARRAY, > g_param_spec_value_array ("data_array", > "Data array", > "GValueArray of data", > - g_param_spec_double("data_array_value", > - "Data array value", > - "GValueArray element", > - 0.0, > - 100.0, > - 0, > - G_PARAM_READABLE | G_PARAM_WRITABLE), > + data_array_spec, > G_PARAM_READABLE | G_PARAM_WRITABLE)); > + g_object_class_install_property (object_class, > + PROP_NUMSETS, > + g_param_spec_int ("num_sets", > + "Num Sets", > + "Number of data sets in data", > + 1, 2, 1, > + G_PARAM_READABLE | G_PARAM_WRITABLE)); > g_object_class_install_property (object_class, > PROP_FILLED, > g_param_spec_boolean ("filled", > @@ -168,6 +183,10 @@ > g_value_set_boxed(value, priv->data_array); > break; > > + case PROP_NUMSETS: > + g_value_set_int(value, priv->num_sets); > + break; > + > case PROP_FILLED: > g_value_set_boolean(value, priv->filled); > break; > @@ -197,6 +216,7 @@ > case PROP_DATAARRAY: > g_value_array_free(priv->data_array); > priv->data_array = g_value_array_copy(g_value_get_boxed(value)); > + priv->points_per_set = priv->data_array->n_values / priv->num_sets; > gtk_widget_queue_draw(GTK_WIDGET(object)); > break; > > @@ -206,6 +226,10 @@ > > case PROP_REVERSED: > priv->reversed = g_value_get_boolean(value); > + break; > + > + case PROP_NUMSETS: > + priv->num_sets = g_value_get_int(value); > break; > > default: > @@ -225,22 +249,22 @@ > data = priv->data_array; > > if (area) { > - area->width = data->n_values; > + area->width = data->n_values / priv->num_sets; > area->height = 20; > } > } > > -static double get_y (GtkAllocation *cell_area, > - GValueArray *data, > - int index, int reversed) > +static double get_y (GtkSparklinePrivate *priv, GtkAllocation *cell_area, > + GValueArray *data, int set, int index) > { > double baseline_y = cell_area->height; > int n; > > - if (reversed) > - n = data->n_values - 1 - index; > + n = set * priv->points_per_set; > + if (priv->reversed) > + n += priv->points_per_set - 1 - index; > else > - n = index; > + n += index; > > GValue *val = g_value_array_get_nth(data, n); > return baseline_y - ((cell_area->height-1) * g_value_get_double(val)); > @@ -253,27 +277,15 @@ > { > GtkSparklinePrivate *priv; > GValueArray *data; > - GdkPoint *points; > - int index; > + int index, set; > double pixels_per_point; > GtkAllocation *cell_area = &widget->allocation; > -#if USE_CAIRO > cairo_t *cr; > -#endif > > priv = GTK_SPARKLINE_GET_PRIVATE (widget); > > data = priv->data_array; > - > - pixels_per_point = (double)cell_area->width / ((double)data->n_values-1); > - > - points = g_new(GdkPoint, data->n_values); > - for (index=0;indexn_values;index++) { > - double cx = ((double)index * pixels_per_point); > - double cy = get_y (cell_area, data, index, priv->reversed); > - points[index].x = cx; > - points[index].y = cy; > - } > + pixels_per_point = (double)cell_area->width / ((double)priv->points_per_set-1); > > gdk_draw_rectangle(widget->window, > widget->style->mid_gc[GTK_WIDGET_STATE (widget)], > @@ -300,7 +312,6 @@ > cell_area->height/NTICKS*index); > } > > -#if USE_CAIRO > cr = gdk_cairo_create (widget->window); > > /* Clip to the cell: */ > @@ -308,26 +319,33 @@ > cairo_rectangle (cr, 0, 0, cell_area->width, cell_area->height); > cairo_clip (cr); > > - /* Render the line: */ > + /* Render the lines: */ > cairo_set_line_width (cr, (double)0.5); > > - for (index=0;indexn_values;index++) { > - double cx = points[index].x; > - double cy = points[index].y; > - if (index) { > - cairo_line_to (cr, cx, cy); > - } else { > - cairo_move_to (cr, cx, cy); > + for (set=0; set < priv->num_sets; set++) { > + /* FIXME: add property to add line color */ > + if (set) > + cairo_set_source_rgb (cr, 0.25, 0.25, 0.25); > + else > + cairo_set_source_rgb (cr, 0.0, 0.0, 0.0); > + for (index=0; index < priv->points_per_set; index++) { > + double cx = ((double)index * pixels_per_point); > + double cy = get_y (priv, cell_area, data, set, index); > + if (index) { > + cairo_line_to (cr, cx, cy); > + } else { > + cairo_move_to (cr, cx, cy); > + } > } > - } > - if (data->n_values) { > - if (priv->filled) { > - double baseline_y = cell_area->height + cell_area->y; > - cairo_line_to (cr, cell_area->x + cell_area->width, baseline_y); > - cairo_line_to (cr, 0, baseline_y); > - cairo_fill (cr); > - } else { > - cairo_stroke (cr); > + if (priv->points_per_set) { > + if (priv->filled) { > + double baseline_y = cell_area->height + cell_area->y; > + cairo_line_to (cr, cell_area->x + cell_area->width, baseline_y); > + cairo_line_to (cr, 0, baseline_y); > + cairo_fill (cr); > + } else { > + cairo_stroke (cr); > + } > } > } > > @@ -336,14 +354,6 @@ > > cairo_destroy (cr); > > -#else > - gdk_draw_lines(widget->window, > - widget->style->fg_gc[GTK_WIDGET_STATE(widget)], > - points, data->n_values); > -#endif > - > - g_free(points); > - > return TRUE; > } > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 10:33:49 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 11:33:49 +0100 Subject: [et-mgmt-tools] [PATCH 5/9]: virt-manager: add sparkline "color" property In-Reply-To: <20081004202058.GE29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004202058.GE29914@bogon.ms20.nix> Message-ID: <20081006103349.GK20979@redhat.com> On Sat, Oct 04, 2008 at 10:20:58PM +0200, Guido G?nther wrote: > Add color property so sparklines in the same widget can have different colors ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 10:37:42 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 11:37:42 +0100 Subject: [et-mgmt-tools] [PATCH 6/9]: virt-manager: block device and network statistics In-Reply-To: <20081004202425.GF29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004202425.GF29914@bogon.ms20.nix> Message-ID: <20081006103742.GL20979@redhat.com> On Sat, Oct 04, 2008 at 10:24:25PM +0200, Guido G?nther wrote: > This is the actual patch to calculate the block and net stats: > > Display block device I/0 and network I/O in the overview as well as in > the vm details. The sparkline widget in the vm overview only draws the > rx and read rates.This is fixed up by a followup patch, since this way > we're independent of the sparkline patches. > diff -r 30dc0d5939d4 src/virtManager/domain.py > --- a/src/virtManager/domain.py Sat Oct 04 20:41:20 2008 +0200 > +++ b/src/virtManager/domain.py Sat Oct 04 21:52:04 2008 +0200 > @@ -149,6 +155,34 @@ > self.lastStatus = status > self.emit("status-changed", status) > > + def _network_traffic(self): > + rx = 0 > + tx = 0 > + for netdev in self.get_network_devices(): > + io = self.vm.interfaceStats(netdev[2]) > + if io: > + rx += io[0] > + tx += io[4] The standard behaviour libvirt python binding is to raise an exception if something fails, so checking for io == None isn't sufficient here. You should also wrap the call try: io = self.vm.interfaceStats(netdev[2]) except: pass if io: rx += io[0] tx += io[4] > + return rx, tx > + > + def _disk_io(self): > + rd = 0 > + wr = 0 > + for disk in self.get_disk_devices(): > + io = self.vm.blockStats(disk[3]) > + if io: > + rd += io[1] > + wr += io[3] > + return rd, wr Likewise here. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 10:38:28 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 11:38:28 +0100 Subject: [et-mgmt-tools] [PATCH 7/9]: virt-manager: draw rx/tx and read/write in one graph In-Reply-To: <20081004202817.GG29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004202817.GG29914@bogon.ms20.nix> Message-ID: <20081006103828.GM20979@redhat.com> On Sat, Oct 04, 2008 at 10:28:17PM +0200, Guido G?nther wrote: > Draw separate sparclines for rx/tx (network) and read/write (block). > Depends on the sparkline muti patch. ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 11:04:27 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 12:04:27 +0100 Subject: [et-mgmt-tools] [PATCH 8/9]: virt-manager: color sparkline for rx/tx, read/write In-Reply-To: <20081004202922.GH29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004202922.GH29914@bogon.ms20.nix> Message-ID: <20081006110427.GN20979@redhat.com> On Sat, Oct 04, 2008 at 10:29:22PM +0200, Guido G?nther wrote: > Color the rx and read sparclines red, the tx and write sparcline green. Using pure red + green with same overall colour intensity isn't good for color-blindness, particularly since we're using a gray background > + self.disk_io_graph.set_property("rgb", [1.0, 0.0, 0.0, > + 0.0, 1.0, 0.0]) It'll take a little playing around to get a good colour pair which works on a gray background, and is also color anomoly-safe. There's a really neat DHTML webpage for just this purpose though http://www.colorjack.com/sphere/ I'd pick 'Complementary' or one of the 'Split Complementary' variants and then drag around the dots till you find a pair of suitable colors, which also look reasonably distinctive when you select the various color anomologies. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Mon Oct 6 11:04:47 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Oct 2008 12:04:47 +0100 Subject: [et-mgmt-tools] [PATCH 9/9]: virt-manager: add sparcline to vm/connection overview In-Reply-To: <20081004203046.GI29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> Message-ID: <20081006110447.GO20979@redhat.com> On Sat, Oct 04, 2008 at 10:30:46PM +0200, Guido G?nther wrote: > Finally display a combined sparcline for rx & tx (network) and input & > output (disk) in the Network I/O and Disk I/O columns in the vm machine > overview. ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From markmc at redhat.com Mon Oct 6 14:12:28 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 06 Oct 2008 15:12:28 +0100 Subject: [et-mgmt-tools] [PATCH] Fix virt-install --bridge Message-ID: <1223302348.4182.39.camel@blaa> If you run virt-install with --bridge, you get: ERROR Cannot mix both --bridge and --network arguments because digest_networks() is comparing [] to None. Reduce confusion by also normalizing the bridges argument to a list and evaluating the lists as bools. Signed-off-by: Mark McLoughlin diff -r ca48e58d85ec virtinst/cli.py --- a/virtinst/cli.py Fri Oct 03 14:23:37 2008 -0400 +++ b/virtinst/cli.py Mon Oct 06 15:11:31 2008 +0100 @@ -277,24 +277,22 @@ guest.nics.append(n) def digest_networks(conn, macs, bridges, networks, nics = 0): - if type(bridges) != list and bridges != None: - bridges = [ bridges ] + def listify(l): + if l is None: + return [] + elif type(l) != list: + return [ l ] + else: + return l - if macs is None: - macs = [] - elif type(macs) != list: - macs = [ macs ] - - if networks is None: - networks = [] - elif type(networks) != list: - networks = [ macs ] + macs = listify(macs) + bridges = listify(bridges) + networks = listify(networks) - if bridges is not None and networks != None: + if bridges and networks: fail(_("Cannot mix both --bridge and --network arguments")) - - if bridges != None: + if bridges: networks = map(lambda b: "bridge:" + b, bridges) # ensure we have less macs then networks. Auto fill in the remaining From crobinso at redhat.com Mon Oct 6 16:23:19 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 06 Oct 2008 12:23:19 -0400 Subject: [et-mgmt-tools] Re: [PATCH] Fix virt-install --bridge In-Reply-To: <1223302348.4182.39.camel@blaa> References: <1223302348.4182.39.camel@blaa> Message-ID: <48EA3B77.2080601@redhat.com> Mark McLoughlin wrote: > If you run virt-install with --bridge, you get: > > ERROR Cannot mix both --bridge and --network arguments > > because digest_networks() is comparing [] to None. > > Reduce confusion by also normalizing the bridges argument to > a list and evaluating the lists as bools. > Thanks, applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=2aba69a1a16c I'll make sure this is pulled in for f10 as well. Thanks, Cole From crobinso at redhat.com Mon Oct 6 16:40:11 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 06 Oct 2008 12:40:11 -0400 Subject: [et-mgmt-tools] [PATCH 4/9]: virt-manager: allow multiple sparclines per widget In-Reply-To: <20081006103316.GJ20979@redhat.com> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201911.GD29914@bogon.ms20.nix> <20081006103316.GJ20979@redhat.com> Message-ID: <48EA3F6B.1090605@redhat.com> Daniel P. Berrange wrote: > On Sat, Oct 04, 2008 at 10:19:11PM +0200, Guido G?nther wrote: >> Add num_sets property so a sparkline graph can have multiple lines >> >> all data is still stored in a 1D array so we can still use g_param_spec_double >> for type checking. This removes the support for non cairo builds. > > What version of GTK first introduced support for Cairo in its > widget sets. I don't want us to drop support for non-Cairo drawing > if its still something people are likely to be using on older > distros. The non-cairo code wasn't particularly complex / hard to > maintain. > > Daniel > Seems like gtk 2.8, released August 05. Which goes all the way back to fc5. http://lwn.net/Articles/147467/ So doesn't seem like the biggest deal to drop. Thanks, Cole From crobinso at redhat.com Mon Oct 6 17:01:59 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 06 Oct 2008 13:01:59 -0400 Subject: [et-mgmt-tools] Re: [PATCH 1/9]: virt-manager: silence compiler warnings In-Reply-To: <20081004201352.GA29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201352.GA29914@bogon.ms20.nix> Message-ID: <48EA4487.4070307@redhat.com> Guido G?nther wrote: > Hi, > this patch removes unused variables, simply to silence compiler warnings. > -- Guido > Thanks, applied: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=48d4e2acbdc7 - Cole From crobinso at redhat.com Mon Oct 6 17:02:51 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 06 Oct 2008 13:02:51 -0400 Subject: [et-mgmt-tools] Re: [PATCH 2/9]: virt-manager: add sparkline "filled" property In-Reply-To: <20081004201502.GB29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201502.GB29914@bogon.ms20.nix> Message-ID: <48EA44BB.8050503@redhat.com> Guido G?nther wrote: > add "filled" property so sparklines can be filled or not without recompiling > -- Guido > Thanks, applied: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=f316869cfc3a - Cole From crobinso at redhat.com Mon Oct 6 17:03:15 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 06 Oct 2008 13:03:15 -0400 Subject: [et-mgmt-tools] Re: [PATCH 3/9]: virt-manager: add sparkline "reversed" property In-Reply-To: <20081004201726.GC29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201726.GC29914@bogon.ms20.nix> Message-ID: <48EA44D3.9010209@redhat.com> Guido G?nther wrote: > add "reversed" property to process data back to front > > this way we don't have to reverse the list in place in python code so > it's more obvious which set is which when having multiple lines (see > follow up patch). > -- Guido > Thanks, applied: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=9f5d5b6940c5 - Cole From crobinso at redhat.com Mon Oct 6 17:22:27 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 06 Oct 2008 13:22:27 -0400 Subject: [et-mgmt-tools] virt-manager: exception when connecting to URI with already running VMs In-Reply-To: <20081002173025.GA29444@bogon.ms20.nix> References: <20081002173025.GA29444@bogon.ms20.nix> Message-ID: <48EA4953.6080805@redhat.com> Guido G?nther wrote: > Hi, > when opening virt-manager and doubleclicking on the previously definded > qemu:///system connection which has an already running vm I get: > This should be fixed now: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=270e1697b81a Let me know if you still have any problems. Thanks for the report. - Cole From agx at sigxcpu.org Tue Oct 7 13:11:53 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 7 Oct 2008 15:11:53 +0200 Subject: [et-mgmt-tools] [PATCH 6/9]: virt-manager: block device and network statistics In-Reply-To: <20081006103742.GL20979@redhat.com> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004202425.GF29914@bogon.ms20.nix> <20081006103742.GL20979@redhat.com> Message-ID: <20081007131153.GA29854@bogon.ms20.nix> On Mon, Oct 06, 2008 at 11:37:42AM +0100, Daniel P. Berrange wrote: [..snip..] > The standard behaviour libvirt python binding is to raise an exception > if something fails, so checking for io == None isn't sufficient here. > You should also wrap the call Updated version attached. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 06_block_and_netstats.patch Type: text/x-diff Size: 32066 bytes Desc: not available URL: From agx at sigxcpu.org Tue Oct 7 13:16:01 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 7 Oct 2008 15:16:01 +0200 Subject: [et-mgmt-tools] [PATCH 8/9]: virt-manager: color sparkline for rx/tx, read/write In-Reply-To: <20081006110427.GN20979@redhat.com> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004202922.GH29914@bogon.ms20.nix> <20081006110427.GN20979@redhat.com> Message-ID: <20081007131601.GB29854@bogon.ms20.nix> On Mon, Oct 06, 2008 at 12:04:27PM +0100, Daniel P. Berrange wrote: > On Sat, Oct 04, 2008 at 10:29:22PM +0200, Guido G?nther wrote: > > Color the rx and read sparclines red, the tx and write sparcline green. > > Using pure red + green with same overall colour intensity isn't good > for color-blindness, particularly since we're using a gray background Thought so, but I hoped to delay this until we can make the color of the graphs configurable. > > + self.disk_io_graph.set_property("rgb", [1.0, 0.0, 0.0, > > + 0.0, 1.0, 0.0]) > > It'll take a little playing around to get a good colour pair which > works on a gray background, and is also color anomoly-safe. There's > a really neat DHTML webpage for just this purpose though > > http://www.colorjack.com/sphere/ > > I'd pick 'Complementary' or one of the 'Split Complementary' variants > and then drag around the dots till you find a pair of suitable colors, > which also look reasonably distinctive when you select the various > color anomologies. Nice tool. Updated patch attached. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 08_color_graph.patch Type: text/x-diff Size: 5123 bytes Desc: not available URL: From agx at sigxcpu.org Tue Oct 7 13:19:53 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 7 Oct 2008 15:19:53 +0200 Subject: [et-mgmt-tools] virt-manager: exception when connecting to URI with already running VMs In-Reply-To: <48EA4953.6080805@redhat.com> References: <20081002173025.GA29444@bogon.ms20.nix> <48EA4953.6080805@redhat.com> Message-ID: <20081007131953.GC29854@bogon.ms20.nix> On Mon, Oct 06, 2008 at 01:22:27PM -0400, Cole Robinson wrote: > Guido G?nther wrote: > > Hi, > > when opening virt-manager and doubleclicking on the previously definded > > qemu:///system connection which has an already running vm I get: > > > > This should be fixed now: Thanks! > > http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=270e1697b81a > > Let me know if you still have any problems. Thanks for > the report. Hmm...the exception is gone now but when I set "Automatically open consoles" to "for all domains" the gtk-vnc widget just isn't getting refreshed properly on the spawned consoles. However when I close the console windows and click on the individual VMs everything works as expected and the gtk-vnc widget refreshes properly. -- Guido From agx at sigxcpu.org Tue Oct 7 16:12:33 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 7 Oct 2008 18:12:33 +0200 Subject: [et-mgmt-tools] [PATCH/RFC] kvm/qemu vs libvirtd restarts In-Reply-To: <20080926154705.GB543@redhat.com> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> <48DCE8DE.8010707@redhat.com> <20080926154102.GA25350@bogon.ms20.nix> <20080926154705.GB543@redhat.com> Message-ID: <20081007161233.GA31074@bogon.ms20.nix> On Fri, Sep 26, 2008 at 04:47:05PM +0100, Daniel P. Berrange wrote: > On Fri, Sep 26, 2008 at 05:41:02PM +0200, Guido G?nther wrote: > > On Fri, Sep 26, 2008 at 09:51:26AM -0400, Cole Robinson wrote: > > > It's easy to forget, but anytime you update libvirt you will > > > need to restart libvirtd. Sounds like that could be the problem. > > The Ubuntu packages are based on the Debian ones and I dropped the > > daemon restart from the postinst so we don't tear down all running > > machines - so this is likely the problem. > > Did anybody work on saving enough state to restart libvirtd while > > keeping the VMs running? If not I might give it a whirl once I find some > > time. > > We've got this problem sorted in the 'lxc' driver and need to apply > the same approach to the QEMU driver. The problem was always finding > the Pseduo-TTY/PID for the monitor after restart, and associating the > live config with it. We've "solved" that in LXC driver by savingt the > live XML & PID to /var/run/libvirt/lxc/. It basically needs the same > approach to be applied to the QEMU daemons. In addition the DNSmasq > deamon needs adapting for simiarl reasons. Attached is a very early patch. It keeps the qemu instances running and writes out their states upon shutdown. Reconnecting (and therefore sending monitor commands, etc.) works but since stdout/stderr don't get picked up again yet we don't handle virEventAddhandle. I'll grab them from /proc//fd/{1,2} later. Network state is missing too, but since this is moving into a separate file it's becoming a different matter anyway. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-let-qemu-kvm-survive-libvirtd-restarts.patch Type: text/x-diff Size: 13057 bytes Desc: not available URL: From berrange at redhat.com Tue Oct 7 16:37:52 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 7 Oct 2008 17:37:52 +0100 Subject: [et-mgmt-tools] Re: [PATCH/RFC] kvm/qemu vs libvirtd restarts In-Reply-To: <20081007161233.GA31074@bogon.ms20.nix> References: <48DCADA0.4060001@call-of-ktulu.de> <20080926094223.GC25341@redhat.com> <48DCBDAC.7000909@call-of-ktulu.de> <48DCE8DE.8010707@redhat.com> <20080926154102.GA25350@bogon.ms20.nix> <20080926154705.GB543@redhat.com> <20081007161233.GA31074@bogon.ms20.nix> Message-ID: <20081007163752.GP17780@redhat.com> Moving thread to libvir-list.... On Tue, Oct 07, 2008 at 06:12:33PM +0200, Guido G?nther wrote: > On Fri, Sep 26, 2008 at 04:47:05PM +0100, Daniel P. Berrange wrote: > > On Fri, Sep 26, 2008 at 05:41:02PM +0200, Guido G?nther wrote: > > > > We've got this problem sorted in the 'lxc' driver and need to apply > > the same approach to the QEMU driver. The problem was always finding > > the Pseduo-TTY/PID for the monitor after restart, and associating the > > live config with it. We've "solved" that in LXC driver by savingt the > > live XML & PID to /var/run/libvirt/lxc/. It basically needs the same > > approach to be applied to the QEMU daemons. In addition the DNSmasq > > deamon needs adapting for simiarl reasons. > > Attached is a very early patch. It keeps the qemu instances running and > writes out their states upon shutdown. Reconnecting (and therefore sending > monitor commands, etc.) works but since stdout/stderr don't get picked > up again yet we don't handle virEventAddhandle. I'll grab them from > /proc//fd/{1,2} later. Network state is missing too, but since this > is moving into a separate file it's becoming a different matter anyway. First off, thanks for working on this! A few general comments, and then I'll put rest inline.. For stdout/err, it need to be setup so that the logfile is dup()'d onto the QEMU process' file descriptors directly, and get libvirt outof the business of I/O forwarding. This avoids any complications with re-attaching to stdout/err, and loosing any log data while libvirt isn't running. This also needs to be implemented with the assumption that the daemon can & will crash any time. So putting the state-saving hooks into the qemudShutdown() method won't be sufficient. We need to write out the state we need when initially starting the VM, and then update it any time we hot-plug/unplug devices. Ignoring network state is fine - we can address that separately.. > Subject: [PATCH] let qemu/kvm survive libvirtd restarts > > --- > src/domain_conf.c | 1 + > src/domain_conf.h | 1 + > src/qemu_conf.h | 1 + > src/qemu_driver.c | 264 +++++++++++++++++++++++++++++++++++++++++++++++++---- > src/util.c | 4 +- > src/util.h | 1 + > 6 files changed, 254 insertions(+), 18 deletions(-) > > diff --git a/src/domain_conf.c b/src/domain_conf.c > index 6a35064..aa102f6 100644 > --- a/src/domain_conf.c > +++ b/src/domain_conf.c > @@ -420,6 +420,7 @@ void virDomainObjFree(virDomainObjPtr dom) > virDomainDefFree(dom->def); > virDomainDefFree(dom->newDef); > > + VIR_FREE(dom->monitorpath); > VIR_FREE(dom->vcpupids); > > VIR_FREE(dom); > diff --git a/src/domain_conf.h b/src/domain_conf.h > index 632e5ad..1ac1561 100644 > --- a/src/domain_conf.h > +++ b/src/domain_conf.h > @@ -448,6 +448,7 @@ struct _virDomainObj { > int stdout_fd; > int stderr_fd; > int monitor; > + char *monitorpath; I think we can avoid needing this. If we write out the staste the moment the VM is started, we don't need to carry this around in memory. Alternatively, since we're writing all stdout/err data to the logfile, we could simply re-parse the log to extract the monitor path upon restart. > int logfile; > int pid; > int state; > diff --git a/src/qemu_conf.h b/src/qemu_conf.h > index 88dfade..f47582e 100644 > --- a/src/qemu_conf.h > +++ b/src/qemu_conf.h > @@ -62,6 +62,7 @@ struct qemud_driver { > char *networkConfigDir; > char *networkAutostartDir; > char *logDir; > + char *stateDir; > unsigned int vncTLS : 1; > unsigned int vncTLSx509verify : 1; > char *vncTLSx509certdir; > diff --git a/src/qemu_driver.c b/src/qemu_driver.c > index 806608d..87789a9 100644 > --- a/src/qemu_driver.c > +++ b/src/qemu_driver.c > @@ -172,6 +172,181 @@ void qemudAutostartConfigs(struct qemud_driver *driver) { > } > > #ifdef WITH_LIBVIRTD > + > +static int > +qemudFileWriteMonitor(const char *dir, > + const char *name, > + const char *path) > +{ > + int rc; > + int fd; > + FILE *file = NULL; > + char *monitorfile = NULL; > + > + if ((rc = virFileMakePath(dir))) > + goto cleanup; > + > + if (asprintf(&monitorfile, "%s/%s.monitor", dir, name) < 0) { > + rc = ENOMEM; > + goto cleanup; > + } > + > + if ((fd = open(monitorfile, > + O_WRONLY | O_CREAT | O_TRUNC, > + S_IRUSR | S_IWUSR)) < 0) { > + rc = errno; > + goto cleanup; > + } > + > + if (!(file = fdopen(fd, "w"))) { > + rc = errno; > + close(fd); > + goto cleanup; > + } > + > + if (fprintf(file, "%s", path) < 0) { > + rc = errno; > + goto cleanup; > + } > + > + rc = 0; > + > +cleanup: > + if (file && > + fclose(file) < 0) { > + rc = errno; > + } > + > + VIR_FREE(monitorfile); > + return rc; > +} > + > +static int > +qemudFileReadMonitor(const char *dir, > + const char *name, > + char **path) > +{ > + int rc; > + FILE *file; > + char *monitorfile = NULL; > + > + if (asprintf(&monitorfile, "%s/%s.monitor", dir, name) < 0) { > + rc = ENOMEM; > + goto cleanup; > + } > + > + if (!(file = fopen(monitorfile, "r"))) { > + rc = errno; > + goto cleanup; > + } > + > + if (fscanf(file, "%as", path) != 1) { > + rc = EINVAL; > + goto cleanup; > + } > + > + if (fclose(file) < 0) { > + rc = errno; > + goto cleanup; > + } > + > + rc = 0; > + > + cleanup: > + VIR_FREE(monitorfile); > + return rc; > +} If we re-parse the logfile to extract the monitiro PTY path, this is unneccessary. If not, this can be simplied by just calling the convenient virFileReadAll() method. > + > +static int > +qemudFileDeleteMonitor(const char *dir, > + const char *name) > +{ > + int rc = 0; > + char *pidfile = NULL; > + > + if (asprintf(&pidfile, "%s/%s.monitor", dir, name) < 0) { > + rc = errno; > + goto cleanup; > + } > + > + if (unlink(pidfile) < 0 && errno != ENOENT) > + rc = errno; > + > +cleanup: > + VIR_FREE(pidfile); > + return rc; > +} > + > + > +static int qemudOpenMonitor(virConnectPtr conn, > + struct qemud_driver *driver, > + virDomainObjPtr vm, > + const char *monitor, > + int reconnect); > +/** > + * qemudReconnectVMs > + * > + * Reconnect running vms to the daemon process > + */ > +static int > +qemudReconnectVMs(struct qemud_driver *driver) > +{ > + virDomainObjPtr vm = driver->domains; > + > + while (vm) { > + virDomainDefPtr tmp; > + char *config = NULL; > + char *monitor = NULL; > + int rc; > + > + /* Read pid */ > + if ((rc = virFileReadPid(driver->stateDir, vm->def->name, &vm->pid)) == 0) { > + virFileDeletePid(driver->stateDir, vm->def->name); > + DEBUG("Found pid %d for '%s'", vm->pid, vm->def->name); > + } else > + goto next; > + > + if ((config = virDomainConfigFile(NULL, > + driver->stateDir, > + vm->def->name)) == NULL) { > + qemudLog(QEMUD_ERR, _("Failed to read back domain config for %s\n"), > + vm->def->name); > + goto next; > + } > + > + /* Try and load the config */ > + tmp = virDomainDefParseFile(NULL, driver->caps, config); > + unlink(config); > + if (tmp) { > + vm->newDef = vm->def; > + vm->def = tmp; > + } > + > + /* read back monitor path */ > + if ((rc = qemudFileReadMonitor(driver->stateDir, vm->def->name, &monitor)) != 0) { > + qemudLog(QEMUD_ERR, _("Failed to read back monitor path for %s: %s\n"), > + vm->def->name, strerror(rc)); > + goto next; > + } > + qemudFileDeleteMonitor(driver->stateDir, vm->def->name); > + > + /* FIXME: reconnect stdout/stderr via /proc/pid/fd/ */ > + > + if ((rc = qemudOpenMonitor(NULL, driver, vm, monitor, 1)) != 0) { > + qemudLog(QEMUD_ERR, _("Failed to reconnect to monitor for %s: %d\n"), > + vm->def->name, rc); > + goto next; > + } > + vm->def->id = driver->nextvmid++; The ID of a vm must never change for until it is rebooted. Simply don't overwrite the existing vm->def->id that we jjust loaded off disk. And instead adjust the nextvmid field, eg if (vm->def->id >= driver->nextvmid) driver->nextvmid = vm->def->id + 1; > + vm->state = VIR_DOMAIN_RUNNING; > +next: > + VIR_FREE(config); > + VIR_FREE(monitor); > + vm = vm->next; > + } > + return 0; > +} > + > /** > * qemudStartup: > * > @@ -197,6 +372,10 @@ qemudStartup(void) { > > if ((base = strdup (SYSCONF_DIR "/libvirt")) == NULL) > goto out_of_memory; > + > + if (asprintf (&qemu_driver->stateDir, > + "%s/run/libvirt/qemu/", LOCAL_STATE_DIR) == -1) > + goto out_of_memory; > } else { > if (!(pw = getpwuid(uid))) { > qemudLog(QEMUD_ERR, _("Failed to find user record for uid '%d': %s\n"), > @@ -210,6 +389,10 @@ qemudStartup(void) { > > if (asprintf (&base, "%s/.libvirt", pw->pw_dir) == -1) > goto out_of_memory; > + > + if (asprintf (&qemu_driver->stateDir, > + "%s/run/libvirt/qemu/", base) == -1) > + goto out_of_memory; > } > > /* Configuration paths are either ~/.libvirt/qemu/... (session) or > @@ -250,6 +433,8 @@ qemudStartup(void) { > qemudShutdown(); > return -1; > } > + qemudReconnectVMs(qemu_driver); > + > if (virNetworkLoadAllConfigs(NULL, > &qemu_driver->networks, > qemu_driver->networkConfigDir, > @@ -329,6 +514,34 @@ qemudActive(void) { > return 0; > } > > +/** > + * qemudSaveDomainState > + * > + * Save the full state of a running domain to statedir > + * > + * Returns 0 on success > + */ > +static int > +qemudSaveDomainState(struct qemud_driver * driver, virDomainObjPtr vm) { > + int ret; > + > + if ((ret = virFileWritePid(driver->stateDir, vm->def->name, vm->pid)) != 0) { > + qemudLog(QEMUD_ERR, _("Unable to safe pidfile for %s: %s\n"), > + vm->def->name, strerror(ret)); > + return ret; > + } > + if ((ret = virDomainSaveConfig(NULL, driver->stateDir, vm->def))) { > + qemudLog(QEMUD_ERR, _("Unable to save domain %s\n"), vm->def->name); > + return ret; > + } > + if ((ret = qemudFileWriteMonitor(driver->stateDir, vm->def->name, vm->monitorpath)) != 0) { > + qemudLog(QEMUD_ERR, _("Unable to monitor file for %s: %s\n"), > + vm->def->name, strerror(ret)); > + return ret; > + } > + return 0; > +} > + This will need to be called at time of VM creation, and the XSL config will need updating whether live config changes. > /** > * qemudShutdown: > * > @@ -349,10 +562,14 @@ qemudShutdown(void) { > while (vm) { > virDomainObjPtr next = vm->next; > if (virDomainIsActive(vm)) > +#if 1 > + qemudSaveDomainState(qemu_driver, vm); > +#else > qemudShutdownVMDaemon(NULL, qemu_driver, vm); > if (!vm->persistent) > virDomainRemoveInactive(&qemu_driver->domains, > vm); > +#endif > vm = next; > } > > @@ -389,6 +606,7 @@ qemudShutdown(void) { > VIR_FREE(qemu_driver->networkConfigDir); > VIR_FREE(qemu_driver->networkAutostartDir); > VIR_FREE(qemu_driver->vncTLSx509certdir); > + VIR_FREE(qemu_driver->stateDir); > > if (qemu_driver->brctl) > brShutdown(qemu_driver->brctl); > @@ -499,7 +717,7 @@ qemudCheckMonitorPrompt(virConnectPtr conn ATTRIBUTE_UNUSED, > static int qemudOpenMonitor(virConnectPtr conn, > struct qemud_driver *driver, > virDomainObjPtr vm, > - const char *monitor) { > + const char *monitor, int reconnect) { > int monfd; > char buf[1024]; > int ret = -1; > @@ -520,11 +738,26 @@ static int qemudOpenMonitor(virConnectPtr conn, > goto error; > } > > - ret = qemudReadMonitorOutput(conn, > - driver, vm, monfd, > - buf, sizeof(buf), > - qemudCheckMonitorPrompt, > - "monitor"); > + if (!reconnect) { > + ret = qemudReadMonitorOutput(conn, > + driver, vm, monfd, > + buf, sizeof(buf), > + qemudCheckMonitorPrompt, > + "monitor"); > + > + } else { > + vm->monitor = monfd; > + ret = 0; > + } > + > + if (ret != 0) > + goto error; > + > + if (!(vm->monitorpath = strdup(monitor))) { > + qemudReportError(conn, NULL, NULL, VIR_ERR_NO_MEMORY, > + "%s", _("failed to allocate space for monitor path")); > + goto error; > + } > > /* Keep monitor open upon success */ > if (ret == 0) > @@ -623,7 +856,7 @@ qemudFindCharDevicePTYs(virConnectPtr conn, > } > > /* Got them all, so now open the monitor console */ > - ret = qemudOpenMonitor(conn, driver, vm, monitor); > + ret = qemudOpenMonitor(conn, driver, vm, monitor, 0); > > cleanup: > VIR_FREE(monitor); > @@ -966,12 +1199,11 @@ static int qemudStartVMDaemon(virConnectPtr conn, > > ret = virExec(conn, argv, NULL, &keepfd, &vm->pid, > vm->stdin_fd, &vm->stdout_fd, &vm->stderr_fd, > - VIR_EXEC_NONBLOCK); > + VIR_EXEC_NONBLOCK | VIR_EXEC_SETSID); > if (ret == 0) { > vm->def->id = driver->nextvmid++; > vm->state = migrateFrom ? VIR_DOMAIN_PAUSED : VIR_DOMAIN_RUNNING; > } > - > for (i = 0 ; argv[i] ; i++) > VIR_FREE(argv[i]); > VIR_FREE(argv); > @@ -1037,7 +1269,9 @@ static void qemudShutdownVMDaemon(virConnectPtr conn ATTRIBUTE_UNUSED, > > qemudLog(QEMUD_INFO, _("Shutting down VM '%s'\n"), vm->def->name); > > - kill(vm->pid, SIGTERM); > + if (kill(vm->pid, SIGTERM) < 0) > + qemudLog(QEMUD_ERROR, _("Failed to send SIGTERM to %s (%d): %s\n"), > + vm->def->name, vm->pid, strerror(errno)); > > qemudVMData(driver, vm, vm->stdout_fd); > qemudVMData(driver, vm, vm->stderr_fd); > @@ -1057,13 +1291,9 @@ static void qemudShutdownVMDaemon(virConnectPtr conn ATTRIBUTE_UNUSED, > vm->stderr_fd = -1; > vm->monitor = -1; > > - if (waitpid(vm->pid, NULL, WNOHANG) != vm->pid) { > - kill(vm->pid, SIGKILL); > - if (waitpid(vm->pid, NULL, 0) != vm->pid) { > - qemudLog(QEMUD_WARN, > - "%s", _("Got unexpected pid, damn\n")); > - } > - } > + /* shut if off for sure */ > + kill(vm->pid, SIGKILL); > + virFileDeletePid(driver->stateDir, vm->def->name); > > vm->pid = -1; > vm->def->id = -1; > diff --git a/src/util.c b/src/util.c > index ca14be1..442c810 100644 > --- a/src/util.c > +++ b/src/util.c > @@ -299,14 +299,16 @@ virExec(virConnectPtr conn, > !FD_ISSET(i, keepfd))) > close(i); > > - if (flags & VIR_EXEC_DAEMON) { > + if (flags & VIR_EXEC_DAEMON || flags & VIR_EXEC_SETSID) { > if (setsid() < 0) { > ReportError(conn, VIR_ERR_INTERNAL_ERROR, > _("cannot become session leader: %s"), > strerror(errno)); > _exit(1); > } > + } > > + if (flags & VIR_EXEC_DAEMON) { > if (chdir("/") < 0) { > ReportError(conn, VIR_ERR_INTERNAL_ERROR, > _("cannot change to root directory: %s"), > diff --git a/src/util.h b/src/util.h > index 093ef46..8fbe2cd 100644 > --- a/src/util.h > +++ b/src/util.h > @@ -32,6 +32,7 @@ enum { > VIR_EXEC_NONE = 0, > VIR_EXEC_NONBLOCK = (1 << 0), > VIR_EXEC_DAEMON = (1 << 1), > + VIR_EXEC_SETSID = (1 << 2), > }; Shouldn't we simply be starting all the QEMU VMs with VIR_EXEC_DAEMON so they totally disassociate themselves from libvirtd right away. They will be disassociated anyway if the libvirtd is ever restarted, so best to daemonize from time they are started, to avoid any surprising changes in behaviour 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 dlbewley at lib.ucdavis.edu Tue Oct 7 16:55:49 2008 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Tue, 7 Oct 2008 09:55:49 -0700 (PDT) Subject: [et-mgmt-tools] input on F10 virtualization release notes In-Reply-To: <2131900444.281591223398293181.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> I've been working on the virtualization release notes[1] for Fedora 10 these past several days, and I'm looking for input from those in the know. The advances coming out of the Emerging Technologies projects and Fedora in general are very impressive, and I'd like to do them justice. I added a lot of content quickly yesterday, and the page structure is by no means solid, but there is a pending freeze[2] on October 10th. I'd like to get it into the best and most accurate shape possible before then. There will be a chance to make updates again before the F10 release. I've attempted to describe the improvements to virtualization-related packages between the F9 release versions and the anticipated F10 versions. I've created a table[3] of those versions to help with the comparison. I'd appreciate it if you'd let me know: * if you believe a version bump is pending * if I've left out any packages or features * if I included something not noteworthy * anything else you have to say If you have any comments, contributions, or criticisms at all, please add them to the wiki article/talk page/or email them to me. Thanks! And keep up the great work! [1] https://fedoraproject.org/wiki/Docs/Beats/Virtualization [2] http://poelstra.fedorapeople.org/schedules/f-10/f-10-docs-tasks.html [3] https://fedoraproject.org/wiki/DaleBewley#Virtualization_Release_Notes -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3 From adam.huffman at gmail.com Wed Oct 8 12:58:08 2008 From: adam.huffman at gmail.com (Adam Huffman) Date: Wed, 08 Oct 2008 13:58:08 +0100 Subject: [et-mgmt-tools] virt-manager shared device problem Message-ID: <48ECAE60.5010605@gmail.com> I'm having trouble adding a shared network device to a VM already running on an F9 host. What shows up in the interface is a single greyed out item - "eth0 (not bridged)". In virt-manager.log I see this traceback: [Wed, 08 Oct 2008 13:30:59 virt-manager 22122] ERROR (virt-manager:141) Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/addhardware.py", line 228, in forward if(self.validate(notebook.get_current_page()) != True): File "/usr/share/virt-manager/virtManager/addhardware.py", line 722, in validate net = self.get_config_network() File "/usr/share/virt-manager/virtManager/addhardware.py", line 322, in get_config_network return ["bridge", model.get_value(dev.get_active_iter(), 0)] TypeError: iter must be a GtkTreeIter None The version in use is virt-manager-0.5.4-4.fc9.x86_64. Adam From crobinso at redhat.com Wed Oct 8 13:57:17 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 08 Oct 2008 09:57:17 -0400 Subject: [et-mgmt-tools] virt-manager shared device problem In-Reply-To: <48ECAE60.5010605@gmail.com> References: <48ECAE60.5010605@gmail.com> Message-ID: <48ECBC3D.1040606@redhat.com> Adam Huffman wrote: > I'm having trouble adding a shared network device to a VM already > running on an F9 host. > > What shows up in the interface is a single greyed out item - "eth0 (not > bridged)". > The fact that the nonbridged entry is the initial selection and is actually selectable is a bug, which is fixed upstream and I believe the latest release. virt-manager doesn't set up a bridge for you, one needs to be preconfigured. Do you have a bridge already set up? If so: What are the full contents of shared device drop down? Output of `brctl show`? Thanks, Cole From pasik at iki.fi Wed Oct 8 15:11:03 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 8 Oct 2008 18:11:03 +0300 Subject: [et-mgmt-tools] Re: [Fedora-xen] input on F10 virtualization release notes In-Reply-To: <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> References: <2131900444.281591223398293181.JavaMail.root@zebra.lib.ucdavis.edu> <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <20081008151103.GY9714@edu.joroinen.fi> On Tue, Oct 07, 2008 at 09:55:49AM -0700, Dale Bewley wrote: > I've been working on the virtualization release notes[1] for Fedora 10 > these past several days, and I'm looking for input from those in the > know. The advances coming out of the Emerging Technologies projects and > Fedora in general are very impressive, and I'd like to do them justice. > Very good summary of changes. I'm sure there will be a lot questions about (missing) dom0 support, so maybe add even more information about it. Xensource plans to have pv_ops dom0 support ready for Xen 3.4, so maybe add that information. http://www.xen.org/download/roadmap.html I think (at least earlier) the plan was to submit pv_ops dom0 patches for inclusion in Linux kernel 2.6.28. I'm not sure if that is still the plan. pv_ops/dom0 patch queue: http://xenbits.xen.org/paravirt_ops/patches.hg/ > > I've attempted to describe the improvements to virtualization-related > packages between the F9 release versions and the anticipated F10 > versions. I've created a table[3] of those versions to help with the > comparison. I'd appreciate it if you'd let me know: > The table is really nice and gives nice overview of the changes made. > * if you believe a version bump is pending > * if I've left out any packages or features > * if I included something not noteworthy > * anything else you have to say > > If you have any comments, contributions, or criticisms at all, please > add them to the wiki article/talk page/or email them to me. > -- Pasi From adam.huffman at gmail.com Wed Oct 8 15:53:55 2008 From: adam.huffman at gmail.com (Adam Huffman) Date: Wed, 08 Oct 2008 16:53:55 +0100 Subject: [et-mgmt-tools] virt-manager shared device problem In-Reply-To: <48ECBC3D.1040606@redhat.com> References: <48ECAE60.5010605@gmail.com> <48ECBC3D.1040606@redhat.com> Message-ID: <48ECD793.9000904@gmail.com> Cole Robinson wrote: > Adam Huffman wrote: > >> I'm having trouble adding a shared network device to a VM already >> running on an F9 host. >> >> What shows up in the interface is a single greyed out item - "eth0 (not >> bridged)". >> >> > > The fact that the nonbridged entry is the initial selection and > is actually selectable is a bug, which is fixed upstream and I > believe the latest release. > > virt-manager doesn't set up a bridge for you, one needs to be > preconfigured. Do you have a bridge already set up? If so: > > I didn't, but I have one now, having followed the instructions at: http://poelcat.wordpress.com/2008/09/05/bridged-networking-in-virt-manager/ and the device is selectable in the interface. Once added to a guest it does work. However, now another guest on the same host, using the default NAT network, seems to have lost its connection. > What are the full contents of shared device drop down? > Output of `brctl show`? > > bridge name bridge id STP enabled interfaces br0 8000.00188b1d9acb no eth0 vnet1 pan0 8000.000000000000 no virbr0 8000.00ff3d160b55 yes vnet0 Adam From crobinso at redhat.com Wed Oct 8 16:05:37 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 08 Oct 2008 12:05:37 -0400 Subject: [et-mgmt-tools] virt-manager shared device problem In-Reply-To: <48ECD793.9000904@gmail.com> References: <48ECAE60.5010605@gmail.com> <48ECBC3D.1040606@redhat.com> <48ECD793.9000904@gmail.com> Message-ID: <48ECDA51.3010902@redhat.com> Adam Huffman wrote: > Cole Robinson wrote: >> Adam Huffman wrote: >> >>> I'm having trouble adding a shared network device to a VM already >>> running on an F9 host. >>> >>> What shows up in the interface is a single greyed out item - "eth0 (not >>> bridged)". >>> >>> >> The fact that the nonbridged entry is the initial selection and >> is actually selectable is a bug, which is fixed upstream and I >> believe the latest release. >> >> virt-manager doesn't set up a bridge for you, one needs to be >> preconfigured. Do you have a bridge already set up? If so: >> >> > I didn't, but I have one now, having followed the instructions at: > http://poelcat.wordpress.com/2008/09/05/bridged-networking-in-virt-manager/ > and the device is selectable in the interface. > > Once added to a guest it does work. > > However, now another guest on the same host, using the default NAT > network, seems to have lost its connection. Hmm, not sure about that. Maybe try restarting libvirtd, the network rules may need to be reapplied. If that doesn't work, please file a bug against libvirt. Thanks, Cole From rjones at redhat.com Wed Oct 8 16:12:52 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 8 Oct 2008 17:12:52 +0100 Subject: [et-mgmt-tools] Re: [libvirt] input on F10 virtualization release notes In-Reply-To: <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> References: <2131900444.281591223398293181.JavaMail.root@zebra.lib.ucdavis.edu> <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <20081008161252.GD15772@amd.home.annexia.org> On Tue, Oct 07, 2008 at 09:55:49AM -0700, Dale Bewley wrote: > [1] https://fedoraproject.org/wiki/Docs/Beats/Virtualization > [2] http://poelstra.fedorapeople.org/schedules/f-10/f-10-docs-tasks.html > [3] https://fedoraproject.org/wiki/DaleBewley#Virtualization_Release_Notes Certainly looks good to me -- thanks for taking the time to do this. You might want to mention virt-df in there (see my signature). Although it has been backported to F-9, it is "new" in Fedora 10 because it didn't exist when F-9 started out. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jboggs at redhat.com Wed Oct 8 16:22:05 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 08 Oct 2008 12:22:05 -0400 Subject: [et-mgmt-tools] [patch] virt-convert - disk signature support - patch 1 Message-ID: <48ECDE2D.70309@redhat.com> This adds the underlying support for disk signatures into virt-convert disk class for each disk. Additional changes to follow in completing implementation -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-diskcfg-checksum-diskclass-10081218.patch Type: text/x-patch Size: 571 bytes Desc: not available URL: From berrange at redhat.com Wed Oct 8 16:26:19 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 8 Oct 2008 17:26:19 +0100 Subject: [et-mgmt-tools] [patch] virt-convert - disk signature support - patch 1 In-Reply-To: <48ECDE2D.70309@redhat.com> References: <48ECDE2D.70309@redhat.com> Message-ID: <20081008162619.GK19052@redhat.com> On Wed, Oct 08, 2008 at 12:22:05PM -0400, Joey Boggs wrote: > This adds the underlying support for disk signatures into virt-convert > disk class for each disk. Additional changes to follow in completing > implementation There's not much point in doing md5 and sha1, both are more or less equivalent strength and compromised algorithms. Doing both is just wasting CPU resources. Pick either md5 or sha1 for sake of compatability with old python, and then sha256 for strength. > diff -r 2aba69a1a16c virtconv/diskcfg.py > --- a/virtconv/diskcfg.py Mon Oct 06 12:21:17 2008 -0400 > +++ b/virtconv/diskcfg.py Wed Oct 08 12:19:19 2008 -0400 > @@ -53,6 +53,11 @@ > "vdisk": DISK_FORMAT_VDISK, > } > > +checksum_types = { > + CSUM_MD5 = 'md5' > + CSUM_SHA1 = 'sha1' > + CSUM_SHA256 = 'sha256' > +} > def ensuredirs(path): > """ > Make sure that all the containing directories of the given file > @@ -83,6 +88,7 @@ > self.bus = bus > self.type = type > self.clean = [] > + self.csum_dict = {} > > def cleanup(self): > """ Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Wed Oct 8 16:48:41 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 08 Oct 2008 12:48:41 -0400 Subject: [et-mgmt-tools] [patch] virt-convert - disk signature support - patch 1 In-Reply-To: <20081008162619.GK19052@redhat.com> References: <48ECDE2D.70309@redhat.com> <20081008162619.GK19052@redhat.com> Message-ID: <48ECE469.6020708@redhat.com> Daniel P. Berrange wrote: > On Wed, Oct 08, 2008 at 12:22:05PM -0400, Joey Boggs wrote: >> This adds the underlying support for disk signatures into virt-convert >> disk class for each disk. Additional changes to follow in completing >> implementation > > There's not much point in doing md5 and sha1, both are more or > less equivalent strength and compromised algorithms. Doing both > is just wasting CPU resources. Pick either md5 or sha1 for sake > of compatability with old python, and then sha256 for strength. > OVF seems to offer sha-1 hashes for packaged files, so let's use that and sha256. >> diff -r 2aba69a1a16c virtconv/diskcfg.py >> --- a/virtconv/diskcfg.py Mon Oct 06 12:21:17 2008 -0400 >> +++ b/virtconv/diskcfg.py Wed Oct 08 12:19:19 2008 -0400 >> @@ -53,6 +53,11 @@ >> "vdisk": DISK_FORMAT_VDISK, >> } >> >> +checksum_types = { >> + CSUM_MD5 = 'md5' >> + CSUM_SHA1 = 'sha1' >> + CSUM_SHA256 = 'sha256' >> +} Stick a new line after this to preserve the previous spacing. >> def ensuredirs(path): >> """ >> Make sure that all the containing directories of the given file >> @@ -83,6 +88,7 @@ >> self.bus = bus >> self.type = type >> self.clean = [] >> + self.csum_dict = {} >> >> def cleanup(self): >> """ > Thanks, Cole From berrange at redhat.com Wed Oct 8 17:12:58 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 8 Oct 2008 18:12:58 +0100 Subject: [et-mgmt-tools] virt-manager shared device problem In-Reply-To: <48ECDA51.3010902@redhat.com> References: <48ECAE60.5010605@gmail.com> <48ECBC3D.1040606@redhat.com> <48ECD793.9000904@gmail.com> <48ECDA51.3010902@redhat.com> Message-ID: <20081008171258.GP19052@redhat.com> On Wed, Oct 08, 2008 at 12:05:37PM -0400, Cole Robinson wrote: > Adam Huffman wrote: > > Cole Robinson wrote: > >> Adam Huffman wrote: > >> > >>> I'm having trouble adding a shared network device to a VM already > >>> running on an F9 host. > >>> > >>> What shows up in the interface is a single greyed out item - "eth0 (not > >>> bridged)". > >>> > >>> > >> The fact that the nonbridged entry is the initial selection and > >> is actually selectable is a bug, which is fixed upstream and I > >> believe the latest release. > >> > >> virt-manager doesn't set up a bridge for you, one needs to be > >> preconfigured. Do you have a bridge already set up? If so: > >> > >> > > I didn't, but I have one now, having followed the instructions at: > > http://poelcat.wordpress.com/2008/09/05/bridged-networking-in-virt-manager/ > > and the device is selectable in the interface. > > > > Once added to a guest it does work. > > > > However, now another guest on the same host, using the default NAT > > network, seems to have lost its connection. > > Hmm, not sure about that. Maybe try restarting libvirtd, the > network rules may need to be reapplied. If that doesn't work, > please file a bug against libvirt. Don't restart the daemon - that'll kill all guests. it is sufficient to send it SIGHUP, or 'service libvirtd reload' to make it restore iptables rules. This page is the canonical source for recommended libvirt networking configurations: http://wiki.libvirt.org/page/Networking If anyone has equivalent bridging setup notes for OS besides the existing Debian/Ubutun/Fedora/RHEL notes, please add them. eg for SLES / OpenSUSE or Gentoo 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 fj0588di at aa.jp.fujitsu.com Thu Oct 9 09:10:13 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Thu, 9 Oct 2008 18:10:13 +0900 Subject: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH] virt-managercallsmigration API In-Reply-To: <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> References: <48C4EF66.9070400@redhat.com> <200809112004.FEC57380.J0G9K96E@aa.jp.fujitsu.com> <200809191843.GCG69223.96J09KGE@aa.jp.fujitsu.com> <20080919100727.GM18194@redhat.com> <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> Message-ID: <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> Hi, I make the prototype patch. This patch is displayed destination host in a sub-menu, as follows. right-click | +- Run Pause Shutdown -------- Migrate ----> host1.example.com host2.example.com host3.example.com The item that display in a sub-menu is the host which is a state of ACTIVE or INACTIVE besides the source host. When the host which is a state of ACTIVE or INACTIVE besides a source host doesn't exist, "(None)" that is insensitive is displayed, as follows. right-click | +- Run Pause Shutdown -------- Migrate ----> (None) domain.py | 6 ++++ engine.py | 36 ++++++++++++++++++++++++++++ manager.py | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 117 insertions(+), 3 deletions(-) Thanks, Shigeki Sakamoto. > Hi, Daniel > > Sorry for delaying response. > > Thank you for your suggestions. I understand. > I will make the prototype patch! > > Thanks > Shigeki Sakamoto. > > > On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote: > > > > > > > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > > > > development happens, > > > > > > > > OK. For this, I tried to hear in et-mgmt-list. > > > > > > > > > > I'm sorry to be pressing, but would you give me a comment on this patch for > > > going on the next step to migrate from virt-manager ? > > > I attached screenshots this patch shows. > > > > I think rather than having it popup a new window with a list of hosts to > > migrate to, you could just have a sub-menu where you choose the destination > > host directly. > > > > eg, > > > > right-click > > | > > +- Run > > Pause > > Shutdown > > -------- > > Migrate ----> host1.example.com > > host2.example.com > > host3.example.com > > ...etc... > > > > When the user selects one of these hosts, it'd popup a confirmation > > window, and do the neccessary migration checks, and then allow the > > admin to confirm to start the migration. > > > > > > > I sent an e-mail last month with proposals for doing this within libvirt. I put > > > > > up all of the information I have in the libvirt wiki here: > > > > > > > > > > http://wiki.libvirt.org/page/TodoPreMigrationChecks > > > > > > > > Thank you for your information. I see above libvirt wiki and I have a few > > > > idea adding checks within libvirt. These point of view are Guest and Host sanity > > > > in BASIC CHECKS. How about this points ? > > > > > > > > 1)Guest sanity is checking whether already existing or not on the destination. > > > > Otherwise the uniqueness of the domain(UUID, name) are lost. > > > > * I think that it is right to check this in libvirt. How do you think this ? > > > > Yes, checking for name/uuid uniqueness has to be done inside libvirt by > > each hypervisor driver according to their own rules. > > > > > > 2)Host sanity is checking whether a migration flag is ON at each virtualization. > > > > virt-manager will need to check the kind of things on the TodoPreMigrationChecks > > wiki page. > > > > > > Daniel > > -- > > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| > > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -------------- next part -------------- A non-text attachment was scrubbed... Name: migrate_submenu.patch Type: application/octet-stream Size: 10942 bytes Desc: not available URL: From federico at panizzolo.it Thu Oct 9 10:03:25 2008 From: federico at panizzolo.it (Federico Fanton) Date: Thu, 09 Oct 2008 12:03:25 +0200 Subject: [et-mgmt-tools] Creating a guest server Message-ID: <48EDD6ED.4020505@panizzolo.it> Hi everyone! I'm new to virt-manager, I'm trying to create a Xen VM that would act as a server in my LAN.. I can't figure out how I should configure the network :( How should I configure virt-manager/virt-install so that I can get access to the VM from the LAN? (e.g. ping, ssh..) Many thanks for your time! From mraley at globalclassroom.us Thu Oct 9 12:38:26 2008 From: mraley at globalclassroom.us (Mike Raley) Date: Thu, 9 Oct 2008 08:38:26 -0400 Subject: [et-mgmt-tools] virt-p2v issue Message-ID: Greetings, I am attempting to use virt-p2v to move a physical server to a xen instance. The Xen box is CentOS 5.2 fully updated and running Xen. The server to migrate is also CentOS 5.2 fully updated. Everything appears to work entirely fine with the process. However, during copying it errors out with the following error: Unix.Unix_error(13, "read", "") at which point the machine is frozen and I have no resort except to reboot. I have tried varying parameters, even going to a test server to migrate, to no effect. Unfortunately, googling the issue has not brought any level of success. Has anyone experienced this issue before or have any thoughts or suggestions? This is an excellent tool that will save me alot of time in migration, so I would really like to find a way to make this work. Many thanks! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From federico at panizzolo.it Thu Oct 9 13:02:32 2008 From: federico at panizzolo.it (Federico Fanton) Date: Thu, 09 Oct 2008 15:02:32 +0200 Subject: [et-mgmt-tools] Creating a guest server In-Reply-To: <48EDD6ED.4020505@panizzolo.it> References: <48EDD6ED.4020505@panizzolo.it> Message-ID: <48EE00E8.6040005@panizzolo.it> Federico Fanton wrote: > How should I configure virt-manager/virt-install so that I can get > access to the VM from the LAN? (e.g. ping, ssh..) Sorry, I found it.. virt-install -p -n test -l ftp://192.168.1.43 -f /dev/vg/test-disk -f /dev/vg/test-swap -r 384 -w bridge:eth0 Thanks all the same! From jboggs at redhat.com Thu Oct 9 13:45:30 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 09 Oct 2008 09:45:30 -0400 Subject: [et-mgmt-tools] [patch] virt-convert - disk signature support - patch 1 In-Reply-To: <48ECE469.6020708@redhat.com> References: <48ECDE2D.70309@redhat.com> <20081008162619.GK19052@redhat.com> <48ECE469.6020708@redhat.com> Message-ID: <48EE0AFA.2050501@redhat.com> Corrected spacing and removed md5 Cole Robinson wrote: > Daniel P. Berrange wrote: > >> On Wed, Oct 08, 2008 at 12:22:05PM -0400, Joey Boggs wrote: >> >>> This adds the underlying support for disk signatures into virt-convert >>> disk class for each disk. Additional changes to follow in completing >>> implementation >>> >> There's not much point in doing md5 and sha1, both are more or >> less equivalent strength and compromised algorithms. Doing both >> is just wasting CPU resources. Pick either md5 or sha1 for sake >> of compatability with old python, and then sha256 for strength. >> >> > > OVF seems to offer sha-1 hashes for packaged files, so let's > use that and sha256. > > >>> diff -r 2aba69a1a16c virtconv/diskcfg.py >>> --- a/virtconv/diskcfg.py Mon Oct 06 12:21:17 2008 -0400 >>> +++ b/virtconv/diskcfg.py Wed Oct 08 12:19:19 2008 -0400 >>> @@ -53,6 +53,11 @@ >>> "vdisk": DISK_FORMAT_VDISK, >>> } >>> >>> +checksum_types = { >>> + CSUM_MD5 = 'md5' >>> + CSUM_SHA1 = 'sha1' >>> + CSUM_SHA256 = 'sha256' >>> +} >>> > > Stick a new line after this to preserve the previous spacing. > > >>> def ensuredirs(path): >>> """ >>> Make sure that all the containing directories of the given file >>> @@ -83,6 +88,7 @@ >>> self.bus = bus >>> self.type = type >>> self.clean = [] >>> + self.csum_dict = {} >>> >>> def cleanup(self): >>> """ >>> > > Thanks, > Cole > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-diskcfg-checksum-diskclass-10090935.patch Type: text/x-patch Size: 551 bytes Desc: not available URL: From jboggs at redhat.com Thu Oct 9 14:53:13 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 09 Oct 2008 10:53:13 -0400 Subject: [et-mgmt-tools] [patch] virt-convert - disk signature support - patch 1 In-Reply-To: <48EE0AFA.2050501@redhat.com> References: <48ECDE2D.70309@redhat.com> <20081008162619.GK19052@redhat.com> <48ECE469.6020708@redhat.com> <48EE0AFA.2050501@redhat.com> Message-ID: <48EE1AD9.20101@redhat.com> Did some more testing and made some syntax changes, should work now Joey Boggs wrote: > Corrected spacing and removed md5 > > > Cole Robinson wrote: >> Daniel P. Berrange wrote: >> >>> On Wed, Oct 08, 2008 at 12:22:05PM -0400, Joey Boggs wrote: >>> >>>> This adds the underlying support for disk signatures into >>>> virt-convert disk class for each disk. Additional changes to follow >>>> in completing implementation >>>> >>> There's not much point in doing md5 and sha1, both are more or >>> less equivalent strength and compromised algorithms. Doing both >>> is just wasting CPU resources. Pick either md5 or sha1 for sake >>> of compatability with old python, and then sha256 for strength. >>> >>> >> >> OVF seems to offer sha-1 hashes for packaged files, so let's >> use that and sha256. >> >> >>>> diff -r 2aba69a1a16c virtconv/diskcfg.py >>>> --- a/virtconv/diskcfg.py Mon Oct 06 12:21:17 2008 -0400 >>>> +++ b/virtconv/diskcfg.py Wed Oct 08 12:19:19 2008 -0400 >>>> @@ -53,6 +53,11 @@ >>>> "vdisk": DISK_FORMAT_VDISK, >>>> } >>>> >>>> +checksum_types = { >>>> + CSUM_MD5 = 'md5' >>>> + CSUM_SHA1 = 'sha1' >>>> + CSUM_SHA256 = 'sha256' >>>> +} >>>> >> >> Stick a new line after this to preserve the previous spacing. >> >> >>>> def ensuredirs(path): >>>> """ >>>> Make sure that all the containing directories of the given file >>>> @@ -83,6 +88,7 @@ >>>> self.bus = bus >>>> self.type = type >>>> self.clean = [] >>>> + self.csum_dict = {} >>>> >>>> def cleanup(self): >>>> """ >>>> >> >> Thanks, >> Cole >> > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-convert-diskcfg-checksum-diskclass-100901050.patch Type: text/x-patch Size: 710 bytes Desc: not available URL: From bkearney at redhat.com Thu Oct 9 14:58:55 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Oct 2008 10:58:55 -0400 Subject: [et-mgmt-tools] RFC On importing raw images Message-ID: <48EE1C2F.7050401@redhat.com> We are starting to look at more interesting use cases around bringing in existing appliances into virt-manager. Joey has some interesting questions about driver, but I wanted to bring up an easier one. Some of public appliances which exist are raw disk images which can easily be booted, but have no virt-image xml file. The user can of course manually create the file, but I think it would be nice to have the tooling help this. I could see one of the following solutions. Can folks pipe in with comments on these or another approach? (1) Create an "interactive" mode for virt-image which prompts the user. (2) Modify virt-image to allow for all data normally the xml to be passed at command line (example, add a --imagefile parameter) (3)Create a simple pre-processor to achieve 1 or 2 above. -- bk From jboggs at redhat.com Thu Oct 9 15:51:39 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 09 Oct 2008 11:51:39 -0400 Subject: [et-mgmt-tools] Re: [Thincrust-devel] RFC On importing raw images In-Reply-To: <48EE218D.9070106@redhat.com> References: <48EE1C2F.7050401@redhat.com> <48EE218D.9070106@redhat.com> Message-ID: <48EE288B.8030608@redhat.com> David Huff wrote: > Bryan Kearney wrote: >> We are starting to look at more interesting use cases around bringing >> in existing appliances into virt-manager. Joey has some interesting >> questions about driver, but I wanted to bring up an easier one. >> >> Some of public appliances which exist are raw disk images which can >> easily be booted, but have no virt-image xml file. The user can of >> course manually create the file, but I think it would be nice to have >> the tooling help this. I could see one of the following solutions. >> Can folks pipe in with comments on these or another approach? >> >> >> (1) Create an "interactive" mode for virt-image which prompts the user. > Doesn't virt install already have a kindaof an interactive mode for > creating a new image? I think Bryan's hinting at a way to import just an imagefile and the interactive portion fills in the blanks about the memory/etc >> (2) Modify virt-image to allow for all data normally the xml to be >> passed at command line (example, add a --imagefile parameter) >> (3)Create a simple pre-processor to achieve 1 or 2 above. >> >> >> -- bk >> >> >> _______________________________________________ >> Thincrust-devel mailing list >> Thincrust-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/thincrust-devel > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From crobinso at redhat.com Thu Oct 9 16:23:13 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 09 Oct 2008 12:23:13 -0400 Subject: [et-mgmt-tools] RFC On importing raw images In-Reply-To: <48EE1C2F.7050401@redhat.com> References: <48EE1C2F.7050401@redhat.com> Message-ID: <48EE2FF1.3020102@redhat.com> Bryan Kearney wrote: > We are starting to look at more interesting use cases around bringing in > existing appliances into virt-manager. Joey has some interesting > questions about driver, but I wanted to bring up an easier one. > > Some of public appliances which exist are raw disk images which can > easily be booted, but have no virt-image xml file. The user can of > course manually create the file, but I think it would be nice to have > the tooling help this. I could see one of the following solutions. Can > folks pipe in with comments on these or another approach? > > (1) Create an "interactive" mode for virt-image which prompts the user. Interactive shouldn't be our first goal, if a goal at all. We should design for the command line options and build a cli wizard as an afterthought. > (2) Modify virt-image to allow for all data normally the xml to be > passed at command line (example, add a --imagefile parameter) > (3)Create a simple pre-processor to achieve 1 or 2 above. > Hmm, the whole problem of taking an existing disk image and turning into something useful is not handled well by any of the virt-* tools. There needs to be an explicit way using one of the tools to say 'Don't install anything on this, just build an xml file with these options'. In turn there could be a flag to dump out libvirt xml or virt-image xml. The main problem is, where do we do this? - virt-install: Seems the only option for libvirt xml, if we want to define and start the guest. But what about just dumping out the xml? Seems like it may be getting a bit too ambitious. There are lots of virt-install options that don't map well to virt-image, though we could just build the xml and feed it through a libvirt xml -> virt-image parser in virt-convert. - virt-image: no go for libvirt xml, but could be expanded to build image xml, and probably the most consistent place to do it. - separate tool, something like virt-import? would duplicate all the option parsing, but probably the cleanest solution. I'd have to look at it all a bit more and determine what it would really require to build up virt-image xml and how the options would differ from a subset of virt-install options to make an informed decision. Thanks, Cole From crobinso at redhat.com Thu Oct 9 16:36:41 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 09 Oct 2008 12:36:41 -0400 Subject: [et-mgmt-tools] [patch] virt-convert - disk signature support - patch 1 In-Reply-To: <48EE1AD9.20101@redhat.com> References: <48ECDE2D.70309@redhat.com> <20081008162619.GK19052@redhat.com> <48ECE469.6020708@redhat.com> <48EE0AFA.2050501@redhat.com> <48EE1AD9.20101@redhat.com> Message-ID: <48EE3319.4030904@redhat.com> Joey Boggs wrote: > Did some more testing and made some syntax changes, should work now > > > Thanks, applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=3e2e7db24cb5 - Cole From crobinso at redhat.com Thu Oct 9 16:38:00 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 09 Oct 2008 12:38:00 -0400 Subject: [et-mgmt-tools] Re: [PATCH 4/9]: virt-manager: allow multiple sparclines per widget In-Reply-To: <20081004201911.GD29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004201911.GD29914@bogon.ms20.nix> Message-ID: <48EE3368.8020807@redhat.com> Guido G?nther wrote: > Add num_sets property so a sparkline graph can have multiple lines > > all data is still stored in a 1D array so we can still use g_param_spec_double > for type checking. This removes the support for non cairo builds. > -- Guido > Committed now. Thanks, Cole From crobinso at redhat.com Thu Oct 9 16:38:13 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 09 Oct 2008 12:38:13 -0400 Subject: [et-mgmt-tools] Re: [PATCH 5/9]: virt-manager: add sparkline "color" property In-Reply-To: <20081004202058.GE29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004202058.GE29914@bogon.ms20.nix> Message-ID: <48EE3375.2020304@redhat.com> Guido G?nther wrote: > Add color property so sparklines in the same widget can have different colors > -- Guido > Committed now. Thanks, Cole From crobinso at redhat.com Thu Oct 9 16:45:51 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 09 Oct 2008 12:45:51 -0400 Subject: [et-mgmt-tools] Re: [PATCH 9/9]: virt-manager: add sparcline to vm/connection overview In-Reply-To: <20081004203046.GI29914@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> Message-ID: <48EE353F.1080207@redhat.com> Guido G?nther wrote: > Finally display a combined sparcline for rx & tx (network) and input & > output (disk) in the Network I/O and Disk I/O columns in the vm machine > overview. > -- Guido > > diff -r 134368ad3def src/virtManager/connection.py > --- a/src/virtManager/connection.py Sat Oct 04 17:04:56 2008 +0200 > +++ b/src/virtManager/connection.py Sat Oct 04 17:27:01 2008 +0200 > @@ -1056,6 +1056,14 @@ > > def disk_io_rate(self): > return self.disk_read_rate() + self.disk_write_rate() > + > + def disk_io_vector_limit(self, dummy): > + """No point to accumulate unnormalized I/O for a conenction""" > + return [ 0.0 ] > + > + def network_traffic_vector_limit(self, dummy): > + """No point to accumulate unnormalized Rx/Tx for a conenction""" > + return [ 0.0 ] > > def uuidstr(self, rawuuid): > hex = ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'] > diff -r 134368ad3def src/virtManager/domain.py > --- a/src/virtManager/domain.py Sat Oct 04 17:04:56 2008 +0200 > +++ b/src/virtManager/domain.py Sat Oct 04 17:27:01 2008 +0200 > @@ -422,6 +422,14 @@ > vector.append(0) > return vector > > + def in_out_vector_limit(self, data, limit): > + l = len(data)/2 > + end = [l, limit][l > limit] > + if l > limit: > + data = data[0:end] + data[l:l+end] This piece here was giving me some trouble. If we shrink data here, then the line below will try to grab an out of bound index. > + d = map(lambda x,y: (x + y)/2, data[0:end], data[l:l+end]) Maybe this should be ... data[0:end], data[end:end*2] or similar. Also, the scaling problems with the disk polling can be _really_ bad (though it's no fault of the code). If I have polling going once a second, and single guest running with six disks and a nic, the UI is completely locked up. So I'd like to hold off on committing the actual polling work until we put the gconf values in to disable this. It doesn't even need to wired up to the gui for now, I can do that after this its committed if you'd like (the prefs dialog needs an overhaul anyways, but that can come after). Thanks, Cole From berrange at redhat.com Thu Oct 9 19:55:59 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 9 Oct 2008 20:55:59 +0100 Subject: [et-mgmt-tools] RFC On importing raw images In-Reply-To: <48EE2FF1.3020102@redhat.com> References: <48EE1C2F.7050401@redhat.com> <48EE2FF1.3020102@redhat.com> Message-ID: <20081009195559.GC2941@redhat.com> On Thu, Oct 09, 2008 at 12:23:13PM -0400, Cole Robinson wrote: > Bryan Kearney wrote: > > We are starting to look at more interesting use cases around bringing in > > existing appliances into virt-manager. Joey has some interesting > > questions about driver, but I wanted to bring up an easier one. > > > > Some of public appliances which exist are raw disk images which can > > easily be booted, but have no virt-image xml file. The user can of > > course manually create the file, but I think it would be nice to have > > the tooling help this. I could see one of the following solutions. Can > > folks pipe in with comments on these or another approach? > > > > > (1) Create an "interactive" mode for virt-image which prompts the user. > > Interactive shouldn't be our first goal, if a goal at all. We > should design for the command line options and build a cli > wizard as an afterthought. > > > (2) Modify virt-image to allow for all data normally the xml to be > > passed at command line (example, add a --imagefile parameter) > > (3)Create a simple pre-processor to achieve 1 or 2 above. > > > > Hmm, the whole problem of taking an existing disk image and > turning into something useful is not handled well by any of > the virt-* tools. > > There needs to be an explicit way using one of the tools to > say 'Don't install anything on this, just build an xml file > with these options'. In turn there could be a flag to dump > out libvirt xml or virt-image xml. > > The main problem is, where do we do this? It really isn't all that much different from the live cd case where there's no installer either - in fact the live cd installer class in virtinst can basically do 90% of the neccessary stuff already - just doesn't need to bother with adding a CDROM device. > - virt-install: Seems the only option for libvirt xml, if > we want to define and start the guest. But what about just > dumping out the xml? Seems like it may be getting a bit > too ambitious. There are lots of virt-install options that > don't map well to virt-image, though we could just build > the xml and feed it through a libvirt xml -> virt-image > parser in virt-convert. How about just adding a '--preinstalled' flag, handled in the same way as --livecd, just causing it to skip install phase and boot it straight off. This could work in virt-manager too - in the wizard step where you select install source. You currently chose network install source, PXE, or local media. Simply add a fourth 'pre-installed'. All the rest of the wizard steps still apply, so we'd want to share all that. > - virt-image: no go for libvirt xml, but could be expanded > to build image xml, and probably the most consistent place > to do it. Yeah, I don't think its applicable for virt-image. virt-image is really focused on having all the domain metadata upfront and not prompting the user for it. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jboggs at redhat.com Thu Oct 9 20:32:18 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 09 Oct 2008 16:32:18 -0400 Subject: [et-mgmt-tools] [patch] virtinst - ImageParser support disk checksum parsing, patch 2 of disk checksum feature Message-ID: <48EE6A52.4080707@redhat.com> Adds support to parse disk signature values from ImageParser, updates image.rng schema as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: imageparser-support-checksum-values-1627.patch Type: text/x-patch Size: 1479 bytes Desc: not available URL: From berrange at redhat.com Thu Oct 9 20:34:00 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 9 Oct 2008 21:34:00 +0100 Subject: [et-mgmt-tools] [patch] virtinst - ImageParser support disk checksum parsing, patch 2 of disk checksum feature In-Reply-To: <48EE6A52.4080707@redhat.com> References: <48EE6A52.4080707@redhat.com> Message-ID: <20081009203400.GM2941@redhat.com> On Thu, Oct 09, 2008 at 04:32:18PM -0400, Joey Boggs wrote: > Adds support to parse disk signature values from ImageParser, updates > image.rng schema as well. ACK. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From martial.paupe at metservice.com Thu Oct 9 20:55:58 2008 From: martial.paupe at metservice.com (Martial Paupe) Date: Fri, 10 Oct 2008 09:55:58 +1300 Subject: [et-mgmt-tools] Try to use cft ... Message-ID: <200810100955.58361.martial.paupe@metservice.com> Hi, I'm trying to use cft but I've got that error when I begin a session. # cft begin httpd /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:403:in `unsafe_validate': Invalid 'failovermethod' value "priorit". Valid values are absent. Valid values match (?-mix:roundrobin|priority). (ArgumentError) from /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:159:in `validate' from /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:395:in `should=' from /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:394:in `each' from /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:394:in `should=' from /usr/lib/ruby/site_ruby/1.8/puppet/type/yumrepo.rb:94:in `instances' from /usr/lib/ruby/site_ruby/1.8/puppet/metatype/attributes.rb:530:in `eachproperty' from /usr/lib/ruby/site_ruby/1.8/puppet/metatype/attributes.rb:529:in `each' from /usr/lib/ruby/site_ruby/1.8/puppet/metatype/attributes.rb:529:in `eachproperty' ... 9 levels... from /usr/lib/ruby/site_ruby/1.8/cft/puppet.rb:8:in `genstate' from /usr/lib/ruby/site_ruby/1.8/cft/commands.rb:178:in `execute' from /usr/lib/ruby/site_ruby/1.8/cft/commands.rb:148:in `execute' from /usr/sbin/cft:7 # My config is as follow : rhel 5.2 puppet-0.24.5-1.el5 cft-0.2.2-1.el5 ruby-1.8.5-5.el5_1.1 ruby-fam-0.2.0-4.el5 ruby-rpm-1.2.3-4.el5 Thanks for any help Martial From berrange at redhat.com Fri Oct 10 09:45:03 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 10 Oct 2008 10:45:03 +0100 Subject: [et-mgmt-tools] Re: [libvirt] Re: [Fedora-xen] input on F10 virtualization release notes In-Reply-To: <20081008151103.GY9714@edu.joroinen.fi> References: <2131900444.281591223398293181.JavaMail.root@zebra.lib.ucdavis.edu> <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> <20081008151103.GY9714@edu.joroinen.fi> Message-ID: <20081010094503.GA12910@redhat.com> On Wed, Oct 08, 2008 at 06:11:03PM +0300, Pasi K?rkk?inen wrote: > On Tue, Oct 07, 2008 at 09:55:49AM -0700, Dale Bewley wrote: > > I've been working on the virtualization release notes[1] for Fedora 10 > > these past several days, and I'm looking for input from those in the > > know. The advances coming out of the Emerging Technologies projects and > > Fedora in general are very impressive, and I'd like to do them justice. > > > > Very good summary of changes. > > I'm sure there will be a lot questions about (missing) dom0 support, so > maybe add even more information about it. > > Xensource plans to have pv_ops dom0 support ready for Xen 3.4, so maybe add > that information. http://www.xen.org/download/roadmap.html > > I think (at least earlier) the plan was to submit pv_ops dom0 patches for > inclusion in Linux kernel 2.6.28. I'm not sure if that is still the plan. That's premature for Fedora 10 release notes. It'll be shipping Xen 3.3 and 2.6.27. Should be good for Fedora 11 though Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From agx at sigxcpu.org Fri Oct 10 16:15:43 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 10 Oct 2008 18:15:43 +0200 Subject: [et-mgmt-tools] [PATCH] virt-manager: Don't use storage pool with qemu:///session Message-ID: <20081010161543.GA8479@bogon.ms20.nix> Hi, qemu:///session can't write to the storage pool (except for root of course) so defaulting to cwd is probably better. This also makes the distinction between session and system more obvious. (Debian Bug #500260) -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: pool_qemu_session.diff Type: text/x-diff Size: 1020 bytes Desc: not available URL: From berrange at redhat.com Fri Oct 10 17:02:40 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 10 Oct 2008 18:02:40 +0100 Subject: [et-mgmt-tools] [PATCH] virt-manager: Don't use storage pool with qemu:///session In-Reply-To: <20081010161543.GA8479@bogon.ms20.nix> References: <20081010161543.GA8479@bogon.ms20.nix> Message-ID: <20081010170240.GL12910@redhat.com> On Fri, Oct 10, 2008 at 06:15:43PM +0200, Guido G?nther wrote: > Hi, > qemu:///session can't write to the storage pool (except for root of > course) so defaulting to cwd is probably better. This also makes the > distinction between session and system more obvious. (Debian Bug > #500260) The original choice of $HOME was rather a cop-out - I wonder if we should defualt to creating a directory storage pool at $HOME/VirtualMachines if we don't find any pools. No objection to applying this patch in the meantime though. 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 orion at cora.nwra.com Fri Oct 10 21:52:50 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 10 Oct 2008 15:52:50 -0600 Subject: [et-mgmt-tools] "personal" use of virt- tools Message-ID: <48EFCEB2.7050106@cora.nwra.com> I'd like to setup Windows guests (using qemu-kvm) on my users' laptops that they can have access to. Ideally I'd like to provide an icon that would startup the virtual machine and connect to it. Is virt-manager/libvirtd and company the right tools for this job? If so, how would I go about doing this? If not, any other suggestions? Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From dor.laor at qumranet.com Sun Oct 12 08:20:17 2008 From: dor.laor at qumranet.com (Dor Laor) Date: Sun, 12 Oct 2008 10:20:17 +0200 Subject: [et-mgmt-tools] input on F10 virtualization release notes In-Reply-To: <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> References: <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <48F1B341.2060703@il.qumranet.com> Hi, According to the release notes kvm-65 is used. There is a maintenance branch that we keep for kvm. It is called maint/2.6.26. It is based on 2.6.26 for the kvm kernel module and +- kvm-68 for userspace Only bug fixes are applied on these branches so they aught to be relatively stable. So what about rebase fedora-10 kvm over them? Soon we'll branch a new one out of 2.6.28 kernel module and a matching userspace. Regards, Dor Dale Bewley wrote: > I've been working on the virtualization release notes[1] for Fedora 10 > these past several days, and I'm looking for input from those in the > know. The advances coming out of the Emerging Technologies projects and > Fedora in general are very impressive, and I'd like to do them justice. > > I added a lot of content quickly yesterday, and the page structure > is by no means solid, but there is a pending freeze[2] on October > 10th. I'd like to get it into the best and most accurate shape > possible before then. There will be a chance to make updates again > before the F10 release. > > I've attempted to describe the improvements to virtualization-related > packages between the F9 release versions and the anticipated F10 > versions. I've created a table[3] of those versions to help with the > comparison. I'd appreciate it if you'd let me know: > > * if you believe a version bump is pending > * if I've left out any packages or features > * if I included something not noteworthy > * anything else you have to say > > If you have any comments, contributions, or criticisms at all, please > add them to the wiki article/talk page/or email them to me. > > Thanks! And keep up the great work! > > [1] https://fedoraproject.org/wiki/Docs/Beats/Virtualization > [2] http://poelstra.fedorapeople.org/schedules/f-10/f-10-docs-tasks.html > [3] https://fedoraproject.org/wiki/DaleBewley#Virtualization_Release_Notes > > -- > Dale Bewley - Unix Administrator - Shields Library - UC Davis > GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From berrange at redhat.com Sun Oct 12 15:21:59 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 12 Oct 2008 16:21:59 +0100 Subject: [et-mgmt-tools] input on F10 virtualization release notes In-Reply-To: <48F1B341.2060703@il.qumranet.com> References: <486886383.282141223398549554.JavaMail.root@zebra.lib.ucdavis.edu> <48F1B341.2060703@il.qumranet.com> Message-ID: <20081012152159.GA19130@redhat.com> On Sun, Oct 12, 2008 at 10:20:17AM +0200, Dor Laor wrote: > Hi, > > According to the release notes kvm-65 is used. > There is a maintenance branch that we keep for kvm. It is called > maint/2.6.26. It is based on > 2.6.26 for the kvm kernel module and +- kvm-68 for userspace > Only bug fixes are applied on these branches so they aught to be > relatively stable. > So what about rebase fedora-10 kvm over them? Opps, the release notes are incorrect wrt to Fedora 10 then. The latest KVM build is -74 for Fedora 10. The -65 release was what was in Fedora 9 repos. $ koji latest-pkg dist-f10 kvm Build Tag Built by ---------------------------------------- -------------------- ---------------- kvm-74-4.fc10 dist-f10 glommer $ koji latest-pkg dist-f9 kvm Build Tag Built by ---------------------------------------- -------------------- ---------------- kvm-65-1.fc9 dist-f9 katzj $ koji latest-pkg dist-f9-updates kvm Build Tag Built by ---------------------------------------- -------------------- ---------------- kvm-65-9.fc9 dist-f9-updates glommer Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Tue Oct 14 15:09:31 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 14 Oct 2008 11:09:31 -0400 Subject: [et-mgmt-tools] "personal" use of virt- tools In-Reply-To: <48EFCEB2.7050106@cora.nwra.com> References: <48EFCEB2.7050106@cora.nwra.com> Message-ID: <48F4B62B.2000209@redhat.com> Orion Poplawski wrote: > I'd like to setup Windows guests (using qemu-kvm) on my users' laptops > that they can have access to. Ideally I'd like to provide an icon that > would startup the virtual machine and connect to it. Is > virt-manager/libvirtd and company the right tools for this job? If so, > how would I go about doing this? If not, any other suggestions? > > Thanks! > The libvirt stack could certainly help accomplish this. Assuming you install the windows vm using virt-manager or virt-install before hand, a simple script would do the job: UUID=`virsh --connect qemu:///system domuuid vm-name` virsh --connect qemu:///system start $UUID virt-manager --connect qemu:///system \ --show-domain-console=$UUID This will pop up the machine console via virt-manager. You will probably need the latest virt-manager version for this to work correctly. This also has the added benefit of allowing the user to connect/eject cdroms to the guest, or pass a USB thumbdrive through as well. You can also replace virt-manager with virt-viewer, which will provide a graphical console but no CDROM/USB options: virt-viewer --connect qemu:///system $UUID If the user will be starting these VM's as a regular user, they will need extra permissions to run the above commands. On Fedora you can use PolicyKit with libvirt (http://libvirt.org/auth.html#ACL_server_polkit) or a typical sudo type setup would work as well. Thanks, Cole From crobinso at redhat.com Tue Oct 14 18:28:39 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 14 Oct 2008 14:28:39 -0400 Subject: [et-mgmt-tools] virt-manager: exception when connecting to URI with already running VMs In-Reply-To: <20081007131953.GC29854@bogon.ms20.nix> References: <20081002173025.GA29444@bogon.ms20.nix> <48EA4953.6080805@redhat.com> <20081007131953.GC29854@bogon.ms20.nix> Message-ID: <48F4E4D7.3040902@redhat.com> Guido G?nther wrote: > On Mon, Oct 06, 2008 at 01:22:27PM -0400, Cole Robinson wrote: >> Guido G?nther wrote: >>> Hi, >>> when opening virt-manager and doubleclicking on the previously definded >>> qemu:///system connection which has an already running vm I get: >>> >> This should be fixed now: > Thanks! >> http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=270e1697b81a >> >> Let me know if you still have any problems. Thanks for >> the report. > Hmm...the exception is gone now but when I set "Automatically open > consoles" to "for all domains" the gtk-vnc widget just isn't getting > refreshed properly on the spawned consoles. However when I close the > console windows and click on the individual VMs everything works as > expected and the gtk-vnc widget refreshes properly. > -- Guido I haven't been able to reproduce this: - virsh start vmname - run virt-manager - double click qemu:///system connection - vmname console pops up and connects fine Works for guest booting up and when the graphical console is fully started. Are you using a remote connection or anything? - Cole From crobinso at redhat.com Tue Oct 14 18:41:44 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 14 Oct 2008 14:41:44 -0400 Subject: [et-mgmt-tools] [PATCH] virt-manager: Don't use storage pool with qemu:///session In-Reply-To: <20081010161543.GA8479@bogon.ms20.nix> References: <20081010161543.GA8479@bogon.ms20.nix> Message-ID: <48F4E7E8.2070802@redhat.com> Guido G?nther wrote: > Hi, > qemu:///session can't write to the storage pool (except for root of > course) so defaulting to cwd is probably better. This also makes the > distinction between session and system more obvious. (Debian Bug > #500260) > -- Guido > > Thanks, applied: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=5ef55af70018 - Cole From crobinso at redhat.com Tue Oct 14 18:42:20 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 14 Oct 2008 14:42:20 -0400 Subject: [et-mgmt-tools] [patch] virtinst - ImageParser support disk checksum parsing, patch 2 of disk checksum feature In-Reply-To: <48EE6A52.4080707@redhat.com> References: <48EE6A52.4080707@redhat.com> Message-ID: <48F4E80C.9020309@redhat.com> Joey Boggs wrote: > Adds support to parse disk signature values from ImageParser, updates > image.rng schema as well. > Thanks, applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=9f6f1a011174 - Cole From jboggs at redhat.com Wed Oct 15 02:33:28 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 14 Oct 2008 22:33:28 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function Message-ID: <48F55678.6000609@redhat.com> This adds a new function to the virtinst.ImageParser.Disk class to verify disk signatures and runs by default when using virt-image. The next patch will wrap up loose ends in the ImageParser.Disk class to weed out unsupported checksum types. For now, if the checksum type is not matched it skips the check process. -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-imageparser-disk-signature-function-10-14-2212.patch Type: text/x-patch Size: 2701 bytes Desc: not available URL: From sakaia at jp.fujitsu.com Wed Oct 15 04:20:09 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Wed, 15 Oct 2008 13:20:09 +0900 Subject: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH]virt-managercallsmigration API In-Reply-To: <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> References: <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> Message-ID: <200810150420.m9F4KEav031271@fjmscan501.ms.jp.fujitsu.com> Hi, Shigeki When you plan to post "commit ready" patch? Thanks Atsushi SAKAI "S.Sakamoto" wrote: > Hi, > > I make the prototype patch. > > This patch is displayed destination host in a sub-menu, as follows. > > right-click > | > +- Run > Pause > Shutdown > -------- > Migrate ----> host1.example.com > host2.example.com > host3.example.com > > The item that display in a sub-menu is the host > which is a state of ACTIVE or INACTIVE besides the source host. > When the host which is a state of ACTIVE or INACTIVE besides a source host doesn't exist, > "(None)" that is insensitive is displayed, as follows. > > right-click > | > +- Run > Pause > Shutdown > -------- > Migrate ----> (None) > > > domain.py | 6 ++++ > engine.py | 36 ++++++++++++++++++++++++++++ > manager.py | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- > 3 files changed, 117 insertions(+), 3 deletions(-) > > > > Thanks, > Shigeki Sakamoto. > > > Hi, Daniel > > > > Sorry for delaying response. > > > > Thank you for your suggestions. I understand. > > I will make the prototype patch! > > > > Thanks > > Shigeki Sakamoto. > > > > > On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote: > > > > > > > > > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > > > > > development happens, > > > > > > > > > > OK. For this, I tried to hear in et-mgmt-list. > > > > > > > > > > > > > I'm sorry to be pressing, but would you give me a comment on this patch for > > > > going on the next step to migrate from virt-manager ? > > > > I attached screenshots this patch shows. > > > > > > I think rather than having it popup a new window with a list of hosts to > > > migrate to, you could just have a sub-menu where you choose the destination > > > host directly. > > > > > > eg, > > > > > > right-click > > > | > > > +- Run > > > Pause > > > Shutdown > > > -------- > > > Migrate ----> host1.example.com > > > host2.example.com > > > host3.example.com > > > ...etc... > > > > > > When the user selects one of these hosts, it'd popup a confirmation > > > window, and do the neccessary migration checks, and then allow the > > > admin to confirm to start the migration. > > > > > > > > > I sent an e-mail last month with proposals for doing this within libvirt. I put > > > > > > up all of the information I have in the libvirt wiki here: > > > > > > > > > > > > http://wiki.libvirt.org/page/TodoPreMigrationChecks > > > > > > > > > > Thank you for your information. I see above libvirt wiki and I have a few > > > > > idea adding checks within libvirt. These point of view are Guest and Host sanity > > > > > in BASIC CHECKS. How about this points ? > > > > > > > > > > 1)Guest sanity is checking whether already existing or not on the destination. > > > > > Otherwise the uniqueness of the domain(UUID, name) are lost. > > > > > * I think that it is right to check this in libvirt. How do you think this ? > > > > > > Yes, checking for name/uuid uniqueness has to be done inside libvirt by > > > each hypervisor driver according to their own rules. > > > > > > > > 2)Host sanity is checking whether a migration flag is ON at each virtualization. > > > > > > virt-manager will need to check the kind of things on the TodoPreMigrationChecks > > > wiki page. > > > > > > > > > Daniel > > > -- > > > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| > > > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > > > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > > > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| > > > > > > _______________________________________________ > > > et-mgmt-tools mailing list > > > et-mgmt-tools at redhat.com > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From fj0588di at aa.jp.fujitsu.com Wed Oct 15 05:04:42 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Wed, 15 Oct 2008 14:04:42 +0900 Subject: [et-mgmt-tools] [RFC]Re: [libvirt][RFC][PATCH]virt-managercallsmigration API In-Reply-To: <200810150420.m9F4KEav031271@fjmscan501.ms.jp.fujitsu.com> References: <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> <200810150420.m9F4KEav031271@fjmscan501.ms.jp.fujitsu.com> Message-ID: <200810151404.IHC52128.E6K9J09G@aa.jp.fujitsu.com> Hi, As a result of migration test in my environment that applied this patch, there is not a problem. If not comment, please apply this patch. Thanks, Shigeki Sakamoto. > Hi, Shigeki > > When you plan to post "commit ready" patch? > > Thanks > Atsushi SAKAI > > > "S.Sakamoto" wrote: > > > Hi, > > > > I make the prototype patch. > > > > This patch is displayed destination host in a sub-menu, as follows. > > > > right-click > > | > > +- Run > > Pause > > Shutdown > > -------- > > Migrate ----> host1.example.com > > host2.example.com > > host3.example.com > > > > The item that display in a sub-menu is the host > > which is a state of ACTIVE or INACTIVE besides the source host. > > When the host which is a state of ACTIVE or INACTIVE besides a source host doesn't exist, > > "(None)" that is insensitive is displayed, as follows. > > > > right-click > > | > > +- Run > > Pause > > Shutdown > > -------- > > Migrate ----> (None) > > > > > > domain.py | 6 ++++ > > engine.py | 36 ++++++++++++++++++++++++++++ > > manager.py | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- > > 3 files changed, 117 insertions(+), 3 deletions(-) > > > > > > > > Thanks, > > Shigeki Sakamoto. > > > > > Hi, Daniel > > > > > > Sorry for delaying response. > > > > > > Thank you for your suggestions. I understand. > > > I will make the prototype patch! > > > > > > Thanks > > > Shigeki Sakamoto. > > > > > > > On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote: > > > > > > > > > > > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > > > > > > development happens, > > > > > > > > > > > > OK. For this, I tried to hear in et-mgmt-list. > > > > > > > > > > > > > > > > I'm sorry to be pressing, but would you give me a comment on this patch for > > > > > going on the next step to migrate from virt-manager ? > > > > > I attached screenshots this patch shows. > > > > > > > > I think rather than having it popup a new window with a list of hosts to > > > > migrate to, you could just have a sub-menu where you choose the destination > > > > host directly. > > > > > > > > eg, > > > > > > > > right-click > > > > | > > > > +- Run > > > > Pause > > > > Shutdown > > > > -------- > > > > Migrate ----> host1.example.com > > > > host2.example.com > > > > host3.example.com > > > > ...etc... > > > > > > > > When the user selects one of these hosts, it'd popup a confirmation > > > > window, and do the neccessary migration checks, and then allow the > > > > admin to confirm to start the migration. > > > > > > > > > > > I sent an e-mail last month with proposals for doing this within libvirt. I put > > > > > > > up all of the information I have in the libvirt wiki here: > > > > > > > > > > > > > > http://wiki.libvirt.org/page/TodoPreMigrationChecks > > > > > > > > > > > > Thank you for your information. I see above libvirt wiki and I have a few > > > > > > idea adding checks within libvirt. These point of view are Guest and Host sanity > > > > > > in BASIC CHECKS. How about this points ? > > > > > > > > > > > > 1)Guest sanity is checking whether already existing or not on the destination. > > > > > > Otherwise the uniqueness of the domain(UUID, name) are lost. > > > > > > * I think that it is right to check this in libvirt. How do you think this ? > > > > > > > > Yes, checking for name/uuid uniqueness has to be done inside libvirt by > > > > each hypervisor driver according to their own rules. > > > > > > > > > > 2)Host sanity is checking whether a migration flag is ON at each virtualization. > > > > > > > > virt-manager will need to check the kind of things on the TodoPreMigrationChecks > > > > wiki page. > > > > > > > > > > > > Daniel > > > > -- > > > > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| > > > > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > > > > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > > > > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| > > > > > > > > _______________________________________________ > > > > et-mgmt-tools mailing list > > > > et-mgmt-tools at redhat.com > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > _______________________________________________ > > > et-mgmt-tools mailing list > > > et-mgmt-tools at redhat.com > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- A non-text attachment was scrubbed... Name: migrate_submenu.patch Type: application/octet-stream Size: 10942 bytes Desc: not available URL: From crobinso at redhat.com Wed Oct 15 19:11:22 2008 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 15 Oct 2008 15:11:22 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F55678.6000609@redhat.com> References: <48F55678.6000609@redhat.com> Message-ID: <48F6405A.4010505@redhat.com> Joey Boggs wrote: > This adds a new function to the virtinst.ImageParser.Disk class to > verify disk signatures and runs by default when using virt-image. The > next patch will wrap up loose ends in the ImageParser.Disk class to weed > out unsupported checksum types. For now, if the checksum type is not > matched it skips the check process. > > > diff -r db5d9aeca590 virt-image > --- a/virt-image Fri Oct 10 10:32:50 2008 -0400 > +++ b/virt-image Tue Oct 14 22:25:21 2008 -0400 > @@ -197,6 +197,8 @@ > > get_graphics(image.domain, options.vnc, options.vncport, > options.nographics, options.sdl, options.keymap, guest) > + checksum = virtinst.ImageParser.Disk > + checksum.check_disk_signature(image) > I don't really like this interface of having a method of the Disk class that receives an Image object and pulls disks from that. Doesn't really fit the whole class dichotomy. The way to do it is to have the Disk method calculate the checksum for that particular disk. Then you can add a convenience method to the Image class that will calculate the checksums for every Disk object associated with that Image. > if installer.is_hvm(): > if options.noacpi: > diff -r db5d9aeca590 virtinst/ImageParser.py > --- a/virtinst/ImageParser.py Fri Oct 10 10:32:50 2008 -0400 > +++ b/virtinst/ImageParser.py Tue Oct 14 22:25:21 2008 -0400 > @@ -23,6 +23,8 @@ > import libxml2 > import CapabilitiesParser > from virtinst import _virtinst as _ > +import logging > +import urlgrabber.progress as progress > > class ParserException(Exception): > def __init__(self, msg): > @@ -224,6 +226,49 @@ > _("The format for disk %s must be one of %s") % > (self.file, ",".join(formats))) > > + def check_disk_signature(self,image): > + try: > + import hashlib > + has_hashlib = True > + except: > + import sha > + has_hashlib = False > + > + for disk in image.storage.values(): > + meter_ct = 0 > + m = None > + disk_size = os.path.getsize(disk.id) Disk.id doesn't seem to be a required field, and doesn't necessarily point to a path. I would say use disk.file throughout. > + meter = progress.TextMeter() > + meter.start(size=disk_size, text=("Checking disk signature for %s" % disk.id)) > + Make that text=_("... to translate it. > + if has_hashlib is True: > + if disk.csum.has_key("sha256"): > + csumvalue = disk.csum["sha256"] > + m = hashlib.sha256() > + elif disk.csum.has_key("sha1"): > + csumvalue = disk.csum["sha1"] > + m = hashlib.sha1() > + else: > + if disk.csum.has_key("sha1"): > + csumvalue = disk.csum["sha1"] > + m = sha.new() > + if m: At this point, I'd just do if not m: return to avoid all the indentation. > + f = open(disk.id,"r") > + while 1: > + chunk = f.read(65536) > + meter.update(meter_ct) > + meter_ct = meter_ct + 65536 > + if not chunk: > + break Pop this 'if not' right after the read() so we don't update the meter if nothing was read. > + m.update(chunk) > + checksum = m.hexdigest() > + if checksum != csumvalue: > + logging.debug(_("Disk signature for %s does not match Expected: %s Received: %s" > + % (disk.id,csumvalue,checksum))) > + raise ValueError (_("Disk signature for %s does not match" % disk.id)) > + > + > + Please be consistent with the current white space and just use 1 newline here. > def validate(cond, msg): > if not cond: > raise ParserException(msg) From jboggs at redhat.com Wed Oct 15 23:03:48 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 15 Oct 2008 19:03:48 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F6405A.4010505@redhat.com> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> Message-ID: <48F676D4.3060202@redhat.com> Cole Robinson wrote: > Joey Boggs wrote: > >> This adds a new function to the virtinst.ImageParser.Disk class to >> verify disk signatures and runs by default when using virt-image. The >> next patch will wrap up loose ends in the ImageParser.Disk class to weed >> out unsupported checksum types. For now, if the checksum type is not >> matched it skips the check process. >> >> >> > > > >> diff -r db5d9aeca590 virt-image >> --- a/virt-image Fri Oct 10 10:32:50 2008 -0400 >> +++ b/virt-image Tue Oct 14 22:25:21 2008 -0400 >> @@ -197,6 +197,8 @@ >> >> get_graphics(image.domain, options.vnc, options.vncport, >> options.nographics, options.sdl, options.keymap, guest) >> + checksum = virtinst.ImageParser.Disk >> + checksum.check_disk_signature(image) >> >> > > I don't really like this interface of having a method > of the Disk class that receives an Image object and > pulls disks from that. Doesn't really fit the whole > class dichotomy. > > The way to do it is to have the Disk method calculate > the checksum for that particular disk. Then you can > add a convenience method to the Image class that will > calculate the checksums for every Disk object associated > with that Image. > > Made all the corrections. I understand calculating for just one disk, which will be more reusable for other code than just this case, but why create separate method to check all the disks as well? >> if installer.is_hvm(): >> if options.noacpi: >> diff -r db5d9aeca590 virtinst/ImageParser.py >> --- a/virtinst/ImageParser.py Fri Oct 10 10:32:50 2008 -0400 >> +++ b/virtinst/ImageParser.py Tue Oct 14 22:25:21 2008 -0400 >> @@ -23,6 +23,8 @@ >> import libxml2 >> import CapabilitiesParser >> from virtinst import _virtinst as _ >> +import logging >> +import urlgrabber.progress as progress >> >> class ParserException(Exception): >> def __init__(self, msg): >> @@ -224,6 +226,49 @@ >> _("The format for disk %s must be one of %s") % >> (self.file, ",".join(formats))) >> >> + def check_disk_signature(self,image): >> + try: >> + import hashlib >> + has_hashlib = True >> + except: >> + import sha >> + has_hashlib = False >> + >> + for disk in image.storage.values(): >> + meter_ct = 0 >> + m = None >> + disk_size = os.path.getsize(disk.id) >> > > Disk.id doesn't seem to be a required field, and > doesn't necessarily point to a path. I would say > use disk.file throughout. > > >> + meter = progress.TextMeter() >> + meter.start(size=disk_size, text=("Checking disk signature for %s" % disk.id)) >> + >> > > Make that text=_("... to translate it. > > >> + if has_hashlib is True: >> + if disk.csum.has_key("sha256"): >> + csumvalue = disk.csum["sha256"] >> + m = hashlib.sha256() >> + elif disk.csum.has_key("sha1"): >> + csumvalue = disk.csum["sha1"] >> + m = hashlib.sha1() >> + else: >> + if disk.csum.has_key("sha1"): >> + csumvalue = disk.csum["sha1"] >> + m = sha.new() >> + if m: >> > > At this point, I'd just do > > if not m: > return > > to avoid all the indentation. > > >> + f = open(disk.id,"r") >> + while 1: >> + chunk = f.read(65536) >> + meter.update(meter_ct) >> + meter_ct = meter_ct + 65536 >> + if not chunk: >> + break >> > > Pop this 'if not' right after the read() so we > don't update the meter if nothing was read. > > >> + m.update(chunk) >> + checksum = m.hexdigest() >> + if checksum != csumvalue: >> + logging.debug(_("Disk signature for %s does not match Expected: %s Received: %s" >> + % (disk.id,csumvalue,checksum))) >> + raise ValueError (_("Disk signature for %s does not match" % disk.id)) >> + >> + >> + >> > > Please be consistent with the current white space > and just use 1 newline here. > > >> def validate(cond, msg): >> if not cond: >> raise ParserException(msg) >> > > From crobinso at redhat.com Thu Oct 16 13:21:12 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 16 Oct 2008 09:21:12 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F676D4.3060202@redhat.com> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> Message-ID: <48F73FC8.2010605@redhat.com> Joey Boggs wrote: > Cole Robinson wrote: >> Joey Boggs wrote: >> >>> This adds a new function to the virtinst.ImageParser.Disk class to >>> verify disk signatures and runs by default when using virt-image. >>> The next patch will wrap up loose ends in the ImageParser.Disk class >>> to weed out unsupported checksum types. For now, if the checksum >>> type is not matched it skips the check process. >>> >>> >>> >> >> >> >>> diff -r db5d9aeca590 virt-image >>> --- a/virt-image Fri Oct 10 10:32:50 2008 -0400 >>> +++ b/virt-image Tue Oct 14 22:25:21 2008 -0400 >>> @@ -197,6 +197,8 @@ >>> >>> get_graphics(image.domain, options.vnc, options.vncport, >>> options.nographics, options.sdl, options.keymap, >>> guest) >>> + checksum = virtinst.ImageParser.Disk >>> + checksum.check_disk_signature(image) >>> >>> >> >> I don't really like this interface of having a method >> of the Disk class that receives an Image object and >> pulls disks from that. Doesn't really fit the whole >> class dichotomy. >> >> The way to do it is to have the Disk method calculate >> the checksum for that particular disk. Then you can >> add a convenience method to the Image class that will >> calculate the checksums for every Disk object associated >> with that Image. >> >> > Made all the corrections. I understand calculating for just one disk, > which will be more reusable for other code than just this case, but > why create separate method to check all the disks as well? > It's certainly not required, it would just be a convenience function. I'm not attached to the idea if you want to skip it. Not sure if you intended to or not, but the patch wasn't attached to this email. Thanks, Cole From jboggs at redhat.com Thu Oct 16 13:44:04 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 16 Oct 2008 09:44:04 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F73FC8.2010605@redhat.com> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> <48F73FC8.2010605@redhat.com> Message-ID: <48F74524.9090008@redhat.com> Better integrated into the Disk class and runs when a Disk object is created Cole Robinson wrote: > Joey Boggs wrote: > >> Cole Robinson wrote: >> >>> Joey Boggs wrote: >>> >>> >>>> This adds a new function to the virtinst.ImageParser.Disk class to >>>> verify disk signatures and runs by default when using virt-image. >>>> The next patch will wrap up loose ends in the ImageParser.Disk class >>>> to weed out unsupported checksum types. For now, if the checksum >>>> type is not matched it skips the check process. >>>> >>>> >>>> >>>> >>> >>> >>>> diff -r db5d9aeca590 virt-image >>>> --- a/virt-image Fri Oct 10 10:32:50 2008 -0400 >>>> +++ b/virt-image Tue Oct 14 22:25:21 2008 -0400 >>>> @@ -197,6 +197,8 @@ >>>> >>>> get_graphics(image.domain, options.vnc, options.vncport, >>>> options.nographics, options.sdl, options.keymap, >>>> guest) >>>> + checksum = virtinst.ImageParser.Disk >>>> + checksum.check_disk_signature(image) >>>> >>>> >>>> >>> I don't really like this interface of having a method >>> of the Disk class that receives an Image object and >>> pulls disks from that. Doesn't really fit the whole >>> class dichotomy. >>> >>> The way to do it is to have the Disk method calculate >>> the checksum for that particular disk. Then you can >>> add a convenience method to the Image class that will >>> calculate the checksums for every Disk object associated >>> with that Image. >>> >>> >>> >> Made all the corrections. I understand calculating for just one disk, >> which will be more reusable for other code than just this case, but >> why create separate method to check all the disks as well? >> >> > > It's certainly not required, it would just be a convenience > function. I'm not attached to the idea if you want to skip > it. > > Not sure if you intended to or not, but the patch wasn't > attached to this email. > > Thanks, > Cole > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-imageparser-disk-signature-function-10-16-0941.patch Type: text/x-patch Size: 2282 bytes Desc: not available URL: From sakaia at jp.fujitsu.com Thu Oct 16 13:43:27 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Thu, 16 Oct 2008 22:43:27 +0900 Subject: [et-mgmt-tools] [RFC]Re:[libvirt][RFC][PATCH]virt-managercallsmigration API In-Reply-To: <200810151404.IHC52128.E6K9J09G@aa.jp.fujitsu.com> References: <200810151404.IHC52128.E6K9J09G@aa.jp.fujitsu.com> Message-ID: <200810161343.m9GDhWi9027624@fjmscan502.ms.jp.fujitsu.com> Hi, Dan and Cole I know you are very busy. But would you give me a comment on this patch? Thanks Atsushi SAKAI "S.Sakamoto" wrote: > Hi, > > As a result of migration test in my environment that applied this patch, > there is not a problem. > > If not comment, please apply this patch. > > > Thanks, > Shigeki Sakamoto. > > > Hi, Shigeki > > > > When you plan to post "commit ready" patch? > > > > Thanks > > Atsushi SAKAI > > > > > > "S.Sakamoto" wrote: > > > > > Hi, > > > > > > I make the prototype patch. > > > > > > This patch is displayed destination host in a sub-menu, as follows. > > > > > > right-click > > > | > > > +- Run > > > Pause > > > Shutdown > > > -------- > > > Migrate ----> host1.example.com > > > host2.example.com > > > host3.example.com > > > > > > The item that display in a sub-menu is the host > > > which is a state of ACTIVE or INACTIVE besides the source host. > > > When the host which is a state of ACTIVE or INACTIVE besides a source host doesn't exist, > > > "(None)" that is insensitive is displayed, as follows. > > > > > > right-click > > > | > > > +- Run > > > Pause > > > Shutdown > > > -------- > > > Migrate ----> (None) > > > > > > > > > domain.py | 6 ++++ > > > engine.py | 36 ++++++++++++++++++++++++++++ > > > manager.py | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- > > > 3 files changed, 117 insertions(+), 3 deletions(-) > > > > > > > > > > > > Thanks, > > > Shigeki Sakamoto. > > > > > > > Hi, Daniel > > > > > > > > Sorry for delaying response. > > > > > > > > Thank you for your suggestions. I understand. > > > > I will make the prototype patch! > > > > > > > > Thanks > > > > Shigeki Sakamoto. > > > > > > > > > On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote: > > > > > > > > > > > > > > > You probably want to send this to et-mgmt-list, which is where virt-manager > > > > > > > > development happens, > > > > > > > > > > > > > > OK. For this, I tried to hear in et-mgmt-list. > > > > > > > > > > > > > > > > > > > I'm sorry to be pressing, but would you give me a comment on this patch for > > > > > > going on the next step to migrate from virt-manager ? > > > > > > I attached screenshots this patch shows. > > > > > > > > > > I think rather than having it popup a new window with a list of hosts to > > > > > migrate to, you could just have a sub-menu where you choose the destination > > > > > host directly. > > > > > > > > > > eg, > > > > > > > > > > right-click > > > > > | > > > > > +- Run > > > > > Pause > > > > > Shutdown > > > > > -------- > > > > > Migrate ----> host1.example.com > > > > > host2.example.com > > > > > host3.example.com > > > > > ...etc... > > > > > > > > > > When the user selects one of these hosts, it'd popup a confirmation > > > > > window, and do the neccessary migration checks, and then allow the > > > > > admin to confirm to start the migration. > > > > > > > > > > > > > I sent an e-mail last month with proposals for doing this within libvirt. I put > > > > > > > > up all of the information I have in the libvirt wiki here: > > > > > > > > > > > > > > > > http://wiki.libvirt.org/page/TodoPreMigrationChecks > > > > > > > > > > > > > > Thank you for your information. I see above libvirt wiki and I have a few > > > > > > > idea adding checks within libvirt. These point of view are Guest and Host sanity > > > > > > > in BASIC CHECKS. How about this points ? > > > > > > > > > > > > > > 1)Guest sanity is checking whether already existing or not on the destination. > > > > > > > Otherwise the uniqueness of the domain(UUID, name) are lost. > > > > > > > * I think that it is right to check this in libvirt. How do you think this ? > > > > > > > > > > Yes, checking for name/uuid uniqueness has to be done inside libvirt by > > > > > each hypervisor driver according to their own rules. > > > > > > > > > > > > 2)Host sanity is checking whether a migration flag is ON at each virtualization. > > > > > > > > > > virt-manager will need to check the kind of things on the TodoPreMigrationChecks > > > > > wiki page. > > > > > > > > > > > > > > > Daniel > > > > > -- > > > > > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| > > > > > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > > > > > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > > > > > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| > > > > > > > > > > _______________________________________________ > > > > > et-mgmt-tools mailing list > > > > > et-mgmt-tools at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > > _______________________________________________ > > > > et-mgmt-tools mailing list > > > > et-mgmt-tools at redhat.com > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From crobinso at redhat.com Thu Oct 16 14:17:11 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 16 Oct 2008 10:17:11 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F74524.9090008@redhat.com> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> <48F73FC8.2010605@redhat.com> <48F74524.9090008@redhat.com> Message-ID: <48F74CE7.10208@redhat.com> Joey Boggs wrote: > > Better integrated into the Disk class and runs when a Disk object is > created > > diff -r db5d9aeca590 virtinst/ImageParser.py > --- a/virtinst/ImageParser.py Fri Oct 10 10:32:50 2008 -0400 > +++ b/virtinst/ImageParser.py Thu Oct 16 09:41:22 2008 -0400 > @@ -23,6 +23,8 @@ > import libxml2 > import CapabilitiesParser > from virtinst import _virtinst as _ > +import logging > +import urlgrabber.progress as progress > > class ParserException(Exception): > def __init__(self, msg): > @@ -207,6 +209,7 @@ > self.csum = {} > if not node is None: > self.parseXML(node) > + self.check_disk_signature() > Do we really want this at init time? That doesn't provide the API user any way to prevent the csum checks from running. We should really make this optional from an API standpoint, but still make it the default in virt-image. Just dropping the above should solve that. That's really my only gripe, so I can fix it when I commit if it's okay with you. Thanks, Cole From jboggs at redhat.com Thu Oct 16 14:20:49 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 16 Oct 2008 10:20:49 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F74CE7.10208@redhat.com> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> <48F73FC8.2010605@redhat.com> <48F74524.9090008@redhat.com> <48F74CE7.10208@redhat.com> Message-ID: <48F74DC1.80504@redhat.com> Cole, That's fine I'll take a look after it's commited and write that down for future reference. Cole Robinson wrote: > Joey Boggs wrote: > >> Better integrated into the Disk class and runs when a Disk object is >> created >> >> diff -r db5d9aeca590 virtinst/ImageParser.py >> --- a/virtinst/ImageParser.py Fri Oct 10 10:32:50 2008 -0400 >> +++ b/virtinst/ImageParser.py Thu Oct 16 09:41:22 2008 -0400 >> @@ -23,6 +23,8 @@ >> import libxml2 >> import CapabilitiesParser >> from virtinst import _virtinst as _ >> +import logging >> +import urlgrabber.progress as progress >> >> class ParserException(Exception): >> def __init__(self, msg): >> @@ -207,6 +209,7 @@ >> self.csum = {} >> if not node is None: >> self.parseXML(node) >> + self.check_disk_signature() >> >> > > Do we really want this at init time? That doesn't > provide the API user any way to prevent the csum > checks from running. We should really make this > optional from an API standpoint, but still make > it the default in virt-image. Just dropping the > above should solve that. > > That's really my only gripe, so I can fix it when > I commit if it's okay with you. > > Thanks, > Cole > From crobinso at redhat.com Thu Oct 16 15:05:00 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 16 Oct 2008 11:05:00 -0400 Subject: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH] virt-managercallsmigration API In-Reply-To: <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> References: <48C4EF66.9070400@redhat.com> <200809112004.FEC57380.J0G9K96E@aa.jp.fujitsu.com> <200809191843.GCG69223.96J09KGE@aa.jp.fujitsu.com> <20080919100727.GM18194@redhat.com> <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> Message-ID: <48F7581C.4040203@redhat.com> S.Sakamoto wrote: > Hi, > > I make the prototype patch. > > This patch is displayed destination host in a sub-menu, as follows. > > right-click > | > +- Run > Pause > Shutdown > -------- > Migrate ----> host1.example.com > host2.example.com > host3.example.com > > The item that display in a sub-menu is the host > which is a state of ACTIVE or INACTIVE besides the source host. > When the host which is a state of ACTIVE or INACTIVE besides a source host doesn't exist, > "(None)" that is insensitive is displayed, as follows. > > right-click > | > +- Run > Pause > Shutdown > -------- > Migrate ----> (None) > > > domain.py | 6 ++++ > engine.py | 36 ++++++++++++++++++++++++++++ > manager.py | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- > 3 files changed, 117 insertions(+), 3 deletions(-) > > > > Thanks, > Shigeki Sakamoto. > Hi, patch generally looks good. One issue though: how does this handle connections using different hypervisors? Say a local xen and a remote qemu. Obviously we shouldn't be able to migrate between the two but I think this code would allow it. Maybe have the connection list look something like: migrate -> hostname1 (qemu) -> hostname2 (xen) If the hypervisors don't match the entry would be disabled. Also, having the migrate option only available as a right click menu item doesn't seem too transparent. Maybe also list it as an option under the 'Virtual Machine' menu in the individual VM view. If you go this route, you'll want to offload most of the logic to engine.py like is done for shutdown, pause, etc. > diff -r 270e1697b81a src/virtManager/domain.py > --- a/src/virtManager/domain.py Mon Oct 06 13:21:06 2008 -0400 > +++ b/src/virtManager/domain.py Wed Oct 08 16:38:05 2008 +0900 > @@ -972,4 +972,10 @@ class vmmDomain(gobject.GObject): > # Invalidate cached xml > self.xml = None > > + def migrate(self, dictcon): > + flags = 0 > + if self.lastStatus == libvirt.VIR_DOMAIN_RUNNING: > + flags = libvirt.VIR_MIGRATE_LIVE > + self.vm.migrate(self.connection.vmm, flags, None, > dictcon.get_short_hostname(), 0) > + > gobject.type_register(vmmDomain) > diff -r 270e1697b81a src/virtManager/engine.py > --- a/src/virtManager/engine.py Mon Oct 06 13:21:06 2008 -0400 > +++ b/src/virtManager/engine.py Wed Oct 08 16:38:05 2008 +0900 > @@ -202,6 +202,8 @@ class vmmEngine(gobject.GObject): > self.shutdown_domain(src, uri, uuid) > def _do_reboot_domain(self, src, uri, uuid): > self.reboot_domain(src, uri, uuid) > + def _do_migrate_domain(self, src, uri, uuid, desturi): > + self.migrate_domain(uri, uuid, desturi) > def _do_exit_app(self, src): > self.exit_app() > > @@ -296,6 +298,7 @@ class vmmEngine(gobject.GObject): > self.windowManager.connect("action-shutdown-domain", > self._do_shutdown_domain) > self.windowManager.connect("action-reboot-domain", > self._do_reboot_domain) > self.windowManager.connect("action-destroy-domain", > self._do_destroy_domain) > + self.windowManager.connect("action-migrate-domain", > self._do_migrate_domain) > self.windowManager.connect("action-show-console", > self._do_show_console) > self.windowManager.connect("action-show-details", > self._do_show_details) > self.windowManager.connect("action-show-preferences", > self._do_show_preferences) > @@ -528,6 +531,39 @@ class vmmEngine(gobject.GObject): > else: > logging.warning("Reboot requested, but machine is already > shutting down / shutoff") > > + def migrate_domain(self, uri, uuid, desturi): > + conn = self.get_connection(uri, False) > + vm = conn.get_vm(uuid) > + destconn = self.get_connection(desturi, False) > + migrate_progress = None > + try: > + # show progress dialog > + migrate_progress = > self.get_migrate_progress(vm.get_name(), conn.get_short_hostname(), > destconn.get_short_hostname()) > + migrate_progress.show() > + while gtk.events_pending(): > + gtk.main_iteration() > + # call virDomainMigrate > + vm.migrate(destconn) > + # close progress dialog > + migrate_progress.destroy() > + except Exception, e: > + migrate_progress.destroy() > + self.err.show_err(_("Error migrating domain: %s") % str(e), > + "".join(traceback.format_exc())) > + > + self.windowManager.conn_refresh_resources(conn) > + self.windowManager.conn_refresh_resources(destconn) > + > + def get_migrate_progress(self, vmname, hostname, desthostname): > + migrate_progress = None > + migrate_progress = gtk.MessageDialog(None, \ > + > gtk.DIALOG_DESTROY_WITH_PARENT, \ > + gtk.MESSAGE_INFO, \ > + gtk.BUTTONS_NONE, \ > + _("%s is migrating from > %s to %s." % \ > + (vmname, hostname, > desthostname))) > + migrate_progress.set_title(" ") > + return migrate_progress > > > gobject.type_register(vmmEngine) > diff -r 270e1697b81a src/virtManager/manager.py > --- a/src/virtManager/manager.py Mon Oct 06 13:21:06 2008 -0400 > +++ b/src/virtManager/manager.py Wed Oct 08 16:38:05 2008 +0900 > @@ -101,6 +101,8 @@ class vmmManager(gobject.GObject): > gobject.TYPE_NONE, [str]), > "action-show-help": (gobject.SIGNAL_RUN_FIRST, > gobject.TYPE_NONE, [str]), > + "action-migrate-domain": (gobject.SIGNAL_RUN_FIRST, > + gobject.TYPE_NONE, (str,str,str)), > "action-exit-app": (gobject.SIGNAL_RUN_FIRST, > gobject.TYPE_NONE, []),} > > @@ -154,6 +156,8 @@ class vmmManager(gobject.GObject): > self.vmmenushutdown = gtk.Menu() > self.vmmenu_items = {} > self.vmmenushutdown_items = {} > + self.vmmenumigrate = gtk.Menu() > + self.vmmenumigrate_items = {} > > self.vmmenu_items["run"] = gtk.ImageMenuItem("_Run") > self.vmmenu_items["run"].set_image(self.vmmenu_icons["run"]) > @@ -198,9 +202,23 @@ class vmmManager(gobject.GObject): > > self.vmmenushutdown_items["forcepoweroff"].connect("activate", > self.destroy_vm) > > self.vmmenushutdown.add(self.vmmenushutdown_items["forcepoweroff"]) > > - self.vmmenu_items["hsep"] = gtk.SeparatorMenuItem() > - self.vmmenu_items["hsep"].show(); > - self.vmmenu.add(self.vmmenu_items["hsep"]) > + self.vmmenu_items["hsep1"] = gtk.SeparatorMenuItem() > + self.vmmenu_items["hsep1"].show(); > + self.vmmenu.add(self.vmmenu_items["hsep1"]) > + > + self.vmmenu_items["migrate"] = gtk.ImageMenuItem("_Migrate") > + self.vmmenu_items["migrate"].set_submenu(self.vmmenumigrate) > + self.vmmenu_items["migrate"].show() > + self.vmmenu.add(self.vmmenu_items["migrate"]) > + > + self.vmmenumigrate_items["(None)"] = > gtk.ImageMenuItem(_("(None)")) > + self.vmmenumigrate_items["(None)"].show() > + self.vmmenumigrate_items["(None)"].set_sensitive(False) > + self.vmmenumigrate.add(self.vmmenumigrate_items["(None)"]) > + > + self.vmmenu_items["hsep2"] = gtk.SeparatorMenuItem() > + self.vmmenu_items["hsep2"].show(); > + self.vmmenu.add(self.vmmenu_items["hsep2"]) > > self.vmmenu_items["open"] = gtk.ImageMenuItem(gtk.STOCK_OPEN) > self.vmmenu_items["open"].connect("activate", > self.open_vm_console) > @@ -698,6 +716,7 @@ class vmmManager(gobject.GObject): > self.vmmenu_items["resume"].hide() > self.vmmenu_items["resume"].set_sensitive(False) > self.vmmenu_items["shutdown"].set_sensitive(False) > + self.vmmenu_items["migrate"].set_sensitive(False) > else: > if vm.status() == libvirt.VIR_DOMAIN_SHUTOFF: > self.vmmenu_items["run"].set_sensitive(True) > @@ -706,6 +725,8 @@ class vmmManager(gobject.GObject): > self.vmmenu_items["resume"].hide() > self.vmmenu_items["resume"].set_sensitive(False) > > self.vmmenu_items["shutdown"].set_sensitive(False) > + self.vmmenu_items["migrate"].set_sensitive(True) > + self.set_migrate_submenu() > elif vm.status() == libvirt.VIR_DOMAIN_RUNNING: > self.vmmenu_items["run"].set_sensitive(False) > self.vmmenu_items["pause"].set_sensitive(True) > @@ -713,6 +734,8 @@ class vmmManager(gobject.GObject): > self.vmmenu_items["resume"].hide() > self.vmmenu_items["resume"].set_sensitive(False) > self.vmmenu_items["shutdown"].set_sensitive(True) > + self.vmmenu_items["migrate"].set_sensitive(True) > + self.set_migrate_submenu() > elif vm.status() == libvirt.VIR_DOMAIN_PAUSED: > self.vmmenu_items["run"].set_sensitive(False) > self.vmmenu_items["pause"].hide() > @@ -720,6 +743,8 @@ class vmmManager(gobject.GObject): > self.vmmenu_items["resume"].show() > self.vmmenu_items["resume"].set_sensitive(True) > self.vmmenu_items["shutdown"].set_sensitive(True) > + self.vmmenu_items["migrate"].set_sensitive(True) > + self.set_migrate_submenu() > self.vmmenu.popup(None, None, None, 0, event.time) > return False > else: > @@ -1007,6 +1032,53 @@ class vmmManager(gobject.GObject): > if vm is not None: > self.emit("action-resume-domain", > vm.get_connection().get_uri(), vm.get_uuid()) > > + def migrate(self, ignore): > + vm = self.current_vm() > + # get selected submenu(destination hostname) > + hostname = > self.vmmenumigrate.get_active().get_image().get_stock()[0] > + for key in self.engine.connections.keys(): > + if self.engine.get_connection(key).get_hostname() == > hostname: > + host_uri = key > + break > + if vm is not None: > + result = self.err.yes_no(_("%s is migrated from %s to %s, > are you sure?") % \ Change "is migrated from" to "will be migrated from" The rest looks fine. Thanks, Cole From agx at sigxcpu.org Thu Oct 16 15:38:57 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 16 Oct 2008 17:38:57 +0200 Subject: [et-mgmt-tools] libvirt munin plugins Message-ID: <20081016153857.GA3820@bogon.ms20.nix> Hi, just in case somebody monitors VMs with munin[1]. I've put to simple plugins for net and block I/O monitoring here: http://honk.sigxcpu.org/projects/libvirt/monitor/ Cheers, -- Guido [1]: http://munin.projects.linpro.no/ From berrange at redhat.com Thu Oct 16 15:41:22 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 16 Oct 2008 16:41:22 +0100 Subject: [et-mgmt-tools] libvirt munin plugins In-Reply-To: <20081016153857.GA3820@bogon.ms20.nix> References: <20081016153857.GA3820@bogon.ms20.nix> Message-ID: <20081016154122.GF1821@redhat.com> On Thu, Oct 16, 2008 at 05:38:57PM +0200, Guido G?nther wrote: > Hi, > just in case somebody monitors VMs with munin[1]. I've put to simple > plugins for net and block I/O monitoring here: > http://honk.sigxcpu.org/projects/libvirt/monitor/ Nice idea ! Rich Jones did a similar thing for collectd, and Nagios. We should link to all 3 of these plugins from the libvirt applications page on the website http://libvirt.org/apps.html Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From crobinso at redhat.com Thu Oct 16 15:49:39 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 16 Oct 2008 11:49:39 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F74DC1.80504@redhat.com> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> <48F73FC8.2010605@redhat.com> <48F74524.9090008@redhat.com> <48F74CE7.10208@redhat.com> <48F74DC1.80504@redhat.com> Message-ID: <48F76293.3020502@redhat.com> Joey Boggs wrote: > Cole, > > That's fine I'll take a look after it's commited and write that down > for future reference. > Thanks, committed now: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=9f45a36d8242 - Cole From veillard at redhat.com Thu Oct 16 16:34:59 2008 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 16 Oct 2008 18:34:59 +0200 Subject: [et-mgmt-tools] libvirt munin plugins In-Reply-To: <20081016154122.GF1821@redhat.com> References: <20081016153857.GA3820@bogon.ms20.nix> <20081016154122.GF1821@redhat.com> Message-ID: <20081016163459.GX1978@redhat.com> On Thu, Oct 16, 2008 at 04:41:22PM +0100, Daniel P. Berrange wrote: > On Thu, Oct 16, 2008 at 05:38:57PM +0200, Guido G?nther wrote: > > Hi, > > just in case somebody monitors VMs with munin[1]. I've put to simple > > plugins for net and block I/O monitoring here: > > http://honk.sigxcpu.org/projects/libvirt/monitor/ > > Nice idea ! Rich Jones did a similar thing for collectd, and Nagios. > > We should link to all 3 of these plugins from the libvirt applications > page on the website http://libvirt.org/apps.html Makes sense ! Attached patch adds the 3 plugins in a new section of the application page, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -------------- next part -------------- Index: docs/apps.html.in =================================================================== RCS file: /data/cvs/libxen/docs/apps.html.in,v retrieving revision 1.2 diff -u -p -r1.2 apps.html.in --- docs/apps.html.in 15 May 2008 06:12:32 -0000 1.2 +++ docs/apps.html.in 16 Oct 2008 16:33:40 -0000 @@ -103,6 +103,31 @@ +

Monitoring plugins

+
+
for munin
+
+ The two plugins provided by Guido G?nther allows to monitor network and + block I/O with Munin. +
+
for collectd
+
+ The libvirt-plugin is part of collectd + and gather statistics about virtualized guests on a system. This + way, you can collect CPU, network interface and block device usage + for each guest without installing collectd on the guest systems. + or a full description of available please refer to the libvirt section + in the collectd.conf(5) manual page. +
+
nagios-virt
+
+ Nagios-virt is a configuration tool for adding monitoring of your + virtualised domains to Nagios. + You can use this tool to either set up a new Nagios installation for + your Xen or QEMU/KVM guests, or to integrate with your existing Nagios + installation. +
+
From lutter at redhat.com Thu Oct 16 17:04:05 2008 From: lutter at redhat.com (David Lutterkort) Date: Thu, 16 Oct 2008 10:04:05 -0700 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <48F76293.3020502@redhat.com> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> <48F73FC8.2010605@redhat.com> <48F74524.9090008@redhat.com> <48F74CE7.10208@redhat.com> <48F74DC1.80504@redhat.com> <48F76293.3020502@redhat.com> Message-ID: <1224176645.13790.4.camel@localhost.localdomain> On Thu, 2008-10-16 at 11:49 -0400, Cole Robinson wrote: > Joey Boggs wrote: > > Cole, > > > > That's fine I'll take a look after it's commited and write that down > > for future reference. > > > > Thanks, committed now: > > http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=9f45a36d8242 One gripe I have with that is that check_disk_signature always runs a TextMeter .. shouldn't the meter be passed in as an argument (and default to None), so that checksums can be computed completely queitly ? David From lutter at redhat.com Thu Oct 16 17:10:17 2008 From: lutter at redhat.com (David Lutterkort) Date: Thu, 16 Oct 2008 10:10:17 -0700 Subject: [et-mgmt-tools] RFC On importing raw images In-Reply-To: <20081009195559.GC2941@redhat.com> References: <48EE1C2F.7050401@redhat.com> <48EE2FF1.3020102@redhat.com> <20081009195559.GC2941@redhat.com> Message-ID: <1224177017.13790.7.camel@localhost.localdomain> On Thu, 2008-10-09 at 20:55 +0100, Daniel P. Berrange wrote: > > - virt-image: no go for libvirt xml, but could be expanded > > to build image xml, and probably the most consistent place > > to do it. > > Yeah, I don't think its applicable for virt-image. virt-image > is really focused on having all the domain metadata upfront > and not prompting the user for it. Wouldn't that be a job for virt-convert ? If the images are so raw that they have _no_ metadata whatsoever, I am not sure that a tool would be any better than a doc describing how to craft image.xml. BTW, virt-image has a --print option which will print the libvirt.xml, so there's at least a way to do image.xml -> libvirt.xml David From jboggs at redhat.com Thu Oct 16 17:37:13 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 16 Oct 2008 13:37:13 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <1224176645.13790.4.camel@localhost.localdomain> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> <48F73FC8.2010605@redhat.com> <48F74524.9090008@redhat.com> <48F74CE7.10208@redhat.com> <48F74DC1.80504@redhat.com> <48F76293.3020502@redhat.com> <1224176645.13790.4.camel@localhost.localdomain> Message-ID: <48F77BC9.9080702@redhat.com> Cole had picked the TextMeter for this, it can be modified as required. David Lutterkort wrote: > On Thu, 2008-10-16 at 11:49 -0400, Cole Robinson wrote: > >> Joey Boggs wrote: >> >>> Cole, >>> >>> That's fine I'll take a look after it's commited and write that down >>> for future reference. >>> >>> >> Thanks, committed now: >> >> http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=9f45a36d8242 >> > > One gripe I have with that is that check_disk_signature always runs a > TextMeter .. shouldn't the meter be passed in as an argument (and > default to None), so that checksums can be computed completely queitly ? > > David > > > From crobinso at redhat.com Thu Oct 16 17:43:56 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 16 Oct 2008 13:43:56 -0400 Subject: [et-mgmt-tools] [patch] virt-image / ImageParser disk signature verification function In-Reply-To: <1224176645.13790.4.camel@localhost.localdomain> References: <48F55678.6000609@redhat.com> <48F6405A.4010505@redhat.com> <48F676D4.3060202@redhat.com> <48F73FC8.2010605@redhat.com> <48F74524.9090008@redhat.com> <48F74CE7.10208@redhat.com> <48F74DC1.80504@redhat.com> <48F76293.3020502@redhat.com> <1224176645.13790.4.camel@localhost.localdomain> Message-ID: <48F77D5C.6080307@redhat.com> David Lutterkort wrote: > On Thu, 2008-10-16 at 11:49 -0400, Cole Robinson wrote: > >> Joey Boggs wrote: >> >>> Cole, >>> >>> That's fine I'll take a look after it's commited and write that down >>> for future reference. >>> >>> >> Thanks, committed now: >> >> http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=9f45a36d8242 >> > > One gripe I have with that is that check_disk_signature always runs a > TextMeter .. shouldn't the meter be passed in as an argument (and > default to None), so that checksums can be computed completely queitly ? > > David > > Yes, good call, I forgot about that. It should be handled similar to how we handle allocating disks. I'll commit a fix for that. Thanks, Cole From lutter at redhat.com Fri Oct 17 01:04:06 2008 From: lutter at redhat.com (David Lutterkort) Date: Thu, 16 Oct 2008 18:04:06 -0700 Subject: [et-mgmt-tools] Try to use cft ... In-Reply-To: <200810100955.58361.martial.paupe@metservice.com> References: <200810100955.58361.martial.paupe@metservice.com> Message-ID: <1224205446.13790.36.camel@localhost.localdomain> On Fri, 2008-10-10 at 09:55 +1300, Martial Paupe wrote: > I'm trying to use cft but I've got that error when I begin a session. > > # cft begin httpd > /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:403:in > `unsafe_validate': Invalid 'failovermethod' value "priorit". Valid > values are absent. Valid values match (?-mix:roundrobin|priority). It seems that you havea yumrepo on that machine with a failovermethod that is neither 'roundrobin' nor 'priority' - the only valid values according to yum.conf(5) David From tournesol33 at gmail.com Fri Oct 17 02:42:28 2008 From: tournesol33 at gmail.com (tournesol) Date: Fri, 17 Oct 2008 11:42:28 +0900 Subject: [et-mgmt-tools] virt-instal with silent install Message-ID: <48F7FB94.1000400@gmail.com> Hi All, I've made a original distribution that is automatic installation without any prompt (= silent install). When I run following on Dom0, it looks running well. /usr/sbin/virt-install -n fc6 -r 1024 -f /disk/xen/fc6.img -s 40 -m 00:16:3e:00:10:10 -b xenbr0 -c /tmp/auto_fc6.iso -v --vnc --noautoconsole And here is the configuration of /etc/xen/fc6. ?on_poweroff = "destroy" ?on_reboot = "restart" ?on_crash = "restart" The problem is that after installed OS, the installer try to reboot itself. But, the session is going to down. it just looks like on_reboot = "destroy" It is a bug? any ideas please! Regards From takatom at jp.fujitsu.com Fri Oct 17 06:44:07 2008 From: takatom at jp.fujitsu.com (=?ISO-2022-JP?B?GyRCOWI2NiEhQ045KBsoQg==?=) Date: Fri, 17 Oct 2008 15:44:07 +0900 (JST) Subject: [et-mgmt-tools] [PATCH][virt-manager] disconnected hosts are still alive on virt-manager. Message-ID: <3a8ac7c017c0dbdd5a1ca7a9ee91be6d.squirrel@webmail-d.css.fujitsu.com> Hi, When a virt-manager monitors multiple hosts and disconnecting these hosts at once, the virt-manager window still shows that these guest domains are connected. And they shows following message. This patch fix this problem. ======== [Fri, 17 Oct 2008 09:42:11 virt-manager 4182] DEBUG (engine:321) window counter decremented to 0 [Fri, 17 Oct 2008 09:42:11 virt-manager 4182] ERROR (virt-manager:148) Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/manager.py", line 550, in conn_state_changed self.conn_refresh_resources(conn) File "/usr/share/virt-manager/virtManager/manager.py", line 568, in conn_refresh_resources del self.rows[model.get_value(child, ROW_KEY)] KeyError: '00000000-0000-0000-0000-000000000000' None ======== Thanks, Tomohiro Takahashi -------------- next part -------------- A non-text attachment was scrubbed... Name: disconnection.patch Type: text/x-patch Size: 1065 bytes Desc: not available URL: From agx at sigxcpu.org Fri Oct 17 08:05:46 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 17 Oct 2008 10:05:46 +0200 Subject: [et-mgmt-tools] virt-manager: exception when connecting to URI with already running VMs In-Reply-To: <48F4E4D7.3040902@redhat.com> References: <20081002173025.GA29444@bogon.ms20.nix> <48EA4953.6080805@redhat.com> <20081007131953.GC29854@bogon.ms20.nix> <48F4E4D7.3040902@redhat.com> Message-ID: <20081017080546.GA5514@bogon.ms20.nix> On Tue, Oct 14, 2008 at 02:28:39PM -0400, Cole Robinson wrote: [..snip..] > I haven't been able to reproduce this: > > - virsh start vmname > - run virt-manager > - double click qemu:///system connection > - vmname console pops up and connects fine > > Works for guest booting up and when the graphical > console is fully started. > > Are you using a remote connection or anything? No all local and it work here now too. I'll report back should it show up again. -- Guido From agx at sigxcpu.org Fri Oct 17 10:12:06 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 17 Oct 2008 12:12:06 +0200 Subject: [et-mgmt-tools] [PATCH] virt-install: allow to pass bustype via --disk Message-ID: <20081017101206.GA6673@bogon.ms20.nix> Hi, attached patch allows to pass the target device's bustype to virtinst. Otherwise one can't force installation via virtio or scsi since the OS/Distro specific default is always being used. Does this look sane? Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: bustype.diff Type: text/x-diff Size: 3267 bytes Desc: not available URL: From jboggs at redhat.com Fri Oct 17 20:17:55 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 17 Oct 2008 16:17:55 -0400 Subject: [et-mgmt-tools] [patch] virt-image verify disk checksum Message-ID: <48F8F2F3.5020002@redhat.com> This patch will make use of the recent disk checksum function for virt-image and verifies prior to importing -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-image-disk-csum-verify-10-17-1612.patch Type: text/x-patch Size: 943 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 18 19:49:02 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 18 Oct 2008 21:49:02 +0200 Subject: [et-mgmt-tools] Re: [PATCH 9/9]: virt-manager: add sparcline to vm/connection overview In-Reply-To: <48EE353F.1080207@redhat.com> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> <48EE353F.1080207@redhat.com> Message-ID: <20081018194902.GA23310@bogon.ms20.nix> Hi Cole, On Thu, Oct 09, 2008 at 12:45:51PM -0400, Cole Robinson wrote: > > + def in_out_vector_limit(self, data, limit): > > + l = len(data)/2 > > + end = [l, limit][l > limit] > > + if l > limit: > > + data = data[0:end] + data[l:l+end] > > This piece here was giving me some trouble. If we > shrink data here, then the line below will try to > grab an out of bound index. That's broken. Fixed in the updated patch series as you suggested. [..snip..] > Also, the scaling problems with the disk polling can be > _really_ bad (though it's no fault of the code). If I have > polling going once a second, and single guest running with > six disks and a nic, the UI is completely locked up. Doesn't look so bad here, but I agree that this can slow down things a lot with plenty of machines - I made this tunable now, see below. > So I'd like to hold off on committing the actual polling > work until we put the gconf values in to disable this. It > doesn't even need to wired up to the gui for now, I can > do that after this its committed if you'd like (the prefs > dialog needs an overhaul anyways, but that can come after). I didn't want to introduce another gconf value if the gui needs an overwhole anyway so I simply used the existing vmlist-fiels/{network_traffic, disk_usage}. Are you o.k. with that? I repost the whole remaining series. Cheers, -- Guido From agx at sigxcpu.org Sat Oct 18 19:49:57 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 18 Oct 2008 21:49:57 +0200 Subject: [et-mgmt-tools] [PATCH 1/5]: virt-manager: block device and network statistics References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> <48EE353F.1080207@redhat.com> Message-ID: <20081018194956.GA23505@bogon.ms20.nix> Hi, this patch calculates block and net stats. Only change is a more condensed calculation of the limits by introducing _set_max_rate(). -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 01_block_and_net_stats.diff Type: text/x-diff Size: 31549 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 18 19:50:17 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 18 Oct 2008 21:50:17 +0200 Subject: [et-mgmt-tools] [PATCH 2/5]: virt-manager: draw rx/tx and read/write in one graph each References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> <48EE353F.1080207@redhat.com> Message-ID: <20081018195017.GB23505@bogon.ms20.nix> Hi, Draw separate sparclines for rx/tx (network) and read/write (block). This patch is unchanged. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 02_use_dualspark.diff Type: text/x-diff Size: 3000 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 18 19:50:35 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 18 Oct 2008 21:50:35 +0200 Subject: [et-mgmt-tools] [PATCH 3/9]: virt-manager: color sparkline for rx/tx, read/write References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> <48EE353F.1080207@redhat.com> Message-ID: <20081018195035.GC23505@bogon.ms20.nix> Hi, Color the rx and read sparclines redish, the tx and write sparcline greenish - same for the labels. Colors adjusted as to Daniel's suggestion. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 03_color_graph.diff Type: text/x-diff Size: 5176 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 18 19:51:11 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 18 Oct 2008 21:51:11 +0200 Subject: [et-mgmt-tools] [PATCH 4/5]: virt-manager: add sparcline to vm/connection overview References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> <48EE353F.1080207@redhat.com> Message-ID: <20081018195111.GD23505@bogon.ms20.nix> Hi, Display a combined sparcline for rx & tx (network) and input & output (disk) in the Network I/O and Disk I/O columns in the vm machine overview. Bounds fixed as suggested by Cole. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 04_block_and_net_cellsparcline.diff Type: text/x-diff Size: 5144 bytes Desc: not available URL: From agx at sigxcpu.org Sat Oct 18 19:51:34 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Sat, 18 Oct 2008 21:51:34 +0200 Subject: [et-mgmt-tools] [PATCH 5/5]: virt-manager: allow to turn of sampling References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> <48EE353F.1080207@redhat.com> Message-ID: <20081018195134.GE23505@bogon.ms20.nix> Hi, this patch allows to disale the sampling of net/block stats - triggered via the vmlist-fields/{network_traffic,disk_io} gconf keys. We do this by replacing the sampling routines with noops. Also adjust the label in the vm details to say "sampling disabled". -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 05_allow_to_disale_sampling.diff Type: text/x-diff Size: 5806 bytes Desc: not available URL: From fj0588di at aa.jp.fujitsu.com Mon Oct 20 08:44:59 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Mon, 20 Oct 2008 17:44:59 +0900 Subject: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH] virt-managercallsmigrationAPI In-Reply-To: <48F7581C.4040203@redhat.com> References: <200809191843.GCG69223.96J09KGE@aa.jp.fujitsu.com> <20080919100727.GM18194@redhat.com> <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> <48F7581C.4040203@redhat.com> Message-ID: <200810201744.HHD43727.6G9JKE09@aa.jp.fujitsu.com> Hi, Cole Thank you for your comment. I fix the following three points about Migrate patch. 1. Move the logic that get available host from manager.py to engnine.py. 2. Don't show a host of the different hypervisor in available host list. 3. Change the message from "is migrated from" to "will be migrated from". This patch only can migrate from sub-menu. I understand that it is necessary to add migrate to the 'Virtual Machine' menu in the individual VM view. But, Just now, I can't focus on that. So, anybody's patch are welcome. Signed-off-by: Shigeki Sakamoto Thanks, Shigeki Sakamoto. > > Hi, patch generally looks good. One issue though: how does > this handle connections using different hypervisors? Say a local > xen and a remote qemu. Obviously we shouldn't be able to > migrate between the two but I think this code would allow it. > > Maybe have the connection list look something like: > > migrate -> hostname1 (qemu) > -> hostname2 (xen) > > If the hypervisors don't match the entry would be disabled. > > Also, having the migrate option only available as a right > click menu item doesn't seem too transparent. Maybe also > list it as an option under the 'Virtual Machine' menu > in the individual VM view. If you go this route, you'll want > to offload most of the logic to engine.py like is done for > shutdown, pause, etc. > > > diff -r 270e1697b81a src/virtManager/domain.py > > --- a/src/virtManager/domain.py Mon Oct 06 13:21:06 2008 -0400 > > +++ b/src/virtManager/domain.py Wed Oct 08 16:38:05 2008 +0900 > > @@ -972,4 +972,10 @@ class vmmDomain(gobject.GObject): > > # Invalidate cached xml > > self.xml = None > > > > + def migrate(self, dictcon): > > + flags = 0 > > + if self.lastStatus == libvirt.VIR_DOMAIN_RUNNING: > > + flags = libvirt.VIR_MIGRATE_LIVE > > + self.vm.migrate(self.connection.vmm, flags, None, > > dictcon.get_short_hostname(), 0) > > + > > gobject.type_register(vmmDomain) > > diff -r 270e1697b81a src/virtManager/engine.py > > --- a/src/virtManager/engine.py Mon Oct 06 13:21:06 2008 -0400 > > +++ b/src/virtManager/engine.py Wed Oct 08 16:38:05 2008 +0900 > > @@ -202,6 +202,8 @@ class vmmEngine(gobject.GObject): > > self.shutdown_domain(src, uri, uuid) > > def _do_reboot_domain(self, src, uri, uuid): > > self.reboot_domain(src, uri, uuid) > > + def _do_migrate_domain(self, src, uri, uuid, desturi): > > + self.migrate_domain(uri, uuid, desturi) > > def _do_exit_app(self, src): > > self.exit_app() > > > > @@ -296,6 +298,7 @@ class vmmEngine(gobject.GObject): > > self.windowManager.connect("action-shutdown-domain", > > self._do_shutdown_domain) > > self.windowManager.connect("action-reboot-domain", > > self._do_reboot_domain) > > self.windowManager.connect("action-destroy-domain", > > self._do_destroy_domain) > > + self.windowManager.connect("action-migrate-domain", > > self._do_migrate_domain) > > self.windowManager.connect("action-show-console", > > self._do_show_console) > > self.windowManager.connect("action-show-details", > > self._do_show_details) > > self.windowManager.connect("action-show-preferences", > > self._do_show_preferences) > > @@ -528,6 +531,39 @@ class vmmEngine(gobject.GObject): > > else: > > logging.warning("Reboot requested, but machine is already > > shutting down / shutoff") > > > > + def migrate_domain(self, uri, uuid, desturi): > > + conn = self.get_connection(uri, False) > > + vm = conn.get_vm(uuid) > > + destconn = self.get_connection(desturi, False) > > + migrate_progress = None > > + try: > > + # show progress dialog > > + migrate_progress = > > self.get_migrate_progress(vm.get_name(), conn.get_short_hostname(), > > destconn.get_short_hostname()) > > + migrate_progress.show() > > + while gtk.events_pending(): > > + gtk.main_iteration() > > + # call virDomainMigrate > > + vm.migrate(destconn) > > + # close progress dialog > > + migrate_progress.destroy() > > + except Exception, e: > > + migrate_progress.destroy() > > + self.err.show_err(_("Error migrating domain: %s") % str(e), > > + "".join(traceback.format_exc())) > > + > > + self.windowManager.conn_refresh_resources(conn) > > + self.windowManager.conn_refresh_resources(destconn) > > + > > + def get_migrate_progress(self, vmname, hostname, desthostname): > > + migrate_progress = None > > + migrate_progress = gtk.MessageDialog(None, \ > > + > > gtk.DIALOG_DESTROY_WITH_PARENT, \ > > + gtk.MESSAGE_INFO, \ > > + gtk.BUTTONS_NONE, \ > > + _("%s is migrating from > > %s to %s." % \ > > + (vmname, hostname, > > desthostname))) > > + migrate_progress.set_title(" ") > > + return migrate_progress > > > > > > gobject.type_register(vmmEngine) > > diff -r 270e1697b81a src/virtManager/manager.py > > --- a/src/virtManager/manager.py Mon Oct 06 13:21:06 2008 -0400 > > +++ b/src/virtManager/manager.py Wed Oct 08 16:38:05 2008 +0900 > > @@ -101,6 +101,8 @@ class vmmManager(gobject.GObject): > > gobject.TYPE_NONE, [str]), > > "action-show-help": (gobject.SIGNAL_RUN_FIRST, > > gobject.TYPE_NONE, [str]), > > + "action-migrate-domain": (gobject.SIGNAL_RUN_FIRST, > > + gobject.TYPE_NONE, (str,str,str)), > > "action-exit-app": (gobject.SIGNAL_RUN_FIRST, > > gobject.TYPE_NONE, []),} > > > > @@ -154,6 +156,8 @@ class vmmManager(gobject.GObject): > > self.vmmenushutdown = gtk.Menu() > > self.vmmenu_items = {} > > self.vmmenushutdown_items = {} > > + self.vmmenumigrate = gtk.Menu() > > + self.vmmenumigrate_items = {} > > > > self.vmmenu_items["run"] = gtk.ImageMenuItem("_Run") > > self.vmmenu_items["run"].set_image(self.vmmenu_icons["run"]) > > @@ -198,9 +202,23 @@ class vmmManager(gobject.GObject): > > > > self.vmmenushutdown_items["forcepoweroff"].connect("activate", > > self.destroy_vm) > > > > self.vmmenushutdown.add(self.vmmenushutdown_items["forcepoweroff"]) > > > > - self.vmmenu_items["hsep"] = gtk.SeparatorMenuItem() > > - self.vmmenu_items["hsep"].show(); > > - self.vmmenu.add(self.vmmenu_items["hsep"]) > > + self.vmmenu_items["hsep1"] = gtk.SeparatorMenuItem() > > + self.vmmenu_items["hsep1"].show(); > > + self.vmmenu.add(self.vmmenu_items["hsep1"]) > > + > > + self.vmmenu_items["migrate"] = gtk.ImageMenuItem("_Migrate") > > + self.vmmenu_items["migrate"].set_submenu(self.vmmenumigrate) > > + self.vmmenu_items["migrate"].show() > > + self.vmmenu.add(self.vmmenu_items["migrate"]) > > + > > + self.vmmenumigrate_items["(None)"] = > > gtk.ImageMenuItem(_("(None)")) > > + self.vmmenumigrate_items["(None)"].show() > > + self.vmmenumigrate_items["(None)"].set_sensitive(False) > > + self.vmmenumigrate.add(self.vmmenumigrate_items["(None)"]) > > + > > + self.vmmenu_items["hsep2"] = gtk.SeparatorMenuItem() > > + self.vmmenu_items["hsep2"].show(); > > + self.vmmenu.add(self.vmmenu_items["hsep2"]) > > > > self.vmmenu_items["open"] = gtk.ImageMenuItem(gtk.STOCK_OPEN) > > self.vmmenu_items["open"].connect("activate", > > self.open_vm_console) > > @@ -698,6 +716,7 @@ class vmmManager(gobject.GObject): > > self.vmmenu_items["resume"].hide() > > self.vmmenu_items["resume"].set_sensitive(False) > > self.vmmenu_items["shutdown"].set_sensitive(False) > > + self.vmmenu_items["migrate"].set_sensitive(False) > > else: > > if vm.status() == libvirt.VIR_DOMAIN_SHUTOFF: > > self.vmmenu_items["run"].set_sensitive(True) > > @@ -706,6 +725,8 @@ class vmmManager(gobject.GObject): > > self.vmmenu_items["resume"].hide() > > self.vmmenu_items["resume"].set_sensitive(False) > > > > self.vmmenu_items["shutdown"].set_sensitive(False) > > + self.vmmenu_items["migrate"].set_sensitive(True) > > + self.set_migrate_submenu() > > elif vm.status() == libvirt.VIR_DOMAIN_RUNNING: > > self.vmmenu_items["run"].set_sensitive(False) > > self.vmmenu_items["pause"].set_sensitive(True) > > @@ -713,6 +734,8 @@ class vmmManager(gobject.GObject): > > self.vmmenu_items["resume"].hide() > > self.vmmenu_items["resume"].set_sensitive(False) > > self.vmmenu_items["shutdown"].set_sensitive(True) > > + self.vmmenu_items["migrate"].set_sensitive(True) > > + self.set_migrate_submenu() > > elif vm.status() == libvirt.VIR_DOMAIN_PAUSED: > > self.vmmenu_items["run"].set_sensitive(False) > > self.vmmenu_items["pause"].hide() > > @@ -720,6 +743,8 @@ class vmmManager(gobject.GObject): > > self.vmmenu_items["resume"].show() > > self.vmmenu_items["resume"].set_sensitive(True) > > self.vmmenu_items["shutdown"].set_sensitive(True) > > + self.vmmenu_items["migrate"].set_sensitive(True) > > + self.set_migrate_submenu() > > self.vmmenu.popup(None, None, None, 0, event.time) > > return False > > else: > > @@ -1007,6 +1032,53 @@ class vmmManager(gobject.GObject): > > if vm is not None: > > self.emit("action-resume-domain", > > vm.get_connection().get_uri(), vm.get_uuid()) > > > > + def migrate(self, ignore): > > + vm = self.current_vm() > > + # get selected submenu(destination hostname) > > + hostname = > > self.vmmenumigrate.get_active().get_image().get_stock()[0] > > + for key in self.engine.connections.keys(): > > + if self.engine.get_connection(key).get_hostname() == > > hostname: > > + host_uri = key > > + break > > + if vm is not None: > > + result = self.err.yes_no(_("%s is migrated from %s to %s, > > are you sure?") % \ > > Change "is migrated from" to "will be migrated from" > > The rest looks fine. > > Thanks, > Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: migrate_submenu.patch Type: application/octet-stream Size: 11232 bytes Desc: not available URL: From bkearney at redhat.com Mon Oct 20 14:23:09 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 20 Oct 2008 10:23:09 -0400 Subject: [et-mgmt-tools] [patch] virt-image verify disk checksum In-Reply-To: <48F8F2F3.5020002@redhat.com> References: <48F8F2F3.5020002@redhat.com> Message-ID: <48FC944D.7090201@redhat.com> Joey Boggs wrote: > This patch will make use of the recent disk checksum function for > virt-image and verifies prior to importing Is there any reason why I would want to control which signature to check? -- bk From crobinso at redhat.com Mon Oct 20 14:32:06 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Oct 2008 10:32:06 -0400 Subject: [et-mgmt-tools] [patch] virt-image verify disk checksum In-Reply-To: <48F8F2F3.5020002@redhat.com> References: <48F8F2F3.5020002@redhat.com> Message-ID: <48FC9666.7030602@redhat.com> Joey Boggs wrote: > This patch will make use of the recent disk checksum function for > virt-image and verifies prior to importing > > diff -r 9f45a36d8242 virt-image > --- a/virt-image Thu Oct 16 11:18:49 2008 -0400 > +++ b/virt-image Fri Oct 17 16:12:16 2008 -0400 > @@ -145,6 +145,8 @@ > parser.add_option("", "--replace",action="store_true", dest="replace", > help=_("Overwrite, or destroy, an existing image with the same name"), > default=False) > + parser.add_option("","--skip-checksum", action="store_true", dest="skipchecksum", > + help=_("Skip disk checksum verification process")) > > (options,args) = parser.parse_args() > if len(args) < 1: > @@ -204,6 +206,10 @@ > if options.noapic: > guest.features["apic"] = False > > + if not options.skipchecksum: > + for d in image.storage.values(): > + virtinst.ImageParser.Disk.check_disk_signature(d) > + This line just abuses the way python does object orientation. You want to do: if not options.skipchecksum: for disk in image.storage.values(): disk.check_disk_signature() Thanks, Cole From crobinso at redhat.com Mon Oct 20 14:35:38 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Oct 2008 10:35:38 -0400 Subject: [et-mgmt-tools] [PATCH] virt-install: allow to pass bustype via --disk In-Reply-To: <20081017101206.GA6673@bogon.ms20.nix> References: <20081017101206.GA6673@bogon.ms20.nix> Message-ID: <48FC973A.1020200@redhat.com> Guido G?nther wrote: > Hi, > attached patch allows to pass the target device's bustype to virtinst. > Otherwise one can't force installation via virtio or scsi since the > OS/Distro specific default is always being used. Does this look sane? > Cheers, > -- Guido > Looks good to me. Pushed now: http://hg.et.redhat.com/virt/applications/virtinst--devel Thanks, Cole From crobinso at redhat.com Mon Oct 20 14:36:55 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Oct 2008 10:36:55 -0400 Subject: [et-mgmt-tools] [PATCH] virt-install: allow to pass bustype via --disk In-Reply-To: <48FC973A.1020200@redhat.com> References: <20081017101206.GA6673@bogon.ms20.nix> <48FC973A.1020200@redhat.com> Message-ID: <48FC9787.4050305@redhat.com> Cole Robinson wrote: > Guido G?nther wrote: >> Hi, >> attached patch allows to pass the target device's bustype to virtinst. >> Otherwise one can't force installation via virtio or scsi since the >> OS/Distro specific default is always being used. Does this look sane? >> Cheers, >> -- Guido >> > > Looks good to me. Pushed now: > > http://hg.et.redhat.com/virt/applications/virtinst--devel > > Thanks, > Cole > Umm, psuedo-wrong link :) http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=710611367b50 - Cole From crobinso at redhat.com Mon Oct 20 14:51:37 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Oct 2008 10:51:37 -0400 Subject: [et-mgmt-tools] [PATCH][virt-manager] disconnected hosts are still alive on virt-manager. In-Reply-To: <3a8ac7c017c0dbdd5a1ca7a9ee91be6d.squirrel@webmail-d.css.fujitsu.com> References: <3a8ac7c017c0dbdd5a1ca7a9ee91be6d.squirrel@webmail-d.css.fujitsu.com> Message-ID: <48FC9AF9.9090708@redhat.com> ????? wrote: > Hi, > > When a virt-manager monitors multiple hosts and > disconnecting these hosts at once, > the virt-manager window still shows that these guest domains are connected. > And they shows following message. > This patch fix this problem. > > ======== > [Fri, 17 Oct 2008 09:42:11 virt-manager 4182] DEBUG (engine:321) window > counter decremented to 0 > [Fri, 17 Oct 2008 09:42:11 virt-manager 4182] ERROR (virt-manager:148) > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/manager.py", line 550, in > conn_state_changed > self.conn_refresh_resources(conn) > File "/usr/share/virt-manager/virtManager/manager.py", line 568, in > conn_refresh_resources > del self.rows[model.get_value(child, ROW_KEY)] > KeyError: '00000000-0000-0000-0000-000000000000' > None > ======== > Thanks, applied: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=9c4afb8ad1e6 - Cole From jboggs at redhat.com Mon Oct 20 15:03:53 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 20 Oct 2008 11:03:53 -0400 Subject: [et-mgmt-tools] [patch] virt-image verify disk checksum In-Reply-To: <48FC944D.7090201@redhat.com> References: <48F8F2F3.5020002@redhat.com> <48FC944D.7090201@redhat.com> Message-ID: <48FC9DD9.4030005@redhat.com> Bryan Kearney wrote: > Joey Boggs wrote: >> This patch will make use of the recent disk checksum function for >> virt-image and verifies prior to importing > > > Is there any reason why I would want to control which signature to check? > More or less could be just preference, sha256 being stronger and less potential to generate the same signature again. Final checksum is up to the image release person/vendor. > -- bk > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From jboggs at redhat.com Mon Oct 20 15:04:52 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 20 Oct 2008 11:04:52 -0400 Subject: [et-mgmt-tools] [patch] virt-image verify disk checksum In-Reply-To: <48FC9666.7030602@redhat.com> References: <48F8F2F3.5020002@redhat.com> <48FC9666.7030602@redhat.com> Message-ID: <48FC9E14.70500@redhat.com> updated to use corrected method Cole Robinson wrote: > Joey Boggs wrote: > >> This patch will make use of the recent disk checksum function for >> virt-image and verifies prior to importing >> >> > > >> diff -r 9f45a36d8242 virt-image >> --- a/virt-image Thu Oct 16 11:18:49 2008 -0400 >> +++ b/virt-image Fri Oct 17 16:12:16 2008 -0400 >> @@ -145,6 +145,8 @@ >> parser.add_option("", "--replace",action="store_true", dest="replace", >> help=_("Overwrite, or destroy, an existing image with the same name"), >> default=False) >> + parser.add_option("","--skip-checksum", action="store_true", dest="skipchecksum", >> + help=_("Skip disk checksum verification process")) >> >> (options,args) = parser.parse_args() >> if len(args) < 1: >> @@ -204,6 +206,10 @@ >> if options.noapic: >> guest.features["apic"] = False >> >> + if not options.skipchecksum: >> + for d in image.storage.values(): >> + virtinst.ImageParser.Disk.check_disk_signature(d) >> + >> > > This line just abuses the way python does object orientation. You > want to do: > > if not options.skipchecksum: > for disk in image.storage.values(): > disk.check_disk_signature() > > Thanks, > Cole > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-image-disk-csum-verify-10-20-1100.patch Type: text/x-patch Size: 924 bytes Desc: not available URL: From crobinso at redhat.com Mon Oct 20 15:16:19 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Oct 2008 11:16:19 -0400 Subject: [et-mgmt-tools] [patch] virt-image verify disk checksum In-Reply-To: <48FC9E14.70500@redhat.com> References: <48F8F2F3.5020002@redhat.com> <48FC9666.7030602@redhat.com> <48FC9E14.70500@redhat.com> Message-ID: <48FCA0C3.5050902@redhat.com> Joey Boggs wrote: > updated to use corrected method > > Thanks, applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=976334e29192 - Cole From bryan.christ at hp.com Mon Oct 20 23:11:43 2008 From: bryan.christ at hp.com (Bryan Christ) Date: Mon, 20 Oct 2008 18:11:43 -0500 Subject: [et-mgmt-tools] Copying Images for VMM Message-ID: <1224544303.2557.88.camel@tuxdev64> Please accept my apologies if this is not the right form for Virtual Machine Manager questions. I was wondering if someone could point me to documentation on image management. In short I have WinXP guest machine on my laptop running on KVM and would like to copy that image to another computer. Thanks in advance, Bryan From sakaia at jp.fujitsu.com Tue Oct 21 00:39:43 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Tue, 21 Oct 2008 09:39:43 +0900 Subject: [et-mgmt-tools] Copying Images for VMM In-Reply-To: <1224544303.2557.88.camel@tuxdev64> References: <1224544303.2557.88.camel@tuxdev64> Message-ID: <20081021003948.5B8121804C@m022.s.css.fujitsu.com> Hello Bryan I hope following page will help. http://libvirt.org/apps.html Thanks Atsushi SAKAI Bryan Christ wrote: > Please accept my apologies if this is not the right form for Virtual > Machine Manager questions. > > I was wondering if someone could point me to documentation on image > management. In short I have WinXP guest machine on my laptop running on > KVM and would like to copy that image to another computer. > > Thanks in advance, > > Bryan > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From bryan.christ at hp.com Tue Oct 21 14:58:41 2008 From: bryan.christ at hp.com (Bryan Christ) Date: Tue, 21 Oct 2008 09:58:41 -0500 Subject: [et-mgmt-tools] Copying Images for VMM In-Reply-To: <20081021003948.5B8121804C@m022.s.css.fujitsu.com> References: <1224544303.2557.88.camel@tuxdev64> <20081021003948.5B8121804C@m022.s.css.fujitsu.com> Message-ID: <1224601121.2557.103.camel@tuxdev64> Thanks for the URL. I looked at the virt-clone tool, but it only lets you clone images on a local host. I need to copy my *.img file from my laptop to my desktop. I tried manually copying the file from /var/lib/libvirt/images but I think there's an extra step (or more) that I need to do. Does anyone know? On Tue, 2008-10-21 at 00:39 +0000, Atsushi SAKAI wrote: > Hello Bryan > > I hope following page will help. > http://libvirt.org/apps.html > > Thanks > Atsushi SAKAI > > > > Bryan Christ wrote: > > > Please accept my apologies if this is not the right form for Virtual > > Machine Manager questions. > > > > I was wondering if someone could point me to documentation on image > > management. In short I have WinXP guest machine on my laptop running on > > KVM and would like to copy that image to another computer. > > > > Thanks in advance, > > > > Bryan > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > From crobinso at redhat.com Tue Oct 21 15:09:28 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 21 Oct 2008 11:09:28 -0400 Subject: [et-mgmt-tools] Copying Images for VMM In-Reply-To: <1224601121.2557.103.camel@tuxdev64> References: <1224544303.2557.88.camel@tuxdev64> <20081021003948.5B8121804C@m022.s.css.fujitsu.com> <1224601121.2557.103.camel@tuxdev64> Message-ID: <48FDF0A8.4080500@redhat.com> Bryan Christ wrote: > Thanks for the URL. I looked at the virt-clone tool, but it only lets > you clone images on a local host. I need to copy my *.img file from my > laptop to my desktop. I tried manually copying the file > from /var/lib/libvirt/images but I think there's an extra step (or more) > that I need to do. > > Does anyone know? > You'll need to transfer the vm configuration as well. (on source host) virsh dumpxml vmname > vmname.xml copy vmname.xml from src to dest (on dest host) virsh define vmname.xml If the .img is at the same path on the new host, and you have a similar network setup, machine arch, distro etc, it should just work. Thanks, Cole From bryan.christ at hp.com Tue Oct 21 15:21:35 2008 From: bryan.christ at hp.com (Bryan Christ) Date: Tue, 21 Oct 2008 10:21:35 -0500 Subject: [et-mgmt-tools] Copying Images for VMM In-Reply-To: <48FDF0A8.4080500@redhat.com> References: <1224544303.2557.88.camel@tuxdev64> <20081021003948.5B8121804C@m022.s.css.fujitsu.com> <1224601121.2557.103.camel@tuxdev64> <48FDF0A8.4080500@redhat.com> Message-ID: <1224602495.2557.109.camel@tuxdev64> Thank you! I will try that. On Tue, 2008-10-21 at 15:09 +0000, Cole Robinson wrote: > Bryan Christ wrote: > > Thanks for the URL. I looked at the virt-clone tool, but it only lets > > you clone images on a local host. I need to copy my *.img file from my > > laptop to my desktop. I tried manually copying the file > > from /var/lib/libvirt/images but I think there's an extra step (or more) > > that I need to do. > > > > Does anyone know? > > > > You'll need to transfer the vm configuration as well. > > (on source host) virsh dumpxml vmname > vmname.xml > copy vmname.xml from src to dest > (on dest host) virsh define vmname.xml > > If the .img is at the same path on the new host, and you > have a similar network setup, machine arch, distro etc, > it should just work. > > Thanks, > Cole > From agx at sigxcpu.org Tue Oct 21 17:04:16 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 21 Oct 2008 19:04:16 +0200 Subject: [et-mgmt-tools] libvirt munin plugins In-Reply-To: <20081016163459.GX1978@redhat.com> References: <20081016153857.GA3820@bogon.ms20.nix> <20081016154122.GF1821@redhat.com> <20081016163459.GX1978@redhat.com> Message-ID: <20081021170416.GA349@bogon.ms20.nix> On Thu, Oct 16, 2008 at 06:34:59PM +0200, Daniel Veillard wrote: > On Thu, Oct 16, 2008 at 04:41:22PM +0100, Daniel P. Berrange wrote: > > On Thu, Oct 16, 2008 at 05:38:57PM +0200, Guido G?nther wrote: > > > Hi, > > > just in case somebody monitors VMs with munin[1]. I've put to simple > > > plugins for net and block I/O monitoring here: > > > http://honk.sigxcpu.org/projects/libvirt/monitor/ > > > > Nice idea ! Rich Jones did a similar thing for collectd, and Nagios. > > > > We should link to all 3 of these plugins from the libvirt applications > > page on the website http://libvirt.org/apps.html > > Makes sense ! Attached patch adds the 3 plugins in a new section of > the application page, Would be great to have this! I just added a munin cputime plugin. To keep things simple you could just link to http://honk.sigxcpu.org/projects/libvirt/#munin Cheers, -- Guido From berrange at redhat.com Tue Oct 21 17:24:28 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 21 Oct 2008 18:24:28 +0100 Subject: [et-mgmt-tools] libvirt munin plugins In-Reply-To: <20081021170416.GA349@bogon.ms20.nix> References: <20081016153857.GA3820@bogon.ms20.nix> <20081016154122.GF1821@redhat.com> <20081016163459.GX1978@redhat.com> <20081021170416.GA349@bogon.ms20.nix> Message-ID: <20081021172428.GQ16442@redhat.com> On Tue, Oct 21, 2008 at 07:04:16PM +0200, Guido G?nther wrote: > On Thu, Oct 16, 2008 at 06:34:59PM +0200, Daniel Veillard wrote: > > On Thu, Oct 16, 2008 at 04:41:22PM +0100, Daniel P. Berrange wrote: > > > On Thu, Oct 16, 2008 at 05:38:57PM +0200, Guido G?nther wrote: > > > > Hi, > > > > just in case somebody monitors VMs with munin[1]. I've put to simple > > > > plugins for net and block I/O monitoring here: > > > > http://honk.sigxcpu.org/projects/libvirt/monitor/ > > > > > > Nice idea ! Rich Jones did a similar thing for collectd, and Nagios. > > > > > > We should link to all 3 of these plugins from the libvirt applications > > > page on the website http://libvirt.org/apps.html > > > > Makes sense ! Attached patch adds the 3 plugins in a new section of > > the application page, > Would be great to have this! I just added a munin cputime plugin. To > keep things simple you could just link to > http://honk.sigxcpu.org/projects/libvirt/#munin Is the conversion of cpuTime to a percentage value really doing what you want here ? The 'cpuTime' field is cummulative since the domain was first started, so the % utilization you're calcuating is the % of the host that was utilized over the entire time the domain was running. I would have thought the % you really want is the utilization between the two invocations of the 'libvirt-cputime' script. eg if you have munin running that script once every 10 seconds, you'd want the % to be calculated based on that 10 second window, rather than the lifetime of the VM 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 veillard at redhat.com Wed Oct 22 13:34:53 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 22 Oct 2008 15:34:53 +0200 Subject: [et-mgmt-tools] libvirt munin plugins In-Reply-To: <20081021170416.GA349@bogon.ms20.nix> References: <20081016153857.GA3820@bogon.ms20.nix> <20081016154122.GF1821@redhat.com> <20081016163459.GX1978@redhat.com> <20081021170416.GA349@bogon.ms20.nix> Message-ID: <20081022133453.GD11386@redhat.com> On Tue, Oct 21, 2008 at 07:04:16PM +0200, Guido G?nther wrote: > On Thu, Oct 16, 2008 at 06:34:59PM +0200, Daniel Veillard wrote: > > On Thu, Oct 16, 2008 at 04:41:22PM +0100, Daniel P. Berrange wrote: > > > On Thu, Oct 16, 2008 at 05:38:57PM +0200, Guido G?nther wrote: > > > > Hi, > > > > just in case somebody monitors VMs with munin[1]. I've put to simple > > > > plugins for net and block I/O monitoring here: > > > > http://honk.sigxcpu.org/projects/libvirt/monitor/ > > > > > > Nice idea ! Rich Jones did a similar thing for collectd, and Nagios. > > > > > > We should link to all 3 of these plugins from the libvirt applications > > > page on the website http://libvirt.org/apps.html > > > > Makes sense ! Attached patch adds the 3 plugins in a new section of > > the application page, > Would be great to have this! I just added a munin cputime plugin. To > keep things simple you could just link to > http://honk.sigxcpu.org/projects/libvirt/#munin Okay I will update the page soon with a new link and slightly different description. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ From agx at sigxcpu.org Wed Oct 22 20:26:20 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Wed, 22 Oct 2008 22:26:20 +0200 Subject: [et-mgmt-tools] libvirt munin plugins In-Reply-To: <20081021172428.GQ16442@redhat.com> References: <20081016153857.GA3820@bogon.ms20.nix> <20081016154122.GF1821@redhat.com> <20081016163459.GX1978@redhat.com> <20081021170416.GA349@bogon.ms20.nix> <20081021172428.GQ16442@redhat.com> Message-ID: <20081022202620.GB23383@bogon.ms20.nix> On Tue, Oct 21, 2008 at 06:24:28PM +0100, Daniel P. Berrange wrote: > Is the conversion of cpuTime to a percentage value really doing what > you want here ? It does since we have "cputime.type DERIVE" in the config: http://munin.projects.linpro.no/wiki/fieldname.type So rrdtool will do (val(now)-val(backthen)/interval) for us. Cheers, -- Guido From crobinso at redhat.com Thu Oct 23 15:45:51 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 23 Oct 2008 11:45:51 -0400 Subject: [et-mgmt-tools] Re: [PATCH 9/9]: virt-manager: add sparcline to vm/connection overview In-Reply-To: <20081018194902.GA23310@bogon.ms20.nix> References: <20081003135003.GA5273@bogon.ms20.nix> <48E67E5B.9000106@redhat.com> <20081004201157.GA29584@bogon.ms20.nix> <20081004203046.GI29914@bogon.ms20.nix> <48EE353F.1080207@redhat.com> <20081018194902.GA23310@bogon.ms20.nix> Message-ID: <49009C2F.4000203@redhat.com> Guido G?nther wrote: > Hi Cole, > On Thu, Oct 09, 2008 at 12:45:51PM -0400, Cole Robinson wrote: >>> + def in_out_vector_limit(self, data, limit): >>> + l = len(data)/2 >>> + end = [l, limit][l > limit] >>> + if l > limit: >>> + data = data[0:end] + data[l:l+end] >> This piece here was giving me some trouble. If we >> shrink data here, then the line below will try to >> grab an out of bound index. > That's broken. Fixed in the updated patch series as you suggested. > > [..snip..] >> Also, the scaling problems with the disk polling can be >> _really_ bad (though it's no fault of the code). If I have >> polling going once a second, and single guest running with >> six disks and a nic, the UI is completely locked up. > Doesn't look so bad here, but I agree that this can slow down things a > lot with plenty of machines - I made this tunable now, see below. > >> So I'd like to hold off on committing the actual polling >> work until we put the gconf values in to disable this. It >> doesn't even need to wired up to the gui for now, I can >> do that after this its committed if you'd like (the prefs >> dialog needs an overhaul anyways, but that can come after). > I didn't want to introduce another gconf value if the gui needs an > overwhole anyway so I simply used the existing > vmlist-fiels/{network_traffic, disk_usage}. Are you o.k. with that? > Yep, that's fine for now. I'm probably going to make this more fine grained in the near future, so that disabling the column view in the manager window _doesn't_ mean skip the polling: that will be a separate option. My guess is, when we cut a new release, I will keep the disk and net stats disabled as they are now, with a warning in the prefs dialog that there may be scaling issues. Anyways, I've applied the remaining patches. Thanks a lot for the contribution! - Cole From orion at cora.nwra.com Thu Oct 23 21:44:58 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 23 Oct 2008 15:44:58 -0600 Subject: [et-mgmt-tools] virt-install fails if http server has directory indexes turned off Message-ID: <4900F05A.4060005@cora.nwra.com> def acquireKernel(baseuri, progresscb, scratchdir="/var/tmp", type=None, distro=None, arch=None): fetcher = _fetcherForURI(baseuri, scratchdir) try: fetcher.prepareLocation(progresscb) except ValueError, e: raise ValueError, _("Invalid install location: ") + str(e) Here we're attempting to download the base directory to test whether the location is valid. This seems unnecessary and fails if the server has disabled directory listings. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From fj0588di at aa.jp.fujitsu.com Fri Oct 24 08:29:29 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Fri, 24 Oct 2008 17:29:29 +0900 Subject: [et-mgmt-tools] [PATCH][RFC](take2)Add "Migrate" to VirtualMachine-menu in the individual VM view In-Reply-To: <200810201744.HHD43727.6G9JKE09@aa.jp.fujitsu.com> References: <20080919100727.GM18194@redhat.com> <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> <48F7581C.4040203@redhat.com> <200810201744.HHD43727.6G9JKE09@aa.jp.fujitsu.com> Message-ID: <200810241729.BEB29711.0GE9KJ69@aa.jp.fujitsu.com> Hi, Cole I cleared all the problems about your comment. I show the following the summary of this patch and a problem about doing "Migrate" from individual VM view. [Summary] 1. Move the logic that get available host from manager.py to engnine.py. 2. Don't show a host of the different hypervisor in available host list. 3. Change the message from "is migrated from" to "will be migrated from". 4. Add "Migrate" to VirtualMachine-menu in the individual VM view. VirtualMachine | +- Run Pause Shutdown Save --------------- Migrate ----> host1.example.com --------------- host2.example.com Take Screenshot host3.example.com [Problem] After I do "Migrate" from the individual VM view, the view shows a information of the VM on not destination host. But, I think that the view should show a information of the VM on destination host. How about this problem? Thanks, Shigeki Sakamoto. > Hi, Cole > > Thank you for your comment. > > I fix the following three points about Migrate patch. > > 1. Move the logic that get available host from manager.py to engnine.py. > > 2. Don't show a host of the different hypervisor in available host list. > > 3. Change the message from "is migrated from" to "will be migrated from". > > This patch only can migrate from sub-menu. > I understand that it is necessary to add migrate to the 'Virtual Machine' menu > in the individual VM view. > But, Just now, I can't focus on that. So, anybody's patch are welcome. > > > Signed-off-by: Shigeki Sakamoto > > Thanks, > Shigeki Sakamoto. > > > > > > Hi, patch generally looks good. One issue though: how does > > this handle connections using different hypervisors? Say a local > > xen and a remote qemu. Obviously we shouldn't be able to > > migrate between the two but I think this code would allow it. > > > > Maybe have the connection list look something like: > > > > migrate -> hostname1 (qemu) > > -> hostname2 (xen) > > > > If the hypervisors don't match the entry would be disabled. > > > > Also, having the migrate option only available as a right > > click menu item doesn't seem too transparent. Maybe also > > list it as an option under the 'Virtual Machine' menu > > in the individual VM view. If you go this route, you'll want > > to offload most of the logic to engine.py like is done for > > shutdown, pause, etc. > > > > > diff -r 270e1697b81a src/virtManager/domain.py > > > --- a/src/virtManager/domain.py Mon Oct 06 13:21:06 2008 -0400 > > > +++ b/src/virtManager/domain.py Wed Oct 08 16:38:05 2008 +0900 > > > @@ -972,4 +972,10 @@ class vmmDomain(gobject.GObject): > > > # Invalidate cached xml > > > self.xml = None > > > > > > + def migrate(self, dictcon): > > > + flags = 0 > > > + if self.lastStatus == libvirt.VIR_DOMAIN_RUNNING: > > > + flags = libvirt.VIR_MIGRATE_LIVE > > > + self.vm.migrate(self.connection.vmm, flags, None, > > > dictcon.get_short_hostname(), 0) > > > + > > > gobject.type_register(vmmDomain) > > > diff -r 270e1697b81a src/virtManager/engine.py > > > --- a/src/virtManager/engine.py Mon Oct 06 13:21:06 2008 -0400 > > > +++ b/src/virtManager/engine.py Wed Oct 08 16:38:05 2008 +0900 > > > @@ -202,6 +202,8 @@ class vmmEngine(gobject.GObject): > > > self.shutdown_domain(src, uri, uuid) > > > def _do_reboot_domain(self, src, uri, uuid): > > > self.reboot_domain(src, uri, uuid) > > > + def _do_migrate_domain(self, src, uri, uuid, desturi): > > > + self.migrate_domain(uri, uuid, desturi) > > > def _do_exit_app(self, src): > > > self.exit_app() > > > > > > @@ -296,6 +298,7 @@ class vmmEngine(gobject.GObject): > > > self.windowManager.connect("action-shutdown-domain", > > > self._do_shutdown_domain) > > > self.windowManager.connect("action-reboot-domain", > > > self._do_reboot_domain) > > > self.windowManager.connect("action-destroy-domain", > > > self._do_destroy_domain) > > > + self.windowManager.connect("action-migrate-domain", > > > self._do_migrate_domain) > > > self.windowManager.connect("action-show-console", > > > self._do_show_console) > > > self.windowManager.connect("action-show-details", > > > self._do_show_details) > > > self.windowManager.connect("action-show-preferences", > > > self._do_show_preferences) > > > @@ -528,6 +531,39 @@ class vmmEngine(gobject.GObject): > > > else: > > > logging.warning("Reboot requested, but machine is already > > > shutting down / shutoff") > > > > > > + def migrate_domain(self, uri, uuid, desturi): > > > + conn = self.get_connection(uri, False) > > > + vm = conn.get_vm(uuid) > > > + destconn = self.get_connection(desturi, False) > > > + migrate_progress = None > > > + try: > > > + # show progress dialog > > > + migrate_progress = > > > self.get_migrate_progress(vm.get_name(), conn.get_short_hostname(), > > > destconn.get_short_hostname()) > > > + migrate_progress.show() > > > + while gtk.events_pending(): > > > + gtk.main_iteration() > > > + # call virDomainMigrate > > > + vm.migrate(destconn) > > > + # close progress dialog > > > + migrate_progress.destroy() > > > + except Exception, e: > > > + migrate_progress.destroy() > > > + self.err.show_err(_("Error migrating domain: %s") % str(e), > > > + "".join(traceback.format_exc())) > > > + > > > + self.windowManager.conn_refresh_resources(conn) > > > + self.windowManager.conn_refresh_resources(destconn) > > > + > > > + def get_migrate_progress(self, vmname, hostname, desthostname): > > > + migrate_progress = None > > > + migrate_progress = gtk.MessageDialog(None, \ > > > + > > > gtk.DIALOG_DESTROY_WITH_PARENT, \ > > > + gtk.MESSAGE_INFO, \ > > > + gtk.BUTTONS_NONE, \ > > > + _("%s is migrating from > > > %s to %s." % \ > > > + (vmname, hostname, > > > desthostname))) > > > + migrate_progress.set_title(" ") > > > + return migrate_progress > > > > > > > > > gobject.type_register(vmmEngine) > > > diff -r 270e1697b81a src/virtManager/manager.py > > > --- a/src/virtManager/manager.py Mon Oct 06 13:21:06 2008 -0400 > > > +++ b/src/virtManager/manager.py Wed Oct 08 16:38:05 2008 +0900 > > > @@ -101,6 +101,8 @@ class vmmManager(gobject.GObject): > > > gobject.TYPE_NONE, [str]), > > > "action-show-help": (gobject.SIGNAL_RUN_FIRST, > > > gobject.TYPE_NONE, [str]), > > > + "action-migrate-domain": (gobject.SIGNAL_RUN_FIRST, > > > + gobject.TYPE_NONE, (str,str,str)), > > > "action-exit-app": (gobject.SIGNAL_RUN_FIRST, > > > gobject.TYPE_NONE, []),} > > > > > > @@ -154,6 +156,8 @@ class vmmManager(gobject.GObject): > > > self.vmmenushutdown = gtk.Menu() > > > self.vmmenu_items = {} > > > self.vmmenushutdown_items = {} > > > + self.vmmenumigrate = gtk.Menu() > > > + self.vmmenumigrate_items = {} > > > > > > self.vmmenu_items["run"] = gtk.ImageMenuItem("_Run") > > > self.vmmenu_items["run"].set_image(self.vmmenu_icons["run"]) > > > @@ -198,9 +202,23 @@ class vmmManager(gobject.GObject): > > > > > > self.vmmenushutdown_items["forcepoweroff"].connect("activate", > > > self.destroy_vm) > > > > > > self.vmmenushutdown.add(self.vmmenushutdown_items["forcepoweroff"]) > > > > > > - self.vmmenu_items["hsep"] = gtk.SeparatorMenuItem() > > > - self.vmmenu_items["hsep"].show(); > > > - self.vmmenu.add(self.vmmenu_items["hsep"]) > > > + self.vmmenu_items["hsep1"] = gtk.SeparatorMenuItem() > > > + self.vmmenu_items["hsep1"].show(); > > > + self.vmmenu.add(self.vmmenu_items["hsep1"]) > > > + > > > + self.vmmenu_items["migrate"] = gtk.ImageMenuItem("_Migrate") > > > + self.vmmenu_items["migrate"].set_submenu(self.vmmenumigrate) > > > + self.vmmenu_items["migrate"].show() > > > + self.vmmenu.add(self.vmmenu_items["migrate"]) > > > + > > > + self.vmmenumigrate_items["(None)"] = > > > gtk.ImageMenuItem(_("(None)")) > > > + self.vmmenumigrate_items["(None)"].show() > > > + self.vmmenumigrate_items["(None)"].set_sensitive(False) > > > + self.vmmenumigrate.add(self.vmmenumigrate_items["(None)"]) > > > + > > > + self.vmmenu_items["hsep2"] = gtk.SeparatorMenuItem() > > > + self.vmmenu_items["hsep2"].show(); > > > + self.vmmenu.add(self.vmmenu_items["hsep2"]) > > > > > > self.vmmenu_items["open"] = gtk.ImageMenuItem(gtk.STOCK_OPEN) > > > self.vmmenu_items["open"].connect("activate", > > > self.open_vm_console) > > > @@ -698,6 +716,7 @@ class vmmManager(gobject.GObject): > > > self.vmmenu_items["resume"].hide() > > > self.vmmenu_items["resume"].set_sensitive(False) > > > self.vmmenu_items["shutdown"].set_sensitive(False) > > > + self.vmmenu_items["migrate"].set_sensitive(False) > > > else: > > > if vm.status() == libvirt.VIR_DOMAIN_SHUTOFF: > > > self.vmmenu_items["run"].set_sensitive(True) > > > @@ -706,6 +725,8 @@ class vmmManager(gobject.GObject): > > > self.vmmenu_items["resume"].hide() > > > self.vmmenu_items["resume"].set_sensitive(False) > > > > > > self.vmmenu_items["shutdown"].set_sensitive(False) > > > + self.vmmenu_items["migrate"].set_sensitive(True) > > > + self.set_migrate_submenu() > > > elif vm.status() == libvirt.VIR_DOMAIN_RUNNING: > > > self.vmmenu_items["run"].set_sensitive(False) > > > self.vmmenu_items["pause"].set_sensitive(True) > > > @@ -713,6 +734,8 @@ class vmmManager(gobject.GObject): > > > self.vmmenu_items["resume"].hide() > > > self.vmmenu_items["resume"].set_sensitive(False) > > > self.vmmenu_items["shutdown"].set_sensitive(True) > > > + self.vmmenu_items["migrate"].set_sensitive(True) > > > + self.set_migrate_submenu() > > > elif vm.status() == libvirt.VIR_DOMAIN_PAUSED: > > > self.vmmenu_items["run"].set_sensitive(False) > > > self.vmmenu_items["pause"].hide() > > > @@ -720,6 +743,8 @@ class vmmManager(gobject.GObject): > > > self.vmmenu_items["resume"].show() > > > self.vmmenu_items["resume"].set_sensitive(True) > > > self.vmmenu_items["shutdown"].set_sensitive(True) > > > + self.vmmenu_items["migrate"].set_sensitive(True) > > > + self.set_migrate_submenu() > > > self.vmmenu.popup(None, None, None, 0, event.time) > > > return False > > > else: > > > @@ -1007,6 +1032,53 @@ class vmmManager(gobject.GObject): > > > if vm is not None: > > > self.emit("action-resume-domain", > > > vm.get_connection().get_uri(), vm.get_uuid()) > > > > > > + def migrate(self, ignore): > > > + vm = self.current_vm() > > > + # get selected submenu(destination hostname) > > > + hostname = > > > self.vmmenumigrate.get_active().get_image().get_stock()[0] > > > + for key in self.engine.connections.keys(): > > > + if self.engine.get_connection(key).get_hostname() == > > > hostname: > > > + host_uri = key > > > + break > > > + if vm is not None: > > > + result = self.err.yes_no(_("%s is migrated from %s to %s, > > > are you sure?") % \ > > > > Change "is migrated from" to "will be migrated from" > > > > The rest looks fine. > > > > Thanks, > > Cole > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From arayamajhi at unmc.edu Fri Oct 24 16:03:27 2008 From: arayamajhi at unmc.edu (Atul Rayamajhi) Date: Fri, 24 Oct 2008 11:03:27 -0500 Subject: [et-mgmt-tools] Atul Rayamajhi/ITS/UNMC/UNEBR is out of the office. Message-ID: I will be out of the office starting 10/24/2008 and will not return until 10/27/2008. I will respond to your message when I return. If you have any question please contact Joe Ziskovsky at jziskovs at unmc.edu. From crobinso at redhat.com Tue Oct 28 15:25:18 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 28 Oct 2008 11:25:18 -0400 Subject: [et-mgmt-tools] Re: [PATCH][RFC](take2)Add "Migrate" to VirtualMachine-menu in the individual VM view In-Reply-To: <200810241729.BEB29711.0GE9KJ69@aa.jp.fujitsu.com> References: <20080919100727.GM18194@redhat.com> <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> <48F7581C.4040203@redhat.com> <200810201744.HHD43727.6G9JKE09@aa.jp.fujitsu.com> <200810241729.BEB29711.0GE9KJ69@aa.jp.fujitsu.com> Message-ID: <49072EDE.2030406@redhat.com> S.Sakamoto wrote: > Hi, Cole > > I cleared all the problems about your comment. > I show the following the summary of this patch > and a problem about doing "Migrate" from individual VM view. > Hi, I've been playing with the previous round a bit more and wanted to take a look at this version, but it doesn't look like the patch was attached. > [Summary] > 1. Move the logic that get available host from manager.py to engnine.py. > > 2. Don't show a host of the different hypervisor in available host list. > > 3. Change the message from "is migrated from" to "will be migrated from". > > 4. Add "Migrate" to VirtualMachine-menu in the individual VM view. > > VirtualMachine > | > +- Run > Pause > Shutdown > Save > --------------- > Migrate ----> host1.example.com > --------------- host2.example.com > Take Screenshot host3.example.com > > [Problem] > After I do "Migrate" from the individual VM view, > the view shows a information of the VM on not destination host. > But, I think that the view should show a information of the VM > on destination host. > > How about this problem? > Hmm, I think I understand what you mean. I'd probably need to play with the code though to determine what the best solution might be, though it may be that we will just commit this and address it later. Thanks, Cole From fj0588di at aa.jp.fujitsu.com Thu Oct 30 00:21:53 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Thu, 30 Oct 2008 09:21:53 +0900 Subject: [et-mgmt-tools] Re: [PATCH][RFC](take2)Add "Migrate" to VirtualMachine-menu in theindividual VM view In-Reply-To: <49072EDE.2030406@redhat.com> References: <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> <48F7581C.4040203@redhat.com> <200810201744.HHD43727.6G9JKE09@aa.jp.fujitsu.com> <200810241729.BEB29711.0GE9KJ69@aa.jp.fujitsu.com> <49072EDE.2030406@redhat.com> Message-ID: <200810300921.BFH86975.60G9EJ9K@aa.jp.fujitsu.com> > > I cleared all the problems about your comment. > > I show the following the summary of this patch > > and a problem about doing "Migrate" from individual VM view. > > I'm sorry, forgot to attach the patch. Thanks, Sakamoto Shigeki. > > Hi, I've been playing with the previous round a bit more > and wanted to take a look at this version, but it doesn't > look like the patch was attached. > > > [Summary] > > 1. Move the logic that get available host from manager.py to engnine.py. > > > > 2. Don't show a host of the different hypervisor in available host list. > > > > 3. Change the message from "is migrated from" to "will be migrated from". > > > > 4. Add "Migrate" to VirtualMachine-menu in the individual VM view. > > > > VirtualMachine > > | > > +- Run > > Pause > > Shutdown > > Save > > --------------- > > Migrate ----> host1.example.com > > --------------- host2.example.com > > Take Screenshot host3.example.com > > > > [Problem] > > After I do "Migrate" from the individual VM view, > > the view shows a information of the VM on not destination host. > > But, I think that the view should show a information of the VM > > on destination host. > > > > How about this problem? > > > > Hmm, I think I understand what you mean. I'd probably need to > play with the code though to determine what the best solution > might be, though it may be that we will just commit this and > address it later. > > Thanks, > Cole > -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager_migrate.patch Type: application/octet-stream Size: 16480 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 30 12:54:21 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 30 Oct 2008 13:54:21 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst: fix --disk option parsing error message Message-ID: <20081030125421.GA22779@bogon.ms20.nix> Hi, the description is far longer than the patch: ERROR not all arguments converted during string formatting Traceback (most recent call last): File "./virt-install", line 715, in main() File "./virt-install", line 572, in main options.sparse, options.nodisks, guest, hvm, conn) File "./virt-install", line 243, in get_disks is_file_path), disk, size) File "./virt-install", line 243, in is_file_path), disk, size) File "./virt-install", line 188, in get_disk size, sparse) = parse_disk_option(guest, disk, size) File "./virt-install", line 139, in parse_disk_option fail(_("Unknown --disk option '%s'." % opt)) TypeError: not all arguments converted during string formatting Attached patch makes sure the tuple opt is converted to a string: ERROR Unknown --disk option '('device', 'disk')'. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-disk-error-msg.diff Type: text/x-diff Size: 841 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 30 12:56:28 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 30 Oct 2008 13:56:28 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst: unbreak --disk device suboption Message-ID: <20081030125627.GA22947@bogon.ms20.nix> Hi, the bus= suboption patch broke disk=. This fixes it. -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: unbreak-disk-device-option.diff Type: text/x-diff Size: 680 bytes Desc: not available URL: From agx at sigxcpu.org Thu Oct 30 14:51:26 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 30 Oct 2008 15:51:26 +0100 Subject: [et-mgmt-tools] [PATCH] virtinst: support Debian paravirt installs Message-ID: <20081030145126.GA26705@bogon.ms20.nix> Hi, attached patch adds support for Debian paravirt Xen installs. It also adds support for 'http://people.debian.org/~joeyh/d-i/' which is the location for debian-installer daily builds but has slightly different layout (images/daily instead of current/images). Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: debian-pvm-support.diff Type: text/x-diff Size: 3094 bytes Desc: not available URL: From pradhanparas at gmail.com Thu Oct 30 17:46:45 2008 From: pradhanparas at gmail.com (Paras pradhan) Date: Thu, 30 Oct 2008 12:46:45 -0500 Subject: [et-mgmt-tools] partitions Message-ID: <8b711df40810301046w57d26074n9ec242f12df1dd9d@mail.gmail.com> hi all, I have a centos 5.2 server which has 3 partitions. Part1: / (30GB) Part2: swap (1GB) Part3: unused (229GB) I want to convert this physical machine to virtual machine but I don't need the third partition. Is it possible to exclude the 3rd partition? The Text UI can only transfer the whole single as a sda block. Any possibility? Thanks Paras. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Thu Oct 30 21:18:30 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 30 Oct 2008 17:18:30 -0400 Subject: [et-mgmt-tools] Re: [PATCH][RFC](take2)Add "Migrate" to VirtualMachine-menu in the individual VM view In-Reply-To: <200810241729.BEB29711.0GE9KJ69@aa.jp.fujitsu.com> References: <20080919100727.GM18194@redhat.com> <200810011848.IBC65664.JEK906G9@aa.jp.fujitsu.com> <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> <48F7581C.4040203@redhat.com> <200810201744.HHD43727.6G9JKE09@aa.jp.fujitsu.com> <200810241729.BEB29711.0GE9KJ69@aa.jp.fujitsu.com> Message-ID: <490A24A6.4010307@redhat.com> S.Sakamoto wrote: > Hi, Cole > > I cleared all the problems about your comment. > I show the following the summary of this patch > and a problem about doing "Migrate" from individual VM view. > Okay, this looks good, I've committed this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=f47cf079e311 Though I had a few more small issues with the code. I worked up a patch (attached) that fixes them. There was a bug when trying to migrate from the manager view: the migrate connection list won't update correctly if clicking around between different VM's on different connections. The fix was just to populate the migrate menu on demand, rather than when a new VM was selected. The other change was to actually list unusable connections in the migrate list, but have them as inactive list entries: http://fedorapeople.org/~crobinso/virt-manager/virt-manager-migrate.png The disabled list entries also have tooltips which explain why they are disabled. I think this will be more clear to users if there are invalid connections. Do you think this is an okay change? Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-migrate-fixes.patch Type: text/x-patch Size: 9337 bytes Desc: not available URL: From crobinso at redhat.com Thu Oct 30 21:18:38 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 30 Oct 2008 17:18:38 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst: fix --disk option parsing error message In-Reply-To: <20081030125421.GA22779@bogon.ms20.nix> References: <20081030125421.GA22779@bogon.ms20.nix> Message-ID: <490A24AE.6010102@redhat.com> Guido G?nther wrote: > Hi, > the description is far longer than the patch: > > ERROR not all arguments converted during string formatting > Traceback (most recent call last): > File "./virt-install", line 715, in > main() > File "./virt-install", line 572, in main > options.sparse, options.nodisks, guest, hvm, conn) > File "./virt-install", line 243, in get_disks > is_file_path), disk, size) > File "./virt-install", line 243, in > is_file_path), disk, size) > File "./virt-install", line 188, in get_disk > size, sparse) = parse_disk_option(guest, disk, size) > File "./virt-install", line 139, in parse_disk_option > fail(_("Unknown --disk option '%s'." % opt)) > TypeError: not all arguments converted during string formatting > > Attached patch makes sure the tuple opt is converted to a string: > > ERROR Unknown --disk option '('device', 'disk')'. > > -- Guido > Applied, thanks: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=fef7dd673020 - Cole From crobinso at redhat.com Thu Oct 30 21:19:31 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 30 Oct 2008 17:19:31 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst: unbreak --disk device suboption In-Reply-To: <20081030125627.GA22947@bogon.ms20.nix> References: <20081030125627.GA22947@bogon.ms20.nix> Message-ID: <490A24E3.7000201@redhat.com> Guido G?nther wrote: > Hi, > the bus= suboption patch broke disk=. This fixes it. > -- Guido > Applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=54ab0d67a045 Thanks, Cole From crobinso at redhat.com Thu Oct 30 21:20:04 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 30 Oct 2008 17:20:04 -0400 Subject: [et-mgmt-tools] [PATCH] virtinst: support Debian paravirt installs In-Reply-To: <20081030145126.GA26705@bogon.ms20.nix> References: <20081030145126.GA26705@bogon.ms20.nix> Message-ID: <490A2504.6050902@redhat.com> Guido G?nther wrote: > Hi, > attached patch adds support for Debian paravirt Xen installs. It also > adds support for 'http://people.debian.org/~joeyh/d-i/' which is the > location for debian-installer daily builds but has slightly different > layout (images/daily instead of current/images). > Cheers, > -- Guido > Cool! Applied: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=285a112054ff Thanks, Cole From fj0588di at aa.jp.fujitsu.com Fri Oct 31 01:29:38 2008 From: fj0588di at aa.jp.fujitsu.com (S.Sakamoto) Date: Fri, 31 Oct 2008 10:29:38 +0900 Subject: [et-mgmt-tools] Re: [PATCH][RFC](take2)Add "Migrate" to VirtualMachine-menu in theindividual VM view In-Reply-To: <490A24A6.4010307@redhat.com> References: <200810091810.EAJ00006.K96JG09E@aa.jp.fujitsu.com> <48F7581C.4040203@redhat.com> <200810201744.HHD43727.6G9JKE09@aa.jp.fujitsu.com> <200810241729.BEB29711.0GE9KJ69@aa.jp.fujitsu.com> <490A24A6.4010307@redhat.com> Message-ID: <200810311029.GFC30265.0GJ9E9K6@aa.jp.fujitsu.com> > S.Sakamoto wrote: > > Hi, Cole > > > > I cleared all the problems about your comment. > > I show the following the summary of this patch > > and a problem about doing "Migrate" from individual VM view. > > > > Okay, this looks good, I've committed this: > > http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=f47cf079e311 > > Though I had a few more small issues with the code. I > worked up a patch (attached) that fixes them. > > There was a bug when trying to migrate from the manager > view: the migrate connection list won't update correctly > if clicking around between different VM's on different > connections. The fix was just to populate the migrate > menu on demand, rather than when a new VM was selected. > > The other change was to actually list unusable connections > in the migrate list, but have them as inactive list entries: > > http://fedorapeople.org/~crobinso/virt-manager/virt-manager-migrate.png > > The disabled list entries also have tooltips which explain > why they are disabled. I think this will be more clear to > users if there are invalid connections. > > Do you think this is an okay change? Yes, okay! Thanks, Shigeki Sakamoto. From FCOMBERNOUS at ares.fr Fri Oct 31 10:12:09 2008 From: FCOMBERNOUS at ares.fr (FCOMBERNOUS at ares.fr) Date: Fri, 31 Oct 2008 11:12:09 +0100 Subject: [et-mgmt-tools] using virtinstall--devel and bus type option. Message-ID: Lo, As indicated i get the source with mercurial : hg clone http://hg.et.redhat.com/virt/applications/virtinst--devel After this i read the INSTALL file, so i used the command : python setup.py install All looks to be ok. But, when i use virt-install, i don't have acces to the new options about disk. The new syntax permit to choose bus type for device. When i have a look in the pod file this option "--disk opt1=val1,opt2=val2,..." is indicated, but in the man it is not. And virt-install doesn't use the new syntax. And the tool virt-install doesn't know the new syntax. However, when i read the source code of virt-install, if i compare with diff [1], it looks to do the job as wished (new syntax). I'm lost. what did i missed ? -- Fabien?COMBERNOUS IT?Engineer,?Open?source?specialist http://www.ares.fr **************************************************************************************************** Ce message ou ses pi?ces jointes peuvent contenir des informations confidentielles ? l'intention exclusive de son destinataire et est couvert par le secret professionnel. Toute utilisation, divulgation ou reproduction de son contenu sont strictement interdits. Si vous avez re?u ce message par erreur, merci de le notifier ? son exp?diteur et d'en d?truire toute copie. Le pr?sent message pouvant ?tre alt?r? ? notre insu, le groupe ARES ne peut pas ?tre engag? par son contenu. www.ares.fr **************************************************************************************************** From FCOMBERNOUS at ares.fr Fri Oct 31 10:51:27 2008 From: FCOMBERNOUS at ares.fr (FCOMBERNOUS at ares.fr) Date: Fri, 31 Oct 2008 11:51:27 +0100 Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_[et-mgmt-tools]_using_virtinstall--devel_and?= =?ISO-8859-1?Q?_bus_type_option=2E?= In-Reply-To: References: Message-ID: -----et-mgmt-tools-bounces at redhat.com a ?crit : ----- >Pour?:?et-mgmt-tools at redhat.com >De?:?FCOMBERNOUS at ares.fr >Envoy??par?:?et-mgmt-tools-bounces at redhat.com >Date?:?31/10/2008?11:12 >Objet?:?[et-mgmt-tools]?using?virtinstall--devel?and?bus?type?option. [...] > >However, when i read the source code of virt-install, if i compare >with diff?[1],?it?looks?to?do?the?job?as?wished?(new?syntax).?I'm?lost. Forgotten the link : [1] http://www.nabble.com/-PATCH--virt-install:-allow-to-pass-bustype-via---disk-td20030562.html -- Fabien COMBERNOUS IT Engineer, Open source specialist http://www.ares.fr **************************************************************************************************** Ce message ou ses pi?ces jointes peuvent contenir des informations confidentielles ? l'intention exclusive de son destinataire et est couvert par le secret professionnel. Toute utilisation, divulgation ou reproduction de son contenu sont strictement interdits. Si vous avez re?u ce message par erreur, merci de le notifier ? son exp?diteur et d'en d?truire toute copie. Le pr?sent message pouvant ?tre alt?r? ? notre insu, le groupe ARES ne peut pas ?tre engag? par son contenu. www.ares.fr **************************************************************************************************** From crobinso at redhat.com Fri Oct 31 13:36:15 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 31 Oct 2008 09:36:15 -0400 Subject: [et-mgmt-tools] using virtinstall--devel and bus type option. In-Reply-To: References: Message-ID: <490B09CF.3060409@redhat.com> FCOMBERNOUS at ares.fr wrote: > Lo, > > As indicated i get the source with mercurial : > hg clone http://hg.et.redhat.com/virt/applications/virtinst--devel > When did you clone the repo? Just yesterday I committed a few more patches from Guido that fixed up some of the code to do with the 'bus' option, so you may be running in to issues that have been fixed. Try: cd virtinst--devel hg pull hg update python setup.py install Then see if the bus option isn't working. If not, report back here. > After this i read the INSTALL file, so i used the command : > python setup.py install > > All looks to be ok. > > But, when i use virt-install, i don't have acces to the new options about > disk. The new syntax permit to choose bus type for device. > > When i have a look in the pod file this option "--disk > opt1=val1,opt2=val2,..." is indicated, but in the man it is not. > And virt-install doesn't use the new syntax. And the tool virt-install > doesn't know the new syntax. The man page is generated from the pod file, but it hasn't been refreshed to sync up yet. The pod file is the correct version. Thanks, Cole From crobinso at redhat.com Fri Oct 31 14:49:45 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 31 Oct 2008 10:49:45 -0400 Subject: [et-mgmt-tools] ATTN: Now using glade3 for virt-manager GUI development Message-ID: <490B1B09.6000900@redhat.com> Hi all, I just committed a change to virt-manager that moves all the glade xml files to glade-3 format: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=8369921a3e13 glade-2 and glade-3 actually use the same format so they are compatible, but glade-3 is a complete rewrite and generates much different xml (and cleaner: the reformatting removed almost 8000 lines). glade-2 has been dead for what looks like 3 years, and glade-3 has nice features, like an actual 'Undo' option! So, going forward, please use glade-3 for all virt-manager GUI development. Thanks, Cole From ab at stollmann.de Fri Oct 31 15:28:30 2008 From: ab at stollmann.de (Arne Bernin) Date: Fri, 31 Oct 2008 16:28:30 +0100 Subject: [et-mgmt-tools] virt-manager Problem with german keyboard (AltGr) and builtin vnc client Message-ID: <20081031152830.19582.qmail@bux.stollmann.net> Hi all! I have a little problem getting virt-manager (0.6) running with my german keyboard layout. I am able to get all chars correctly, without those that require an AltGr (@ and | which is really nasty). I also had an issue with kvm (which i am using for virtual machines), but found a patch to fix this behaviour. Now, while the vnc server seems to work correctly, it is only working with external vncviwer like realvnc or tightvnc, not with the internal one used by virt-manager (which seems to be based on libgtk-vnc). So i am wondering, where is the correct place to get this fixed ? Thanks and best regards, Arne Bernin -- ------------------------------------------------------------------- Arne Bernin Tel: +49 40 890 88 433 Fax: +49 40 890 88 444 mailto:ab at stollmann.de http://www.stollmann.de Stollmann E+V GmbH, Mendelssohnstr. 15D, D-22761 Hamburg, Germany HRB Hamburg 55634, VAT-ID DE 811 675 541 GF: Peter Herrmann, Christian L?hrs ------------------------------------------------------------- If it's ISDN, Bluetooth, GPRS or NFC make sure it's driven by Stollmann From crobinso at redhat.com Fri Oct 31 16:28:01 2008 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 31 Oct 2008 12:28:01 -0400 Subject: [et-mgmt-tools] virt-manager Problem with german keyboard (AltGr) and builtin vnc client In-Reply-To: <20081031152830.19582.qmail@bux.stollmann.net> References: <20081031152830.19582.qmail@bux.stollmann.net> Message-ID: <490B3211.4040404@redhat.com> Arne Bernin wrote: > Hi all! > > I have a little problem getting virt-manager (0.6) running > with my german keyboard layout. I am able to get > all chars correctly, without those that require an > AltGr (@ and | which is really nasty). > > I also had an issue with kvm (which i am using for virtual machines), > but found a patch to fix this behaviour. Now, while the vnc server seems > to work correctly, it is only working with external vncviwer like > realvnc or tightvnc, not with the internal one used by virt-manager > (which seems to be based on libgtk-vnc). > So i am wondering, where is the correct place to get this fixed ? > > Can you paste the output of: virsh dumpxml your-vm-name | grep keymap cat /etc/sysconfig/keyboard Thanks, Cole