Image Virtualbox Windows 7
Alpha Knows
The packer template you are using is going to be what determins if windows can boot and complete setup without interaction. There should be a autounattend.xml file that will need to match the settings for the windows iso you have.
Hi, yes I did test for that also.
I was able to manually browse and see the disk and the CD is recognised even without specifying "hard_drive_interface": "sata", or "iso_interface": "sata" like the online Packer docs recommend:
image1437900 119 KB
As you manually browse through the OOBE interface, do you see all your devices, such as hard drives? When the hypervisor is switched to EFI mode.The OS will be presented with a different view of the hardware devices.
I use VirtualBox frequently to create virtual machines for testing new versions of Fedora, new application programs, and lots of administrative tools like Ansible. I have even used VirtualBox to test the creation of a Windows guest host.
Never have I ever used Windows as my primary operating system on any of my personal computers or even in a VM to perform some obscure task that cannot be done with Linux. I do, however, volunteer for an organization that uses one financial program that requires Windows. This program runs on the office manager's computer on Windows 10 Pro, which came preinstalled.
This financial application is not special, and a better Linux program could easily replace it, but I've found that many accountants and treasurers are extremely reluctant to make changes, so I've not yet been able to convince those in our organization to migrate.
This set of circumstances, along with a recent security scare, made it highly desirable to convert the host running Windows to Fedora and to run Windows and the accounting program in a VM on that host.
The physical computer already had a 240GB NVMe m.2 storage device installed in the only available m.2 slot on the motherboard. I decided to install a new SATA SSD in the host and use the existing SSD with Windows on it as the storage device for the Windows VM. Kingston has an excellent overview of various SSD devices, form factors, and interfaces on its web site.
That approach meant that I wouldn't need to do a completely new installation of Windows or any of the existing application software. It also meant that the office manager who works at this computer would use Linux for all normal activities such as email, web access, document and spreadsheet creation with LibreOffice. This approach increases the host's security profile. The only time that the Windows VM would be used is to run the accounting program.
Before I did anything else, I created a backup ISO image of the entire NVMe storage device. I made a partition on a 500GB external USB storage drive, created an ext4 filesystem on it, and then mounted that partition on /mnt. I used the dd command to create the image.
I installed the new 500GB SATA SSD in the host and installed the Fedora 32 Xfce spin on it from a Live USB. At the initial reboot after installation, both the Linux and Windows drives were available on the GRUB2 boot menu. At this point, the host could be dual-booted between Linux and Windows.
Now I needed some information on creating a VM that uses a physical hard drive or SSD as its storage device. I quickly discovered a lot of information about how to do this in the VirtualBox documentation and the internet in general. Although the VirtualBox documentation helped me to get started, it is not complete, leaving out some critical information. Most of the other information I found on the internet is also quite incomplete.
First, I installed the most recent version of VirtualBox on the Linux host. VirtualBox can be installed from many distributions' software repositories, directly from the Oracle VirtualBox repository, or by downloading the desired package file from the VirtualBox web site and installing locally. I chose to download the AMD64 version, which is actually an installer and not a package. I use this version to circumvent a problem that is not related to this particular project.
The installation procedure always creates a vboxusers group in /etc/group. I added the users intended to run this VM to the vboxusers and disk groups in /etc/group. It is important to add the same users to the disk group because VirtualBox runs as the user who launched it and also requires direct access to the /dev/sdx device special file to work in this scenario. Adding users to the disk group provides that level of access, which they would not otherwise have.
I then created a directory to store the VMs and gave it ownership of root.vboxusers and 775 permissions. I used /vms for the directory, but it could be anything you want. By default, VirtualBox creates new virtual machines in a subdirectory of the user creating the VM. That would make it impossible to share access to the VM among multiple users without creating a massive security vulnerability. Placing the VM directory in an accessible location allows sharing the VMs.
I created the VM without a virtual disk. The Type should be Windows, and the Version should be set to Windows 10 64-bit. Set a reasonable amount of RAM for the VM, but this can be changed later so long as the VM is off. On the Hard disk page of the installation, I chose the "Do not add a virtual hard disk" and clicked on Create. The new VM appeared in the VirtualBox Manager window. This procedure also created the /vms/Test1 directory.
I did this using the Advanced menu and performed all of the configurations on a single page, as seen in Figure 1. The Guided Mode obtains the same information but requires more clicks to go through a window for each configuration item. It does provide a little more in the way of help text, but I did not need that.
Then I needed to know which device was assigned by Linux to the raw Windows drive. As root in a terminal session, use the lshw command to discover the device assignment for the Windows disk. In this case, the device that represents the entire storage device is /dev/sdb.
Instead of a virtual storage device located in the /vms/Test1 directory, VirtualBox needs to have a way to identify the physical hard drive from which it is to boot. This identification is accomplished by creating a *.vmdk file, which points to the raw physical disk that will be used as the storage device for the VM. As a non-root user, I created a vmdk file that points to the entire Windows device, /dev/sdb.
The next step was to add this vmdk disk to the storage devices for our VM. In the settings menu for the Test1 VM, I selected Storage and clicked on the icon to add a hard disk. This opened a dialog that showed the Test1vmdk virtual disk file in a list entitled Not attached. I selected this file and clicked on the Choose button. This device is now displayed in the list of storage devices connected to the Test1 VM. The only other storage device on this VM is an empty CD/DVD-ROM drive.
There was one more item to configure before the new VM would work. Using the VirtualBox Manager Settings dialog for the Test1 VM, I navigated to the System ==> Motherboard page and placed a check in the box for Enable EFI. If you do not do this, VirtualBox will generate an error stating that it cannot find a bootable medium when you attempt to boot this VM.
The virtual machine now boots from the raw Windows 10 hard drive. However, I could not log in because I did not have a regular account on this system, and I also did not have access to the password for the Windows administrator account.
No, this section is not about breaking the encryption of the hard drive. Rather, it is about bypassing the password for one of the many Windows administrator accounts, which no one at the organization had.
Even though I could boot the Windows VM, I could not log in because I had no account on that host and asking people for their passwords is a horrible security breach. Nevertheless, I needed to log in to the VM to install the VirtualBox Guest Additions, which would provide seamless capture and release of the mouse pointer, allow me to resize the VM to be larger than 1024x768, and perform normal maintenance in the future.
This is a perfect use case for the Linux capability to change user passwords. Even though I am accessing the previous administrator's account to start, in this case, he will no longer support this system, and I won't be able to discern his password or the patterns he uses to generate them. I will simply clear the password for the previous sysadmin.
I powered off the VM and then mounted the /dev/sdb3 partition on /mnt. I determined that /dev/sdb3 is the correct partition because it is the first large NTFS partition I saw in the output from the lshw command I performed previously. Be sure not to mount the partition while the VM is running; that could cause significant corruption of the data on the VM storage device. Note that the correct partition might be different on other hosts.
The chntpw command uses a TUI (Text User Interface), which provides a set of menu options. When one of the primary menu items is chosen, a secondary menu is usually displayed. Following the clear menu names, I first chose menu item 1.
I know, I know, but why not! I have already bypassed security on this drive and host, so it matters not one iota. At this point, I did log in to the old administrative account and created a new account for myself with a secure password. I then logged in as myself and deleted the old admin account so that no one else could use it.
d3342ee215