[libvirt] [PATCH v2 0/6] Move secret object command line building helpers
by John Ferlan
v1: http://www.redhat.com/archives/libvir-list/2016-May/msg02017.html
Changes in v2:
Patch 1 - Move function to a new src/util/virqemu.c with adjustments
to other affected areas
Patches 2-4 - Similarly adjust the flow/name of the patches with an
adjustment so that patch 2 is just the new code in virqemu.c and patch 3
shows how the master secret code would use the same function to build
it's command line. Patch 4 just follows suit...
Patch 5 was reviewed/ACK'd - this patch just shows the changes to remove
the "virSecretPtr secret = NULL;" and "virObjectUnref(secret);"
Patch 6 is unchanged
John Ferlan (6):
qemu: Move and rename qemuBuildObjectCommandlineFromJSON
util: Introduce virQEMUBuildSecretObjectProps
qemu: Use virQEMUBuildSecretObjectProps to build secret objects
qemu: Rework secinfo command line building
storage: Use virSecretGetSecretString
secret: Move virStorageSecretType to secret_util and rename
cfg.mk | 2 +-
po/POTFILES.in | 1 +
src/Makefile.am | 2 +
src/libvirt_private.syms | 5 +
src/libxl/libxl_conf.c | 2 +-
src/qemu/qemu_command.c | 219 +++++----------------
src/qemu/qemu_command.h | 4 -
src/qemu/qemu_domain.c | 4 +-
src/secret/secret_util.c | 18 +-
src/secret/secret_util.h | 22 ++-
src/storage/storage_backend_iscsi.c | 55 +-----
src/storage/storage_backend_rbd.c | 49 +----
src/util/virqemu.c | 211 ++++++++++++++++++++
src/util/virqemu.h | 42 ++++
src/util/virstoragefile.c | 33 ++--
src/util/virstoragefile.h | 17 +-
tests/qemuargv2xmltest.c | 4 +-
tests/qemucommandutiltest.c | 9 +-
...muxml2argv-disk-drive-network-rbd-auth-AES.args | 3 +-
.../qemuxml2argvdata/qemuxml2argv-master-key.args | 3 +-
.../qemuxml2argvdata/qemuxml2argv-name-escape.args | 3 +-
21 files changed, 380 insertions(+), 328 deletions(-)
create mode 100644 src/util/virqemu.c
create mode 100644 src/util/virqemu.h
--
2.5.5
8 years, 5 months
[libvirt] RFC: turn cpu 'host-model' into 'custom' for active config on domain start
by Nikolay Shirokovskiy
Hi, everyone.
Cpu mode 'host-model' is not convinient for migration in current form.
Consider migration from less capable host to more capable one - it is possible.
But then migration backwards is impossible despite the fact that qemu process
on destination is running with the same model and features as on source because
migration does not update 'host-model' cpu upon migration on destination. The
problem is that on migrating back instead of taking current cpu config
'host-model' is expanded again and gain extra features of destination and
migration failed by source (new destination) side.
What if we change cpu for active config from 'host-model' into 'custom' in
the starting process? Then this issue will be fixed. It is quite reasonable
from my POV - 'host-model' is effectively about taking active domain cpu from host on
start, after that active domain cpu is on its own. Persistent config stays
'host-model' so migrating of active domain and restarting it gains extra
features of new host as before.
Nikolay
8 years, 5 months
[libvirt] NFS over AF_VSOCK in <filesystem>
by Stefan Hajnoczi
virtio-vsock support has been added to the nfs-ganesha NFS server. I'm
currently working on upstreaming virtio-vsock into Linux and QEMU. I
also have patches for the Linux NFS client and server.
Users wishing to share a file system with the guest will need to
configure the NFS server. Perhaps libvirt could handle that given that
it already has <filesystem> syntax.
The basic task is setting up either the kernel nfsd or nfs-ganesha for
the VM to access the NFS export(s). When the VM is destroy the NFS
server can be shut down.
Does this sound like a responsibility that libvirt should handle?
Stefan
8 years, 5 months
[libvirt] [PATCH 0/3] bhyve: virConnectDomainXMLFromNative
by Fabian Freyer
The following series of patches implement virConnectDomainXMLFromNative. This
is mostly some boiler plate code generating argv-lists from the native command
string, and two getopt-based argument parsers for the /usr/sbin/bhyve and
/usr/sbin/bhyveload commands.
Since there is quite some string handling involved especially in the first
patch that I am not 100% sure about, I'd appreciate a thorough review.
Fabian Freyer (3):
bhyve: implement virConnectDomainXMLFromNative
bhyve: implement bhyve argument parser
bhyve: implement argument parser for loader
po/POTFILES.in | 1 +
src/Makefile.am | 2 +
src/bhyve/bhyve_driver.c | 42 ++
src/bhyve/bhyve_parse_command.c | 869 ++++++++++++++++++++++++++++++++++++++++
src/bhyve/bhyve_parse_command.h | 30 ++
5 files changed, 944 insertions(+)
create mode 100644 src/bhyve/bhyve_parse_command.c
create mode 100644 src/bhyve/bhyve_parse_command.h
--
2.7.0
8 years, 5 months
Re: [libvirt] [ovs-dev] [PATCH v2 2/2] netdev-dpdk: Support user-defined socket attribs
by Ansis Atteka
On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
<christian.ehrhardt(a)canonical.com> wrote:
> On Tue, May 24, 2016 at 4:10 PM, Aaron Conole <aconole(a)redhat.com> wrote:
>
>> Daniele Di Proietto <diproiettod(a)vmware.com> writes:
>>
>> > Hi Aaron,
>> >
>> > I'm still a little bit nervous about calling chown on a (partially)
>> > user controlled file name.
>>
>> I agree, that always seems scary.
>>
>> > Before moving forward I wanted to discuss a couple of other options:
>> >
>> > * Ansis (in CC) suggested using -runas parameter in qemu. This way
>> > qemu can open the socket as root and drop privileges before starting
>> > guest execution.
>>
>> I'm not sure how to do this with libvirt, or via the OpenStack Neutron
>> plugin. I also don't know if it would be an acceptable workaround for
>> users. Additionally, I recall there being something of a "don't even
>> know if this works" around it. Maybe Christian or Ansis (both in CC)
>> can expound on it.
>>
Cross-posting to libvirt mailing list to hear opinion from libvirt developers.
In short - the problem is that libvirtd process starts qemu process
under non-root user. Since qemu starts under non-root process, then
qemu can't connect to DPDK unix domain sockets created by ovs-vswitcd
process that runs under "root". There are two solutions to this
problem:
1. let ovs-vswitchd process to chown its socket from "root" to
"libvirt" group and/or user (this is what Aarons patch proposes)
2. make libvirtd process to start qemu process under "root" but then
let qemu to downgrade via "-run-as" flag after qemu has opened the
Unix Domain socket.
Regarding solution #2. I think the necessary changes roughly would be to:
1. invoke virCommandAddArgPair(cmd, "-runas", "libvirt") before
starting qemu process; AND
2. revert virCommandSetUID() that automatically downgrades user from
"root" to "libvirt" even before qemu starts.
I would like to hear feasibility of such solution from libvirt
developers? Or maybe there is even a better solution that I am
missing?
Regarding solution #1. There have already been precedents that other
daemons are chowning their sockets so that non-privileged daemons
could connect to them. IMHO this is not elegant from security
perspective but will at least get the job done if Linux Distribution
maintainers (Aaron and Christian) need to ship something out ASAP .
The thing I am concerned about this solutions is that ovs-vswitchd
could be used to chown() arbitrary files and sockets on file system if
there happens to be a bug. Also, this socket is not created by
ovs-vswitchd code base itself but rather from Intel DPDK library where
ovs-vswitchd calls into.
> Hi,
> IIRC we kind of agree that long term a proper MAC will be much better but
> most involved people needed something to get it working like "now".
> Since they are complementary (other than the fix removing a bit of the
> urgency for more MAC) it was kind of the least bad option.
>
> You have to be aware that I brought up the discussion on dev(a)dpdk.org - see
> [1] and [2]:
> But this will take time and eventually still be the applications task to
> "do something" - no matter if via API or via the chmod's right now.
> So Aaron is trying to get something that works now until the long term
> things are in place, which I appreciate.
>
> FYI - I was even more in a hurry as it was clear that OVS-2.5 won't get
> this in time I run with [3] for now.
> I never intended to suggest that, but with the discussion in place, one
> could ask if you (Aaron) want to pick up that instead.
> That would keep OVS free for now until DPDK made up the API (see [2]) for
> socket ownership control and this then could be implemented in OVS?
>
> (I hope) In some months/years we will all be happy to drop this bunch of
> interim solutions, never the less we need it for now.
>
> [1]: http://dpdk.org/dev/patchwork/patch/12222/
> [2]: http://dpdk.org/ml/archives/dev/2015-December/030326.html
> [3]:
> https://git.launchpad.net/~ubuntu-server/dpdk/commit/?h=ubuntu-xenial-to-...
>
> [...]
>
>
>> I think originally we quickly discussed 4 possible solutions (and
>> hopefully I captured them correctly):
>>
>> 1. OVS downgrades to the ovs user, and kvm runs under the ovs
>> group. I don't actually like this solution because kvm could then
>> pollute the ovs database.
>>
>> 2. OVS runs as some user and sets the user/group ownership of the socket
>> via chown/chmod where permissions come from the database (the
>> original context had ovs running as root - but as I described above
>> it doesn't need to be root provided ovs+DPDK can start without root).
>>
>> 3. OVS runs as some user, kvm starts as root, opens the socket and
>> downgrades. IIRC, this doesn't actually work, or it may have
>> implications on other projects. I don't remember exactly what was
>> not as great about this solution, TBH.
>>
>> 4. OVS and KVM run as whatever users; MAC is used to enforce the
>> layering between them.
>>
>> I think solution 2 and solution 4 don't actually interfere with each
>> other, and can be used to a complementary effect (if implemented
>> properly) so that the MAC layer enforces access, but even without MAC,
>> the DAC layer can provide appropriate whitelisting behavior.
>>
>
> I also remember several complex changes needed for the #1 and #3 that
> always would end up with huge effort and a high risk not being accepted.
> Probably that is what you refer to with "implications on other projects".
>
> Also keep in mind the position of dpdk out of the last few discussions
> which I'd like to summarize as "dpdk got this path from an app, so this app
> OWNS that path".
> _______________________________________________
> dev mailing list
> dev(a)openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
8 years, 5 months
