May 2007 - 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

[Libvir] RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
by Daniel P. Berrange 27 Feb '08

27 Feb '08

One user's feature request for our QEMU driver is to support serial ports. Easy you might think... you'd be wrong :-) On Xen we have very simple approach. When creating a guest simply add <console/> And it'll cause a serial port to be setup with an autoallocated pty, so you get back <console pty='/dev/pts/5'/> In retrospect calling it 'console' was dumb, but hey we're stuck with that now and its only a tiny naming issue so I don't mind really. We can do the same thing with QEMU quite easily. QEMU, however, supports many many many more ways to hooking up the serial port to Dom0. Indeed so does Xen fullyvirt, but we don't expose this ability. Parallel ports have identical config syntax to serial ports so we might as well deal with both at once. So, here's a stripped down version of the QEMU docs: [quote http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10] `-serial dev' Redirect the virtual serial port to host character device dev. The default device is vc in graphical mode and stdio in non graphical mode. This option can be used several times to simulate up to 4 serials ports. Use -serial none to disable all serial ports. Available character devices are: vc Virtual console pty [Linux only] Pseudo TTY (a new PTY is automatically allocated) none No device is allocated. null void device /dev/XXX [Linux only] Use host tty, e.g. `/dev/ttyS0'. The host serial port parameters are set according to the emulated ones. /dev/parportN [Linux only, parallel port only] Use host parallel port N. Currently only SPP parallel port features can be used. file:filename Write output to filename. No character can be read. stdio [Unix only] standard input/output pipe:filename name pipe filename COMn [Windows only] Use host serial port n udp:[remote_host]:remote_port[@[src_ip]:src_port] This implements UDP Net Console. tcp:[host]:port[,server][,nowait][,nodelay] The TCP Net Console has two modes of operation. telnet:host:port[,server][,nowait][,nodelay] The telnet protocol is used instead of raw tcp sockets. unix:path[,server][,nowait] A unix domain socket is used instead of a tcp socket. [/quote] I don't see any reason to not support all/most of these options. The things I don't like here is that /dev/XXX, vs /dev/parportN, vs COMn differences for connecting guest <-> host passthrough of the devices. I figure it could be simpler if it was just represented as 'n' and we'd translate that to be /dev/ttyS[n] or /dev/parport[n] or COM[n] as needed. The question as ever is how to represent this in XML. For serial ports we'll stick with '<console>', while parallel ports we might as well use a better named '<parallel>'. Next up, I think should use a 'type' attribute on this element to determine the main way ot connecting the device, and then more type specific attributes or sub-elements as needed. If 'type' was not specified then use a default of 'pty', since that gives compatability with existing practice. As an illustrative example /* * Parse the XML definition for a character device * * Top level node will be <console> or <parallel>, but all attributes * and sub-elements are identical. * * type=vc|pty|null|host|file|pipe|udp|tcp|telnet, default is pty * * <console type='vc'/> * * <console type='pty' pty='/dev/pts/3'/> * * <console type='null'/> * * <console type='host' port='3'/> * * <console type='file' path='/some/file'/> * * <console type='pipe' path='/some/file'/> * * <console type='udp'> * <sendto port='12356'/> * </console> * * <console type='udp'> * <sendto addr='127.0.0.1' port='12356'/> * </console> * * <console type='udp'> * <sendto addr='127.0.0.1' port='12356'/> * <bind port='12356'/> * </console> * * <console type='udp'> * <sendto addr='127.0.0.1' port='12356'/> * <bind addr='127.0.0.1' port='12356'/> * </console> * * <console type='tcp'> * <listen port='12356'/> * </console> * * <console type='tcp'> * <listen addr='127.0.0.1' port='12356'> * <nowait/> * <nodelay/> * </listen> * </console> * * <console type='tcp'> * <connect addr='127.0.0.1' port='12356'> * <nodelay/> * </connect> * </console> * * <console type='telnet'> * <listen addr='127.0.0.1' port='12356'/> * </console> * * <console type='telnet'> * <connect addr='127.0.0.1' port='12356'/> * </console> * */ BTW, the udp, tcp, telnet options are only available on QEMU >= 0.9.0. We already have ability to detect / validate that for both Xen & QEMU drivers. NB, whereever there are IP addresses, hostnames can be used too, hence I call the attriute 'addr' instead of 'ip' Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

5 8

[Libvir] virsh vcpupin does not work with xend
by Saori Fukuta 06 Jul '07

06 Jul '07

Hi, The virsh vcpupin command does not work when it uses Xend(xend_internal.c). HV(xen_internal.c) works fine. I'm testing on Xen3.1.0(hypervisor_version=2, dom_interface_version=5, xendConfigVersion=4), and using current libvirt(ChangeLog revision 1.546). To solve this problem, I got the xend debug information and compared that. * in the case of executing "virsh vcpupin 63 7 1" * [2007-05-29 09:33:20 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'str'>) * in the case of executing "xm vcpu-pin 63 7 1" * [2007-05-29 09:33:32 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'list'>) There is one different thing. The type of cpumap is str when executing virsh command, but the type of cpumap is list when executing xm command. Do you have any idea ? Thanks, Saori Fukuta

2 4

Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: >> >> Daemon though? Can't the libvirt code just invoke the OpenVZ commands >> directly? > > Yeah, that is very much possible. But if it were a daemon, it could be > a Python daemon, since text processing is much simpler and I don't > have to use the str*( ) funcs in C. What is your comment? I'm a big advocate of using a sane language instead of C, but libvirt is written in C for better or worse. The problem with a separate daemon is management of that daemon. Something needs to start it and stop it, it needs to have sockets with the right permissions and so on. What happens if the process runs and can't find the daemon? What is the path to the socket? etc. etc. At the moment we have two daemons - the qemu daemon (which has two separate functions intertwined), and a remote daemon (necessary, because there's no other way to communicate to a remote machine). One idea would be to have the Python code fork off from the main program and communicate over a pipe. With this, there is no daemon management problem. +----------------+ | Program | | - - - - - - - -| | libvirt | +----------------+ | | fork(2) and pipe(2) | +-------------+ | Python code | +-------------+ But I'm not the person who ultimately decides what would be acceptable in libvirt. You'd need to get general agreement on the best way to do this. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 7

[Libvir] [RFC] Device attach/detach on virsh
by Masayuki Sunou 19 Jun '07

19 Jun '07

I want to add I/F to do attach/detatch of VIF and VBD to virsh with virDomainAttachDevice()/virDomainDetachDevice(). And, I have two proposals about I/F for virsh to do attach/detach of VIF and VBD. proposal 1: Virsh catches MAC, bridge name, device name (physical,virtual), and another by the command option. ex) ------------------------------------------------------------------ # virsh help attach(detach)-vif(vbd) NAME attach(detach)-vif(vbd) - attach(detach) vif(vbd) SYNOPSIS * VIF attach(detach)-vif <domain> <MAC> <bridge> ... or * VBD attach(detach)-vbd <domain> <virt-dev> ... DESCRIPTION Attach(Detach) vif(vbd) device OPTIONS <domain> domain name, id or uuid * VIF <MAC> MAC address of vif <bridge> bridge name of vif ... * VBD <virt-dev> virtual device name of vbd <phy-dev> physical device name of vbd ... ------------------------------------------------------------------ <advantage> - I/F is easy to use than proposal 1. (Because the user does not have to make XML) <disadvantage> - I/F increases because I/F of VIF and VBD becomes separate. (So, the addition of I/F is necessary at any time for supporting devices other than VIF and VBD. ) - Handling of optional analysis, handling of XML making are necessary in virsh.c, and processing becomes complicated. proposal 2: virsh catches a definition of a device by XML ex) ------------------------------------------------------------------ # virsh help attach(detach)-device NAME attach(detach)-device - attach(detach) device from an XML file SYNOPSIS attach(detach)-device <domain> <file> DESCRIPTION Attach(Detach) device from an XML <file> OPTIONS <domain> domain name, id or uuid <file> XML file of device description ------------------------------------------------------------------ <advantage> - I/F is unified without affecting a device type. (I/F is simple) - Handling of virsh.c is simple. (Optional analysis is not necessary) <disadvantage> - The user has to describe XML.(It is troublesome) I think that specifications that a user is easy to use (proposal 1) are better. Please, give me an opinion which proposal is better. Thanks, Masayuki Sunou

6 28

[Libvir] Storage manager initial requirements and thoughts
by Hugh Brock 15 Jun '07

15 Jun '07

Hi all. At the Red Hat virtualization team meeting last week we spent some time talking about the problem of remote storage management, which is a requirement for at the very least creating remote guests. Remote storage management also delivers a lot of benefits for managing guest storage, provisioning, and a host of other issues. Note that we don't (I think) believe that storage management should be part of libvirt. However we might want to be able to grab storage information with libvirt when creating a guest, for example. Here's the tentative requirements we came up with, along with several questions that came up. We have two important use cases for remote storage management: --Create a new guest against an existing physical device --Create a new guest against a file on an existing physical device (SELinux context must match up on both) Requirements: 2 key requirements: enumerate devices, create files * Enumerate devices (unallocated disks) * storage pool * Unallocated space * Allocated volumes -- free -- in use * Read only / Read-write * Host availability * Volume -- Global unique name -- Local device name -- Usage -- Mounted locally -- Assigned to guest read only shared exclusive -- Inactive guest * Create a backing store for a guest * need to know what storage is available * Can be plain file * Can be a physical partition (local scsi/IDE, SAN) * Can be a logical volume * Can be network - iscsi/nbd Cases: Physical device --> create partitions Volume group --> create logical volumes Directory --> create files Todos: Investigate gparted, one of the partition management tools we already have (apis? remote accessibility?) (I believe Jim Meyering volunteered to take a look at this?) Identify what other scenarios we need to address. Please comment; I'm hoping we can get these into a more definite form sooner rather than later. -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

10 43

[Libvir] [PATCH] output virsh log to file
by Nobuhiro Itou 07 Jun '07

07 Jun '07

Hi, I made the patch which output debug messages and error messages of virsh to the log file. I think that it is necessary to leave logs to the file for the investigation at the failure. Debug messages can take appointed optional information, and error messages will make it easy to specify a cause. Moreover, I'm thinking about outputting virterror information to the virsh log file by the next step. It is simple specifications as follows. * Destination -- <USER HOME>/.virsh/virsh.log * Log size -- 1MB(1024*1024) * Number of Rotations -- 5 * There is process exclusion. First, will you take in this patch ? And, I have a plan to enhance logging functionality. (for example, libvirt error logging) Signed-off-by: Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com> Thanks, Nobuhiro Itou.

6 18

[Libvir] [PATCH] Cut out "type=ioemu" on Xen3.1
by Saori Fukuta 07 Jun '07

07 Jun '07

Hi, The definition of (type ioemu) is *not* required by Xen3.1. So I cut out it when xendConfigVersion is 4 or later. Signed-off-by: Saori Fukuta <fukuta.saori(a)jp.fujitsu.com> Thanks, Saori Fukuta. Index: xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.73 diff -u -p -r1.73 xml.c --- xml.c 23 Apr 2007 07:41:23 -0000 1.73 +++ xml.c 31 May 2007 07:02:01 -0000 @@ -1047,6 +1047,7 @@ virDomainParseXMLDiskDesc(virConnectPtr * @conn: pointer to the hypervisor connection * @node: node containing the interface description * @buf: a buffer for the result S-Expr + * @xendConfigVersion: xend configuration file format * * Parse the one interface the XML description and add it to the S-Expr in buf * This is a temporary interface as the S-Expr interface @@ -1056,7 +1057,7 @@ virDomainParseXMLDiskDesc(virConnectPtr * Returns 0 in case of success, -1 in case of error. */ static int -virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm) +virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm, int xendConfigVersion) { xmlNodePtr cur; xmlChar *type = NULL; @@ -1129,7 +1130,8 @@ virDomainParseXMLIfDesc(virConnectPtr co virBufferVSprintf(buf, "(script '%s')", script); if (ip != NULL) virBufferVSprintf(buf, "(ip '%s')", ip); - if (hvm) + /* HVM type ioemu config for xen < 3.1 */ + if (hvm && xendConfigVersion < 4) virBufferAdd(buf, "(type ioemu)", 12); virBufferAdd(buf, ")", 1); @@ -1335,7 +1337,7 @@ virDomainParseXMLDesc(virConnectPtr conn if (nb_nodes > 0) { for (i = 0; i < nb_nodes; i++) { virBufferAdd(&buf, "(device ", 8); - res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm); + res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm, xendConfigVersion); if (res != 0) { free(nodes); goto error; @@ -1494,7 +1496,7 @@ virParseXMLDevice(virConnectPtr conn, ch goto error; } else if (xmlStrEqual(node->name, BAD_CAST "interface")) { - if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0) + if (virDomainParseXMLIfDesc(conn, node, &buf, hvm, xendConfigVersion) != 0) goto error; } cleanup:

3 6

Re: [Libvir] [PATCH] add scheduler API(take 3?)
by Richard W.M. Jones 04 Jun '07

04 Jun '07

+char * +virDomainGetSchedulerType(virDomainPtr domain, int *nparams) +{ + virConnectPtr conn; + char *schedtype; + + if (domain == NULL) { + TODO + return NULL; + } Is this case an error, or were you thinking of adding more semantics later on here? (and the same comment for virDomainGet/SetSchedulerParameters) +static int +cmdSchedinfo(vshControl * ctl, vshCmd * cmd) +{ [...] + char *str_weight = strdup("weight"); + char *str_cap = strdup("cap"); + + nparams = malloc(sizeof(int)); + *nparams = 0; + + if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) + return FALSE; There's still a problem memory leak here. + /* Currently supports Xen Credit only */ + weight = vshCommandOptInt(cmd, "weight", &weightfound); + if(weightfound){ inputparam++; } + + cap = vshCommandOptInt(cmd, "cap", &capfound); + if(capfound){ inputparam++; } and can this be made so it isn't Xen-specific? + if ((domain == NULL) || (domain->conn == NULL)) + return -1; + + priv = (xenUnifiedPrivatePtr) domain->conn->privateData; + if (priv->handle < 0 || domain->id < 0) + return -1; At the lowest level, these functions should return error messages back to the upper layers. Otherwise users have nothing to diagnose errors with. + /* + * Support only dom_interface_version >=5 + * (Xen3.1.0 or later) + */ + if (dom_interface_version < 5) + return -1; Is this because earlier hypervisors didn't support this, or is it just not implemented? Rich.

3 7

[Libvir] [PATCH] Fix strange error message in virsh attach-device
by Masayuki Sunou 04 Jun '07

04 Jun '07

Hi Now, virsh attach-device displays the following messages when "device" attribute of "disk" element is "floppy" in XML. # virsh attach-device HVM_RH4_file floppy.xml libvir: Xen Daemon error : POST operation failed: (xend.err 'Invalid Configuration: XendConfig: @\x14\xce not a valid device type') error: Failed to attach device from floppy.xml This patch fixes this strange error message displaying "@\x14\xce". Description of this patch VirDomainParseXMLDiskDesc() returns 0 without putting data in virBuffer, when "floppy" is set. Therefore, virParseXMLDevice() returns no initialized data, and xenDaemonAttachDevice() passes Xen this data. Because virDomainParseXMLDesc() works wrong when this patch changes return value of VirDomainParseXMLDiskDesc(),this patch fixes virParseXMLDevice() as follows. - Initialize data - Return error if data does not change. As a result, xenDaemonAttachDevice() doesn't pass strange data to Xen, and Xen doesn't return strange error message. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. ---------------------------------------------------------------------- Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.73 diff -u -p -r1.73 xml.c --- src/xml.c 23 Apr 2007 07:41:23 -0000 1.73 +++ src/xml.c 25 May 2007 09:46:56 -0000 @@ -1481,6 +1481,7 @@ virParseXMLDevice(virConnectPtr conn, ch return (NULL); buf.size = 1000; buf.use = 0; + memset(buf.content, 0, (size_t)buf.size); xml = xmlReadDoc((const xmlChar *) xmldesc, "domain.xml", NULL, XML_PARSE_NOENT | XML_PARSE_NONET | XML_PARSE_NOERROR | XML_PARSE_NOWARNING); @@ -1492,6 +1493,9 @@ virParseXMLDevice(virConnectPtr conn, ch if (xmlStrEqual(node->name, BAD_CAST "disk")) { if (virDomainParseXMLDiskDesc(conn, node, &buf, hvm, xendConfigVersion) != 0) goto error; + /* SXP is not created when device is "floppy". */ + else if (!strlen(buf.content)) + goto error; } else if (xmlStrEqual(node->name, BAD_CAST "interface")) { if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0) ----------------------------------------------------------------------

2 5

[Libvir] cannot use vncviewer and VMM graphics console to access HVM guest on RHES 5
by Glen Deem 01 Jun '07

01 Jun '07

Hi all, I've created an HVM guest under RHES 5 (Xen 3.0.3) using "xm create" but I cannot access it with vncviewer. The Virtual Machine Manager also informs about graphics console unavailability. What am I doing wrong, please? I do > vncviewer 123.456.789.123:4, where 4 is the guest id. This is the xm config file is: name = "hvmGuest" builder = "hvm" memory = "500" disk = [ 'file:/var/lib/red-hat.img,hda,w', ] vif = [ 'type=ioemu, mac=00:16:3e:34:3b:ba, bridge=xenbr0', ] device_model = "/usr/lib/xen/bin/qemu-dm" kernel = "/usr/lib/xen/boot/hvmloader" vnc=1 vncunused=1 apic=1 acpi=1 pae=1 vcpus=1 serial = "pty" on_reboot = 'restart' on_crash = 'restart' Thanks a lot in advance. Glen from Ottawa, Canada

3 2

Re: [Libvir] Debian package structure
by Marco Sinhoreli 01 Jun '07

01 Jun '07

On 5/30/07, Richard W.M. Jones <rjones(a)redhat.com> wrote: > > Marco Sinhoreli wrote: > > hello all, > > > > I have been worked in libvirt, virt-manager and virtinst packages to > > Debian for a weeks. Packages are now stabilized. Following below the > > /debian directories structure for analise. > > * libvirt: > > svn co http://svn.mussicorp.net/projetos/src/xen/libvirt/trunk/ > > In debian/rules you shouldn't need this any longer (with latest CVS): > > export CFLAGS += -fno-stack-protector I know it is fixed for libvirt, but it is nedded to fix virt-manager too. That's why I keep it in this package. > * Virt-manager: > > svn co > > > http://svn.mussicorp.net/projetos/src/xen/virt-manager/virt-manager/trunk/ > > Shouldn't virt-manager Depends: on python-libvirt and virtinst? My fault. I'll fix it. It should probably Build-Depends: on (eg) cdbs too, since firstly you're > using cdbs in debian/rules, and secondly virt-manager isn't pure Python > - it contains a C-based widget. okay. I'll pay attention on that. Not clear what the postrm was for. Is there configuration kept in > /usr/share/virt-manager? My fault. I'll checked it. Thanks

1 0

[Libvir] Debian package structure
by Marco Sinhoreli 31 May '07

31 May '07

hello all, I have been worked in libvirt, virt-manager and virtinst packages to Debian for a weeks. Packages are now stabilized. Following below the /debian directories structure for analise. * libvirt: svn co http://svn.mussicorp.net/projetos/src/xen/libvirt/trunk/ * Virt-manager: svn co http://svn.mussicorp.net/projetos/src/xen/virt-manager/virt-manager/trunk/ * Virtinst: svn co http://svn.mussicorp.net/projetos/src/xen/virt-manager/virtinst/trunk/ Best regards, -- Marco Sinhoreli

2 1

Re: [Libvir] Error while run make: undefined reference to `xenHypervisorMakeCapabilitiesXML'
by Marco Sinhoreli 30 May '07

