Re: [libvirt] [PATCH v2 2/2] qemu: Use the correct vm def on cold attach
On 06/12/2018 06:06 PM, Laine Stump wrote:
> On 06/12/2018 10:32 AM, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1559867
>>
>> When attaching a device to the domain we need to be sure
>> to use the correct domain definition (vm->def or vm->newDef)
>> when calling virDomainDeviceDefParse because the post parse
>> processing algorithms that may assign an address for the
>> device will use whatever domain definition was passed in.
>>
>> Additionally, some devices (SCSI hostdev and SCSI disk) use
>> algorithms that rely on knowing what already exists of the
>> other type when generating the new device's address. Using
>> the wrong VM definition could result in duplicated addresses.
>>
>> In the case of the bz, two hostdev's with no domain address
>> provided were added to the running domain's config only.
>> However, the parsing algorithm used the live domain in
>> order to figure out the host device address resulting in
>> the same address being used and a subsequent start failing
>> due to duplicate address.
>>
>> Fix this by separating the checks/code into CONFIG and LIVE
>> processing using the correct definition for each block and
>> peforming cleanup for both options as necessary.
>
> So what happens if someone requests only LIVE for the hotplug of one
> device, and then both LIVE and CONFIG for another? Does the 2nd device
> get a different address in the running guest than it has in the
> persistent config?
>
Hmmm... good question.
For the live, then live+config case:
my test live domain has:
...
...
...
...
config domain has:
...
...
...
So, yes, different, but then again, unsupplied. We have a chicken and
egg problem I think... Still if someone added scsi_host5 to the config
afterwards it'd get unit='1'. Do we guarantee anything if someone
doesn't supply the address? The virsh man page says:
"Note: using of partial device definition XML files may lead to
unexpected results as some fields may be autogenerated and thus match
devices other than expected."
WYSIWYG.
John
>>
>> Signed-off-by: John Ferlan
>> ---
>> src/qemu/qemu_driver.c | 52
>> ++
>> 1 file changed, 23 insertions(+), 29 deletions(-)
>>
>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>> index ae8e0e898a..494141af4a 100644
>> --- a/src/qemu/qemu_driver.c
>> +++ b/src/qemu/qemu_driver.c
>> @@ -8473,7 +8473,8 @@ qemuDomainAttachDeviceLiveAndConfig(virDomainObjPtr vm,
>> {
>> virDomainDefPtr vmdef = NULL;
>> virQEMUDriverConfigPtr cfg = NULL;
>> -virDomainDeviceDefPtr dev = NULL, dev_copy = NULL;
>> +virDomainDeviceDefPtr devConf = NULL;
>> +virDomainDeviceDefPtr devLive = NULL;
>> int ret = -1;
>> virCapsPtr caps = NULL;
>> unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE |
>> @@ -8487,45 +8488,39 @@ qemuDomainAttachDeviceLiveAndConfig(virDomainObjPtr
>> vm,
>> if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
>> goto cleanup;
>>
>> -dev = dev_copy = virDomainDeviceDefParse(xml, vm->def,
>> - caps, driver->xmlopt,
>> - parse_flags);
>> -if (dev == NULL)
>> -goto cleanup;
>> -
>> -if (virDomainDeviceValidateAliasForHotplug(vm, dev, flags) < 0)
>> -goto cleanup;
>> -
>> -if (flags & VIR_DOMAIN_AFFECT_CONFIG &&
>> -flags & VIR_DOMAIN_AFFECT_LIVE) {
>> -/* If we are affecting both CONFIG and LIVE
>> - * create a deep copy of device as adding
>> - * to CONFIG takes one instance.
>> - */
>> -dev_copy = virDomainDeviceDefCopy(dev, vm->def, caps,
>> driver->xmlopt);
>> -if (!dev_copy)
>> -goto cleanup;
>> -}
>> -
>> +/* The config and live post processing address auto-generation
>> algorithms
>> + * rely on the correct vm->def or vm->newDef being passed, so call the
>> + * device parse based on which definition is in use */
>> if (flags & VIR_DOMAIN_AFFECT_CONFIG) {
>> -/* Make a copy for updated domain. */
>> vmdef = virDomainObjCopyPersistentDef(vm, caps, driver->xmlopt);
>> if (!vmdef)
>> goto cleanup;
>>
>> -if (virDomainDefCompatibleDevice(vmdef, dev, NULL) < 0)
>> +if (!(devConf = virDomainDeviceDefParse(xml, vmdef, caps,
>> +driver->xmlopt,
>> parse_flags)))
>> +goto cleanup;
>> +
>> +if (virDomainDefCompatibleDevice(vmdef, devConf, NULL) < 0)
>> goto cleanup;
>> -if ((ret = qemuDomainAttachDeviceConfig(vmdef, dev, caps,
>> +
>> +if ((ret = qemuDomainAttachDeviceConfig(vmdef, devConf, caps,
>> parse_flags,
>> driver->xmlopt)) < 0)
>> goto cleanup;
Re: [libvirt] [PATCH 01/12] virsh: Force boot emulation is only required for virDomainCreateWithFlags
On 05/09/2018 10:56 AM, Marc Hartmayer wrote:
> The force boot emulation is only required for virDomainCreateWithFlags
> as the flag VIR_DOMAIN_START_FORCE_BOOT was introduced with the commit
> 27c85260532f879be5674a4eed0811c21fd34f94 (2011). But
> virDomainCreateXMLWithFiles is newer and therefore already had support
> for VIR_DOMAIN_START_FORCE_BOOT. This means there is now no second
> call with VIR_DOMAIN_START_FORCE_BOOT removed from flags for
> virDomainCreateXMLWithFiles in case the first call
> fails. virDomainCreateXMLWithFiles was introduced with commit
> d76227bea35cc49374a94414f6d46e3493ac2a52 (2013).
>
> This patch takes this into account and simplifies the function. In
> addition, it's now easier to extend the function.
>
> Signed-off-by: Marc Hartmayer
> Reviewed-by: Boris Fiuczynski
> ---
> tools/virsh-domain.c | 52
>
> 1 file changed, 28 insertions(+), 24 deletions(-)
>
OK so I took the bait ;-)... I agree 110% what you've changed to is
easier to read; however, I think there's a subtle difference with your
changes... I'm not sure this new flow will work quite right "if" for
some reason someone passes the --force-boot flag to/for a startup that
uses CreateWithFiles, such as lxc.
> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> index 598d2fa4a4bd..7cf8373f05bc 100644
> --- a/tools/virsh-domain.c
> +++ b/tools/virsh-domain.c
> @@ -4038,40 +4038,44 @@ cmdStart(vshControl *ctl, const vshCmd *cmd)
> if (vshCommandOptBool(cmd, "force-boot"))
> flags |= VIR_DOMAIN_START_FORCE_BOOT;>
> -/* We can emulate force boot, even for older servers that reject it. */
FWIW: I see that this hunk was added by commit id 691ec08b shortly after
adding support for force_boot via commit id 27c85260.
> -if (flags & VIR_DOMAIN_START_FORCE_BOOT) {
> -if ((nfds ?
> - virDomainCreateWithFiles(dom, nfds, fds, flags) :
> - virDomainCreateWithFlags(dom, flags)) == 0)
> -goto started;
> -if (last_error->code != VIR_ERR_NO_SUPPORT &&
> -last_error->code != VIR_ERR_INVALID_ARG) {
> -vshReportError(ctl);
> -goto cleanup;
> -}
Previously if flags & VIR_DOMAIN_START_FORCE_BOOT, we'd try w/
CreateWithFiles without changing @flags.
For lxc, eventually we'd end up in lxcDomainCreateWithFiles which would
do a virCheckFlags and "fail" with VIR_ERR_INVALID_ARG because the flag
VIR_DOMAIN_START_FORCE_BOOT is not supported.
That would fall through this removed code and remove the FORCE_BOOT
flag. Then we'd again call virDomainCreateWithFiles w/ @flags adjusted
to remove VIR_DOMAIN_START_FORCE_BOOT
> -vshResetLibvirtError();
> -rc = virDomainHasManagedSaveImage(dom, 0);
> -if (rc < 0) {
> -/* No managed save image to remove */
> -vshResetLibvirtError();
> -} else if (rc > 0) {
> -if (virDomainManagedSaveRemove(dom, 0) < 0) {
> +/* Prefer older API unless we have to pass extra parameters */
> +if (nfds) {
> +rc = virDomainCreateWithFiles(dom, nfds, fds, flags);
With this new code if @flags has VIR_DOMAIN_START_FORCE_BOOT, then
there's no fallback and we fail.
> +} else if (flags) {
> +rc = virDomainCreateWithFlags(dom, flags);
> +/* We can emulate force boot, even for older servers that
> + * reject it. */
> +if (rc < 0 && flags & VIR_DOMAIN_START_FORCE_BOOT) {
> +if (last_error->code != VIR_ERR_NO_SUPPORT &&
> +last_error->code != VIR_ERR_INVALID_ARG) {
The CreateWithFlags code could "fail" w/ INVALID_ARG if some hypervisor
didn't support some flag, but even calling it again without the
FORCE_BOOT may not change the result.
This (existing, I know) code assumes the failure is from the lack of a
FORCE_BOOT flag as added via commit 691ec08b. Having commit id afb50d79
further complicate the logic especially w/r/t FORCE_BOOT (which I think
makes no sense for a container hypervisor, but then again I'm not the
expert there ;-)). Still since it's in the API and documented, it's not
like we could remove it (whether or not it was an unintentional
cut-copy-paste, change API name).
John
> vshReportError(ctl);
> goto cleanup;
> }
> +vshResetLibvirtError();
> +rc = virDomainHasManagedSaveImage(dom, 0);
> +if (rc < 0) {
> +/* No managed save image to remove */
> +vshResetLibvirtError();
> +} else if (rc > 0) {
> +if (virDomainManagedSaveRemove(dom, 0) < 0) {
> +vshReportError(ctl);
> +goto cleanup;
> +}
> +}
> +
> +/* now try it again without the force boot flag */
> +flags &= ~VIR_DOMAIN_START_FORCE_BOOT;
> +rc = virDomainCreateWithFlags(dom, flags);
>
Re: [libvirt] [PATCH v2 2/2] qemu: Use the correct vm def on cold attach
On 06/12/2018 10:32 AM, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1559867
>
> When attaching a device to the domain we need to be sure
> to use the correct domain definition (vm->def or vm->newDef)
> when calling virDomainDeviceDefParse because the post parse
> processing algorithms that may assign an address for the
> device will use whatever domain definition was passed in.
>
> Additionally, some devices (SCSI hostdev and SCSI disk) use
> algorithms that rely on knowing what already exists of the
> other type when generating the new device's address. Using
> the wrong VM definition could result in duplicated addresses.
>
> In the case of the bz, two hostdev's with no domain address
> provided were added to the running domain's config only.
> However, the parsing algorithm used the live domain in
> order to figure out the host device address resulting in
> the same address being used and a subsequent start failing
> due to duplicate address.
>
> Fix this by separating the checks/code into CONFIG and LIVE
> processing using the correct definition for each block and
> peforming cleanup for both options as necessary.
So what happens if someone requests only LIVE for the hotplug of one
device, and then both LIVE and CONFIG for another? Does the 2nd device
get a different address in the running guest than it has in the
persistent config?
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/qemu_driver.c | 52
> ++
> 1 file changed, 23 insertions(+), 29 deletions(-)
>
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index ae8e0e898a..494141af4a 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -8473,7 +8473,8 @@ qemuDomainAttachDeviceLiveAndConfig(virDomainObjPtr vm,
> {
> virDomainDefPtr vmdef = NULL;
> virQEMUDriverConfigPtr cfg = NULL;
> -virDomainDeviceDefPtr dev = NULL, dev_copy = NULL;
> +virDomainDeviceDefPtr devConf = NULL;
> +virDomainDeviceDefPtr devLive = NULL;
> int ret = -1;
> virCapsPtr caps = NULL;
> unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE |
> @@ -8487,45 +8488,39 @@ qemuDomainAttachDeviceLiveAndConfig(virDomainObjPtr
> vm,
> if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
> goto cleanup;
>
> -dev = dev_copy = virDomainDeviceDefParse(xml, vm->def,
> - caps, driver->xmlopt,
> - parse_flags);
> -if (dev == NULL)
> -goto cleanup;
> -
> -if (virDomainDeviceValidateAliasForHotplug(vm, dev, flags) < 0)
> -goto cleanup;
> -
> -if (flags & VIR_DOMAIN_AFFECT_CONFIG &&
> -flags & VIR_DOMAIN_AFFECT_LIVE) {
> -/* If we are affecting both CONFIG and LIVE
> - * create a deep copy of device as adding
> - * to CONFIG takes one instance.
> - */
> -dev_copy = virDomainDeviceDefCopy(dev, vm->def, caps,
> driver->xmlopt);
> -if (!dev_copy)
> -goto cleanup;
> -}
> -
> +/* The config and live post processing address auto-generation algorithms
> + * rely on the correct vm->def or vm->newDef being passed, so call the
> + * device parse based on which definition is in use */
> if (flags & VIR_DOMAIN_AFFECT_CONFIG) {
> -/* Make a copy for updated domain. */
> vmdef = virDomainObjCopyPersistentDef(vm, caps, driver->xmlopt);
> if (!vmdef)
> goto cleanup;
>
> -if (virDomainDefCompatibleDevice(vmdef, dev, NULL) < 0)
> +if (!(devConf = virDomainDeviceDefParse(xml, vmdef, caps,
> +driver->xmlopt,
> parse_flags)))
> +goto cleanup;
> +
> +if (virDomainDefCompatibleDevice(vmdef, devConf, NULL) < 0)
> goto cleanup;
> -if ((ret = qemuDomainAttachDeviceConfig(vmdef, dev, caps,
> +
> +if ((ret = qemuDomainAttachDeviceConfig(vmdef, devConf, caps,
> parse_flags,
> driver->xmlopt)) < 0)
> goto cleanup;
> }
>
> if (flags & VIR_DOMAIN_AFFECT_LIVE) {
> -if (virDomainDefCompatibleDevice(vm->def, dev_copy, NULL) < 0)
> +if (!(devLive = virDomainDeviceDefParse(xml, vm->def, caps,
> +driver->xmlopt,
> parse_flags)))
> goto cleanup;
>
> -if ((ret = qemuDomainAttachDeviceLive(vm, dev_copy, driver)) < 0)
> +if (virDomainDeviceValidateAliasForHotplug(vm, devLive, flags) < 0)
> +goto cleanup;
> +
> +if (virDomainDefCompatibleDevice(vm->def, devLive, NULL) < 0)
> +goto cleanup;
> +
> +if ((ret = qemuDomainAttachDeviceLive(vm, devLive, driver)) < 0)
> goto cleanup;
> /*
> * update domain status forcibly because the
Re: [libvirt] [PATCH] lib: Document limitation of virDomainInterfaceAddresses
On 06/12/2018 07:32 AM, Michal Privoznik wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1588336 > > This API takes @source argument which tells it where to get > domain IP addresses from. However, not all sources are capable of > providing all the information we report, for instance ARP table > has no notion of IP address prefixes. Document this limitation. > > Signed-off-by: Michal Privoznik Reviewed-by: Laine Stump -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] docs: formatdomain: Note the caveats for CPU policy option "force"
On Tue, Jun 12, 2018 at 10:58:46AM +0200, Kashyap Chamarthy wrote: > Eduardo Habkost has pointed out that the current documentation of > libvirt's CPU feature policy "require" vs. "force" does not match > QEMU's behaviour. > > Update the documentation by spelling out the QEMU version dependency and > explain in which scenarios the usage of "policy = 'force'" is applicable > or not. > > Signed-off-by: Kashyap Chamarthy > --- > Wordsmithing / corrections welcome. > --- > docs/formatdomain.html.in | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index 6912762f28..4d6c3892ee 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -1566,8 +1566,17 @@ > > >force > - The virtual CPU will claim the feature is supported regardless > -of it being supported by host CPU. > + The virtual CPU will claim the feature is supported > + regardless of it being supported by host CPU -- this is only > + true for QEMU version older than 2.9.0. I.e. when using the This isn't true for any QEMU versions. QEMU never enables a feature if it's not supported by the host. > + CPU mode 'host-model', libvirt identifies which CPU features > + to use by looking at host CPUID. For that to take effect, it > + is mandatory to use force to tell libvirt that a > + said CPU feature must be used despite it not existing in the > + host -- this applicable only for a very limited set of CPU > + features, such as 'x2apic', virt-ssbd' (for AMD CPUs). > + However, when using QEMU 2.9.0 and above, there should > + never be any need to use force. >require >Guest creation will fail unless the feature is supported by the > host CPU or the hypervisor is able to emulate it. > -- > 2.17.0 > -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH libvirt 4/4] events: remove umlDomainEventQueue wrapper func
And replace all calls with virObjectEventStateQueue such that:
umlDomainEventQueue(driver, event);
becomes:
virObjectEventStateQueue(driver->domainEventState, event);
And remove NULL checking from all callers.
Signed-off-by: Anya Harter
---
src/uml/uml_driver.c | 33 -
1 file changed, 8 insertions(+), 25 deletions(-)
diff --git a/src/uml/uml_driver.c b/src/uml/uml_driver.c
index 53ec64e10f..0c5b7fcda7 100644
--- a/src/uml/uml_driver.c
+++ b/src/uml/uml_driver.c
@@ -125,8 +125,6 @@ static int umlOpenMonitor(struct uml_driver *driver,
virDomainObjPtr vm);
static int umlReadPidFile(struct uml_driver *driver,
virDomainObjPtr vm);
-static void umlDomainEventQueue(struct uml_driver *driver,
-virObjectEventPtr event);
static int umlStartVMDaemon(virConnectPtr conn,
struct uml_driver *driver,
@@ -228,8 +226,7 @@ umlAutostartDomain(virDomainObjPtr vm,
virDomainEventLifecycleNewFromObj(vm,
VIR_DOMAIN_EVENT_STARTED,
VIR_DOMAIN_EVENT_STARTED_BOOTED);
-if (event)
-umlDomainEventQueue(data->driver, event);
+virObjectEventStateQueue(data->driver->domainEventState, event);
}
}
virObjectUnlock(vm);
@@ -425,10 +422,8 @@ umlInotifyEvent(int watch,
}
}
virDomainObjEndAPI();
-if (event) {
-umlDomainEventQueue(driver, event);
-event = NULL;
-}
+virObjectEventStateQueue(driver->domainEventState, event);
+event = NULL;
}
cleanup:
@@ -646,8 +641,7 @@ static void umlNotifyLoadDomain(virDomainObjPtr vm, int
newVM, void *opaque)
virDomainEventLifecycleNewFromObj(vm,
VIR_DOMAIN_EVENT_DEFINED,
VIR_DOMAIN_EVENT_DEFINED_ADDED);
-if (event)
-umlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
}
}
@@ -783,8 +777,7 @@ static int umlProcessAutoDestroyDom(void *payload,
virDomainObjListRemove(data->driver->domains, dom);
virDomainObjEndAPI();
-if (event)
-umlDomainEventQueue(data->driver, event);
+virObjectEventStateQueue(data->driver->domainEventState, event);
virHashRemoveEntry(data->driver->autodestroy, uuidstr);
return 0;
}
@@ -1615,8 +1608,7 @@ static virDomainPtr umlDomainCreateXML(virConnectPtr
conn, const char *xml,
cleanup:
virDomainDefFree(def);
virDomainObjEndAPI();
-if (event)
-umlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
umlDriverUnlock(driver);
virNWFilterUnlockFilterUpdates();
return dom;
@@ -1689,8 +1681,7 @@ umlDomainDestroyFlags(virDomainPtr dom,
cleanup:
virDomainObjEndAPI();
-if (event)
-umlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
umlDriverUnlock(driver);
return ret;
}
@@ -1949,8 +1940,7 @@ static int umlDomainCreateWithFlags(virDomainPtr dom,
unsigned int flags)
cleanup:
virDomainObjEndAPI();
-if (event)
-umlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
umlDriverUnlock(driver);
virNWFilterUnlockFilterUpdates();
return ret;
@@ -2587,13 +2577,6 @@ umlConnectDomainEventDeregisterAny(virConnectPtr conn,
}
-/* driver must be locked before calling */
-static void umlDomainEventQueue(struct uml_driver *driver,
-virObjectEventPtr event)
-{
-virObjectEventStateQueue(driver->domainEventState, event);
-}
-
static int umlConnectListAllDomains(virConnectPtr conn,
virDomainPtr **domains,
unsigned int flags)
--
2.17.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH libvirt 2/4] events: remove libxlDomainEventQueue wrapper func
And replace all calls with virObjectEventStateQueue such that:
libxlDomainEventQueue(driver, event);
becomes:
virObjectEventStateQueue(driver->domainEventState, event);
And remove NULL checking from all callers.
Signed-off-by: Anya Harter
---
src/libxl/libxl_domain.c| 24 ++--
src/libxl/libxl_domain.h| 4
src/libxl/libxl_driver.c| 21 +++--
src/libxl/libxl_migration.c | 18 ++
4 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index d12b1b1b4b..2ab78ac9a5 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -526,10 +526,8 @@ libxlDomainShutdownThread(void *opaque)
}
destroy:
-if (dom_event) {
-libxlDomainEventQueue(driver, dom_event);
-dom_event = NULL;
-}
+virObjectEventStateQueue(driver->domainEventState, dom_event);
+dom_event = NULL;
libxlDomainDestroyInternal(driver, vm);
libxlDomainCleanup(driver, vm);
if (!vm->persistent)
@@ -538,10 +536,8 @@ libxlDomainShutdownThread(void *opaque)
goto endjob;
restart:
-if (dom_event) {
-libxlDomainEventQueue(driver, dom_event);
-dom_event = NULL;
-}
+virObjectEventStateQueue(driver->domainEventState, dom_event);
+dom_event = NULL;
libxlDomainDestroyInternal(driver, vm);
libxlDomainCleanup(driver, vm);
if (libxlDomainStartNew(driver, vm, false) < 0) {
@@ -554,8 +550,7 @@ libxlDomainShutdownThread(void *opaque)
cleanup:
virDomainObjEndAPI();
-if (dom_event)
-libxlDomainEventQueue(driver, dom_event);
+virObjectEventStateQueue(driver->domainEventState, dom_event);
libxl_event_free(cfg->ctx, ev);
VIR_FREE(shutdown_info);
virObjectUnref(cfg);
@@ -616,12 +611,6 @@ libxlDomainEventHandler(void *data, VIR_LIBXL_EVENT_CONST
libxl_event *event)
VIR_FREE(shutdown_info);
}
-void
-libxlDomainEventQueue(libxlDriverPrivatePtr driver, virObjectEventPtr event)
-{
-virObjectEventStateQueue(driver->domainEventState, event);
-}
-
char *
libxlDomainManagedSavePath(libxlDriverPrivatePtr driver, virDomainObjPtr vm)
{
@@ -1394,8 +1383,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver,
restore_fd < 0 ?
VIR_DOMAIN_EVENT_STARTED_BOOTED :
VIR_DOMAIN_EVENT_STARTED_RESTORED);
-if (event)
-libxlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
ret = 0;
goto cleanup;
diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
index b5b6332151..5d83230cd6 100644
--- a/src/libxl/libxl_domain.h
+++ b/src/libxl/libxl_domain.h
@@ -95,10 +95,6 @@ int
libxlDomainJobUpdateTime(struct libxlDomainJobObj *job)
ATTRIBUTE_RETURN_CHECK;
-void
-libxlDomainEventQueue(libxlDriverPrivatePtr driver,
- virObjectEventPtr event);
-
char *
libxlDomainManagedSavePath(libxlDriverPrivatePtr driver,
virDomainObjPtr vm);
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 8c40661e5a..5a5e792957 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1179,8 +1179,7 @@ libxlDomainSuspend(virDomainPtr dom)
cleanup:
virDomainObjEndAPI();
-if (event)
-libxlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
virObjectUnref(cfg);
return ret;
}
@@ -1234,8 +1233,7 @@ libxlDomainResume(virDomainPtr dom)
cleanup:
virDomainObjEndAPI();
-if (event)
-libxlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
virObjectUnref(cfg);
return ret;
}
@@ -1394,8 +1392,7 @@ libxlDomainDestroyFlags(virDomainPtr dom,
cleanup:
virDomainObjEndAPI();
-if (event)
-libxlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
virObjectUnref(cfg);
return ret;
}
@@ -1734,8 +1731,7 @@ libxlDoDomainSave(libxlDriverPrivatePtr driver,
VIR_FREE(xml);
if (VIR_CLOSE(fd) < 0)
virReportSystemError(errno, "%s", _("cannot close file"));
-if (event)
-libxlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
virObjectUnref(cfg);
return ret;
}
@@ -1950,8 +1946,7 @@ libxlDomainCoreDump(virDomainPtr dom, const char *to,
unsigned int flags)
cleanup:
virDomainObjEndAPI();
-if (event)
-libxlDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
virObjectUnref(cfg);
return ret;
}
@@ -2755,8 +2750,7 @@ libxlDomainDefineXMLFlags(virConnectPtr conn, const char
*xml, unsigned int flag
virDomainDefFree(def);
virDomainDefFree(oldDef);
virDomainObjEndAPI();
-if
[libvirt] [PATCH libvirt 0/4] rmv virObjectEventStateQueue wrapper funcs
Currently, there are four wrapper functions which call virObjectEventStateQueue: - testObjectEventQueue - libxlDomainEventQueue - qemuDomainEventQueue - umlDomainEventQueue This patch series removes these wrappers makes all calls directly to virObjectEventStateQueue. Since virObjectEventStateQueue takes care of NULL checking, all NULL checking by callers has also been removed. This patch series should complete the BiteSizedTask entry at https://wiki.libvirt.org/page/BiteSizedTasks#Remove_NULL_checking_around_EventStateQueue . Anya Harter (4): events: remove testObjectEventQueue wrapper func events: remove libxlDomainEventQueue wrapper func events: remove qemuDomainEventQueue wrapper func events: remove umlDomainEventQueue wrapper func src/libxl/libxl_domain.c| 24 +++--- src/libxl/libxl_domain.h| 4 -- src/libxl/libxl_driver.c| 21 +++-- src/libxl/libxl_migration.c | 18 +++- src/qemu/qemu_blockjob.c| 4 +- src/qemu/qemu_cgroup.c | 2 +- src/qemu/qemu_domain.c | 11 + src/qemu/qemu_domain.h | 2 - src/qemu/qemu_driver.c | 88 + src/qemu/qemu_hotplug.c | 26 +-- src/qemu/qemu_migration.c | 24 +- src/qemu/qemu_process.c | 54 +++ src/test/test_driver.c | 80 - src/uml/uml_driver.c| 33 -- 14 files changed, 162 insertions(+), 229 deletions(-) -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH libvirt 1/4] events: remove testObjectEventQueue wrapper func
And replace all calls with virObjectEventStateQueue such that:
testObjectEventQueue(privconn, event);
becomes:
virObjectEventStateQueue(privconn->eventState, event);
Signed-off-by: Anya Harter
---
src/test/test_driver.c | 80 +++---
1 file changed, 37 insertions(+), 43 deletions(-)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index eb4e5aa341..5494d51017 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -174,12 +174,6 @@ static void testDriverUnlock(testDriverPtr driver)
virMutexUnlock(>lock);
}
-static void testObjectEventQueue(testDriverPtr driver,
- virObjectEventPtr event)
-{
-virObjectEventStateQueue(driver->eventState, event);
-}
-
#define TEST_NAMESPACE_HREF "http://libvirt.org/schemas/domain/test/1.0;
typedef struct _testDomainNamespaceDef testDomainNamespaceDef;
@@ -1692,7 +1686,7 @@ testDomainCreateXML(virConnectPtr conn, const char *xml,
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
virDomainDefFree(def);
testDriverUnlock(privconn);
return ret;
@@ -1791,7 +1785,7 @@ static int testDomainDestroyFlags(virDomainPtr domain,
ret = 0;
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -1825,7 +1819,7 @@ static int testDomainResume(virDomainPtr domain)
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -1855,7 +1849,7 @@ static int testDomainSuspend(virDomainPtr domain)
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -1890,7 +1884,7 @@ static int testDomainShutdownFlags(virDomainPtr domain,
ret = 0;
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -1958,7 +1952,7 @@ static int testDomainReboot(virDomainPtr domain,
ret = 0;
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -2102,7 +2096,7 @@ testDomainSaveFlags(virDomainPtr domain, const char *path,
unlink(path);
}
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -2205,7 +2199,7 @@ testDomainRestoreFlags(virConnectPtr conn,
VIR_FREE(xml);
VIR_FORCE_CLOSE(fd);
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -2275,7 +2269,7 @@ static int testDomainCoreDumpWithFormat(virDomainPtr
domain,
cleanup:
VIR_FORCE_CLOSE(fd);
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -2649,8 +2643,8 @@ testDomainRenameCallback(virDomainObjPtr privdom,
cleanup:
VIR_FREE(old_dom_name);
VIR_FREE(new_dom_name);
-testObjectEventQueue(driver, event_old);
-testObjectEventQueue(driver, event_new);
+virObjectEventStateQueue(driver->eventState, event_old);
+virObjectEventStateQueue(driver->eventState, event_new);
return ret;
}
@@ -2786,7 +2780,7 @@ static virDomainPtr
testDomainDefineXMLFlags(virConnectPtr conn,
virDomainDefFree(def);
virDomainDefFree(oldDef);
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -2840,7 +2834,7 @@ static int testDomainSetMetadata(virDomainPtr dom,
if (ret == 0) {
virObjectEventPtr ev = NULL;
ev = virDomainEventMetadataChangeNewFromObj(privdom, type, uri);
-testObjectEventQueue(privconn, ev);
+virObjectEventStateQueue(privconn->eventState, ev);
}
virDomainObjEndAPI();
@@ -2995,7 +2989,7 @@ static int testDomainCreateWithFlags(virDomainPtr domain,
unsigned int flags)
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
testDriverUnlock(privconn);
return ret;
}
@@ -3061,7 +3055,7 @@ static int testDomainUndefineFlags(virDomainPtr domain,
cleanup:
virDomainObjEndAPI();
-testObjectEventQueue(privconn, event);
+virObjectEventStateQueue(privconn->eventState, event);
return ret;
}
@@ -3486,7 +3480,7 @@ testNetworkCreateXML(virConnectPtr conn, const char *xml)
cleanup:
virNetworkDefFree(newDef);
-testObjectEventQueue(privconn, event);
+
[libvirt] [PATCH libvirt 3/4] events: remove qemuDomainEventQueue wrapper func
And replace all calls with virObjectEventStateQueue such that:
qemuDomainEventQueue(driver, event);
becomes:
virObjectEventStateQueue(driver->domainEventState, event);
And remove NULL checking from all callers.
Signed-off-by: Anya Harter
---
src/qemu/qemu_blockjob.c | 4 +-
src/qemu/qemu_cgroup.c| 2 +-
src/qemu/qemu_domain.c| 11 +
src/qemu/qemu_domain.h| 2 -
src/qemu/qemu_driver.c| 88 ++-
src/qemu/qemu_hotplug.c | 26 ++--
src/qemu/qemu_migration.c | 24 +--
src/qemu/qemu_process.c | 54
8 files changed, 98 insertions(+), 113 deletions(-)
diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c
index e0dfb88c1c..b08e047490 100644
--- a/src/qemu/qemu_blockjob.c
+++ b/src/qemu/qemu_blockjob.c
@@ -210,8 +210,8 @@ qemuBlockJobEventProcess(virQEMUDriverPtr driver,
"after block job", vm->def->name);
}
-qemuDomainEventQueue(driver, event);
-qemuDomainEventQueue(driver, event2);
+virObjectEventStateQueue(driver->domainEventState, event);
+virObjectEventStateQueue(driver->domainEventState, event2);
virObjectUnref(cfg);
}
diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
index 43c5ae8f8e..c8fba7f9e6 100644
--- a/src/qemu/qemu_cgroup.c
+++ b/src/qemu/qemu_cgroup.c
@@ -896,7 +896,7 @@ qemuSetupCpuCgroup(virDomainObjPtr vm)
event = virDomainEventTunableNewFromObj(vm, eventParams,
eventNparams);
}
-qemuDomainEventQueue(priv->driver, event);
+virObjectEventStateQueue(priv->driver->domainEventState, event);
}
return 0;
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 756e938858..2119233907 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -256,13 +256,6 @@ qemuDomainDisableNamespace(virDomainObjPtr vm,
}
-void qemuDomainEventQueue(virQEMUDriverPtr driver,
- virObjectEventPtr event)
-{
-virObjectEventStateQueue(driver->domainEventState, event);
-}
-
-
void
qemuDomainEventEmitJobCompleted(virQEMUDriverPtr driver,
virDomainObjPtr vm)
@@ -283,7 +276,7 @@ qemuDomainEventEmitJobCompleted(virQEMUDriverPtr driver,
}
event = virDomainEventJobCompletedNewFromObj(vm, params, nparams);
-qemuDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
}
@@ -7872,7 +7865,7 @@ qemuDomainCheckRemoveOptionalDisk(virQEMUDriverPtr driver,
virDomainDiskDefFree(disk);
}
-qemuDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
}
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index f17157b951..fd8d9b5305 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -493,8 +493,6 @@ int qemuDomainAsyncJobPhaseFromString(qemuDomainAsyncJob
job,
void qemuDomainEventFlush(int timer, void *opaque);
-void qemuDomainEventQueue(virQEMUDriverPtr driver,
- virObjectEventPtr event);
void qemuDomainEventEmitJobCompleted(virQEMUDriverPtr driver,
virDomainObjPtr vm);
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index f0fb806fcd..7c79c324e6 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -975,7 +975,7 @@ static void qemuNotifyLoadDomain(virDomainObjPtr vm, int
newVM, void *opaque)
virDomainEventLifecycleNewFromObj(vm,
VIR_DOMAIN_EVENT_DEFINED,
VIR_DOMAIN_EVENT_DEFINED_ADDED);
-qemuDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
}
}
@@ -1806,10 +1806,8 @@ static virDomainPtr qemuDomainCreateXML(virConnectPtr
conn,
cleanup:
virDomainDefFree(def);
virDomainObjEndAPI();
-if (event) {
-qemuDomainEventQueue(driver, event);
-qemuDomainEventQueue(driver, event2);
-}
+virObjectEventStateQueue(driver->domainEventState, event);
+virObjectEventStateQueue(driver->domainEventState, event2);
virObjectUnref(caps);
virNWFilterUnlockFilterUpdates();
return dom;
@@ -1879,7 +1877,7 @@ static int qemuDomainSuspend(virDomainPtr dom)
cleanup:
virDomainObjEndAPI();
-qemuDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
virObjectUnref(cfg);
return ret;
}
@@ -1942,7 +1940,7 @@ static int qemuDomainResume(virDomainPtr dom)
cleanup:
virDomainObjEndAPI();
-qemuDomainEventQueue(driver, event);
+virObjectEventStateQueue(driver->domainEventState, event);
virObjectUnref(cfg);
return ret;
}
@@ -2250,7 +2248,7 @@ qemuDomainDestroyFlags(virDomainPtr dom,
cleanup:
virDomainObjEndAPI();
-qemuDomainEventQueue(driver, event);
+
Re: [libvirt] [PATCH v2 05/21] conf: add support for parsing/formatting virNWFilterBindingDefPtr
On Thu, May 17, 2018 at 05:55:39PM -0400, John Ferlan wrote: > > > On 05/17/2018 01:37 PM, Daniel P. Berrangé wrote: > > On Thu, May 17, 2018 at 01:31:04PM -0400, Laine Stump wrote: > >> On 05/15/2018 01:43 PM, Daniel P. Berrangé wrote: > >>> A typical XML representation of the virNWFilterBindingDefPtr struct > >>> looks like this: > >>> > >>> > >>> > >>> f25arm7 > >>> 12ac8b8c-4f23-4248-ae42-fdcd50c400fd > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> I haven't had time to look at this in detail yet, or to really think > >> about the comment I'm going to make, but I wanted to be sure I said it > >> right away in case there are any public API implications > >> > >> > >> By now we all know the horror by which OpenStack's networking creates a > >> separate bridge device, and connects the guest's tap device to that > >> bridge so that (in addition to other reasons) there is a place for > >> libvirt's nwfilter rules to attach (what they *really* want to connect > >> to is an Open vSwitch, but ipfilter rules aren't in the data path when a > >> tap device is connected to OVS). This atrocity could be avoided if > >> nwfilter supported OVN (OVS's ipfilter analog) directly. In order to > >> support it though, nwfilter would need to know more details about the > >> network device that it's adding rules for. (because some guests may be > >> connected to OVS and others may be connected to a standard host bridge > >> (or nothing at all) we can't just have a system-wide config to decide). > >> > >> I can't recall if there is a reasonable API to figure out what a tap > >> device is connected to, but I think such a thing may not exist and, if > >> so, we'll likely need to send some sort of indicator in the > >> NWFilterBinding XML. It *might* be simpler / more futureproof if we > >> included the element that is already in the domain XML > >> information - that's currently what we use to decide how to > >> connect the tap device; hopefully in the future it will continue to > >> conain everything that's needed (if we think that's inadequate, we could > >> just go for broke and include the entire , but that's > >> probably overkill. (although. - thinking about the potential case > >> where some SRIOV network card supported some sort of filtering, if we > >> sent the entire , we would know that it was a hostdev...) > >> > >> I started typing this wondering if the C API might need any change, but > >> now that I've typed this, I realize it would only require additions to > >> the XML, which can always be done later, so > > > > Yes, that's exactly why I ended up using XML for this - originally I > > had just used virTypedParameters but felt XML would give us better > > future proofing. Esstentially any part of the domain XML > > that is related to the /backend/ of the device is fair game for us > > to include in the filterbinding XML. I just started with the minimal > > set of data, rather than try to wire up everything, so it is simpler. > > > > So in the future , will the possibly have a "type" > attribute? Should we go there now or just leave it for the future? I didn't want to add 'type' to this, as we don't neccessarily care about the device type. eg we might add a "type" that specifies the firewall engine type instead. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] conf: Forbid device alias change on device-update
https://bugzilla.redhat.com/show_bug.cgi?id=1585108
When updating a live device users might pass different alias than
the one the device has. Currently, this is silently ignored which
goes against our behaviour for other parts of the device where we
explicitly allow only certain changes and error out loudly on
anything else.
Signed-off-by: Michal Privoznik
---
src/conf/domain_conf.c | 12 +++-
src/conf/domain_conf.h | 3 ++-
src/lxc/lxc_driver.c | 6 +++---
src/qemu/qemu_driver.c | 16
4 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 85f07af46e..91cac75c0a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -28195,7 +28195,8 @@ virDomainDeviceInfoCheckBootIndex(virDomainDefPtr def
ATTRIBUTE_UNUSED,
int
virDomainDefCompatibleDevice(virDomainDefPtr def,
virDomainDeviceDefPtr dev,
- virDomainDeviceDefPtr oldDev)
+ virDomainDeviceDefPtr oldDev,
+ bool live)
{
virDomainCompatibleDeviceData data = {
.newInfo = virDomainDeviceGetInfo(dev),
@@ -28205,6 +28206,15 @@ virDomainDefCompatibleDevice(virDomainDefPtr def,
if (oldDev)
data.oldInfo = virDomainDeviceGetInfo(oldDev);
+if (live &&
+((!!data.newInfo != !!data.oldInfo) ||
+ (data.newInfo && data.oldInfo &&
+ STRNEQ(data.newInfo->alias, data.oldInfo->alias {
+virReportError(VIR_ERR_OPERATION_DENIED, "%s",
+ _("changing device alias is not allowed"));
+return -1;
+}
+
if (!virDomainDefHasUSB(def) &&
def->os.type != VIR_DOMAIN_OSTYPE_EXE &&
virDomainDeviceIsUSB(dev)) {
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index ea8ddb2b39..c03028efb9 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -3107,7 +3107,8 @@ typedef enum {
int virDomainDefCompatibleDevice(virDomainDefPtr def,
virDomainDeviceDefPtr dev,
- virDomainDeviceDefPtr oldDev);
+ virDomainDeviceDefPtr oldDev,
+ bool live);
void virDomainRNGDefFree(virDomainRNGDefPtr def);
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
index cfb431488d..fb7c8135e0 100644
--- a/src/lxc/lxc_driver.c
+++ b/src/lxc/lxc_driver.c
@@ -3549,7 +3549,7 @@ lxcDomainUpdateDeviceConfig(virDomainDefPtr vmdef,
goto cleanup;
oldDev.data.net = vmdef->nets[idx];
-if (virDomainDefCompatibleDevice(vmdef, dev, ) < 0)
+if (virDomainDefCompatibleDevice(vmdef, dev, , false) < 0)
return -1;
virDomainNetDefFree(vmdef->nets[idx]);
@@ -4785,7 +4785,7 @@ static int lxcDomainAttachDeviceFlags(virDomainPtr dom,
if (!vmdef)
goto endjob;
-if (virDomainDefCompatibleDevice(vmdef, dev, NULL) < 0)
+if (virDomainDefCompatibleDevice(vmdef, dev, NULL, false) < 0)
goto endjob;
if ((ret = lxcDomainAttachDeviceConfig(vmdef, dev)) < 0)
@@ -4793,7 +4793,7 @@ static int lxcDomainAttachDeviceFlags(virDomainPtr dom,
}
if (flags & VIR_DOMAIN_AFFECT_LIVE) {
-if (virDomainDefCompatibleDevice(vm->def, dev_copy, NULL) < 0)
+if (virDomainDefCompatibleDevice(vm->def, dev_copy, NULL, true) < 0)
goto endjob;
if ((ret = lxcDomainAttachDeviceLive(dom->conn, driver, vm, dev_copy))
< 0)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ab5cc6ea31..2d4e777b47 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7860,7 +7860,7 @@ qemuDomainChangeDiskLive(virDomainObjPtr vm,
}
oldDev.data.disk = orig_disk;
-if (virDomainDefCompatibleDevice(vm->def, dev, ) < 0)
+if (virDomainDefCompatibleDevice(vm->def, dev, , true) < 0)
goto cleanup;
if (!qemuDomainDiskChangeSupported(disk, orig_disk))
@@ -7918,7 +7918,7 @@ qemuDomainUpdateDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_GRAPHICS:
if ((idx = qemuDomainFindGraphicsIndex(vm->def, dev->data.graphics))
>= 0) {
oldDev.data.graphics = vm->def->graphics[idx];
-if (virDomainDefCompatibleDevice(vm->def, dev, ) < 0)
+if (virDomainDefCompatibleDevice(vm->def, dev, , true) < 0)
return -1;
}
@@ -7928,7 +7928,7 @@ qemuDomainUpdateDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_NET:
if ((idx = virDomainNetFindIdx(vm->def, dev->data.net)) >= 0) {
oldDev.data.net = vm->def->nets[idx];
-if (virDomainDefCompatibleDevice(vm->def, dev, ) < 0)
+if (virDomainDefCompatibleDevice(vm->def, dev, , true) < 0)
return -1;
}
@@ -8383,7 +8383,7 @@ qemuDomainUpdateDeviceConfig(virDomainDefPtr vmdef,
}
[libvirt] [PATCH 1/2] qemuDomainUpdateDeviceFlags: Parse device as live if needed
When updating device it's worth parsing live info too as users
might want to update it as well.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_driver.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index f0fb806fcd..ab5cc6ea31 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -8608,7 +8608,7 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
int ret = -1;
virQEMUDriverConfigPtr cfg = NULL;
virCapsPtr caps = NULL;
-unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE;
+unsigned int parse_flags = 0;
virCheckFlags(VIR_DOMAIN_AFFECT_LIVE |
VIR_DOMAIN_AFFECT_CONFIG |
@@ -8630,15 +8630,19 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0)
goto cleanup;
+if (virDomainObjUpdateModificationImpact(vm, ) < 0)
+goto endjob;
+
+if ((flags & VIR_DOMAIN_AFFECT_CONFIG) &&
+!(flags & VIR_DOMAIN_AFFECT_LIVE))
+parse_flags |= VIR_DOMAIN_DEF_PARSE_INACTIVE;
+
dev = dev_copy = virDomainDeviceDefParse(xml, vm->def,
caps, driver->xmlopt,
parse_flags);
if (dev == NULL)
goto endjob;
-if (virDomainObjUpdateModificationImpact(vm, ) < 0)
-goto endjob;
-
if (flags & VIR_DOMAIN_AFFECT_CONFIG &&
flags & VIR_DOMAIN_AFFECT_LIVE) {
/* If we are affecting both CONFIG and LIVE
--
2.16.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] Deny live device alias change
*** BLURB HERE *** Michal Privoznik (2): qemuDomainUpdateDeviceFlags: Parse device as live if needed conf: Forbid device alias change on device-update src/conf/domain_conf.c | 12 +++- src/conf/domain_conf.h | 3 ++- src/lxc/lxc_driver.c | 6 +++--- src/qemu/qemu_driver.c | 28 4 files changed, 32 insertions(+), 17 deletions(-) -- 2.16.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libvirtd: Add service dependency on systemd-logind
On Tue, 2018-06-12 at 09:47 -0400, Cole Robinson wrote: > At daemon startup we query logind for host PM support status. Without > a service dependency host startup can trigger libvirtd errors like: > > error : virNodeSuspendSupportsTarget:336 : internal error: Cannot probe for > supported suspend types > warning : virQEMUCapsInit:949 : Failed to get host power management > capabilities > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1588288 Please leave a blank line here. Some people would argue the Resolves: prefix is pointless and/or harmful, so consider dropping it. Or, you know, don't :) > Signed-off-by: Cole Robinson > --- > src/remote/libvirtd.service.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in > index 769702ea75..7f689e08a8 100644 > --- a/src/remote/libvirtd.service.in > +++ b/src/remote/libvirtd.service.in > @@ -15,6 +15,7 @@ After=iscsid.service > After=apparmor.service > After=local-fs.target > After=remote-fs.target > +After=systemd-logind.service > After=systemd-machined.service > Documentation=man:libvirtd(8) > Documentation=https://libvirt.org Reviewed-by: Andrea Bolognani -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH libvirt 3/3] events: remove remoteEventQueue wrapper function
On 06/11/2018 03:38 PM, Anya Harter wrote:
>>From remote_driver.c
>
> And replace all calls with virObjectEventStateQueue such that:
>
> remoteEventQueue(priv, event, callbackID);
>
> becomes:
>
> virObjectEventStateQueue(priv->eventState, event, callbackID);
Just a quick edit...
The last line of the commit message should read:
virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
>
> Signed-off-by: Anya Harter
> ---
> src/remote/remote_driver.c | 74 +-
> 1 file changed, 33 insertions(+), 41 deletions(-)
>
> diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
> index fbec5c727b..c36941c27e 100644
> --- a/src/remote/remote_driver.c
> +++ b/src/remote/remote_driver.c
> @@ -4431,14 +4431,6 @@ remoteConnectDomainEventDeregister(virConnectPtr conn,
> }
>
>
> -static void
> -remoteEventQueue(struct private_data *priv, virObjectEventPtr event,
> - int remoteID)
> -{
> -virObjectEventStateQueueRemote(priv->eventState, event, remoteID);
> -}
> -
> -
> static void
> remoteDomainBuildEventLifecycleHelper(virConnectPtr conn,
>remote_domain_event_lifecycle_msg *msg,
> @@ -4455,7 +4447,7 @@ remoteDomainBuildEventLifecycleHelper(virConnectPtr
> conn,
> event = virDomainEventLifecycleNewFromDom(dom, msg->event, msg->detail);
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventLifecycle(virNetClientProgramPtr prog ATTRIBUTE_UNUSED,
> @@ -4493,7 +4485,7 @@ remoteDomainBuildEventRebootHelper(virConnectPtr conn,
> event = virDomainEventRebootNewFromDom(dom);
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventReboot(virNetClientProgramPtr prog ATTRIBUTE_UNUSED,
> @@ -4530,7 +4522,7 @@ remoteDomainBuildEventRTCChangeHelper(virConnectPtr
> conn,
> event = virDomainEventRTCChangeNewFromDom(dom, msg->offset);
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventRTCChange(virNetClientProgramPtr prog ATTRIBUTE_UNUSED,
> @@ -4567,7 +4559,7 @@ remoteDomainBuildEventWatchdogHelper(virConnectPtr conn,
> event = virDomainEventWatchdogNewFromDom(dom, msg->action);
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventWatchdog(virNetClientProgramPtr prog ATTRIBUTE_UNUSED,
> @@ -4607,7 +4599,7 @@ remoteDomainBuildEventIOErrorHelper(virConnectPtr conn,
> msg->action);
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventIOError(virNetClientProgramPtr prog ATTRIBUTE_UNUSED,
> @@ -4649,7 +4641,7 @@ remoteDomainBuildEventIOErrorReasonHelper(virConnectPtr
> conn,
>
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventIOErrorReason(virNetClientProgramPtr prog
> ATTRIBUTE_UNUSED,
> @@ -4688,7 +4680,7 @@ remoteDomainBuildEventBlockJobHelper(virConnectPtr conn,
>
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventBlockJob(virNetClientProgramPtr prog ATTRIBUTE_UNUSED,
> @@ -4728,7 +4720,7 @@ remoteDomainBuildEventBlockJob2(virNetClientProgramPtr
> prog ATTRIBUTE_UNUSED,
>
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, msg->callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, msg->callbackID);
> }
>
> static void
> @@ -4782,7 +4774,7 @@ remoteDomainBuildEventGraphicsHelper(virConnectPtr conn,
>
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> return;
>
> error:
> @@ -4843,7 +4835,7 @@ remoteDomainBuildEventControlErrorHelper(virConnectPtr
> conn,
>
> virObjectUnref(dom);
>
> -remoteEventQueue(priv, event, callbackID);
> +virObjectEventStateQueueRemote(priv->eventState, event, callbackID);
> }
> static void
> remoteDomainBuildEventControlError(virNetClientProgramPtr prog
> ATTRIBUTE_UNUSED,
> @@ -4886,7 +4878,7 @@ remoteDomainBuildEventDiskChangeHelper(virConnectPtr
> conn,
>
>
Re: [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"
On Tue, Jun 12, 2018 at 04:16:53PM +0200, Jiri Denemark wrote: > On Tue, Jun 12, 2018 at 07:57:40 -0500, Eric Blake wrote: > > On 06/12/2018 06:11 AM, Jiri Denemark wrote: > > > > > I hit the same race twice on aarch64 and ppc64 and I can confirm the > > > installation phase fails if libvirt.la is installed later than libraries > > > which link to it. However, the dependencies seem to be set correctly in > > > the Makefiles. But it looks like they are only honored when linking the > > > library during the build phase. During make install libvirt.la and > > > libraries which link to it are installed independently. That is, > > > install-modLTLIBRARIES does not depend on anything except for the > > > mod_LTIBRARIES themselves. Thus when libtool decides to relink the > > > libraries libvirt.la may still be missing at this point. Manually > > > changing > > > > > > install-modLTLIBRARIES: $(mod_LTLIBRARIES) > > > > > > to > > > > > > install-modLTLIBRARIES: $(mod_LTLIBRARIES) install-libLTLIBRARIES > > > > > > fixed the problem for me (tested with an artificial delay added to > > > install-libLTLIBRARIES target), but I have no idea how to persuade > > > automake to generate something like that for us. > > > > > > Eric, is my investigation correct and do you have any ideas on how to > > > fix the race? > > > > Can you add that line directly into Makefile.am, or does doing that > > cause automake to complain and/or omit its normal rules because it > > thinks you are overriding its defaults? > > Yeah. It doesn't complain, but it omits its normal > install-modLTLIBRARIES rule which mean nothing will be installed. > However, the error is still reported so there are other libraries which > are not in mod_LTLIBRARIES affected too. What I find strange is that automake has chosen to wire up install-modLTLIBRARIES to the install-data-am target, instead of the install-exec-am target. mod_LTLIBRARIES = moddir = $(libdir)/libvirt/connection-driver ... mod_LTLIBRARIES += libvirt_driver_lxc.la I would have expected the _LTLIBRARIES suffix to cause it to be wired into the install-exec-am target > > I also tried adding install-modLTLIBRARIES-local target, but it didn't > work either since automake doesn't use this target (well I didn't really > hope it would work, but I tried it anyway). > > It's not really surprising bisecting found the following commit which > introduced the race, but I'm not really sure how to fix it. Isn't this a > bug in automake? :-) The attractive big hammer solution is to stop using libtool entirely and create shared libraries directly with gcc -shared, thus getting rid of the stupid shell wrapper scripts & relinking that libtool does > > commit 21639744f6371db0bfa1bd0d21fe5c51c6d6878a > Author: Daniel P. Berrangé > Date: Thu Jan 25 09:35:56 2018 + > > build: explicitly link all modules with libvirt.so > > The dlopened modules we currently build all use various symbols from > libvirt.so, but don't actually link to it. They rely on the libvirtd > daemon re-exporting the libvirt.so symbols. This means that at the > time the modules are linked, they contain a huge number of undefined > symbols. It also means that these undefined symbols are not versioned, > so despite us providing a LIBVIRT_PRIVATE_ version that > intentionally changes on every release, the loadable modules could > actually be loaded into any libvirtd regardless of version. > > This change explicitly links all modules against libvirt.so so > that they don't rely on the re-export behave and can be fully resolved > at build time. This will give us a stronger guarantee modules will > actually be loadable at runtime and that we're using modules from the > matched build. > > Signed-off-by: Daniel P. Berrange Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 1/2] qemu: Check for existing hostdev address for cold attach device
Add a check during qemuDomainAttachDeviceConfig whether the
new/incoming device would have an existing
already and if so fail the attach. This can happen
if two hostdev's are added supplying the same address or
if the new hostdev address could possibly be a duplicate
of an existing SCSI .
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index f0fb806fcd..ae8e0e898a 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -8015,6 +8015,12 @@ qemuDomainAttachDeviceConfig(virDomainDefPtr vmdef,
_("device is already in the domain configuration"));
return -1;
}
+if (dev->data.hostdev->info->type !=
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE &&
+virDomainDefHasDeviceAddress(vmdef, dev->data.hostdev->info)) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("a device with the same address already exists
"));
+return -1;
+}
if (virDomainHostdevInsert(vmdef, hostdev))
return -1;
dev->data.hostdev = NULL;
--
2.14.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 2/2] qemu: Use the correct vm def on cold attach
https://bugzilla.redhat.com/show_bug.cgi?id=1559867
When attaching a device to the domain we need to be sure
to use the correct domain definition (vm->def or vm->newDef)
when calling virDomainDeviceDefParse because the post parse
processing algorithms that may assign an address for the
device will use whatever domain definition was passed in.
Additionally, some devices (SCSI hostdev and SCSI disk) use
algorithms that rely on knowing what already exists of the
other type when generating the new device's address. Using
the wrong VM definition could result in duplicated addresses.
In the case of the bz, two hostdev's with no domain address
provided were added to the running domain's config only.
However, the parsing algorithm used the live domain in
order to figure out the host device address resulting in
the same address being used and a subsequent start failing
due to duplicate address.
Fix this by separating the checks/code into CONFIG and LIVE
processing using the correct definition for each block and
peforming cleanup for both options as necessary.
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 52 ++
1 file changed, 23 insertions(+), 29 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ae8e0e898a..494141af4a 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -8473,7 +8473,8 @@ qemuDomainAttachDeviceLiveAndConfig(virDomainObjPtr vm,
{
virDomainDefPtr vmdef = NULL;
virQEMUDriverConfigPtr cfg = NULL;
-virDomainDeviceDefPtr dev = NULL, dev_copy = NULL;
+virDomainDeviceDefPtr devConf = NULL;
+virDomainDeviceDefPtr devLive = NULL;
int ret = -1;
virCapsPtr caps = NULL;
unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE |
@@ -8487,45 +8488,39 @@ qemuDomainAttachDeviceLiveAndConfig(virDomainObjPtr vm,
if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
goto cleanup;
-dev = dev_copy = virDomainDeviceDefParse(xml, vm->def,
- caps, driver->xmlopt,
- parse_flags);
-if (dev == NULL)
-goto cleanup;
-
-if (virDomainDeviceValidateAliasForHotplug(vm, dev, flags) < 0)
-goto cleanup;
-
-if (flags & VIR_DOMAIN_AFFECT_CONFIG &&
-flags & VIR_DOMAIN_AFFECT_LIVE) {
-/* If we are affecting both CONFIG and LIVE
- * create a deep copy of device as adding
- * to CONFIG takes one instance.
- */
-dev_copy = virDomainDeviceDefCopy(dev, vm->def, caps, driver->xmlopt);
-if (!dev_copy)
-goto cleanup;
-}
-
+/* The config and live post processing address auto-generation algorithms
+ * rely on the correct vm->def or vm->newDef being passed, so call the
+ * device parse based on which definition is in use */
if (flags & VIR_DOMAIN_AFFECT_CONFIG) {
-/* Make a copy for updated domain. */
vmdef = virDomainObjCopyPersistentDef(vm, caps, driver->xmlopt);
if (!vmdef)
goto cleanup;
-if (virDomainDefCompatibleDevice(vmdef, dev, NULL) < 0)
+if (!(devConf = virDomainDeviceDefParse(xml, vmdef, caps,
+driver->xmlopt, parse_flags)))
+goto cleanup;
+
+if (virDomainDefCompatibleDevice(vmdef, devConf, NULL) < 0)
goto cleanup;
-if ((ret = qemuDomainAttachDeviceConfig(vmdef, dev, caps,
+
+if ((ret = qemuDomainAttachDeviceConfig(vmdef, devConf, caps,
parse_flags,
driver->xmlopt)) < 0)
goto cleanup;
}
if (flags & VIR_DOMAIN_AFFECT_LIVE) {
-if (virDomainDefCompatibleDevice(vm->def, dev_copy, NULL) < 0)
+if (!(devLive = virDomainDeviceDefParse(xml, vm->def, caps,
+driver->xmlopt, parse_flags)))
goto cleanup;
-if ((ret = qemuDomainAttachDeviceLive(vm, dev_copy, driver)) < 0)
+if (virDomainDeviceValidateAliasForHotplug(vm, devLive, flags) < 0)
+goto cleanup;
+
+if (virDomainDefCompatibleDevice(vm->def, devLive, NULL) < 0)
+goto cleanup;
+
+if ((ret = qemuDomainAttachDeviceLive(vm, devLive, driver)) < 0)
goto cleanup;
/*
* update domain status forcibly because the domain status may be
@@ -8549,9 +8544,8 @@ qemuDomainAttachDeviceLiveAndConfig(virDomainObjPtr vm,
cleanup:
virDomainDefFree(vmdef);
-if (dev != dev_copy)
-virDomainDeviceDefFree(dev_copy);
-virDomainDeviceDefFree(dev);
+virDomainDeviceDefFree(devConf);
+virDomainDeviceDefFree(devLive);
virObjectUnref(cfg);
virObjectUnref(caps);
--
2.14.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 0/2] Alter qemu live/cold device attach algorithm
v1: https://www.redhat.com/archives/libvir-list/2018-June/msg00465.html The first patch is essentially a repeat of the v1 patch, but with a more correct commit message. During testing if the same address was supplied for the --config it wasn't checked. The second patch rearranges qemuDomainAttachDeviceLiveAndConfig to perform CONFIG and LIVE actions separately since the generated @devConf or @devLive could be different depending on whether the incoming XML has an or not and whether the corresponding domain parse and post parse algorithms need to generate some sort of address for the device. John Ferlan (2): qemu: Check for existing hostdev address for cold attach device qemu: Use the correct vm def on cold attach src/qemu/qemu_driver.c | 58 +- 1 file changed, 29 insertions(+), 29 deletions(-) -- 2.14.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-python PATCH 1/2] Add support for virDomainGetLaunchSecurityInfo
Libvirt recently introduced support for getting launch security
parameters, most notably AMD SEV VM memory measurement. This API can't
be generated as it's using typed parameters which we need to allocate.
Signed-off-by: Erik Skultety
---
generator.py | 1 +
libvirt-override-api.xml | 6 ++
libvirt-override.c | 39 +++
3 files changed, 46 insertions(+)
diff --git a/generator.py b/generator.py
index b7d96a1..643d1b4 100755
--- a/generator.py
+++ b/generator.py
@@ -489,6 +489,7 @@ skip_impl = (
'virDomainSetPerfEvents',
'virDomainGetGuestVcpus',
'virConnectBaselineHypervisorCPU',
+'virDomainGetLaunchSecurityInfo',
)
lxc_skip_impl = (
diff --git a/libvirt-override-api.xml b/libvirt-override-api.xml
index 36d3577..7137237 100644
--- a/libvirt-override-api.xml
+++ b/libvirt-override-api.xml
@@ -728,5 +728,11 @@
+
+ Get launch security info for a domain
+
+
+
+
diff --git a/libvirt-override.c b/libvirt-override.c
index 2f2c4ff..5de8693 100644
--- a/libvirt-override.c
+++ b/libvirt-override.c
@@ -9763,6 +9763,42 @@ libvirt_virConnectBaselineHypervisorCPU(PyObject *self
ATTRIBUTE_UNUSED,
#endif /* LIBVIR_CHECK_VERSION(4, 4, 0) */
+#if LIBVIR_CHECK_VERSION(4, 5, 0)
+static PyObject *
+libvirt_virDomainGetLaunchSecurityInfo(PyObject *self ATTRIBUTE_UNUSED,
+ PyObject *args)
+{
+PyObject *pyobj_dom = NULL;
+PyObject *ret = NULL;
+
+virDomainPtr dom = NULL;
+virTypedParameterPtr params = NULL;
+int nparams = 0;
+unsigned int flags = 0;
+int i_retval;
+
+if (!PyArg_ParseTuple(args, (char *)"OI:virDomainGetLaunchSecurityInfo",
+ _dom, ))
+return NULL;
+dom = (virDomainPtr) PyvirDomain_Get(pyobj_dom);
+
+LIBVIRT_BEGIN_ALLOW_THREADS;
+i_retval = virDomainGetLaunchSecurityInfo(dom, params, nparams, flags);
+LIBVIRT_END_ALLOW_THREADS;
+
+if (i_retval < 0) {
+ret = VIR_PY_NONE;
+goto cleanup;
+}
+
+ret = getPyVirTypedParameter(params, nparams);
+ cleanup:
+virTypedParamsFree(params, nparams);
+return ret;
+}
+#endif /* LIBVIR_CHECK_VERSION(4, 5, 0) */
+
+
/
* *
* The registration stuff *
@@ -,6 +10035,9 @@ static PyMethodDef libvirtMethods[] = {
#if LIBVIR_CHECK_VERSION(4, 4, 0)
{(char *) "virConnectBaselineHypervisorCPU",
libvirt_virConnectBaselineHypervisorCPU, METH_VARARGS, NULL},
#endif /* LIBVIR_CHECK_VERSION(4, 4, 0) */
+#if LIBVIR_CHECK_VERSION(4, 5, 0)
+{(char *) "virDomainGetLaunchSecurityInfo",
libvirt_virDomainGetLaunchSecurityInfo, METH_VARARGS, NULL},
+#endif /* LIBVIR_CHECK_VERSION(4, 5, 0) */
{NULL, NULL, 0, NULL}
};
--
2.14.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-python PATCH 0/2] Provide coverage for the AMD SEV APIs
Add support for the recently introduced AMD SEV APIs Erik Skultety (2): Add support for virDomainGetLaunchSecurityInfo Add support for virNodeGetSEVInfo generator.py | 2 ++ libvirt-override-api.xml | 12 libvirt-override.c | 73 3 files changed, 87 insertions(+) -- 2.14.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-python PATCH 2/2] Add support for virNodeGetSEVInfo
This binding allows to query the AMD's SEV firmware for various platform
specific things, like a PDH certificate and a certificate chain to
establish a trusted connection with the firmware. Because the API uses
typed params, it's exempted from generation.
Signed-off-by: Erik Skultety
---
generator.py | 1 +
libvirt-override-api.xml | 6 ++
libvirt-override.c | 34 ++
3 files changed, 41 insertions(+)
diff --git a/generator.py b/generator.py
index 643d1b4..353adab 100755
--- a/generator.py
+++ b/generator.py
@@ -490,6 +490,7 @@ skip_impl = (
'virDomainGetGuestVcpus',
'virConnectBaselineHypervisorCPU',
'virDomainGetLaunchSecurityInfo',
+'virNodeGetSEVInfo',
)
lxc_skip_impl = (
diff --git a/libvirt-override-api.xml b/libvirt-override-api.xml
index 7137237..7f7ae58 100644
--- a/libvirt-override-api.xml
+++ b/libvirt-override-api.xml
@@ -734,5 +734,11 @@
+
+ Get platform specific information from the SEV firmware
+
+
+
+
diff --git a/libvirt-override.c b/libvirt-override.c
index 5de8693..a0584a7 100644
--- a/libvirt-override.c
+++ b/libvirt-override.c
@@ -9796,6 +9796,40 @@ libvirt_virDomainGetLaunchSecurityInfo(PyObject *self
ATTRIBUTE_UNUSED,
virTypedParamsFree(params, nparams);
return ret;
}
+
+
+static PyObject *
+libvirt_virNodeGetSEVInfo(PyObject *self ATTRIBUTE_UNUSED,
+ PyObject *args)
+{
+PyObject *pyobj_conn = NULL;
+PyObject *ret = NULL;
+
+virConnectPtr conn = NULL;
+virTypedParameterPtr params = NULL;
+int nparams = 0;
+unsigned int flags = 0;
+int i_retval;
+
+if (!PyArg_ParseTuple(args, (char *)"OI:virNodeGetSEVInfo",
+ _conn, ))
+return NULL;
+conn = (virConnectPtr) PyvirConnect_Get(pyobj_conn);
+
+LIBVIRT_BEGIN_ALLOW_THREADS;
+i_retval = virNodeGetSEVInfo(conn, params, nparams, flags);
+LIBVIRT_END_ALLOW_THREADS;
+
+if (i_retval < 0) {
+ret = VIR_PY_NONE;
+goto cleanup;
+}
+
+ret = getPyVirTypedParameter(params, nparams);
+ cleanup:
+virTypedParamsFree(params, nparams);
+return ret;
+}
#endif /* LIBVIR_CHECK_VERSION(4, 5, 0) */
--
2.14.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/10] SEV: use camelCase in XMLs and other cleanups
On 06/12/2018 07:00 AM, Ján Tomko wrote: The first two patches tune up the XML elements to use camelCase instead of dashes as the word separators. Hopefully our QEMU capability probing is right and we can fix error reporting in patch 3. The rest are minor cleanups and renames to use SEV instead of Sev in internal identifier names. Thanks for the series, In addition to looking at the changes I did a quick build and run tests. All seems to be working fine. thanks Reviewed-by: Brijesh Singh Tested-by: Brijesh Singh I did not touch virNodeGetSevInfoEnsureACL - not sure if it's all right since the public API uses SEV. Ján Tomko (10): domaincaps: rename reduced-phys-bits to reducedPhysBits conf: prefer camelCase for launchSecurity qemu: fail if virQEMUCapsProbeQMPSEVCapabilities fails remove virQEMUCapsSetSEVCapabilities qemuDomainGetSEVMeasurement: fix possible leak rename qemuBuildSevCreateFile to qemuProcessSEVCreateFile qemuProcessSEVCreateFile: use a cleanup label Rename virDomainSevDefPtr to virDomainSEVDefPtr rename more Sev functions to SEV qemuMonitorJSONGetSEVCapabilities: remove redundant whitespace docs/formatdomain.html.in | 22 +++ docs/formatdomaincaps.html.in | 2 +- docs/schemas/domaincaps.rng| 2 +- docs/schemas/domaincommon.rng | 10 +++ src/conf/domain_capabilities.c | 2 +- src/conf/domain_conf.c | 32 +++--- src/conf/domain_conf.h | 8 +++--- src/qemu/qemu_capabilities.c | 16 ++- src/qemu/qemu_command.c| 6 ++-- src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor_json.c | 1 - src/qemu/qemu_process.c| 26 -- tests/genericxml2xmlindata/launch-security-sev.xml | 8 +++--- tests/qemuxml2argvdata/launch-security-sev.xml | 8 +++--- 14 files changed, 66 insertions(+), 79 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] apparmor: fix vfio usage without initial hostdev
Thanks everybody, pushed with the commit message cleaned up and acks/reviews added. On Tue, Jun 12, 2018 at 2:39 PM, Jamie Strandboge wrote: > On Mon, 2018-06-11 at 13:52 +0200, Christian Ehrhardt wrote: > > The base vfio has not much functionality but to provide a custom > > container by opening this path. > > See https://www.kernel.org/doc/Documentation/vfio.txt for more. > > > > Systems with static hostdevs will get /dev/vfio/vfio by virt-aa- > > hotplug > > right from the beginning. But if the guest initially had no hostdev > > at > > all it will run into the following deny before the security module > > labelling callbacks will make the actual vfio device (like > > /dev/vfio/93) > > known. > > > > Access by qemu is "wr" even thou in theory it could maybe be "r": > > [ 2652.756712] audit: type=1400 audit(1491303691.719:25): > > apparmor="DENIED" operation="open" > > profile="libvirt-17a61b87-5132-497c-b928-421ac2ee0c8a" > > name="/dev/vfio/vfio" pid=8486 comm="qemu-system-x86" > > requested_mask="wr" denied_mask="wr" fsuid=64055 ouid=0 > > > > Bug-Ubuntu: https://bugs.launchpad.net/bugs/1678322 > > Bug-Ubuntu: https://bugs.launchpad.net/bugs/1775777 > > > > Signed-off-by: Christian Ehrhardt > > Signed-off-by: Stefan Bader > > --- > > examples/apparmor/libvirt-qemu | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/examples/apparmor/libvirt-qemu > > b/examples/apparmor/libvirt-qemu > > index 2c47652250..874aca2092 100644 > > --- a/examples/apparmor/libvirt-qemu > > +++ b/examples/apparmor/libvirt-qemu > > @@ -193,6 +193,9 @@ > >deny /dev/shm/lttng-ust-wait-* r, > >deny /run/shm/lttng-ust-wait-* r, > > > > + # for vfio hotplug on systems without static vfio (LP: #1775777) > > + /dev/vfio/vfio rw, > > + > > Makes sense. If the guest doesn't start with vfio then libvirtd is > going to have to give it to the guest and so libvirtd would need this > access. +1 to apply. > > -- > Jamie Strandboge | http://www.canonical.com -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"
On Tue, Jun 12, 2018 at 07:57:40 -0500, Eric Blake wrote: > On 06/12/2018 06:11 AM, Jiri Denemark wrote: > > > I hit the same race twice on aarch64 and ppc64 and I can confirm the > > installation phase fails if libvirt.la is installed later than libraries > > which link to it. However, the dependencies seem to be set correctly in > > the Makefiles. But it looks like they are only honored when linking the > > library during the build phase. During make install libvirt.la and > > libraries which link to it are installed independently. That is, > > install-modLTLIBRARIES does not depend on anything except for the > > mod_LTIBRARIES themselves. Thus when libtool decides to relink the > > libraries libvirt.la may still be missing at this point. Manually > > changing > > > > install-modLTLIBRARIES: $(mod_LTLIBRARIES) > > > > to > > > > install-modLTLIBRARIES: $(mod_LTLIBRARIES) install-libLTLIBRARIES > > > > fixed the problem for me (tested with an artificial delay added to > > install-libLTLIBRARIES target), but I have no idea how to persuade > > automake to generate something like that for us. > > > > Eric, is my investigation correct and do you have any ideas on how to > > fix the race? > > Can you add that line directly into Makefile.am, or does doing that > cause automake to complain and/or omit its normal rules because it > thinks you are overriding its defaults? Yeah. It doesn't complain, but it omits its normal install-modLTLIBRARIES rule which mean nothing will be installed. However, the error is still reported so there are other libraries which are not in mod_LTLIBRARIES affected too. I also tried adding install-modLTLIBRARIES-local target, but it didn't work either since automake doesn't use this target (well I didn't really hope it would work, but I tried it anyway). It's not really surprising bisecting found the following commit which introduced the race, but I'm not really sure how to fix it. Isn't this a bug in automake? :-) commit 21639744f6371db0bfa1bd0d21fe5c51c6d6878a Author: Daniel P. Berrangé Date: Thu Jan 25 09:35:56 2018 + build: explicitly link all modules with libvirt.so The dlopened modules we currently build all use various symbols from libvirt.so, but don't actually link to it. They rely on the libvirtd daemon re-exporting the libvirt.so symbols. This means that at the time the modules are linked, they contain a huge number of undefined symbols. It also means that these undefined symbols are not versioned, so despite us providing a LIBVIRT_PRIVATE_ version that intentionally changes on every release, the loadable modules could actually be loaded into any libvirtd regardless of version. This change explicitly links all modules against libvirt.so so that they don't rely on the re-export behave and can be fully resolved at build time. This will give us a stronger guarantee modules will actually be loadable at runtime and that we're using modules from the matched build. Signed-off-by: Daniel P. Berrange Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [jenkins-ci PATCH 3/3] guests: Drop CentOS 6 support
It hasn't been a target platform for a while now, and the last job that was running on it has been dropped too. Signed-off-by: Andrea Bolognani --- guests/host_vars/libvirt-centos-6/install.yml | 3 - guests/host_vars/libvirt-centos-6/main.yml| 2 - guests/inventory | 1 - guests/tasks/base.yml | 2 - guests/vars/mappings.yml | 19 +--- guests/vars/projects/libvirt.yml | 1 - guests/vars/vault.yml | 86 +-- 7 files changed, 42 insertions(+), 72 deletions(-) delete mode 100644 guests/host_vars/libvirt-centos-6/install.yml delete mode 100644 guests/host_vars/libvirt-centos-6/main.yml diff --git a/guests/host_vars/libvirt-centos-6/install.yml b/guests/host_vars/libvirt-centos-6/install.yml deleted file mode 100644 index 3a9459b..000 --- a/guests/host_vars/libvirt-centos-6/install.yml +++ /dev/null @@ -1,3 +0,0 @@ -install_url: http://mirror.centos.org/centos/6/os/x86_64/ -install_config: kickstart.cfg diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml deleted file mode 100644 index c3a555c..000 --- a/guests/host_vars/libvirt-centos-6/main.yml +++ /dev/null @@ -1,2 +0,0 @@ -projects: diff --git a/guests/inventory b/guests/inventory index 0c8e280..6ea43d9 100644 --- a/guests/inventory +++ b/guests/inventory @@ -1,4 +1,3 @@ -libvirt-centos-6 libvirt-centos-7 libvirt-debian-8 libvirt-debian-9 diff --git a/guests/tasks/base.yml b/guests/tasks/base.yml index b774b29..13d02f8 100644 --- a/guests/tasks/base.yml +++ b/guests/tasks/base.yml @@ -156,8 +156,6 @@ warn: no when: - package_format == 'rpm' -- not ( os_name == 'CentOS' and -os_version == '6' ) - name: Clean up packages after update apt: diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index 9847649..92822cb 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -9,7 +9,7 @@ # - default # - package format (deb, pkg, rpm) # - OS name (CentOS, Debian, Fedora, FreeBSD, Ubuntu) -# - OS version (CentOS6, Debian9, FedoraRawhide, Ubuntu18 and so on) +# - OS version (CentOS7, Debian9, FedoraRawhide, Ubuntu18 and so on) # # So something like # @@ -58,7 +58,6 @@ mappings: bash-completion: default: bash-completion -CentOS6: ccache: default: ccache @@ -144,19 +143,16 @@ mappings: go: default: golang FreeBSD: go -CentOS6: gobject-introspection: deb: libgirepository1.0-dev pkg: gobject-introspection rpm: gobject-introspection-devel -CentOS6: gtk3: deb: libgtk-3-dev pkg: gtk3 rpm: gtk3-devel -CentOS6: gtk-doc: default: gtk-doc @@ -171,14 +167,12 @@ mappings: deb: libgtk-vnc-2.0-dev pkg: gtk-vnc rpm: gtk-vnc2-devel -CentOS6: hal: FreeBSD: hal icoutils: default: icoutils -CentOS6: intltool: default: intltool @@ -245,9 +239,6 @@ mappings: Debian: libgovirt-dev Debian8: - libnl: -CentOS6: libnl-devel - libnl3: deb: libnl-3-dev rpm: libnl3-devel @@ -293,7 +284,6 @@ mappings: rpm: libssh-devel Debian: libssh-gcrypt-dev Ubuntu: libssh-dev -CentOS6: libssh2: deb: libssh2-1-dev @@ -528,7 +518,6 @@ mappings: deb: libcpan-changes-perl pkg: p5-CPAN-Changes rpm: perl-CPAN-Changes -CentOS6: perl-Config-Record: deb: libconfig-record-perl @@ -539,13 +528,11 @@ mappings: deb: libdigest-perl pkg: p5-Digest rpm: perl-Digest -CentOS6: perl-Digest-MD5: deb: libdigest-perl-md5-perl pkg: p5-Digest-MD5 rpm: perl-Digest-MD5 -CentOS6: perl-File-Slurp: deb: libfile-slurp-perl @@ -632,7 +619,6 @@ mappings: perl-generators: rpm: perl-generators -CentOS6: CentOS7: pkg-config: @@ -757,7 +743,6 @@ mappings: deb: libspice-client-gtk-3.0-dev pkg: spice-gtk rpm: spice-gtk3-devel -CentOS6: sudo: default: sudo @@ -765,7 +750,6 @@ mappings: tc: deb: iproute2 rpm: iproute-tc -CentOS6: iproute CentOS7: iproute unzip: @@ -779,7 +763,6 @@ mappings: vala: default: vala deb: valac -CentOS6: vim: default: vim diff --git a/guests/vars/projects/libvirt.yml b/guests/vars/projects/libvirt.yml index 248a64e..3274564 100644 --- a/guests/vars/projects/libvirt.yml +++ b/guests/vars/projects/libvirt.yml @@ -22,7 +22,6 @@ packages: - libcap-ng - libcurl - libdbus - - libnl - libnl3 - libnlroute3 - libnuma diff --git a/guests/vars/vault.yml b/guests/vars/vault.yml index 5bf89dc..69a61da 100644 --- a/guests/vars/vault.yml +++ b/guests/vars/vault.yml @@ -1,46 +1,42 @@ $ANSIBLE_VAULT;1.1;AES256 -66646139336431653964363035353762363664313738393832356132333835616363373032656335
[libvirt] [jenkins-ci PATCH 1/3] projects: Drop libvirt-master-build-website job
The job has been failing ever since libvirt has made
GnuTLS 3.2.0 mandatory with commit 60d9ad6f1e42, so
it no longer provides any value.
Signed-off-by: Andrea Bolognani
---
projects/libvirt.yaml | 11 ---
1 file changed, 11 deletions(-)
diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
index 3d893dd..7a8392e 100644
--- a/projects/libvirt.yaml
+++ b/projects/libvirt.yaml
@@ -40,14 +40,3 @@
local_env: '{mingw64_local_env}'
autogen_args: '{mingw64_autogen_args}'
machines: '{mingw_machines}'
- - generic-build-job:
- parent_jobs:
- variant: -website
- command: |
-mkdir build
-cd build
-../autogen.sh --without-libvirtd --without-macvtap
-$MAKE -C docs/
-$MAKE dist
- machines:
-- libvirt-centos-6
--
2.17.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [jenkins-ci PATCH 2/3] guests: Drop libvirt+website project
We're no longer running the corresponding job. Signed-off-by: Andrea Bolognani --- guests/host_vars/libvirt-centos-6/main.yml | 1 - guests/vars/projects/libvirt+website.yml | 5 - 2 files changed, 6 deletions(-) delete mode 100644 guests/vars/projects/libvirt+website.yml diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml index 265c622..c3a555c 100644 --- a/guests/host_vars/libvirt-centos-6/main.yml +++ b/guests/host_vars/libvirt-centos-6/main.yml @@ -1,3 +1,2 @@ --- projects: - - libvirt+website diff --git a/guests/vars/projects/libvirt+website.yml b/guests/vars/projects/libvirt+website.yml deleted file mode 100644 index 128ed8c..000 --- a/guests/vars/projects/libvirt+website.yml +++ /dev/null @@ -1,5 +0,0 @@ -packages: - - libxml2 - - rpcgen - - xsltproc -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [jenkins-ci PATCH 0/3] Drop CentOS 6 support
As suggested in https://www.redhat.com/archives/libvir-list/2018-June/msg00943.html Andrea Bolognani (3): projects: Drop libvirt-master-build-website job guests: Drop libvirt+website project guests: Drop CentOS 6 support guests/host_vars/libvirt-centos-6/install.yml | 3 - guests/host_vars/libvirt-centos-6/main.yml| 3 - guests/inventory | 1 - guests/tasks/base.yml | 2 - guests/vars/mappings.yml | 19 +--- guests/vars/projects/libvirt+website.yml | 5 -- guests/vars/projects/libvirt.yml | 1 - guests/vars/vault.yml | 86 +-- projects/libvirt.yaml | 11 --- 9 files changed, 42 insertions(+), 89 deletions(-) delete mode 100644 guests/host_vars/libvirt-centos-6/install.yml delete mode 100644 guests/host_vars/libvirt-centos-6/main.yml delete mode 100644 guests/vars/projects/libvirt+website.yml -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] libvirtd: Add service dependency on systemd-logind
At daemon startup we query logind for host PM support status. Without a service dependency host startup can trigger libvirtd errors like: error : virNodeSuspendSupportsTarget:336 : internal error: Cannot probe for supported suspend types warning : virQEMUCapsInit:949 : Failed to get host power management capabilities Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1588288 Signed-off-by: Cole Robinson --- src/remote/libvirtd.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in index 769702ea75..7f689e08a8 100644 --- a/src/remote/libvirtd.service.in +++ b/src/remote/libvirtd.service.in @@ -15,6 +15,7 @@ After=iscsid.service After=apparmor.service After=local-fs.target After=remote-fs.target +After=systemd-logind.service After=systemd-machined.service Documentation=man:libvirtd(8) Documentation=https://libvirt.org -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Check for existing hostdev address for cold attach device
On 06/11/2018 10:42 AM, Ján Tomko wrote:
> On Wed, Jun 06, 2018 at 10:44:10AM -0400, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1559867
>>
>> Add a check if the incoming with specified
>> already exists and if so fail the attach.
>>
>
> Looking at the reproducer steps, the bug talks about libvirt
> auto-generating a duplicate address, not user-specified input.
>
Oh, right - perhaps should have been clearer what's happening with the
addition. While/when not provided, the post parse processing
for a hostdev will automagically generate the address... of course in
the code I was looking at that was there and essentially
copied the check from VIR_DOMAIN_DEVICE_RNG and that's what was on my
mind when I wrote the terse commit message.
>> Signed-off-by: John Ferlan
>> ---
>> src/qemu/qemu_driver.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>> index 38ea865ce3..7b4cdbcdcf 100644
>> --- a/src/qemu/qemu_driver.c
>> +++ b/src/qemu/qemu_driver.c
>> @@ -8014,6 +8014,12 @@ qemuDomainAttachDeviceConfig(virDomainDefPtr
>> vmdef,
>> _("device is already in the domain
>> configuration"));
>> return -1;
>> }
>> + if (dev->data.hostdev->info->type !=
>> VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE &&
>> + virDomainDefHasDeviceAddress(vmdef,
>> dev->data.hostdev->info)) {
>> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
>> + _("a device with the same address already
>> exists "));
>> + return -1;
>> + }
>
> This does not fix the problem of autogenerating the address in any way
> (which seems to work when I call attach --config while the domain is not
> running).
True, but it does avoid the attempt to attach a duplicated address -
still I see now it's the autogeneration of a address that's
broken when a domain is running and the attachment is for the config.
When just looking at the virDomainHostdevAssignAddress code one could
believe sure this should provide the right answer, but unlike the SCSI
option for virDomainDiskDefAssignAddress which makes use of the def->dst
in order to "seed" the @idx for the subsequent equations the hostdev
code doesn't have a name so it linearly looks for an available address
during post parse processing.
In this instance however, it's using the running domain's vm->def
instead of the persistent vm->newDef, thus obtaining the same answer
twice with the second one being incorrect.
Updated patches will be posted soon.
>
> Also, if we needded additional checks for guest addresses on attach,
> we should either do it for all devices (and drop the calling of
> per-domain postParse after adding a single device), or take care of the
> conflicts in postParse.
>
Not 100% sure what you mean by this. Still the processing of a SCSI
hostdev relies not only on existing SCSI hostdev's, but also any
existing SCSI disk - so making the correct calculation is challenging.
Whether that same "need" exists for other cold attach devices (net,
lease, controller, chrdev, fs, rng, memory, redirdev, shmem, watchdog,
and vsock) would seem to extend beyond the bounds of this bz.
Thanks for the review -
John
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH libvirt 0/3] events: clean up NULL checking involving virObjectEventStateQueueRemote
On 06/12/2018 01:36 AM, Pavel Hrdina wrote: > On Mon, Jun 11, 2018 at 03:38:16PM -0400, Anya Harter wrote: >> Currently, all virObjectEventStateQueue callers and >> virObjectEventStateQueueRemote callers need to do NULL checking. >> >> In this patch series, all NULL checking has been moved to >> virObjectEventStateQueueRemote and all callers of the Remote or >> not Remote function have their NULL checking removed. >> >> Anya Harter (3): >> events: add NULL check in virObjectEventStateQueue >> events: move NULL check to EventStateQueueRemote >> events: remove remoteEventQueue wrapper function > > I've tweaked the commit messages and pushed it. Congratulation on your > first libvirt contribution! :) Thanks! > > One note, the same cleanup as for remote driver can be done for test > driver and the testObjectEventQueue() function. Yes, my intent is to repeat this cleanup with testObjectEventQueue, libxlDomainEventQueue, qemuDomainEventQueue, and umlDomainEventQueue. I was going to send the four as a patch series once they were done. This task was laid out on the BiteSizedTasks page https://wiki.libvirt.org/page/BiteSizedTasks#Remove_NULL_checking_around_EventStateQueue. > > Pavel > > > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
On Tue, Jun 12, 2018 at 03:04:42PM +0200, Michal Privoznik wrote: > On 06/12/2018 02:42 PM, Igor Mammedov wrote: > > >>> > >>> Do we really need to make -daemonize and -preconfig work > >>> together? libvirt uses -daemonize only for its initial > >>> capability probing, which shouldn't require -preconfig at all. > >>> > >>> Even on that case, I wonder why libvirt doesn't simply create a > >>> server socket and waits for QEMU to connect instead of using > >>> -daemonize as a sync point. > >>> > >> > >> because libvirt views qemu as well behaved daemon. Should anything go > >> wrong libvirt reads qemu's stderr and reports error to upper layers. > > We can keep daemonizing flow in QEMU as it's now. > > But Eduardo's idea about libvirt created socked + letting QEMU connect to it > > has a merit. It should fix current deadlock issue with as monitor > > won't be depending on lead exit event. > > Not sure about the benefits. Currently, libvirt spawns qemu, waits for > monitor to show up (currently, the timeout dynamic depending on some > black magic involving guest RAM size) and if it does not show up in time > it kills qemu. The same algorithm must be kept in place even for case > when libvirt would pass pre-opened socket to qemu in case qemu deadlocks > before being able to communicate over qmp. The only advantage I see is > libvirt would not need to label the socket (set uid:gid, selinux, ...). As mentioned in my other reply, we already do FD passing, and that code has intentionally got rid of the timeout, because timeouts cause false failures to launch QEMU. This is a particular problem when using many disks that are encrypted, since LUKS encryption has a minimum 1 second delay on opening each disk, so with many disks we're at risk of hitting the timeout even when QEMU is still starting normally. I don't see a reason to special case startup with timeouts to deal with hangs, while ignoring the possibility of hangs after initial startup. > On the other hand, since it would be libvirt creating the socket what > would happen on libvirtd restart? We're creating a *listener* socket, not a client connection, so on restart we simply connect again as normal. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
On Tue, Jun 12, 2018 at 15:04:42 +0200, Michal Privoznik wrote: > On 06/12/2018 02:42 PM, Igor Mammedov wrote: > > >>> > >>> Do we really need to make -daemonize and -preconfig work > >>> together? libvirt uses -daemonize only for its initial > >>> capability probing, which shouldn't require -preconfig at all. > >>> > >>> Even on that case, I wonder why libvirt doesn't simply create a > >>> server socket and waits for QEMU to connect instead of using > >>> -daemonize as a sync point. > >>> > >> > >> because libvirt views qemu as well behaved daemon. Should anything go > >> wrong libvirt reads qemu's stderr and reports error to upper layers. > > We can keep daemonizing flow in QEMU as it's now. > > But Eduardo's idea about libvirt created socked + letting QEMU connect to it > > has a merit. It should fix current deadlock issue with as monitor > > won't be depending on lead exit event. > > Not sure about the benefits. Currently, libvirt spawns qemu, waits for > monitor to show up (currently, the timeout dynamic depending on some > black magic involving guest RAM size) and if it does not show up in time > it kills qemu. The same algorithm must be kept in place even for case > when libvirt would pass pre-opened socket to qemu in case qemu deadlocks > before being able to communicate over qmp. The only advantage I see is > libvirt would not need to label the socket (set uid:gid, selinux, ...). > On the other hand, since it would be libvirt creating the socket what > would happen on libvirtd restart? Well, if qemu deadlocks just after spewing out the monitor greeting you end up in the same situation as the timeout code is not applied later for regular monitor communication. Depending on how early the preconfig state happens, keeping in the timeout may be pointless. signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
On 06/12/2018 02:42 PM, Igor Mammedov wrote: >>> >>> Do we really need to make -daemonize and -preconfig work >>> together? libvirt uses -daemonize only for its initial >>> capability probing, which shouldn't require -preconfig at all. >>> >>> Even on that case, I wonder why libvirt doesn't simply create a >>> server socket and waits for QEMU to connect instead of using >>> -daemonize as a sync point. >>> >> >> because libvirt views qemu as well behaved daemon. Should anything go >> wrong libvirt reads qemu's stderr and reports error to upper layers. > We can keep daemonizing flow in QEMU as it's now. > But Eduardo's idea about libvirt created socked + letting QEMU connect to it > has a merit. It should fix current deadlock issue with as monitor > won't be depending on lead exit event. Not sure about the benefits. Currently, libvirt spawns qemu, waits for monitor to show up (currently, the timeout dynamic depending on some black magic involving guest RAM size) and if it does not show up in time it kills qemu. The same algorithm must be kept in place even for case when libvirt would pass pre-opened socket to qemu in case qemu deadlocks before being able to communicate over qmp. The only advantage I see is libvirt would not need to label the socket (set uid:gid, selinux, ...). On the other hand, since it would be libvirt creating the socket what would happen on libvirtd restart? > Can we do this way on libvirt side when --preconfig is in use > (it might even be fine for normal flow without -preconfig)? I think passing pre-opened socket and --preconfig are orthogonal. What if somebody wants to use --preconfig does not pass any FD? Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"
On 06/12/2018 06:11 AM, Jiri Denemark wrote: I hit the same race twice on aarch64 and ppc64 and I can confirm the installation phase fails if libvirt.la is installed later than libraries which link to it. However, the dependencies seem to be set correctly in the Makefiles. But it looks like they are only honored when linking the library during the build phase. During make install libvirt.la and libraries which link to it are installed independently. That is, install-modLTLIBRARIES does not depend on anything except for the mod_LTIBRARIES themselves. Thus when libtool decides to relink the libraries libvirt.la may still be missing at this point. Manually changing install-modLTLIBRARIES: $(mod_LTLIBRARIES) to install-modLTLIBRARIES: $(mod_LTLIBRARIES) install-libLTLIBRARIES fixed the problem for me (tested with an artificial delay added to install-libLTLIBRARIES target), but I have no idea how to persuade automake to generate something like that for us. Eric, is my investigation correct and do you have any ideas on how to fix the race? Can you add that line directly into Makefile.am, or does doing that cause automake to complain and/or omit its normal rules because it thinks you are overriding its defaults? I know that getting automake to add a dependency is not always trivial, but that it should be possible (my strengths lie more on autoconf than on automake). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
On Tue, Jun 12, 2018 at 02:42:05PM +0200, Igor Mammedov wrote: > We can keep daemonizing flow in QEMU as it's now. > But Eduardo's idea about libvirt created socked + letting QEMU connect to it > has a merit. It should fix current deadlock issue with as monitor > won't be depending on lead exit event. NB, libvirt only ever uses --daemonize when probing capabilities, never when launching QEMU for a real VM. In the latter case, we now use FD passing, so libvirt opens the UNIX domain socket listener, and passes this into QEMU. So libvirt knows it can connect to the listener immediately and will only ever get a failure if QEMU has exited. We can't use FD passing for the capabilities probing because of the chicken & egg problem - we need to probe capabilities to find out if FD passing it available or not. Fortunately with capabilities probing, we don't care about using --preconfig, as were not running a real VM Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
On Tue, 12 Jun 2018 11:17:15 +0200
Michal Privoznik wrote:
> On 06/12/2018 12:36 AM, Eduardo Habkost wrote:
> > CCing libvir-list.
> >
> > On Mon, Jun 11, 2018 at 11:29:24PM +0200, Igor Mammedov wrote:
> >> On Mon, 11 Jun 2018 16:06:07 -0300
> >> Eduardo Habkost wrote:
> >>
> >>> On Mon, Jun 11, 2018 at 03:16:25PM +0200, Igor Mammedov wrote:
> On Fri, 8 Jun 2018 10:21:05 -0300
> Eduardo Habkost wrote:
>
> > On Thu, Jun 07, 2018 at 02:00:09PM +0200, Igor Mammedov wrote:
> >> When using --daemonize, the initial lead process will fork a child and
> >> then wait to be notified that setup is complete via a pipe, before it
> >> exits. When using --preconfig there is an extra call to main_loop()
> >> before the notification is done from os_setup_post(). Thus the parent
> >> process won't exit until the mgmt application connects to the monitor
> >> and tells QEMU to leave the RUN_STATE_PRECONFIG. The mgmt application
> >> won't connect to the monitor until daemonizing has completed though.
> >>
> >> This is a chicken and egg problem, leading to deadlock at startup.
> >>
> >> The only viable way to fix this is to call os_setup_post() before
> >> the early main_loop() call when --preconfig is used. This has the
> >> downside that any errors from this point onwards won't be handled
> >> well by the mgmt application, because it will think QEMU has started
> >> successfully, so not be expecting an abrupt exit. Moving as much user
> >> input validation as possible to before the main_loop() call might help,
> >> but mgmt application should stop assuming that QEMU has started
> >> successfuly and use other means to collect errors from QEMU (logfile).
> >>
> >> Signed-off-by: Daniel P. Berrangé
> >> Signed-off-by: Igor Mammedov
> >> ---
> >> v5:
> >> * use original Daniel's patch [1], but addapt it to apply on top of
> >> "[PATCH v3 1/2] cli: Don't run early event loop if no --preconfig
> >> was specified"
> >> with extra comment and massage commit message a little bit.
> >> v6:
> >> * hide os_setup_post_done flag inside of os_setup_post() as it was
> >> in v4
> >>
> >> CC: berra...@redhat.com
> >> CC: mre...@redhat.com
> >> CC: pbonz...@redhat.com
> >> CC: ehabk...@redhat.com
> >> CC: ldok...@redhat.com
> >> CC: ebl...@redhat.com
> >> ---
> >> os-posix.c | 6 ++
> >> vl.c | 6 ++
> >> 2 files changed, 12 insertions(+)
> >>
> >> diff --git a/os-posix.c b/os-posix.c
> >> index 9ce6f74..0246195 100644
> >> --- a/os-posix.c
> >> +++ b/os-posix.c
> >> @@ -309,8 +309,14 @@ void os_daemonize(void)
> >>
> >> void os_setup_post(void)
> >> {
> >> +static bool os_setup_post_done;
> >> int fd = 0;
> >>
> >> +if (os_setup_post_done) {
> >> +return;
> >> +}
> >> +os_setup_post_done = true;
> >> +
> >> if (daemonize) {
> >> if (chdir("/")) {
> >> error_report("not able to chdir to /: %s",
> >> strerror(errno));
> >> diff --git a/vl.c b/vl.c
> >> index fa44138..457ff2a 100644
> >> --- a/vl.c
> >> +++ b/vl.c
> >> @@ -4578,6 +4578,12 @@ int main(int argc, char **argv, char **envp)
> >> parse_numa_opts(current_machine);
> >>
> >> /* do monitor/qmp handling at preconfig state if requested */
> >> +if (!preconfig_exit_requested && is_daemonized()) {
> >> +/* signal parent QEMU to exit, libvirt treats it as a sign
> >> + * that monitor socket is ready to accept connections
> >> + */
> >> +os_setup_post();
> >> +}
> >
> > I was looking at the daemonize logic, and noticed it we have a
> > huge amount of code between this line and the next
> > os_setup_post() call that could either:
> >
> > * call exit() and/or error_report(); or
> logging would work to the extent mentioned in commit message,
> i.e. it' would work fine when log file is used otherwise it
> errors will go to /dev/null
>
> so it should be more or less fine on this point
> >>>
> >>> My worry is that most users of error_report() involve an exit()
> >>> call too.
> >>>
> >>> Once we have an active monitor, we must never call exit()
> >>> directly. Even qmp_quit() doesn't call exit() directly.
> >> Is there any reason why exit() can't be called?
> >
> > QMP clients don't expect the QMP socket to be closed except when
> > using the 'quit' command.
>
> Libvirt views HANGUP on monitor socket as qemu process dying
> unexpectedly so it starts cleanup (which involves 'kill -9' of qemu).
So if we exit(1) there is a chance to get SIGKILL before exit(1) completes.
Do we care about it at this point?
(there are places when QEMU calls exit(1) at runtime on
Re: [libvirt] [PATCH v2 1/5] configure: Require GnuTLS
On Tue, 2018-06-12 at 13:22 +0100, Daniel P. Berrangé wrote: > On Tue, Jun 12, 2018 at 01:26:05PM +0200, Andrea Bolognani wrote: > > > I was actually intending to take a simpler approach - just compile a > > > newer gnutls into /opt and let the website build use that. > > > > Sure, that would probably do the trick as far as libvirt.org itself > > is concerned; however, we would not only have to keep CentOS 6 > > around in the CentOS CI environment, but also figure out a way to > > reproduce the same hack there if we want to make sure changes in > > libvirt don't accidentally break building the website. > > I'd just drop the CI job and we'll deal with problems with the > website build if and when we find them In that case, going for the local GnuTLS build on libvirt.org is perfectly fine with me. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] apparmor: fix vfio usage without initial hostdev
On Mon, 2018-06-11 at 13:52 +0200, Christian Ehrhardt wrote: > The base vfio has not much functionality but to provide a custom > container by opening this path. > See https://www.kernel.org/doc/Documentation/vfio.txt for more. > > Systems with static hostdevs will get /dev/vfio/vfio by virt-aa- > hotplug > right from the beginning. But if the guest initially had no hostdev > at > all it will run into the following deny before the security module > labelling callbacks will make the actual vfio device (like > /dev/vfio/93) > known. > > Access by qemu is "wr" even thou in theory it could maybe be "r": > [ 2652.756712] audit: type=1400 audit(1491303691.719:25): > apparmor="DENIED" operation="open" > profile="libvirt-17a61b87-5132-497c-b928-421ac2ee0c8a" > name="/dev/vfio/vfio" pid=8486 comm="qemu-system-x86" > requested_mask="wr" denied_mask="wr" fsuid=64055 ouid=0 > > Bug-Ubuntu: https://bugs.launchpad.net/bugs/1678322 > Bug-Ubuntu: https://bugs.launchpad.net/bugs/1775777 > > Signed-off-by: Christian Ehrhardt > Signed-off-by: Stefan Bader > --- > examples/apparmor/libvirt-qemu | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/examples/apparmor/libvirt-qemu > b/examples/apparmor/libvirt-qemu > index 2c47652250..874aca2092 100644 > --- a/examples/apparmor/libvirt-qemu > +++ b/examples/apparmor/libvirt-qemu > @@ -193,6 +193,9 @@ >deny /dev/shm/lttng-ust-wait-* r, >deny /run/shm/lttng-ust-wait-* r, > > + # for vfio hotplug on systems without static vfio (LP: #1775777) > + /dev/vfio/vfio rw, > + Makes sense. If the guest doesn't start with vfio then libvirtd is going to have to give it to the guest and so libvirtd would need this access. +1 to apply. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/5] configure: Require GnuTLS
On Tue, Jun 12, 2018 at 01:26:05PM +0200, Andrea Bolognani wrote: > On Tue, 2018-06-12 at 11:41 +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 12, 2018 at 12:24:14PM +0200, Andrea Bolognani wrote: > > > I've started building Docker containers with all libvirt build > > > dependencies already installed[1], mainly for use in Travis CI; > > > the CentOS 7 container could easily be used to also solve the > > > issue at hand. > > > > > > I've already tried building libvirt inside said container on a > > > CentOS 6 host running Docker from EPEL without encountering any > > > issue; all that's left to do is install Docker on libvirt.org > > > and script the integration, which shouldn't be too difficult. > > > > > > Does that sound like a sensible way forward? > > > > AFAIK, Docker is explicitly unsupported on CentOS 6 now. > > > > https://github.com/moby/moby/issues/14365 > > Yeah, the Docker version available in CentOS 6 EPEL is fairly old > and I doubt it's getting a lot of updates these days. > > That said, we would be using it exclusively with images we've > crafted ourselves starting from official (and thus arguably > trustworthy) base images, and only to run build jobs locally, so > I'm not sure there's much to be concerned about security-wise. > > > I was actually intending to take a simpler approach - just compile a > > newer gnutls into /opt and let the website build use that. > > Sure, that would probably do the trick as far as libvirt.org itself > is concerned; however, we would not only have to keep CentOS 6 > around in the CentOS CI environment, but also figure out a way to > reproduce the same hack there if we want to make sure changes in > libvirt don't accidentally break building the website. I'd just drop the CI job and we'll deal with problems with the website build if and when we find them Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 10/10] qemuMonitorJSONGetSEVCapabilities: remove redundant whitespace
Signed-off-by: Ján Tomko --- src/qemu/qemu_monitor_json.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index c5480a2d0e..3ad01b9dd3 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -6423,7 +6423,6 @@ qemuMonitorJSONGetSEVCapabilities(qemuMonitorPtr mon, if (qemuMonitorJSONCommand(mon, cmd, ) < 0) goto cleanup; - if (qemuMonitorJSONCheckError(cmd, reply) < 0) goto cleanup; -- 2.16.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 09/10] rename more Sev functions to SEV
Signed-off-by: Ján Tomko
---
src/qemu/qemu_command.c | 4 ++--
src/qemu/qemu_process.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 1cb721c152..a557a0387a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -9691,7 +9691,7 @@ qemuBuildTPMCommandLine(virCommandPtr cmd,
}
static int
-qemuBuildSevCommandLine(virDomainObjPtr vm, virCommandPtr cmd,
+qemuBuildSEVCommandLine(virDomainObjPtr vm, virCommandPtr cmd,
virDomainSEVDefPtr sev)
{
virBuffer obj = VIR_BUFFER_INITIALIZER;
@@ -10321,7 +10321,7 @@ qemuBuildCommandLine(virQEMUDriverPtr driver,
if (qemuBuildVMCoreInfoCommandLine(cmd, def, qemuCaps) < 0)
goto error;
-if (qemuBuildSevCommandLine(vm, cmd, def->sev) < 0)
+if (qemuBuildSEVCommandLine(vm, cmd, def->sev) < 0)
goto error;
if (snapshot)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 36ca365a72..f62433c278 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5849,7 +5849,7 @@ qemuProcessSEVCreateFile(const char *configDir,
static int
-qemuProcessPrepareSevGuestInput(virDomainObjPtr vm)
+qemuProcessPrepareSEVGuestInput(virDomainObjPtr vm)
{
qemuDomainObjPrivatePtr priv = vm->privateData;
virDomainDefPtr def = vm->def;
@@ -6044,7 +6044,7 @@ qemuProcessPrepareHost(virQEMUDriverPtr driver,
if (qemuExtDevicesPrepareHost(driver, vm->def) < 0)
goto cleanup;
-if (qemuProcessPrepareSevGuestInput(vm) < 0)
+if (qemuProcessPrepareSEVGuestInput(vm) < 0)
goto cleanup;
ret = 0;
--
2.16.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 08/10] Rename virDomainSevDefPtr to virDomainSEVDefPtr
Some identifiers use Sev, some SEV. Prefer the latter.
Signed-off-by: Ján Tomko
---
src/conf/domain_conf.c | 8
src/conf/domain_conf.h | 8
src/qemu/qemu_command.c | 2 +-
src/qemu/qemu_process.c | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index ac5484d070..5c3b20fb21 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2962,7 +2962,7 @@ virDomainCachetuneDefFree(virDomainCachetuneDefPtr
cachetune)
static void
-virDomainSEVDefFree(virDomainSevDefPtr def)
+virDomainSEVDefFree(virDomainSEVDefPtr def)
{
if (!def)
return;
@@ -15845,14 +15845,14 @@ virDomainMemoryTargetDefParseXML(xmlNodePtr node,
}
-static virDomainSevDefPtr
+static virDomainSEVDefPtr
virDomainSEVDefParseXML(xmlNodePtr sevNode,
xmlXPathContextPtr ctxt)
{
char *tmp = NULL;
char *type = NULL;
xmlNodePtr save = ctxt->node;
-virDomainSevDefPtr def;
+virDomainSEVDefPtr def;
unsigned long policy;
ctxt->node = sevNode;
@@ -26766,7 +26766,7 @@ virDomainKeyWrapDefFormat(virBufferPtr buf,
virDomainKeyWrapDefPtr keywrap)
static void
-virDomainSEVDefFormat(virBufferPtr buf, virDomainSevDefPtr sev)
+virDomainSEVDefFormat(virBufferPtr buf, virDomainSEVDefPtr sev)
{
if (!sev)
return;
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index ea8ddb2b39..6344c02d1c 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2324,10 +2324,10 @@ typedef enum {
VIR_DOMAIN_LAUNCH_SECURITY_LAST,
} virDomainLaunchSecurity;
-typedef struct _virDomainSevDef virDomainSevDef;
-typedef virDomainSevDef *virDomainSevDefPtr;
+typedef struct _virDomainSEVDef virDomainSEVDef;
+typedef virDomainSEVDef *virDomainSEVDefPtr;
-struct _virDomainSevDef {
+struct _virDomainSEVDef {
int sectype; /* enum virDomainLaunchSecurity */
char *dh_cert;
char *session;
@@ -2529,7 +2529,7 @@ struct _virDomainDef {
virDomainKeyWrapDefPtr keywrap;
/* SEV-specific domain */
-virDomainSevDefPtr sev;
+virDomainSEVDefPtr sev;
/* Application-specific custom metadata */
xmlNodePtr metadata;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 6a95344fd5..1cb721c152 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -9692,7 +9692,7 @@ qemuBuildTPMCommandLine(virCommandPtr cmd,
static int
qemuBuildSevCommandLine(virDomainObjPtr vm, virCommandPtr cmd,
-virDomainSevDefPtr sev)
+virDomainSEVDefPtr sev)
{
virBuffer obj = VIR_BUFFER_INITIALIZER;
qemuDomainObjPrivatePtr priv = vm->privateData;
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 7468e14447..36ca365a72 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5854,7 +5854,7 @@ qemuProcessPrepareSevGuestInput(virDomainObjPtr vm)
qemuDomainObjPrivatePtr priv = vm->privateData;
virDomainDefPtr def = vm->def;
virQEMUCapsPtr qemuCaps = priv->qemuCaps;
-virDomainSevDefPtr sev = def->sev;
+virDomainSEVDefPtr sev = def->sev;
if (!sev)
return 0;
--
2.16.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 04/10] remove virQEMUCapsSetSEVCapabilities
It is only used in one place.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 35d46c465d..7131c2a8ee 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2084,16 +2084,6 @@ virQEMUCapsSetGICCapabilities(virQEMUCapsPtr qemuCaps,
}
-void
-virQEMUCapsSetSEVCapabilities(virQEMUCapsPtr qemuCaps,
- virSEVCapability *capabilities)
-{
-virSEVCapabilitiesFree(qemuCaps->sevCapabilities);
-
-qemuCaps->sevCapabilities = capabilities;
-}
-
-
virSEVCapabilityPtr
virQEMUCapsGetSEVCapabilities(virQEMUCapsPtr qemuCaps)
{
@@ -2697,8 +2687,8 @@ virQEMUCapsProbeQMPSEVCapabilities(virQEMUCapsPtr
qemuCaps,
if (qemuMonitorGetSEVCapabilities(mon, ) < 0)
return -1;
-virQEMUCapsSetSEVCapabilities(qemuCaps, caps);
-
+virSEVCapabilitiesFree(qemuCaps->sevCapabilities);
+qemuCaps->sevCapabilities = caps;
return 0;
}
--
2.16.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 07/10] qemuProcessSEVCreateFile: use a cleanup label
A common cleanup path for both the success and the error case.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_process.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 5d4b6a9499..7468e14447 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5831,6 +5831,7 @@ qemuProcessSEVCreateFile(const char *configDir,
const char *data)
{
char *configFile;
+int ret = -1;
if (!(configFile = virFileBuildPath(configDir, name, ".base64")))
return -1;
@@ -5838,15 +5839,12 @@ qemuProcessSEVCreateFile(const char *configDir,
if (virFileRewriteStr(configFile, S_IRUSR | S_IWUSR, data) < 0) {
virReportSystemError(errno, _("failed to write data to config '%s'"),
configFile);
-goto error;
+goto cleanup;
}
+ cleanup:
VIR_FREE(configFile);
-return 0;
-
- error:
-VIR_FREE(configFile);
-return -1;
+return ret;
}
--
2.16.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 05/10] qemuDomainGetSEVMeasurement: fix possible leak
Free tmp even on failure. Signed-off-by: Ján Tomko --- src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index f0fb806fcd..ac2ef35f70 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -21532,10 +21532,10 @@ qemuDomainGetSEVMeasurement(virQEMUDriverPtr driver, tmp) < 0) goto endjob; -VIR_FREE(tmp); ret = 0; endjob: +VIR_FREE(tmp); qemuDomainObjEndJob(driver, vm); return ret; } -- 2.16.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 06/10] rename qemuBuildSevCreateFile to qemuProcessSEVCreateFile
Make the function prefix match the file it's in.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_process.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 480bc8c1ad..5d4b6a9499 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5826,9 +5826,9 @@ qemuProcessPrepareDomain(virQEMUDriverPtr driver,
static int
-qemuBuildSevCreateFile(const char *configDir,
- const char *name,
- const char *data)
+qemuProcessSEVCreateFile(const char *configDir,
+ const char *name,
+ const char *data)
{
char *configFile;
@@ -5871,12 +5871,12 @@ qemuProcessPrepareSevGuestInput(virDomainObjPtr vm)
}
if (sev->dh_cert) {
-if (qemuBuildSevCreateFile(priv->libDir, "dh_cert", sev->dh_cert) < 0)
+if (qemuProcessSEVCreateFile(priv->libDir, "dh_cert", sev->dh_cert) <
0)
return -1;
}
if (sev->session) {
-if (qemuBuildSevCreateFile(priv->libDir, "session", sev->session) < 0)
+if (qemuProcessSEVCreateFile(priv->libDir, "session", sev->session) <
0)
return -1;
}
--
2.16.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 02/10] conf: prefer camelCase for launchSecurity
Adjust the documentation, parser and tests to change:
launch-security -> launchSecurity
reduced-phys-bits -> reducedPhysBits
dh-cert -> dhCert
Also fix the headline in formatdomain.html to be more generic,
and some leftover closing elements in the documentation.
Signed-off-by: Ján Tomko
---
docs/formatdomain.html.in | 22 ++--
docs/schemas/domaincommon.rng | 10 -
src/conf/domain_conf.c | 24 +++---
tests/genericxml2xmlindata/launch-security-sev.xml | 8
tests/qemuxml2argvdata/launch-security-sev.xml | 8
5 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 77845fe5f7..7e710d7c4a 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -8458,12 +8458,12 @@ qemu-kvm -net nic,model=? /dev/null
Note: DEA/TDEA is synonymous with DES/TDES.
-Secure Encrypted Virtualization (SEV)
+Launch Security
- The contents of the launch-security type='sev'
element
+ The contents of the launchSecurity type='sev'
element
is used to provide the guest owners input used for creating an encrypted
- VM using the AMD SEV feature.
+ VM using the AMD SEV feature (Secure Encrypted Virtualization).
SEV is an extension to the AMD-V architecture which supports running
encrypted virtual machine (VMs) under the control of KVM. Encrypted
@@ -8480,13 +8480,13 @@ qemu-kvm -net nic,model=? /dev/null
domain
...
- launch-security type='sev'
+ launchSecurity type='sev'
policy 0x0001 /policy
cbitpos 47 /cbitpos
-reduced-phys-bits 1 /reduced-phys-bits
+reducedPhysBits 1 /reducedPhysBits
+dhCert RBBBSDDD=FDDCCCDDDG /dhCert
session AAACCCDD=FFFCCCDSDS /session
-dh-cert RBBBSDDD=FDDCCCDDDG /dh
- /sev
+ /launchSecurity
...
/domain
@@ -8498,8 +8498,8 @@ qemu-kvm -net nic,model=? /dev/null
hypervisor dependent and can be obtained through the sev
element
from the domain capabilities.
- reduced-phys-bits
- The required reduced-phys-bits element provides the
physical
+ reducedPhysBits
+ The required reducedPhysBits element provides the
physical
address bit reducation. Similar to cbitpos the value of
reduced-phys-bit is hypervisor dependent and can be obtained
through the sev element from the domain capabilities.
@@ -8558,8 +8558,8 @@ qemu-kvm -net nic,model=? /dev/null
- dh-cert
- The optional dh-cert element provides the guest owners
+ dhCert
+ The optional dhCert element provides the guest owners
base64 encoded Diffie-Hellman (DH) key. The key is used to negotiate a
master secret key between the SEV firmware and guest owner. This master
secret key is then used to establish a trusted channel between SEV
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 1d06a5ea89..4a454dddb4 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -78,7 +78,7 @@
-
+
@@ -439,8 +439,8 @@
-
-
+
+
sev
@@ -448,7 +448,7 @@
-
+
@@ -460,7 +460,7 @@
-
+
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 85f07af46e..ac5484d070 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -15862,7 +15862,7 @@ virDomainSEVDefParseXML(xmlNodePtr sevNode,
if (!(type = virXMLPropString(sevNode, "type"))) {
virReportError(VIR_ERR_XML_ERROR, "%s",
- _("missing launch-security type"));
+ _("missing launch security type"));
goto error;
}
@@ -15874,33 +15874,33 @@ virDomainSEVDefParseXML(xmlNodePtr sevNode,
case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
default:
virReportError(VIR_ERR_XML_ERROR,
- _("unsupported launch-security type '%s'"),
+ _("unsupported launch security type '%s'"),
type);
goto error;
}
if (virXPathUInt("string(./cbitpos)", ctxt, >cbitpos) < 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
- _("failed to get launch-security cbitpos"));
+ _("failed to get launch security cbitpos"));
goto error;
}
-if (virXPathUInt("string(./reduced-phys-bits)", ctxt,
+if (virXPathUInt("string(./reducedPhysBits)", ctxt,
>reduced_phys_bits) < 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
- _("failed to get launch-security reduced-phys-bits"));
+
[libvirt] [PATCH 03/10] qemu: fail if virQEMUCapsProbeQMPSEVCapabilities fails
Do not mask the errors.
If we'd expect query-sev-capabilities to fail, we should not
call it in the first place.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 7a245a58bc..35d46c465d 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -4105,7 +4105,7 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
/* Probe for SEV capabilities */
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST)) {
if (virQEMUCapsProbeQMPSEVCapabilities(qemuCaps, mon) < 0)
-virQEMUCapsClear(qemuCaps, QEMU_CAPS_SEV_GUEST);
+goto cleanup;
}
ret = 0;
--
2.16.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 01/10] domaincaps: rename reduced-phys-bits to reducedPhysBits
We have enough elements using underscores instead of camelCase, do not bring dashes into the mix. Signed-off-by: Ján Tomko --- docs/formatdomaincaps.html.in | 2 +- docs/schemas/domaincaps.rng| 2 +- src/conf/domain_capabilities.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 6be553a114..9920de4dac 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -492,7 +492,7 @@ When memory encryption is enabled, one of the physical address bits (aka the C-bit) is utilized to mark if a memory page is protected. The C-bit position is Hypervisor dependent. - reduced-phys-bits + reducedPhysBits When memory encryption is enabled, we lose certain bits in physical address space. The number of bits we lose is hypervisor dependent. diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng index 1d0a2e17aa..e25201fc68 100644 --- a/docs/schemas/domaincaps.rng +++ b/docs/schemas/domaincaps.rng @@ -216,7 +216,7 @@ - + diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c index ec469bfb9a..e5d943af50 100644 --- a/src/conf/domain_capabilities.c +++ b/src/conf/domain_capabilities.c @@ -565,7 +565,7 @@ virDomainCapsFeatureSEVFormat(virBufferPtr buf, virBufferAddLit(buf, "\n"); virBufferAdjustIndent(buf, 2); virBufferAsprintf(buf, "%d\n", sev->cbitpos); -virBufferAsprintf(buf, "%d\n", +virBufferAsprintf(buf, "%d\n", sev->reduced_phys_bits); virBufferAdjustIndent(buf, -2); virBufferAddLit(buf, "\n"); -- 2.16.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 00/10] SEV: use camelCase in XMLs and other cleanups
The first two patches tune up the XML elements to use camelCase instead of dashes as the word separators. Hopefully our QEMU capability probing is right and we can fix error reporting in patch 3. The rest are minor cleanups and renames to use SEV instead of Sev in internal identifier names. I did not touch virNodeGetSevInfoEnsureACL - not sure if it's all right since the public API uses SEV. Ján Tomko (10): domaincaps: rename reduced-phys-bits to reducedPhysBits conf: prefer camelCase for launchSecurity qemu: fail if virQEMUCapsProbeQMPSEVCapabilities fails remove virQEMUCapsSetSEVCapabilities qemuDomainGetSEVMeasurement: fix possible leak rename qemuBuildSevCreateFile to qemuProcessSEVCreateFile qemuProcessSEVCreateFile: use a cleanup label Rename virDomainSevDefPtr to virDomainSEVDefPtr rename more Sev functions to SEV qemuMonitorJSONGetSEVCapabilities: remove redundant whitespace docs/formatdomain.html.in | 22 +++ docs/formatdomaincaps.html.in | 2 +- docs/schemas/domaincaps.rng| 2 +- docs/schemas/domaincommon.rng | 10 +++ src/conf/domain_capabilities.c | 2 +- src/conf/domain_conf.c | 32 +++--- src/conf/domain_conf.h | 8 +++--- src/qemu/qemu_capabilities.c | 16 ++- src/qemu/qemu_command.c| 6 ++-- src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor_json.c | 1 - src/qemu/qemu_process.c| 26 -- tests/genericxml2xmlindata/launch-security-sev.xml | 8 +++--- tests/qemuxml2argvdata/launch-security-sev.xml | 8 +++--- 14 files changed, 66 insertions(+), 79 deletions(-) -- 2.16.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] lib: Document limitation of virDomainInterfaceAddresses
https://bugzilla.redhat.com/show_bug.cgi?id=1588336 This API takes @source argument which tells it where to get domain IP addresses from. However, not all sources are capable of providing all the information we report, for instance ARP table has no notion of IP address prefixes. Document this limitation. Signed-off-by: Michal Privoznik --- src/libvirt-domain.c | 4 1 file changed, 4 insertions(+) diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index dcfc7d4c57..4a899f31c8 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -11780,6 +11780,10 @@ virDomainFSInfoFree(virDomainFSInfoPtr info) * be unreachable. Depending on the route table config of the * guest, the returned mac address may be duplicated. * + * Note that for some @source values some pieces of returned @ifaces + * might be unset (e.g. VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP does not + * set IP address prefix as ARP table does not have any notion of that). + * * @ifaces->name and @ifaces->hwaddr are never NULL. * * The caller *must* free @ifaces when no longer needed. Usual use case -- 2.16.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/5] configure: Require GnuTLS
On Tue, 2018-06-12 at 11:41 +0100, Daniel P. Berrangé wrote: > On Tue, Jun 12, 2018 at 12:24:14PM +0200, Andrea Bolognani wrote: > > I've started building Docker containers with all libvirt build > > dependencies already installed[1], mainly for use in Travis CI; > > the CentOS 7 container could easily be used to also solve the > > issue at hand. > > > > I've already tried building libvirt inside said container on a > > CentOS 6 host running Docker from EPEL without encountering any > > issue; all that's left to do is install Docker on libvirt.org > > and script the integration, which shouldn't be too difficult. > > > > Does that sound like a sensible way forward? > > AFAIK, Docker is explicitly unsupported on CentOS 6 now. > > https://github.com/moby/moby/issues/14365 Yeah, the Docker version available in CentOS 6 EPEL is fairly old and I doubt it's getting a lot of updates these days. That said, we would be using it exclusively with images we've crafted ourselves starting from official (and thus arguably trustworthy) base images, and only to run build jobs locally, so I'm not sure there's much to be concerned about security-wise. > I was actually intending to take a simpler approach - just compile a > newer gnutls into /opt and let the website build use that. Sure, that would probably do the trick as far as libvirt.org itself is concerned; however, we would not only have to keep CentOS 6 around in the CentOS CI environment, but also figure out a way to reproduce the same hack there if we want to make sure changes in libvirt don't accidentally break building the website. That doesn't sound too attractive overall, and more specifically I'm not sure it would be much better than running an unsupported Docker version. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"
On Thu, May 24, 2018 at 15:52:55 -0600, Jim Fehlig wrote:
> On 05/24/2018 04:27 AM, Ian Jackson wrote:
> > Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""):
> >> tl;dr:
> >>
> >> I think there is a bug in libvirt's build system which, with
> >> low probability, causes a build failure containing this message:
> >>/usr/bin/ld: cannot find -lvirt
> >>
> >> Complete build logs of two attempts:
> >>
> >>
> >> http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-build.log
> >>
> >>
> >> http://logs.test-lab.xenproject.org/osstest/logs/123096/build-i386-libvirt/6.ts-libvirt-build.log
> >
> > I have run a number of attempts. Out of 5 more, 1 succeeded. So out
> > of a total of 7 attempts, 1 succeeded. This repro rate is an IMO
> > excellent opportunity to debug this race :-).
>
> There appears to be a missing dependency between the lockd library and
> libvirt
> library, but my autotools skills lack the savvy to find it. Here we see the
> install command and relinking of lockd.la
I hit the same race twice on aarch64 and ppc64 and I can confirm the
installation phase fails if libvirt.la is installed later than libraries
which link to it. However, the dependencies seem to be set correctly in
the Makefiles. But it looks like they are only honored when linking the
library during the build phase. During make install libvirt.la and
libraries which link to it are installed independently. That is,
install-modLTLIBRARIES does not depend on anything except for the
mod_LTIBRARIES themselves. Thus when libtool decides to relink the
libraries libvirt.la may still be missing at this point. Manually
changing
install-modLTLIBRARIES: $(mod_LTLIBRARIES)
to
install-modLTLIBRARIES: $(mod_LTLIBRARIES) install-libLTLIBRARIES
fixed the problem for me (tested with an artificial delay added to
install-libLTLIBRARIES target), but I have no idea how to persuade
automake to generate something like that for us.
Eric, is my investigation correct and do you have any ideas on how to
fix the race?
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/5] configure: Require GnuTLS
On Tue, Jun 12, 2018 at 12:24:14PM +0200, Andrea Bolognani wrote: > On Wed, 2018-06-06 at 12:45 +0200, Andrea Bolognani wrote: > > Another thing to keep in mind is that moving the website build to > > a CentOS 7 container would allow us to remove the last remnants > > of CentOS 6 support from libvirt-jenkins-ci.git and delete the > > corresponding virtual machine from the CentOS CI environment, > > freeing up resources for other tasks. > > I've started building Docker containers with all libvirt build > dependencies already installed[1], mainly for use in Travis CI; > the CentOS 7 container could easily be used to also solve the > issue at hand. > > I've already tried building libvirt inside said container on a > CentOS 6 host running Docker from EPEL without encountering any > issue; all that's left to do is install Docker on libvirt.org > and script the integration, which shouldn't be too difficult. > > Does that sound like a sensible way forward? AFAIK, Docker is explicitly unsupported on CentOS 6 now. https://github.com/moby/moby/issues/14365 I was actually intending to take a simpler approach - just compile a newer gnutls into /opt and let the website build use that. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/5] configure: Require GnuTLS
On Wed, 2018-06-06 at 12:45 +0200, Andrea Bolognani wrote: > Another thing to keep in mind is that moving the website build to > a CentOS 7 container would allow us to remove the last remnants > of CentOS 6 support from libvirt-jenkins-ci.git and delete the > corresponding virtual machine from the CentOS CI environment, > freeing up resources for other tasks. I've started building Docker containers with all libvirt build dependencies already installed[1], mainly for use in Travis CI; the CentOS 7 container could easily be used to also solve the issue at hand. I've already tried building libvirt inside said container on a CentOS 6 host running Docker from EPEL without encountering any issue; all that's left to do is install Docker on libvirt.org and script the integration, which shouldn't be too difficult. Does that sound like a sensible way forward? [1] https://www.redhat.com/archives/libvir-list/2018-June/msg00920.html -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] tools: virsh: add command for controling/monitoring resctrl
> -Original Message- > From: Martin Kletzander [mailto:mklet...@redhat.com] > Sent: Monday, June 11, 2018 4:45 PM > To: Wang, Huaqiang > Cc: libvir-list@redhat.com; Feng, Shaohe ; Niu, Bing > ; Ding, Jian-feng ; Zang, Rui > > Subject: Re: [libvirt] [PATCH 2/3] tools: virsh: add command for > controling/monitoring resctrl > > On Fri, Jun 08, 2018 at 05:02:18PM +0800, Wang Huaqiang wrote: > >--- > > The subject says 'virsh', but the code does: > > > include/libvirt/libvirt-domain.h| 9 +++ > > src/conf/domain_conf.c | 28 +++ > > src/conf/domain_conf.h | 3 + > > something with XML parsing and/or formatting > > > src/driver-hypervisor.h | 8 ++ > > src/libvirt-domain.c| 81 + > > src/libvirt_public.syms | 6 ++ > > changes som public API? > > > src/qemu/qemu_driver.c | 141 > > > src/qemu/qemu_process.c | 65 - > > qemu? > > > src/remote/remote_daemon_dispatch.c | 45 > > src/remote/remote_driver.c | 2 + > > src/remote/remote_protocol.x| 28 ++- > > remote driver? > > > src/remote_protocol-structs | 12 +++ > > tools/virsh-domain.c| 74 +++ > > oh, look, here's the virsh change =) > > Look at the list and check the git log to see how changes are usually split. > > Also see contributor guidelines, mainly for formatting. Will separate source code and create more reasonable patch serials in the next update. Thanks. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] util: add Intel x86 RDT/CMT support
See my update inline. > -Original Message- > From: Martin Kletzander [mailto:mklet...@redhat.com] > Sent: Monday, June 11, 2018 4:40 PM > To: Wang, Huaqiang > Cc: libvir-list@redhat.com; Feng, Shaohe ; Niu, Bing > ; Ding, Jian-feng ; Zang, Rui > > Subject: Re: [libvirt] [PATCH 1/3] util: add Intel x86 RDT/CMT support > > On Fri, Jun 08, 2018 at 05:02:17PM +0800, Wang Huaqiang wrote: > >Add RDT/CMT feature (Intel x86) by interacting with kernel resctrl file > >system. > Integrate code into util/resctrl. > >--- > > src/libvirt_private.syms | 9 ++ > > src/util/virresctrl.c| 316 > ++- > > src/util/virresctrl.h| 44 +++ > > 3 files changed, 367 insertions(+), 2 deletions(-) > > > > This will not merge after some of the cleanups I made. There is one more > patch > that didn't get in and you clould look there for some inspiration as well, > but it's > just about keeping the data in another part of the code. > > Anyway the conflict is very easy to fix now. > > Why isn't it just a matter of setting a boolean? > > Aling the code and run the checks before posting to the list. For more info > see > contribution guidelines: > > https://libvirt.org/hacking.html Yes, noticed your patch. I'd like to make changes accordingly. Will follow the rules listed in "https://libvirt.org/hacking.html; and take care the coding style. Thanks very much. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3] travis: Use pre-built Docker image
Instead of starting from the minimal Ubuntu 18.04 base image and installing all requirements at build time, use a Docker image that has been specifically tailored at building libvirt and thus already includes all required packages. Signed-off-by: Andrea Bolognani --- The pre-built images have been hand-crafted using the build dependencies recorded in the libvirt-jenkins-ci repository: of course that's not something that we want to keep doing manually going forward, so figuring out a sensible way to generate Dockerfiles and potentially even Docker images automatically is pretty high on the priority list. .travis.yml | 75 ++--- 1 file changed, 2 insertions(+), 73 deletions(-) diff --git a/.travis.yml b/.travis.yml index f62e8c6437..1b0d1e824b 100644 --- a/.travis.yml +++ b/.travis.yml @@ -10,7 +10,7 @@ matrix: - services: - docker env: -- IMAGE=ubuntu:18.04 +- IMAGE="ubuntu-18" - DISTCHECK_CONFIGURE_FLAGS="--with-init-script=systemd" - compiler: clang language: c @@ -22,13 +22,11 @@ matrix: script: - docker run - --privileged -v $(pwd):/build -w /build -e VIR_TEST_DEBUG="$VIR_TEST_DEBUG" - -e PACKAGES="$PACKAGES" -e DISTCHECK_CONFIGURE_FLAGS="$DISTCHECK_CONFIGURE_FLAGS" - "$IMAGE" + "libvirt/build:$IMAGE" /bin/sh -xc "$LINUX_CMD" git: @@ -38,8 +36,6 @@ env: global: - VIR_TEST_DEBUG=1 - LINUX_CMD=" -apt-get update && -apt-get install -y \$PACKAGES && ./autogen.sh && make -j3 && make -j3 syntax-check && @@ -67,73 +63,6 @@ env: exit 1 ) " -# Please keep this list sorted alphabetically -- PACKAGES=" -augeas-tools -autoconf -automake -autopoint -bash-completion -ccache -dnsmasq-base -dwarves -ebtables -gcc -gettext -git -glusterfs-client -libacl1-dev -libapparmor-dev -libattr1-dev -libaudit-dev -libavahi-client-dev -libblkid-dev -libc6-dev -libcap-ng-dev -libc-dev-bin -libdbus-1-dev -libdevmapper-dev -libfuse-dev -libgnutls28-dev -libnetcf-dev -libnl-3-dev -libnl-route-3-dev -libnuma-dev -libopenwsman-dev -libparted-dev -libpcap-dev -libpciaccess-dev -librbd-dev -libreadline-dev -libsanlock-dev -libsasl2-dev -libselinux1-dev -libssh2-1-dev -libssh-dev -libtirpc-dev -libtool -libudev-dev -libxen-dev -libxml2-dev -libxml2-utils -libyajl-dev -lvm2 -make -nfs-common -open-iscsi -parted -patch -perl -pkgconf -policykit-1 -qemu-utils -radvd -scrub -sheepdog -systemtap-sdt-dev -xsltproc -zfs-fuse - " notifications: irc: -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3] travis: Add CentOS 7 build
Now that we use pre-built Docker images, it's very easy to extend our test matrix; adding CentOS 7 is a good start. Signed-off-by: Andrea Bolognani --- .travis.yml | 5 + 1 file changed, 5 insertions(+) diff --git a/.travis.yml b/.travis.yml index 1b0d1e824b..37fa1ccf8c 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,6 +12,11 @@ matrix: env: - IMAGE="ubuntu-18" - DISTCHECK_CONFIGURE_FLAGS="--with-init-script=systemd" +- services: +- docker + env: +- IMAGE="centos-7" +- DISTCHECK_CONFIGURE_FLAGS="--with-init-script=upstart" - compiler: clang language: c os: osx -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v9 00/11] x86: Secure Encrypted Virtualization (AMD)
On Tue, Jun 12, 2018 at 11:07:51AM +0100, Daniel P. Berrangé wrote: > On Mon, Jun 11, 2018 at 11:17:02AM -0500, Brijesh Singh wrote: > > Hi Erik, > > > > > > On 06/11/2018 09:10 AM, Erik Skultety wrote: > > > On Fri, Jun 08, 2018 at 10:14:35AM -0500, Brijesh Singh wrote: > > > > > > > > Re: Jano's below comment > > > > > > > > (Also, some of the patches have double "<< >>" around your e-mail, > > > > how did that happen?) > > > > > > > > I am not sure what I am doing that is causing the double "<< >>" around > > > > my > > > > email address in some patches. I tried fixing it after I saw Jano note > > > > but > > > > it somehow happens again...I have no explanation on what is going on. > > > > Whoever commits the series, can you please remove one of the quote from > > > > the > > > > my email address, Or I can try fixing it and resend the series. Please > > > > let > > > > me know. thanks > > > > > > For the whole series (I'll make the tiny change in patch 5): > > > Reviewed-by: Erik Skultety > > > > > > I'll also tweak the double angle brackets, at first I thought you were > > > adding > > > the SoB manually and this was a typo, but it clearly isn't the case, it > > > would > > > be pointless to bikeshed about that, so as I said, I'll take care of that > > > before merging. > > > > > > Also, now that this is done, would take also take care of extending the > > > other > > > language bindings for the new APIs, or shall I do that? > > > > > > Thanks for all your help in reviews. Any help on language bindings for the > > new APIs are appreciated. I think I may able to do python but will certainly > > need help with others (I am not very familiar with other languages). > > Thanks for all your hard work in developing this feature for libvirt and > patience with the many rounds of the review process. > > I will take care of the Go & Perl bindings if no one beats me to it. I'm working on the python ones at the moment, thanks Daniel for taking care of Go & Perl. Erik -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/3] travis: Use pre-built Docker images
Applies on top of https://www.redhat.com/archives/libvir-list/2018-June/msg00579.html See patch 2/3 for more information. Andrea Bolognani (3): travis: Drop Ubuntu 16.04 build travis: Use pre-built Docker image travis: Add CentOS 7 build .travis.yml | 77 +++-- 1 file changed, 3 insertions(+), 74 deletions(-) -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/3] travis: Drop Ubuntu 16.04 build
This will make further changes easier; all coverage lost due to this will be reintroduced later on. Signed-off-by: Andrea Bolognani --- .travis.yml | 5 - 1 file changed, 5 deletions(-) diff --git a/.travis.yml b/.travis.yml index 0ae8b293b1..f62e8c6437 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,11 +12,6 @@ matrix: env: - IMAGE=ubuntu:18.04 - DISTCHECK_CONFIGURE_FLAGS="--with-init-script=systemd" -- services: -- docker - env: -- IMAGE=ubuntu:16.04 -- DISTCHECK_CONFIGURE_FLAGS="--with-init-script=upstart" - compiler: clang language: c os: osx -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 0/3] RFC for X86 RDT Cache Monitoring Technology (CMT) support
Hi Martin,
Thanks for your comments, please see my update inline below.
> -Original Message-
> From: Martin Kletzander [mailto:mklet...@redhat.com]
> Sent: Monday, June 11, 2018 4:30 PM
> To: Wang, Huaqiang
> Cc: libvir-list@redhat.com; Feng, Shaohe ; Niu, Bing
> ; Ding, Jian-feng ; Zang, Rui
>
> Subject: Re: [libvirt] [RFC PATCH 0/3] RFC for X86 RDT Cache Monitoring
> Technology (CMT) support
>
> [It would be nice if you wrapped the long lines]
I'll pay attention to these long lines. Thanks for advices.
>
> On Fri, Jun 08, 2018 at 05:02:16PM +0800, Wang Huaqiang wrote:
> >This is an RFC request for supporting CPU Cache Monitoring Technology (CMT)
> feature in libvirt. Since MBM is also another feature which is very close to
> CMT,
> for simplicity we only discuss CMT here. MBM is the followup that will be
> implemented after CMT.
> >About CMT please refer to Intel x86 SDM section 17.18 of volume 3
> (link:https://software.intel.com/en-us/articles/intel-sdm).
> >
>
> Can you elaborate on how is this different to the CMT perf event that is
> already
> in libvirt and can be monitored through domstats API?
Due to kernel interface removal of the perf events 'cmt,mbmt,mbml', the libvirt
will no
longer work with latest kernel. Please examine following link for details.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=c39a0e2c8850f08249383f2425dbd8dbe4baad69,
This serials is trying to provide the similar functions of this missing part
for reporting
cmt, mbmt and mbml information. First we only focus on cmt.
Comparing with 'CMT perf event already in libvirt', I am trying to implement
almost
the same output as 'perf.cmt' in the output message of 'domstats', but with
another
name , such as 'resctrl.cmt' or 'rdt.cmt' (or some others).
Another difference is that the underlying implementation is done through the
kernel resctrl fs.
This serials also attempts to provide a command interface for enabling and
disabling
cmt feature in scope of whole domain as original perf event based cmt could be
controlled, enabled or disabled, through specifying '--enable cmt' or
'--disable cmt'
while invoking command 'virsh perf '.
Our version is like 'virsh resctrl --enable' with a difference of no
suffix of
'cmt'. The 'cmt' is omitted because the CMT and MBM function are both enabled
whenever a valid resctrl fs sub-folder created, there is no way to disable one
while
enable another one, such as enabling CMT while disabling MBML at the same time.
This serials is trying to stick to interfaces exposed by perf event based
CMT/MBM
and provide an interface substitution for perf event based CMB/MBM, such as
the perf based CMT only provides the cache occupancy information for whole
domain only. We are also in thinking providing the capability to provide the
cache occupancy information based on vcpus groups which may be specified in
XML file.
For example, if we have following configuration:
The 'domstats' will output following information regarding cmt
[root@dl-c200 libvirt]# virsh domstats vm1 --resctrl
Domain: 'vm1'
rdt.cmt.total=645562
rdt.cmt.vcpu0=104331
rdt.cmt.vcpu1_2=203200
rdt.cmt.vcpu3=340129
Those updates address your comment for " Can you elaborate on how is
this different to the CMT perf event that is already in libvirt and can be
monitored through domstats API?", any input is welcome.
>
> https://libvirt.org/formatdomain.html#elementsPerf
>
> >## About '_virResctrlMon' interface
> >
> >The cache allocation technology (CAT) has already been implemented in
> >util/virresctrl.* which interacts with Linux kernel resctrl file
> >system. Very simlimar to CAT, the CMT object is represented by 'struct
> >_virResctrlMon', which is
> >
> >```
> >struct _virResctrlMon {
> >virObject parent;
> >
> >/* pairedalloc: pointer to a resctrl allocaion it paried with.
> > * NULL for a resctrl monitoring group not associated with
> > * any allocation. */
> >virResctrlAllocPtr pairedalloc;
> >/* The identifier (any unique string for now) */
> >char *id;
> >/* libvirt-generated path, may be identical to alloction path
> > * may not if allocation is ready */
> >char *path;
> >};
> >```
> >
> >Almost following the same logic behind '_virResctrlAlloc' which is mainly
> presented in file 'virresctrl.c', a group of APIs has been designed to
> manipulate
> '_virResctrlMon'. The '_virResctrlMon' shares a lot in common with
> '_virResctrlAlloc' except field 'pairedalloc'.
> >'pairedalloc' stores the pointer of paired resctrl allocation object. With
> >current
> libvirt resctrl implementation, if a resctrl '_virResctrlAlloc' object is
>
Re: [libvirt] [PATCH v9 00/11] x86: Secure Encrypted Virtualization (AMD)
On Mon, Jun 11, 2018 at 11:17:02AM -0500, Brijesh Singh wrote: > Hi Erik, > > > On 06/11/2018 09:10 AM, Erik Skultety wrote: > > On Fri, Jun 08, 2018 at 10:14:35AM -0500, Brijesh Singh wrote: > > > > > > Re: Jano's below comment > > > > > > (Also, some of the patches have double "<< >>" around your e-mail, > > > how did that happen?) > > > > > > I am not sure what I am doing that is causing the double "<< >>" around my > > > email address in some patches. I tried fixing it after I saw Jano note but > > > it somehow happens again...I have no explanation on what is going on. > > > Whoever commits the series, can you please remove one of the quote from > > > the > > > my email address, Or I can try fixing it and resend the series. Please let > > > me know. thanks > > > > For the whole series (I'll make the tiny change in patch 5): > > Reviewed-by: Erik Skultety > > > > I'll also tweak the double angle brackets, at first I thought you were > > adding > > the SoB manually and this was a typo, but it clearly isn't the case, it > > would > > be pointless to bikeshed about that, so as I said, I'll take care of that > > before merging. > > > > Also, now that this is done, would take also take care of extending the > > other > > language bindings for the new APIs, or shall I do that? > > > Thanks for all your help in reviews. Any help on language bindings for the > new APIs are appreciated. I think I may able to do python but will certainly > need help with others (I am not very familiar with other languages). Thanks for all your hard work in developing this feature for libvirt and patience with the many rounds of the review process. I will take care of the Go & Perl bindings if no one beats me to it. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] KVM Forum 2018: Call For Participation
A friendly reminder that the deadline for abstract submission is end of day this Thursday, June 14th. On Thu, May 17, 2018 at 12:52:35PM +0200, Paolo Bonzini wrote: > > KVM Forum 2018: Call For Participation > October 24-26, 2018 - Edinburgh International Conference Centre - Edinburgh, > UK > > (All submissions must be received before midnight June 14, 2018) > = > > 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 2018. > > 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. After more than ten > years of development in the Linux kernel, KVM continues to be a > critical part of the FOSS cloud infrastructure. > > This year, KVM Forum is joining Open Source Summit in Edinburgh, UK. Selected > talks from KVM Forum will be presented on Wednesday October 24 to the full > audience of the Open Source Summit. Also, attendees of KVM Forum will have > access to all of the talks from Open Source Summit on Wednesday. > https://events.linuxfoundation.org/events/kvm-forum-2018/program/cfp/ > > Suggested topics: > * Scaling, latency optimizations, performance tuning, real-time guests > * Hardening and security > * New features > * Testing > > KVM and the Linux kernel: > * Nested virtualization > * Resource management (CPU, I/O, memory) and scheduling > * VFIO: IOMMU, SR-IOV, virtual GPU, etc. > * Networking: Open vSwitch, XDP, etc. > * virtio and vhost > * Architecture ports and new processor features > > QEMU: > * Management interfaces: QOM and QMP > * New devices, new boards, new architectures > * Graphics, desktop virtualization and virtual GPU > * New storage features > * High availability, live migration and fault tolerance > * Emulation and TCG > * Firmware: ACPI, UEFI, coreboot, U-Boot, etc. > > Management and infrastructure > * Managing KVM: Libvirt, OpenStack, oVirt, etc. > * Storage: Ceph, Gluster, SPDK, etc.r > * Network Function Virtualization: DPDK, OPNFV, OVN, etc. > * Provisioning > > > === > SUBMITTING YOUR PROPOSAL > === > Abstracts due: June 14, 2018 > > 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 August 10, 2018. > > Speakers will receive a complimentary pass for the event. In the instance > that case your submission has multiple presenters, only the primary speaker > for a > proposal will receive a complimentary 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_2018_BOF > > Let people you think who might be interested know about your BOF, and > encourage > them to add their names to the wiki page as well. Please try to > add your ideas to the
Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
On 06/12/2018 12:36 AM, Eduardo Habkost wrote:
> CCing libvir-list.
>
> On Mon, Jun 11, 2018 at 11:29:24PM +0200, Igor Mammedov wrote:
>> On Mon, 11 Jun 2018 16:06:07 -0300
>> Eduardo Habkost wrote:
>>
>>> On Mon, Jun 11, 2018 at 03:16:25PM +0200, Igor Mammedov wrote:
On Fri, 8 Jun 2018 10:21:05 -0300
Eduardo Habkost wrote:
> On Thu, Jun 07, 2018 at 02:00:09PM +0200, Igor Mammedov wrote:
>> When using --daemonize, the initial lead process will fork a child and
>> then wait to be notified that setup is complete via a pipe, before it
>> exits. When using --preconfig there is an extra call to main_loop()
>> before the notification is done from os_setup_post(). Thus the parent
>> process won't exit until the mgmt application connects to the monitor
>> and tells QEMU to leave the RUN_STATE_PRECONFIG. The mgmt application
>> won't connect to the monitor until daemonizing has completed though.
>>
>> This is a chicken and egg problem, leading to deadlock at startup.
>>
>> The only viable way to fix this is to call os_setup_post() before
>> the early main_loop() call when --preconfig is used. This has the
>> downside that any errors from this point onwards won't be handled
>> well by the mgmt application, because it will think QEMU has started
>> successfully, so not be expecting an abrupt exit. Moving as much user
>> input validation as possible to before the main_loop() call might help,
>> but mgmt application should stop assuming that QEMU has started
>> successfuly and use other means to collect errors from QEMU (logfile).
>>
>> Signed-off-by: Daniel P. Berrangé
>> Signed-off-by: Igor Mammedov
>> ---
>> v5:
>> * use original Daniel's patch [1], but addapt it to apply on top of
>> "[PATCH v3 1/2] cli: Don't run early event loop if no --preconfig
>> was specified"
>> with extra comment and massage commit message a little bit.
>> v6:
>> * hide os_setup_post_done flag inside of os_setup_post() as it was in
>> v4
>>
>> CC: berra...@redhat.com
>> CC: mre...@redhat.com
>> CC: pbonz...@redhat.com
>> CC: ehabk...@redhat.com
>> CC: ldok...@redhat.com
>> CC: ebl...@redhat.com
>> ---
>> os-posix.c | 6 ++
>> vl.c | 6 ++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/os-posix.c b/os-posix.c
>> index 9ce6f74..0246195 100644
>> --- a/os-posix.c
>> +++ b/os-posix.c
>> @@ -309,8 +309,14 @@ void os_daemonize(void)
>>
>> void os_setup_post(void)
>> {
>> +static bool os_setup_post_done;
>> int fd = 0;
>>
>> +if (os_setup_post_done) {
>> +return;
>> +}
>> +os_setup_post_done = true;
>> +
>> if (daemonize) {
>> if (chdir("/")) {
>> error_report("not able to chdir to /: %s", strerror(errno));
>> diff --git a/vl.c b/vl.c
>> index fa44138..457ff2a 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4578,6 +4578,12 @@ int main(int argc, char **argv, char **envp)
>> parse_numa_opts(current_machine);
>>
>> /* do monitor/qmp handling at preconfig state if requested */
>> +if (!preconfig_exit_requested && is_daemonized()) {
>> +/* signal parent QEMU to exit, libvirt treats it as a sign
>> + * that monitor socket is ready to accept connections
>> + */
>> +os_setup_post();
>> +}
>
> I was looking at the daemonize logic, and noticed it we have a
> huge amount of code between this line and the next
> os_setup_post() call that could either:
>
> * call exit() and/or error_report(); or
logging would work to the extent mentioned in commit message,
i.e. it' would work fine when log file is used otherwise it
errors will go to /dev/null
so it should be more or less fine on this point
>>>
>>> My worry is that most users of error_report() involve an exit()
>>> call too.
>>>
>>> Once we have an active monitor, we must never call exit()
>>> directly. Even qmp_quit() doesn't call exit() directly.
>> Is there any reason why exit() can't be called?
>
> QMP clients don't expect the QMP socket to be closed except when
> using the 'quit' command.
Libvirt views HANGUP on monitor socket as qemu process dying
unexpectedly so it starts cleanup (which involves 'kill -9' of qemu).
>
>>
> * be unable to finish machine initialization because of
> chdir("/"), change_root(), or change_process_uid().
this one really no go.
I see 2 options here,
* move init code that opens files to early stage (before preconfig
monitor)
or split it to open files early.
(I've spotted several obvious places fwcfg/vnc/replay_start/migration)
but there might be code somewhere in callbacks that would do it too,
[libvirt] [PATCH] qemu: add qemu_monitor_priv.h to sources list
Signed-off-by: Daniel P. Berrangé --- Pushed as a build fix src/qemu/Makefile.inc.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/Makefile.inc.am b/src/qemu/Makefile.inc.am index 46797af4be..2afa67f195 100644 --- a/src/qemu/Makefile.inc.am +++ b/src/qemu/Makefile.inc.am @@ -40,6 +40,7 @@ QEMU_DRIVER_SOURCES = \ qemu/qemu_migration_paramspriv.h \ qemu/qemu_monitor.c \ qemu/qemu_monitor.h \ + qemu/qemu_monitor_priv.h \ qemu/qemu_monitor_text.c \ qemu/qemu_monitor_text.h \ qemu/qemu_monitor_json.c \ -- 2.17.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] conf: remove duplicated typedefs for virDomainSevDef
The typedefs were present twice in the header file which causes failures with some compilers, eg FreeBSD 10 CLang: ../../src/conf/domain_conf.h:2330:33: error: redefinition of typedef 'virDomainSevDef' is a C11 feature +[-Werror,-Wtypedef-redefinition] typedef struct _virDomainSevDef virDomainSevDef; ^ ../../src/conf/domain_conf.h:145:33: note: previous definition is here typedef struct _virDomainSevDef virDomainSevDef; ^ Signed-off-by: Daniel P. Berrangé --- Pushed as a build fix src/conf/domain_conf.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index fe7a6bb21b..ea8ddb2b39 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -142,9 +142,6 @@ typedef virDomainPanicDef *virDomainPanicDefPtr; typedef struct _virDomainMemoryDef virDomainMemoryDef; typedef virDomainMemoryDef *virDomainMemoryDefPtr; -typedef struct _virDomainSevDef virDomainSevDef; -typedef virDomainSevDef *virDomainSevDefPtr; - /* forward declarations virDomainChrSourceDef, required by * virDomainNetDef */ -- 2.17.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 11/15] Implement Resize method for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 6 ++
src/storagevol.c| 26 ++
2 files changed, 32 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index c1fecf3..fdde430 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -24,5 +24,11 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolResize"/>
+
+
+
diff --git a/src/storagevol.c b/src/storagevol.c
index efe88d3..66f7c86 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -118,6 +118,31 @@ virtDBusStorageVolGetXMLDesc(GVariant *inArgs,
*outArgs = g_variant_new("(s)", xml);
}
+static void
+virtDBusStorageVolResize(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs G_GNUC_UNUSED,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+guint64 capacity;
+guint flags;
+
+g_variant_get(inArgs, "(tu)", , );
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+if (virStorageVolResize(storageVol, capacity, flags) < 0)
+virtDBusUtilSetLastVirtError(error);
+}
+
static virtDBusGDBusPropertyTable virtDBusStorageVolPropertyTable[] = {
{ "Name", virtDBusStorageVolGetName, NULL },
{ "Key", virtDBusStorageVolGetKey, NULL },
@@ -127,6 +152,7 @@ static virtDBusGDBusPropertyTable
virtDBusStorageVolPropertyTable[] = {
static virtDBusGDBusMethodTable virtDBusStorageVolMethodTable[] = {
{ "GetXMLDesc", virtDBusStorageVolGetXMLDesc },
+{ "Resize", virtDBusStorageVolResize },
{ 0 }
};
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 13/15] Implement GetInfo method for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 6 ++
src/storagevol.c| 29 +
2 files changed, 35 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index aed3f7a..8a4eab2 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -18,6 +18,12 @@
value="See
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetPath"/>
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetInfoFlags"/>
+
+
+
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetXMLDesc"/>
diff --git a/src/storagevol.c b/src/storagevol.c
index 91d99e7..dc05dc4 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -90,6 +90,34 @@ virtDBusStorageVolGetPath(const gchar *objectPath,
*value = g_variant_new("s", key);
}
+static void
+virtDBusStorageVolGetInfo(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+virStorageVolInfo info;
+guint flags;
+
+g_variant_get(inArgs, "(u)", );
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+if (virStorageVolGetInfoFlags(storageVol, , flags) < 0)
+return virtDBusUtilSetLastVirtError(error);
+
+*outArgs = g_variant_new("((itt))", info.type, info.capacity,
+ info.allocation);
+}
+
static void
virtDBusStorageVolGetXMLDesc(GVariant *inArgs,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -176,6 +204,7 @@ static virtDBusGDBusPropertyTable
virtDBusStorageVolPropertyTable[] = {
};
static virtDBusGDBusMethodTable virtDBusStorageVolMethodTable[] = {
+{ "GetInfo", virtDBusStorageVolGetInfo },
{ "GetXMLDesc", virtDBusStorageVolGetXMLDesc },
{ "Resize", virtDBusStorageVolResize },
{ "Wipe", virtDBusStorageVolWipe },
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 10/15] Implement StorageVolLookupByPath method for Connect Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.Connect.xml | 6 ++
src/connect.c| 29 +
tests/test_connect.py| 1 +
3 files changed, 36 insertions(+)
diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
index d3871b3..37daed0 100644
--- a/data/org.libvirt.Connect.xml
+++ b/data/org.libvirt.Connect.xml
@@ -314,6 +314,12 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolLookupByPath"/>
+
+
+
https://libvirt.org/html/libvirt-libvirt-domain.html#virConnectDomainEventCallback"/>
diff --git a/src/connect.c b/src/connect.c
index c526808..157cdb3 100644
--- a/src/connect.c
+++ b/src/connect.c
@@ -1573,6 +1573,34 @@ virtDBusConnectStorageVolLookupByKey(GVariant *inArgs,
*outArgs = g_variant_new("(o)", path);
}
+static void
+virtDBusConnectStorageVolLookupByPath(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath G_GNUC_UNUSED,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+g_autofree gchar *path = NULL;
+
+g_variant_get(inArgs, "(s)", );
+
+if (!virtDBusConnectOpen(connect, error))
+return;
+
+storageVol = virStorageVolLookupByPath(connect->connection, path);
+if (!storageVol)
+return virtDBusUtilSetLastVirtError(error);
+
+path = virtDBusUtilBusPathForVirStorageVol(storageVol,
+ connect->storageVolPath);
+
+*outArgs = g_variant_new("(o)", path);
+}
+
static virtDBusGDBusPropertyTable virtDBusConnectPropertyTable[] = {
{ "Encrypted", virtDBusConnectGetEncrypted, NULL },
{ "Hostname", virtDBusConnectGetHostname, NULL },
@@ -1627,6 +1655,7 @@ static virtDBusGDBusMethodTable
virtDBusConnectMethodTable[] = {
{ "StoragePoolLookupByName", virtDBusConnectStoragePoolLookupByName },
{ "StoragePoolLookupByUUID", virtDBusConnectStoragePoolLookupByUUID },
{ "StorageVolLookupByKey", virtDBusConnectStorageVolLookupByKey },
+{ "StorageVolLookupByPath", virtDBusConnectStorageVolLookupByPath },
{ 0 }
};
diff --git a/tests/test_connect.py b/tests/test_connect.py
index fc4ca78..80bb50b 100755
--- a/tests/test_connect.py
+++ b/tests/test_connect.py
@@ -247,6 +247,7 @@ class TestConnect(libvirttest.BaseTestClass):
@pytest.mark.parametrize("lookup_method_name,lookup_item", [
("StorageVolLookupByKey", 'Key'),
+("StorageVolLookupByPath", 'Path'),
])
def test_connect_storage_vol_lookup_by_property(self,
lookup_method_name,
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 04/15] Implement Name property for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 5 +
src/storagevol.c| 44 +
tests/test_storage.py | 9 +
3 files changed, 58 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index c72c847..3110b4f 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -3,5 +3,10 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetName"/>
+
+
diff --git a/src/storagevol.c b/src/storagevol.c
index dad7d11..70bc2bc 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -3,7 +3,51 @@
#include
+static virStorageVolPtr
+virtDBusStorageVolGetVirStorageVol(virtDBusConnect *connect,
+ const gchar *objectPath,
+ GError **error)
+{
+virStorageVolPtr storageVol;
+
+if (virtDBusConnectOpen(connect, error) < 0)
+return NULL;
+
+storageVol = virtDBusUtilVirStorageVolFromBusPath(connect->connection,
+ objectPath,
+ connect->storageVolPath);
+if (!storageVol) {
+virtDBusUtilSetLastVirtError(error);
+return NULL;
+}
+
+return storageVol;
+}
+
+static void
+virtDBusStorageVolGetName(const gchar *objectPath,
+ gpointer userData,
+ GVariant **value,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+const gchar *name;
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+name = virStorageVolGetName(storageVol);
+if (!name)
+return virtDBusUtilSetLastVirtError(error);
+
+*value = g_variant_new("s", name);
+}
+
static virtDBusGDBusPropertyTable virtDBusStorageVolPropertyTable[] = {
+{ "Name", virtDBusStorageVolGetName, NULL },
{ 0 }
};
diff --git a/tests/test_storage.py b/tests/test_storage.py
index 1cd1249..bfdd084 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -131,5 +131,14 @@ class TestStoragePool(libvirttest.BaseTestClass):
assert isinstance(path, dbus.ObjectPath)
+class TestStorageVolume(libvirttest.BaseTestClass):
+def test_storage_vol_properties_type(self):
+_, obj = self.test_storage_vol()
+
+props = obj.GetAll('org.libvirt.StorageVol',
+ dbus_interface=dbus.PROPERTIES_IFACE)
+assert isinstance(props['Name'], dbus.String)
+
+
if __name__ == '__main__':
libvirttest.run()
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 06/15] Implement Path property for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 5 +
src/storagevol.c| 23 +++
tests/test_storage.py | 1 +
3 files changed, 29 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index 3b36f3b..03c15c2 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -13,5 +13,10 @@
value="See
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetKey"/>
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetPath"/>
+
+
diff --git a/src/storagevol.c b/src/storagevol.c
index 82d81ab..c65e11a 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -68,9 +68,32 @@ virtDBusStorageVolGetKey(const gchar *objectPath,
*value = g_variant_new("s", key);
}
+static void
+virtDBusStorageVolGetPath(const gchar *objectPath,
+ gpointer userData,
+ GVariant **value,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+const gchar *key;
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+key = virStorageVolGetPath(storageVol);
+if (!key)
+return virtDBusUtilSetLastVirtError(error);
+
+*value = g_variant_new("s", key);
+}
+
static virtDBusGDBusPropertyTable virtDBusStorageVolPropertyTable[] = {
{ "Name", virtDBusStorageVolGetName, NULL },
{ "Key", virtDBusStorageVolGetKey, NULL },
+{ "Path", virtDBusStorageVolGetPath, NULL },
{ 0 }
};
diff --git a/tests/test_storage.py b/tests/test_storage.py
index 7aa887d..a430808 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -139,6 +139,7 @@ class TestStorageVolume(libvirttest.BaseTestClass):
dbus_interface=dbus.PROPERTIES_IFACE)
assert isinstance(props['Key'], dbus.String)
assert isinstance(props['Name'], dbus.String)
+assert isinstance(props['Path'], dbus.String)
if __name__ == '__main__':
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 08/15] Implement StorageVolLookupByKey method for Connect Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.Connect.xml | 6 ++
src/connect.c| 30 ++
tests/test_connect.py| 14 ++
3 files changed, 50 insertions(+)
diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
index f41acd2..d3871b3 100644
--- a/data/org.libvirt.Connect.xml
+++ b/data/org.libvirt.Connect.xml
@@ -308,6 +308,12 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolLookupByKey"/>
+
+
+
https://libvirt.org/html/libvirt-libvirt-domain.html#virConnectDomainEventCallback"/>
diff --git a/src/connect.c b/src/connect.c
index 1090e3e..c526808 100644
--- a/src/connect.c
+++ b/src/connect.c
@@ -1544,6 +1544,35 @@ virtDBusConnectStoragePoolLookupByUUID(GVariant *inArgs,
*outArgs = g_variant_new("(o)", path);
}
+static void
+virtDBusConnectStorageVolLookupByKey(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath G_GNUC_UNUSED,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+g_autofree gchar *path = NULL;
+const gchar *key;
+
+g_variant_get(inArgs, "(s)", );
+
+if (!virtDBusConnectOpen(connect, error))
+return;
+
+storageVol = virStorageVolLookupByKey(connect->connection, key);
+if (!storageVol)
+return virtDBusUtilSetLastVirtError(error);
+
+path = virtDBusUtilBusPathForVirStorageVol(storageVol,
+ connect->storageVolPath);
+
+*outArgs = g_variant_new("(o)", path);
+}
+
static virtDBusGDBusPropertyTable virtDBusConnectPropertyTable[] = {
{ "Encrypted", virtDBusConnectGetEncrypted, NULL },
{ "Hostname", virtDBusConnectGetHostname, NULL },
@@ -1597,6 +1626,7 @@ static virtDBusGDBusMethodTable
virtDBusConnectMethodTable[] = {
{ "StoragePoolDefineXML", virtDBusConnectStoragePoolDefineXML },
{ "StoragePoolLookupByName", virtDBusConnectStoragePoolLookupByName },
{ "StoragePoolLookupByUUID", virtDBusConnectStoragePoolLookupByUUID },
+{ "StorageVolLookupByKey", virtDBusConnectStorageVolLookupByKey },
{ 0 }
};
diff --git a/tests/test_connect.py b/tests/test_connect.py
index da146a4..fc4ca78 100755
--- a/tests/test_connect.py
+++ b/tests/test_connect.py
@@ -245,6 +245,20 @@ class TestConnect(libvirttest.BaseTestClass):
path = getattr(self.connect, lookup_method_name)(prop)
assert original_path == path
+@pytest.mark.parametrize("lookup_method_name,lookup_item", [
+("StorageVolLookupByKey", 'Key'),
+])
+def test_connect_storage_vol_lookup_by_property(self,
+lookup_method_name,
+lookup_item):
+"""Parameterized test for all StorageVolLookupBy* API calls of Connect
interface
+"""
+original_path, obj = self.test_storage_vol()
+prop = obj.Get('org.libvirt.StorageVol', lookup_item,
+ dbus_interface=dbus.PROPERTIES_IFACE)
+path = getattr(self.connect, lookup_method_name)(prop)
+assert original_path == path
+
if __name__ == '__main__':
libvirttest.run()
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 14/15] Implement Delete method for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 5 +
src/storagevol.c| 25 +
tests/test_storage.py | 6 ++
3 files changed, 36 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index 8a4eab2..7ad9459 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -18,6 +18,11 @@
value="See
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetPath"/>
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolDelete"/>
+
+
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetInfoFlags"/>
diff --git a/src/storagevol.c b/src/storagevol.c
index dc05dc4..c574be9 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -90,6 +90,30 @@ virtDBusStorageVolGetPath(const gchar *objectPath,
*value = g_variant_new("s", key);
}
+static void
+virtDBusStorageVolDelete(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs G_GNUC_UNUSED,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+guint flags;
+
+g_variant_get(inArgs, "(u)", );
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+if (virStorageVolDelete(storageVol, flags) < 0)
+virtDBusUtilSetLastVirtError(error);
+}
+
static void
virtDBusStorageVolGetInfo(GVariant *inArgs,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -204,6 +228,7 @@ static virtDBusGDBusPropertyTable
virtDBusStorageVolPropertyTable[] = {
};
static virtDBusGDBusMethodTable virtDBusStorageVolMethodTable[] = {
+{ "Delete", virtDBusStorageVolDelete },
{ "GetInfo", virtDBusStorageVolGetInfo },
{ "GetXMLDesc", virtDBusStorageVolGetXMLDesc },
{ "Resize", virtDBusStorageVolResize },
diff --git a/tests/test_storage.py b/tests/test_storage.py
index 1d0afe0..f342e77 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -132,6 +132,12 @@ class TestStoragePool(libvirttest.BaseTestClass):
class TestStorageVolume(libvirttest.BaseTestClass):
+def test_storage_vol_delete(self):
+test_storage_vol_path, test_storage_vol = self.test_storage_vol()
+interface_obj = dbus.Interface(test_storage_vol,
+ 'org.libvirt.StorageVol')
+interface_obj.Delete(0)
+
def test_storage_vol_properties_type(self):
_, obj = self.test_storage_vol()
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 12/15] Implement Wipe method for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 6 ++
src/storagevol.c| 26 ++
2 files changed, 32 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index fdde430..aed3f7a 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -30,5 +30,11 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolWipePattern"/>
+
+
+
diff --git a/src/storagevol.c b/src/storagevol.c
index 66f7c86..91d99e7 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -143,6 +143,31 @@ virtDBusStorageVolResize(GVariant *inArgs,
virtDBusUtilSetLastVirtError(error);
}
+static void
+virtDBusStorageVolWipe(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs G_GNUC_UNUSED,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+guint pattern;
+guint flags;
+
+g_variant_get(inArgs, "(uu)", , );
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+if (virStorageVolWipePattern(storageVol, pattern, flags) < 0)
+virtDBusUtilSetLastVirtError(error);
+}
+
static virtDBusGDBusPropertyTable virtDBusStorageVolPropertyTable[] = {
{ "Name", virtDBusStorageVolGetName, NULL },
{ "Key", virtDBusStorageVolGetKey, NULL },
@@ -153,6 +178,7 @@ static virtDBusGDBusPropertyTable
virtDBusStorageVolPropertyTable[] = {
static virtDBusGDBusMethodTable virtDBusStorageVolMethodTable[] = {
{ "GetXMLDesc", virtDBusStorageVolGetXMLDesc },
{ "Resize", virtDBusStorageVolResize },
+{ "Wipe", virtDBusStorageVolWipe },
{ 0 }
};
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 09/15] Implement StorageVolLookupByName method for StoragePool Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StoragePool.xml | 6 ++
src/storagepool.c| 34 ++
2 files changed, 40 insertions(+)
diff --git a/data/org.libvirt.StoragePool.xml b/data/org.libvirt.StoragePool.xml
index 51d65ab..161ade5 100644
--- a/data/org.libvirt.StoragePool.xml
+++ b/data/org.libvirt.StoragePool.xml
@@ -75,6 +75,12 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolLookupByName"/>
+
+
+
https://libvirt.org/html/libvirt-libvirt-storage.html#virStoragePoolUndefine"/>
diff --git a/src/storagepool.c b/src/storagepool.c
index c3fd0bf..55077ed 100644
--- a/src/storagepool.c
+++ b/src/storagepool.c
@@ -401,6 +401,39 @@ virtDBusStoragePoolStorageVolCreateXML(GVariant *inArgs,
*outArgs = g_variant_new("(o)", path);
}
+static void
+virtDBusStoragePoolStorageVolLookupByName(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath
G_GNUC_UNUSED,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStoragePool) storagePool = NULL;
+g_autoptr(virStorageVol) storageVol = NULL;
+g_autofree gchar *path = NULL;
+const gchar *name;
+
+g_variant_get(inArgs, "()", );
+
+storagePool = virtDBusStoragePoolGetVirStoragePool(connect, objectPath,
+ error);
+if (!storagePool)
+return;
+
+storageVol = virStorageVolLookupByName(storagePool, name);
+
+if (!storageVol)
+return virtDBusUtilSetLastVirtError(error);
+
+path = virtDBusUtilBusPathForVirStorageVol(storageVol,
+ connect->storageVolPath);
+
+*outArgs = g_variant_new("(o)", path);
+}
+
static void
virtDBusStoragePoolUndefine(GVariant *inArgs G_GNUC_UNUSED,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -442,6 +475,7 @@ static virtDBusGDBusMethodTable
virtDBusStoragePoolMethodTable[] = {
{ "ListStorageVolumes", virtDBusStoragePoolListAllVolumes },
{ "Refresh", virtDBusStoragePoolRefresh },
{ "StorageVolCreateXML", virtDBusStoragePoolStorageVolCreateXML },
+{ "StorageVolLookupByName", virtDBusStoragePoolStorageVolLookupByName },
{ "Undefine", virtDBusStoragePoolUndefine },
{ 0 }
};
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 07/15] Implement GetXMLDesc method for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 6 ++
src/storagevol.c| 29 +
tests/test_storage.py | 7 +++
3 files changed, 42 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index 03c15c2..c1fecf3 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -18,5 +18,11 @@
value="See
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetPath"/>
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetXMLDesc"/>
+
+
+
diff --git a/src/storagevol.c b/src/storagevol.c
index c65e11a..efe88d3 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -90,6 +90,34 @@ virtDBusStorageVolGetPath(const gchar *objectPath,
*value = g_variant_new("s", key);
}
+static void
+virtDBusStorageVolGetXMLDesc(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+g_autofree gchar *xml = NULL;
+guint flags;
+
+g_variant_get(inArgs, "(u)", );
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+xml = virStorageVolGetXMLDesc(storageVol, flags);
+if (!xml)
+return virtDBusUtilSetLastVirtError(error);
+
+*outArgs = g_variant_new("(s)", xml);
+}
+
static virtDBusGDBusPropertyTable virtDBusStorageVolPropertyTable[] = {
{ "Name", virtDBusStorageVolGetName, NULL },
{ "Key", virtDBusStorageVolGetKey, NULL },
@@ -98,6 +126,7 @@ static virtDBusGDBusPropertyTable
virtDBusStorageVolPropertyTable[] = {
};
static virtDBusGDBusMethodTable virtDBusStorageVolMethodTable[] = {
+{ "GetXMLDesc", virtDBusStorageVolGetXMLDesc },
{ 0 }
};
diff --git a/tests/test_storage.py b/tests/test_storage.py
index a430808..1d0afe0 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -141,6 +141,13 @@ class TestStorageVolume(libvirttest.BaseTestClass):
assert isinstance(props['Name'], dbus.String)
assert isinstance(props['Path'], dbus.String)
+def test_storage_vol_get_xml_description(self):
+_, test_storage_vol = self.test_storage_vol()
+interface_obj = dbus.Interface(test_storage_vol,
+ 'org.libvirt.StorageVol')
+xml = interface_obj.GetXMLDesc(0)
+assert isinstance(xml, dbus.String)
+
if __name__ == '__main__':
libvirttest.run()
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 02/15] Implement ListStorageVolumes for StoragePool Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StoragePool.xml | 6 ++
src/storagepool.c| 44
tests/test_storage.py| 8
3 files changed, 58 insertions(+)
diff --git a/data/org.libvirt.StoragePool.xml b/data/org.libvirt.StoragePool.xml
index e9d6b0e..764c9c1 100644
--- a/data/org.libvirt.StoragePool.xml
+++ b/data/org.libvirt.StoragePool.xml
@@ -57,6 +57,12 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStoragePoolListAllVolumes"/>
+
+
+
https://libvirt.org/html/libvirt-libvirt-storage.html#virStoragePoolRefresh"/>
diff --git a/src/storagepool.c b/src/storagepool.c
index 0da732f..11e356c 100644
--- a/src/storagepool.c
+++ b/src/storagepool.c
@@ -301,6 +301,49 @@ virtDBusStoragePoolGetXMLDesc(GVariant *inArgs,
*outArgs = g_variant_new("(s)", xml);
}
+static void
+virtDBusStoragePoolListAllVolumes(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStoragePool) storagePool = NULL;
+g_autoptr(virStorageVolPtr) storageVols = NULL;
+g_autofree gchar *xml = NULL;
+guint flags;
+gint nVols;
+GVariantBuilder builder;
+GVariant *gstorageVols;
+
+g_variant_get(inArgs, "(u)", );
+
+storagePool = virtDBusStoragePoolGetVirStoragePool(connect, objectPath,
+ error);
+if (!storagePool)
+return;
+
+nVols = virStoragePoolListAllVolumes(storagePool, , flags);
+if (nVols < 0)
+return virtDBusUtilSetLastVirtError(error);
+
+g_variant_builder_init(, G_VARIANT_TYPE("ao"));
+
+for (gint i = 0; i< nVols; i++) {
+g_autofree gchar *path = NULL;
+path = virtDBusUtilBusPathForVirStorageVol(storageVols[i],
+ connect->storageVolPath);
+
+g_variant_builder_add(, "o", path);
+}
+
+gstorageVols = g_variant_builder_end();
+*outArgs = g_variant_new_tuple(, 1);
+}
+
static void
virtDBusStoragePoolRefresh(GVariant *inArgs,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -363,6 +406,7 @@ static virtDBusGDBusMethodTable
virtDBusStoragePoolMethodTable[] = {
{ "Destroy", virtDBusStoragePoolDestroy },
{ "GetInfo", virtDBusStoragePoolGetInfo },
{ "GetXMLDesc", virtDBusStoragePoolGetXMLDesc },
+{ "ListStorageVolumes", virtDBusStoragePoolListAllVolumes },
{ "Refresh", virtDBusStoragePoolRefresh },
{ "Undefine", virtDBusStoragePoolUndefine },
{ 0 }
diff --git a/tests/test_storage.py b/tests/test_storage.py
index b9e7090..79e0c16 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -79,6 +79,14 @@ class TestStoragePool(libvirttest.BaseTestClass):
info = interface_obj.GetXMLDesc(0)
assert isinstance(info, dbus.String)
+def test_storage_pool_list_storage_volumes(self):
+_, test_storage_pool = self.test_storage_pool()
+interface_obj = dbus.Interface(test_storage_pool,
+ 'org.libvirt.StoragePool')
+storage_vols = interface_obj.ListStorageVolumes(0)
+assert isinstance(storage_vols, dbus.Array)
+assert len(storage_vols) == 0
+
def test_storage_pool_properties_type(self):
_, obj = self.test_storage_pool()
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 15/15] Implement StorageVolCreateXMLFrom method for StoragePool Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StoragePool.xml | 9 +
src/storagepool.c| 41
tests/test_storage.py| 21
3 files changed, 71 insertions(+)
diff --git a/data/org.libvirt.StoragePool.xml b/data/org.libvirt.StoragePool.xml
index 161ade5..0a324e6 100644
--- a/data/org.libvirt.StoragePool.xml
+++ b/data/org.libvirt.StoragePool.xml
@@ -75,6 +75,15 @@
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolCreateXMLFrom
+ Call with @key argument set to the key of the storage volume to
be cloned."/>
+
+
+
+
+
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolLookupByName"/>
diff --git a/src/storagepool.c b/src/storagepool.c
index 55077ed..854ca7d 100644
--- a/src/storagepool.c
+++ b/src/storagepool.c
@@ -401,6 +401,46 @@ virtDBusStoragePoolStorageVolCreateXML(GVariant *inArgs,
*outArgs = g_variant_new("(o)", path);
}
+static void
+virtDBusStoragePoolStorageVolCreateXMLFrom(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStoragePool) storagePool = NULL;
+g_autoptr(virStorageVol) storageVol = NULL;
+g_autoptr(virStorageVol) storageVolOld = NULL;
+gchar *key;
+gchar *xml;
+guint flags;
+g_autofree gchar *path = NULL;
+
+g_variant_get(inArgs, "()", , , );
+
+storagePool = virtDBusStoragePoolGetVirStoragePool(connect, objectPath,
+ error);
+if (!storagePool)
+return;
+
+storageVolOld = virStorageVolLookupByKey(connect->connection, key);
+if (!storageVolOld)
+return virtDBusUtilSetLastVirtError(error);
+
+storageVol = virStorageVolCreateXMLFrom(storagePool, xml, storageVolOld,
+flags);
+if (!storageVol)
+return virtDBusUtilSetLastVirtError(error);
+
+path = virtDBusUtilBusPathForVirStorageVol(storageVol,
+ connect->storageVolPath);
+
+*outArgs = g_variant_new("(o)", path);
+}
+
static void
virtDBusStoragePoolStorageVolLookupByName(GVariant *inArgs,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -475,6 +515,7 @@ static virtDBusGDBusMethodTable
virtDBusStoragePoolMethodTable[] = {
{ "ListStorageVolumes", virtDBusStoragePoolListAllVolumes },
{ "Refresh", virtDBusStoragePoolRefresh },
{ "StorageVolCreateXML", virtDBusStoragePoolStorageVolCreateXML },
+{ "StorageVolCreateXMLFrom", virtDBusStoragePoolStorageVolCreateXMLFrom },
{ "StorageVolLookupByName", virtDBusStoragePoolStorageVolLookupByName },
{ "Undefine", virtDBusStoragePoolUndefine },
{ 0 }
diff --git a/tests/test_storage.py b/tests/test_storage.py
index f342e77..8a0c4f6 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -130,6 +130,27 @@ class TestStoragePool(libvirttest.BaseTestClass):
path, _ = self.test_storage_vol()
assert isinstance(path, dbus.ObjectPath)
+def test_storage_pool_volume_create_xml_from(self):
+minimal_storage_vol_clone_xml = '''
+
+ clone.img
+ 1
+
+'''
+_, test_storage_vol = self.test_storage_vol()
+props = test_storage_vol.GetAll('org.libvirt.StorageVol',
+dbus_interface=dbus.PROPERTIES_IFACE)
+test_storage_vol_key = str(props['Key'])
+
+_, test_storage_pool = self.test_storage_pool()
+storage_pool_iface = dbus.Interface(test_storage_pool,
+'org.libvirt.StoragePool')
+
+new_vol_path =
storage_pool_iface.StorageVolCreateXMLFrom(minimal_storage_vol_clone_xml,
+
test_storage_vol_key,
+ 0)
+assert isinstance(new_vol_path, dbus.ObjectPath)
+
class TestStorageVolume(libvirttest.BaseTestClass):
def test_storage_vol_delete(self):
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 03/15] Implement StorageVolCreateXML method for StoragePool Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StoragePool.xml | 7 +++
src/storagepool.c| 34 ++
tests/libvirttest.py | 17 +
tests/test_storage.py| 4
4 files changed, 62 insertions(+)
diff --git a/data/org.libvirt.StoragePool.xml b/data/org.libvirt.StoragePool.xml
index 764c9c1..51d65ab 100644
--- a/data/org.libvirt.StoragePool.xml
+++ b/data/org.libvirt.StoragePool.xml
@@ -68,6 +68,13 @@
value="See
https://libvirt.org/html/libvirt-libvirt-storage.html#virStoragePoolRefresh"/>
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolCreateXML"/>
+
+
+
+
https://libvirt.org/html/libvirt-libvirt-storage.html#virStoragePoolUndefine"/>
diff --git a/src/storagepool.c b/src/storagepool.c
index 11e356c..c3fd0bf 100644
--- a/src/storagepool.c
+++ b/src/storagepool.c
@@ -368,6 +368,39 @@ virtDBusStoragePoolRefresh(GVariant *inArgs,
virtDBusUtilSetLastVirtError(error);
}
+static void
+virtDBusStoragePoolStorageVolCreateXML(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStoragePool) storagePool = NULL;
+g_autoptr(virStorageVol) storageVol = NULL;
+gchar *xml;
+guint flags;
+g_autofree gchar *path = NULL;
+
+g_variant_get(inArgs, "()", , );
+
+storagePool = virtDBusStoragePoolGetVirStoragePool(connect, objectPath,
+ error);
+if (!storagePool)
+return;
+
+storageVol = virStorageVolCreateXML(storagePool, xml, flags);
+if (!storageVol)
+return virtDBusUtilSetLastVirtError(error);
+
+path = virtDBusUtilBusPathForVirStorageVol(storageVol,
+ connect->storageVolPath);
+
+*outArgs = g_variant_new("(o)", path);
+}
+
static void
virtDBusStoragePoolUndefine(GVariant *inArgs G_GNUC_UNUSED,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -408,6 +441,7 @@ static virtDBusGDBusMethodTable
virtDBusStoragePoolMethodTable[] = {
{ "GetXMLDesc", virtDBusStoragePoolGetXMLDesc },
{ "ListStorageVolumes", virtDBusStoragePoolListAllVolumes },
{ "Refresh", virtDBusStoragePoolRefresh },
+{ "StorageVolCreateXML", virtDBusStoragePoolStorageVolCreateXML },
{ "Undefine", virtDBusStoragePoolUndefine },
{ 0 }
};
diff --git a/tests/libvirttest.py b/tests/libvirttest.py
index 3cd02ef..f65251a 100644
--- a/tests/libvirttest.py
+++ b/tests/libvirttest.py
@@ -100,6 +100,23 @@ class BaseTestClass():
obj = self.bus.get_object('org.libvirt', path)
return path, obj
+def test_storage_vol(self):
+minimal_storage_vol_xml = '''
+
+ sparse.img
+ 2
+
+/var/lib/virt/images/sparse.img
+
+
+'''
+_, test_storage_pool = self.test_storage_pool()
+interface_obj = dbus.Interface(test_storage_pool,
+ 'org.libvirt.StoragePool')
+path = interface_obj.StorageVolCreateXML(minimal_storage_vol_xml, 0)
+obj = self.bus.get_object('org.libvirt', path)
+return path, obj
+
class DomainEvent(IntEnum):
DEFINED = 0
diff --git a/tests/test_storage.py b/tests/test_storage.py
index 79e0c16..1cd1249 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -126,6 +126,10 @@ class TestStoragePool(libvirttest.BaseTestClass):
self.main_loop()
+def test_storage_pool_volume_create(self):
+path, _ = self.test_storage_vol()
+assert isinstance(path, dbus.ObjectPath)
+
if __name__ == '__main__':
libvirttest.run()
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 00/15] StorageVolume APIs
StorageVols logically should be nested under StoragePools, however this implementation does not nest the StorageVol interface under StorageVols. Reason is that the current gdbus.c implementation would not allow nesting of objects. Phrdina checked the posibility of rewritting the gdbus.c to support such requirements, but the effort stopped, since such implentation would interfere with the current lazy loading of objects. Thus, this solution appears to be the only viable. Katerina Koukiou (15): Introduce StorageVol Interface Implement ListStorageVolumes for StoragePool Interface Implement StorageVolCreateXML method for StoragePool Interface Implement Name property for StorageVol Interface Implement Key property for StorageVol Interface Implement Path property for StorageVol Interface Implement GetXMLDesc method for StorageVol Interface Implement StorageVolLookupByKey method for Connect Interface Implement StorageVolLookupByName method for StoragePool Interface Implement StorageVolLookupByPath method for Connect Interface Implement Resize method for StorageVol Interface Implement Wipe method for StorageVol Interface Implement GetInfo method for StorageVol Interface Implement Delete method for StorageVol Interface Implement StorageVolCreateXMLFrom method for StoragePool Interface data/Makefile.am | 3 +- data/org.libvirt.Connect.xml | 12 ++ data/org.libvirt.StoragePool.xml | 28 data/org.libvirt.StorageVol.xml | 51 +++ src/Makefile.am | 3 +- src/connect.c| 65 src/connect.h| 1 + src/storagepool.c| 153 +++ src/storagevol.c | 321 +++ src/storagevol.h | 9 ++ src/util.c | 35 + src/util.h | 16 ++ tests/libvirttest.py | 17 +++ tests/test_connect.py| 15 ++ tests/test_storage.py| 57 +++ 15 files changed, 784 insertions(+), 2 deletions(-) create mode 100644 data/org.libvirt.StorageVol.xml create mode 100644 src/storagevol.c create mode 100644 src/storagevol.h -- 2.15.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [dbus PATCH 01/15] Introduce StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/Makefile.am| 3 +-
data/org.libvirt.StorageVol.xml | 7 +++
src/Makefile.am | 3 +-
src/connect.c | 6 +++
src/connect.h | 1 +
src/storagevol.c| 96 +
src/storagevol.h| 9
src/util.c | 35 +++
src/util.h | 16 +++
9 files changed, 174 insertions(+), 2 deletions(-)
create mode 100644 data/org.libvirt.StorageVol.xml
create mode 100644 src/storagevol.c
create mode 100644 src/storagevol.h
diff --git a/data/Makefile.am b/data/Makefile.am
index fdec857..5688cab 100644
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -24,7 +24,8 @@ interfaces_files = \
org.libvirt.Network.xml \
org.libvirt.NWFilter.xml \
org.libvirt.Secret.xml \
- org.libvirt.StoragePool.xml
+ org.libvirt.StoragePool.xml \
+ org.libvirt.StorageVol.xml
interfacesdir = $(DBUS_INTERFACES_DIR)
interfaces_DATA = $(interfaces_files)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
new file mode 100644
index 000..c72c847
--- /dev/null
+++ b/data/org.libvirt.StorageVol.xml
@@ -0,0 +1,7 @@
+http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd;>
+
+
+
+
+
diff --git a/src/Makefile.am b/src/Makefile.am
index 22128c2..539e722 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -12,7 +12,8 @@ DAEMON_SOURCES = \
network.c network.h \
nwfilter.c nwfilter.h \
secret.c secret.h \
- storagepool.c storagepool.h
+ storagepool.c storagepool.h \
+ storagevol.c storagevol.h
EXTRA_DIST = \
$(DAEMON_SOURCES)
diff --git a/src/connect.c b/src/connect.c
index 75ae1cd..1090e3e 100644
--- a/src/connect.c
+++ b/src/connect.c
@@ -5,6 +5,7 @@
#include "nwfilter.h"
#include "secret.h"
#include "storagepool.h"
+#include "storagevol.h"
#include "util.h"
#include
@@ -1612,6 +1613,7 @@ virtDBusConnectFree(virtDBusConnect *connect)
g_free(connect->nwfilterPath);
g_free(connect->secretPath);
g_free(connect->storagePoolPath);
+g_free(connect->storageVolPath);
g_free(connect);
}
G_DEFINE_AUTOPTR_CLEANUP_FUNC(virtDBusConnect, virtDBusConnectFree);
@@ -1679,6 +1681,10 @@ virtDBusConnectNew(virtDBusConnect **connectp,
if (error && *error)
return;
+virtDBusStorageVolRegister(connect, error);
+if (error && *error)
+return;
+
*connectp = connect;
connect = NULL;
}
diff --git a/src/connect.h b/src/connect.h
index fe672ed..341dfc4 100644
--- a/src/connect.h
+++ b/src/connect.h
@@ -17,6 +17,7 @@ struct virtDBusConnect {
gchar *nwfilterPath;
gchar *secretPath;
gchar *storagePoolPath;
+gchar *storageVolPath;
virConnectPtr connection;
GMutex lock;
diff --git a/src/storagevol.c b/src/storagevol.c
new file mode 100644
index 000..dad7d11
--- /dev/null
+++ b/src/storagevol.c
@@ -0,0 +1,96 @@
+#include "storagevol.h"
+#include "util.h"
+
+#include
+
+static virtDBusGDBusPropertyTable virtDBusStorageVolPropertyTable[] = {
+{ 0 }
+};
+
+static virtDBusGDBusMethodTable virtDBusStorageVolMethodTable[] = {
+{ 0 }
+};
+
+static gchar **
+virtDBusStorageVolEnumerate(gpointer userData)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStoragePoolPtr) storagePools = NULL;
+gint numPools = 0;
+gint numVols = 0;
+gint numVolsTotal = 0;
+gint offset = 0;
+gchar **ret = NULL;
+
+if (!virtDBusConnectOpen(connect, NULL))
+return NULL;
+
+numPools = virConnectListAllStoragePools(connect->connection,
+ , 0);
+if (numPools < 0)
+return NULL;
+
+if (numPools == 0)
+return NULL;
+
+for (gint i = 0; i < numPools; i++) {
+g_autoptr(virStorageVolPtr) storageVols = NULL;
+
+numVols = virStoragePoolListAllVolumes(storagePools[i],
+ , 0);
+if (numVols < 0)
+return NULL;
+
+if (numVols == 0)
+return NULL;
+
+numVolsTotal += numVols;
+}
+
+ret = g_new0(gchar *, numVolsTotal + 1);
+
+for (gint i = 0; i < numPools; i++) {
+g_autoptr(virStorageVolPtr) storageVols = NULL;
+
+numVols = virStoragePoolListAllVolumes(storagePools[i],
+ , 0);
+if (numVols < 0)
+return NULL;
+
+if (numVols == 0)
+return NULL;
+
+for (gint j = 0; j < numVols; j++) {
+ret[offset] = virtDBusUtilBusPathForVirStorageVol(storageVols[j],
+
connect->storageVolPath);
+offset++;
+}
+}
+
+return ret;
+}
+
+static GDBusInterfaceInfo *interfaceInfo;
+
+void
+virtDBusStorageVolRegister(virtDBusConnect
[libvirt] [dbus PATCH 05/15] Implement Key property for StorageVol Interface
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.StorageVol.xml | 5 +
src/storagevol.c| 23 +++
tests/test_storage.py | 1 +
3 files changed, 29 insertions(+)
diff --git a/data/org.libvirt.StorageVol.xml b/data/org.libvirt.StorageVol.xml
index 3110b4f..3b36f3b 100644
--- a/data/org.libvirt.StorageVol.xml
+++ b/data/org.libvirt.StorageVol.xml
@@ -8,5 +8,10 @@
value="See
https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetName"/>
+
+ https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetKey"/>
+
+
diff --git a/src/storagevol.c b/src/storagevol.c
index 70bc2bc..82d81ab 100644
--- a/src/storagevol.c
+++ b/src/storagevol.c
@@ -46,8 +46,31 @@ virtDBusStorageVolGetName(const gchar *objectPath,
*value = g_variant_new("s", name);
}
+static void
+virtDBusStorageVolGetKey(const gchar *objectPath,
+ gpointer userData,
+ GVariant **value,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virStorageVol) storageVol = NULL;
+const gchar *key;
+
+storageVol = virtDBusStorageVolGetVirStorageVol(connect, objectPath,
+error);
+if (!storageVol)
+return;
+
+key = virStorageVolGetKey(storageVol);
+if (!key)
+return virtDBusUtilSetLastVirtError(error);
+
+*value = g_variant_new("s", key);
+}
+
static virtDBusGDBusPropertyTable virtDBusStorageVolPropertyTable[] = {
{ "Name", virtDBusStorageVolGetName, NULL },
+{ "Key", virtDBusStorageVolGetKey, NULL },
{ 0 }
};
diff --git a/tests/test_storage.py b/tests/test_storage.py
index bfdd084..7aa887d 100755
--- a/tests/test_storage.py
+++ b/tests/test_storage.py
@@ -137,6 +137,7 @@ class TestStorageVolume(libvirttest.BaseTestClass):
props = obj.GetAll('org.libvirt.StorageVol',
dbus_interface=dbus.PROPERTIES_IFACE)
+assert isinstance(props['Key'], dbus.String)
assert isinstance(props['Name'], dbus.String)
--
2.15.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] docs: formatdomain: Note the caveats for CPU policy option "force"
Eduardo Habkost has pointed out that the current documentation of libvirt's CPU feature policy "require" vs. "force" does not match QEMU's behaviour. Update the documentation by spelling out the QEMU version dependency and explain in which scenarios the usage of "policy = 'force'" is applicable or not. Signed-off-by: Kashyap Chamarthy --- Wordsmithing / corrections welcome. --- docs/formatdomain.html.in | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 6912762f28..4d6c3892ee 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1566,8 +1566,17 @@ force - The virtual CPU will claim the feature is supported regardless -of it being supported by host CPU. + The virtual CPU will claim the feature is supported + regardless of it being supported by host CPU -- this is only + true for QEMU version older than 2.9.0. I.e. when using the + CPU mode 'host-model', libvirt identifies which CPU features + to use by looking at host CPUID. For that to take effect, it + is mandatory to use force to tell libvirt that a + said CPU feature must be used despite it not existing in the + host -- this applicable only for a very limited set of CPU + features, such as 'x2apic', virt-ssbd' (for AMD CPUs). + However, when using QEMU 2.9.0 and above, there should + never be any need to use force. require Guest creation will fail unless the feature is supported by the host CPU or the hypervisor is able to emulate it. -- 2.17.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] AppArmor: allow virt-aa-helper read access to Nova's qcow backing files.
On 06/11/2018 02:01 PM, intrigeri wrote: > Hi, > > Michal Prívozník: >> On 06/11/2018 08:43 AM, Christian Ehrhardt wrote: >>> On Mon, Jun 11, 2018 at 8:12 AM, Michal Prívozník >>> wrote: Also, it would be nice if you can use your real name. >>> >>> We had the real name discussion before, but at least the S-O-B as agreed >>> last time should be added. > >> To my recollection even the usage of real name is a must (although we >> don't have any means to verify that). Anyway, the point being we don't >> allow any nicknames, TLAs (three letter acronyms), and so on. IANAL, but >> I guess the reason for that is to protect libvirt from any future lawsuits. > > FTR here are the relevant bits of the previous discussion about this > topic: > https://www.redhat.com/archives/libvir-list/2016-December/msg00841.html > https://www.redhat.com/archives/libvir-list/2016-December/msg00856.html > > Then the conclusion of that discussion has been applied consistently > (although implicitly): 4 commits of mine have been applied to Git > since Daniel wrote that this was a valid exception, and nobody raised > this topic again until today. > > Cheers, > Ah, okay. I've ACKed and pushed your patch. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [python PATCH 4/4] libvirt_charPtrUnwrap: remove unnecessary check of returned string
On Tue, Jun 12, 2018 at 07:16:41AM +0200, Pavel Hrdina wrote: Function libvirt_charPtrUnwrap() either fails or always sets the unwrapped string so there is no need to check it explicitly. Signed-off-by: Pavel Hrdina --- libvirt-override.c | 12 libvirt-utils.c| 10 +++--- 2 files changed, 7 insertions(+), 15 deletions(-) Reviewed-by: Ján Tomko Jano signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [python PATCH 3/4] libvirt-override: Reset exception if the error is ignored
On Tue, Jun 12, 2018 at 07:16:40AM +0200, Pavel Hrdina wrote: In virConnectCredCallbackWrapper() we ignore the error case of libvirt_charPtrUnwrap() function so we should also reset the exception. Signed-off-by: Pavel Hrdina --- libvirt-override.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Ján Tomko Jano signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [python PATCH 2/4] typewrappers: Fix libvirt_charPtrUnwrap to set an exception if it fails
On Tue, Jun 12, 2018 at 07:16:39AM +0200, Pavel Hrdina wrote: If the function fails it should always set an exception. Signed-off-by: Pavel Hrdina --- typewrappers.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Ján Tomko Jano signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [python PATCH 1/4] libvirt-utils: remove unused py_str function
On Tue, Jun 12, 2018 at 07:16:38AM +0200, Pavel Hrdina wrote: Commit <57a160b5248ba47d4e1c9d22d95847dad8e0524f> removed last usage but did not remove the function itself. Signed-off-by: Pavel Hrdina --- libvirt-utils.c | 14 -- libvirt-utils.h | 1 - 2 files changed, 15 deletions(-) Beautiful diffstat. Reviewed-by: Ján Tomko Jano signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [dbus PATCH] util: Introduce virtDBusUtil(En|De)codeStr helpers
On Mon, Jun 11, 2018 at 04:21:47PM +0200, Pavel Hrdina wrote: > D-Bus object path element can contain only [a-zA-Z0-9_] characters so > we need to encode existing unique IDs. In case of UUID it's simple, we > just change '-' into '_' but in case of storage volumes we need to use > 'key' which is arbitrary string. > > This helpers encode the string using this algorithm: > > [a-zA-Z0-9] > [a-zA-Z0-9] > anything else > _XX where XX is hex representation > > Signed-off-by: Pavel Hrdina > --- > .gitignore| 4 ++- > src/util.c| 64 +++ > src/util.h| 6 + > tests/Makefile.am | 20 +++ > tests/test_util.c | 47 ++ > 5 files changed, 140 insertions(+), 1 deletion(-) > create mode 100644 tests/test_util.c Reviewed-by: Katerina Koukiou signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] qemu: Fixing uninitialised variable inside virQEMUDriverConfigLoadFile.
To save precious space in the commit summary: s/Fixing/fix/ s/inside/in/ And most importantly, I deleted the period at the end. On Mon, Jun 11, 2018 at 05:35:33PM -0300, Julio Faracco wrote: Since virConfGetValueBool() can return earlier, the parameter 'value' might be not initialised properly inside this method. Another proof: Valgrind is returning this error during the libvirtd daemon startup: ==16199== Conditional jump or move depends on uninitialised value(s) ==16199==at 0x27FFFEF4: virQEMUDriverConfigLoadFile (qemu_conf.c:809) ==16199==by 0x2807665C: qemuStateInitialize (qemu_driver.c:654) ==16199==by 0x5535428: virStateInitialize (libvirt.c:662) ==16199==by 0x12AED8: daemonRunStateInit (remote_daemon.c:802) ==16199==by 0x536DE18: virThreadHelper (virthread.c:206) ==16199==by 0x6CB36DA: start_thread (pthread_create.c:463) ==16199==by 0x6FEC88E: clone (clone.S:95) Signed-off-by: Julio Faracco --- src/qemu/qemu_conf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Ján Tomko And pushed. Jano signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
