<div dir="ltr">I run a number of Ubuntu VMs under Hyper-V and it's led me to have a few (minor) issues and requests for future releases.  Here's a short list:<div><br></div><div><span style="line-height:1.5"><b>Partitioning:</b></span></div><div><span style="line-height:1.5">MS's best practices for Linux on HyperV[1] recommend a few specific options for filesystems:</span><br></div><div>  - ext4 rather than ext3 (it's more space-efficient in conjunction with .vhdx files)</div><div>  - <span style="font-family:consolas,courier,monospace;font-size:13px;line-height:17.55px">mkfs.ext4 –G 4096</span><span style="line-height:1.5"></span><span style="line-height:1.5"> [...] as options </span><span style="line-height:1.5"></span></div><div><br></div><div><span style="line-height:1.5">It's currently not particularly easy to do this in the installer: You can't directly set options to mkfs.ext4; even if you could, I suspect most users are unaware of the best practices document and wouldn't set them anyways.  Additionally, there's no good opportunity to format partitions manually after the installer writes the partition table to disk (as it immediately copies over some files).  Right now, my "easy" solution is to allow the installer to write the partition table, then reset the VM and manually reformat all of the ext4 partitions in question.  The complexity of this approach increases drastically if using LVM or encryption (though encrypted filesystems in a VM is of dubious usefulness when the contents of the VM's RAM might be written to the host's disk).</span></div><div><span style="line-height:1.5"><br></span></div><div>In a perfect world, an installer running under Hyper-V would detect it (trivially done with `dmesg | grep HyperV`. though the exact pattern should be fine-tuned) and ask the user if they want to apply the relevant options during partitioning.  Likewise is presumably true for running under VMWare/Virtualbox/xen/kvm/qemu/etc, though the optimal options for each may vary.</div><div><br></div><div><br></div><div><b>Packages:</b></div><div><span style="line-height:1.5">A number of the default packages that ubuntu-standard/ubuntu-server depend on don't make a lot of sense on a VM; some that do aren't installed by default.  IMHO ubuntu-server-vm/ubuntu-standard-vm metapackages or some other reorganization of those packagse might make sense.  Some notable instances:</span><br></div><div><span style="line-height:1.5"><br></span></div><div>- crda and iw relate to wireless devices, which VMs don't have.</div><div>- laptop-detect (unless it has a means of telling if a VM is running on a laptop and invoking appropriate power-saving measures, but that seems finnicky)</div><div>- linux-*-generic should be replaced by linux-*-virtual in most cases.</div><div>- Packages like lvm2 (and its dependencies) and dmeventd/dmraid/dmsetup are less useful on VMs where fault tolerance is likely to be handled on the host and resizing disks is more a case of "resize VHD on host, then grow partition on guest"..  </div><div>- Disk encryption on VMs may cause a false sense of security since decryption keys (and the decrypted data) live in memory, which means it may also hit the host's filesystem in cases where the VM is snapshotted or otherwise saved.</div><div><br></div><div><br></div><div><br></div><div>[1] <a href="https://technet.microsoft.com/en-us/library/dn720239.aspx" target="_blank">https://technet.microsoft.com/en-us/library/dn720239.aspx</a></div><div><br></div><div>-- Daniel</div></div>