August 2016 - Devel - libvirt List Archives

[libvirt] RFC: Limited dynamic ownership
by Martin Kletzander 29 Aug '16

29 Aug '16

Hi everyone, so there was an idea about limiting the relabelling of images that libvirt does. And I'm taking the liberty of pitching my idea how to approach this. I feel like it's pretty simple thing and there's not much to talk about, but a) I could've missed something and b) you might hate the way I approach it. The idea is to extend the seclabel XML, for example: <seclabel type='dynamic' model='dac' relabel='whitelist'> <path>/var/lib/libvirt/images</path> <path>/data/virt-stuff</path> </seclabel> Either we allow 'relabel' to be set to 'whitelist' or add a new attribute with a name like 'mode' or something, which will control how we relabel the files (actually relabel='no' can mean 'whitelist' and relabel='yes' can mean blacklist without adding anything there). After that you can specify what paths are (dis)allowed to be labelled. Actually thinking about it I like the following the most: <seclabel type='dynamic' model='dac' relabel='no'> <whitelist path='/data'/> <blacklist path='/data/private/non-virt/stuff'/> </seclabel> which I believe is pretty explanatory. Feel free to ask if it's not. And let me know what you think. And have a nice day!!! Martin

2 4

[libvirt] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration
by Philipp Hahn 29 Aug '16

29 Aug '16

Hello, If my understanding of migration/snapshots is correct, the target/loading VM must be a clone of the source/saving VM, that is have the same devices, RAM/PCI layout, etc. In the past I have had several issues with Qemu, when the distribution (Debian) updates their packaging of SeaBIOS/iPXE/VgaROM, which changes the the next/previous power-of-2 size and thus changes the PCI layout, preventing me from loading old snapshots. As the BIOS file is provided externally, it is prone to such (accidental) updates. As (AFAIK) libvirt does not track the Qemu version, BIOS files inside its XML data, there's always the danger of making snapshots invalid by updating Qemu and the BIOS files. Some questions: 1. Does Qemu use ROM shadowing, that is copying the ROM to RAM? This makes sense on real HW as ROMs are a low slower than RAM. In that case the content of the "ROM" would already be contained inside the VM-State and it would be enough to provide an "empty ROM file of the right size". 2. If Qemu does no ROM shadowing, what happens if I suspend a VM while executing ROM or SMM code and then doing an SeaBIOS update? (my DOS-assembler knowledge is quiet old nowadays) 3. How do others handle long-term snapshots? Just say "good-bye" to your old snapshots when upgrading to a newer Qemu version or keeping the old, probably unmaintained and vulnerable Qemu/BIOS binaries until the end-of-time? Thanks in advance Philipp -- Philipp Hahn Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str. 1 D-28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 hahn(a)univention.de http://www.univention.de/ Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876

2 1

[libvirt] [PATCH] bhyve: fix disks address allocation
by Roman Bogorodskiy 29 Aug '16

29 Aug '16

As bhyve currently doesn't use controller addressing and simply uses 1 implicit controller for 1 disk device, the scheme looks the following: pci addrees -> (implicit controller) -> disk device So in fact we identify disk devices by pci address of implicit controller and just pass it this way to bhyve in a form: -s pci_addr,ahci-(cd|hd),/path/to/disk Therefore, we cannot use virDeviceInfoPCIAddressWanted() because it does not expect that disk devices might need PCI address assignment. As a result, if a disk was specified without address, it will not be generated and domain will to start. Until proper controller addressing is not implemented in the bhyve driver, force each disk to have PCI address generated if it was not specified by user. --- src/bhyve/bhyve_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/bhyve/bhyve_device.c b/src/bhyve/bhyve_device.c index 8373a5f..ca30e9f 100644 --- a/src/bhyve/bhyve_device.c +++ b/src/bhyve/bhyve_device.c @@ -107,7 +107,8 @@ bhyveAssignDevicePCISlots(virDomainDefPtr def, } for (i = 0; i < def->ndisks; i++) { - if (!virDeviceInfoPCIAddressWanted(&def->disks[i]->info)) + if (def->disks[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI && + !virPCIDeviceAddressIsEmpty(&def->disks[i]->info.addr.pci)) continue; if (virDomainPCIAddressReserveNextSlot(addrs, &def->disks[i]->info, -- 2.9.2

2 2

