October 2007 - Devel - libvirt List Archives

[Libvir] FYI: bug in remote code
by Mark Johnson 16 Oct '07

16 Oct '07

I ran into a bug in the remote code... I was doing # virsh -c xen_tcp://<ip_addr>/ It you don't have qemu compiled in, you will hang in in libvirtd in do_open() res = virNetworkDriverTab[i]->open (ret, name, flags); when trying to open the remote network driver. Usually qemu returns success and you fall out of the loop before you call this (which is why you won't see it with qemu support built in). You hang in libvirtd trying to read from the libvirtd PF_UNIX socket. You read from the socket because you hit this code path in doRemoteOpen() if (!uri->server && !transport_str) { if (flags & VIR_DRV_OPEN_REMOTE_UNIX) { transport = trans_unix; No idea what it should be doing? :-) I reproduced it on todays CVS bits on FC7 by commenting out qemu's network register.. int qemudRegister(void) { virRegisterDriver(&qemuDriver); /* virRegisterNetworkDriver(&qemuNetworkDriver); */ virRegisterStateDriver(&qemuStateDriver); return 0; } MRJ

2 4

[Libvir] [for discussion only] virDomainBlockPeek preliminary implementation
by Richard W.M. Jones 16 Oct '07

16 Oct '07

The attached patch (for discussion only) adds a virDomainBlockPeek call, allowing callers to peek into the block devices of domains. +/** + * virDomainBlockPeek: + * @dom: pointer to the domain object + * @path: path to the block device + * @offset: offset within block device + * @size: size to read + * @buffer: return buffer (must be at least size bytes) + * + * This function allows you to read the contents of a domain's + * disk device. + * + * Typical uses for this are to determine if the domain has + * written a Master Boot Record (indicating that the domain + * has completed installation), or to try to work out the state + * of the domain's filesystems. + * + * (Note that in the local case you might try to open the + * block device or file directly, but that won't work in the + * remote case, nor if you don't have sufficient permission. + * Hence the need for this call). + * + * 'path' must be a device or file corresponding to the domain. + * In other words it must be the precise string returned in + * a <disk><source dev='...'/></disk> from + * virDomainGetXMLDesc. + * + * 'offset' and 'size' represent an area which must lie entirely + * within the device or file. 'size' may be 0 to test if the + * call would succeed. + * + * 'buffer' is the return buffer and must be at least 'size' bytes. + * + * Returns: 0 in case of success or -1 in case of failure. + */ +int +virDomainBlockPeek (virDomainPtr dom, + const char *path, + long long offset /* really 64 bits */, + size_t size, + void *buffer) The patch doesn't include: - remote - qemu - Xen < 3.0.3 inactive domains I will add these if I get favourable feedback. 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 3

[Libvir] PATCH: Implement CDROM media change for QEMU/KVM driver
by Daniel P. Berrange 16 Oct '07

16 Oct '07

Hugh recently added support for CDROM media change to the Xen driver, so I thought it was time I did the same for the QEMU/KVM driver. The attached patch implements the virDomainAttachDevice API to support changing the media of the CDROM device. To re-use the existing QEMU code for parsing I had to re-factor a couple of the internal QEMU device parsing apis so that they get supplied with a pre-allocated struct for the device info, rather than allocating it themselves. Although this isn't strictly needed for CDROM media change, I have prepared the virDomainAttachDevice method so that I can easily add USB device hotplut in the near future. It will also be useful when KVM gets paravirt driver support sooon... The actual implementation just runs the 'change cdrom path' command over the QEMU monitor console. diffstat libvirt-qemu-cdrom-change.patch qemu_conf.c | 135 +++++++++++++++++++++++++++++++++++++++------------------- qemu_conf.h | 21 +++++++++ qemu_driver.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++------ 3 files changed, 230 insertions(+), 58 deletions(-) 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 -=|

3 7

[Libvir] Thoughts on remote storage support
by Tóth István 16 Oct '07

16 Oct '07

