Re: simulating multiple hypervisors with the test driver
Daniel, That got me up and running quickly. The examples were easy to follow, all I had to do was read a couple of the xml documents to figure out how to get what I was after. Thank you, and the rest of the people working on the project, for all the effort you've put into libvirt! Tom On Tue, Jan 4, 2022 at 4:56 AM Daniel P. Berrangé wrote: > On Mon, Jan 03, 2022 at 09:06:35PM -0600, Tom Ammon wrote: > > Hello, > > > > I'm working on a python application that will manage multiple remote > > libvirt hypervisors. I've been using the test:///default uri for > > single-hypervisor tests, and it works great. > > > > I'd like to simulate connecting to two different remote hypervisors, > > however, in my testing so far it appears that multiple connections to the > > test:///default uri just look like different connections to the same > > hypervisor. Here's what I tried : > > Yes, the test:///default URI is shared process-global state. > > > What I would like is to be able to spin up two completely independent > > instances of the test driver so that it can simulate two different > > hypervisors/instances of libvirtd. > > Pass in a path to a custom XML file for the connection > > eg: > >test:///path/to/checkout/of/libvirt.git/examples/xml/test/testnode.xml > > every instance of a file base URL will be unique. See this example > file for guidance on how to write the XML to pre-populate arbitrary > resources > > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > -- - Tom Ammon M: (737) 400-9042 thomasam...@gmail.com -
Re: simulating multiple hypervisors with the test driver
On Mon, Jan 03, 2022 at 09:06:35PM -0600, Tom Ammon wrote: > Hello, > > I'm working on a python application that will manage multiple remote > libvirt hypervisors. I've been using the test:///default uri for > single-hypervisor tests, and it works great. > > I'd like to simulate connecting to two different remote hypervisors, > however, in my testing so far it appears that multiple connections to the > test:///default uri just look like different connections to the same > hypervisor. Here's what I tried : Yes, the test:///default URI is shared process-global state. > What I would like is to be able to spin up two completely independent > instances of the test driver so that it can simulate two different > hypervisors/instances of libvirtd. Pass in a path to a custom XML file for the connection eg: test:///path/to/checkout/of/libvirt.git/examples/xml/test/testnode.xml every instance of a file base URL will be unique. See this example file for guidance on how to write the XML to pre-populate arbitrary resources Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: Best way to install guest when it is not listed in output of osinfo-query os
On Tue, Dec 21, 2021 at 02:19:50PM +0100, john doe wrote: > On 12/21/2021 10:41 AM, Andrea Bolognani wrote: > > On Mon, Dec 20, 2021 at 10:59:15PM +0100, Martin Kletzander wrote: > > > Any reason for debian not having an -unknown version like lot of the > > > other distros? > > > > I don't think there's a specific reason for that, it's probably just > > a matter of nobody thinking of it until now :) > > > > In addition to that, considering that there already entries for > > Debian testing and Fedora Rawhide, adding one for Debian unstable > > might make sense too. > > > > That would be lovely if 'debian-unknown' and 'debian11' could be > available on Bullseye!!! :) > > Is it intentional that the Debian URLs in the output of 'osinfo-query > os' point to 'debian.org/debian/VERSION_ID' instead of > 'debian.org/releases/VERSION_ID|VERSION_CODENAME'? The URLs are not a pointer to any specific resource. They are just an arbitrarily invented unique identifier & once released, we must never change any URL. By convention we pick a short "product name" as the first path component, because over time vendors have introduced new or parallel products. Thus '/releases/' would not be future proof. As an example, Fedora has both the traditional 'fedora' OS releases and 'silverblue'. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
