Adding QEMU Guest Agent

[lnxbil]

For better integration into KVM/QEMU, the guest agent is started
analogously to the VMware, Hyper-V, XEN and Parallels agents.

[tianon]

I wasn't even aware QEMU had a guest agent!

According to what I read about it (https://wiki.qemu.org/Features/GuestAgent and https://wiki.libvirt.org/page/Qemu_guest_agent), it seems it's mostly useful for minimal file transfering and/or running arbitrary commands inside the guest OS? Is that accurate?

With the other guest tools, we get a more full-featured experience by including them. For example, with VMware's tools, we report a lot of information back to the VMware platform (IP addresses, memory usage, etc) by including them. Many include some kind of shared folder solution and/or host time synchronization.

With QEMU, we don't get any of that, so I'm having a hard time justifying the inclusion. 😕

[lnxbil]

it seems it's mostly useful for minimal file transfering and/or running arbitrary commands inside the guest OS? Is that accurate?

Yes, but I've never used it for that.

With QEMU, we don't get any of that, so I'm having a hard time justifying the inclusion. 😕

I needed the guest agent for retrieving information about the used IP addresses for a Docker Maschine driver, so the information is the only part I need. You can also shutdown, hibernate and snapshot the machine via the agent. There are also callbacks for fsinfo, vcpus and memory, but I never used that either.

You can also hook into the agent and define whatever you want, so this is pretty cool stuff.

[lnxbil]

Any news on integration this? It's still essential for the docker-machine integration.
Travis still shows it as failed after terminating the job due to "too much logging".

[prologic]

ping?!

[tianon]

Sorry, but I'm still not convinced -- I can see some value in QEMU Agent, but I don't see what relevance that has to boot2docker, where we're specifically trying to decrease scope in an effort to maintain continued maintainability in the face of better methods of setting up Docker environments for the few users who can't migrate off docker-machine (because they're on Windows 7 or need VirtualBox for other things, for example).

[prologic]

@tianon How would you suggest we implement a way to automatically provisioned Docker hosts via docker-machine where Proxmox VE is the Hypervisor? It seems without some way to either a) allocate an IP Address up front or b) Communicate with the new guest there isn't much way to continue with the docker-machine provisioning process.

[tianon]

Why not use a production-grade distribution like Debian or Ubuntu instead? docker-machine supports them reasonably well in my experience.

[lnxbil]

Sorry, but I'm still not convinced -- I can see some value in QEMU Agent, but I don't see what relevance that has to boot2docker, [...]

Sorry, but why did you allow xen, vmware and virtualbox agents to be installed and refuse to add support for another hypervisor?

As I pointed out before, the qemu agent is is capable of a lot of things, yet I wanted only the integration that @prologic also wants: IP retrieval.

I looked it up and here are the features you want from an agent and they're all present in the API documentation:

• guest time synchronization, timezone support
• file transfer capabilities
• network performance metrics including ip, hostname.
• filesystem info
• passwort change capability
• online memory, cpu, disk, network changes
• remote command execution

[prologic]

This whole point of this PR is to validate and open up the door for further work on the docker-machine-proxmox-ve driver by @lnxbil

Why not use a production-grade distribution like Debian or Ubuntu instead? docker-machine supports them reasonably well in my experience.

Even if we were to do this; you'd still need to build a custom Image or ISO based off of a so-called "mainstream distro" with the qemu-agent installed and running anyway.

I don't understand the intend being your statement and your position. Why are you reluctant to also support the addition of the qemu guest agent?

[tianon]

I don't understand the intend being your statement and your position. Why are you reluctant to also support the addition of the qemu guest agent?

"Boot2Docker is officially in maintenance mode" (from the current repository readme) -- this has been the case officially since at least as far back as Mar 2 of this year, but it was a reality within the repository long before that. New projects using Boot2Docker as a base are definitely misguided IMO -- there are many other distribution choices which are much more well-suited to the task (especially for production workloads).

Adding the QEMU agent is going to add even more code which:

1. I won't be testing
2. I won't be using
3. I will still be maintaining (ensuring it still compiles, checking whether we need to do version bumps, etc)

Sorry, but why did you allow xen, vmware and virtualbox agents to be installed and refuse to add support for another hypervisor?

These are honestly unfortunate additions at this point that I'd love to deprecate if I could -- they were added long before the project went into maintenance mode (back while docker-machine was still very actively maintained and Docker for Mac and Docker for Windows didn't exist). Honestly, VirtualBox is one I should be testing (since it's the primary default driver for docker-machine), but I don't have a good VirtualBox setup and it's not something you can easily throw together sanely on a system that's got other hypervisors too (I use KVM quite a bit).

These other hypervisor bits receive no testing from me other than "does this thing still compile? great, hopefully it still works."

I want to stress that obstinance isn't my intention; I'm trying to be realistic and set realistic expectations. This project is not "active" in the sense that we're accepting new functionality and doing heavy maintenance -- all development here has been focused on making sure we can attempt to maintain the status quo for as long as possible while folks upgrade systems and/or Docker for Mac / Docker for Windows improve to the point that this project's primary use case is no longer necessary. See docker/machine#4537 for more discussion around docker-machine being in roughly the same state/position as boot2docker.

At this point, for folks looking for a very small/lightweight Docker distribution that can be easily live-booted in a similar manner as boot2docker but is also production ready/recommended (which boot2docker never has been), I would recommend RancherOS.

[prologic]

Yeah fair enough. I actually didn't realise boot2docker was in maintenance mode tbh. A crying shame really since I probably won't ever use Docker for Mac -- Since I'm one of those weird UNIXy / CLI types that just brew install and expect everything to have sane CLI/API interfaces :)

That being said; we may need to find other ways to get Docker on to Proxmox VE guests by way of docker-machine (which I assume is NOT in maintenance mode right?)

@lnxbil This may mean rethinking our approach and maybe making some assumptions on requisite infrastructure that docker-machine-proxmox-ve would require ahead of time in order to function.

[tianon]

... docker-machine (which I assume is NOT in maintenance mode right?)

It is, actually; see docker/machine#4537. "bugfix-only"

[lnxbil]

Maybe a little off topic, but there is currently no official bare-metal provisioning tool available for Docker that is not in maintenance mode from Docker Inc.?

[prologic]

Maybe a little off topic, but there is currently no official bare-metal provisioning tool available for Docker that is not in maintenance mode from Docker Inc.?

It's actually not off-topic at all! The whole point of the work that went into docker-machine-proxmox-ve and this PR was to support Docker on Proxmox VE based infra. This is what I happen to run in a small Rack.

As both docker-machine and boot2docker are considered EOL and in Maintenance Mode; assuming infrakit doesn't support Prmox (haven't looked) I'd say your choices are slim; Shell, Ansbile, by hand (ugh).