September 2009 - Devel - libvirt List Archives

[Libvir] Hang with virt-install graphic=no on FC 6 6.93/F7 RC2
by libvirtuser 23 Dec '25

23 Dec '25

I had this problem and another user confirmed the same behavior on his machine: http://pastie.caboo.se/65417 Haven't tried it with *2925.10* yet. Also, is there a way to get more verbose info about what calls are causing the "configuration file syntax error" errors? Thanks. virt-install How large would you like the disk () to be (in gigabytes)? 4 ERROR: Must provide a file, not a directory for the disk What would you like to use as the disk (path)? /xen/images/x6.img Would you like to enable graphics support? (yes or no) no What is the install location? http://mirror.anl.gov/pub/fedora-linux-core/test/6.93/Fedora/i386/os/ Starting install... libvir: Xen Daemon error : GET operation failed: libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name Retrieving Fedora... 276 kB 00:01 Retrieving vmlinuz... 100% |=========================| 2.1 MB 00:16 Retrieving initrd.img... 100% |=========================| 5.4 MB 00:28 libvir: Xen Daemon error : GET operation failed: libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name Creating domain... 0 B 00:06 Linux version 2.6.20-2925.5.fc7xen (brewbuilder(a)ls20-bc1-14.build.redhat.com) (gcc version 4.1.2 20070317 (Red Hat 4.1.2-5)) #1 SMP Thu Mar 22 13:51:38 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize bail 0 copy_e820_map() start: 0000000000000000 size: 0000000020800000 end: 0000000020800000 type: 1 Xen: 0000000000000000 - 0000000020800000 (usable) 0MB HIGHMEM available. 520MB LOWMEM available. Using x86 segment limits to approximate NX protection Zone PFN ranges: DMA 0 -> 133120 Normal 133120 -> 133120 HighMem 133120 -> 133120 early_node_map[1] active PFN ranges 0: 0 -> 133120 ACPI in unprivileged domain disabled Built 1 zonelists. Total pages: 132080 Kernel command line: method=http://mirror.anl.gov/pub/fedora-linux-core/test/6.93/Fedora/i386/os/ Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c135f000 soft=c133f000 PID hash table entries: 4096 (order: 12, 16384 bytes) Xen reported: 1694.994 MHz processor. Console: colour dummy device 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS: 2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1064 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: e1000000-f4ffe000, maxmem 2d7fe000 Memory: 503936k/532480k available (2030k kernel code, 19948k reserved, 1079k data, 180k init, 0k highmem) virtual kernel memory layout: fixmap : 0xf5315000 - 0xf57fe000 (5028 kB) pkmap : 0xf5000000 - 0xf5200000 (2048 kB) vmalloc : 0xe1000000 - 0xf4ffe000 ( 319 MB) lowmem : 0xc0000000 - 0xe0800000 ( 520 MB) .init : 0xc130e000 - 0xc133b000 ( 180 kB) .data : 0xc11fb9d9 - 0xc1309714 (1079 kB) .text : 0xc1000000 - 0xc11fb9d9 (2030 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4262.67 BogoMIPS (lpj=8525343) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 256K Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 11k freed Brought up 1 CPUs Grant table initialized NET: Registered protocol family 16 Brought up 1 CPUs PCI: Fatal: No config space access function found PCI: setting up Xen PCI frontend stub Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled xen_mem: Initialising balloon driver. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 7256k freed IA-32 Microcode Update Driver: v1.14-xen <tigran(a)veritas.com> audit: initializing netlink socket (disabled) audit(1180379657.981:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 BUG: at kernel/fork.c:994 copy_process() [<c1005d9a>] show_trace_log_lvl+0x1a/0x2f [<c1006343>] show_trace+0x12/0x14 [<c10063be>] dump_stack+0x16/0x18 [<c101d044>] copy_process+0x195/0x1245 [<c101e144>] do_fork+0x50/0x117 [<c1003351>] kernel_thread+0x8e/0x96 [<c102c701>] __call_usermodehelper+0x2d/0x46 [<c102cd4f>] run_workqueue+0x89/0x145 [<c102d711>] worker_thread+0xd5/0x102 [<c102ff27>] kthread+0xb3/0xdc [<c10058db>] kernel_thread_helper+0x7/0x10 ======================= rtc: IRQ 8 is not free. Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize input: Macintosh mouse button emulation as /class/input/input0 Xen virtual console successfully installed as xvc0 Event-channel device installed. usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI No-Shortcut mode XENBUS: Device with no driver: device/vbd/51712 XENBUS: Device with no driver: device/vif/0 Freeing unused kernel memory: 180k freed Write protecting the kernel read-only data: 762k ^[Domain installation still in progress. You can reconnect

