Missing Hyper-V modules
Bug #1099611 reported by
Alessandro Pilotti
This bug affects 4 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| CirrOS |
Triaged
|
Medium
|
Unassigned | ||
Bug Description
Booting a CirrOS VM on HyperV is possible, but due to the lack of the kernel Linux Integration Services (LIS), networking and storage are not properly recognised and configured.
To solve this issue, the LIS modules, already part of the Linux kernel codebase, should be included in the Kernel configuration in use on CirrOS. The required modules are:
hv_netvsc,hv_utils, hv_storvsc, hid_hyperv, hv_vmbus
| summary: |
- Hyper-V support is incomplete + Missing Hyper-V modules |
Revision history for this message
| Scott Moser (smoser) wrote | #1 |
| Changed in cirros: | |
| importance: | Undecided → Medium |
| status: | New → Triaged |
Revision history for this message
| Harm Weites (harmw) wrote | #2 |
Revision history for this message
| Scott Moser (smoser) wrote | #3 |
To post a comment you must log in.
As discussed, with Alessandro in IRC, there are 2 issues right now with cirros for this:
a.) the disk1.img right now has an initramfs that has no modules in it. That was a decision to trim the size of the disk image. There is also no way to denote currently that "these modules need to go into the initramfs" (block device dependencies) and "these modules dont need to be". So the simplist thing to do right now is to just copy all the modules into the initramfs, but that increases the duplication between initramfs and filesystem.
b.) cirros does not use udev (nor its busybox sibling 'mdev') right now. As a result, there is no system-id based loading of modules based on hardware present. a 'modprobe hv_storvsc' causes a 5 second timeout waiting for the bus/device so this is not going to work with cirros's simplistic 'modprobe everything' solution that is in place.
I'm really interested in getting 0.3.1 out "real soon now" as there are lots of other features i'd want to tackle. If we want to get support for this into 0.3.1, I think I'd suggest a temporary approach where we load the module only if there is something down /sys that tells us we should (ie, a very simplistic loader based on system ids).