Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hypervisor detection #7

Open
Wenzel opened this issue Aug 4, 2019 · 5 comments
Open

hypervisor detection #7

Wenzel opened this issue Aug 4, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@Wenzel
Copy link
Owner

Wenzel commented Aug 4, 2019

Libmicrovmi's api needs to explicitely specify the hypervisor that we want to use.

We could improve that behavior by detecting if a given hypervisor is present, and test all possible hypervisors (the ones compiled in the library).

As we are only compiling a specific hypervisor, there will be only 2 hypervisors available:

  • Dummy
  • the selected feature (xen or kvm at this point)

How can we modify the init function, so that it takes an optional driver type ?

pub fn init(driver_type: Option<DriverType>, domain_name: &String) -> Box<Introspectable> {

So we could pass None and let the function decide.

What do you think @tathanhdinh, how to implement this feature ?

Thanks.

@Wenzel
Copy link
Owner Author

Wenzel commented Aug 4, 2019

I was looking at adding a new function in the Introspectable trait:

fn detect() -> Result<bool,Box<Error>> where Self: Sized {

And then you could loop over the DriverType enum, and pick the only hypervisor that will return true

@Wenzel
Copy link
Owner Author

Wenzel commented Apr 23, 2020

We should rename this feature as hypervisor test, and test whether a given domain name is available on for a specific hypervisor.

Implementing the same logic that LibVMI's driver_init_mode function does.

Overview:

  • xen_test
    • xen_init
      • xen_get_version
        • reading /sys/hypervisor/major/minor
      • init libxc_wrapper
      • init libxs_wrapper
    • test converting domain name to domain id
      • via xenstore directories
  • kvm_test
    • kvm_init
      • init libvirt_wrapper
      • connect to qemu:///system

@Wenzel
Copy link
Owner Author

Wenzel commented Dec 30, 2020

Next here would be to enable a set of features by default.
Of course, we have to take the platform into account, Linux or Windows.

I tried to play with Cargo conditional compilation, but I can't get this thing working as I expect:
carbon

Im getting

warning: unused manifest key: target.cfg(target_os="linux").features
warning: unused manifest key: target.cfg(target_os="windows").features
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s

I saw the syntax in a SO post:
https://stackoverflow.com/questions/39709542/why-does-the-last-platform-specific-dependency-take-precedence-in-cargo

of course, if this isn't supported for the features section, we can ditch the hyper-v driver and set the default linux drivers

@rageagainsthepc
Copy link
Collaborator

rust-lang/cargo#1197

:(

@Wenzel
Copy link
Owner Author

Wenzel commented Dec 30, 2020

Thanks for finding this.
At least this should be available in nightly already, according to:

Target-specific features for dependencies has been implemented and is available as a nightly-only feature on the latest nightly 2020-02-23. See the tracking issue at #7914.

In the meantime, we can assume linux by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
No open projects
Development

No branches or pull requests

2 participants