2 1

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

In the python bindings, all vir* classes expect to be passed a virConnect object when instantiated. Before the storage stuff, these classes were only instantiated in virConnect methods, so the generator is hardcoded to pass 'self' as the connection instance to these classes. Problem is there are some methods that return pool or vol instances which aren't called from virConnect: you can lookup a storage volume's associated pool, and can lookup volumes from a pool. In these cases passing 'self' doesn't give the vir* instance a connection, so when it comes time to raise an exception crap hits the fan. Rather than rework the generator to accomodate this edge case, I just fixed the init functions for virStorage* to pull the associated connection out of the passed value if it's not a virConnect instance. Thanks, Cole diff --git a/python/generator.py b/python/generator.py index 01a17da..c706b19 100755 --- a/python/generator.py +++ b/python/generator.py @@ -962,8 +962,12 @@ def buildWrappers(): list = reference_keepers[classname] for ref in list: classes.write(" self.%s = None\n" % ref[1]) - if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]: + if classname in [ "virDomain", "virNetwork" ]: classes.write(" self._conn = conn\n") + elif classname in [ "virStorageVol", "virStoragePool" ]: + classes.write(" self._conn = conn\n" + \ + " if not isinstance(conn, virConnect):\n" + \ + " self._conn = conn._conn\n") classes.write(" if _obj != None:self._o = _obj;return\n") classes.write(" self._o = None\n\n"); destruct=None

4 3

[libvirt] race between qemu monitor startup and blocking migrate -incoming
by Charles Duffy 19 Nov '09

19 Nov '09

Howdy, 'yall. I'm having issues with virDomainRestore failing, particularly under load -- even in 0.7.0, when there's no need to parse through qemu's output to find the monitor PTY. Digging through strace output of libvirtd and the qemu processes it spawns, this is happening when qemu blocks on the migrate -incoming and ceases to respond to the monitor socket -- though some versions of qemu can go into this state before the monitor socket is even opened, leading to libvirt timing out either while attempting to open the monitor socket or while trying to read therefrom, and subsequently killing the qemu instance it spawned while that instance is still attempting to migrate in its old saved state. Both of qemu-0.11.0-rc1 and qemu-kvm master have some form of blocking in -incoming exec: which can prevent libvirt from successfully carrying through a resume; I have reproduced the issue (and maintain logs from strace, available on request) irrespective of the state of Chris Lalancette's "Fix detached migration with exec" and "Allow monitor interaction when using migrate -exec" patches. The qemu binaries being used _appear_ to correctly allow monitor interaction prior to -incoming exec:... completion when interactively invoked in the trivial case shown below: $ qemu-system-x86_64 \ -monitor stdio \ -nographic \ -serial file:/dev/null \ -incoming 'exec:sleep 5; echo DONE >&2; kill $PPID' \ /dev/null QEMU 0.10.91 monitor - type 'help' for more information (qemu) DONE $ ...however, whether these same binaries work as-expected when invoked from libvirt by our automated test system under load is nondeterministic. (I have yet to reproduce the issue in a low-load environment using "virsh restore"). Is someone else working on this? Is a known-good (or believed-good) libvirt/qemu pair available? What can I do to help in getting this issue resolved? Thanks! --- libvirt-0.7.0 + qemu-kvm-0.11.0-rc1 qemudReadMonitorOutput:728 : internal error Timed out while reading monitor startup output libvirt-0.6.5 + qemu-kvm-0.11.0-rc1 error : qemudReadMonitorOutput:705 : internal error Timed out while reading monitor startup output error : qemudWaitForMonitor:1003 : internal error unable to start guest: char device redirected to /dev/pts/9 libvir: QEMU error : internal error unable to start guest: char device redirected to /dev/pts/9 ^^ particularly interesting, as the above line should have been eaten by qemudExtractMonitorPath rather than emitted as error text --- <aliguori> -incoming is blocking <aliguori> you cannot interact with the monitor during -incoming <mDuff> ...shouldn't we always be opening the monitor before starting the blocking -incoming bits, though? I don't always see that happening (and have an strace handy where it certainly doesn't). <aliguori> no <aliguori> well, i think they added some patches for that <aliguori> but originally, that's not how it worked <aliguori> and i think it's silly to work that way <aliguori> -incoming should mean, wait patiently for an incoming migration <aliguori> there's no point in interfacing with the monitor in the interim <mDuff> I agree that interacting may not be called for, but at least connect()ing -- if it's a UNIX socket, the other side won't be able to connect at all until qemu goes first... <aliguori> heh, well.... <aliguori> that particular race condition is addressed by -daemonize <aliguori> because that's generally true <aliguori> you don't know how long qemu will take to open the monitor <aliguori> but -daemonize makes gives you notification because it doesn't daemonize the process until you've gotten to the point where all sockets are open <aliguori> but IIRC, libvirt doesn't use -daemonize

