[libvirt] [PATCH 0/3] Clean up some virstorageencryption code
by John Ferlan
While working through adding luks support for libvirt, I have a few patches
that aren't really germane to adding support and rather than drop a large
patch series when I'm done - I figured I'd post a few adjustments.
In the long run the encryption code probably doesn't work, but I'm trying
to move it to the side at least.
John Ferlan (3):
util: Clean up code formatting in virstorageencryption
storage: Split out setting default secret for encryption
storage: Split out a helper for encryption checks
src/storage/storage_backend.c | 80 ++++++++++++++++++++++++++--------------
src/storage/storage_backend_fs.c | 79 ++++++++++++++++++++++++---------------
src/util/virstorageencryption.c | 58 ++++++++++++++---------------
3 files changed, 128 insertions(+), 89 deletions(-)
--
2.5.5
8 years, 6 months
[libvirt] Plan for the next release
by Daniel Veillard
I will be travelling end of this week and most of next week, but
I think we can still try to get a release for June 1st, I suggest:
- enter freeze this Thrusday 26
- Push an rc2 over the week-end
- try to push the 1.3.5 release on Wed June 1st
I hope this works for everybody !
Thanks,
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
8 years, 6 months
[libvirt] [PATCH v2 0/2] qemu: expand domain memory statistics
by Derbyshev Dmitriy
From: Derbyshev Dmitry <dderbyshev(a)virtuozzo.com>
QEMU reports timestamp and available along with other memory statistics.
This information was not saved into domain statistics.
Changes since v1:
* Enum numeration fixed
* Macro getting "usage" field fixed
Derbyshev Dmitry (2):
qemu: expand domain memory statistics with 'usable'
qemu: expand domain memory statistics with 'last-update' timestamp
include/libvirt/libvirt-domain.h | 11 ++++++++++-
src/libvirt-domain.c | 5 +++++
src/qemu/qemu_monitor_json.c | 23 +++++++++++++----------
tools/virsh-domain-monitor.c | 4 ++++
4 files changed, 32 insertions(+), 11 deletions(-)
--
1.9.5.msysgit.0
8 years, 7 months
[libvirt] [PATCH 0/4] Move secret object command line building helpers
by John Ferlan
More "extractable" changes from my work on adding luks support.
While working through changes in storage_backend.c I found that the
building of the 'qemu-img' command to create a luks volume will need
to create a secret object.
In order to do that I found if I took the qemu_command code and moved
things around a bit, then I would be able to access the API's that I
need. Moving the command line building from qemu_command.c to virjson.c
seemed logical since it was multipurpose/generic anyway. I'm not "tied"
to the API name chosen - if there's suggestions, I'll adjust. Then splitting
out the generation of the secret object props into their own API and then
eventually into secret_util.c seemed to be the best avenue. I can then
include secret_util into the storage driver.
The last change just cleans up the secinfo command building processing.
It was "complicated" when there was going to be hostdev and disk code
trying to generate the same objects... Now that just seems less important.
When/if iSCSI/hostdev support for the AES secret is added, I'll made the
appropriate adjustments then.
John Ferlan (4):
qemu: Move and rename qemuBuildObjectCommandlineFromJSON
qemu: Introduce qemuBuildSecretObjectProps
qemu: Move and rename qemuBuildSecretObjectProps
qemu: Rework secinfo command line building
src/libvirt_private.syms | 4 +-
src/qemu/qemu_command.c | 199 ++++++--------------------------------------
src/qemu/qemu_command.h | 4 -
src/secret/secret_util.c | 59 +++++++++++++
src/secret/secret_util.h | 10 +++
src/util/virjson.c | 117 +++++++++++++++++++++++++-
src/util/virjson.h | 12 ++-
tests/qemucommandutiltest.c | 7 +-
8 files changed, 219 insertions(+), 193 deletions(-)
--
2.5.5
8 years, 7 months
[libvirt] KVM Forum 2016: Call For Participation
by Paolo Bonzini
=================================================================
KVM Forum 2016: Call For Participation
August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada
(All submissions must be received before midnight May 1, 2016)
=================================================================
KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux
virtualization technology, and plan for the challenges ahead.
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2016.
At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.
KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.
This year, KVM Forum is joining LinuxCon and ContainerCon in Toronto,
Canada. Selected talks from KVM Forum will be presented on Wednesday
August 24 to the full audience of LinuxCon and ContainerCon. Also,
attendees of KVM Forum will have access to all of the LinuxCon and
ContainerCon talks on Wednesday.
http://events.linuxfoundation.org/cfp
Suggested topics:
KVM and Linux
* Scaling and optimizations
* Nested virtualization
* Linux kernel performance improvements
* Resource management (CPU, I/O, memory)
* Hardening and security
* VFIO: SR-IOV, GPU, platform device assignment
* Architecture ports
QEMU
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Scaling and optimizations
* Desktop virtualization and SPICE
* Virtual GPU
* virtio and vhost, including non-Linux or non-virtualized uses
* Hardening and security
* New storage features
* Live migration and fault tolerance
* High availability and continuous backup
* Real-time guest support
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, u-Boot, etc.
* Testing
Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: glusterfs, Ceph, etc.
* Software defined networking: Open vSwitch, OpenDaylight, etc.
* Network Function Virtualization
* Security
* Provisioning
* Performance tuning
===============
SUBMITTING YOUR PROPOSAL
===============
Abstracts due: May 1, 2016
Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include the proposal
type -- one of:
- technical talk
- end-user talk
Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"
You will receive a notification whether or not your presentation proposal
was accepted by May 27, 2016.
Speakers will receive a complimentary pass for the event. In the instance
that your submission has multiple presenters, only the primary speaker for a
proposal will receive a complementary event pass. For panel discussions, all
panelists will receive a complimentary event pass.
TECHNICAL TALKS
A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.
END-USER TALKS
One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.
If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.
HANDS-ON / BOF SESSIONS
We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.
These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at
http://www.linux-kvm.org/page/KVM_Forum_2016_BOF
Let people you think might be interested know about it, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.
PANEL DISCUSSIONS
If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your abstract. We will request full
biographies if a panel is accepted.
===============
HOTEL / TRAVEL
===============
This year's event will take place at the Westin Harbour Castle Toronto.
For information on discounted room rates for conference attendees
and on other hotels close to the conference, please visit
http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-travel.
As of March 15, 2016, non-US citizens need either a visa or an Electronic
Travel Authorization (eTA) in order to enter Canada. Detailed information
on the travel documentation required for your country of origin can
be found at http://www.cic.gc.ca/english/visit/visas.asp and
http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-travel.
** We urge you to start this process as quickly as possible to ensure
** receipt of appropriate travel documentation in time for your conference
** travel to Canada. For processing times for visa applications, please visit
** http://www.cic.gc.ca/english/information/times/.
===============
IMPORTANT DATES
===============
Notification: May 27, 2015
Schedule announced: June 3, 2015
Event dates: August 24-26, 2016
Thank you for your interest in KVM. We're looking forward to your
submissions and seeing you at the KVM Forum 2016 in August!
-your KVM Forum 2016 Program Committee
Please contact us with any questions or comments at
kvm-forum-2016-pc(a)redhat.com
8 years, 7 months
[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, 7 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, 7 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, 7 months
[libvirt] [PATCH] Removed function virDomainDefNewFull.
by Tomáš Ryšavý
The function virDomainDefNewFull() in src/conf/domain_conf.c was a thin
wrapper around virDomainDefNew() that was only used in a few places in
the code. The function was removed and the callers were re-implemented.
---
src/conf/domain_conf.c | 22 ----------------------
src/conf/domain_conf.h | 3 ---
src/libvirt_private.syms | 1 -
src/vz/vz_utils.c | 8 +++++++-
src/xen/xen_hypervisor.c | 26 ++++++++++++++++++--------
src/xen/xend_internal.c | 23 +++++++++++++++++++----
src/xen/xm_internal.c | 24 ++++++++++++++++++++++--
7 files changed, 66 insertions(+), 41 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index fb05bf7..5721800 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2754,28 +2754,6 @@ virDomainDefNew(void)
}
-virDomainDefPtr
-virDomainDefNewFull(const char *name,
- const unsigned char *uuid,
- int id)
-{
- virDomainDefPtr def;
-
- if (!(def = virDomainDefNew()))
- return NULL;
-
- if (VIR_STRDUP(def->name, name) < 0) {
- VIR_FREE(def);
- return NULL;
- }
-
- memcpy(def->uuid, uuid, VIR_UUID_BUFLEN);
- def->id = id;
-
- return def;
-}
-
-
void virDomainObjAssignDef(virDomainObjPtr domain,
virDomainDefPtr def,
bool live,
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 82e581b..afb722c 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2507,9 +2507,6 @@ void virDomainDefFree(virDomainDefPtr vm);
virDomainChrDefPtr virDomainChrDefNew(void);
virDomainDefPtr virDomainDefNew(void);
-virDomainDefPtr virDomainDefNewFull(const char *name,
- const unsigned char *uuid,
- int id);
void virDomainObjAssignDef(virDomainObjPtr domain,
virDomainDefPtr def,
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index fb5b419..1a09a95 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -234,7 +234,6 @@ virDomainDefMaybeAddController;
virDomainDefMaybeAddInput;
virDomainDefNeedsPlacementAdvice;
virDomainDefNew;
-virDomainDefNewFull;
virDomainDefParseFile;
virDomainDefParseNode;
virDomainDefParseString;
diff --git a/src/vz/vz_utils.c b/src/vz/vz_utils.c
index 5427314..0e98a39 100644
--- a/src/vz/vz_utils.c
+++ b/src/vz/vz_utils.c
@@ -166,9 +166,15 @@ vzNewDomain(vzDriverPtr driver, const char *name, const unsigned char *uuid)
virDomainObjPtr dom = NULL;
vzDomObjPtr pdom = NULL;
- if (!(def = virDomainDefNewFull(name, uuid, -1)))
+ if (!(def = virDomainDefNew()))
goto error;
+ if (VIR_STRDUP(def->name, name) < 0)
+ goto error;
+
+ memcpy(def->uuid, uuid, VIR_UUID_BUFLEN);
+ def->id = -1;
+
if (VIR_ALLOC(pdom) < 0)
goto error;
diff --git a/src/xen/xen_hypervisor.c b/src/xen/xen_hypervisor.c
index fc9e1c6..1b9d2e1 100644
--- a/src/xen/xen_hypervisor.c
+++ b/src/xen/xen_hypervisor.c
@@ -2634,10 +2634,15 @@ xenHypervisorLookupDomainByID(virConnectPtr conn, int id)
if (!name)
return NULL;
- ret = virDomainDefNewFull(name,
- XEN_GETDOMAININFO_UUID(dominfo),
- id);
- VIR_FREE(name);
+ if (!(ret = virDomainDefNew())) {
+ VIR_FREE(name);
+ return NULL;
+ }
+
+ ret->name = name;
+ memcpy(ret->uuid, XEN_GETDOMAININFO_UUID(dominfo), VIR_UUID_BUFLEN);
+ ret->id = id;
+
return ret;
}
@@ -2699,10 +2704,15 @@ xenHypervisorLookupDomainByUUID(virConnectPtr conn, const unsigned char *uuid)
if (!name)
return NULL;
- ret = virDomainDefNewFull(name, uuid, id);
- if (ret)
- ret->id = id;
- VIR_FREE(name);
+ if (!(ret = virDomainDefNew())) {
+ VIR_FREE(name);
+ return NULL;
+ }
+
+ ret->name = name;
+ memcpy(ret->uuid, uuid, VIR_UUID_BUFLEN);
+ ret->id = id;
+
return ret;
}
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 4dd6b41..2ba5459 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -1111,12 +1111,21 @@ sexpr_to_domain(virConnectPtr conn ATTRIBUTE_UNUSED, const struct sexpr *root)
if (sexpr_node(root, "domain/domid"))
id = sexpr_int(root, "domain/domid");
- return virDomainDefNewFull(name, uuid, id);
+ if (!(ret = virDomainDefNew()))
+ goto error;
+
+ if (VIR_STRDUP(ret->name, name) < 0)
+ goto error;
+
+ memcpy(def->uuid, uuid, VIR_UUID_BUFLEN);
+ def->id = id;
+
+ return ret;
error:
virReportError(VIR_ERR_INTERNAL_ERROR,
"%s", _("failed to parse Xend domain information"));
- virObjectUnref(ret);
+ virDomainDevFree(ret);
return NULL;
}
@@ -2003,9 +2012,15 @@ xenDaemonLookupByUUID(virConnectPtr conn, const unsigned char *uuid)
if (name == NULL)
return NULL;
- ret = virDomainDefNewFull(name, uuid, id);
+ if (!(ret = virDomainDefNew())) {
+ VIR_FREE(name);
+ return NULL;
+ }
+
+ ret->name = name;
+ memcpy(ret->uuid, uuid, VIR_UUID_BUFLEN);
+ ret->id = id;
- VIR_FREE(name);
return ret;
}
diff --git a/src/xen/xm_internal.c b/src/xen/xm_internal.c
index ef1a460..ca4577f 100644
--- a/src/xen/xm_internal.c
+++ b/src/xen/xm_internal.c
@@ -848,7 +848,17 @@ xenXMDomainLookupByName(virConnectPtr conn, const char *domname)
if (!(entry = virHashLookup(priv->configCache, filename)))
goto cleanup;
- ret = virDomainDefNewFull(domname, entry->def->uuid, -1);
+ if (!(ret = virDomainDefNew()))
+ goto cleanup;
+
+ if (VIR_STRDUP(ret->name, domname) < 0) {
+ virDomainDevFree(ret);
+ ret = NULL;
+ goto cleanup;
+ }
+
+ memcpy(def->uuid, entry->def->uuid, VIR_UUID_BUFLEN);
+ def->id = -1;
cleanup:
xenUnifiedUnlock(priv);
@@ -891,7 +901,17 @@ xenXMDomainLookupByUUID(virConnectPtr conn, const unsigned char *uuid)
if (!(entry = virHashSearch(priv->configCache, xenXMDomainSearchForUUID, (const void *)uuid)))
goto cleanup;
- ret = virDomainDefNewFull(entry->def->name, uuid, -1);
+ if (!(ret = virDomainDefNew()))
+ goto cleanup;
+
+ if (VIR_STRDUP(ret->name, entry->def->name) < 0) {
+ virDomainDevFree(ret);
+ ret = NULL;
+ goto cleanup;
+ }
+
+ memcpy(def->uuid, uuid, VIR_UUID_BUFLEN);
+ def->id = -1;
cleanup:
xenUnifiedUnlock(priv);
--
2.5.5
8 years, 7 months
[libvirt] [PATCH] network: restart dnsmasq after adding/removing txt and srv records
by Laine Stump
Although dns host records are stored in a separate configuration file
that is reread by dnsmasq when it receives a SIGHUP, the txt and srv
records are directly in the dnsmasq .conf file which can't be reread
after initial dnsmasq startup. This means that if an srv or txt record
is modified in a network config, libvirt needs to restart the dnsmasq
process rather than just sending a SIGHUP.
This was pointed out in a question in
https://bugzilla.redhat.com/show_bug.cgi?id=988718 , but no separate
BZ was filed.
---
src/network/bridge_driver.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 0fd2095..7c8d2cc 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -3404,9 +3404,14 @@ networkUpdate(virNetworkPtr net,
if (section == VIR_NETWORK_SECTION_BRIDGE ||
section == VIR_NETWORK_SECTION_DOMAIN ||
section == VIR_NETWORK_SECTION_IP ||
- section == VIR_NETWORK_SECTION_IP_DHCP_RANGE) {
- /* these sections all change things on the dnsmasq commandline,
- * so we need to kill and restart dnsmasq.
+ section == VIR_NETWORK_SECTION_IP_DHCP_RANGE ||
+ section == VIR_NETWORK_SECTION_DNS_TXT ||
+ section == VIR_NETWORK_SECTION_DNS_SRV) {
+ /* these sections all change things on the dnsmasq
+ * commandline (i.e. in the .conf file), so we need to
+ * kill and restart dnsmasq, because dnsmasq sets its uid
+ * to "nobody" after it starts, and is unable to re-read
+ * the conf file (owned by root, mode 600)
*/
if (networkRestartDhcpDaemon(driver, network) < 0)
goto cleanup;
@@ -3434,12 +3439,10 @@ networkUpdate(virNetworkPtr net,
goto cleanup;
}
- } else if (section == VIR_NETWORK_SECTION_DNS_HOST ||
- section == VIR_NETWORK_SECTION_DNS_TXT ||
- section == VIR_NETWORK_SECTION_DNS_SRV) {
- /* these sections only change things in config files, so we
- * can just update the config files and send SIGHUP to
- * dnsmasq.
+ } else if (section == VIR_NETWORK_SECTION_DNS_HOST) {
+ /* this section only changes data in an external file
+ * (not the .conf file) so we can just update the config
+ * files and send SIGHUP to dnsmasq.
*/
if (networkRefreshDhcpDaemon(driver, network) < 0)
goto cleanup;
--
2.5.5
8 years, 7 months
