- Devel - libvirt List Archives

[libvirt] auto-generating HACKING?
by Eric Blake 11 Nov '10

11 Nov '10

Right now, docs/hacking.html.in contains more data than HACKING. Back in March(! - commit d1c754168) the plan was to add a Makefile rule to autogenerate HACKING via some xml filter; but this still hasn't happened. Can anyone with a better skill set than me at setting up xml filters step in and help? -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

2 1

[libvirt] [PATCH v2] show compiled in options in virsh --version
by Daniel Veillard 11 Nov '10

11 Nov '10

To ease debugging this trivial patch allows to find what was compiled in in the local version of libvirt, this doesn't work for remote access but that's probably sufficient. With the patch I get on my machine: paphio:~/libvirt/tools -> ./virsh -V Virsh command line tool of libvirt 0.8.4 See web site at http://libvirt.org/ Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline paphio:~/libvirt/tools -> v2: map the command to -V and leave -v/--version unchanged change the way spacing is done 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/

4 8

[libvirt] Per user preference file
by Justin Clift 11 Nov '10

11 Nov '10

Hi all, Had a thought the other night, about a possible approach to having a "per user" libvirt preferences file. How about, in the user's home directory, we have a single text file, say ".libvirt-prefs", structured something like this: [common] default_uri = qemu+ssh://somehost/system default_socket = /path/to/somewhere-socket default_session_type = system tls_client_cert = /path/to/somewhere.cert tls_client_key = /path/to/somewhere.key log_file=/path/to/logfile.log some_other_preference=value [gtk-vnc] tls_client_cert = /path/that/overrides/the/common/section/if/present/somefile.cert tls_client_key = /path/that/overrides/the/common/section/if/present/somefile.key [virt-viewer] more_overrides=/value/foo The suggestion being, that we have a [common] section with preferences that general libvirt client apps can use (ie virsh). But also allowing other libvirt client apps (ie virt-viewer), to store overrides to that. Just thinking it would be useful to have these things in one place, so sensible defaults can be set once (ie for TLS certs), and things will then "automagically" use them. + Justin

1 0

[libvirt] RFC [0/3]: A proposal for lock manager plugins
by Daniel P. Berrange 10 Nov '10

10 Nov '10

A few weeks back David introduce sync-manager as a means for protecting against the same VM being started on multiple hosts: https://www.redhat.com/archives/libvir-list/2010-August/msg00179.html This is obviously a desirable feature for libvirt, but we don't want to have a hardcoded dependancy on a particular implementation. We can achieve isolation between libvirt & sync-manager, allowing for alternative implementations by specifying a formal plugin for supervisor processes. What follows is my mockup of what a plugin API would look like, its internal libvirt API and an outline of the usage scenarios in psuedo code. At the minimum level of compliance, the plugin implementation provides for per-VM level exclusion. Optionally a plugin can declare that it - supports locks against individual resources (disks) - supports hotplug of individual resources - supports migration of the supervised process Migration/hotplug will be forbid if those capabilities aren't declared by the plugin. In parallel with David's work on sync-manager, I intend to write a simple plugin implementation based solely on fcntl() locking. It is important that we have 2 independant implementations to prove the validity of the plugin API. The fcntl() impl should provide a zero-config impl we can deploy out of the box that will provide protection against 2 vms using the same disk image on a host, and limited protection in multi-host scenarios with shared filesystems (no protection for shared block devs). Perhaps we should have a 3rd impl based on libdlm too, for Red Hat ClusterSuite scenarios, though sync-manager may well be general & simple enough to easily cope with this already. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

7 26

[libvirt] [PATCH v2] qemu: Add flag to force a CDROM eject
by Cole Robinson 10 Nov '10

10 Nov '10