3 2

[libvirt] 0.7.1 compile fails on opensuse 11.1
by Dominik Klein 30 Oct '09

30 Oct '09

Hi it seems openSuSE 11.1 does not come with a pkgconfig for the device-mapper-devel package. I created a bug [1] for opensuse but was also told to mention it here so configure.in could be patched once the bug was fixed. Regards Dominik 1 https://bugzilla.novell.com/show_bug.cgi?id=54094

4 9

[libvirt] [PATCH 0/4] Support for SPICE graphics
by Daniel P. Berrange 28 Oct '09

28 Oct '09

This series of patches adds minimal support for SPICE graphics which is newly introduced in RHEL-5.4's fork of KVM. Since this is not yet merged in upstream QEMU/KVM, I'm not proposing to merge all these patches. The two XML schema patches are straightforward to merge. The two implementation ones are RHEL5 specific and I want to avoid declaring them supported until we have a sign of what the upstream merge will look like, since previous attempst to support KVM args prior to QEMU acceptance have been very painful long term. Daniel

3 14

[libvirt] [RFC] Support for CPUID masking
by Jiri Denemark 16 Oct '09

16 Oct '09

Hi, We need to provide support for CPU ID masking. Xen and VMware ESX are examples of current hypervisors which support such masking. My proposal is to define new 'cpuid' feature advertised in guest capabilities: <guest> ... <features> <cpuid/> </feature> </guest> When a driver supports cpuid feature, one can use it to mask/check for specific bits returned by CPU ID as follows: <domain> ... <features> <cpuid> <mask level='hex' register='eax|ebx|ecx|edx'>MASK</mask> </cpuid> </features> ... </domain> Where - level is a hexadecimal number used as an input to CPU ID (i.e. eax register), - register is one of eax, ebx, ecx or edx, - and MASK is a string with the following format: mmmm:mmmm:mmmm:mmmm:mmmm:mmmm:mmmm:mmmm with m being 1-bit mask for the corresponding bit in the register. There are three possibilities of specifying what values can be used for 'm': - let it be driver-specific, - define all possible values, - define a common set of values and allow drivers to specify their own additional values. I think the third is the way to go as it lowers the confusion of different values used by different drivers for the same purpose while maintaining the flexibility to support driver-specific masks. The following could be a good set of predefined common values: - 1 force the bit to be 1 - 0 force the bit to be 0 - x don't care, i.e., use driver's default value - T require the bit to be 1 - F require the bit to be 0 Some examples of what it could look like follow: <capabilities> ... <guest> <os_type>xen</os_type> ... <features> <pae/> <cpuid/> </features> </guest> ... </capabilities> <domain type='xen' id='42'> ... <features> <pae/> <acpi/> <apic/> <cpuid> <mask level='1' register='ebx'> xxxx:xxxx:0000:1010:xxxx:xxxx:xxxx:xxxx </mask> <mask level='1' register='ecx'> xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xx1x:xxxx </mask> <mask level='1' register='edx'> xxx1:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx </mask> <mask level='80000001' register='ecx'> xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xx1x </mask> <mask level='80000008' register='ecx'> xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xx00:1001 </mask> </cpuid> </features> ... </domain> What are your opinions about this? Thank for all comments. Jirka

