From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EB1FC3F2D2 for ; Sat, 29 Feb 2020 00:21:16 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 55919246AF for ; Sat, 29 Feb 2020 00:21:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55919246AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:55332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7psZ-0004Dl-7A for qemu-devel@archiver.kernel.org; Fri, 28 Feb 2020 19:21:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59247) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7pry-0003mI-PE for qemu-devel@nongnu.org; Fri, 28 Feb 2020 19:20:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7prx-0001co-FC for qemu-devel@nongnu.org; Fri, 28 Feb 2020 19:20:38 -0500 Received: from indium.canonical.com ([91.189.90.7]:42180) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j7prx-0001bx-9q for qemu-devel@nongnu.org; Fri, 28 Feb 2020 19:20:37 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1j7prv-0006o2-QD for ; Sat, 29 Feb 2020 00:20:35 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 8F2382E8076 for ; Sat, 29 Feb 2020 00:20:35 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Feb 2020 00:14:40 -0000 From: maro <1759522@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Tags: qemu-img X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: atmgnd maro the.netadmin voltagex X-Launchpad-Bug-Reporter: Zixuan Wang (the.netadmin) X-Launchpad-Bug-Modifier: maro (maro) References: <152222836105.21062.2375148895134658603.malonedeb@chaenomeles.canonical.com> Message-Id: <158293528081.6414.785953810547926980.malone@chaenomeles.canonical.com> Subject: [Bug 1759522] Re: windows qemu-img create vpc/vhdx error X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="e0878392dc799b267dea80578fa65500a5d74155"; Instance="production-secrets-lazr.conf" X-Launchpad-Hash: 09c50ef14dcea4d237e195698d4372200c3d0cca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 91.189.90.7 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1759522 <1759522@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" I also discovered just a few days ago the problem that sparse VHD/VHDX image files are not being accepted by Windows. It appears that qemu-img on Windows always tries to create images as sparse files. Only in some cases (e.g. when operating on a NTFS file system) will the file actually be a sparse file. Being a sparse file seems to be no issue when using these file with QEMU itself. Most file formats that qemu-img is able to create will be unknown to Windows own tools, but the one exception are VHD/VHDX files. As long as a file carries the sparse attribute it will be "un- acceptable" to the Windows tools (e.g. diskpart/diskmgmt). As a crude work-around I've noticed that a copy of such a file will have "lost" the sparse attribute, and therefore can be mounted. Likewise any copy of a file created on a different system will not be a sparse file (and hence the issue does not arise). I'm attaching a log file (with a few comments) of some steps that demonstrate the problem, and how I worked around it. The test was done with qemu-img v4.1.0, but I'm fairly certain that this issue has been present since "forever" (and a quick re-test with v4.2.0 confirmed that it has not "gone away"). So, a simple work-around exists, but I see myself unable to suggest a patch. I guess the patch should be specific to prevent the creation of sparse VHD/VHDX files on Windows. But from the superficial reading I did I could not work out whether the image format information would be available in 'raw_co_create()' (of: 'block/file-win32.c'). ** Attachment added: "sparse-VHD_issue.log" https://bugs.launchpad.net/qemu/+bug/1759522/+attachment/5332081/+files/= sparse-VHD_issue.log -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1759522 Title: windows qemu-img create vpc/vhdx error Status in QEMU: New Bug description: On windows, using qemu-img (version 2.11.90) to create vpc/vhdx virtual disk tends to fail. Here's the way to reproduce: 1. Install qemu-w64-setup-20180321.exe 2. Use `qemu-img create -f vhdx -o subformat=3Dfixed disk.vhdx 512M` to c= reate a vhdx: Formatting 'disk.vhdx', fmt=3Dvhdx size=3D536870912 log_size=3D1048576= block_size=3D0 subformat=3Dfixed 3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk si= ze` is incorrect): image: disk.vhdx file format: vhdx virtual size: 512M (536870912 bytes) disk size: 1.4M cluster_size: 8388608 4. On Windows 10 (V1709), double click disk.vhdx gives an error: Make sure the file is in an NTFS volume and isn't in a compressed fold= er or volume. Using Disk Management -> Action -> Attach VHD gives an error: The requested operation could not be completed due to a virtual disk s= ystem limitation. Virtual hard disk files must be uncompressed and uneccryp= ted and must not be sparse. Comparison with Windows 10 created VHDX: 1. Using Disk Management -> Action -> Create VHD: File name: win.vhdx Virtual hard disk size: 512MB Virtual hard disk format: VHDX Virtual hard disk type: Fixed size 2. Detach VHDX 3. Execute `qemu-img info win.vhdx` gives the result: image: win.vhdx file format: vhdx virtual size: 512M (536870912 bytes) disk size: 516M cluster_size: 33554432 Comparison with qemu-img under Ubuntu: 1. Version: qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2004-2008 Fabrice Bellard 2. qemu-img create -f vhdx -o subformat=3Dfixed lin.vhdx 512M Formatting 'lin.vhdx', fmt=3Dvhdx size=3D536870912 log_size=3D1048576 = block_size=3D0 subformat=3Dfixed 3. qemu-img info lin.vhdx image: lin.vhdx file format: vhdx virtual size: 512M (536870912 bytes) disk size: 520M cluster_size: 8388608 4. Load lin.vhdx under Windows 10 is ok The same thing happens on `vpc` format with or without `oformat=3Dfixed`, it seems that windows version of qemu-img has some incorrect operation? My guess is that windows version of qemu-img doesn't handle the description field of vpc/vhdx, which leads to an incorrect `disk size` field. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1759522/+subscriptions