Need to attach HDD to Windows 7 standalone

Hello. I simply need to copy files from a partition in my HDD to my Windows 7 standalone (i.e. attach the HDD to my Windows 7 standalone successfully). Searched so much and couldn’t find, so I’m making this post on the forum.

(Assuming that the standalone is named ‘my-standalone’, and that the HDD partition I need to copy from is dom0:sdb1.)
Here’s what I tried (with the standalone shutdown at first):
1. Starting the standalone, and when Windows 7 completely starts, using the USB tray to attach the partition of the HDD to the standalone.
2. Starting the standalone, and just right afterwards quickly use the USB tray to attach the partition of the HDD to the Windows 7 standalone before Windows 7 starts.
3. Running the command qvm-start my-standalone --drive=hd:dom0:sdb1.
4. Running the command qvm-block detach my-standalone dom0:sdb1 (just in case), then the command qvm-block attach my-standalone dom0:sdb1 -p, then starting the standalone qvm-start my-standalone.

*These 4 (from 1 to 4) (doing any ONE of them) results in:
- I can’t find anything in the “Disk Management” of Windows 7 more than the already-existed ones before I do anything of these 4.

5. Running the command `qvm-start my-standalone --drive=dom0:sdb1`.
6. Running the command `qvm-block detach my-standalone dom0:sdb1` (just in case), then the command `qvm-block attach my-standalone dom0:sdb1 -p -o devtype=cdrom`, then starting the standalone.

*These 2 (5 and 6) (doing any ONE of them) results in:
- I found a volume named ‘E’ besides the already-existed ‘C’ and ‘D’ in the “Disk Management” of Windows 7 that didn’t exist before doing 5 or 6, but the icon of ‘E’ looks different.
- In the File Explorer, trying to open ‘E’ results in the message Windows can't access this disc. The disc might be corrupt. Make sure that the disc uses a format that Windows recognizes. If the disc is unformatted, you need to format it before using it.
- In CMD as administrator, in ‘diskpart’, here is the output of the commands:

> list disk
Disk ###  Status         Size     Free     Dyn  Gpt
--------  -------------  -------  -------  ---  ---
Disk 0    Online          200 GB  1024 KB
Disk 1    Online          20  GB     0  B
Disk 2    Online          10  GB    10 GB

> list volume
Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
----------  ---  -----------  -----  ----------  -------  ---------  --------
Volume 0     E                RAW    CD-ROM        65 GB  Healthy
Volume 1         System Rese  NTFS   Partition    100 MB  Healthy    System
Volume 2     D                NTFS   Partition    199 GB  Healthy
Volume 3     C                NTFS   Partition     19 GB  Healthy    Boot

> select volume 0
*prints that it is selected successfully*

> format fs=ntfs
    0 percent completed

Virtual Disk Service error:
The media is write protected.

Note: the Windows 7 standalone private storage max size is set to 20 GB, and the System storage max size is set to 200 GB. When I first installed the Windows 7 in the standalone by the .iso file, I set only two partitions in the Windows installation process: ‘C’ to be the 20 GB and ‘D’ to be the 200 GB.

What should I do? How to attach my HDD partition (or the whole HDD, if it has to be like that) to the Windows 7 standalone? How do people do it? If you told me how, and then I tried and then it turned out to be a Windows problem, then I’ll go out of here of course because it’ll be no more a Qubes problem.

You need to install Xen PV Storage driver either signed one from QWT, but notice about potential security issue with it:

Or unsigned driver from Xen:

Thank you!
But, I tried the QWT, and everything worked until the step of really executing the .msi which you find in the new volume created by Qubes in Windows when you start the Windows standalone with qvm-start my-standalone --install-windows-tools after installing qubes-windows-tools with sudo qubes-dom0-update qubes-windows-tools, I couldn’t find anything other than a README file that contains one line that says like: Qubes Windows Tools are currently unavailable due to security concerns.

So, I believe the option of Windows PV via QWT is not available now, right?