8 12

[libvirt] [PATCH 0/9] Support disk-hotremove and controller hotplugging
by Wolfgang Mauerer 13 Oct '09

13 Oct '09

Hi, this patch reworks libvirt's disk-hotadd support and introduces support for disk controller hotplugging and disk-hotremove (see http://thread.gmane.org/gmane.comp.emulators.libvirt/15860 for more details). Currently, it targets only qemu and also requires some additions to qemu that have only recently been submitted, which is why this is cross-posted to qemu-devel. Hopefully the lack of support in qemu does not prevent the community from reviewing the code, though ;-) Notice that no documentation and testcases are included yet; I'll supply those once the interface is fixed and possible issues are settled. Thanks for your comments, Wolfgang docs/schemas/domain.rng | 145 ++++++++++---- src/domain_conf.c | 208 ++++++++++++++++++++- src/domain_conf.h | 39 ++++- src/libvirt_private.syms | 4 +- src/qemu_driver.c | 479 +++++++++++++++++++++++++++++++++++++++++++--- 5 files changed, 802 insertions(+), 73 deletions(-) -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux

5 26

[libvirt] Tentative schedule for next release
by Daniel Veillard 09 Oct '09

09 Oct '09

I'm suggesting to try to push 0.7.2 around Fri 16 Oct, we already have a number of cleanup patches in and serious improvements for ESX driver. If we go with that plan I think patches and big changes should be pushed in the tree by Fri 9, this includes among other things the AppArmor security driver. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 3

[libvirt] Resubmission #2: [PATCH 0/3] sVirt AppArmor security driver
by Jamie Strandboge 08 Oct '09

08 Oct '09