QEMU allows forcing a CDROM eject even if the guest has locked the device. Expose this via a new UpdateDevice flag, VIR_DOMAIN_DEVICE_MODIFY_FORCE. This has been requested for RHEV: https://bugzilla.redhat.com/show_bug.cgi?id=626305 v2: Change flag name, bool cleanups Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- include/libvirt/libvirt.h.in | 2 ++ src/qemu/qemu_driver.c | 15 ++++++++++----- src/qemu/qemu_monitor.c | 9 +++++---- src/qemu/qemu_monitor.h | 6 ++---- src/qemu/qemu_monitor_json.c | 5 +++-- src/qemu/qemu_monitor_json.h | 3 ++- src/qemu/qemu_monitor_text.c | 5 +++-- src/qemu/qemu_monitor_text.h | 3 ++- 8 files changed, 29 insertions(+), 19 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index 81db3a2..5c78270 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -1033,6 +1033,8 @@ typedef enum { VIR_DOMAIN_DEVICE_MODIFY_CURRENT = 0, /* Modify device allocation based on current domain state */ VIR_DOMAIN_DEVICE_MODIFY_LIVE = (1 << 0), /* Modify live device allocation */ VIR_DOMAIN_DEVICE_MODIFY_CONFIG = (1 << 1), /* Modify persisted device allocation */ + VIR_DOMAIN_DEVICE_MODIFY_FORCE = (1 << 2), /* Forcibly modify device + (ex. force eject a cdrom) */ } virDomainDeviceModifyFlags; int virDomainAttachDevice(virDomainPtr domain, const char *xml); diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e7b37e1..2728448 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -7686,7 +7686,8 @@ cleanup: static int qemudDomainChangeEjectableMedia(struct qemud_driver *driver, virDomainObjPtr vm, virDomainDiskDefPtr disk, - unsigned long long qemuCmdFlags) + unsigned long long qemuCmdFlags, + bool force) { virDomainDiskDefPtr origdisk = NULL; int i; @@ -7747,7 +7748,7 @@ static int qemudDomainChangeEjectableMedia(struct qemud_driver *driver, driveAlias, disk->src, format); } else { - ret = qemuMonitorEjectMedia(priv->mon, driveAlias); + ret = qemuMonitorEjectMedia(priv->mon, driveAlias, force); } qemuDomainObjExitMonitorWithDriver(driver, vm); @@ -8719,7 +8720,8 @@ static int qemudDomainAttachDevice(virDomainPtr dom, case VIR_DOMAIN_DISK_DEVICE_FLOPPY: ret = qemudDomainChangeEjectableMedia(driver, vm, dev->data.disk, - qemuCmdFlags); + qemuCmdFlags, + false); if (ret == 0) dev->data.disk = NULL; break; @@ -8906,10 +8908,12 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom, unsigned long long qemuCmdFlags; virCgroupPtr cgroup = NULL; int ret = -1; + bool force = (flags & VIR_DOMAIN_DEVICE_MODIFY_FORCE) != 0; virCheckFlags(VIR_DOMAIN_DEVICE_MODIFY_CURRENT | VIR_DOMAIN_DEVICE_MODIFY_LIVE | - VIR_DOMAIN_DEVICE_MODIFY_CONFIG, -1); + VIR_DOMAIN_DEVICE_MODIFY_CONFIG | + VIR_DOMAIN_DEVICE_MODIFY_FORCE, -1); if (flags & VIR_DOMAIN_DEVICE_MODIFY_CONFIG) { qemuReportError(VIR_ERR_OPERATION_INVALID, @@ -8964,7 +8968,8 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom, case VIR_DOMAIN_DISK_DEVICE_FLOPPY: ret = qemudDomainChangeEjectableMedia(driver, vm, dev->data.disk, - qemuCmdFlags); + qemuCmdFlags, + force); if (ret == 0) dev->data.disk = NULL; break; diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 2366fdb..3600fd8 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -1146,10 +1146,11 @@ int qemuMonitorSetCPU(qemuMonitorPtr mon, int cpu, int online) int qemuMonitorEjectMedia(qemuMonitorPtr mon, - const char *devname) + const char *devname, + bool force) { int ret; - DEBUG("mon=%p devname=%s", mon, devname); + DEBUG("mon=%p devname=%s force=%d", mon, devname, force); if (!mon) { qemuReportError(VIR_ERR_INVALID_ARG, "%s", @@ -1158,9 +1159,9 @@ int qemuMonitorEjectMedia(qemuMonitorPtr mon, } if (mon->json) - ret = qemuMonitorJSONEjectMedia(mon, devname); + ret = qemuMonitorJSONEjectMedia(mon, devname, force); else - ret = qemuMonitorTextEjectMedia(mon, devname); + ret = qemuMonitorTextEjectMedia(mon, devname, force); return ret; } diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 7d09145..41b3135 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -203,12 +203,10 @@ int qemuMonitorSetCPU(qemuMonitorPtr mon, int cpu, int online); /* XXX should we pass the virDomainDiskDefPtr instead * and hide devname details inside monitor. Reconsider * this when doing the QMP implementation - * - * XXXX 'eject' has gained a 'force' flag we might like - * to make use of... */ int qemuMonitorEjectMedia(qemuMonitorPtr mon, - const char *devname); + const char *devname, + bool force); int qemuMonitorChangeMedia(qemuMonitorPtr mon, const char *devname, const char *newmedia, diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index d2c6f0a..da51a4f 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -1348,12 +1348,13 @@ cleanup: int qemuMonitorJSONEjectMedia(qemuMonitorPtr mon, - const char *devname) + const char *devname, + bool force) { int ret; virJSONValuePtr cmd = qemuMonitorJSONMakeCommand("eject", "s:device", devname, - "b:force", 0, + "b:force", force ? 1 : 0, NULL); virJSONValuePtr reply = NULL; if (!cmd) diff --git a/src/qemu/qemu_monitor_json.h b/src/qemu/qemu_monitor_json.h index 94806c1..c78ee24 100644 --- a/src/qemu/qemu_monitor_json.h +++ b/src/qemu/qemu_monitor_json.h @@ -68,7 +68,8 @@ int qemuMonitorJSONSetBalloon(qemuMonitorPtr mon, int qemuMonitorJSONSetCPU(qemuMonitorPtr mon, int cpu, int online); int qemuMonitorJSONEjectMedia(qemuMonitorPtr mon, - const char *devname); + const char *devname, + bool force); int qemuMonitorJSONChangeMedia(qemuMonitorPtr mon, const char *devname, const char *newmedia, diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c index 7f15008..2552111 100644 --- a/src/qemu/qemu_monitor_text.c +++ b/src/qemu/qemu_monitor_text.c @@ -848,13 +848,14 @@ int qemuMonitorTextSetCPU(qemuMonitorPtr mon, int cpu, int online) int qemuMonitorTextEjectMedia(qemuMonitorPtr mon, - const char *devname) + const char *devname, + bool force) { char *cmd = NULL; char *reply = NULL; int ret = -1; - if (virAsprintf(&cmd, "eject %s", devname) < 0) { + if (virAsprintf(&cmd, "eject %s%s", force ? "-f " : "", devname) < 0) { virReportOOMError(); goto cleanup; } diff --git a/src/qemu/qemu_monitor_text.h b/src/qemu/qemu_monitor_text.h index c017509..983f402 100644 --- a/src/qemu/qemu_monitor_text.h +++ b/src/qemu/qemu_monitor_text.h @@ -66,7 +66,8 @@ int qemuMonitorTextSetBalloon(qemuMonitorPtr mon, int qemuMonitorTextSetCPU(qemuMonitorPtr mon, int cpu, int online); int qemuMonitorTextEjectMedia(qemuMonitorPtr mon, - const char *devname); + const char *devname, + bool force); int qemuMonitorTextChangeMedia(qemuMonitorPtr mon, const char *devname, const char *newmedia, -- 1.7.2.1

