On Mon, Jun 10, 2019 at 09:23:15AM -0500, Christopher Loyd Nugent wrote:
My name is Christopher Nugent. This is my first time posting to the mailing list, and I am still adjusting to the community norms. If I do anything out of line, please let me know. Anyway, on to the question:
I am attempting to use libvirt in a Windows application I am developing, and came upon the following in the documentation:
Libvirt is known to work as a client (not server) on Windows XP (32-bit), and Windows 7 (64-bit).
I am a bit confused as to what this means. Does it mean that I won't be able to use libvirt in a host configuration, Hyper-V acting as the underlying hypervisor?
Hi, basically what that means is that libvirtd as a daemon cannot run on Windows, and it's libvirtd acting as a server the clients are connecting to. However, since you're planning on using Hyper-V as the underlying hypervisor, you don't need libvirtd, you just need libvirt public API on the client side. That's because Hyper-V is something we call stateless driver, IOW client-side only driver which is shipped with the library. I suggest you look at the following resource [1] to understand how connection to libvirtd works. Essentially, a bunch of proprietary drivers do not need our libvirtd daemon to tunnel the remote connection nor need the daemon to store a state of the VM. [1] https://libvirt.org/api.html#Remote Erik
I am posting to the development list because, if I am right, I would like to donate my time to amend the situation. My application will be cross-platform and will
support multiple hypervisors, so using libvirt will help me not have to duplicate functionality.
Thank you for your time.
--Chris Nugent.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list