Cheers! I was missing a couple of points re the UEFI status and I would have been there all day trying to configure GRUB to push it full-screen. An extremely helpful vid.
Hi Phillip. Just wanted to thank you for sharing this solution as it drove me nuts for over a week trying to figure out why my screen was stuck at 1024x768 after loading kubuntu in a hyper-v vm. all love for you.
Hi Philip, thanks for the detailed step-by-step review! I'm running Debian VMs (my main headless workhorse, and sometimes some little cleanly installed VMs to test stuff). When I saw your video, I let out a sigh of relief: nothing had appeared principally different in W11!. Support for Secure Boot now seems fully available on desktop OSes. That's a plus for security-minded users. May I offer a couple of suggestion for the next steps from experience? I have a 6 Cores/12HT CPU and 32GB of RAM. Of course, everyone's requirements are different, but I'm loading my main development Debian VM quite heavily. * First, you can allocate all cores to a VM. It will share them with the host, and, since I do not run a lot of Windows apps while developing on Linux (VSCode, Firefox; the rest doesn't need a lot of RAM, like Notepad++ etc.-Firefox can be a memory hog, VSCode is okay). None of these need much CPU, unless you run some serious Web apps in FF. When the VM is idle, all the CPU power goes to the host. Extra Linux processes are just like extra Windows processes for the purpose of estimating the capacity. * Second, install the hv-daemons package via APT on the guest after first boot. Make sure you have HyperV guest drivers loaded ("lsmod | grep ^hv_") shows 5 of them here, *especially one named hv_balloon*. Whether to use a swap file in the guest is a judgment call; if your have a NVMe SSD storage, you may create a small separate hard drive for it on the virtual SCSI controller for a swap partition, but do not make it big (2-4GB for a 24G VM with 32G physical RAM on the host is fine). I usually do not, but larger compiles sometimes go OOM on the guest when they could have been saved by a bit of swapping. Normally, after the host fulfills the request from hv_balloon for more RAM, stuff gets swap in if you have a guest swap. The hv_balloon maintains "just enough" RAM for the guest, so you can set a minimum and a maximum RAM allotments for the VM. This driver talks to the Hyper-V host services, and increases or decreases VM memory (stealing it from the host: memory cannot be shared as easy as the CPU, it always involves major faulting and ensuing cache buffer trimming on the host and potential swapping both in the guest and on the host, when RAM is in short supply). Oftentimes, ballooning isn't agile enough to provide more page-committed memory to the host quickly enough if the spike in requests is sharp, like when a 12-thread make suddenly goes into 6-8 linkers, which are memory-hungry for large SO and binaries. If you have a little guest swap file, the guest will first try swapping holding the processes frozen until some RAM is freed, but it cannot wait in the same manner on hv_balloon to provide more free RAM by design. So, after the initial install in a small fixed RAM, which you demonstrate at an excellent detail level (as an aside, you may allocate as many CPU as you want in the final configuration from the start: this does not need any support from the guest; it's only the RAM that requires the hv_balloon kernel module), make sure the "hv_" drivers are loaded, and then dial the maximum RAM, possibly to a quite large value (I'm using min=3GB and max=24GB out of 32GB on the Windows 10 host: 3/4 of the total RAM). Sometimes the host may also request your VM to shrink ASAP, which may result in sudden RAM shortage on the VM. The VM also shrinks over time when idle ("deflates the balloon"), becoming an unnoticeable memory consumer on the host. All in all, the ballooning mechanism is an excellent way to overcommit your physical RAM to the VM for its _potential_ use, and, if all set up correctly for your pattern of use, you'll hardly ever notice it!
I have never tried, but if the MS key is provided in virtual UEFI (there are _some_, but I am not sure if they are _the_ keys which validate the shim; but at the least, I see it when run "mokutil --db" on my Debian VM, which is Gen2), you can use grub2 to boot through shimx64.efi. This shim is signed with the MS key, so it "just checks out". Unfortunately, I cannot find the blog post of the good guy who went through the signing process for the very first time (it cost him $250) around 2013 (or '14 or '15) and released the signed file to the public domain for the common good. The versions that come with distros not backed by corporations (such as Debian) very well may be the copies of that same venerable file: root:/boot/efi/EFI/debian# sbverify --list shimx64.efi image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root There is a dropbox under the "Enable Secure Boot" with 3 (on W10) choices; try them all. This may work out of the box. grubx64.efi is signed by the distro key, tho, so you'll need to enroll the keys into the DB database as trusted for the signature to be recognized on boot (see the mokutil tool): root:/boot/efi/EFI/debian# sbverify --list grubx64.efi signature 1 image signature issuers: - /CN=Debian Secure Boot CA image signature certificates: - subject: /CN=Debian Secure Boot Signer 2021 - grub2 issuer: /CN=Debian Secure Boot CA The package 'shim-signed' must be installed, but it normally is when you install 'grub-efi-amd64-signed'.
Thank you for these percise steps. I was having trouble installing Ubuntu and having it boot under UEFI. You're tutorial was precise and appreciated.
Cheers! I was missing a couple of points re the UEFI status and I would have been there all day trying to configure GRUB to push it full-screen. An extremely helpful vid.
Hi Phillip. Just wanted to thank you for sharing this solution as it drove me nuts for over a week trying to figure out why my screen was stuck at 1024x768 after loading kubuntu in a hyper-v vm. all love for you.
Exactly what I needed! Great explanations, good pacing - thank you so much!
i accidently skip MOK to choose in blue screen step. what should i do ? OS is running but I realized I need to do for MOK.
Exactly what I needed. Thank you for the clear instructions. This was straightforward.
Works with Ubuntu 22.4 too. Thank you for this well done video.
Hello, It's great guide for me thanks for release
Great Post this is my go to guide! I appreciate.
Thanks for the video. This worked flawlessly on my Dell G7.
Hi Philip, thanks for the detailed step-by-step review! I'm running Debian VMs (my main headless workhorse, and sometimes some little cleanly installed VMs to test stuff). When I saw your video, I let out a sigh of relief: nothing had appeared principally different in W11!. Support for Secure Boot now seems fully available on desktop OSes. That's a plus for security-minded users.
May I offer a couple of suggestion for the next steps from experience? I have a 6 Cores/12HT CPU and 32GB of RAM. Of course, everyone's requirements are different, but I'm loading my main development Debian VM quite heavily.
* First, you can allocate all cores to a VM. It will share them with the host, and, since I do not run a lot of Windows apps while developing on Linux (VSCode, Firefox; the rest doesn't need a lot of RAM, like Notepad++ etc.-Firefox can be a memory hog, VSCode is okay). None of these need much CPU, unless you run some serious Web apps in FF. When the VM is idle, all the CPU power goes to the host. Extra Linux processes are just like extra Windows processes for the purpose of estimating the capacity.
* Second, install the hv-daemons package via APT on the guest after first boot. Make sure you have HyperV guest drivers loaded ("lsmod | grep ^hv_") shows 5 of them here, *especially one named hv_balloon*. Whether to use a swap file in the guest is a judgment call; if your have a NVMe SSD storage, you may create a small separate hard drive for it on the virtual SCSI controller for a swap partition, but do not make it big (2-4GB for a 24G VM with 32G physical RAM on the host is fine). I usually do not, but larger compiles sometimes go OOM on the guest when they could have been saved by a bit of swapping. Normally, after the host fulfills the request from hv_balloon for more RAM, stuff gets swap in if you have a guest swap. The hv_balloon maintains "just enough" RAM for the guest, so you can set a minimum and a maximum RAM allotments for the VM. This driver talks to the Hyper-V host services, and increases or decreases VM memory (stealing it from the host: memory cannot be shared as easy as the CPU, it always involves major faulting and ensuing cache buffer trimming on the host and potential swapping both in the guest and on the host, when RAM is in short supply). Oftentimes, ballooning isn't agile enough to provide more page-committed memory to the host quickly enough if the spike in requests is sharp, like when a 12-thread make suddenly goes into 6-8 linkers, which are memory-hungry for large SO and binaries. If you have a little guest swap file, the guest will first try swapping holding the processes frozen until some RAM is freed, but it cannot wait in the same manner on hv_balloon to provide more free RAM by design.
So, after the initial install in a small fixed RAM, which you demonstrate at an excellent detail level (as an aside, you may allocate as many CPU as you want in the final configuration from the start: this does not need any support from the guest; it's only the RAM that requires the hv_balloon kernel module), make sure the "hv_" drivers are loaded, and then dial the maximum RAM, possibly to a quite large value (I'm using min=3GB and max=24GB out of 32GB on the Windows 10 host: 3/4 of the total RAM). Sometimes the host may also request your VM to shrink ASAP, which may result in sudden RAM shortage on the VM. The VM also shrinks over time when idle ("deflates the balloon"), becoming an unnoticeable memory consumer on the host. All in all, the ballooning mechanism is an excellent way to overcommit your physical RAM to the VM for its _potential_ use, and, if all set up correctly for your pattern of use, you'll hardly ever notice it!
Does Secure Boot also has to be set up in UEFI?
I think so. I had it enabled in UEFI. And was able to delete and make a new Ubuntu VM using the same MOK key.
I have never tried, but if the MS key is provided in virtual UEFI (there are _some_, but I am not sure if they are _the_ keys which validate the shim; but at the least, I see it when run "mokutil --db" on my Debian VM, which is Gen2), you can use grub2 to boot through shimx64.efi. This shim is signed with the MS key, so it "just checks out". Unfortunately, I cannot find the blog post of the good guy who went through the signing process for the very first time (it cost him $250) around 2013 (or '14 or '15) and released the signed file to the public domain for the common good. The versions that come with distros not backed by corporations (such as Debian) very well may be the copies of that same venerable file:
root:/boot/efi/EFI/debian# sbverify --list shimx64.efi
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
There is a dropbox under the "Enable Secure Boot" with 3 (on W10) choices; try them all. This may work out of the box. grubx64.efi is signed by the distro key, tho, so you'll need to enroll the keys into the DB database as trusted for the signature to be recognized on boot (see the mokutil tool):
root:/boot/efi/EFI/debian# sbverify --list grubx64.efi
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2021 - grub2
issuer: /CN=Debian Secure Boot CA
The package 'shim-signed' must be installed, but it normally is when you install 'grub-efi-amd64-signed'.
It's work. Thank for a lot!!
Thank you very much for this great video!
thanks, directly to the point!
Thank you so much. You made it very easy.
Bro, I can't copy-paste items from host to guest machine or vice-versa, can u please guide me?
P.S: I did exactly everything the same as u mentioned.
I have the same issue. Anyone knows what to do :(((?
I can't get my Internet to work but okay
Really great instructions, thanks lot for sharing it.
Alternatively you can click quick create on the Hyper-v Manager and go and make a cup of tea
Hi . Thank you so much good piece of information
Perfect tutorial
you dont need windows 11 for this, same on windows 10
thank you a lot
Well done
Thanks
you not activate a integration services, dislike