Hello! I had a hobby project where I needed to manipulate xen disk images on remote systems, that used a model similar to libirt's remote support. Based on what I learnt from it, I came up with a possible model for libvirt's remote storage support. I present it here for discussion. We typically store the images in volumes on LVM, or in dedicated file system folders. The folders and volume groups usable by libvirt can be limited in a config file. It is probably not neccessary to differentiate between defined and created files, as you can not stop and start a file like a domain, you either have it on disk, or not. Libvirt should not store information on these files, everything should be checked/listed on the fly, so that if you just copy an image to a directory, libvirt can deduct all information (well, all it can) on it, and handle it just as if the file was created by it. The handle for the file is its path, plus its virConnect object (i.e. the host it is on). For consistency, it may be possible to create an object for it, but as disk images have no persistent properties apart from what is on the disk, and it can always be checked from there, it provides no extra functionality. I think there is no need to support remote files explicitly, as the domains mount local files/volumes. The file/volume may actually be mounted from a NAS or SAN, of course, but it does not matter because we use the local path names, and AFAIK all virtualization tools use local files or local devices as blockdevs. I have added compression to the mix because it is immensely useful. I have used lzop in my project, and a full backup and restore was much faster when using a compressed backup file, than with and uncrompessed one. It conserves disk space, as well as cpu/bus capacity. Zeroing out newly allocated files, helps with compressed backups, as well as security. It also means that no holey files can be used. The objects we are dealing with are disk images. They have the following properties: -Path: The unix path of the file ( /mnt/images/fc7.img or /dev/VG/fc7) -Compression: Mountable/compressed -Type: Plain file/LVM volume/ What else? -Size -Filesystem: swap/ext3/xfs/.... -Is it mounted? We can do the following operations on the images: Create -connection -filepath -size Allocates a new image of the given type, size, and name. Libvirt should parse the filepath, and determine the base path, check if it's a directory or a VG, check if libvirt is allowed to operate on the path/VG, then create the file/volume. For security reasons zeroing out the allocated space should be a non-optional step of the allocation. DirectoryList -connection -directorypath Plain ls functionality, that returns the list of files, and any subdirectories. If called on a VG, it returns the volumes in it. Info -connection -filepath Returns information on the given file/volume, including size, type, filesystem (if available), whether it is a snapshot (if a volume), and whether it is mounted or not. size can be determined by ls or lvinfo, filesystem by 'file' command. Delete -connection -filepath Delete the file/volume. Find out if it's a file or volume, and rm or lvremove it. Grow -connection -path -filename -newsize Grows the specified image to the given size. The newly added space is zeroed out. Shrink? -connection -path -filename -newsize Shrinks the specified image the the given size. It's very tricky, because to avoid data loss, we need to analyze the file system size. Of course, we can just say that it's the reponsibility of the user, after all, we allow him to outright delete the file as well. We may combine it with Grow, and call it Resize. Growfs -connection -path -filename -newsize? Grows the filesystem on the image to fill the size of the image, or the given newsize. Can only be used on umounted images. It is neccesary because some filesystems may not be grown while mounted, so the guest can not do it on its own. Shrinkfs -connection -path -filname -newsize Shrinks the filesystem to the given size. Same coniderations apply as with growfs, may be combined to Resizefs? Snapshot -connection -filepath -filesize Creates a snapshot of the given image. It is only possible with images on LVM. Should return the snapshot image name. The snapshot can later be deleted with Delete. CopyTo -connection -source filepath -target connection -target filepath -snapshot flag -archive flag -overwrite flag Copy the source image to the target image. If connection is on another machine, then it's a network copy. If the snapshot flag is true, then first create a snapshot of the source image, copy that, then delete the snapshot. If the archive flag is active, then the target file will be archive file (compressed). If the overwite flag is active, then the target file is overwitten, if it exists. Otherwise existing files are not changed. Even if the source file is compressed, the target file is uncompressed, unless the archive flag is set. CopyContents -connection -source filepath -target connection -target filepath -snapshot flag Copies the contents of the source file to the target file. The target file must already exist, and be no smaller than the source file. The contents of the target file are overwitten, and any extra space is zeroed out. Archive -connection -filepath compresses the given file. Makes sense only on files, not volumes. Unarchive -connection -filepath uncompresses the given file. Makes sense only on archved(compressed) files. StorageInfo - connection Returns information on the node's storage configuration. What kind of filesystems it can handle, What are the accessible file / VG paths, what's the free space on them, etc. A typical usage scenario could be something like this: Aconn=getVirconn("ssh:Ahost"); //Open the connection to host A Bconn=getVirconn("ssh:Bhost"); //Host B will hold our backup image Ainfo=StorageInfo(Aconn); //Get Ainfo AVGPath = <get the first usable VG path from VG info> Newimage = Create(Aconn, concat("AVGPath", "newimage", 100000); //A 100Mb volume is created and zeroed out. CopyContents(Aconn, NewImage, Aconn, "/images/ghost/FC7default.img", no); //Copy our pre-created FC7 image to the new image Growfs(Aconn, NewImage, 0); //Grow the copied filesystem to fill the whole volume. <Here we define a new domain, and use NewImage as the name of the backing image for the guest's block device> <Start the new domain> Copy(Aconn, NewImage, Bconn, "/mnt/backups/backup23image", snapshot=yes, archive=yes, overwrite=no); //Make an LVM snapshot of NewImage, and copy it to Host B on the given filename, compressing it on the fly, then remove the snapshot <Stop the domain> CopyContents(Bconn, "/mnt/backups/backup23image", Aconn, NewImage, snapshot=no); //Restore the backed-up image to NewImage, decompress it on the fly. <Start the domain> <Stop the domain> Grow(Aconn, NewImage, 200000); //Grow the volume to 200MBs Growfs(Aconn, NewImage); //Grow the fs on the volume to fill the volume <Start the domain> ..... Best regards István