[libvirt] [PATCH 0/6] auto-assign addresses when <address type='pci'/> is specified
by Laine Stump 28 Aug '16

28 Aug '16

This is an alternative to Cole's series that permits <address type='pci'/> to force assignment of a PCI address, which is particularly useful on platforms that could connect the same device in different ways (e.g. aarch64/virt). Here is Cole's last iteration of the series: https://www.redhat.com/archives/libvir-list/2016-May/msg01088.html I had expressed a dislike of the "auto_allocate" flag that his series temporarily adds to the address (while simultaneously changing the address type to NONE) and suggested just changing all the necessary places to check for a valid PCI address instead of just checking the address type. He replied that this wasn't as simple as it looked, so I decided to try it; turns out he's right. But I still like this method better because it's not playing tricks with the address type, or adding a temporary private attribute to what should be pure config data. Your opinion may vary though :-) Note that patch 5/6 incorporates the same test case that Cole used in his penultimate patch, and I've added his patch to check the case of aarch64 at the end as well. Cole Robinson (1): tests: qemu: test <address type='pci'/> with aarch64 Laine Stump (5): conf: move virDomainDeviceInfo definition from domain_conf.h to device_conf.h conf: new functions to check if PCI address is wanted/present conf: allow type='pci' addresses with no address attributes specified bhyve: auto-assign addresses when <address type='pci'/> is specified qemu: auto-assign addresses when <address type='pci'/> is specified docs/schemas/basictypes.rng | 8 +- src/bhyve/bhyve_device.c | 10 +- src/conf/device_conf.c | 6 +- src/conf/device_conf.h | 132 ++++++++++++++++++++- src/conf/domain_addr.c | 2 +- src/conf/domain_conf.c | 13 +- src/conf/domain_conf.h | 129 -------------------- src/qemu/qemu_domain_address.c | 64 +++++----- ...l2argv-aarch64-virtio-pci-manual-addresses.args | 4 +- ...ml2argv-aarch64-virtio-pci-manual-addresses.xml | 5 + .../qemuxml2argv-pci-autofill-addr.args | 25 ++++ .../qemuxml2argv-pci-autofill-addr.xml | 35 ++++++ tests/qemuxml2argvtest.c | 1 + ...2xmlout-aarch64-virtio-pci-manual-addresses.xml | 5 + .../qemuxml2xmlout-pci-autofill-addr.xml | 41 +++++++ tests/qemuxml2xmltest.c | 1 + 16 files changed, 298 insertions(+), 183 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-autofill-addr.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-autofill-addr.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pci-autofill-addr.xml -- 2.5.5

4 21

[libvirt] [PATCH] docs: Add missing / to closing tag
by Christophe Fergeau 26 Aug '16

26 Aug '16

The iothread example for virtio-scsi should be <driver iothread='4'/> rather than <driver iothread='4'> for the XML to be valid. --- I've already pushed this under the docs/trivial rule. Christophe docs/formatdomain.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index f1dadc6..8c15a73 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -3166,7 +3166,7 @@ <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <controller type='scsi' index='0' model='virtio-scsi'> - <driver iothread='4'> + <driver iothread='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> </controller> ... -- 2.7.4

1 0

[libvirt] [PATCH 0/6] Fix a few issues introduced by adding vcpu hotplug
by Peter Krempa 26 Aug '16

26 Aug '16

Peter Krempa (6): virsh: vcpuinfo: Report vcpu number from the structure rather than it's position qemu: driver: Fix qemuDomainHelperGetVcpus for sparse vcpu topologies doc: clarify documentation for vcpu order conf: Don't validate vcpu count in XML parser qemu: driver: Validate configuration when setting maximum vcpu count conf: Fix build with picky GCC docs/formatdomain.html.in | 7 ++++--- src/conf/domain_conf.c | 13 ++++--------- src/qemu/qemu_driver.c | 23 ++++++++++++++++++----- tools/virsh-domain.c | 3 ++- 4 files changed, 28 insertions(+), 18 deletions(-) -- 2.8.2

2 12

[libvirt] [PATCH] vz: update domain cache after device updates
by Nikolay Shirokovskiy 26 Aug '16

26 Aug '16

