From patchwork Mon Oct 7 21:49:14 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cole Robinson X-Patchwork-Id: 175415 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp4845674ill; Mon, 7 Oct 2019 14:49:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSIzWGKTVFonBK1BAs/e5FhY5ONNWdKnB0H+vbEmIDuOzfM92uC+ZYl1pu4IAL5CoVNEZr X-Received: by 2002:a6b:254:: with SMTP id 81mr4459234ioc.17.1570484969145; Mon, 07 Oct 2019 14:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570484969; cv=none; d=google.com; s=arc-20160816; b=QosrsQCyGHp5w+/puNmdFxALUgVyo/NBe9cH07n73mbmTDKfvezG47E0DdF6GT+wr8 IditPorLhSZLAFf7bstNO9EWk4arJHeBZlsbxSJAIDyGfK4aQibbMdDIVd5kEWvUza9j 0G3TvSCNFBVjtBNr2C2dr68zkpQCo9iJujINVMKdB/CGprzQ3iyN8dzPZTAduB0+lxYM J4oMR2xHhc40FeDz9xVvIPA4aeA6TYYJXvEnkmrV0c8w/0iHPmyMB5jv+u+ePR++pmbk 532LYAyaWT69gtqJxvN3ZJ2IT99bimwFUgINwbF6o/VZR+woJMzDlzarzYJYZLV/d5kp Qgrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:sender:content-transfer-encoding:list-subscribe:list-help :list-post:list-archive:list-unsubscribe:list-id:precedence:subject :mime-version:message-id:date:to:from:delivered-to; bh=p2SsECxz/bRZcvlSwAyxkJzH/fd6AnHR0B3ALtKHL3E=; b=ODqBJ0Kxwgi3MFe4l2dIqUmUhKdTARcLAVZ8DM66hfoyARSYcWYWAuANBOCUPs7rqb WggrHKkEUqSb7zd+Lv1P4DYb1MfH4SgPEr4uXf/5i7P6IpiKASqTzYvFiZD52QwypHmL NX34Uzk6GLHALiyfckNb3NMDV+YKtj3lBdN6qxUyB+NtbszMnODYeeerCMuPXWgWrSoN VtUB1NtIVE1wxaLYjPaUV/FTqkgAAmYS4KLKO2I7rAuGXJTm4AFb2d6f5azxNQ+fCgFJ QMquJjYXGEVh86fHSc7tySol6EwPvAunDt+i3PGqWrgJ5J2ThjIHcoE+KPcNu55rVhA4 +lpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of libvir-list-bounces@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id i10si16934535ioh.146.2019.10.07.14.49.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Oct 2019 14:49:29 -0700 (PDT) Received-SPF: pass (google.com: domain of libvir-list-bounces@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Authentication-Results: mx.google.com; spf=pass (google.com: domain of libvir-list-bounces@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 006ED10C093B; Mon, 7 Oct 2019 21:49:28 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D026B60A35; Mon, 7 Oct 2019 21:49:27 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 989021803518; Mon, 7 Oct 2019 21:49:22 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x97LnLiE014506 for ; Mon, 7 Oct 2019 17:49:21 -0400 Received: by smtp.corp.redhat.com (Postfix) id 99C395C223; Mon, 7 Oct 2019 21:49:21 +0000 (UTC) Delivered-To: libvir-list@redhat.com Received: from worklaptop.redhat.com (ovpn-123-156.rdu2.redhat.com [10.10.123.156]) by smtp.corp.redhat.com (Postfix) with ESMTP id 361DD5C219; Mon, 7 Oct 2019 21:49:18 +0000 (UTC) From: Cole Robinson To: libvir-list@redhat.com Date: Mon, 7 Oct 2019 17:49:14 -0400 Message-Id: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 00/30] storagefile, security: qcow2 data_file support X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.66]); Mon, 07 Oct 2019 21:49:28 +0000 (UTC) This series is the first steps to teaching libvirt about qcow2 data_file support, aka external data files or qcow2 external metadata. A bit about the feature: it was added in qemu 4.0. It essentially creates a two part image file: a qcow2 layer that just tracks the image metadata, and a separate data file which is stores the VM disk contents. AFAICT the driving use case is to keep a fully coherent raw disk image on disk, and only use qcow2 as an intermediate metadata layer when necessary, for things like incremental backup support. The original qemu patch posting is here: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg07496.html For testing, you can create a new qcow2+raw data_file image from an existing image, like: qemu-img convert -O qcow2 \ -o data_file=NEW.raw,data_file_raw=yes EXISTING.raw NEW.qcow2 The goal of this series is to teach libvirt enough about this case so that we can correctly relabel the data_file on VM startup/shutdown. The main functional changes are * Teach storagefile how to parse out data_file from the qcow2 header * Store the raw string as virStorageSource->externalDataStoreRaw * Track that as its out virStorageSource in externalDataStore * dac/selinux relabel externalDataStore as needed >From libvirt's perspective, externalDataStore is conceptually pretty close to a backingStore, but the main difference is its read/write permissions should match its parent image, rather than being readonly like backingStore. This series has only been tested on top of the -blockdev enablement series, but I don't think it actually interacts with that work at the moment. Future work: * Exposing this in the runtime XML. We need to figure out an XML schema. It will reuse virStorageSource obviously, but the main thing to figure out is probably 1) what the top element name should be ('dataFile' maybe?), 2) where it sits in the XML hierarchy (under or under I guess) * Exposing this on the qemu -blockdev command line. Similar to how in the blockdev world we are explicitly putting the disk backing chain on the command line, we can do that for data_file too. Then like persistent XML the user will have the power to overwrite the data_file location for an individual VM run. * Figure out how we expect ovirt/rhev to be using this at runtime. Possibly taking a running VM using a raw image, doing blockdev-* magic to pivot it to qcow2+raw data_file, so it can initiate incremental backup on top of a previously raw only VM? Known issues: * In the qemu driver, the qcow2 image metadata is only parsed in -blockdev world if no is specified in the persistent XML. So basically if there's a listed, we never parse the qcow2 header and detect the presence of data_file. Fixable I'm sure but I didn't look into it much yet. Most of this is cleanups and refactorings to simplify the actual functional changes. Cole Robinson (30): storagefile: Make GetMetadataInternal static storagefile: qcow1: Check for BACKING_STORE_OK storagefile: qcow1: Fix check for empty backing file storagefile: qcow1: Let qcowXGetBackingStore fill in format storagefile: Check version to determine if qcow2 or not storagefile: Drop now unused isQCow2 argument storagefile: Use qcowXGetBackingStore directly storagefile: Push 'start' into qcow2GetBackingStoreFormat storagefile: Push extension_end calc to qcow2GetBackingStoreFormat storagefile: Rename qcow2GetBackingStoreFormat storagefile: Rename qcow2GetExtensions 'format' argument storagefile: Fix backing format \0 check storagefile: Add externalDataStoreRaw member storagefile: Parse qcow2 external data file storagefile: Fill in meta->externalDataStoreRaw storagefile: Don't access backingStoreRaw directly in FromBackingRelative storagefile: Split out virStorageSourceNewFromChild storagefile: Add externalDataStore member storagefile: Fill in meta->externalDataStore security: dac: Drop !parent handling in SetImageLabelInternal security: dac: Add is_toplevel to SetImageLabelInternal security: dac: Restore image label for externalDataStore security: dac: break out SetImageLabelRelative security: dac: Label externalDataStore security: selinux: Simplify SetImageLabelInternal security: selinux: Drop !parent handling in SetImageLabelInternal security: selinux: Add is_toplevel to SetImageLabelInternal security: selinux: Restore image label for externalDataStore security: selinux: break out SetImageLabelRelative security: selinux: Label externalDataStore src/libvirt_private.syms | 1 - src/security/security_dac.c | 63 +++++-- src/security/security_selinux.c | 97 +++++++---- src/util/virstoragefile.c | 281 ++++++++++++++++++++------------ src/util/virstoragefile.h | 11 +- 5 files changed, 290 insertions(+), 163 deletions(-) -- 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list Reviewed-by: Michal Privoznik