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

[WIP] Qemu agent #881

Closed
wants to merge 13 commits into from
Closed

[WIP] Qemu agent #881

wants to merge 13 commits into from

Conversation

teto
Copy link
Member

@teto teto commented Feb 28, 2018

I do some testing on the TCP stack and in general to support static IP VMs etc it might be best to rely on the VM Agent.

The only missing part is the script to start the agent in the VM. There seems to be one at NixOS/nixpkgs#34722 so I hope to revisit this once it appears in nixpkgs.
Related issue #847

@teto
Copy link
Member Author

teto commented Apr 9, 2018

for whatever reason, I get plenty of errors like

File "/nix/store/dwd62qwwr4jzrcpp6nfrgq9mzrnjp73m-python2.7-libvirt-4.1.0/lib/python2.7/site-packages/libvirt.py", line 1347, in interfaceAddresses
    if ret is None: raise libvirtError ('virDomainInterfaceAddresses() failed', dom=self)

which I believe could be solved with the agent. I believe @mbrgm has a working agent ? do you intend to share it ? I would hate to duplicate the work :(

@mbrgm
Copy link
Member

mbrgm commented Apr 10, 2018

Yes, it's working and I intend to share it. However, it's based on #824 and I don't know how to handle this in a PR... Should I just put my branch on top of #824 (this is the current state), create a PR and then rebase whenever #824 changes?

@teto
Copy link
Member Author

teto commented Apr 10, 2018

Sure you can open a PR prefixed with [WIP] (work in Progress) and rebase once #824 is merged. This prevents people from reimplementing things already being developed and let some users test it in advance. The dev activity is not that huge on nixops so it shouldn't be a burden.
If you don't feel like opening a PR yet that's fine but I would love if possible to copy your code (I searched in your repo to no avail) since I've had tons of network problems when trying to do source routing xD

@teto
Copy link
Member Author

teto commented Apr 12, 2018

sorry to nag you but may I ask when you intend to make it public ? I have a tight deadline so I might reimplement it myself (not like it's too much work) but I would rather improve what you have if need be.

`MachineState.run_command()` passes SSH flags to `self.ssh.run_command()`.
However, `self.get_ssh_flags()` is already registered as a `ssh_flag_fun` in the
class `__init__()` function, so `ssh_util.SSH` already uses it to get the flags
when initiating a connection. This lead to the SSH flags being duplicated, which
causes an error for some flags (e.g. the `-J` flag, which can only be specified once).
Offers better separation, especially when additional features will be added.
This helps in situations when there's no network connectivity to the guest, e.g.
when the hypervisor host can be reached via a VPN, but the guest host cannot.
This mainly adds driver support for virtio drivers to the initial image of the
guest provisioning.
This is a WIP!

- Replaced `deployment.libvirtd.networks` option with a submodule to allow not
  only (libvirt) network names, but other networking types as well.
- Domain XML was adjusted accordingly to incorporate the parameters from the new
  `networks` submodule.
- Added the qemu guest agent to guests to allow for out-of-band
  communication (no need for network connectivity) with the hypervisor.
- Guest IP (for provisioning after guest has started) is no longer determined by
  waiting for the guest to get a DHCP lease in the hypervisor libvirt network.
  If the guest has a static IP, it won't ask for a DHCP lease. Also, for bridged
  networking, we probably will not have access to the DHCP server.
- Instead, the address of the first interface is retrieved from libvirt using
  the `VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_AGENT` method, which can now be done
  because of the newly added qemu guest agent.
@teto
Copy link
Member Author

teto commented Apr 16, 2018

closing this as a better PR is on the way

@teto teto closed this Apr 16, 2018
@teto teto deleted the qemu-agent branch November 26, 2020 01:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants