- Devel - libvirt List Archives

[libvirt] both libvirt 0.7.4 and latest git crashing
by Nikola Ciprich 03 Dec '09

03 Dec '09

Hi, few days ago, I've reported problem with libvirt getting stuck while saving kvm. Today, I tried latest git and it seems the problem is solved which is great. Unfortunately, there seems to be another problem (which I noticed even for 0.7.4 although haven't reported yet) is that libvirtd sometimes crashes. I'm not 100% sure which action causes it to crash as it's being executed by cluster resource manager, but the backtrace might help those familiar with it's internals. (I think it's domain start) (gdb) bt #0 0x00007f4f46d03cd0 in pthread_mutex_unlock () from /lib64/libpthread.so.0 #1 0x000000000042da91 in qemuDomainObjExitMonitor (obj=0x980a80) at qemu/qemu_driver.c:287 #2 0x000000000043ca84 in qemudDomainGetInfo (dom=0x978d50, info=0x42690de0) at qemu/qemu_driver.c:3294 #3 0x00007f4f47ddf3fb in virDomainGetInfo (domain=0x978d50, info=0x42690de0) at libvirt.c:2786 #4 0x000000000041d79e in remoteDispatchDomainGetInfo (server=<value optimized out>, client=<value optimized out>, conn=0x961840, hdr=<value optimized out>, rerr=0x42690e70, args=<value optimized out>, ret=0x42690f50) at remote.c:1076 #5 0x000000000041f35c in remoteDispatchClientCall (server=0x95b780, client=0x97e310, msg=0x980b00) at dispatch.c:506 #6 0x000000000041f712 in remoteDispatchClientRequest (server=0x95b780, client=0x97e310, msg=0x980b00) at dispatch.c:388 #7 0x00000000004147e2 in qemudWorker (data=<value optimized out>) at libvirtd.c:1518 #8 0x00007f4f46d004a7 in start_thread () from /lib64/libpthread.so.0 #9 0x00007f4f46a76c2d in clone () from /lib64/libc.so.6 Could anyone please have a look at it? thanks a lot in advance nik -- ------------------------------------- Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: servis(a)linuxbox.cz -------------------------------------

2 1

[libvirt] cannot read libvirt.org website...
by Matthew Woehlke 03 Dec '09

03 Dec '09