--- src/vz/vz_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index b34fe33..f223794 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -1694,6 +1694,9 @@ static int vzDomainUpdateDeviceFlags(virDomainPtr domain, if (prlsdkUpdateDevice(driver, dom, dev) < 0) goto cleanup; + if (prlsdkUpdateDomain(driver, dom) < 0) + goto cleanup; + ret = 0; cleanup: -- 1.8.3.1

3 2

[libvirt] [PATCH] vz: fixed race in vzDomainAttach/DettachDevice
by Olga Krishtal 26 Aug '16

26 Aug '16

While dettaching/attaching device in OpenStack, nova calls vzDomainDettachDevice twice, because the update of the internal configuration of the ct comes a bit latter than the update event. As the result, we suffer from the second call to dettach the same device. Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com> --- src/vz/vz_sdk.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index 68dd5b5..9fbf968 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -3594,6 +3594,12 @@ prlsdkAttachDevice(vzDriverPtr driver, return -1; } + if (prlsdkUpdateDomain(driver, dom) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to save new config")); + return -1; + } + job = PrlVm_CommitEx(privdom->sdkdom, PVCF_DETACH_HDD_BUNDLE); if (PRL_FAILED(waitDomainJob(job, dom))) return -1; @@ -3661,6 +3667,12 @@ prlsdkDetachDevice(vzDriverPtr driver, goto cleanup; } + if (prlsdkUpdateDomain(driver, dom) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to save new config")); + goto cleanup; + } + job = PrlVm_CommitEx(privdom->sdkdom, PVCF_DETACH_HDD_BUNDLE); if (PRL_FAILED(waitDomainJob(job, dom))) goto cleanup; -- 1.8.3.1

3 2

[libvirt] [PATCH] vz: getting bus type for containers
by Mikhail Feoktistov 26 Aug '16

26 Aug '16

