-
-
Notifications
You must be signed in to change notification settings - Fork 362
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
[WIP] Qemu agent #881
Conversation
Otherwise, deployments with multiple VMs try to write to the same image. Also, do the temp_image_path calculation only once.
for whatever reason, I get plenty of errors like
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 :( |
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. |
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.
closing this as a better PR is on the way |
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