Resubmitting again based on feedback from this list. Notably, the driver has been reworked to use: xml = virDomainDefFormat(conn, vm->def, ... Then the helper program uses: ctl->def = virDomainDefParseString(... xmlStr ...); This simplifies adding new files. Part of this process involved adding support for kernel, initrd, loader, serial, and console. I have commented out code for hostdev (and pci would be easy enough), but it requires a patch to to move the _usbDevice struct fully into hostusb.h. I figure once the AppArmor driver is in, I can submit a patch for that. This iteration also properly works with attach/detach. While I use virDomainDefFormat() primarily, this does not work with attach because the definition is not updated with the information yet (neither def nor newDef), so I pass the disk file on the command line. For now this is ok since SetSecurityImageLabel currently only deals with a single file, but this will need to be adjusted depending on how the storage backend patch works out. I thought about creating a new def and inserting the disk into it and sending it off to virt-aa-helper, but I couldn't find an easy way to get an accurate virCapsPtr in security_apparmor.c. I had a similar problem with virt-aa-helper, but there I just created a fake virCapsPtr (which defaults to 'hvm', which was a compromise I was willing to make at this time since sVirt only supports qemu right now). The issues with virCapsPtr aside, the code is overall cleaner and much more easily extendable, so thanks for the excellent feedback. :) The patches are against up to date trunk, compiles with no warnings, 'make check' passes for the tests I added, and the code passes syntax-check. With the exception of the three calls to strncpy I had to convert to virStr*, this is the code that is currently in Ubuntu 9.10 (0.7.0-1ubuntu8). Among other things, that means 9.10 now has your preferred licensing. [PATCH 1] patch_1_reenable-nonfile-labels.patch (Updated based on prior feedback): When James Morris originally submitted his sVirt patches (as seen in libvirt 0.6.1), he did not require on disk labelling for virSecurityDomainRestoreImageLabel. A later commit[2] changed this behavior to assume on disk labelling, which halts implementations for path-based MAC systems such as AppArmor and TOMOYO where vm->def->seclabel is required to obtain the label. This patch simply adds the 'virDomainObjPtr vm' argument back to *RestoreImageLabel. [PATCH 2] patch_2_apparmor_driver.patch (updated and merged into one patch based on prior feedback): - Updates src/security.c for AppArmor - Adds security_apparmor.c, security_apparmor.h, virt-aa-helper.c and updates po/POTFILES.in. virt-aa-helper.c is a new binary which is used exclusively by the AppArmor security driver to manipulate AppArmor. - Adds tests for virt-aa-helper and the security driver. secaatest.c is identical to seclabeltest.c except it initializes the 'apparmor' driver instead of 'selinux'. These tests are integrated into 'make check' and pass. - Updates configure.in, Makefile.am, src/Makefile.am, tests/Makefile.am, and tools/Makefile.am for AppArmor. It is based on and should operate the same as the SELinux configuration. [PATCH 3] patch_3_docs.patch (Updated based on prior feedback): Updates docs/drvqemu.html.in for AppArmor and adds profile examples to examples/apparmor. Updated based on prior feedback. Jamie On Fri, 04 Sep 2009, Jamie Strandboge wrote: > This patch series implements the AppArmor security driver for sVirt. > This implementation was developed for the Ubuntu AppArmorLibvirtProfile > specification[1], but is general enough for any AppArmor deployment > (such as Ubuntu, *SUSE and Mandriva). > > This patch has seen quite a bit of real world testing in Ubuntu 9.10 > (our development release) in our 0.7.0-1ubuntu3 package. I did make a > few small changes after going through HACKING, but mostly I got the > tests going and added documentation. > > DESIGN > ------ > When a virtual machine is started, determine if a profile is currently > defined for the machine, and use it if available. If not, generate a new > profile for the machine based on a template, which is by default a very > restrictive profile allowing access to disk files, and anything else > needed to run, such as the pid, monitor and log files. > > Virtual machines should have a unique profile specific to that machine. > To ensure uniqueness, the profile name will be derived from the UUID of > the virtual machine. These profiles should be configurable, either by > adjusting the profile template for new machines, creating/modifying the > VM profile directly or through the use of AppArmor abstractions. This > will allow for administrators to fine-tune confinement for individual > machines if desired. > > If enabled at compile time, the sVirt security model will be activated > if AppArmor is available on the host OS and a profile for the libvirtd > daemon is loaded when libvirtd is started. > > libvirtd should not be allowed to create arbitrary profiles or modify > profiles directly, so as to not allow libvirtd to potentially (ie via a > security bug in libvirtd itself) bootstrap out of AppArmor confinement. > > Because root privileges are needed to manipulate AppArmor profiles, > qemu:///session will not be supported at this time, but the > implementation must allow for a confined libvirtd with qemu:///session > guests running unconfined. This can be revisited when AppArmor supports > per-user profiles. > > Please see the specification[1] for more details. -- Jamie Strandboge | http://www.canonical.com

3 12

[libvirt] [PATCH] in vbox driver, interface type bridge should really be type ethernet
by Florian Vichot 08 Oct '09

08 Oct '09

If I understand correctly, the "bridge" type for an interface means libvirt is in charge of creating a tun device and adding it to the specified bridge in the <source bridge=".."> attribute. This is not what the (badly named IHMO) "Bridged Networking" mode in vbox does: all it does is read and write its packets on the specified interface. Which is what a type "ethernet" interface does in my opinion. I joined a quick patch for that, Pritesh could you check it ? Also, I was about to patch to add support for the proper "bridge" mode in the vbox driver (because it's what I need in the end), but I see no way of storing the fact that it's not just an "ethernet" interface using the vbox API, so that the config would persist over libvirtd restarts. There is always the possibility of naming the interface a special way like "br1_myTap", and assume any type "ethernet" interface with a device containing a "br1_" prefix would actually be a type "bridge" interface with an associated "vbox_br1" bridge. Would that be acceptable, or is it too hackish ? BTW, just to make sure, I can use pretty much anything as a <target> ie. ethN, panN etc in a type "ethernet" interface, right ? If <target> is specified, it's not going to create a tun and use that ? Thanks, Florian

4 6