2 2

Re: [libvirt] Startup/Shutdown scripts for KVM Machines in Debian (libvirt)
by Avi Kivity 10 Nov '10

10 Nov '10

On 11/10/2010 10:01 AM, Hermann Himmelbauer wrote: > Hi, > I manage my KVM machines via libvirt and wonder if there are any init.d > scripts for automatically starting up and shutting down virtual machines > during boot/shutdown of the host? > > Writing this for myself seems to be not that simple, as when shutting down, > the system has somehow to wait until all machines are halted (not responding > guests have to be destroyed etc.), and I don't really know how to accomplish > this. > > My host system is Debian Lenny, is there anything available? > Perhaps libvirt offers something I'm unaware of? > I think it does. Copying the libvirt mailing list. -- error compiling committee.c: too many arguments to function

4 3

[libvirt] [PATCHv2] rpm: fix /var/lib/libvirt permissions
by Eric Blake 10 Nov '10

10 Nov '10

https://bugzilla.redhat.com/show_bug.cgi?id=649511 Regression of forcing 0700 permissions (which breaks guest startup because the qemu user can't see /var/lib/libvirt/*.monitor) was introduced in commit 66823690e, as part of libvirt 0.8.2. * libvirt.spec.in (%files): Drop %{_localstatedir}/lib/libvirt, since libvirt depends on libvirt-client. (%files client): Guarantee 755 permissions on %(_localstatedir}/lib/libvirt, since the qemu user must be able to do pathname resolution to a subdirectory. --- v2 changes: don't declare directory twice (v1 at https://www.redhat.com/archives/libvir-list/2010-November/msg00238.html) libvirt.spec.in | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 813e0c0..f77626e 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -793,7 +793,6 @@ fi %dir %{_localstatedir}/run/libvirt/ -%dir %{_localstatedir}/lib/libvirt/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/boot/ %dir %attr(0700, root, root) %{_localstatedir}/cache/libvirt/ @@ -883,7 +882,7 @@ fi %{_sysconfdir}/rc.d/init.d/libvirt-guests %config(noreplace) %{_sysconfdir}/sysconfig/libvirt-guests -%dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt +%dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/ %if %{with_sasl} %config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf -- 1.7.3.2