We should query bus type for containers too, like for VM. In openstack we add volume disk like SCSI, so we can't hardcode SATA bus. --- src/vz/vz_sdk.c | 32 +++++++++++++------------------- 1 file changed, 13 insertions(+), 19 deletions(-) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index f81b320..c4a1c3d 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -47,7 +47,7 @@ VIR_LOG_INIT("parallels.sdk"); static PRL_HANDLE prlsdkFindNetByMAC(PRL_HANDLE sdkdom, virMacAddrPtr mac); static PRL_HANDLE -prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool isCt); +prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk); /* * Log error description @@ -547,7 +547,7 @@ prlsdkAddDomainVideoInfoVm(PRL_HANDLE sdkdom, virDomainDefPtr def) } static int -prlsdkGetDiskId(PRL_HANDLE disk, bool isCt, int *bus, char **dst) +prlsdkGetDiskId(PRL_HANDLE disk, int *bus, char **dst) { PRL_RESULT pret; PRL_UINT32 pos, ifType; @@ -555,13 +555,8 @@ prlsdkGetDiskId(PRL_HANDLE disk, bool isCt, int *bus, char **dst) pret = PrlVmDev_GetStackIndex(disk, &pos); prlsdkCheckRetExit(pret, -1); - /* Let physical devices added to CT look like SATA disks */ - if (isCt) { - ifType = PMS_SATA_DEVICE; - } else { - pret = PrlVmDev_GetIfaceType(disk, &ifType); - prlsdkCheckRetExit(pret, -1); - } + pret = PrlVmDev_GetIfaceType(disk, &ifType); + prlsdkCheckRetExit(pret, -1); switch (ifType) { case PMS_IDE_DEVICE: @@ -632,7 +627,7 @@ prlsdkGetDiskInfo(vzDriverPtr driver, if (*buf != '\0' && virDomainDiskSetSource(disk, buf) < 0) goto cleanup; - if (prlsdkGetDiskId(prldisk, isCt, &disk->bus, &disk->dst) < 0) + if (prlsdkGetDiskId(prldisk, &disk->bus, &disk->dst) < 0) goto cleanup; if (virDiskNameToBusDeviceIndex(disk, &busIdx, &devIdx) < 0) @@ -1598,7 +1593,7 @@ prlsdkBootOrderCheck(PRL_HANDLE sdkdom, PRL_DEVICE_TYPE sdkType, int sdkIndex, goto cleanup; } - if (prlsdkGetDiskId(dev, false, &bus, &dst) < 0) + if (prlsdkGetDiskId(dev, &bus, &dst) < 0) goto cleanup; if (!(bus == disk->bus && STREQ(disk->dst, dst))) @@ -3409,7 +3404,6 @@ prlsdkFindNetByMAC(PRL_HANDLE sdkdom, virMacAddrPtr mac) static int prlsdkConfigureDisk(vzDriverPtr driver, PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, - bool isCt, bool create) { PRL_RESULT pret; @@ -3432,7 +3426,7 @@ static int prlsdkConfigureDisk(vzDriverPtr driver, pret = PrlVmCfg_CreateVmDev(sdkdom, devType, &sdkdisk); prlsdkCheckRetGoto(pret, cleanup); } else { - sdkdisk = prlsdkGetDisk(sdkdom, disk, isCt); + sdkdisk = prlsdkGetDisk(sdkdom, disk); if (sdkdisk == PRL_INVALID_HANDLE) return -1; } @@ -3499,7 +3493,7 @@ static int prlsdkConfigureDisk(vzDriverPtr driver, } static PRL_HANDLE -prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool isCt) +prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk) { PRL_RESULT pret; PRL_UINT32 num; @@ -3521,7 +3515,7 @@ prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool isCt) pret = PrlVmCfg_GetDevByType(sdkdom, devType, i, &sdkdisk); prlsdkCheckRetGoto(pret, error); - if (prlsdkGetDiskId(sdkdisk, isCt, &bus, &dst) < 0) + if (prlsdkGetDiskId(sdkdisk, &bus, &dst) < 0) goto error; if (disk->bus == bus && STREQ(disk->dst, dst)) { @@ -3560,7 +3554,7 @@ prlsdkAttachDevice(vzDriverPtr driver, switch (dev->type) { case VIR_DOMAIN_DEVICE_DISK: if (prlsdkConfigureDisk(driver, privdom->sdkdom, - dev->data.disk, IS_CT(dom->def), true) < 0) + dev->data.disk, true) < 0) return -1; break; @@ -3618,7 +3612,7 @@ prlsdkDetachDevice(vzDriverPtr driver, switch (dev->type) { case VIR_DOMAIN_DEVICE_DISK: - sdkdev = prlsdkGetDisk(privdom->sdkdom, dev->data.disk, IS_CT(dom->def)); + sdkdev = prlsdkGetDisk(privdom->sdkdom, dev->data.disk); if (sdkdev == PRL_INVALID_HANDLE) goto cleanup; @@ -3688,7 +3682,7 @@ prlsdkUpdateDevice(vzDriverPtr driver, switch (dev->type) { case VIR_DOMAIN_DEVICE_DISK: if (prlsdkConfigureDisk(driver, privdom->sdkdom, dev->data.disk, - IS_CT(dom->def), false) < 0) + false) < 0) return -1; break; @@ -3981,7 +3975,7 @@ prlsdkDoApplyConfig(vzDriverPtr driver, for (i = 0; i < def->ndisks; i++) { if (prlsdkConfigureDisk(driver, sdkdom, def->disks[i], - IS_CT(def), true) < 0) + true) < 0) goto error; } -- 1.8.3.1

3 2

[libvirt] [PATCH 1/2] vz: implicitly support additional migration flags
by Pavel Glushchak 26 Aug '16

26 Aug '16

* Added VIR_MIGRATE_LIVE, VIR_MIGRATE_UNDEFINE_SOURCE and VIR_MIGRATE_PERSIST_DEST to supported migration flags Signed-off-by: Pavel Glushchak <pglushchak(a)virtuozzo.com> --- src/vz/vz_driver.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index b34fe33..7a12632 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -2887,8 +2887,11 @@ vzEatCookie(const char *cookiein, int cookieinlen, unsigned int flags) goto cleanup; } -#define VZ_MIGRATION_FLAGS (VIR_MIGRATE_PAUSED | \ - VIR_MIGRATE_PEER2PEER) +#define VZ_MIGRATION_FLAGS (VIR_MIGRATE_PAUSED | \ + VIR_MIGRATE_PEER2PEER | \ + VIR_MIGRATE_LIVE | \ + VIR_MIGRATE_UNDEFINE_SOURCE | \ + VIR_MIGRATE_PERSIST_DEST) #define VZ_MIGRATION_PARAMETERS \ VIR_MIGRATE_PARAM_DEST_XML, VIR_TYPED_PARAM_STRING, \ -- 2.7.4

2 4