30 May '07

Thanks, I had a problem with my libxen package. The /usr/lib/libxenstore.so wasn't linked to /usr/lib/libxenstore.so.3.0.0. Regards, > > On 5/29/07, Daniel Veillard <veillard(a)redhat.com> wrote: > > > > On Mon, May 28, 2007 at 11:26:18AM -0400, Daniel Veillard wrote: > > > On Mon, May 28, 2007 at 12:15:31PM -0300, Marco Sinhoreli wrote: > > > > Hello list, > > > > > > > > I'm with this error while I am compiling the libvirt: > > > > > > > > xencapstest.o: In function `testCompareFiles': > > > > /usr/src/libvirt/tests/xencapstest.c:33: undefined reference to > > > > `xenHypervisorMakeCapabilitiesXML' > > > > collect2: ld returned 1 exit status > > > > > > > > Any idea? > > > > > > What version ? I guess it comes when compiling on a machine where > > > Xen developments environment is not present, this ought to be fixed > > > if not already in CVS, > > > > actually I can reproduce that to on CVs head, will fix ! > > > > Daniel > > > > -- > > Red Hat Virtualization group http://redhat.com/virtualization/ > > Daniel Veillard | virtualization library http://libvirt.org/ > > veillard(a)redhat.com | libxml GNOME XML XSLT toolkit > > http://xmlsoft.org/ > > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > > > > > > -- > Marco Sinhoreli -- Marco Sinhoreli

