Re: [libvirt] [PATCH] block: Set cdrom device read only flag
by Kevin Shanahan
On Thu, Aug 02, 2012 at 11:46:13AM +0930, Kevin Shanahan wrote:
> On Thu, Aug 02, 2012 at 11:02:42AM +0930, Kevin Shanahan wrote:
> > Set the block driver read_only flag for cdrom devices so that
> > qmp_change_blockdev does not attempt to open cdrom files in read-write
> > mode when changing media.
>
> Hrm, this fixes my simple test case using the kvm monitor directly but
> changing media via libvirt still has the same issue (fails for RO
> files, succeeds for writable files).
>
> $ virsh attach-disk --type cdrom --mode readonly test1 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso hdc
> error: Failed to attach disk
> error: internal error unable to execute QEMU command 'change': Could not open '/srv/kvm/iso/ubuntu-12.04-server-amd64.iso'
>
> I'll keep looking into it.
In the libvirt case, it seems libvirt is failing to add media=cdrom to
the commandline, so in this case qemu is defaulting to media=disk and
my proposed fix has no effect. Diving into libvirt now to see why no
media=disk is getting added...
Common test case has this xml (generated by virt-install):
<disk type='block' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
> Cheers,
> Kevin.
12 years, 2 months
[libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
by Marcelo Cerri
This is a v4 patch series that updates the libvirt's security driver mechanism to support per-guest configurable user and group for QEMU processes running together with other security drivers, such as SELinux and AppArmor.
Marcelo Cerri (5):
Internal refactory of data structures
Multiple security drivers in XML data
Update security layer to handle many security labels
Support for multiple default security drivers in QEMU config
Update the remote API
daemon/remote.c | 63 ++++
docs/formatdomain.html.in | 11 +-
docs/schemas/capability.rng | 18 +-
docs/schemas/domaincommon.rng | 30 ++-
include/libvirt/libvirt.h.in | 2 +
python/generator.py | 1 +
src/conf/capabilities.c | 17 +-
src/conf/capabilities.h | 6 +-
src/conf/domain_audit.c | 14 +-
src/conf/domain_conf.c | 343 +++++++++++++++-----
src/conf/domain_conf.h | 20 +-
src/driver.h | 4 +
src/libvirt.c | 47 +++
src/libvirt_private.syms | 5 +
src/libvirt_public.syms | 1 +
src/lxc/lxc_conf.c | 8 +-
src/lxc/lxc_controller.c | 8 +-
src/lxc/lxc_driver.c | 11 +-
src/lxc/lxc_process.c | 23 +-
src/qemu/qemu.conf | 6 +-
src/qemu/qemu_conf.c | 38 ++-
src/qemu/qemu_conf.h | 2 +-
src/qemu/qemu_driver.c | 218 +++++++++++---
src/qemu/qemu_process.c | 50 ++-
src/remote/remote_driver.c | 46 +++
src/remote/remote_protocol.x | 17 +-
src/remote_protocol-structs | 11 +
src/security/security_apparmor.c | 118 +++++--
src/security/security_dac.c | 324 +++++++++++++++++--
src/security/security_manager.c | 101 +++++--
src/security/security_manager.h | 8 +-
src/security/security_selinux.c | 263 +++++++++++-----
src/security/security_stack.c | 237 +++++++++-----
src/security/security_stack.h | 13 +
src/test/test_driver.c | 11 +-
.../qemuxml2argv-seclabel-dynamic-override.xml | 4 +-
.../qemuxml2argv-seclabel-dynamic.xml | 2 +-
37 files changed, 1653 insertions(+), 448 deletions(-)
12 years, 2 months
[libvirt] RFC: take two on live update of network configuration
by Laine Stump
We need a way to update the elements of a <network> without being
required to restart the network before the changes take effect. I had
previously thought I could just use a new virNetworkDefineXMLFlags with
an optional flag set to mean "take effect immediately", but have been
discouraged from that approach.
Instead, I'm considering something similar to
virDomain(Attach|Update|Detach)DeviceFlags, but this could be more
complicated because I would like to be able to update *anything* within
the network definition hierarchy, not just the direct subelements of one
level in the hierarchy (as is the case for those existing functions).
Here's an example of an existing network (note that this isn't a legal
network - you can't have an <ip> element and an interface pool (or a
bridge name and an interface pool) in the same network; this is just so
I can use a single example), and some of the things we might want to do
with it:
<network>
<name>test1</name>
<uuid>2d39a0ba-ac4b-6097-114c-50f8bccc277c</uuid>
<forward mode='bridge'/>
<bridge name='virbr5' stp='on' delay='0' />
<mac address='52:54:00:38:81:4D'/>
<domain name='example.com'/>
<forward mode='private'/>
<interface dev="eth20"/>
<interface dev="eth21"/>
<interface dev="eth22"/>
<interface dev="eth23"/>
<interface dev="eth24"/>
</forward>
<portgroup name='engineering' default='yes'>
<virtualport type='802.1Qbh'>
<parameters profileid='test'/>
</virtualport>
<bandwidth>
<inbound average='1000' peak='5000' burst='5120'/>
<outbound average='1000' peak='5000' burst='5120'/>
</bandwidth>
</portgroup></b>
<portgroup name='sales'>
<virtualport type='802.1Qbh'>
<parameters profileid='salestest'/>
</virtualport>
<bandwidth>
<inbound average='500' peak='2000' burst='2560'/>
<outbound average='128' peak='256' burst='256'/>
</bandwidth>
</portgroup></b>
<dns>
<txt name="example" value="example value" />
<srv service='name' protocol='tcp' domain='test-domain-name' target='.' port='1024' priority='10' weight='10'/>
<host ip='192.168.122.2'>
<hostname>myhost</hostname>
<hostname>myhostalias</hostname>
</host>
</dns>
<ip address='10.24.75.1' netmask='255.255.255.0'>
<dhcp>
<range start='10.24.75.128' end='10.24.75.254' />
<host mac='52:54:3e:77:e2:ed' name='X.example.com' ip='10.24.75.10' />
<host mac='52:54:3e:77:e2:ef' name='Y.example.com' ip='10.24.75.11' />
<host mac='52:54:34:77:e2:f0' name='Z.example.com' ip='10.24.75.12' />
<host mac='52:54:3e:77:e2:f1' name='A.example.com' ip='10.24.75.13' />
</dhcp>
</ip>
<ip address='192.168.4.1' netmask='255.255.255.0'/>
</network>
Some things we might want to do to this (the first three have already
been requested):
1) add or remove an interface from the interface pool, i.e. a particular
<interface> sub-element of the (one and only) <forward> element.
2) add/remove/modify a portgroup entry (i.e. a specific sub-element of
<network>)
3) add/remove/modify a static host entry from the <dhcp> section of a
particular <ip> (so, a particular <host> sub-element of a particular
<ip> element)
Some others:
4) add/modify/remove a <host> (or a <txt> or an <srv> in the <dns> section
4) add/modify/remove the <domain>
5) add/modify/remove an entire <ip> element
6) turn stp on/off in the <bridge> element
I can see three possible methods of providing this functionality:
===========
OPTION 1) Have a single API:
virNetworkUpdate(virNetworkPtr network,
const char *xml, unsigned, int flags)
This function would take an entire <network> specification as an arg,
and replace the entire existing config. This would allow changing
anything, but would also require reading the entire config beforehand.
===========
OPTION 2) have a separate API for each different type of element we may want to
change, e.g.:
virNetworkUpdateForwardInterface(virNetworkPtr network,
const char *xml,
unsigned int flags);
virNetworkUpdatePortgroup(virNetworkPtr network,
const char *xml,
unsigned int flags);
virNetworkUpdateIpDhcpHost(virNetworkPtr network,
const char *xml,
unsigned int flags);
virNetworkUpdateDnsEntry(virNetworkPtr network,
const char *xml,
unsigned int flags);
/* The name of this one may confuse... */
virNetworkUpdateDomain(virNetworkPtr network,
const char *xml,
unsigned int flags);
virNetworkUpdateBridge(virNetworkPtr network,
const char *xml,
unsigned int flags);
virNetworkUpdateIpDnsHost(virNetworkPtr network,
const char *xml,
unsigned int flags);
etc. (etc. etc.)
"flags" would include:
/* force add if object with matching key doesn't exist */
VIR_NETWORK_UPDATE_ADD
/* delete existing object(s) that matches the xml */
VIR_NETWORK_UPDATE_DELETE
/* take effect immediately */
VIR_NETWORK_UPDATE_LIVE
/* persistent change */
VIR_NETWORK_UPDATE_CONFIG
This method could be problematic, e.g., for something like
virNetworkUpdateIpDhcpHost() - although currently only a single <ip>
element can have a <dhcp> entries, in the future we could allow any/all
of them to have dhcp entries. Another downside is that we would need to
add an new function for each new element we decide we want to be able to
update.
===========
OPTION 3) Again, a single API, but with an added "nodespec" arg which would
be used to describe the parent node you of the node you want added/updated to:
int virNetworkUpdate(virNetworkPtr network,
const char *nodeSpec,
const char *xml,
unsigned int flags);
For example, if you wanted to add a new <host> entry to <ip
address='10.24.75.1' ...>'s dhcp element, you would do this:
/* nodespec obviously uses an XPath expression */
virNetworkUpdate("/ip[address='10.24.75.1']/dhcp",
/* full text of <host> element to add */
"<host mac='00:16:3e:77:e2:ed' "
"name='X.example.com' ip='10.24.75.10'/>"
VIR_NETWORK_UPDATE_ADD | VIR_NETWORK_UPDATE_LIVE
| VIR_NETWORK_UPDATE_CONFIG);
Or, to change the contents of the exiting portgroup "engineering" you
would use:
virNetworkUpdate("/",
/* full text of portgroup */,
"<portgroup name='engineering'> ..... </portgroup>"
VIR_NETWORK_UPDATE_LIVE|VIR_NETWORK_UPDATE_CONFIG);
To delete a static dhcp host entry, you would use this:
virNetworkUpdate("/ip[address='10.24.75.1']/dhcp",
/* just enough to match existing entry */
"<host mac='00:16:3e:77:e2:ed'/>",
VIR_NETWORK_UPDATE_DELETE | VIR_NETWORK_UPDATE_LIVE
| VIR_NETWORK_UPDATE_CONFIG);
or if you preferred:
virNetworkUpdate("/ip[address='10.24.75.1']/dhcp",
/* again, just enough to match */
"<host ip='10.24.75.10'/>",
VIR_NETWORK_UPDATE_DELETE |VIR_NETWORK_UPDATE_LIVE
| VIR_NETWORK_UPDATE_CONFIG);
To remove an interface from the interface pool:
virNetworkUpdate("/forward",
"<interface dev='eth20'/>",
VIR_NETWORK_UPDATE_DELETE | VIR_NETWORK_UPDATE_LIVE
| VIR_NETWORK_UPDATE_CONFIG)
(adding an interface would be identical, except the flag).
(An alternate implementation would be to have nodeSpec specify the node
that is being updated/removed rather than its parent. This may make more
logical sense, (although not for ADD) and would even make the rest of
the code simpler for update/remove (we wouldn't have to do a manual
search within the node).
The positive side of this is that the one API function allows you to modify
*anything* (even stuff not yet invented, so it's future-proof). The negative
side is that the code that implements it would need to go to quite a bit of
extra trouble to determine what has been changed (basically, it would
a) generate XML for the current state of the network,
b) parse that into an xmlNode,
c) perform the operation on xmlNode using nodeset to figure out where,
and adding in the new xml (or removing any nodes matching it),
d) convert modified xmlNode back to xml text,
e) parse the xml text into a virNetworkDef,
f) compare it to the original virNetworkDef to determine what to do.
==========
Which OPTION? 1, 2, or 3?
=========================
I'm discounting option (1) for now. Here's the scorecard for (2) vs. (3):
2) Pros: easier to understand, more exactly defined.
Cons: requires a new API each time we find a different node we want
to be able to update
3) Pros: one API covers everything, should never need any new API
Cons: more complex for user to understand, me to implement. Possibly
more trouble to do fine grained access control (e.g. if you want
to allow adding dhcp static hosts, but not allow changing the
domain name or interface pool)
(actually, in practice, I guess it shouldn't be any more trouble to do
fine grained access control, as long as you can make the decision of
whether or not to allow later on in the function that implements the API
(at step (6) above), rather than at the top level when the API is first
called).
I'm leaning towards (3). If it raises a technical boundary, or people
don't like the idea of having an arg in the public API that takes an
XPath expression, then maybe I could switch to (2).
Any opinions on which direction I should take? Some way different from
what I'm suggesting?
Specific questions:
1) Does having a single public API that is used to update many different
parts of the object raise any hurdles wrt. fine grained access control?
(knowing that there will be "some point" in that code that we know
exactly what the user is attempting to change).
2) any problems / reservations about accepting XPatch expressions in the
args of a public API?
3) Can you think of a situation where this wouldn't work?
12 years, 2 months
Re: [libvirt] [User question] Huge buffer size on KVM host
by Avi Kivity
On 08/16/2012 05:54 PM, Martin Wawro wrote:
>
> On Aug 15, 2012, at 2:57 PM, Avi Kivity wrote:
>
>>>
>>> We are using logical volumes and the cache is set to 'none'.
>>
>> Strange, that should work without any buffering.
>>
>> What the contents of
>>
>> /sys/block/sda/queue/hw_sector_size
>>
>> and
>>
>> /sys/block/sda/queue/logical_block_size
>>
>> ?
>>
>
> Hi Avi,
>
> It seems that the kernel on that particular machine is too old, those entries are
> not featured. We checked on a comparable setup with a newer kernel and both entries
> were set to 512.
>
> We also did have a third more thorough look on the caching. It turns out that the
> virt-manager does not seem to honor the caching adjusted in the GUI correctly.
> We disabled caching on all virtual devices for this particular VM and checking
> with "ps -fxal" revealed, that only one of those devices (and a rather small one too)
> had this set. We corrected this in the XML file directly and the buffer size
> currently resides at around 1.8 GB after rebooting the VM (the only virtio device
> not having the cache=none option set is now the (non-mounted) cdrom).
>
cc += libvirt-list
Is there a reason that cdroms don't get cache=none?
--
error compiling committee.c: too many arguments to function
12 years, 2 months
[libvirt] [PATCHv6 0/2] Implementation of virConnectListAllDomains() for esx and hyperv
by Peter Krempa
Yet another respin updated and rebased to current head.
Both drivers are compile tested but I don't have the infrastructure do a
functional test.
Peter Krempa (2):
hyperv: Add implementation for virConnectListAllDomains()
esx: Add implementation for virConnectListAllDomains()
src/esx/esx_driver.c | 194 +++++++++++++++++++++++++++++++++++++++++++++
src/hyperv/hyperv_driver.c | 135 +++++++++++++++++++++++++++++++
2 files changed, 329 insertions(+)
--
1.7.12
12 years, 2 months
[libvirt] [PATCH V3] Add proxy FS support to libvirt
by M. Mohan Kumar
From: "M. Mohan Kumar" <mohan(a)in.ibm.com>
A new FS driver type 'proxy' is added to QEMU 9p server. This patch adds
support for using proxy FS driver from libvirt.
QEMU proxy FS driver uses socket for communicating between helper and qemu
proxy FS driver. Proxy helper (a stand alone binary part of qemu) is invoked
with one of the descriptors created using socketpair call and the share path.
Similarly QEMU is invoked with another descriptor created using the same
socketpair system call and with other required FS driver parameters.
Need for proxy FS driver
========================
Pass through security model in QEMU 9p server has following issues:
1) TOCTTOU vulnerability: Following symbolic links in the server could
provide access to files beyond 9p export path.
2) Running QEMU with root privilege could be a security issue (pass
through security model needs root privilege).
Proxy FS driver is implemented to solve these issues.
Proxy FS uses chroot + socket combination for securing the vulnerability
known with following symbolic links. Intention of adding a new filesystem
type is to allow qemu to run in non-root mode, but doing privileged
operations in a chroot environment using socket IO.
Proxy helper is invoked with root privileges and chroots into 9p export path.
QEMU proxy fs driver sends filesystem request to proxy helper and receives the
response from it.
Proxy helper is designed such a way that it needs only few capabilities related
to filesystem operations (such as CAP_DAC_OVERRIDE, CAP_FOWNER, etc) and all
other capabilities are dropped (CAP_SYS_CHROOT, etc)
Proxy patches
http://permalink.gmane.org/gmane.comp.emulators.qemu/128735
Signed-off-by: M. Mohan Kumar <mohan(a)in.ibm.com>
---
Changes from previous version V3
* Addressed Daniel's review comments
Changes from previous version V2
* Rebased on top of current libvirt git level
Changes from previous version
* Remove the xml node for specifying the virtfs-proxy-helper path, now it is
determined from qemu binary path.
docs/formatdomain.html.in | 2 +
src/conf/domain_conf.c | 3 +-
src/conf/domain_conf.h | 2 +-
src/qemu/qemu_capabilities.c | 5 ++-
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 83 ++++++++++++++++++++++++++++++++++++++++--
src/qemu/qemu_command.h | 3 +-
tests/qemuhelptest.c | 7 +++-
8 files changed, 96 insertions(+), 10 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 2c5c456..bf74ed8 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1621,6 +1621,8 @@
while the value <code>immediate</code> means that a host writeback
is immediately triggered for all pages touched during a guest file
write operation <span class="since">(since 0.9.10)</span>.
+ or <code>type='proxy'</code> <span class="since">(since
+ 1.0)</span>.
</dd>
<dt><code>type='template'</code></dt>
<dd>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 851284a..79ca2b7 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -268,7 +268,8 @@ VIR_ENUM_IMPL(virDomainFS, VIR_DOMAIN_FS_TYPE_LAST,
VIR_ENUM_IMPL(virDomainFSDriverType, VIR_DOMAIN_FS_DRIVER_TYPE_LAST,
"default",
"path",
- "handle")
+ "handle",
+ "proxy")
VIR_ENUM_IMPL(virDomainFSAccessMode, VIR_DOMAIN_FS_ACCESSMODE_LAST,
"passthrough",
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index fd0e89e..a296f49 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -660,6 +660,7 @@ enum virDomainFSDriverType {
VIR_DOMAIN_FS_DRIVER_TYPE_DEFAULT = 0,
VIR_DOMAIN_FS_DRIVER_TYPE_PATH,
VIR_DOMAIN_FS_DRIVER_TYPE_HANDLE,
+ VIR_DOMAIN_FS_DRIVER_TYPE_PROXY,
VIR_DOMAIN_FS_DRIVER_TYPE_LAST
};
@@ -698,7 +699,6 @@ struct _virDomainFSDef {
unsigned long long space_soft_limit; /* in bytes */
};
-
/* 5 different types of networking config */
enum virDomainNetType {
VIR_DOMAIN_NET_TYPE_USER,
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 5472267..88b7e87 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -144,7 +144,6 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST,
"ich9-ahci",
"no-acpi",
"fsdev-readonly",
-
"virtio-blk-pci.scsi", /* 80 */
"blk-sg-io",
"drive-copy-on-read",
@@ -172,7 +171,7 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST,
"bridge", /* 100 */
"lsi",
"virtio-scsi-pci",
-
+ "fsdev-proxy",
);
struct qemu_feature_flags {
@@ -1133,6 +1132,8 @@ qemuCapsComputeCmdFlags(const char *help,
qemuCapsSet(flags, QEMU_CAPS_FSDEV_READONLY);
if (strstr(fsdev, "writeout"))
qemuCapsSet(flags, QEMU_CAPS_FSDEV_WRITEOUT);
+ if (strstr(fsdev, "sock_fd"))
+ qemuCapsSet(flags, QEMU_CAPS_FSDEV_PROXY);
}
if (strstr(help, "-smbios type"))
qemuCapsSet(flags, QEMU_CAPS_SMBIOS_TYPE);
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index d606890..073a1cd 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -138,6 +138,7 @@ enum qemuCapsFlags {
QEMU_CAPS_NETDEV_BRIDGE = 100, /* bridge helper support */
QEMU_CAPS_SCSI_LSI = 101, /* -device lsi */
QEMU_CAPS_VIRTIO_SCSI_PCI = 102, /* -device virtio-scsi-pci */
+ QEMU_CAPS_FSDEV_PROXY = 103, /* -fsdev proxy supported */
QEMU_CAPS_LAST, /* this must always be the last item */
};
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 4ca3047..3f78635 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -46,6 +46,7 @@
#include <sys/utsname.h>
#include <sys/stat.h>
#include <fcntl.h>
+#include <libgen.h>
#define VIR_FROM_THIS VIR_FROM_QEMU
@@ -116,7 +117,8 @@ VIR_ENUM_DECL(qemuDomainFSDriver)
VIR_ENUM_IMPL(qemuDomainFSDriver, VIR_DOMAIN_FS_DRIVER_TYPE_LAST,
"local",
"local",
- "handle");
+ "handle",
+ "proxy");
static void
@@ -2632,9 +2634,59 @@ error:
return NULL;
}
+/*
+ * Invokes the Proxy Helper with one of the socketpair as its parameter
+ *
+ */
+static int qemuInvokeProxyHelper(const char *emulator, int sock, const char *path)
+{
+#define HELPER "virtfs-proxy-helper"
+ int ret_val, status;
+ virCommandPtr cmd;
+ char *helper, *dname, *dp;
+
+ dp = strdup(emulator);
+ if (!dp) {
+ virReportOOMError();
+ return -1;
+ }
+ dname = strrchr(dp, '/');
+ if (!dname) {
+ VIR_FREE(dp);
+ VIR_FORCE_CLOSE(sock);
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unable to get path details from %s"), dp);
+ return -1;
+ }
+ *dname = '\0';
+ if (virAsprintf(&helper, "%s/%s", dp, HELPER) < 0) {
+ VIR_FREE(dp);
+ VIR_FORCE_CLOSE(sock);
+ virReportOOMError();
+ return -1;
+ }
+
+ cmd = virCommandNewArgList(helper, NULL);
+ virCommandAddArg(cmd, "-f");
+ virCommandAddArgFormat(cmd, "%d", sock);
+ virCommandAddArg(cmd, "-p");
+ virCommandAddArgFormat(cmd, "%s", path);
+ virCommandTransferFD(cmd, sock);
+ virCommandDaemonize(cmd);
+ ret_val = virCommandRun(cmd, &status);
+ if (ret_val < 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("%s can't execute"), helper);
+ VIR_FORCE_CLOSE(sock);
+ }
+ virCommandFree(cmd);
+ VIR_FREE(helper);
+ VIR_FREE(dp);
+ return ret_val;
+}
char *qemuBuildFSStr(virDomainFSDefPtr fs,
- virBitmapPtr qemuCaps ATTRIBUTE_UNUSED)
+ virBitmapPtr qemuCaps ATTRIBUTE_UNUSED, int qemuSocket)
{
virBuffer opt = VIR_BUFFER_INITIALIZER;
const char *driver = qemuDomainFSDriverTypeToString(fs->fsdriver);
@@ -2683,6 +2735,10 @@ char *qemuBuildFSStr(virDomainFSDefPtr fs,
}
virBufferAsprintf(&opt, ",id=%s%s", QEMU_FSDEV_HOST_PREFIX, fs->info.alias);
+
+ if (fs->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_PROXY)
+ virBufferAsprintf(&opt, ",sock_fd=%d", qemuSocket);
+
virBufferAsprintf(&opt, ",path=%s", fs->src);
if (fs->readonly) {
@@ -5153,10 +5209,31 @@ qemuBuildCommandLine(virConnectPtr conn,
if (qemuCapsGet(qemuCaps, QEMU_CAPS_FSDEV)) {
for (i = 0 ; i < def->nfss ; i++) {
char *optstr;
+ int sockets[2] = {-1, -1};
virDomainFSDefPtr fs = def->fss[i];
+ /*
+ * If its a proxy FS, we need to create a socket pair
+ * and invoke proxy_helper
+ */
+ if (fs->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_PROXY) {
+ if (qemuCapsGet(qemuCaps, QEMU_CAPS_FSDEV_PROXY) < 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("proxy helper not supported"));
+ goto error;
+ }
+ /* create a socket pair */
+ if (socketpair(PF_UNIX, SOCK_STREAM, 0, sockets) < 0) {
+ virReportSystemError(errno, _("socketpair %s"), "failed");
+ goto error;
+ }
+ virCommandTransferFD(cmd, sockets[1]);
+ if (qemuInvokeProxyHelper(def->emulator, sockets[0],
+ fs->src) < 0)
+ goto error;
+ }
virCommandAddArg(cmd, "-fsdev");
- if (!(optstr = qemuBuildFSStr(fs, qemuCaps)))
+ if (!(optstr = qemuBuildFSStr(fs, qemuCaps, sockets[1])))
goto error;
virCommandAddArg(cmd, optstr);
VIR_FREE(optstr);
diff --git a/src/qemu/qemu_command.h b/src/qemu/qemu_command.h
index e999bc7..2da5ad0 100644
--- a/src/qemu/qemu_command.h
+++ b/src/qemu/qemu_command.h
@@ -89,7 +89,8 @@ char *qemuBuildDriveStr(virConnectPtr conn,
bool bootable,
virBitmapPtr qemuCaps);
char *qemuBuildFSStr(virDomainFSDefPtr fs,
- virBitmapPtr qemuCaps);
+ virBitmapPtr qemuCaps,
+ int qemuSocket);
/* Current, best practice */
char * qemuBuildDriveDevStr(virDomainDefPtr def,
diff --git a/tests/qemuhelptest.c b/tests/qemuhelptest.c
index 2d15c94..6af2e68 100644
--- a/tests/qemuhelptest.c
+++ b/tests/qemuhelptest.c
@@ -679,7 +679,9 @@ mymain(void)
QEMU_CAPS_SCSI_BLOCK,
QEMU_CAPS_SCSI_CD,
QEMU_CAPS_IDE_CD,
- QEMU_CAPS_SCSI_LSI);
+ QEMU_CAPS_SCSI_LSI,
+ QEMU_CAPS_FSDEV_PROXY);
+
DO_TEST("qemu-1.1.0", 1001000, 0, 0,
QEMU_CAPS_VNC_COLON,
QEMU_CAPS_NO_REBOOT,
@@ -759,7 +761,8 @@ mymain(void)
QEMU_CAPS_NEC_USB_XHCI,
QEMU_CAPS_NETDEV_BRIDGE,
QEMU_CAPS_SCSI_LSI,
- QEMU_CAPS_VIRTIO_SCSI_PCI);
+ QEMU_CAPS_VIRTIO_SCSI_PCI,
+ QEMU_CAPS_FSDEV_PROXY);
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
--
1.7.7.6
12 years, 2 months
[libvirt] [RFC PATCH v1 0/2] Qemu/Gluster support in Libvirt
by Harsh Prateek Bora
This patchset provides support for Gluster protocol based network disks.
It is based on the proposed gluster support in Qemu on qemu-devel:
http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01539.html
TODO:
- Add support for IPv6 format based server addr
- Support for transport types other than socket.
Harsh Prateek Bora (2):
Qemu/Gluster: Add Gluster protocol as supported network disk formats.
tests: Add tests for gluster protocol based network disks support
docs/schemas/domaincommon.rng | 8 ++
src/conf/domain_conf.c | 14 ++-
src/conf/domain_conf.h | 3 +-
src/qemu/qemu_command.c | 123 +++++++++++++++++++++
tests/qemuargv2xmltest.c | 1 +
.../qemuxml2argv-disk-drive-network-gluster.args | 1 +
.../qemuxml2argv-disk-drive-network-gluster.xml | 33 ++++++
tests/qemuxml2argvtest.c | 2 +
8 files changed, 182 insertions(+), 3 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-gluster.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-gluster.xml
--
1.7.11.2
12 years, 2 months
[libvirt] RFC: APIs to manage KSM
by Osier Yang
Triggered by the requirement to control the new sys knob
/sys/kernel/mm/ksm/merge_nodes for a NUMA aware host by
patch:
http://permalink.gmane.org/gmane.linux.kernel.mm/81497
It shows there is no methods to manage the KSM in
libvirt. This proposes the new APIs like following, thanks
for suggestions/idea in advance.
== The macros and enums for the params' fields
/* virNodeKSMRunMode:
*
* Represents the modes of /sys/kernel/mm/ksm/run.
*/
typedef enum {
/* Stop ksmd from running but keep merged pages */
VIR_NODE_STOP_KSM_KEEP_MERGED_PAGES = 0,
/* Start ksmd */
VIR_NODE_START_KSM = 1,
/* Stop ksmd and and unmerge all pages currently merged */
VIR_NODE_STOP_KSM_UNMERGE_PAGES = 2,
} virNodeKSMRunMode;
/*
* VIR_NODE_KSM_PAGES_TO_SCAN:
*
* Macro for typed parameter that represents how many present pages
* to scan before ksmd goes to sleep.
*/
# define VIR_NODE_KSM_PAGES_TO_SCAN "pages_to_scan"
/*
* VIR_NODE_KSM_SLEEP_MILLISECS:
*
* Macro for typed parameter that represents how many milliseconds
* ksmd should sleep before next scan.
*/
# define VIR_NODE_KSM_SLEEP_MILLISECS "sleep_millisecs"
/*
* VIR_NODE_KSM_RUN:
*
* Macro for typed parameter that is used to control ksmd's state, as
* an int containing a virNodeKSMRunMode value.
*/
# define VIR_NODE_KSM_RUN "run"
/*
* VIR_NODE_KSM_PAGES_SHARED:
*
* Macro for typed parameter that represents how many ksm shared pages
* are being used.
*/
# define VIR_NODE_KSM_PAGES_SHARED "pages_shared"
/*
* VIR_NODE_KSM_PAGES_SHARING:
*
* Macro for typed parameter that represents how many sites are
* sharing the pages i.e. how much saved.
*/
# define VIR_NODE_KSM_PAGES_SHARING "pages_sharing"
/* VIR_NODE_KSM_PAGES_UNSHARED:
*
* Macro for typed parameter that represents how many pages unique
* but repeatedly checked for merging.
*/
# define VIR_NODE_KSM_PAGES_UNSHARED "pages_unshared"
/* VIR_NODE_KSM_PAGES_VOLATILE:
*
* Macro for typed parameter that represents how many pages changing
* too fast to be placed in a tree.
*/
# define VIR_NODE_KSM_PAGES_VOLATILE "pages_volatile"
/* VIR_NODE_KSM_FULL_SCAN:
*
* Macro for typed parameter that represents how many times all
* mergeable areas have been scanned.
*/
# define VIR_NODE_KSM_FULL_SCAN "full_scan"
== API to Get KSM parameters.
/*
* virNodeGetKSMParameters:
* @conn: pointer to the hypervisor connection
* @params: pointer to memory parameter object
* (return value, allocated by the caller)
* @nparams: pointer to number of memory parameters; input and output
* @flags: extra flags; not used yet, so callers should always pass 0
*
* ... Detailed comments ommitted ...
*
* Returns 0 in case of success, and -1 in case of failure.
*/
int
virNodeGetKSMParameters(virConnectPtr conn,
virTypedParameterPtr params,
int *nparams,
unsigned int flags);
== API to set KSM parameters.
Currently only "run", "pages_to_scan", and "sleep_millisecs"
are writable. The new boolearn sys knob "merge_nodes" could
be added once it's acceptted by kernel upstream.
/*
* virNodeSetKSMParameters:
* @conn: pointer to the hypervisor connection
* @params: pointer to scheduler parameter objects
* @naprams: number of scheduler parameter objects
* (this value can be the same or less than the returned
* value nparams of virDomainGetSchedulerType)
* @flags: extra flags; not used yet, so callers should always pass 0
*
* ... Detailed comments ommitted ...
*
* Returns 0 in case of success, -1 in case of failure.
*/
int
virNodeSetKSMParameters(virConnectPtr conn,
virTypedParameterPtr params,
int nparams,
unsigned int flags);
BTW, the other thing libvirt misses is to tell ksmtuned to retune
when a domain is started or destroyed. Which is outlined in
the Red Hat Virtualization Administration Guide doc, but it's
not true. So either we have a hole in libvirt, or lacks a fix
for the document.
<...>
The KSM tuning service
The ksmtuned service does not have any options. The ksmtuned service
loops and adjusts ksm. The ksmtuned service is notified by libvirt when
a guest is created or destroyed.
</...>
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6...
Regards,
Osier
12 years, 2 months
[libvirt] [PATCH] Refactor ESX storage driver and add iSCSI support
by Ata E Husain Bohra
Resent of
http://www.redhat.com/archives/libvir-list/2012-August/msg01353.html.
Merging recent branch updates to this patch.
Ata E Husain Bohra (1):
Refactor ESX storage driver and add iSCSI support
src/Makefile.am | 16 +-
src/esx/esx_driver.c | 4 +-
src/esx/esx_storage_backend_iscsi.c | 794 +++++++++++++++++++
src/esx/esx_storage_backend_iscsi.h | 31 +
src/esx/esx_storage_backend_vmfs.c | 1471 +++++++++++++++++++++++++++++++++++
src/esx/esx_storage_backend_vmfs.h | 31 +
src/esx/esx_storage_driver.c | 1303 +++++--------------------------
src/esx/esx_vi.c | 341 +++++++-
src/esx/esx_vi.h | 21 +-
src/esx/esx_vi_generator.input | 308 +++++++-
src/esx/esx_vi_generator.py | 19 +
11 files changed, 3218 insertions(+), 1121 deletions(-)
create mode 100644 src/esx/esx_storage_backend_iscsi.c
create mode 100644 src/esx/esx_storage_backend_iscsi.h
create mode 100644 src/esx/esx_storage_backend_vmfs.c
create mode 100644 src/esx/esx_storage_backend_vmfs.h
--
1.7.9.5
12 years, 2 months
[libvirt] [PATCH] nwfilter: drop use of awk
by Eric Blake
Commit 2a41bc9 dropped a dependency on gawk, but we can go one step
further and avoid awk altogether.
* src/nwfilter/nwfilter_ebiptables_driver.c
(iptablesLinkIPTablesBaseChain): Simplify command.
(ebiptablesDriverInit, ebiptablesDriverShutdown): Drop awk probe.
---
Caveat - I was not set up to test this via actual nwfilter operations,
so it needs a thorough testing review.
src/nwfilter/nwfilter_ebiptables_driver.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/nwfilter/nwfilter_ebiptables_driver.c b/src/nwfilter/nwfilter_ebiptables_driver.c
index 034e6c4..8ffe737 100644
--- a/src/nwfilter/nwfilter_ebiptables_driver.c
+++ b/src/nwfilter/nwfilter_ebiptables_driver.c
@@ -84,7 +84,6 @@ static char *ebtables_cmd_path;
static char *iptables_cmd_path;
static char *ip6tables_cmd_path;
static char *grep_cmd_path;
-static char *awk_cmd_path;
#define PRINT_ROOT_CHAIN(buf, prefix, ifname) \
snprintf(buf, sizeof(buf), "libvirt-%c-%s", prefix, ifname)
@@ -565,12 +564,11 @@ static int iptablesLinkIPTablesBaseChain(virBufferPtr buf,
int stopOnError)
{
virBufferAsprintf(buf,
- "res=$($IPT -L %s -n --line-number | "
- "%s \" %s \")\n"
+ "res=$($IPT -L %s -n --line-number | %s '%s')\n"
"if [ $? -ne 0 ]; then\n"
" $IPT -I %s %d -j %s\n"
"else\n"
- " r=$(echo $res | %s '{print $1}')\n"
+ " set dummy $res; r=$2\n"
" if [ \"${r}\" != \"%d\" ]; then\n"
" " CMD_DEF("$IPT -I %s %d -j %s") CMD_SEPARATOR
" " CMD_EXEC
@@ -582,11 +580,9 @@ static int iptablesLinkIPTablesBaseChain(virBufferPtr buf,
" fi\n"
"fi\n",
- syschain,
- grep_cmd_path, udchain,
+ syschain, grep_cmd_path, udchain,
syschain, pos, udchain,
- awk_cmd_path,
pos,
@@ -4295,7 +4291,6 @@ ebiptablesDriverInit(bool privileged)
if (virMutexInit(&execCLIMutex) < 0)
return -EINVAL;
- awk_cmd_path = virFindFileInPath("awk");
grep_cmd_path = virFindFileInPath("grep");
/*
@@ -4311,7 +4306,7 @@ ebiptablesDriverInit(bool privileged)
/* ip(6)tables support needs awk & grep, ebtables doesn't */
if ((iptables_cmd_path != NULL || ip6tables_cmd_path != NULL) &&
- (!grep_cmd_path || !awk_cmd_path)) {
+ !grep_cmd_path) {
VIR_ERROR(_("essential tools to support ip(6)tables "
"firewalls could not be located"));
VIR_FREE(iptables_cmd_path);
@@ -4333,7 +4328,6 @@ ebiptablesDriverInit(bool privileged)
static void
ebiptablesDriverShutdown(void)
{
- VIR_FREE(awk_cmd_path);
VIR_FREE(grep_cmd_path);
VIR_FREE(ebtables_cmd_path);
VIR_FREE(iptables_cmd_path);
--
1.7.11.4
12 years, 2 months