2 2

[libvirt] [PATCH] Augment bug reporting documentation
by Daniel Veillard 10 Nov '10

10 Nov '10

With some instruction on how to attach useful gdb backtraces Daniel diff --git a/docs/bugs.html.in b/docs/bugs.html.in index 201705b..560dfa4 100644 --- a/docs/bugs.html.in +++ b/docs/bugs.html.in @@ -78,6 +78,35 @@ </ul> + If the bug leads to a tool linked to libvirt crash, then the best + is to provide a backtrace along with the scenario used to get the + crash, the simplest is to run the program under gdb, reproduce the + steps leading to the crash and then issue a gdb "bt" command to + get the stack trace, attach it to the bug. Note that for the + data to be really useful libvirt debug informations must be present + for example by installing libvirt debuginfo package on Fedora or + Red Hat Enterprise Linux (with debuginfo-install libvirt) prior + to running gdb. + + It may also happen that the libvirt daemon itself crashes or get stuck, + in the first case run it (as root) under gdb, and reproduce the sequence + leading to the crash, similary to a normal program provide the + "bt" backtrace information to where gdb will have stopped. + But if libvirtd get stuck, for example seems to stop processing + commands, try to attach to the faulty daemon and issue a gdb command + "thread apply all bt" to show all the threads backtraces, as in: + <pre> # ps -o etime,pid `pgrep libvirt` +... note the process id from the output +# gdb /usr/sbin/libvirtd +.... some informations about gdb and loading debug data +(gdb) attach $the_damon_process_id +.... +(gdb) thread apply all bt +.... informations to attach to the bug +(gdb) +</pre> + + If requesting a new feature attach any available patch to the ticket and also email the patch to the libvirt mailing list for discussion -- 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/

3 3

[libvirt] [PATCH] Fix LXC container console device setup
by Daniel P. Berrange 10 Nov '10

10 Nov '10

From: Daniel P. Berrange <dan(a)berrange.com> The /dev/console device inside the container must NOT map to the real /dev/console device node, since this allows the container control over the current host console. A fun side effect of this is that starting a container containing a real Fedora OS will kill off your X server. Remove the /dev/console node, and replace it with a symlink to the primary console TTY * src/lxc/lxc_container.c: Replace /dev/console with a symlink to /dev/pty/0 * src/lxc/lxc_controller.c: Remove /dev/console from cgroups ACL --- src/lxc/lxc_container.c | 6 +++++- src/lxc/lxc_controller.c | 1 - 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 0e06a2d..7013667 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -466,7 +466,6 @@ static int lxcContainerPopulateDevices(void) { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_NULL, 0666, "/dev/null" }, { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_ZERO, 0666, "/dev/zero" }, { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_FULL, 0666, "/dev/full" }, - { LXC_DEV_MAJ_TTY, LXC_DEV_MIN_CONSOLE, 0600, "/dev/console" }, { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_RANDOM, 0666, "/dev/random" }, { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_URANDOM, 0666, "/dev/urandom" }, }; @@ -508,6 +507,11 @@ static int lxcContainerPopulateDevices(void) _("Failed to symlink /dev/pts/0 to /dev/tty1")); return -1; } + if (symlink("/dev/pts/0", "/dev/console") < 0) { + virReportSystemError(errno, "%s", + _("Failed to symlink /dev/pts/0 to /dev/console")); + return -1; + } return 0; } diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index eb0148e..478f0d1 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -80,7 +80,6 @@ static int lxcSetContainerResources(virDomainDefPtr def) {'c', LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_RANDOM}, {'c', LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_URANDOM}, {'c', LXC_DEV_MAJ_TTY, LXC_DEV_MIN_TTY}, - {'c', LXC_DEV_MAJ_TTY, LXC_DEV_MIN_CONSOLE}, {'c', LXC_DEV_MAJ_TTY, LXC_DEV_MIN_PTMX}, {0, 0, 0}}; -- 1.7.2.3

2 1

[libvirt] "transient" vs "temporary"
by Justin Clift 10 Nov '10

10 Nov '10

Hi all, While writing up the descriptions for persistent vs transient objects (domains, virtual networks, etc), I'm personally finding the word "temporary" seems a better fit than "transient". Is there anything particularly wrong with using "temporary" in this context instead? Thinking that if "temporary" is ok, I'll do a search-n-replace, changing "transient" to "temporary" across docs (and any code). Bad idea? Regards and best wishes, Justin Clift

3 5