1 0

Re: [Libvir] Finally - fix the build on Debian
by Marco Sinhoreli 30 May '07

30 May '07

Hello, I compiled the libvirt from last cvs source without to export CFLAGS -fstack-protector option without problem. After it, I compiled the virt-manger and it isn't working. Running virt-manager retur this error: virt-manager Traceback (most recent call last): File "/usr/share/virt-manager/virt-manager.py", line 104, in ? from virtManager.config import vmmConfig File "/usr/share/virt-manager/virtManager/config.py", line 24, in ? import libvirt File "/usr/lib/python2.4/site-packages/libvirt.py", line 7, in ? import libvirtmod ImportError: /usr/lib/libvirt.so.0: undefined symbol: __stack_chk_guard Also is necessáry correction in virt-manager code? regards, On 5/29/07, Richard W.M. Jones <rjones(a)redhat.com> wrote: > > > Daniel Veillard wrote: > > > On Tue, May 29, 2007 at 03:21:48PM +0100, Richard W.M. Jones wrote: > > >> The attached patch fixes three separate build problems on Debian: > > >> > > >> (1) The libtool autoconf macro is wrong in that it requires a C++ > > >> compiler and /lib/cpp, neither of which seems to be really needed. > > >> > > >> (2) If you pass -fstack-protector while compiling, then you also need > > to > > >> pass it while linking, so that gcc knows to link -lssp. > > >> > > >> (3) Long-standing problem that xencapstest.c won't compile > > --without-xen. > > >> > > >> Well, OK so I didn't actually fix (1), but I did add a note to the > > TODO > > >> file pointing out the problem. So you'll still need to install the > > >> Debian "g++" package before you can compile libvirt. > > > > > > None of this is actually Debian specific, it actually affects various > > setups. > > > Patch looks fine to me, > > > > Committed. > > > > Rich. > > > > -- > > Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/<http://et.redhat.com/%7Erjones/> > > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in > > England and Wales under Company Registration No. 03798903 > > > > -- > > Libvir-list mailing list > > Libvir-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list > > > > > > > > > -- > Marco Sinhoreli -- Marco Sinhoreli

