[libvirt] [libvirt-php PATCH 0/1] use LDFLAGS for libvirt-php.so
by stefan.kuhn＠foss-group.ch
I'm getting this warning:
* QA Notice: Files built without respecting LDFLAGS have been detected
* Please include the following list of files in your report:
* /usr/lib64/php5.3/lib/extensions/no-debug-non-zts-20090626/libvirt-php.so
The attached patch seems reasonable to me, please check it.
Thank you very much for the quick responses and for adding me to the authors! :-)
Stefan
Stefan Kuhn (1):
src/Makefile.am: use LDFLAGS for libvirt-php.so
src/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
1.7.12.4
12 years
[libvirt] Problems with <filesystem type='block'>
by Lars Kellogg-Stedman
Using libvirt 1.0.1, I'm trying to start an LXC container using the
'<filesytem type="block">' syntax, like this:
<filesystem type="block" accessmode="passthrough">
<source dev="/dev/vg_files/vm-foobar-root" />
<target dir="/" />
</filesystem>
The specified block device exists:
# ls -lL /dev/vg_files/vm-foobar-root
brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root
If I start the domain, it appears to start without any errors...
# virsh start foobar
Domain foobar started
...but it's not actually running. The log files (with loglevel=2)
don't seem to be very interesting; this is everything from the
instance log file:
2012-12-22 04:10:57.862+0000: starting up
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1
2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1
2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver
PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init
2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities
2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities
Running an "strace" on the libvirtd process (strace -p <libvirtd_pid>
-f ...), it doesn't look like libvirt is ever trying to mount the
referenced filesystem.
Is this supposed to work? It seems like the support for having
libvirt mount the block device is relatively recent, and I haven't had
much luck finding examples of other folks using this capability.
Thanks,
-- Lars
12 years
[libvirt] [PATCH 0/4] Multiple problems with saving to block devices
by Daniel P. Berrange
This patch series makes it possible to save to a block device,
instead of a plain file. There were multiple problems
- WHen save failed, we might de-reference a NULL pointer
- When save failed, we unlinked the device node !!
- The approach of using >> to append, doesn't work with block devices
- CGroups was blocking QEMU access to the block device when enabled
One remaining problem is not in libvirt, but rather QEMU. The QEMU
exec: based migration often fails to detect failure of the command
and will thus hang forever attempting a migration that'll never
succeed! Fortunately you can now work around this in libvirt using
the virsh domjobabort command
12 years
Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use
by Thomas Backlund
Thomas Backlund skrev 13.1.2013 20:38:
> patch both inline and attached as thunderbird tends to mess up ...
> -----
>
> if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
> header.
>
> Found by trying to build libvirt and connman against 3.8-rc3 headers.
>
Ok,
ignore this patch, it's not the correct fix as it introduces
redefinitions...
Btw, the error that I hit that made me suggest this fix was libvirt
config check bailing out:
config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has
incomplete type
> Reported-by: Colin Guthrie <colin(a)mageia.org>
> Reported-by: Christiaan Welvaart <cjw(a)daneel.dyndns.org>
> Signed-off-by: Thomas Backlund <tmb(a)mageia.org>
>
> --
>
> diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h
> linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h
> --- linux-3.8-rc3/include/uapi/linux/if_bridge.h 2013-01-13
> 20:09:54.257271755 +0200
> +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h 2013-01-13
> 20:15:04.153676151 +0200
> @@ -14,6 +14,7 @@
> #define _UAPI_LINUX_IF_BRIDGE_H
>
> #include <linux/types.h>
> +#include <linux/in6.h>
>
> #define SYSFS_BRIDGE_ATTR "bridge"
> #define SYSFS_BRIDGE_FDB "brforward"
>
>
> -----
> Thomas
>
--
Thomas
12 years, 1 month
Re: [libvirt] [Qemu-devel] [Qemu PATCH v2] add a boot option to do strict boot
by Eric Blake
On 01/09/2013 01:39 AM, Amos Kong wrote:
> Current seabios will try to boot from selected devices first,
> if they are all failed, seabios will also try to boot from
> un-selected devices.
>
> We need to make it configurable. I already posted a seabios
> patch to add a new device type to halt booting. Qemu can add
> "HALT" at the end of bootindex string, then seabios will halt
> booting after trying to boot from selected devices.
>
> This option only effects when boot priority is changed by
> bootindex options, the old style(-boot order=..) will still
> try to boot from un-selected devices.
>
> v2: add HALT entry in get_boot_devices_list()
> define boot_strict to bool
>
> Signed-off-by: Amos Kong <akong(a)redhat.com>
> ---
Libvirt will need to expose an attribute that lets the user control
whether to use this new option; how do we probe via QMP whether the new
-boot strict=on command-line option is available?
> +++ b/qemu-options.hx
> @@ -376,14 +376,14 @@ ETEXI
>
> DEF("boot", HAS_ARG, QEMU_OPTION_boot,
> "-boot [order=drives][,once=drives][,menu=on|off]\n"
> - " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time]\n"
> + " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n"
> " 'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n"
> " 'sp_name': the file's name that would be passed to bios as logo picture, if menu=on\n"
> " 'sp_time': the period that splash picture last if menu=on, unit is ms\n"
> " 'rb_timeout': the timeout before guest reboot when boot failed, unit is ms\n",
So if I understand correctly, -boot order=... is incompatible with -boot
strict=on; even though you have listed both options under a single -boot
entry in the -help. We've already declared that -help output is no
longer guaranteed stable, so this doesn't really impact libvirt, but
would it make any more sense to list this as two orthogonal entries, to
make it clear that they don't mix?
-boot order=drivers[,once=drives]...
-boot strict=on|off[,menu=on|off]...
But this is all bikeshedding, so it's not worth a v3 if you disagree.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
12 years, 1 month
[libvirt] [PATCHv3 0/5] snapshot revert-and-create
by Eric Blake
v2 was here:
https://www.redhat.com/archives/libvir-list/2012-November/msg00818.html
One patch from v2 has already been committed. This patch additionally
adds a qemu implementation for the new flag, and I have tested creation
of offline branches (I still need to test creation of a branch from a
disk-only or online external snapshot). I've also started documenting
my plans for a new revert FOLLOW flag, which updates to the current
state of external files (rather than reverting completely to the
point where the snapshot was taken); once that is working, then
implementing the combination of createXML(LIVE|BRANCH) will really
be creating the branch, then farming out to revert(FOLLOW) to switch
over to the new branch.
Eric Blake (5):
snapshot: add revert-and-create branching of external snapshots
snapshot: prepare to parse new XML
snapshot: actually compute branch definition from XML
snapshot: support revert-and-create branching in qemu
snapshot: add another revert API flag
docs/formatsnapshot.html.in | 16 ++++-
docs/schemas/domainsnapshot.rng | 45 ++++++------
include/libvirt/libvirt.h.in | 6 ++
src/conf/snapshot_conf.c | 118 ++++++++++++++++++++++++++++---
src/conf/snapshot_conf.h | 2 +
src/esx/esx_driver.c | 2 +-
src/libvirt.c | 41 +++++++++--
src/qemu/qemu_driver.c | 50 +++++++++++--
src/vbox/vbox_tmpl.c | 2 +-
tests/domainsnapshotxml2xmlin/branch.xml | 5 ++
tests/domainsnapshotxml2xmltest.c | 2 +-
tools/virsh-snapshot.c | 44 +++++++++---
tools/virsh.pod | 25 ++++++-
13 files changed, 300 insertions(+), 58 deletions(-)
create mode 100644 tests/domainsnapshotxml2xmlin/branch.xml
--
1.7.11.7
12 years, 1 month
[libvirt] [PATCH] ESX: Add AnyType_Serialize routine to esx_vi_types.c
by Ata E Husain Bohra
Add esxVI_AnyType_Serialize routine to allow serialization
of objects containing variables of type "AnyType". The routine
attempts to determine the type of the object that covers:
boolean, long, int, string, short, byte.
If variables does not fall under any above mentioned types
then it is added as "anyType".
---
src/esx/esx_vi_types.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
src/esx/esx_vi_types.h | 3 ++-
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/src/esx/esx_vi_types.c b/src/esx/esx_vi_types.c
index d1f91ff..2076ce4 100644
--- a/src/esx/esx_vi_types.c
+++ b/src/esx/esx_vi_types.c
@@ -1130,6 +1130,54 @@ esxVI_AnyType_Deserialize(xmlNodePtr node, esxVI_AnyType **anyType)
+int
+esxVI_AnyType_Serialize(esxVI_AnyType *anyType, const char *element,
+ virBufferPtr output)
+{
+ if (element == NULL || output == NULL) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("Invalid argument"));
+ return -1;
+ }
+
+ if (anyType == NULL || anyType->value == NULL) {
+ return 0;
+ }
+
+ switch (anyType->type) {
+ case esxVI_Type_Boolean:
+ ESV_VI__XML_TAG__OPEN(output, element, "xsd:boolean");
+ break;
+ case esxVI_Type_String:
+ ESV_VI__XML_TAG__OPEN(output, element, "xsd:string");
+ break;
+ case esxVI_Type_Short:
+ ESV_VI__XML_TAG__OPEN(output, element, "xsd:short");
+ break;
+ case esxVI_Type_Byte:
+ ESV_VI__XML_TAG__OPEN(output, element, "xsd:byte");
+ break;
+ case esxVI_Type_Int:
+ ESV_VI__XML_TAG__OPEN(output, element, "xsd:int");
+ break;
+ case esxVI_Type_Long:
+ ESV_VI__XML_TAG__OPEN(output, element, "xsd:long");
+ break;
+ case esxVI_Type_Undefined:
+ case esxVI_Type_Other:
+ default:
+ ESV_VI__XML_TAG__OPEN(output, element, "xsd:anyType");
+ break;
+ }
+
+ virBufferAdd(output, anyType->value, -1);
+
+ ESV_VI__XML_TAG__CLOSE(output, element);
+
+ return 0;
+}
+
+
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* XSD: String
*/
diff --git a/src/esx/esx_vi_types.h b/src/esx/esx_vi_types.h
index 92dc16f..5150377 100644
--- a/src/esx/esx_vi_types.h
+++ b/src/esx/esx_vi_types.h
@@ -161,7 +161,8 @@ const char *esxVI_AnyType_TypeToString(esxVI_AnyType *anyType);
int esxVI_AnyType_ExpectType(esxVI_AnyType *anyType, esxVI_Type type);
int esxVI_AnyType_DeepCopy(esxVI_AnyType **dest, esxVI_AnyType *src);
int esxVI_AnyType_Deserialize(xmlNodePtr node, esxVI_AnyType **anyType);
-
+int esxVI_AnyType_Serialize(esxVI_AnyType *anyType, const char *element,
+ virBufferPtr output);
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
--
1.7.9.5
12 years, 1 month
[libvirt] [PATCHv2 0/5] Add API to allow TCP connection tunelling
by Peter Krempa
This series adds ability for the qemu driver to tunnel connections to TCP
ports from the host. This is useful for enabling remote VNC/SPICE sessions
without the need to configure SSH tunnels or portforwards and without the
need to open the ports for public.
There's also an advantage for tools such as virt-viewer that have to guess the remote
connection parameters and you have to hope that nothing is in your way. With
spice/VNC clients that have support for read/write callbacks, this would allow also
direct connection without an intermediate socket.
The API and tunelling works but there's no (stable and good working) client for
this API. I hacked up a dirty netcat-like terminal into virsh for testing
purposes (see patch 5/5) but that isn't what I'd like to see.
The client should be able to open a listening socket and when a client connects
to it, it opens a stream and connects it to the remote host.
For the client there are two options:
1) do all the stuff in virsh: + one tool to rule them all
- i'd like to daemonize it and I don't know if that's okay in virsh
2) add a new tool "virtunnel": + less virsh pollution
- separate tool ...
As nobody responded, I'd like to re-ask for someones opinion on this.
(note: this is my personal effort, I'm annoyed of opening ssh tunnels to remote displays on my server
and I don't want to open the ports to public. )
After this it would be great to add support for this to virt-viewer. I will have a look at that later.
----
Diff to v1:
- fixed error reporting in 2/5
- documented limitation to "localhost" in 3/5
- fixed possible segfault in 4/5
---
Peter Krempa (5):
api: Add API to allow TCP tunneling through streams to the host
fdstream: Add support for TCP connections of streams
qemu: Add configuration options to enable TCP tunelling
qemu: Implement virNodeTunnelTcp for the qemu driver
NOT_TO_BE_APPLIED_UPSTREAM: quick and dirty virsh client to test the
stuff
include/libvirt/libvirt.h.in | 11 +++++++
src/driver.h | 8 +++++
src/fdstream.c | 73 ++++++++++++++++++++++++++++++++++++++++++++
src/fdstream.h | 5 +++
src/libvirt.c | 67 ++++++++++++++++++++++++++++++++++++++++
src/libvirt_private.syms | 1 +
src/libvirt_public.syms | 1 +
src/qemu/qemu.conf | 16 ++++++++++
src/qemu/qemu_conf.c | 26 ++++++++++++++++
src/qemu/qemu_conf.h | 13 ++++++++
src/qemu/qemu_driver.c | 48 +++++++++++++++++++++++++++++
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 9 +++++-
src/remote_protocol-structs | 6 ++++
src/rpc/gendispatch.pl | 1 +
tools/console.c | 66 +++++++++++++++++++++------------------
tools/console.h | 9 ++----
tools/virsh-domain.c | 17 +++++++++--
tools/virsh-host.c | 60 ++++++++++++++++++++++++++++++++++++
19 files changed, 397 insertions(+), 41 deletions(-)
--
1.8.0
12 years, 1 month
[libvirt] [PATCH 0/2] Support PCI passthrough in libxl driver
by Chunyan Liu
This patch series is to add PCI passthrough support to libxenlight driver so that
it can create VM with managed/non-managed host pci device defined.
Chunyan Liu (2):
libxl: add APIs to prepare/release host pci device
libxl: support pci passthrough
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/libxl/libxl_conf.c | 44 ++++
src/libxl/libxl_conf.h | 5 +-
src/libxl/libxl_driver.c | 16 ++
src/libxl/libxl_hostdev.c | 600 +++++++++++++++++++++++++++++++++++++++++++++
src/libxl/libxl_hostdev.h | 44 ++++
7 files changed, 710 insertions(+), 1 deletions(-)
create mode 100644 src/libxl/libxl_hostdev.c
create mode 100644 src/libxl/libxl_hostdev.h
--
1.7.3.4
12 years, 1 month
[libvirt] [PATCH] virsh: add --start option to the define command
by Doug Goldstein
I often find myself doing virsh "define blah.xml; start blah". I figured
adding this would be a easier^Hlazier way to do it.
---
tools/virsh-domain.c | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index e91939c..1a3af34 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -5597,6 +5597,7 @@ static const vshCmdInfo info_define[] = {
static const vshCmdOptDef opts_define[] = {
{"file", VSH_OT_DATA, VSH_OFLAG_REQ, N_("file containing an XML domain description")},
+ {"start", VSH_OT_BOOL, 0, N_("start the domain after creation")},
{NULL, 0, 0, NULL}
};
@@ -5607,6 +5608,7 @@ cmdDefine(vshControl *ctl, const vshCmd *cmd)
const char *from = NULL;
bool ret = true;
char *buffer;
+ bool start;
if (vshCommandOptString(cmd, "file", &from) <= 0)
return false;
@@ -5614,17 +5616,31 @@ cmdDefine(vshControl *ctl, const vshCmd *cmd)
if (virFileReadAll(from, VSH_MAX_XML_FILE, &buffer) < 0)
return false;
+ start = vshCommandOptBool(cmd, "start");
+
dom = virDomainDefineXML(ctl->conn, buffer);
VIR_FREE(buffer);
if (dom != NULL) {
vshPrint(ctl, _("Domain %s defined from %s\n"),
virDomainGetName(dom), from);
- virDomainFree(dom);
} else {
vshError(ctl, _("Failed to define domain from %s"), from);
- ret = false;
+ return false;
}
+
+ /* Start the domain if the user requested it and it was defined */
+ if (start) {
+ if (virDomainCreate(dom) < 0) {
+ vshError(ctl, _("Failed to start domain %s, which was "
+ "successfully defined."), virDomainGetName(dom));
+ ret = false;
+ } else {
+ vshPrint(ctl, _("Domain %s started\n"), virDomainGetName(dom));
+ }
+ }
+
+ virDomainFree(dom);
return ret;
}
--
1.7.8.6
12 years, 1 month
