From dlbewley at lib.ucdavis.edu Wed Apr 1 06:48:02 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Tue, 31 Mar 2009 23:48:02 -0700 Subject: [et-mgmt-tools] f11 virt release notes freezing Message-ID: <1238568482.29645.68.camel@seitan.home.bewley.net> I've been busy at my day job and not paying close enough attention to Fedora 11 docs deadlines. Apparently the window for changes essentially closes Wednesday (today).[1] The notes are essentially in place. I don't think there are any gaping holes, but I should have prompted for feedback much sooner. If you could apply any love to the release notes[2] it would be appreciated. = QEMU / KVM = It is noted that QEMU and KVM are merging as a package, but I've also separately listed the fact that QEMU is now 0.10.0 and KVM is now 84. With the merge, might it be confusing or inaccurate to mention a distinct new version of KVM? I'll admit to being somewhat fuzzy on where/how that line is drawn. I see[3] QEMU 0.10.0 in rawhide, but not 0.10.1, so I adjusted the version in the relnotes. I copied the feature list from the 0.10.0 release announcement. If you'd care to suggest deletes or enhancements of the list please do. The KVM changelog since 74 (version at initial F10 release) is quite long and not easily digestible by me at this late hour. Would anyone care to offer some highlights or fill them into the wiki? Or, again, should those be folded into QEMU? = Libvirt = I previously copied the list of changes from the releases, but did not try to prune them down. It may be fine. = The Current Outline = 1 Virtualization * 1.1 Improved VNC Authentication for Virtual Machine Management * 1.2 Improved Graphical Console for Virtual Machines * 1.3 KVM PCI Device Assignment * 1.4 KVM and QEMU merge * 1.5 SVirt Mandatory Access Control * 1.6 Other Improvements * 1.6.1 QEMU Updated to 0.10.0 * 1.6.2 KVM Updated to 84 * 1.6.3 libvirt Updated to 0.6.1 * 1.6.4 virt-manager Updated to 0.7.0 * 1.6.5 virtinst Updated to 0.400.3 * 1.6.6 Xen Updated to 3.3.1 * 1.7 Xen Kernel Support Thanks for any edits or suggestions you can offer. [1] http://www.redhat.com/archives/fedora-docs-list/2009-March/msg00232.html [2] http://fedoraproject.org/wiki/Documentation_Virtualization_Beat [3] http://fedoraproject.org/wiki/User:Dale#Packages From berrange at redhat.com Wed Apr 1 09:21:10 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Apr 2009 10:21:10 +0100 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <49D279F0.7080607@redhat.com> References: <49D279F0.7080607@redhat.com> Message-ID: <20090401092110.GC29404@redhat.com> On Tue, Mar 31, 2009 at 04:15:44PM -0400, Michael DeHaan wrote: > I'm working on adding scripted Windows install support (ISO + answer > file on floppy) support to koan. > > I'm getting the following when trying to attach a floppy image. > > > ======================= > > Here's the error: > > libvir: QEMU error : Domain not found > libvir: QEMU error : Domain not found > libvir: Domain Config error : internal error Invalid floppy device name: hda > This is the core issue - you're giving the floppy a harddisk name > internal error Invalid floppy device name: hda > > > > This should be > > > guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, > path=floppy_path)) I think you'll need to at least give a device name. libvirt fills in the bus, based on device name if you leave it out Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Wed Apr 1 16:14:49 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 01 Apr 2009 12:14:49 -0400 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <20090401092110.GC29404@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> Message-ID: <49D392F9.5040504@redhat.com> > This is the core issue - you're giving the floppy a harddisk name > Yeah, I caught that :) >> >> guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, >> path=floppy_path)) >> > > I think you'll need to at least give a device name. > > libvirt fills in the bus, based on device name if you leave it out > The constructor signature for VirtualDisk is... __init__(self, path=None, size=None, transient=False, type=None, device='dis k', driverName=None, driverType=None, readOnly=False, sparse=True, conn=None, vo lObject=None, volInstall=None, volName=None, bus=None) Which field would I use for specifying the device name? Thanks! --Michael From berrange at redhat.com Wed Apr 1 16:25:39 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Apr 2009 17:25:39 +0100 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <49D392F9.5040504@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> <49D392F9.5040504@redhat.com> Message-ID: <20090401162539.GT22771@redhat.com> On Wed, Apr 01, 2009 at 12:14:49PM -0400, Michael DeHaan wrote: > > >This is the core issue - you're giving the floppy a harddisk name > > > > Yeah, I caught that :) > > >> > >>guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, > >>path=floppy_path)) > >> > > > >I think you'll need to at least give a device name. > > > >libvirt fills in the bus, based on device name if you leave it out > > > > The constructor signature for VirtualDisk is... > > __init__(self, path=None, size=None, transient=False, type=None, device='dis > k', driverName=None, driverType=None, readOnly=False, sparse=True, > conn=None, vo > lObject=None, volInstall=None, volName=None, bus=None) > > Which field would I use for specifying the device name? Just set device=VirtualDisk.DEVICE_FLOPPY and virtinst generated the device name Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Wed Apr 1 16:25:58 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 01 Apr 2009 12:25:58 -0400 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <20090401162539.GT22771@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> <49D392F9.5040504@redhat.com> <20090401162539.GT22771@redhat.com> Message-ID: <49D39596.2040202@redhat.com> Daniel P. Berrange wrote: > On Wed, Apr 01, 2009 at 12:14:49PM -0400, Michael DeHaan wrote: > >>> This is the core issue - you're giving the floppy a harddisk name >>> >>> >> Yeah, I caught that :) >> >> >>>> guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, >>>> path=floppy_path)) >>>> >>>> >>> I think you'll need to at least give a device name. >>> >>> libvirt fills in the bus, based on device name if you leave it out >>> >>> >> The constructor signature for VirtualDisk is... >> >> __init__(self, path=None, size=None, transient=False, type=None, device='dis >> k', driverName=None, driverType=None, readOnly=False, sparse=True, >> conn=None, vo >> lObject=None, volInstall=None, volName=None, bus=None) >> >> Which field would I use for specifying the device name? >> > > Just set > > device=VirtualDisk.DEVICE_FLOPPY > > and virtinst generated the device name > > Daniel > Scroll up a bit for my Python line I'm using, I did that :) Seems like a bug in virtinst then. I'll write it up. --Michael From crobinso at redhat.com Wed Apr 1 19:22:51 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 01 Apr 2009 15:22:51 -0400 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <49D39596.2040202@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> <49D392F9.5040504@redhat.com> <20090401162539.GT22771@redhat.com> <49D39596.2040202@redhat.com> Message-ID: <49D3BF0B.6000203@redhat.com> Michael DeHaan wrote: > Daniel P. Berrange wrote: >> On Wed, Apr 01, 2009 at 12:14:49PM -0400, Michael DeHaan wrote: >> >>>> This is the core issue - you're giving the floppy a harddisk name >>>> >>>> >>> Yeah, I caught that :) >>> >>> >>>>> guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, >>>>> path=floppy_path)) >>>>> >>>>> >>>> I think you'll need to at least give a device name. >>>> >>>> libvirt fills in the bus, based on device name if you leave it out >>>> >>>> >>> The constructor signature for VirtualDisk is... >>> >>> __init__(self, path=None, size=None, transient=False, type=None, device='dis >>> k', driverName=None, driverType=None, readOnly=False, sparse=True, >>> conn=None, vo >>> lObject=None, volInstall=None, volName=None, bus=None) >>> >>> Which field would I use for specifying the device name? >>> >> Just set >> >> device=VirtualDisk.DEVICE_FLOPPY >> >> and virtinst generated the device name >> >> Daniel >> > > Scroll up a bit for my Python line I'm using, I did that :) > > Seems like a bug in virtinst then. I'll write it up. > > --Michael > Actually this may be fixed upstream: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/fd4baa6410d8 Can you try an upstream checkout? Thanks, Cole From mdehaan at redhat.com Wed Apr 1 19:28:58 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 01 Apr 2009 15:28:58 -0400 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <49D3BF0B.6000203@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> <49D392F9.5040504@redhat.com> <20090401162539.GT22771@redhat.com> <49D39596.2040202@redhat.com> <49D3BF0B.6000203@redhat.com> Message-ID: <49D3C07A.8030308@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Daniel P. Berrange wrote: >> >>> On Wed, Apr 01, 2009 at 12:14:49PM -0400, Michael DeHaan wrote: >>> >>> >>>>> This is the core issue - you're giving the floppy a harddisk name >>>>> >>>>> >>>>> >>>> Yeah, I caught that :) >>>> >>>> >>>> >>>>>> guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, >>>>>> path=floppy_path)) >>>>>> >>>>>> >>>>>> >>>>> I think you'll need to at least give a device name. >>>>> >>>>> libvirt fills in the bus, based on device name if you leave it out >>>>> >>>>> >>>>> >>>> The constructor signature for VirtualDisk is... >>>> >>>> __init__(self, path=None, size=None, transient=False, type=None, device='dis >>>> k', driverName=None, driverType=None, readOnly=False, sparse=True, >>>> conn=None, vo >>>> lObject=None, volInstall=None, volName=None, bus=None) >>>> >>>> Which field would I use for specifying the device name? >>>> >>>> >>> Just set >>> >>> device=VirtualDisk.DEVICE_FLOPPY >>> >>> and virtinst generated the device name >>> >>> Daniel >>> >>> >> Scroll up a bit for my Python line I'm using, I did that :) >> >> Seems like a bug in virtinst then. I'll write it up. >> >> --Michael >> >> > > Actually this may be fixed upstream: > > http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/fd4baa6410d8 > > Can you try an upstream checkout? > > Thanks, > Cole > > Great! Absolutely. Do you know when that is on schedule to be backported to F10 and/or EL 5? (Yes, I know F11 is out soon enough, but mainly I'm interested in EL). I typically do that with each release (i.e. upstream bugs get released for all OS's) but wasn't sure what the policy was for virtinst. --Michael From crobinso at redhat.com Wed Apr 1 19:36:59 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 01 Apr 2009 15:36:59 -0400 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <49D3C07A.8030308@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> <49D392F9.5040504@redhat.com> <20090401162539.GT22771@redhat.com> <49D39596.2040202@redhat.com> <49D3BF0B.6000203@redhat.com> <49D3C07A.8030308@redhat.com> Message-ID: <49D3C25B.2090500@redhat.com> Michael DeHaan wrote: > Cole Robinson wrote: >> Michael DeHaan wrote: >> >>> Daniel P. Berrange wrote: >>> >>>> On Wed, Apr 01, 2009 at 12:14:49PM -0400, Michael DeHaan wrote: >>>> >>>> >>>>>> This is the core issue - you're giving the floppy a harddisk name >>>>>> >>>>>> >>>>>> >>>>> Yeah, I caught that :) >>>>> >>>>> >>>>> >>>>>>> guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, >>>>>>> path=floppy_path)) >>>>>>> >>>>>>> >>>>>>> >>>>>> I think you'll need to at least give a device name. >>>>>> >>>>>> libvirt fills in the bus, based on device name if you leave it out >>>>>> >>>>>> >>>>>> >>>>> The constructor signature for VirtualDisk is... >>>>> >>>>> __init__(self, path=None, size=None, transient=False, type=None, device='dis >>>>> k', driverName=None, driverType=None, readOnly=False, sparse=True, >>>>> conn=None, vo >>>>> lObject=None, volInstall=None, volName=None, bus=None) >>>>> >>>>> Which field would I use for specifying the device name? >>>>> >>>>> >>>> Just set >>>> >>>> device=VirtualDisk.DEVICE_FLOPPY >>>> >>>> and virtinst generated the device name >>>> >>>> Daniel >>>> >>>> >>> Scroll up a bit for my Python line I'm using, I did that :) >>> >>> Seems like a bug in virtinst then. I'll write it up. >>> >>> --Michael >>> >>> >> Actually this may be fixed upstream: >> >> http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/fd4baa6410d8 >> >> Can you try an upstream checkout? >> >> Thanks, >> Cole >> >> > > Great! > > Absolutely. > > Do you know when that is on schedule to be backported to F10 and/or EL > 5? (Yes, I know F11 is out soon enough, but mainly I'm > interested in EL). > I still haven't pushed the latest virtinst release to F10, but when I do it will have this fix. For RHEL, as long as a bug is filed I'll pull it in. Thanks, Cole From mdehaan at redhat.com Wed Apr 1 19:44:25 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 01 Apr 2009 15:44:25 -0400 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <49D3C25B.2090500@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> <49D392F9.5040504@redhat.com> <20090401162539.GT22771@redhat.com> <49D39596.2040202@redhat.com> <49D3BF0B.6000203@redhat.com> <49D3C07A.8030308@redhat.com> <49D3C25B.2090500@redhat.com> Message-ID: <49D3C419.1060700@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Cole Robinson wrote: >> >>> Michael DeHaan wrote: >>> >>> >>>> Daniel P. Berrange wrote: >>>> >>>> >>>>> On Wed, Apr 01, 2009 at 12:14:49PM -0400, Michael DeHaan wrote: >>>>> >>>>> >>>>> >>>>>>> This is the core issue - you're giving the floppy a harddisk name >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yeah, I caught that :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, >>>>>>>> path=floppy_path)) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I think you'll need to at least give a device name. >>>>>>> >>>>>>> libvirt fills in the bus, based on device name if you leave it out >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> The constructor signature for VirtualDisk is... >>>>>> >>>>>> __init__(self, path=None, size=None, transient=False, type=None, device='dis >>>>>> k', driverName=None, driverType=None, readOnly=False, sparse=True, >>>>>> conn=None, vo >>>>>> lObject=None, volInstall=None, volName=None, bus=None) >>>>>> >>>>>> Which field would I use for specifying the device name? >>>>>> >>>>>> >>>>>> >>>>> Just set >>>>> >>>>> device=VirtualDisk.DEVICE_FLOPPY >>>>> >>>>> and virtinst generated the device name >>>>> >>>>> Daniel >>>>> >>>>> >>>>> >>>> Scroll up a bit for my Python line I'm using, I did that :) >>>> >>>> Seems like a bug in virtinst then. I'll write it up. >>>> >>>> --Michael >>>> >>>> >>>> >>> Actually this may be fixed upstream: >>> >>> http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/fd4baa6410d8 >>> >>> Can you try an upstream checkout? >>> >>> Thanks, >>> Cole >>> >>> >>> >> Great! >> >> Absolutely. >> >> Do you know when that is on schedule to be backported to F10 and/or EL >> 5? (Yes, I know F11 is out soon enough, but mainly I'm >> interested in EL). >> >> > > I still haven't pushed the latest virtinst release to F10, but when I do > it will have this fix. For RHEL, as long as a bug is filed I'll pull it in. > > Thanks, > Cole > Great, thanks! --Michael From roadrunner_gs at web.de Wed Apr 1 22:59:47 2009 From: roadrunner_gs at web.de (Gerrit Slomma) Date: Thu, 02 Apr 2009 00:59:47 +0200 Subject: [et-mgmt-tools] fix for presenting memory allocation of host and/or vm Message-ID: <49D3F1E3.5060000@web.de> Hello I found the presentation of the memory allocation of host and/or vm annoying, e.g. hosts/vms with more then one GB showed up in virtual-manager with x.yy GBwhereas hosts/vms with less or equal to on GB showed up as xxxx.yy MB. In details of hosts this also showed up. I changed this behavior to showing GB if memory is >10 GB and set MB-presentation to 2.0f. I find it clearer, what is your opinion? --- a/src/virtManager/domain.py 2009-04-01 23:19:28.000000000 +0200 +++ b/src/virtManager/domain.py 2009-04-02 00:28:44.000000000 +0200 @@ -379,7 +379,7 @@ def current_memory_pretty(self): if self.get_id() == -1: - return "0.00 MB" + return "0 MB" return self.get_memory_pretty() @@ -400,10 +400,10 @@ def get_memory_pretty(self): mem = self.get_memory() - if mem > (1024*1024): + if mem > (10*1024*1024): return "%2.2f GB" % (mem/(1024.0*1024.0)) else: - return "%2.2f MB" % (mem/1024.0) + return "%2.0f MB" % (mem/1024.0) def maximum_memory(self): @@ -418,10 +418,10 @@ def maximum_memory_pretty(self): mem = self.maximum_memory() - if mem > (1024*1024): + if mem > (10*1024*1024): return "%2.2f GB" % (mem/(1024.0*1024.0)) else: - return "%2.2f MB" % (mem/1024.0) + return "%2.0f MB" % (mem/1024.0) def cpu_time(self): --- a/src/virtManager/connection.py 2009-04-01 23:19:28.000000000 +0200 +++ b/src/virtManager/connection.py 2009-04-02 00:40:25.000000000 +0200 @@ -686,10 +686,10 @@ if self.vmm is None: return "" mem = self.host_memory_size() - if mem > (1024*1024): + if mem > (10*1024*1024): return "%2.2f GB" % (mem/(1024.0*1024.0)) else: - return "%2.2f MB" % (mem/1024.0) + return "%2.0f MB" % (mem/1024.0) def host_memory_size(self): @@ -1107,10 +1107,10 @@ def pretty_current_memory(self): mem = self.current_memory() - if mem > (1024*1024): + if mem > (10*1024*1024): return "%2.2f GB" % (mem/(1024.0*1024.0)) else: - return "%2.2f MB" % (mem/1024.0) + return "%2.0f MB" % (mem/1024.0) def current_memory_percentage(self): if len(self.record) == 0: From nhappel at redhat.com Fri Apr 3 10:30:04 2009 From: nhappel at redhat.com (Niels Happel) Date: Fri, 3 Apr 2009 12:30:04 +0200 Subject: [et-mgmt-tools] virt-p2v doesnt find cciss devices Message-ID: <200904031230.04763.nhappel@redhat.com> Hi, it looks like virt-p2v is not able to find /dev/cciss/c0d* as devices for hard- drives and only looks for devices residing directly at /dev/ - did somebody else had the same experience while having HP hardware raid controllers ? Cheers, Niels -- Niels Happel Red Hat GmbH From mdehaan at redhat.com Fri Apr 3 18:28:56 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 03 Apr 2009 14:28:56 -0400 Subject: [et-mgmt-tools] virtinst ... proper API way to add a floppy drive? In-Reply-To: <49D3C25B.2090500@redhat.com> References: <49D279F0.7080607@redhat.com> <20090401092110.GC29404@redhat.com> <49D392F9.5040504@redhat.com> <20090401162539.GT22771@redhat.com> <49D39596.2040202@redhat.com> <49D3BF0B.6000203@redhat.com> <49D3C07A.8030308@redhat.com> <49D3C25B.2090500@redhat.com> Message-ID: <49D65568.9010002@redhat.com> Cole Robinson wrote: > Michael DeHaan wrote: > >> Cole Robinson wrote: >> >>> Michael DeHaan wrote: >>> >>> >>>> Daniel P. Berrange wrote: >>>> >>>> >>>>> On Wed, Apr 01, 2009 at 12:14:49PM -0400, Michael DeHaan wrote: >>>>> >>>>> >>>>> >>>>>>> This is the core issue - you're giving the floppy a harddisk name >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yeah, I caught that :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> guest.disks.append(virtinst.VirtualDisk(device=virtinst.VirtualDisk.DEVICE_FLOPPY, >>>>>>>> path=floppy_path)) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I think you'll need to at least give a device name. >>>>>>> >>>>>>> libvirt fills in the bus, based on device name if you leave it out >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> The constructor signature for VirtualDisk is... >>>>>> >>>>>> __init__(self, path=None, size=None, transient=False, type=None, device='dis >>>>>> k', driverName=None, driverType=None, readOnly=False, sparse=True, >>>>>> conn=None, vo >>>>>> lObject=None, volInstall=None, volName=None, bus=None) >>>>>> >>>>>> Which field would I use for specifying the device name? >>>>>> >>>>>> >>>>>> >>>>> Just set >>>>> >>>>> device=VirtualDisk.DEVICE_FLOPPY >>>>> >>>>> and virtinst generated the device name >>>>> >>>>> Daniel >>>>> >>>>> >>>>> >>>> Scroll up a bit for my Python line I'm using, I did that :) >>>> >>>> Seems like a bug in virtinst then. I'll write it up. >>>> >>>> --Michael >>>> >>>> >>>> >>> Actually this may be fixed upstream: >>> >>> http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/fd4baa6410d8 >>> >>> Can you try an upstream checkout? >>> >>> Thanks, >>> Cole >>> >>> >>> >> Great! >> >> Absolutely. >> >> Do you know when that is on schedule to be backported to F10 and/or EL >> 5? (Yes, I know F11 is out soon enough, but mainly I'm >> interested in EL). >> >> > > I still haven't pushed the latest virtinst release to F10, but when I do > it will have this fix. For RHEL, as long as a bug is filed I'll pull it in. > > Thanks, > Cole > Floppy drive addition works. So, one remaining Virt Manager problem exists (also in virt-inst, as I use it, but easily reproducible in virt-manager in rawhide, even with upgraded virtinst libraries) I still get the problem where almost immediately (right after "Windows is loading files") into install I get "Windows Boot Manager" Windows has encountered a problem communicating with a devic econnected to your computer ... this erro can be caused by unplugging a removable storage device ... Status: 0xc000000e9 Info: An unexpected I/O error occurred. This happens when I use an ISO location like /opt/images/win2008.iso, but not when I use the an ISO inserted as a CDROM. I selected Windows 2008 in Virt Manager prior to starting the install, all other parameters were the same. So basically it seems to not like reading ISOs off of the file system? --Michael From Greg.Caetano at hp.com Fri Apr 3 20:06:02 2009 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Fri, 3 Apr 2009 20:06:02 +0000 Subject: [et-mgmt-tools] virt-p2v doesnt find cciss devices In-Reply-To: <200904031230.04763.nhappel@redhat.com> References: <200904031230.04763.nhappel@redhat.com> Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=451388 Greg Caetano Hewlett-Packard Company ESS Software Platform & Business Enablement Solutions Engineering Chicago, IL greg.caetano at hp.com Red Hat Certified Engineer RHCE#805007310328754 -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Niels Happel Sent: Friday, April 03, 2009 5:30 AM To: Fedora/Linux Management Tools Subject: [et-mgmt-tools] virt-p2v doesnt find cciss devices Hi, it looks like virt-p2v is not able to find /dev/cciss/c0d* as devices for hard- drives and only looks for devices residing directly at /dev/ - did somebody else had the same experience while having HP hardware raid controllers ? Cheers, Niels -- Niels Happel Red Hat GmbH _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From gramos at yahoo.com Mon Apr 6 05:06:26 2009 From: gramos at yahoo.com (brown wrap) Date: Sun, 5 Apr 2009 22:06:26 -0700 (PDT) Subject: [et-mgmt-tools] I'd like to build a kick-start serever on a home network Message-ID: <133788.13400.qm@web38102.mail.mud.yahoo.com> If I had a static address, it might not be as big a problem, but I am home using DSL with DHCP. I'd like to use Cobbler to a Fedora Kickstart Server. Since my server will be using a DHCP address, can it too, be a DHCP server? Is there a page that has available tools on it? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Mon Apr 6 18:40:27 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Apr 2009 14:40:27 -0400 Subject: [et-mgmt-tools] Svirt patch for virt-manager Message-ID: <49DA4C9B.1080804@redhat.com> This patch adds the ability to set the security mode, type and label. Hows it look? Dan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-svirt.patch URL: From jks at iname.com Tue Apr 7 23:38:06 2009 From: jks at iname.com (Joseph S) Date: Tue, 7 Apr 2009 19:38:06 -0400 (EDT) Subject: [et-mgmt-tools] Where do I report bugs? Message-ID: I'm having some issues with virt-manager 0.7.0. Do I report bugs here, or on bugzilla.redhat.com ? From crobinso at redhat.com Tue Apr 7 23:51:33 2009 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 07 Apr 2009 19:51:33 -0400 Subject: [et-mgmt-tools] Where do I report bugs? In-Reply-To: References: Message-ID: <49DBE705.5040409@redhat.com> On 04/07/2009 07:38 PM, Joseph S wrote: > I'm having some issues with virt-manager 0.7.0. Do I report bugs here, > or on bugzilla.redhat.com ? > Preferably bugzilla.redhat.com, against the 'virt-manager' component. If you built from source, use Product: 'Virtualization Tools'. If you are using a package provided by Fedora, use Product: 'Fedora'. If you are using another distros package, either file a bug with them, or use the 'Virtualization Tools' product as above. Thanks, Cole From jks at iname.com Wed Apr 8 00:00:11 2009 From: jks at iname.com (Joseph Shraibman) Date: Tue, 7 Apr 2009 20:00:11 -0400 (EDT) Subject: [et-mgmt-tools] Where do I report bugs? In-Reply-To: <49DBE705.5040409@redhat.com> References: <49DBE705.5040409@redhat.com> Message-ID: On Tue, 7 Apr 2009, Cole Robinson wrote: > On 04/07/2009 07:38 PM, Joseph S wrote: >> I'm having some issues with virt-manager 0.7.0. Do I report bugs here, >> or on bugzilla.redhat.com ? >> > > Preferably bugzilla.redhat.com, against the 'virt-manager' component. > > If you built from source, use Product: 'Virtualization Tools'. > You might want to put that in the README. Right now all it says is: Contact ------- All comments / suggestions / patches should be directed to the fedora-xen mailing list: http://www.redhat.com/mailman/listinfo/fedora-xen There are further project details on the website: http://virt-manager.org/ From crobinso at redhat.com Wed Apr 8 00:45:59 2009 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 07 Apr 2009 20:45:59 -0400 Subject: [et-mgmt-tools] Where do I report bugs? In-Reply-To: References: <49DBE705.5040409@redhat.com> Message-ID: <49DBF3C7.4040501@redhat.com> On 04/07/2009 08:00 PM, Joseph Shraibman wrote: > > > On Tue, 7 Apr 2009, Cole Robinson wrote: > >> On 04/07/2009 07:38 PM, Joseph S wrote: >>> I'm having some issues with virt-manager 0.7.0. Do I report bugs here, >>> or on bugzilla.redhat.com ? >>> >> >> Preferably bugzilla.redhat.com, against the 'virt-manager' component. >> >> If you built from source, use Product: 'Virtualization Tools'. >> > You might want to put that in the README. Right now all it says is: > Yeah, the docs all around need updating in this respect. Thanks for the heads up, I'll fix this soon. - Cole From levon at movementarian.org Wed Apr 8 13:50:44 2009 From: levon at movementarian.org (John Levon) Date: Wed, 8 Apr 2009 09:50:44 -0400 Subject: [et-mgmt-tools] Support post-2009.06 OpenSolaris releases Message-ID: <20090408135044.GA30577@movementarian.org> Support post-2009.06 OpenSolaris releases Future OpenSolaris releases will have the boot archive at /platform/i86pc/boot_archive. Signed-off-by: John Levon diff --git a/virtinst/OSDistro.py b/virtinst/OSDistro.py --- a/virtinst/OSDistro.py +++ b/virtinst/OSDistro.py @@ -1028,7 +1028,7 @@ os_variant = "opensolaris" kernelpath = "platform/i86xpv/kernel/unix" - initrdpaths = [ "boot/boot_archive", "boot/x86.microroot" ] + initrdpaths = [ "platform/i86pc/boot_archive", "boot/x86.microroot" ] def isValidStore(self, fetcher, progresscb): if fetcher.hasFile(self.kernelpath): From dlbewley at lib.ucdavis.edu Fri Apr 10 04:37:33 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Thu, 09 Apr 2009 21:37:33 -0700 Subject: [et-mgmt-tools] virt-manager wizard suggestions Message-ID: <1239338253.18375.12.camel@seitan.home.bewley.net> The virt-manager new VM wizard defaults to Generic for OS Type and Variant. It defaults to 'Debian Lenny' after you select Linux. It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. At least on the Fedora release of virt-manager. The installation media URL example is generic, it would also be nice if it defaulted to the mirror manager download link for the version selected above. Also, libvirt ships with a 'default' network but not a default storage pool. Should there be a 'default' storage pool for /var/lib/libvirt/images out of the box? From dlbewley at lib.ucdavis.edu Fri Apr 10 05:08:34 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Thu, 09 Apr 2009 22:08:34 -0700 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: <1239338253.18375.12.camel@seitan.home.bewley.net> References: <1239338253.18375.12.camel@seitan.home.bewley.net> Message-ID: <1239340114.18375.18.camel@seitan.home.bewley.net> On Thu, 2009-04-09 at 21:37 -0700, Dale Bewley wrote: > The virt-manager new VM wizard defaults to Generic for OS Type and > Variant. It defaults to 'Debian Lenny' after you select Linux. > > It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. > At least on the Fedora release of virt-manager. > > The installation media URL example is generic, it would also be nice if > it defaulted to the mirror manager download link for the version > selected above. Also, I may be nit picking, but the default disk size of 4G is insufficient for a default install of F11 Beta. 5G works. From quentusrex at gmail.com Fri Apr 10 06:17:11 2009 From: quentusrex at gmail.com (William King) Date: Thu, 09 Apr 2009 23:17:11 -0700 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: <1239340114.18375.18.camel@seitan.home.bewley.net> References: <1239338253.18375.12.camel@seitan.home.bewley.net> <1239340114.18375.18.camel@seitan.home.bewley.net> Message-ID: <49DEE467.7080507@gmail.com> How about the default OS being the OS that virt-manager is running on? or the default OS of the host server? Or the last chosen OS? How about sticky settings? Where the defaults are what you used last? -William Dale Bewley wrote: > On Thu, 2009-04-09 at 21:37 -0700, Dale Bewley wrote: >> The virt-manager new VM wizard defaults to Generic for OS Type and >> Variant. It defaults to 'Debian Lenny' after you select Linux. >> >> It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. >> At least on the Fedora release of virt-manager. >> >> The installation media URL example is generic, it would also be nice if >> it defaulted to the mirror manager download link for the version >> selected above. > > Also, I may be nit picking, but the default disk size of 4G is > insufficient for a default install of F11 Beta. 5G works. > > _______________________________________________ > 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 Fri Apr 10 10:36:50 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 10 Apr 2009 11:36:50 +0100 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: <1239338253.18375.12.camel@seitan.home.bewley.net> References: <1239338253.18375.12.camel@seitan.home.bewley.net> Message-ID: <20090410103650.GE1201@redhat.com> On Thu, Apr 09, 2009 at 09:37:33PM -0700, Dale Bewley wrote: > The virt-manager new VM wizard defaults to Generic for OS Type and > Variant. It defaults to 'Debian Lenny' after you select Linux. > > It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. > At least on the Fedora release of virt-manager. Our goal is that the user should never have to pick the OS type/variant except for when doing PXE boot. I think its reasonable to make ti default to the current host Fedora version in this case. In non-PXe cases, it should be auto-detecting the correct type/variant from the install URL you give it. > The installation media URL example is generic, it would also be nice if > it defaulted to the mirror manager download link for the version > selected above. It'd be nice to be able to pre-populate a list of URLs for all common distros, so you could simply pick one off the list. Any idea if mirror manager provides a URL we can fetch to obtain a complete list of all supported Fedora OS versions, so we can avoid hardcoding this. > Also, libvirt ships with a 'default' network but not a default storage > pool. Should there be a 'default' storage pool > for /var/lib/libvirt/images out of the box? Yes, IMHO, if virt-manager connects to a libvirt host and finds that no storage pools are configured, then it should create one based on /var/lib/libvirt/images. 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 Fri Apr 10 23:11:10 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Fri, 10 Apr 2009 16:11:10 -0700 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: <20090410103650.GE1201@redhat.com> References: <1239338253.18375.12.camel@seitan.home.bewley.net> <20090410103650.GE1201@redhat.com> Message-ID: <1239405070.14392.55.camel@tofu.lib.ucdavis.edu> On Fri, 2009-04-10 at 11:36 +0100, Daniel P. Berrange wrote: > On Thu, Apr 09, 2009 at 09:37:33PM -0700, Dale Bewley wrote: > > The virt-manager new VM wizard defaults to Generic for OS Type and > > Variant. It defaults to 'Debian Lenny' after you select Linux. > > > > It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. > > At least on the Fedora release of virt-manager. > > Our goal is that the user should never have to pick the OS type/variant > except for when doing PXE boot. I think its reasonable to make ti > default to the current host Fedora version in this case. In non-PXe > cases, it should be auto-detecting the correct type/variant from the > install URL you give it. The OS type/variant dialog is presented at the same time the user picks between cdrom/network install/pxe boot. The install URL is entered on the following dialog screen. > > The installation media URL example is generic, it would also be nice if > > it defaulted to the mirror manager download link for the version > > selected above. > > It'd be nice to be able to pre-populate a list of URLs for all common > distros, so you could simply pick one off the list. Any idea if > mirror manager provides a URL we can fetch to obtain a complete list > of all supported Fedora OS versions, so we can avoid hardcoding this. Yes, mirror manager http://fedoraproject.org/wiki/Infrastructure/MirrorManager can do that. Accessing http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-10&arch=x86_64 will give you a list of mirrors for f10 x86_64. In fact it will use GeoIP to find a list of mirrors "close" to you by default. If you add &redirect=1 it will bounce you to the first mirror on the list. Passing an invalid repo and/or arch will return a list of all repos and arches. i.e. http://mirrors.fedoraproject.org/mirrorlist?repo=foo&arch=foo There must be a more formal way to do that though. Is there a parameter for that, Matt? > > Also, libvirt ships with a 'default' network but not a default storage > > pool. Should there be a 'default' storage pool > > for /var/lib/libvirt/images out of the box? > > Yes, IMHO, if virt-manager connects to a libvirt host and finds that > no storage pools are configured, then it should create one based on > /var/lib/libvirt/images. Is the default network shipped with libvirt or virt-manager? I thought the former. -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3 From Matt_Domsch at Dell.com Fri Apr 10 23:22:20 2009 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Fri, 10 Apr 2009 18:22:20 -0500 Subject: [et-mgmt-tools] virt-manager wizard suggestions References: <1239338253.18375.12.camel@seitan.home.bewley.net><20090410103650.GE1201@redhat.com> <1239405070.14392.55.camel@tofu.lib.ucdavis.edu> Message-ID: http://mirrors.fedoraproject.org/releases.txt is used by Fedora's preupgrade package. Will that work? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: Dale Bewley [mailto:dlbewley at lib.ucdavis.edu] Sent: Fri 4/10/2009 6:11 PM To: Fedora/Linux Management Tools Cc: Domsch, Matt Subject: Re: [et-mgmt-tools] virt-manager wizard suggestions On Fri, 2009-04-10 at 11:36 +0100, Daniel P. Berrange wrote: > On Thu, Apr 09, 2009 at 09:37:33PM -0700, Dale Bewley wrote: > > The virt-manager new VM wizard defaults to Generic for OS Type and > > Variant. It defaults to 'Debian Lenny' after you select Linux. > > > > It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. > > At least on the Fedora release of virt-manager. > > Our goal is that the user should never have to pick the OS type/variant > except for when doing PXE boot. I think its reasonable to make ti > default to the current host Fedora version in this case. In non-PXe > cases, it should be auto-detecting the correct type/variant from the > install URL you give it. The OS type/variant dialog is presented at the same time the user picks between cdrom/network install/pxe boot. The install URL is entered on the following dialog screen. > > The installation media URL example is generic, it would also be nice if > > it defaulted to the mirror manager download link for the version > > selected above. > > It'd be nice to be able to pre-populate a list of URLs for all common > distros, so you could simply pick one off the list. Any idea if > mirror manager provides a URL we can fetch to obtain a complete list > of all supported Fedora OS versions, so we can avoid hardcoding this. Yes, mirror manager http://fedoraproject.org/wiki/Infrastructure/MirrorManager can do that. Accessing http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-10&arch=x86_64 will give you a list of mirrors for f10 x86_64. In fact it will use GeoIP to find a list of mirrors "close" to you by default. If you add &redirect=1 it will bounce you to the first mirror on the list. Passing an invalid repo and/or arch will return a list of all repos and arches. i.e. http://mirrors.fedoraproject.org/mirrorlist?repo=foo&arch=foo There must be a more formal way to do that though. Is there a parameter for that, Matt? > > Also, libvirt ships with a 'default' network but not a default storage > > pool. Should there be a 'default' storage pool > > for /var/lib/libvirt/images out of the box? > > Yes, IMHO, if virt-manager connects to a libvirt host and finds that > no storage pools are configured, then it should create one based on > /var/lib/libvirt/images. Is the default network shipped with libvirt or virt-manager? I thought the former. -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3 From crobinso at redhat.com Sat Apr 11 20:45:35 2009 From: crobinso at redhat.com (Cole Robinson) Date: Sat, 11 Apr 2009 16:45:35 -0400 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: <1239340114.18375.18.camel@seitan.home.bewley.net> References: <1239338253.18375.12.camel@seitan.home.bewley.net> <1239340114.18375.18.camel@seitan.home.bewley.net> Message-ID: <49E1016F.5050801@redhat.com> On 04/10/2009 01:08 AM, Dale Bewley wrote: > On Thu, 2009-04-09 at 21:37 -0700, Dale Bewley wrote: >> The virt-manager new VM wizard defaults to Generic for OS Type and >> Variant. It defaults to 'Debian Lenny' after you select Linux. >> >> It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. >> At least on the Fedora release of virt-manager. >> Yes I think that's a good idea. It would be nice to put some host distro detection code into virt-manager to determine this, but in the mean time I'll put a patch in fedora cvs to default to F11. >> The installation media URL example is generic, it would also be nice if >> it defaulted to the mirror manager download link for the version >> selected above. > Like Dan suggests, it would be nice if we can provide URLs for all distros. Unfortunately the only other distro that provides capabilities similar to mirrormanager at the moment is Opensuse, so we would have to hard code a specific tree for all the others. That said, I'll probably add an F11 specific patch to have the F11 GA link populated by default (though I suppose that would need to be applied after GA, which sucks.) > Also, I may be nit picking, but the default disk size of 4G is > insufficient for a default install of F11 Beta. 5G works. > Hmm, It should be 8G, at least that's what it is for me. Are you short on space on the host machine? We will cap it to what's available if it's less than 8G. WRT the default storage pool issue, virt-manager will set one up when the install wizard is launched. The pool is named 'default' and it points to '/var/lib/libvirt/images'. Eventually this will be configurable in virt-manager. From jks at iname.com Mon Apr 13 17:17:15 2009 From: jks at iname.com (Joseph S) Date: Mon, 13 Apr 2009 13:17:15 -0400 (EDT) Subject: [et-mgmt-tools] What causes virt-manager to connect in read only mode? Message-ID: Virt manager 0.7.0 on Centos (libvirt 0.3.3) does this: [Sun, 12 Apr 2009 20:57:00 virt-manager 5830] INFO (virt-manager:144) Application startup [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (engine:81) About to connect to uris ['qemu:///system'] [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:144) Bonding masters are: [] [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:170) Got physical net device /org/freedesktop/Hal/devices/net_00_30_48_c6_55_e0 [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:230) Adding net device eth0 00:30:48:c6:55:e0 /sys/class/net/eth0 (bridge: br0) [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:202) Checking for VLANs on /sys/class/net/eth0 [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:170) Got physical net device /org/freedesktop/Hal/devices/net_00_30_48_c6_55_e1 [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:230) Adding net device eth1 00:30:48:c6:55:e1 /sys/class/net/eth1 (bridge: br1) [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:202) Checking for VLANs on /sys/class/net/eth1 [Sun, 12 Apr 2009 20:57:02 virt-manager 5833] DEBUG (engine:320) window counter incremented to 1 [Sun, 12 Apr 2009 20:57:07 virt-manager 5833] DEBUG (connection:431) Scheduling background open thread for qemu:///system [Sun, 12 Apr 2009 20:57:07 virt-manager 5833] DEBUG (connection:561) Background thread is running [Sun, 12 Apr 2009 20:57:07 virt-manager 5833] ERROR (connection:551) Read/write connection failed for qemu:///system, falling back on read-only. Traceback (most recent call last): File "/usr/local/share/virt-manager/virtManager/connection.py", line 536, in _try_open self.vmm = libvirt.openAuth(self.uri, AttributeError: 'module' object has no attribute 'openAuth' [Sun, 12 Apr 2009 20:57:07 virt-manager 5833] DEBUG (connection:599) Background open thread complete, scheduling notify [Sun, 12 Apr 2009 20:57:08 virt-manager 5833] DEBUG (connection:608) Notifying open result [Sun, 12 Apr 2009 20:57:11 virt-manager 5833] DEBUG (engine:324) window counter decremented to 0 [Sun, 12 Apr 2009 20:57:11 virt-manager 5833] DEBUG (engine:332) Exiting app normally. From crobinso at redhat.com Mon Apr 13 17:28:06 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 13 Apr 2009 13:28:06 -0400 Subject: [et-mgmt-tools] What causes virt-manager to connect in read only mode? In-Reply-To: References: Message-ID: <49E37626.7060708@redhat.com> On 04/13/2009 01:17 PM, Joseph S wrote: > Virt manager 0.7.0 on Centos (libvirt 0.3.3) does this: > > [Sun, 12 Apr 2009 20:57:00 virt-manager 5830] INFO (virt-manager:144) > Application startup > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (engine:81) About to > connect to uris ['qemu:///system'] > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:144) > Bonding masters are: [] > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:170) Got > physical net device /org/freedesktop/Hal/devices/net_00_30_48_c6_55_e0 > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:230) > Adding net device eth0 00:30:48:c6:55:e0 /sys/class/net/eth0 (bridge: br0) > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:202) > Checking for VLANs on /sys/class/net/eth0 > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:170) Got > physical net device /org/freedesktop/Hal/devices/net_00_30_48_c6_55_e1 > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:230) > Adding net device eth1 00:30:48:c6:55:e1 /sys/class/net/eth1 (bridge: br1) > [Sun, 12 Apr 2009 20:57:01 virt-manager 5833] DEBUG (connection:202) > Checking for VLANs on /sys/class/net/eth1 > [Sun, 12 Apr 2009 20:57:02 virt-manager 5833] DEBUG (engine:320) window > counter incremented to 1 > [Sun, 12 Apr 2009 20:57:07 virt-manager 5833] DEBUG (connection:431) > Scheduling background open thread for qemu:///system > [Sun, 12 Apr 2009 20:57:07 virt-manager 5833] DEBUG (connection:561) > Background thread is running > [Sun, 12 Apr 2009 20:57:07 virt-manager 5833] ERROR (connection:551) > Read/write connection failed for qemu:///system, falling back on read-only. > Traceback (most recent call last): > File "/usr/local/share/virt-manager/virtManager/connection.py", line > 536, in _try_open > self.vmm = libvirt.openAuth(self.uri, > AttributeError: 'module' object has no attribute 'openAuth' The version of libvirt on your machine lacks the openAuth command, so we are falling back to read-only mode. We could try to detect this and just try the plain 'open' command instead. That said, if you are using virt-manager 0.7.0 on centos, you should probably update libvirt beyond the stock centos version as well, since that is where most of the features come from. - Cole From berrange at redhat.com Tue Apr 14 08:14:09 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 14 Apr 2009 09:14:09 +0100 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: <1239405070.14392.55.camel@tofu.lib.ucdavis.edu> References: <1239338253.18375.12.camel@seitan.home.bewley.net> <20090410103650.GE1201@redhat.com> <1239405070.14392.55.camel@tofu.lib.ucdavis.edu> Message-ID: <20090414081409.GD14297@redhat.com> On Fri, Apr 10, 2009 at 04:11:10PM -0700, Dale Bewley wrote: > On Fri, 2009-04-10 at 11:36 +0100, Daniel P. Berrange wrote: > > On Thu, Apr 09, 2009 at 09:37:33PM -0700, Dale Bewley wrote: > > > The virt-manager new VM wizard defaults to Generic for OS Type and > > > Variant. It defaults to 'Debian Lenny' after you select Linux. > > > > > > It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. > > > At least on the Fedora release of virt-manager. > > > > Our goal is that the user should never have to pick the OS type/variant > > except for when doing PXE boot. I think its reasonable to make ti > > default to the current host Fedora version in this case. In non-PXe > > cases, it should be auto-detecting the correct type/variant from the > > install URL you give it. > > The OS type/variant dialog is presented at the same time the user picks > between cdrom/network install/pxe boot. The install URL is entered on > the following dialog screen. Checkout the latest virt-manager UI... In Fedora 11, the type/variant choice is on the same wizard page as the place where you enter the URL, and is auto-filled based on the URL > > > The installation media URL example is generic, it would also be nice if > > > it defaulted to the mirror manager download link for the version > > > selected above. > > > > It'd be nice to be able to pre-populate a list of URLs for all common > > distros, so you could simply pick one off the list. Any idea if > > mirror manager provides a URL we can fetch to obtain a complete list > > of all supported Fedora OS versions, so we can avoid hardcoding this. > > Yes, mirror manager > http://fedoraproject.org/wiki/Infrastructure/MirrorManager > can do that. > > Accessing > http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-10&arch=x86_64 > will give you a list of mirrors for f10 x86_64. In fact it will use > GeoIP to find a list of mirrors "close" to you by default. > > If you add &redirect=1 it will bounce you to the first mirror on the > list. > > Passing an invalid repo and/or arch will return a list of all repos and > arches. i.e. > http://mirrors.fedoraproject.org/mirrorlist?repo=foo&arch=foo > There must be a more formal way to do that though. Is there a parameter > for that, Matt? The thing I'm particuarly interested in, is getting a list of all the valudate 'repo' and 'arch' parameters. THought we could hardcode these, its nicer if there's a way for mirror-manager to tell us what is currently officially supported, so we don't need to track EOL dates. > > > Also, libvirt ships with a 'default' network but not a default storage > > > pool. Should there be a 'default' storage pool > > > for /var/lib/libvirt/images out of the box? > > > > Yes, IMHO, if virt-manager connects to a libvirt host and finds that > > no storage pools are configured, then it should create one based on > > /var/lib/libvirt/images. > > Is the default network shipped with libvirt or virt-manager? I thought > the former. The default network is setup by libvirt (for historical reasons). If I were doing it again now, I'd have virt-manager create it automatically if it didn't find any accepted bridged network interface. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Apr 14 08:15:07 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 14 Apr 2009 09:15:07 +0100 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: References: <1239405070.14392.55.camel@tofu.lib.ucdavis.edu> Message-ID: <20090414081507.GE14297@redhat.com> On Fri, Apr 10, 2009 at 06:22:20PM -0500, Matt_Domsch at Dell.com wrote: > http://mirrors.fedoraproject.org/releases.txt > > is used by Fedora's preupgrade package. Will that work? Yes, that's exactly the kind of information we'd be wanting. 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 Matt_Domsch at dell.com Tue Apr 14 13:10:06 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 14 Apr 2009 08:10:06 -0500 Subject: [et-mgmt-tools] virt-manager wizard suggestions In-Reply-To: <20090414081409.GD14297@redhat.com> References: <1239338253.18375.12.camel@seitan.home.bewley.net> <20090410103650.GE1201@redhat.com> <1239405070.14392.55.camel@tofu.lib.ucdavis.edu> <20090414081409.GD14297@redhat.com> Message-ID: <20090414130959.GA15950@mock.linuxdev.us.dell.com> On Tue, Apr 14, 2009 at 09:14:09AM +0100, Daniel P. Berrange wrote: > On Fri, Apr 10, 2009 at 04:11:10PM -0700, Dale Bewley wrote: > > On Fri, 2009-04-10 at 11:36 +0100, Daniel P. Berrange wrote: > > > On Thu, Apr 09, 2009 at 09:37:33PM -0700, Dale Bewley wrote: > > > > The virt-manager new VM wizard defaults to Generic for OS Type and > > > > Variant. It defaults to 'Debian Lenny' after you select Linux. > > > > > > > > It would be nice if it defaulted to 'Linux' and 'Fedora $host_version'. > > > > At least on the Fedora release of virt-manager. > > > > > > Our goal is that the user should never have to pick the OS type/variant > > > except for when doing PXE boot. I think its reasonable to make ti > > > default to the current host Fedora version in this case. In non-PXe > > > cases, it should be auto-detecting the correct type/variant from the > > > install URL you give it. > > > > The OS type/variant dialog is presented at the same time the user picks > > between cdrom/network install/pxe boot. The install URL is entered on > > the following dialog screen. > > Checkout the latest virt-manager UI... > > In Fedora 11, the type/variant choice is on the same wizard page as > the place where you enter the URL, and is auto-filled based on the > URL > > > > > The installation media URL example is generic, it would also be nice if > > > > it defaulted to the mirror manager download link for the version > > > > selected above. > > > > > > It'd be nice to be able to pre-populate a list of URLs for all common > > > distros, so you could simply pick one off the list. Any idea if > > > mirror manager provides a URL we can fetch to obtain a complete list > > > of all supported Fedora OS versions, so we can avoid hardcoding this. > > > > Yes, mirror manager > > http://fedoraproject.org/wiki/Infrastructure/MirrorManager > > can do that. > > > > Accessing > > http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-10&arch=x86_64 > > will give you a list of mirrors for f10 x86_64. In fact it will use > > GeoIP to find a list of mirrors "close" to you by default. > > > > If you add &redirect=1 it will bounce you to the first mirror on the > > list. > > > > Passing an invalid repo and/or arch will return a list of all repos and > > arches. i.e. > > http://mirrors.fedoraproject.org/mirrorlist?repo=foo&arch=foo > > There must be a more formal way to do that though. Is there a parameter > > for that, Matt? > > The thing I'm particuarly interested in, is getting a list of all the > valudate 'repo' and 'arch' parameters. THought we could hardcode these, > its nicer if there's a way for mirror-manager to tell us what is > currently officially supported, so we don't need to track EOL dates. Adding Will Woods who handles the preupgrade package. http://mirrors.fedoraproject.org/releases.txt is the way preupgrade handles it. That URL is a file that looks like: [Rawhide] # Rawhide is *always* the newest stable=False preupgrade-ok=True version=999 mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/development/$basearch/os [Fedora 10 (Cambridge)] stable=True preupgrade-ok=True version=10 mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-10&arch=$basearch installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/10/Fedora/$basearch/os [Fedora 7 (Moonshine)] stable=True version=7 eol-date=20080613 mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-7&arch=$basearch installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/7/Fedora/$basearch/os But note, this only includes the mirrorlist to the main repository, not to updates, updates-testing, etc. for each version. That may be something Will could add to this format, which would then suffice for you. There is an eol-date field in this format (as I show in the F7 block). I don't think you really want _all_ the repo/arch combinations to display - as noted above it is a pretty long list, and there isn't an obvious correlation between each combination and the OS version it might make sense for. MM has a hairy bit of code [1] that hardcodes the repository name pattern based on the product and as the repository names have changed over time. I can understand you not wanting to duplicate that. [1] http://git.fedorahosted.org/git/mirrormanager/?p=mirrormanager;a=blob;f=server/mirrormanager/repomap.py;hb=HEAD -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From agx at sigxcpu.org Thu Apr 16 12:27:25 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 16 Apr 2009 14:27:25 +0200 Subject: [et-mgmt-tools] [PATCH]: virt-manager let netcat quit on EOF Message-ID: <20090416122725.GA13835@bogon.ms20.nix> Hi, attached patch adds "-q 0" to quit on EOF on stdin to the netcat calls uesd for vnc forwarding via ssh. Without it the nc call keeps hanging around which makes the waitpid wait forever and lets the whole main window freeze [1][2]. Cheers, -- Guido [1] http://bugs.debian.org/519979 [2] http://bugs.debian.org/521137 From agx at sigxcpu.org Thu Apr 16 12:28:24 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 16 Apr 2009 14:28:24 +0200 Subject: [et-mgmt-tools] Re: [PATCH]: virt-manager let netcat quit on EOF In-Reply-To: <20090416122725.GA13835@bogon.ms20.nix> References: <20090416122725.GA13835@bogon.ms20.nix> Message-ID: <20090416122824.GA14356@bogon.ms20.nix> This time with the attachment. On Thu, Apr 16, 2009 at 02:27:25PM +0200, Guido G?nther wrote: > Hi, > attached patch adds "-q 0" to quit on EOF on stdin to the netcat calls > uesd for vnc forwarding via ssh. Without it the nc call keeps hanging > around which makes the waitpid wait forever and lets the whole main > window freeze [1][2]. > Cheers, > -- Guido > > [1] http://bugs.debian.org/519979 > [2] http://bugs.debian.org/521137 -------------- next part -------------- A non-text attachment was scrubbed... Name: netcat_close.diff Type: text/x-diff Size: 782 bytes Desc: not available URL: From agx at sigxcpu.org Thu Apr 16 16:15:01 2009 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Thu, 16 Apr 2009 18:15:01 +0200 Subject: [et-mgmt-tools] RFC: virt-manager: Redesigned 'New VM' wizard In-Reply-To: <20090302195028.GA1372@redhat.com> References: <49A86E27.20605@redhat.com> <20090302191203.GA8388@bogon.ms20.nix> <20090302195028.GA1372@redhat.com> Message-ID: <20090416161501.GA5337@bogon.ms20.nix> On Mon, Mar 02, 2009 at 07:50:28PM +0000, Daniel P. Berrange wrote: > On Mon, Mar 02, 2009 at 08:12:03PM +0100, Guido G?nther wrote: > > Hi Cole, > > this all looks great. > > On Fri, Feb 27, 2009 at 05:50:15PM -0500, Cole Robinson wrote: > > > The summary section is pretty straight forward, no surprises here. > > > The 'Advanced Options' section encompasses networking, hypervisor, and > > > architecture options. The hypervisor and arch defaults were explained above. > > An option to select disk (scsi, ide, virtio) and network adapter model > > (e1000, ...) as advanced options would be great (still defaulting to > > virtio if supported via the osdict) since there are some OSes that don't > > support all hardware out of the box and there are kvm/qemu versions that > > have problems with certain adapter types. > > If there are combinations of OS,Disk that don't work IMHO we should > improve the OS type metadata so we don't use them. Choice of specific > hardware models is something we really want to keep out of the new VM > wizard, because the end user really isn't in a position to have the > knowledge to make suitable choices. Sometimes it's not an issue of the guest but of the hypervisor like missing PXE roms[1]. Attached is a patch Andreas Unterkircher that adds NIC model selection to the advanced options of the vm wizard (some code could probably be shared with vmmAddHardware). Cheers, -- Guido [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521091 -------------- next part -------------- A non-text attachment was scrubbed... Name: nic-model-in-wizard.diff Type: text/x-diff Size: 5411 bytes Desc: not available URL: From crobinso at redhat.com Mon Apr 20 16:35:06 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Apr 2009 12:35:06 -0400 Subject: [et-mgmt-tools] Support post-2009.06 OpenSolaris releases In-Reply-To: <20090408135044.GA30577@movementarian.org> References: <20090408135044.GA30577@movementarian.org> Message-ID: <49ECA43A.8080102@redhat.com> On 04/08/2009 09:50 AM, John Levon wrote: > Support post-2009.06 OpenSolaris releases > > Future OpenSolaris releases will have the boot archive at > /platform/i86pc/boot_archive. > > Signed-off-by: John Levon > Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/bb99f9a13ea4 - Cole From crobinso at redhat.com Mon Apr 20 16:35:59 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Apr 2009 12:35:59 -0400 Subject: [et-mgmt-tools] fix for presenting memory allocation of host and/or vm In-Reply-To: <49D3F1E3.5060000@web.de> References: <49D3F1E3.5060000@web.de> Message-ID: <49ECA46F.4030600@redhat.com> On 04/01/2009 06:59 PM, Gerrit Slomma wrote: > Hello > > I found the presentation of the memory allocation of host and/or vm > annoying, e.g. hosts/vms with more then one GB showed up in > virtual-manager with x.yy GBwhereas hosts/vms with less or equal to on > GB showed up as xxxx.yy MB. In details of hosts this also showed up. > I changed this behavior to showing GB if memory is >10 GB and set > MB-presentation to 2.0f. > I find it clearer, what is your opinion? > I agree. I've applied the patch: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/c8798a8e9c6e Thanks, Cole From crobinso at redhat.com Mon Apr 20 16:37:35 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Apr 2009 12:37:35 -0400 Subject: [et-mgmt-tools] Re: [PATCH]: virt-manager let netcat quit on EOF In-Reply-To: <20090416122824.GA14356@bogon.ms20.nix> References: <20090416122725.GA13835@bogon.ms20.nix> <20090416122824.GA14356@bogon.ms20.nix> Message-ID: <49ECA4CF.70005@redhat.com> On 04/16/2009 08:28 AM, Guido G?nther wrote: > This time with the attachment. > > On Thu, Apr 16, 2009 at 02:27:25PM +0200, Guido G?nther wrote: >> Hi, >> attached patch adds "-q 0" to quit on EOF on stdin to the netcat calls >> uesd for vnc forwarding via ssh. Without it the nc call keeps hanging >> around which makes the waitpid wait forever and lets the whole main >> window freeze [1][2]. >> Cheers, >> -- Guido >> >> [1] http://bugs.debian.org/519979 >> [2] http://bugs.debian.org/521137 >> Thanks, applied: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/dd3160e94f25 - Cole From crobinso at redhat.com Mon Apr 20 17:53:12 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 20 Apr 2009 13:53:12 -0400 Subject: [et-mgmt-tools] Re: The gui should drop the connection if libvirt stops for any reason like service libvirt stop. In-Reply-To: <49BEA17F.2050805@redhat.com> References: <49BEA17F.2050805@redhat.com> Message-ID: <49ECB688.6080606@redhat.com> On 03/16/2009 02:59 PM, Daniel J Walsh wrote: > diff -u virtManager/engine.py~ virtManager/engine.py > --- virtManager/engine.py~ 2009-03-16 14:49:16.000000000 -0400 > +++ virtManager/engine.py 2009-03-16 14:58:05.000000000 -0400 > @@ -158,6 +158,7 @@ > logging.error(("Could not refresh connection %s\n" % > (uri)) + str(sys.exc_info()[0]) + \ > " " + str(sys.exc_info()[1]) + "\n" + \ > traceback.format_exc(sys.exc_info()[2])) > + self.connections[uri]["connection"].close() > return 1 > > def change_timer_interval(self,ignore1,ignore2,ignore3,ignore4): Sorry for the delay. Applied now with some additional logging: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/32d53a01e595 - Cole From thatch45 at gmail.com Tue Apr 21 18:10:41 2009 From: thatch45 at gmail.com (Thomas S Hatch) Date: Tue, 21 Apr 2009 12:10:41 -0600 Subject: [et-mgmt-tools] cft - should this install on f10? Message-ID: <6172c17e0904211110n31ac6648gb5cd53a6b0ab17da@mail.gmail.com> I was wondering if cft is still being actively developed and if it can be installed on fedora 10? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutter at redhat.com Tue Apr 21 19:13:21 2009 From: lutter at redhat.com (David Lutterkort) Date: Tue, 21 Apr 2009 19:13:21 +0000 Subject: [et-mgmt-tools] Re: Info on cft In-Reply-To: <6172c17e0904211207v6c0b8f87t4b4fa60b98ed9926@mail.gmail.com> References: <6172c17e0904211108s43bd442eo4914bdd08afe3355@mail.gmail.com> <1240340704.18022.22.camel@avon.watzmann.net> <6172c17e0904211207v6c0b8f87t4b4fa60b98ed9926@mail.gmail.com> Message-ID: <1240341201.18022.29.camel@avon.watzmann.net> On Tue, 2009-04-21 at 13:07 -0600, Thomas S Hatch wrote: > I am a python guy myself, but I will try to take a look. I really > like what you are doing with cft and would hate to see the concept > die. You don't know if there is a similar function in ralsh? No, ralsh doesn't do that; cft requires some more intimate knowledge of the system (e.g., it takes a snapshot of the rpm DB at the start of a session, and tracks file changes using fam/inotify) It just occurred to me that it might be possible to sidestep the whole ruby-rpm issue by shelling out to rpm - that might be an easier way to resurrect cft than fixing the ruby-rpm bindings. David From thatch45 at gmail.com Tue Apr 21 19:16:10 2009 From: thatch45 at gmail.com (Thomas S Hatch) Date: Tue, 21 Apr 2009 13:16:10 -0600 Subject: [et-mgmt-tools] Re: Info on cft In-Reply-To: <1240341201.18022.29.camel@avon.watzmann.net> References: <6172c17e0904211108s43bd442eo4914bdd08afe3355@mail.gmail.com> <1240340704.18022.22.camel@avon.watzmann.net> <6172c17e0904211207v6c0b8f87t4b4fa60b98ed9926@mail.gmail.com> <1240341201.18022.29.camel@avon.watzmann.net> Message-ID: <6172c17e0904211216u59e11ddbg336fab447f4d80c6@mail.gmail.com> Bindings are nice, but it is always better to get functionality then polish later! I will have some time to look at the code later tonight of tomorrow, I will see what I can find. But all in all I think that cft would be an amazing tool to have, and I think it is worth the trouble to get going! On Tue, Apr 21, 2009 at 1:13 PM, David Lutterkort wrote: > On Tue, 2009-04-21 at 13:07 -0600, Thomas S Hatch wrote: > > I am a python guy myself, but I will try to take a look. I really > > like what you are doing with cft and would hate to see the concept > > die. You don't know if there is a similar function in ralsh? > > No, ralsh doesn't do that; cft requires some more intimate knowledge of > the system (e.g., it takes a snapshot of the rpm DB at the start of a > session, and tracks file changes using fam/inotify) > > It just occurred to me that it might be possible to sidestep the whole > ruby-rpm issue by shelling out to rpm - that might be an easier way to > resurrect cft than fixing the ruby-rpm bindings. > > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bleanhar at redhat.com Wed Apr 22 14:52:40 2009 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 22 Apr 2009 10:52:40 -0400 Subject: [et-mgmt-tools] edge case with virt-manager and multiple connections Message-ID: <20090422145240.GC26638@guilin.rdu.redhat.com> I'm using virt-manager 0.6.0 on F10 and I came across an edge case with regard to managing multiple connections. In my case the domain xml files were mounted via NFS and shared across multiple hosts. This obviously leads to guests on each machine having the same uuid. I expected each of my 3 virt hosts to list all the domains and to be able to select where I wanted a particular guest to be started. What I didn't expect was that once I started a guest on one domain it immediately showed up as "Running" on the other two virt hosts. Stopping the VM on the correct host also behaves as expected. Is this a case virt-manager should handle? I could attempt a patch if given a bit of guidance. Namely, Should a vmmDomain have knowledge of which host is running on? Should there be seperate instances for each host even though they have the same uuid (which in this case is not really a uuid). Would it be best to simply patch the UI to handle this edge case? --Brenton From crobinso at redhat.com Wed Apr 22 15:12:30 2009 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 22 Apr 2009 11:12:30 -0400 Subject: [et-mgmt-tools] edge case with virt-manager and multiple connections In-Reply-To: <20090422145240.GC26638@guilin.rdu.redhat.com> References: <20090422145240.GC26638@guilin.rdu.redhat.com> Message-ID: <49EF33DE.6050509@redhat.com> Brenton Leanhardt wrote: > I'm using virt-manager 0.6.0 on F10 and I came across an edge case > with regard to managing multiple connections. In my case the domain > xml files were mounted via NFS and shared across multiple hosts. > > This obviously leads to guests on each machine having the same uuid. > I expected each of my 3 virt hosts to list all the domains and to be > able to select where I wanted a particular guest to be started. What > I didn't expect was that once I started a guest on one domain it > immediately showed up as "Running" on the other two virt hosts. > Stopping the VM on the correct host also behaves as expected. > > Is this a case virt-manager should handle? I could attempt a patch if > given a bit of guidance. Namely, > > Should a vmmDomain have knowledge of which host is running on? > > Should there be seperate instances for each host even though they have > the same uuid (which in this case is not really a uuid). > > Would it be best to simply patch the UI to handle this edge case? > Thanks for looking to patch this, but this should actually be fixed in virt-manager-0.6.1 which I plan on pushing to F10. The commits are: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/9c4afb8ad1e6 http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/4e7c3f99f0db The issue was that we were using only UUID as the unique identifier for rows in the manager window, which was switched to using connection URI + UUID. Thanks, Cole From bleanhar at redhat.com Wed Apr 22 15:15:59 2009 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 22 Apr 2009 11:15:59 -0400 Subject: [et-mgmt-tools] Re: edge case with virt-manager and multiple connections In-Reply-To: <49EF33DE.6050509@redhat.com> References: <20090422145240.GC26638@guilin.rdu.redhat.com> <49EF33DE.6050509@redhat.com> Message-ID: <20090422151559.GD26638@guilin.rdu.redhat.com> +++ Cole Robinson [22/04/09 11:12 -0400]: >Brenton Leanhardt wrote: >> I'm using virt-manager 0.6.0 on F10 and I came across an edge case >> with regard to managing multiple connections. In my case the domain >> xml files were mounted via NFS and shared across multiple hosts. >> >> This obviously leads to guests on each machine having the same uuid. >> I expected each of my 3 virt hosts to list all the domains and to be >> able to select where I wanted a particular guest to be started. What >> I didn't expect was that once I started a guest on one domain it >> immediately showed up as "Running" on the other two virt hosts. >> Stopping the VM on the correct host also behaves as expected. >> >> Is this a case virt-manager should handle? I could attempt a patch if >> given a bit of guidance. Namely, >> >> Should a vmmDomain have knowledge of which host is running on? >> >> Should there be seperate instances for each host even though they have >> the same uuid (which in this case is not really a uuid). >> >> Would it be best to simply patch the UI to handle this edge case? >> > >Thanks for looking to patch this, but this should actually be fixed in >virt-manager-0.6.1 which I plan on pushing to F10. The commits are: > >http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/9c4afb8ad1e6 >http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/4e7c3f99f0db > >The issue was that we were using only UUID as the unique identifier for >rows in the manager window, which was switched to using connection URI + >UUID. > >Thanks, >Cole Excellent! I'll checkout the code and see if it works for me. --Brenton From berrange at redhat.com Wed Apr 22 15:21:19 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 22 Apr 2009 16:21:19 +0100 Subject: [et-mgmt-tools] edge case with virt-manager and multiple connections In-Reply-To: <20090422145240.GC26638@guilin.rdu.redhat.com> References: <20090422145240.GC26638@guilin.rdu.redhat.com> Message-ID: <20090422152119.GG14705@redhat.com> On Wed, Apr 22, 2009 at 10:52:40AM -0400, Brenton Leanhardt wrote: > I'm using virt-manager 0.6.0 on F10 and I came across an edge case > with regard to managing multiple connections. In my case the domain > xml files were mounted via NFS and shared across multiple hosts. That is a really bad idea. There is no locking / monitoring of these files by libvirtd. It expects them to be on local disk, exclusively used locally. If you're setting up a cluster, then it is recommended to have a master storage of XML files elsewhere, and then sync them to the individual nodes as meeded. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From john.levon at sun.com Fri Apr 24 03:27:28 2009 From: john.levon at sun.com (John Levon) Date: Thu, 23 Apr 2009 20:27:28 -0700 Subject: [et-mgmt-tools] [PATCH] Fix processing of extra args for OpenSolaris domains Message-ID: <0e3ca3aba71030b3f370.1240543648@girltalk> # HG changeset patch # User John Levon # Date 1240543631 25200 # Node ID 0e3ca3aba71030b3f370edc2b8651b6ddb82eb43 # Parent 406a2d1897b9e1d16449729e4cb328c254dc15ed Fix processing of extra args for OpenSolaris domains Signed-off-by: John Levon diff --git a/virtinst/OSDistro.py b/virtinst/OSDistro.py --- a/virtinst/OSDistro.py +++ b/virtinst/OSDistro.py @@ -1059,7 +1059,7 @@ class OpenSolarisDistro(SunDistro): args = '' if kopts: - args += '-' + kopts + args += ' -' + kopts if kbargs: args += ' -B ' + kbargs From rjones at redhat.com Sat Apr 25 12:41:37 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 25 Apr 2009 13:41:37 +0100 Subject: [et-mgmt-tools] virt-p2v doesnt find cciss devices In-Reply-To: <200904031230.04763.nhappel@redhat.com> References: <200904031230.04763.nhappel@redhat.com> Message-ID: <20090425124137.GA2764@amd.home.annexia.org> On Fri, Apr 03, 2009 at 12:30:04PM +0200, Niels Happel wrote: > Hi, > > it looks like virt-p2v is not able to find /dev/cciss/c0d* as devices for hard- > drives and only looks for devices residing directly at /dev/ - did somebody > else had the same experience while having HP hardware raid controllers ? Yes, this is a bug which I am just looking at today. https://bugzilla.redhat.com/show_bug.cgi?id=451388 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 rjones at redhat.com Sat Apr 25 12:42:17 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 25 Apr 2009 13:42:17 +0100 Subject: [et-mgmt-tools] guestfish recipes (examples) Message-ID: <20090425124217.GA3367@amd.home.annexia.org> I put up a set of examples using libguestfs / guestfish. These are small (< 10 line) shell scripts that show you how to do some interesting stuff to virtual machines: http://et.redhat.com/~rjones/libguestfs/recipes.html Fedora users' own contributions are welcome too! Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From crobinso at redhat.com Mon Apr 27 13:38:52 2009 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 27 Apr 2009 09:38:52 -0400 Subject: [et-mgmt-tools] [PATCH] Fix processing of extra args for OpenSolaris domains In-Reply-To: <0e3ca3aba71030b3f370.1240543648@girltalk> References: <0e3ca3aba71030b3f370.1240543648@girltalk> Message-ID: <49F5B56C.20607@redhat.com> John Levon wrote: > # HG changeset patch > # User John Levon > # Date 1240543631 25200 > # Node ID 0e3ca3aba71030b3f370edc2b8651b6ddb82eb43 > # Parent 406a2d1897b9e1d16449729e4cb328c254dc15ed > Fix processing of extra args for OpenSolaris domains > > Signed-off-by: John Levon > Applied now. Thanks, Cole From mike.hinz at yr20.com Mon Apr 27 17:33:29 2009 From: mike.hinz at yr20.com (mike.hinz at yr20.com) Date: Mon, 27 Apr 2009 12:33:29 -0500 (CDT) Subject: [et-mgmt-tools] user questions - iscsi and nfs storage Message-ID: <1240853609.12816628@192.168.1.35> Hi, I'm a user and couldn't find a user oriented list for virt-manager so I'd thought I'd ask here. I have a few questions regarding using network storage with virt-manager. I'm using the Fedora 11 beta with libvirt and virt-manager updated to the latest from rawhide. ? Virt-manager is version 0.7.0-4 built on 14 April. Further background is that I have an openfiler in my office with both iscsi and nfs enabled. I can access both properly from my physical host. My first question is in regards to iscsi. ?It appears that I can enabled an iscsi pool, but I can't seem to create any volumes in it via virt-manager. Is this the way it as or am I doing something wrong? If this is the way it is, is there any plan to enabled this functionality in virt-manager? My 2nd question is in regards to nfs. It appears that I can create a pool, but get errors when trying to create volumes for VMs. I get the following in the popup: Error creating vol: Couldn't create storage volume 'test1.img': 'cannot create path '/mnt/nfspoint/test1.img': Invalid argument' Looking at the details gives: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/createvol.py", line 187, in _async_vol_create ? self.vol.install(meter=meter) File "/usr/lib/python2.6/site-packages/virtinst/Storage.py", line 905, in install (self.name, str(e))) RuntimeError: Couldn't create storage volume 'test1.img': 'cannot create path '/mnt/nfspoint/test1.img': Invalid argument' However, I can open a console and navigate to /mnt/nfspoint and I can see the images files created there, although each has zero size. They never appear in nfstest storage pool that I created though. Interestingly, I can delete the nfs volume and attempt to reinitialize it and when I do, i see the two volumes that I attempted to create earlier, even though they don't exist! I've confirmed that in fact that they don't exist via an examination of /mnt/nfspoint. So, can someone give me some advise here on how this is supposed to work and what I'm doing wrong? Thanks in advance for any help that you can give me! Regards, Mike Hinz President YR20 1718 Fry Road, Suite 440 Houston, TX ? 77084 mike.hinz at yr20.com 832-225-1293 (o) 713-594-3095 (m) 832-550-2657 (f)