...because of this (in http://libvirt.org/generic.css) body { margin: 0em; padding: 0px; color: rgb(0,0,0); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 80%; // font-size: 83%; } Black text on unspecified background is not legible on my setup. A background color *must* be specified when a foreground color is specified. Please fix this. (Apologies if this is not the right spot, but alas there is no webmaster AT libvirt.org, and I did not find anything obvious on who is the webmaster. If I should send this elsewhere, please let me know where.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Obscurity: +5

2 2

[libvirt] Move esxVMX_IndexToDiskName to util.c
by Matthias Bolte 03 Dec '09

03 Dec '09

I needed the inverse function to virDiskNameToIndex() for the ESX driver and added it to esx_vmx.c. The pending VirtualBox 3.1 patch needs disk index to disk name mapping too. So I want to move esxVMX_IndexToDiskName() to util.c. esxVMX_IndexToDiskName() handles indices up to 701. This limit comes from a gap in the disk name to disk index mapping of virDiskNameToIndex(): sdzy -> 700 sdzz -> 701 sdaaa -> 728 sdaab -> 729 This line in virDiskNameToIndex() causes this gap: idx = (idx + i) * 26; It can be fixed by altering this line to: idx = (idx + (i < 1 ? 0 : 1)) * 26; But this change breaks compatibility for indices > 701. So, I made two patches for either option and ask you for comments. Matthias

3 3

[libvirt] About libvirt API Support event notification mechanism problem
by ajia 03 Dec '09

03 Dec '09

Dear Daniel, Recently, I am writing test plan about libvirt asynchronous event mechanism, refering to the following bugs from the bugzilla: spice/vnc: https://bugzilla.redhat.com/show_bug.cgi?id=515268 disk error: https://bugzilla.redhat.com/show_bug.cgi?id=515270 I know libvirt can communicate with qemu monitor by QMP at present, can I use libvirt API to test it now?libvirt-0.7.4-1is ok? In addition,In qemu monitor with rhel6(2.6.31-31.el6.x86_64),"notify" command is nonexistent (Fedora12 is existent),if current qemu can't support event notification mechanism in rhel6,from libvirt point of view,I don't clear libvirt how to get asyns event notification?so I don't know how to test it.and I see qemu monitor protocol being patched,I am not sure current QMP status. I would be most grateful for any response . thank you very much. Best Regards, Alex Jia

2 1

[libvirt] [PATCH] Fix some locking issues
by Matthias Bolte 03 Dec '09

03 Dec '09

* src/conf/domain_conf.c: don't call virDomainObjUnlock twice * src/qemu/qemu_driver.c: relock driver lock if an error occurs in qemuDomainObjBeginJobWithDriver, enter/exit monitor with driver in qemudDomainSave --- src/conf/domain_conf.c | 1 - src/qemu/qemu_driver.c | 9 +++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index e9f79b7..21d509d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -5230,7 +5230,6 @@ virDomainObjIsDuplicate(virDomainObjListPtr doms, } dupVM = 1; - virDomainObjUnlock(vm); } else { /* UUID does not match, but if a name matches, refuse it */ vm = virDomainFindByName(doms, def->name); diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index bf4557e..2a63de9 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -353,6 +353,7 @@ static int qemuDomainObjBeginJobWithDriver(struct qemud_driver *driver, else virReportSystemError(NULL, errno, "%s", _("cannot acquire job mutex")); + qemuDriverLock(driver); return -1; } } @@ -3612,9 +3613,9 @@ static int qemudDomainSave(virDomainPtr dom, if (header.compressed == QEMUD_SAVE_FORMAT_RAW) { const char *args[] = { "cat", NULL }; qemuDomainObjPrivatePtr priv = vm->privateData; - qemuDomainObjEnterMonitor(vm); + qemuDomainObjEnterMonitorWithDriver(driver, vm); rc = qemuMonitorMigrateToCommand(priv->mon, 0, args, path); - qemuDomainObjExitMonitor(vm); + qemuDomainObjExitMonitorWithDriver(driver, vm); } else { const char *prog = qemudSaveCompressionTypeToString(header.compressed); qemuDomainObjPrivatePtr priv = vm->privateData; @@ -3623,9 +3624,9 @@ static int qemudDomainSave(virDomainPtr dom, "-c", NULL }; - qemuDomainObjEnterMonitor(vm); + qemuDomainObjEnterMonitorWithDriver(driver, vm); rc = qemuMonitorMigrateToCommand(priv->mon, 0, args, path); - qemuDomainObjExitMonitor(vm); + qemuDomainObjExitMonitorWithDriver(driver, vm); } if (rc < 0) -- 1.6.0.4

2 1

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 02 Dec '09

02 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

[libvirt] how do I stop libvirt futzing with my network configuration?
by Nix 30 Nov '09

30 Nov '09

So I have an existing QEMU/KVM setup with networks connected to a bridge which is routed/forwarded to the host's other interfaces. I'm trying to switch to administering at least *some* of its VMs through libvirt (probably not all as I use QEMU snapshots extensively for some of them and libvirt doesn't support that yet, if ever). So libvirt has to be able to start guests connected to a particular host bridge, and give them appropriate IP addresses. I thought it was easy to teach libvirt about this: spindle:/etc/libvirt/qemu/networks# cat /etc/libvirt/qemu/networks/default.xml <network> <name>default</name> <uuid>ee573497-1d74-473b-a2cb-9916229209b8</uuid> <forward mode='route'/> <bridge name='vm-net' stp='on' delay='0' /> <ip address='192.168.20.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.20.1' end='192.168.20.254' /> </dhcp> </ip> </network> However, there appears to be no way to say 'this is what the network is already like'. That network is considered 'inactive' and can't be used by any guests, and if I try to make it active, I get this: virsh # net-start default error: Failed to start network default error: cannot create bridge 'vm-net': File exists Of course it bloody can't create that bridge: it's already there, has an IP address on the host, and has the host routing packets to it. There appears to be no option to allow libvirt to assign IPs on the host... ... should I fix that, 'net-start' tries to update iptables rules! How should I put this: I do not *not not* want libvirt pissing with the firewall in any way at all. If I want firewall rules, I'll create them. But there's no way to tell it 'hands off! This network is already active, don't try to *make* it active!' ... at least, there's none in the documentation, and there's none in the code that I can see. Or is there?

3 11

Re: [libvirt] how do I stop libvirt futzing with my network configuration?
by Ian Woodstock 30 Nov '09

30 Nov '09

----- "Nix" <nix(a)esperi.org.uk> wrote: > From: "Nix" <nix(a)esperi.org.uk> > To: "Daniel P. Berrange" <berrange(a)redhat.com> > Cc: libvir-list(a)redhat.com > Sent: Saturday, November 28, 2009 4:10:28 PM GMT -05:00 US/Canada Eastern > Subject: Re: [libvirt] how do I stop libvirt futzing with my network configuration? > > On 26 Nov 2009, Daniel P. Berrange spake thusly: > > > On Thu, Nov 26, 2009 at 06:25:07PM +0000, Nix wrote: > >> However, there appears to be no way to say 'this is what the network is > >> already like'. That network is considered 'inactive' and can't be used by > >> any guests, and if I try to make it active, I get this: > >> > >> virsh # net-start default > >> error: Failed to start network default > >> error: cannot create bridge 'vm-net': File exists > >> > >> Of course it bloody can't create that bridge: it's already there, has an > >> IP address on the host, and has the host routing packets to it. There > >> appears to be no option to allow libvirt to assign IPs on the host... > >> > >> ... should I fix that, 'net-start' tries to update iptables rules! > >> How should I put this: I do not *not not* want libvirt pissing with the > >> firewall in any way at all. If I want firewall rules, I'll create them. > >> But there's no way to tell it 'hands off! This network is already active, > >> don't try to *make* it active!' > > > > If you don't want libvirt to create the bridge + setup IPtables rules > > then don't use the net-XXX commands / XML. That functionality is > > not there for pointing libvirt to existing bridge devices. > > > > If you already have a bridge configured, then just point the guest > > directly at that bridge by name. > > OK, I still can't make this work: it worked briefly but then stopped. > As far as I can tell tools like virt-manager are unwilling to *let* you > connect to a network considered 'inactive', and networks are only > considered active if they have a configuration file under > /var/run/libvirt/network. These files are only created if libvirt has > created the bridge itself as well. If no networks are considerd active, > virt-manager won't let you create a guest at all: it insists on trying > to start the sodding network, and when that fails doesn't let you get > any further. > I've been running with this configuration for many months on dozens of hosts. - Created a bridge (the old fashion way) in /etc/sysconfig/network-scripts Bridge called br0 with one device eth1. - Created a VM in virt manager (or edit existing) Picked "Shared Physical Device" Device "eth1 (Bridge br0)" in the GUI. Or just add it to the VMs XML <interface type='bridge'> <mac address='52:54:00:4f:0a:76'/> <source bridge='br0'/> </interface> Works like a charm and there's certainly no configuration in libvirt for this interface, ie. nothing in /var/run/libvirt/network, and *nothing* set up in Virt Manager under "Host Details->Virtual networks You do need to make sure that you disable netfilter on the bridge or setup the appropriate iptables rules ( see http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared…) > So as far as I can tell, if you don't want libvirt creating all your > bridges for you, you may as well give up hope of using virt-manager, or > start hacking all this stuff out of the source. > > I hoped I could use libvirt in conjunction with raw qemu. So much for > that, it seems :( it *really* wants to take over the world... > > > (aside: ideally I should not have to spend half an hour crawling around > the source to figure this out. The only other program I've ever seen > that was this hard to set up was Oracle! Whole *Linux distros* take less > work than this. I have half a dozen patches I'll send your way, but I > wasn't going to send any of them until I'd actually managed to get a VM > working. I got one up last night, somehow -- I no longer have any idea > how, obviously one network had somehow got marked active -- whereupon > KVM fell over. *sigh*) > > -- > Libvir-list mailing list > Libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list >

3 6