Cole Robinson - virthttps://blog.wikichoon.com/2020-09-26T00:00:00-04:00Cole's dev logvirt-install --cloud-init support2020-09-26T00:00:00-04:002020-09-26T00:00:00-04:00Cole Robinsontag:blog.wikichoon.com,2020-09-26:/2020/09/virt-install-cloud-init.html<p>As part of GSOC 2019, <a href="https://athinapl.home.blog/2019/08/25/gsoc-2019-cloud-init-configuration-for-virt-manager-virt-install/">Athina Plaskasoviti implemented <code>--cloud-init</code> support for virt-install</a>. This post provides a bit more info about the feature.</p>
<h4>Why cloud-init</h4>
<p>For a long while, most mainstream Linux distros have shipped 'cloud images': <code>raw</code> or <code>qcow2</code> formatted disk images with the distro minimally pre-installed on it. These …</p><p>As part of GSOC 2019, <a href="https://athinapl.home.blog/2019/08/25/gsoc-2019-cloud-init-configuration-for-virt-manager-virt-install/">Athina Plaskasoviti implemented <code>--cloud-init</code> support for virt-install</a>. This post provides a bit more info about the feature.</p>
<h4>Why cloud-init</h4>
<p>For a long while, most mainstream Linux distros have shipped 'cloud images': <code>raw</code> or <code>qcow2</code> formatted disk images with the distro minimally pre-installed on it. These images typically have <a href="https://cloud-init.io/">cloud-init</a> set to run on VM bootup. cloud-init can do a variety of things, like add users, change passwords, register ssh keys, and generally perform any desired action on the VM OS. This only works when cloud-init is passed the right configuration by whatever platform is starting the VM, like OpenStack or virt-install. cloud-init supports many different <a href="https://cloudinit.readthedocs.io/en/latest/topics/datasources.html">datasources</a> for getting configuration outside the VM.</p>
<p>Historically though the problem is that slapping these images into virt-install or virt-manager gives crappy results, because these tools were not providing any datasource. In this case, cloud-init reverts to its distro default configured behavior, which in most cases is unusable. For example on Fedora, the result was: hang waiting for cloud-init data, time out, drop to login prompt with all accounts locked.</p>
<p>Prior to virt-install <code>--cloud-init</code> support, the simplest workaround was to use libguestfs, specifically <code>virt-customize</code>, to set a root password and disable cloud-init:</p>
<div class="highlight"><pre><span></span><code><span class="gp">$ </span>virt-customize -a MY-CLOUD-IMAGE.qcow2 <span class="se">\</span>
--root-password password:SUPER-SECRET-PASSWORD <span class="se">\</span>
--uninstall cloud-init
</code></pre></div>
<h4>--cloud-init option</h4>
<p>The <code>--cloud-init</code> option will tell virt-install to set up a <a href="https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html">nocloud</a> datasource via a specially formatted <code>.iso</code> file that is generated on the fly, and only used for the first VM bootup.</p>
<p>The default behavior when <code>--cloud-init</code> is specified with no suboptions will do the following:</p>
<ul>
<li>Generate a random root password and print it to the terminal.</li>
<li>Default to VM serial console access rather than graphical console access. Makes it easier to paste the password and gives more ssh-like behavior.</li>
<li>Sets the root password to expire on first login. So the temporary password is only used once.</li>
<li>Disables cloud-init for subsequent VM startups. Otherwise on the next VM boot you'd face locked accounts again.</li>
</ul>
<p>The <code>--cloud-init</code> also has suboptions to specify your own behavior, like transfer in a host ssh public key, pass in raw cloud-init <code>user-data</code>/<code>meta-data</code>, etc. See the <a href="https://github.com/virt-manager/virt-manager/blob/master/man/virt-install.rst#--cloud-init">virt-install --cloud-init man page section</a> for the specifics.</p>
<h4>Room for improvement</h4>
<p>This is all a step in the right direction but there's lots more we can do here:</p>
<ul>
<li>Extend virt-install's <code>--install</code> option to learn how to fetch cloud images for the specified distro. <a href="https://libosinfo.org/">libosinfo</a> and <a href="https://gitlab.com/libosinfo/osinfo-db">osinfo-db</a> already track cloud image download links for many distros so the info we need is already in place. We could make <code>virt-install --install fedora32,cloud=yes</code> a single way to pull down a cloud image, generate a cloud-init datasource, and create the VM in one shot.</li>
<li>Use <code>--cloud-init</code> by default when the user passes us a cloud-init enabled disk image. <code>virt-customize</code> has a lot of disk image detection smarts already, but we aren't using that in virt-install yet.</li>
<li>virt-manager UI support. There's an <a href="https://github.com/virt-manager/virt-manager/issues/143">issue tracking this</a> with some more thoughts in it.</li>
<li>Similar support for <a href="https://coreos.com/ignition/">CoreOS Ignition</a> which fulfills a similar purpose as cloud-init for distros like <a href="https://getfedora.org/en/coreos/">Fedora CoreOS</a>. There's an <a href="https://github.com/virt-manager/virt-manager/issues/152">issue tracking this too</a>.</li>
</ul>
<p>I personally don't have plans to work on these any time soon, but I'm happy to provide guidance if anyone is interested in helping out!</p>virt-manager 3.0.0 released!2020-09-16T00:00:00-04:002020-09-16T00:00:00-04:00Cole Robinsontag:blog.wikichoon.com,2020-09-16:/2020/09/virt-manager-300-released.html<p>Yesterday I released <a href="https://www.redhat.com/archives/virt-tools-list/2020-September/msg00003.html">virt-manager 3.0.0</a>. Despite the major version number bump, things shouldn't look too different from the previous release. For me the major version number bump reflects certain feature removals (like dropping virt-convert), and the large amount of internal code changes that were done, though there's a …</p><p>Yesterday I released <a href="https://www.redhat.com/archives/virt-tools-list/2020-September/msg00003.html">virt-manager 3.0.0</a>. Despite the major version number bump, things shouldn't look too different from the previous release. For me the major version number bump reflects certain feature removals (like dropping virt-convert), and the large amount of internal code changes that were done, though there's a few long awaited features sprinkled in like virt-install <code>--cloud-init</code> support which I plan to write more about later.</p>
<p>This release includes:</p>
<ul>
<li>virt-install --cloud-init support (<a href="https://athinapl.home.blog/2019/08/25/gsoc-2019-cloud-init-configuration-for-virt-manager-virt-install/">Athina Plaskasoviti</a>, Cole Robinson)</li>
<li><a href="https://blog.wikichoon.com/2020/07/virt-convert-removed.html">The virt-convert tool has been removed</a>. Please use virt-v2v instead</li>
<li>A handful of UI XML configuration options have been removed, in an effort to reduce maintenance ongoing maintenance burden, and to be more consistent with what types of UI knobs we expose. The <a href="https://blog.wikichoon.com/2020/07/virt-manager-xml-editor.html">XML editor</a> is an alternative in most cases. For a larger discussion see <a href="https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html">this thread</a> and virt-manager's <a href="https://github.com/virt-manager/virt-manager/blob/master/DESIGN.md">DESIGN.md</a> file.</li>
<li>The 'New VM' UI now has a 'Manual Install' option which creates a VM without any required install media</li>
<li>In the 'New VM' UI, the network/pxe install option has been removed. If you need network boot, choose 'Manual Install' and set the boot device after initial VM creation</li>
<li>'Clone VM' UI has been reworked and simplified</li>
<li>'Migrate VM' UI now has an XML editor for the destination VM</li>
<li>Global and per-vm option to disable graphical console autoconnect. This makes it easier to use virt-manager alongside another client like virt-viewer</li>
<li>virt-manager: set guest time after VM restore (Michael Weiser)</li>
<li>virt-manager: option to delete storage when removing disk device (Lily Nie)</li>
<li>virt-manager: show warnings if snapshot operation is unsafe (Michael Weiser)</li>
<li>Unattended install improvements (Fabiano Fidêncio)</li>
<li>cli: new --xml XPATH=VAL option for making direct XML changes</li>
<li>virt-install: new --reinstall=DOMAIN option</li>
<li>virt-install: new --autoconsole text|graphical|none option</li>
<li>virt-install: new --os-variant detect=on,require=on suboptions</li>
<li>cli: --clock, --keywrap, --blkiotune, --cputune additions (Athina Plaskasoviti)</li>
<li>cli: add --features kvm.hint-dedicated.state= (Menno Lageman)</li>
<li>cli: add --iommu option (Menno Lageman)</li>
<li>cli: Add --graphics websocket= support (Petr Benes)</li>
<li>cli: Add --disk type=nvme source.* suboptions</li>
<li>cli: Fill in all --filesystem suboptions</li>
<li>Translation string improvements (Pino Toscano)</li>
<li>Convert from .pod to .rst for man pages</li>
<li>Switch to pytest as our test runner</li>
<li>Massively improved unittest and uitest code coverage</li>
<li>Now using github issues as our bug tracker</li>
</ul>virt-manager libvirt XML editor UI2020-07-12T00:00:00-04:002020-07-12T00:00:00-04:00Cole Robinsontag:blog.wikichoon.com,2020-07-12:/2020/07/virt-manager-xml-editor.html<p><a href="https://www.redhat.com/archives/virt-tools-list/2019-June/msg00099.html">virt-manager 2.2.0</a> was released in June of last year. It shipped with a major new feature: libvirt XML viewing and editing UI for new and existing domain, pools, volumes, networks.</p>
<p>Every VM, network, and storage object page has a <strong>XML</strong> tab at the top. Here's an example with …</p><p><a href="https://www.redhat.com/archives/virt-tools-list/2019-June/msg00099.html">virt-manager 2.2.0</a> was released in June of last year. It shipped with a major new feature: libvirt XML viewing and editing UI for new and existing domain, pools, volumes, networks.</p>
<p>Every VM, network, and storage object page has a <strong>XML</strong> tab at the top. Here's an example with that tab selected from the VM <strong>Overview</strong> section:</p>
<p><img alt="VM XML editor" src="https://blog.wikichoon.com/images/079-xml1.png" width="500"></p>
<p>Here's an example of the XML view when just a disk is selected. Note it only shows that single device's libvirt XML:</p>
<p><img alt="Disk XML editor" src="https://blog.wikichoon.com/images/079-xml2.png" width="500"></p>
<p>By default the XML is not editable; notice the warning at the top of the first image. After editing is enabled, the warning is gone, like in the second image. You can enable editing via Edit->Preferences from the main <strong>Manager</strong> window. Here's what the option looks like:</p>
<p><img alt="XML edit preference" src="https://blog.wikichoon.com/images/079-xml-prefs.png" width="500"></p>
<p>A bit of background: We are constantly receiving requests to expose libvirt XML config options in virt-manager's UI. Some of these knobs are necessary for <1% but uninteresting to the rest. Some options are difficult to set from the command line because they must be set at VM install time, which means switch from virt-manager to virt-install which is not trivial. And so on. When these options aren't added to the UI, it makes life difficult for those affected users. It's also difficult and draining to have these types of justification conversations on the regular.</p>
<p>The XML editing UI was added to relieve some of the pressure on virt-manager developers fielding these requests, and to give more power to advanced virt users. The users that know they need an advanced option are usually comfortable editing the libvirt XML directly. The XML editor doesn't detract from the existing UI much IMO, and it is uneditable by default to prevent less knowledgeable users from getting into trouble. It ain't gonna win any awards for great UI, but the feedback has been largely positive so far.</p>virt-convert tool removed in virt-manager.git2020-07-11T00:00:00-04:002020-07-11T00:00:00-04:00Cole Robinsontag:blog.wikichoon.com,2020-07-11:/2020/07/virt-convert-removed.html<p>The next release of virt-manager will not ship the <code>virt-convert</code> tool, I removed it upstream with <a href="https://github.com/virt-manager/virt-manager/commit/ee9f93074bf74bd2e4c5177d750e7c438c7790cf">this commit</a>.</p>
<p>Here's the slightly edited quote from my original proposal to remove it:</p>
<blockquote>
<p>virt-convert takes an ovf/ova or vmx file and spits out libvirt XML.
It started as a code drop a …</p></blockquote><p>The next release of virt-manager will not ship the <code>virt-convert</code> tool, I removed it upstream with <a href="https://github.com/virt-manager/virt-manager/commit/ee9f93074bf74bd2e4c5177d750e7c438c7790cf">this commit</a>.</p>
<p>Here's the slightly edited quote from my original proposal to remove it:</p>
<blockquote>
<p>virt-convert takes an ovf/ova or vmx file and spits out libvirt XML.
It started as a code drop a long time ago that could translate back and
forth between vmx, ovf, and virt-image, a <a href="https://blog.wikichoon.com/2014/04/deprecating-little-used-tool-virt-image1.html">long dead appliance format</a>.
In 2014 I <a href="https://blog.wikichoon.com/2014/04/virt-convert-command-line-has-been.html">changed virt-convert</a> to do vmx -> libvirt and ovf ->
libvirt which was a CLI breaking change, but I never heard a peep of a
complaint. It doesn't do a particularly thorough job at its
intended goal, I've seen 2-3 bug reports in the past 5 years and
generally it doesn't seem to have any users. Let's kill it. If anyone
has the desire to keep it alive it could live as a separate project
that's a wrapper around virt-install but there's no compelling reason to
keep it in virt-manager.git IMO</p>
</blockquote>
<p>That mostly sums it up. If there's any users of virt-convert out there, you likely
can get similar results by extracting the relevant disk image from the
<code>.vmx</code> or <code>.ovf</code> config, pass it to <code>virt-manager</code> or <code>virt-install</code>, and let
those tools fill in the defaults. In truth that's about all <code>virt-convert</code> did in
to begin with.</p>
<p>Please see <a href="https://libguestfs.org/virt-v2v.1.html"><code>virt-v2v</code></a> for an actively maintained tool that can covert OVA/OVF appliances to libvirt + KVM. <a href="https://www.redhat.com/en/blog/importing-vms-kvm-virt-v2v">This redhat.com article</a> describes an example conversion.</p>virt-manager is deprecated in RHEL (but only RHEL)2020-06-16T13:00:00-04:002020-06-16T13:00:00-04:00Cole Robinsontag:blog.wikichoon.com,2020-06-16:/2020/06/virt-manager-deprecated-in-rhel.html<p><strong>TL;DR</strong>: I'm the primary author of virt-manager. virt-manager is deprecated in RHEL8 in favor of cockpit, but ONLY in RHEL8 and future RHEL releases. The upstream project virt-manager is still maintained and is still relevant for other distros.</p>
<p>Google 'virt-manager deprecated' and you'll find some discussions suggesting
virt-manager is …</p><p><strong>TL;DR</strong>: I'm the primary author of virt-manager. virt-manager is deprecated in RHEL8 in favor of cockpit, but ONLY in RHEL8 and future RHEL releases. The upstream project virt-manager is still maintained and is still relevant for other distros.</p>
<p>Google 'virt-manager deprecated' and you'll find some discussions suggesting
virt-manager is no longer maintained, <a href="https://cockpit-project.org/">Cockpit</a> is replacing virt-manager, virt-manager is going to be removed from every distro, etc. These conclusions are misinformed.</p>
<p>The primary source for this confusion is the section 'virt-manager has been deprecated' from the <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.2_release_notes/deprecated_functionality#deprecated-functionality_virtualization">RHEL8 release notes virtualization deprecation section</a>. Relevant quote from the RHEL8.2 docs:</p>
<blockquote>
<p>The Virtual Machine Manager application, also known as virt-manager, has been deprecated.
The RHEL 8 web console, also known as Cockpit, is intended to become its replacement in a subsequent release.</p>
</blockquote>
<p>What that means:</p>
<ul>
<li>virt-manager is in RHEL8 and will be there for the lifetime of RHEL8.</li>
<li>Red Hat engineering effort assigned to the virt-manager UI has been reduced compared to previous RHEL versions.</li>
<li>The tentative plan is to not ship the virt-manager UI in RHEL9.</li>
</ul>
<p>Why is this happening? As I understand it, RHEL wants to roughly standardize on Cockpit as their host admin UI tool. It's a great project with great engineers and great UI designers. Red Hat is going all in on it for RHEL and aims to replace the mismash of system-config-X tools and project specific admin frontends (like virt-manager) with a unified project. (Please note: this is my paraphrased understanding, I'm not speaking on behalf of Red Hat here.)</p>
<p>Notice though, this is all about RHEL. virt-manager is not deprecated upstream, or deprecated in other distros automatically just because RHEL has made this decision. The upstream virt-manager project continues on and Red Hat continues to allocate resources to maintain it.</p>
<p>Also, I'm distinguishing virt-manager UI from the virt-manager project, which includes tools like <code>virt-install</code>. I fully expect <code>virt-install</code> to be shipped in RHEL9 and actively maintained (FWIW Cockpit uses it behind the scenes).</p>
<p>And even if the virt-manager UI is not in RHEL9 repos, it will likely end up shipped in EPEL, so the UI will still be available for install, just through external repos.</p>
<p>Overall my personal opinion is that as long as libvirt+KVM is in use on linux desktops and servers, virt-manager will be relevant. I don't expect anything to change in that area any time soon.</p>Blog moved to Pelican and GitHub Pages2019-07-30T15:30:00-04:002019-07-30T15:30:00-04:00Cole Robinsontag:blog.wikichoon.com,2019-07-30:/2019/07/blog-moved.html<p>I've moved my blog from blogger.com to a static site generated with
<a href="https://blog.getpelican.com/">Pelican</a> and hosted on GitHub Pages. This
is a dump of some of the details.</p>
<p>The content is hosted in three branches across two repos:</p>
<ul>
<li><strong><a href="https://github.com/crobinso/blog/tree/gh-pages">blog/gh-pages</a></strong>: <a href="https://blog.wikichoon.com">https://blog.wikichoon.com</a> HTML content</li>
<li><strong><a href="https://github.com/crobinso/crobinso.github.io/tree/master">crobinso.github.io/master …</a></strong></li></ul><p>I've moved my blog from blogger.com to a static site generated with
<a href="https://blog.getpelican.com/">Pelican</a> and hosted on GitHub Pages. This
is a dump of some of the details.</p>
<p>The content is hosted in three branches across two repos:</p>
<ul>
<li><strong><a href="https://github.com/crobinso/blog/tree/gh-pages">blog/gh-pages</a></strong>: <a href="https://blog.wikichoon.com">https://blog.wikichoon.com</a> HTML content</li>
<li><strong><a href="https://github.com/crobinso/crobinso.github.io/tree/master">crobinso.github.io/master</a></strong>: <a href="https://wikichoon.com">https://wikichoon.com</a> front page HTML content</li>
<li><strong><a href="https://github.com/crobinso/crobinso.github.io/tree/pelican">crobinso.github.io/pelican</a></strong>: website source content and theme</li>
</ul>
<p>The motivation for the split is that according to this <a href="https://blog.kmonsoor.com/pelican-how-to-make-seo-friendly/">pelican SEO</a> article, <strong>master</strong> branches of GitHub repos are indexed by google, so if you store HTML content in a <strong>master</strong> branch your canonical blog might be battling your GitHub repo in the search results. And since you can only put content in the <strong>master</strong> branch of a <code>$username.github.io</code> repo, I added a separate blog.git repo. Maybe I could shove all the content into the <strong>blog/gh-pages</strong> branch I think dealing with multiple subdomains prevents it. I've already spent too much timing playing with all this stuff though so that's for another day to figure out. Of course, suggestions welcome, blog comments are enabled with Disqus.</p>
<p>One issue I hit is that pushing updated content to <strong>blog/gh-pages</strong> doesn't consistently trigger a new GitHub Pages deployment. There's a bunch of hits about this around the web (this <a href="https://stackoverflow.com/questions/20422279/github-pages-are-not-updating">stackoverflow post</a> in particular) but no authoritative explanation about what criteria GitHub Pages uses to determine whether to redeploy. The simplest 'fix' I found is to tweak the <code>index.html</code> content via the GitHub web UI and commit the change which seems to consistently trigger a refresh as reported by the repo's <a href="https://github.com/crobinso/blog/deployments">deployments page</a>.</p>
<p>You may notice the blog looks a lot like stock <a href="https://jekyllrb.com/">Jekyll</a> with its <a href="https://github.com/jekyll/minima">minima</a> theme. I didn't find any Pelican theme that I liked as much as minima, so I grabbed the CSS from a minima instance and started adapting the Pelican <a href="https://github.com/getpelican/pelican-themes/tree/master/simple-bootstrap">simple-bootstrap</a> theme to use it. The end result is basically a simple reimplementation of minima for Pelican. I learned a lot in the process but it likely would have been much simpler if I just used Jekyll in the first place, but I'm in too deep to switch now!</p>Host 'Network Interfaces' panel removed from virt-manager2019-04-09T14:01:00-04:002019-04-09T14:01:00-04:00Cole Robinsontag:blog.wikichoon.com,2019-04-09:/2019/04/host-network-interfaces-panel-removed.html<p>I released <a href="https://www.redhat.com/archives/virt-tools-list/2018-October/msg00087.html">virt-manager 2.0.0</a> in October 2018. Since the release contained the full port to python3, it seemed like a good opportunity to drop some baggage from the app.</p>
<p>The biggest piece we removed was the UI for managing host network interfaces. This is the <strong>Connection Details->Network …</strong></p><p>I released <a href="https://www.redhat.com/archives/virt-tools-list/2018-October/msg00087.html">virt-manager 2.0.0</a> in October 2018. Since the release contained the full port to python3, it seemed like a good opportunity to drop some baggage from the app.</p>
<p>The biggest piece we removed was the UI for managing host network interfaces. This is the <strong>Connection Details->Network Interfaces</strong> panel, and the <strong>New Interface</strong> wizard for defining host network definitions for things like bridges, bonds, and vlan devices. The main screen of the old UI looked like this:</p>
<p><img alt="virt-manager host interfaces panel" height="280" src="https://blog.wikichoon.com/images/074-host-network-interfaces-panel-removed-1.png" width="400"></p>
<h4>Some history</h4>
<p>Behind the scenes, this UI was using libvirt's Interface APIs, which also power the <code>virsh iface-*</code> commands. These APIs are little more than a wrapper around the <a href="https://pagure.io/netcf">netcf</a> library.</p>
<p>netcf aimed to be a linux distro independent API for network device configuration. On Red Hat distros this meant turning the API's XML format into an <code>/etc/sysconfig/network</code> script. There were even pie-in-the-sky ideas about NetworkManager one day using netcf.</p>
<p>In practice though the library never really took off. It was years before a debian backend showed up, contributed by a Red Hatter in the hope of increasing library uptake, though it didn't seem to help. netcf basically only existed to serve the libvirt Interface APIs, yet those APIs were never really used by any major libvirt consuming app, besides virt-manager. And in virt-manager's case it was largely just slapping some UI over the XML format and lifecycle operations.</p>
<p>For virt-manager's usecases we hoped that netcf would make it trivial to bridge the host's network interface, which when used with VMs would give them first class IP addresses on the host network setup, not NAT like the 'default' virtual network. Unfortunately though the UI would create the ifcfg files well enough, behind the scenes nothing played well with NetworkManager for years and years. The standard suggestion for was to disable NetworkManager if you wanted to bridge your host NIC. Not very user friendly. Some people did manage to use the UI to that effect but it was never a trivial process.</p>
<h4>The state today</h4>
<p>Nowadays NetworkManager can handle bridging natively and is much more powerful than what virt-manager/libvirt/netcf provide. The virt-manager UI was more likely to shoot you in the foot than make things simple. And it had become increasingly clear that virt-manager was not the place to maintain host network config UI.</p>
<p>So we made the decision to drop all this from virt-manager in 2.0.0. netcf and the libvirt interface APIs still exist. If you're interested in some more history on the interface API/netcf difficulties, check out <a href="https://www.redhat.com/archives/virt-tools-list/2018-October/msg00049.html">Laine's email</a> to virt-tools-list.</p>Setting custom network names on Fedora2018-10-04T21:27:00-04:002018-10-04T21:27:00-04:00Cole Robinsontag:blog.wikichoon.com,2018-10-04:/2018/10/setting-custom-network-names-on-fedora.html<p><a href="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/">systemd predictable network names</a> give us host interface names like <strong>enp3s0</strong>. On one of my hosts, I have two interfaces: one that is my regular hard wired connection, and another I only plug in occasionally for some virt network testing. I can never remember the systemd names, so I want …</p><p><a href="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/">systemd predictable network names</a> give us host interface names like <strong>enp3s0</strong>. On one of my hosts, I have two interfaces: one that is my regular hard wired connection, and another I only plug in occasionally for some virt network testing. I can never remember the systemd names, so I want to rename the interfaces to something more descriptive for my needs. in my case <strong>lan0main</strong> and <strong>lan1pcie</strong></p>
<p>The page referenced says to use systemd links. However after struggling with that for a while I'm that's only relevant to systemd-networkd usage and doesn't apply to Fedora's default use of NetworkManager. So I needed another way.</p>
<p>Long story short I ended up with some custom udev rules that are patterned after the old 70-persistent-net.rules file. Replace <code>$MYMAC1</code> and <code>$MYMAC2</code> with your specific values</p>
<div class="highlight"><pre><span></span><code><span class="gp">$ </span>cat /etc/udev/rules.d/99-cole-nic-names.rules
<span class="go">SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$MYMAC1", ATTR{type}=="1", NAME="lan0main"</span>
<span class="go">SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$MYMAC2", ATTR{type}=="1", NAME="lan1pcie"</span>
</code></pre></div>Easy qemu commandline passthrough with virt-xml2017-03-24T21:30:00-04:002017-03-24T21:30:00-04:00Cole Robinsontag:blog.wikichoon.com,2017-03-24:/2017/03/easy-qemu-commandline-passthrough-with.html<p>Libvirt has supported <a href="https://libvirt.org/drvqemu.html#qemucommand">qemu commandline option passthrough</a> for qemu/kvm VMs for quite a while. The format for it is a bit of a pain though since it requires setting a magic xmlns value at the top of the domain XML. Basically doing it by hand kinda sucks.</p>
<p>In the …</p><p>Libvirt has supported <a href="https://libvirt.org/drvqemu.html#qemucommand">qemu commandline option passthrough</a> for qemu/kvm VMs for quite a while. The format for it is a bit of a pain though since it requires setting a magic xmlns value at the top of the domain XML. Basically doing it by hand kinda sucks.</p>
<p>In the recently released <a href="https://blog.wikichoon.com/2017/03/virt-manager-141-released.html">virt-manager 1.4.1</a>, we added a virt-install/virt-xml option <code>--qemu-commandline</code> that tweaks option passthrough for new or existing VMs. So for example, if you wanted to add the qemu option string <code>-device FOO</code> to an existing VM named <strong>f25</strong>, you can do:</p>
<div class="highlight"><pre><span></span><code>$ ./virt-xml f25 --edit --confirm --qemu-commandline="-device FOO"
<span class="gd">--- Original XML</span>
<span class="gi">+++ Altered XML</span>
<span class="gu">@@ -1,4 +1,4 @@</span>
<span class="gd">-<domain type="kvm"></span>
<span class="gi">+<domain xmlns:qemu="https://libvirt.org/schemas/domain/qemu/1.0" type="kvm"></span>
<name>f25</name>
<uuid>9b6f1795-c88b-452a-a54c-f8579ddc18dd</uuid>
<memory unit="KiB">4194304</memory>
<span class="gu">@@ -104,4 +104,8 @@</span>
<address type="pci" domain="0x0000" bus="0x00" slot="0x0a" function="0x0"/>
</rng>
</devices>
<span class="gi">+ <qemu:commandline></span>
<span class="gi">+ <qemu:arg value="-device"/></span>
<span class="gi">+ <qemu:arg value="foo"/></span>
<span class="gi">+ </qemu:commandline></span>
</domain>
Define 'f25' with the changed XML? (y/n):
</code></pre></div>virt-manager 1.4.1 released2017-03-08T19:15:00-05:002017-03-08T19:15:00-05:00Cole Robinsontag:blog.wikichoon.com,2017-03-08:/2017/03/virt-manager-141-released.html<p>I've just released virt-manager 1.4.1. The highlights are:</p>
<ul>
<li>storage/nodedev event API support (Jovanka Gulicoska)</li>
<li>UI options for enabling spice GL (Marc-André Lureau)</li>
<li>Add default virtio-rng /dev/urandom for supported guest OS</li>
<li>Cloning and rename support for UEFI VMs (Pavel Hrdina)</li>
<li>libguestfs inspection UI improvements (Pino Toscano)</li>
<li>virt-install …</li></ul><p>I've just released virt-manager 1.4.1. The highlights are:</p>
<ul>
<li>storage/nodedev event API support (Jovanka Gulicoska)</li>
<li>UI options for enabling spice GL (Marc-André Lureau)</li>
<li>Add default virtio-rng /dev/urandom for supported guest OS</li>
<li>Cloning and rename support for UEFI VMs (Pavel Hrdina)</li>
<li>libguestfs inspection UI improvements (Pino Toscano)</li>
<li>virt-install: Add --qemu-commandline</li>
<li>virt-install: Add --network vhostuser (Chen Hanxiao)</li>
<li>virt-install: Add --sysinfo (Charles Arnold)</li>
</ul>
<p>Plus the usual slew of bug fixes and small improvements.</p>