1 0

[Libvir] Finally - fix the build on Debian
by Richard W.M. Jones 30 May '07

30 May '07

The attached patch fixes three separate build problems on Debian: (1) The libtool autoconf macro is wrong in that it requires a C++ compiler and /lib/cpp, neither of which seems to be really needed. (2) If you pass -fstack-protector while compiling, then you also need to pass it while linking, so that gcc knows to link -lssp. (3) Long-standing problem that xencapstest.c won't compile --without-xen. Well, OK so I didn't actually fix (1), but I did add a note to the TODO file pointing out the problem. So you'll still need to install the Debian "g++" package before you can compile libvirt. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 2

[Libvir] Error while run make: undefined reference to `xenHypervisorMakeCapabilitiesXML'
by Marco Sinhoreli 30 May '07

30 May '07

Hello list, I'm with this error while I am compiling the libvirt: xencapstest.o: In function `testCompareFiles': /usr/src/libvirt/tests/xencapstest.c:33: undefined reference to `xenHypervisorMakeCapabilitiesXML' collect2: ld returned 1 exit status Any idea? Regards. -- Marco Sinhoreli

2 2

[Libvir] [PATCH] Fix some memory leak
by Masayuki Sunou 29 May '07

29 May '07

Hi This patch fixes some memory leak in libvirt. 1. The point that checks command-option in virsh.c 2. The point that checks version of Xen in xen_internal.c 3. The point that checks OS type of VM in xend_internal.c And these memory leaks can be checked by valgrind. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. ------------------------------------------------------------------------------- Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.76 diff -u -p -r1.76 virsh.c --- src/virsh.c 23 May 2007 15:09:19 -0000 1.76 +++ src/virsh.c 29 May 2007 07:43:48 -0000 @@ -3153,8 +3153,10 @@ vshCommandParse(vshControl * ctl, char * c->def = cmd; c->next = NULL; - if (!vshCommandCheckOpts(ctl, c)) + if (!vshCommandCheckOpts(ctl, c)) { + if(c) free(c); goto syntaxError; + } if (!ctl->cmd) ctl->cmd = c; Index: src/xen_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xen_internal.c,v retrieving revision 1.72 diff -u -p -r1.72 xen_internal.c --- src/xen_internal.c 30 Apr 2007 17:30:11 -0000 1.72 +++ src/xen_internal.c 29 May 2007 07:43:48 -0000 @@ -1497,11 +1497,15 @@ xenHypervisorInit(void) virXenError(VIR_ERR_XEN_CALL, " ioctl ", IOCTL_PRIVCMD_HYPERCALL); close(fd); in_init = 0; + if (ipt) + free(ipt); return(-1); done: close(fd); in_init = 0; + if (ipt) + free(ipt); return(0); } Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.114 diff -u -p -r1.114 xend_internal.c --- src/xend_internal.c 11 May 2007 14:21:28 -0000 1.114 +++ src/xend_internal.c 29 May 2007 07:43:49 -0000 @@ -3072,7 +3072,7 @@ xenDaemonCreateLinux(virConnectPtr conn, static int xenDaemonAttachDevice(virDomainPtr domain, char *xml) { - char *sexpr, *conf; + char *sexpr, *conf, *str; int hvm = 0, ret; xenUnifiedPrivatePtr priv; @@ -3084,8 +3084,11 @@ xenDaemonAttachDevice(virDomainPtr domai priv = (xenUnifiedPrivatePtr) domain->conn->privateData; - if (strcmp(virDomainGetOSType(domain), "linux")) + str = virDomainGetOSType(domain); + if (strcmp(str, "linux")) hvm = 1; + if (str) + free(str); sexpr = virParseXMLDevice(domain->conn, xml, hvm, priv->xendConfigVersion); if (sexpr == NULL) return (-1); -------------------------------------------------------------------------------

2 1

[Libvir] [PATCH] add scheduler API(take 3?)
by Atsushi SAKAI 29 May '07

29 May '07

Hi, This patch is retry from one-month ago. This patch is for fixes following suggestions. https://www.redhat.com/archives/libvir-list/2007-April/msg00090.html And I add Check Xen3.1.0 only. (As you know domctl on Xen3.0.4 does not work fine.) How to use is described in following mail. https://www.redhat.com/archives/libvir-list/2007-April/msg00050.html Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com> Thanks Atsushi SAKAI

5 7

[Libvir] [PATCH] Add Python binding for virGetVersion
by Richard W.M. Jones 29 May '07

29 May '07

This patch adds a Python binding for the virGetVersion call (called libvirt.getVersion). $ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt; >>> libvirt.getVersion (None); (2002, 3000001) >>> libvirt.getVersion ("QEMU"); (2002, 2002) It also gives you a way to detect if a particular driver is compiled in, which I guess could be quite useful: >>> libvirt.getVersion ("not_here"); libvir: error : no support for hypervisor Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/rjones/local/lib/python2.4/site-packages/libvirt.py", line 95, in getVersion if ret is None: raise libvirtError ("virGetVersion() failed") libvirt.libvirtError: virGetVersion() failed no support for hypervisor Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 7

[Libvir] PATCH: Create a logfile for each QEMU vm
by Daniel P. Berrange 29 May '07

29 May '07

Most of the error reporting the QEMU daemon is focused on sending errors wrt to RPC ops to the client. There is no provision currently for getting info about the QEMU vm itself when problems occur. The most common problem is some mis-configurable in the XML causes qemu to fail to start up. This results in the completely accurate & completely useless (mea-culpa) error message libvirt.libvirtError: virDomainCreateLinux() failed internal error End-of-file while reading PTY startup output' What this means is that qemu crashed/exited at startup. Now this patch does not (yet) directly address that stupid error message, but what it does do is provide a way to diagnose the real problem. For every VM we start it will create a logfile /etc/libvirt/qemu/logs/[vmname].log Or $HOME/.libvirt/qemu/logs/[vmname].log And all output from QEMU's stderr/stdout will get written to this file. So # virsh --connect qemu:///system start wizz libvir: QEMU error : internal error End-of-file while reading PTY startup output error: Failed to start domain wizz # cat /etc/libvirt/qemu/logs/wizz.log qemu: could not open hard disk image '/home/berrange/src/xen/virtinst--devel/demo' Next up I'm going to work on a) Improving the error message b) Adding validation that disk images actually exist before launching QEMU since that's the most common error we're seeing Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

6 9

[Libvir] AC_PROG_CPP
by Richard W.M. Jones 29 May '07

29 May '07

We have AC_PROG_CPP, but apparently no C++ code? In any case unless a C++ compiler is installed, I get: checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 4

[Libvir] Question on acquiring cpuTime in struct _virDomainInfo
by Jan Michael 29 May '07

29 May '07

Hi everyone, using libvirt I'm trying to calculate cpu utilization of a node in percent. But sometimes values beyond 100.0% are being calculated. This is because a domain spend more time on a cpu than time is elapsed in the meantime. A short explanation of the way how cpu utilization is computed in my case: 1. - open two connections with conn_cur/conn_old = virConnectOpenReadOnly(NULL); 2. - get current time gettimeofday(&time_old, NULL); - get domain by id with dom_old = virDomainLookupByID(conn_old, id) - get domain information virDomainGetInfo(dom_old, &info_old); 3. - sleep a second 4. - doing same stuff like in 2. but with _cur 5. - compute cpu utilization by dividing used cputime by elapsed time and multiply with 100 Am I right if I suppose that cpuTime for _virDomainInfo structure will be directly acquired from the hypervisor in virDomainGetInfo (dom_old, &info_old) or is it already present with getting the domain itself? Is there any better solution of doing this, which is more precise? And another general question: The monitoring utility of xen, called xentop, provides also statistics about networking and vbds. Are there any plans to provide this values by libvirt in the future? Cheers, Jan

3 5

[Libvir] Please check my autoconf libvirt.m4
by Richard W.M. Jones 24 May '07

24 May '07

Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number. If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

4 7

[Libvir] Remote patch, 2007-05-22
by Richard W.M. Jones 22 May '07

22 May '07

This is the latest version of the remote patch. http://annexia.org/tmp/libvirt-remote-20070522.patch I'd like to propose this for merging. The only differences are those described here: https://www.redhat.com/archives/libvir-list/2007-May/msg00156.html, and a bit more testing. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

1 0