[Libvir] FYI: bug in remote code
by Mark Johnson
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
16 years, 7 months
[Libvir] [for discussion only] virDomainBlockPeek preliminary implementation
by Richard W.M. Jones
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
16 years, 7 months
[Libvir] PATCH: Implement CDROM media change for QEMU/KVM driver
by Daniel P. Berrange
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 -=|
16 years, 7 months
[Libvir] Thoughts on remote storage support
by Tóth István
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
16 years, 7 months
[Libvir] [PATCH] Refactor xend_internal.c block device detection
by Richard W.M. Jones
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
16 years, 7 months
[Libvir] remote access ?
by Mark Johnson
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
16 years, 7 months
[Libvir] [PATCH] Topology fix for "no cpus"
by beth kon
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
16 years, 7 months
[Libvir] PATCH: Fix const-ness for attach/detach device APIs
by Daniel P. Berrange
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 -=|
16 years, 7 months
[Libvir] Core dump while executing virsh in RHEL5 .
by Veerendra
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*
16 years, 7 months
