[libvirt] auto-generating HACKING?
by Eric Blake
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
14 years, 5 months
[libvirt] [PATCH v2] show compiled in options in virsh --version
by Daniel Veillard
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/
14 years, 5 months
[libvirt] Per user preference file
by Justin Clift
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
14 years, 5 months
[libvirt] RFC [0/3]: A proposal for lock manager plugins
by Daniel P. Berrange
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 :|
14 years, 5 months
[libvirt] [PATCH v2] qemu: Add flag to force a CDROM eject
by Cole Robinson
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
14 years, 5 months
Re: [libvirt] Startup/Shutdown scripts for KVM Machines in Debian (libvirt)
by Avi Kivity
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
14 years, 5 months
[libvirt] [PATCHv2] rpm: fix /var/lib/libvirt permissions
by Eric Blake
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
14 years, 5 months
[libvirt] [PATCH] Augment bug reporting documentation
by Daniel Veillard
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>
<p>
+ 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.</p>
+ <p>
+ 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.<br/>
+ 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:</p>
+ <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>
+
+ <p>
If requesting a new feature attach any available patch to the ticket
and also email the patch to the libvirt mailing list for discussion
</p>
--
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/
14 years, 5 months
[libvirt] [PATCH] Fix LXC container console device setup
by Daniel P. Berrange
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
14 years, 5 months
[libvirt] "transient" vs "temporary"
by Justin Clift
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
14 years, 5 months