3 4

[Libvir] [PATCH] Refactor xend_internal.c block device detection
by Richard W.M. Jones 16 Oct '07

16 Oct '07

This patch is a little bit esoteric, but I need it for something I'm working on at the moment. At the moment the code in xend_internal.c: xend_parse_sexp_desc parses the domain sexpr directly into XML. This makes it rather hard to just get a list of block devices without repeating the same code. So here I've factored out the common code for parsing block devices into a separate function and callback. There are a couple of small changes that you should be aware of: (1) The <devices> list may be returned in a different order (specifically, block devices are always returned first). (2) We iterate over the root nodes of the sexpr twice (once for block devices, once for vifs and vfbs). But the sexpr is small and in-memory so this shouldn't be a problem compared to having to do the HTTP request to xend to get it in the first place. 'make check' passes. 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] remote access ?
by Mark Johnson 16 Oct '07

16 Oct '07

I was looking through some of the remote code.. I was wondering if a 32-bit virsh client is supposed to be able to connect to a 64-bit libvirtd? The reason I ask is because I saw some references to longs.. For example, in xdr_remote_node_get_info_ret() ... objp->cpus = IXDR_GET_LONG(buf); objp->mhz = IXDR_GET_LONG(buf); objp->nodes = IXDR_GET_LONG(buf); objp->sockets = IXDR_GET_LONG(buf); objp->cores = IXDR_GET_LONG(buf); objp->threads = IXDR_GET_LONG(buf); Thanks, MRJ

4 17

[Libvir] [PATCH] [REPOST] Remove virDomainRestart typedef from the public API
by Richard W.M. Jones 15 Oct '07

15 Oct '07

... however it is still used internally by the test driver, so the typedef is moved into src/test.c. 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 2

[Libvir] [PATCH] Topology fix for "no cpus"
by beth kon 15 Oct '07

15 Oct '07

I was able to test on a 128-way NUMA box and found a bug. My code did not handle the case of no cpus being associated with a node. I decided to represent (pretty straightforward decision :-) no cpus as follows in the xml... <cell id='2'> <cpus num='0'> </cpus> </cell> Here is the patch... Signed-off-by: Beth Kon <eak(a)us.ibm.com> -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

3 3

[Libvir] PATCH: Fix const-ness for attach/detach device APIs
by Daniel P. Berrange 15 Oct '07

15 Oct '07

virDomainAttachDevice and virDomainDetachDevice both take a char * for the XML description, but this is mistakenly not declared to be const. This patch fixes the public header files & all the internal drivers. NB, yes this is in the public API, no it won't break any apps since these are input params only. 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 -=|

3 2

[Libvir] Core dump while executing virsh in RHEL5 .
by Veerendra 15 Oct '07

15 Oct '07

Hi all, I have installed <mailto:libvir-list@redhat.com>libvirt-0.3.3-1, on my RHEL 5 64 bit machine(KerVer 2.6.18-8.el5xen). But I am getting core-dump , while executing virsh command. Could anyone please help me to solve this? #gdb /usr/bin/virsh core Core was generated by `virsh'. Program terminated with signal 11, Segmentation fault. #0 0x000000393686ca27 in malloc_consolidate () from /lib64/libc.so.6 (gdb) where #0 0x000000393686ca27 in malloc_consolidate () from /lib64/libc.so.6 #1 0x000000393686eea2 in _int_malloc () from /lib64/libc.so.6 #2 0x00000039368706dd in malloc () from /lib64/libc.so.6 #3 0x000000393685eb4a in __fopen_internal () from /lib64/libc.so.6 #4 0x000000393682cb5f in read_alias_file () from /lib64/libc.so.6 #5 0x000000393682d09e in _nl_expand_alias () from /lib64/libc.so.6 #6 0x000000393682b93e in _nl_find_domain () from /lib64/libc.so.6 #7 0x000000393682b2ff in __dcigettext () from /lib64/libc.so.6 #8 0x000000393687530c in strerror_r () from /lib64/libc.so.6 #9 0x000000393687514e in strerror () from /lib64/libc.so.6 #10 0x00002aaaaab018f2 in __virConfReadFile () from /usr/lib64/libvirt.so.0 #11 0x00002aaaaab021ec in __virConfReadFile () from /usr/lib64/libvirt.so.0 #12 0x00002aaaaaadd44b in virInitialize () from /usr/lib64/libvirt.so.0 #13 0x000000000040a65e in ?? () #14 0x000000393681d8a4 in __libc_start_main () from /lib64/libc.so.6 #15 0x00000000004033b9 in ?? () #16 0x00007fffd2df95c8 in ?? () #17 0x0000000000000000 in ?? () I have installed the following rpms from libvirt.org/libvirt # rpm -qa | grep virt libvirt-devel-0.3.3-1 libvirt-0.3.3-1 libvirt-debuginfo-0.3.3-1// * With Regards Veerendra C*

4 9