Add Guest Agent transport setting #3387
Conversation
Signed-off-by: Arthur Sengileyev <[email protected]>
|
I manually tested it
|
| PropagateProxyEnv *bool `yaml:"propagateProxyEnv,omitempty" json:"propagateProxyEnv,omitempty" jsonschema:"nullable"` | ||
| CACertificates CACertificates `yaml:"caCerts,omitempty" json:"caCerts,omitempty"` | ||
| Rosetta Rosetta `yaml:"rosetta,omitempty" json:"rosetta,omitempty"` | ||
| GuestAgentTransportType *GATransportType `yaml:"guestAgentTransportType,omitempty" json:"guestAgentTransportType,omitempty" jsonschema:"nullable"` |
There was a problem hiding this comment.
Maybe we should add a new struct GuestAgent?
GuestInstallPrefix can be moved there too. (The old form should be supported too for a while)
|
@arixmkii But i noticed lots of issues related to qemu serial port. At this point of time I don't think it will work out for all of our cases. Major problem was they don't support multiple instances of sock. With that being said, do you think having this option helps ?? |
|
This option confuses people more because it has drawbacks based on selection in long run. I think we should derive best mode of transport and use it as default always. Giving these config will confuse folks using it also this transport is internal to lima guest agent |
This is serial specifics, somewhat expected.
It the only option usable on Windows hosts. Unix socket forwarding with SSH alone is not possible, all additional workarounds on top of SSH will have overhead and be more fragile. It's having something, which works with limitations vs not having any working solution.
Sounds reasonable, until one steps on platform specific limitations, having unconditional non-configurable different choices on different platforms might be confusing as well. Using "hacky" looking
Just the discussion, I would disagree here. The setting is purely HostAgent specific, where it later communicates it to both GA and VM driver and makes decision how to establish its own connection. |
I agree. Can we think of doing something like below We can have this config but let do these config population as part of default windows itself and this can be a internal config. Not exposed to user This way user doesn't require to configure but as you said we will have meaningful way of deciding on transport medium |
So, the main concern is exposing this to limayaml? Am I getting this right? We can extend Driver API with SupportedTransports, where the priority based list is returned, this would become platform specific, and then HA would find the topmost suitable from this list, which it can use to configure both GA and the driver. This is a rough idea and needs polishing obviously. WDYT? |
Yes atleast for me this is the concern
True, if we can do it with existing data sets it would be great (like config). But happy to see new approach as well |
Fixes #3177
Closes #3255
Adds setting, which could influence, which will then decide, which transport will be in use for connection to GA
Fixes:
If the unsupported option is detected then a warning is printed and fallback will be used instead. The default is VMType and Host OS sensitive (due to limited support of options for some platforms).