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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list