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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