The other option you mentioned: Windows PV Drivers by the Xen Project. I think there’s a problem here: How will I have that in my Windows 7 standalone if I can’t copy to it in the first place. (Isn’t it right that I need to have the Windows PV Drivers tarball content in the Windows 7 standalone, and execute something in it?) Do I have to give it internet (e.g. via changing its NetVM to sys-whonix, or if that’s not the way, what is the way?) and download the Windows PV Drivers by the Xen Project via the Internet Explorer in the Windows 7 standalone?

Note: Due to the security problems described in QSB-091, installation of Qubes Windows Tools is currently blocked. Instead, a text file containing a warning is displayed. Currently, it is difficult to estimate the severity of the risks posed by the sources of the Xen drivers used in QWT possibly being compromised, so it was decided not to offer direct QWT installation until this problem could be treated properly. While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or dom0 and thus be dangerous for Qubes itself. This risk may be small or even non-existent, as stated in QSB-091. If you understand this risk and are willing to take it, you can still install the previous versions of Qubes Windows Tools, using the command

sudo qubes-dom0-update qubes-windows-tools-4.1.68

for Qubes R4.1.2, or

sudo qubes-dom0-update qubes-windows-tools-4.1.69

for Qubes R4.2.0, respectively, instead of the command listed in step 1 of the installation described below. This will provide the .iso file to be presented as an installation drive to the Windows qube in step 3 of the QWT installation.

If you prefer to download the corresponding .rpm files for manual QWT installation, these are still available from the repositories (version 4.1.68-1 for Qubes R4.1.2 and version 4.1.69-1 for Qubes R4.2.0). After downloading, copy the file to dom0 as described in How to copy from dom0 and install it via sudo dnf install /path/to/rpmfile. Now you can proceed according to step 3 of the description below.

Warning: These older versions of Qubes Windows Tools will be replaced during the next dom0 update by the current dummy version 4.1.70-1. This can be inhibited by appending the line exclude=qubes-windows-tools to the file /etc/dnf/dnf.conf in dom0. But this will also stop any further QWT updates - so be sure to remove this line when - hopefully - a new functional version 4.1.71-1 of Qubes Windows Tools will be made available!!!

  1. You can set net qube for your Windows qube and download the file from internet inside qube.
  2. You can copy the file on the USB disk and attach the USB disk to your WIndows qube by enabling stubdom-qrexec feature, but maybe Windows 7 will require additional drivers for USB so it won’t work:
    Windows USB integration with R4.1
  3. You can mount the Windows qube storage in disposable qube and copy the files there:
    How to mount LVM images | Qubes OS

Thanks. I may install the QWT, but I have a last question.

It’s stated in Qubes Windows Tools (QWT) | Qubes OS

While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or dom0 and thus be dangerous for Qubes itself. This risk may be small or even non-existent, as stated in QSB-091.

And it’s stated in the QSB-091: qubes-secpack/QSBs/qsb-091-2023.txt at master · QubesOS/qubes-secpack · GitHub

Dom0 is not affected, even though the qubes-windows-tools package is
installed in dom0, since neither the dom0 package build process nor dom0
itself interprets these driver files. Rather, the purpose of this
package is merely to make the driver files available to the Windows
qubes in which QWT are installed.

First says that dom0 may be compromised, and seconds says no. Does the first says that dom0 may be compromised becuase Xen bugs exist anyway? Does installing QWT add to that probability (i.e. increases the chances of fatal Xen bugs)?

The Windows 7 standalone will never have NetVM. So, doesn’t that mean the maximum that can be done in it, if it got compromised, is that it deletes in itself? and nothing worse can happen? If yes, and fatal Xen bugs don’t get increased when QWT is installed, then I think I’ll install QWT. Because what exist in the Windows 7 standalone is backed up anyway.
If there’s a chance that Windows 7 can control dom0 and the system due to QWT, then there’s no way to install QWT, because what’s in Windows 7 is not trusted.

If it’s a malware that can’t break the virtualization, it’s in offline qube and you won’t copy the files from this qube to other more trusted or networking qubes then it can only mess with the data inside this qube.
But if the malware has some 0-day that can break the virtualization then it can gain control of all your system.