December 2009 - Devel - libvirt List Archives

Re: [libvirt] [PATCH v2] Disk- and Controller Hotplug
by Wolfgang Mauerer 03 Dec '09

03 Dec '09

Hi, Some time ago, Daniel P. Berrange wrote: > On Tue, Nov 24, 2009 at 02:15:58PM +0100, Wolfgang Mauerer wrote: >> Daniel P. Berrange wrote: >>> On Mon, Nov 23, 2009 at 02:15:06PM +0100, Wolfgang Mauerer wrote: >>>> Daniel P. Berrange wrote: >>>>> Wolfgang Mauerer wrote: >> okay, to avoid flooding the mailing list with nearly identical >> patches, I've put the rebased versions into a repository at >> git://git.kiszka.org/libvirt.git queue > > I've been taking a closer look at this, and I think the final state > of patch series as a whole looks good. The minor issue is that the > intermediate patches don't compile, since they rely on compile fixes > at the end of the series. Rather than ask you to re-format the > patches yet again, I'm going to just merge the patches into a smaller > set myself. yes, I've sacrificed individual compilability when I did the forward porting because I the amount of time I can dedicate to this right now is a bit restricted for various reasons. Thanks for doing the missing cleanups! > I've got just one question I'd like to understand before doing this. > On the <disk> element's new <controller> element, you are allowing > two mutually exclusive ways of specifying the controller > > <disk> ... <controller name="<identifier>" bus="<number>" > unit="<number>"/> </disk> > > and > > <disk> ... <controller pci_addr="<addr>" bus="<number>" > unit="<number>"/> </disk> > > I think it is going to cause unneccessary pain for applications to > have to cope with two different ways of specifying the same > relationship. So my intention is to remove the 'pci_addr' variant, > since that information can easily be got directly from the separate > top level <controller> device itself Getting rid of pci_addr is perfectly okay. I've kept it in the current series for setups that don't provide <controller>s, but it's supposed to be eliminated by design. Just go ahead if you want to do this it already now ;-) > On a side note, once we've applied this initial series, I think we'll > also need to be automatically adding a <controller> element in all > guest domains which have IDE or SCSI controllers present by default. > This is going to also force us to hook into QEMU's 'info pci' monitor > command to figure out their PCI address. This is long overdue though > and needed for NIC & Disk devices added at startup too, so this is > good motivation :-) agreed. I can try to address this when I bring back hot-removal. Best regards, Wolfgang -- Siemens AG, Corporate Technology CT T DE IT 1 Corporate Competence Centre Embedded Linux

2 1

[libvirt] Re: virDomainCreate() response time
by Christopher Pyper 03 Dec '09

03 Dec '09

I am using xen with libvirt and I have very slow response times with calls to virDomainCreate(). It takes approximately 5-6 seconds to return. Other calls like virDomainReboot() or virtDomainShutdown() return immediately. Do you know what might be causing this, and how I might speed this up. Cheers.

2 1

[libvirt] Eventtest unit test failure
by Soren Hansen 01 Dec '09

01 Dec '09

Hi, guys. I've changed the libvirt package in Ubuntu to run the test suite with every build. However, on our build daemons, the eventtest unit test seems to almost[1] consistently fail. You can see an example build log here: http://launchpadlibrarian.net/36196282/buildlog_ubuntu-lucid-amd64.libvirt_… Does this look familiar to anyone? Any idea what might be causing this? FWIW, I cannot reproduce it locally, so it's likely environmental, but at this point, I don't really know where to begin to look. [1]: It actually succeeds on sparc and armel :-/ -- Soren Hansen | Lead virtualisation engineer | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/

2 3