Le blog de pingou

I use virt-manager to create and manage the virtual machines running on my laptops. However, by default, virt-manager wants to store the disk image for any new virtual machine it creates on /root/.local/share/libvirt/images/... (on Fedora 34, I remember it was on /var/lib/ on some earlier releases).

The issue is that my / is on a different partition than my /home and this one is much larger (400G) than / (60G). So if I place the disk images on either of the two locations above, I will end up quickly filling up my / which causes all kind of problems :-)

Since last week, I've created a bunch of virtual machines so I needed to figure out this storage location question.

I ended up finding out that I can simply create an empty qcow2 image that I can then use with virt-manager.

To create the qcow2 image simply run:

qemu-img create -f cow2 <name>.qcow2 <size>

For example:

qemu-img create -f qcow2 os_tree_gnome.qcow2 20G

This creates a 20G disk image named os_tree_gnome.cqow2, which can then be used by virt-manager.

To do this, when creating a new virtual machine with virt-manager, select import existing disk image, then browse to the qcow2 image you just created. Select the name of the OS, specify the number of CPUs and the memory the VM will have and on the last screen click on Customize configuration before install. This will allow to see the settings of the virtual machine before it is installed. That allows you to click on Add Hardware of type Storage. There select Device type and make it a CDROM device which allows you via the Manage button to pick the iso of your choice (boot.iso, dvd.iso...). Once the CDROM device is added, go to the Boot Options in the settings of the virtual machine and ensure that the CDROM is checked.

At this point you can click on Begin Installation and the VM will boot from the qcow2 file, which is empty so it will fall back on booting from the CDROM device which contains your ISO.

The package database pkgdb2 is the place where is managed the permission on the git repositories.

In simple words, it is the place managing the "who is allowed to do what on which package".

For each package, when they are created, the summary, the description and the upstream URL from the spec file are added to the database, which allow us to display the information on the page concerning the package. However, until two weeks ago, this information was never updated. That means that if you had an old package whose description had changed over time, pkgdb would present the one from the time the package was created in the database.

Nowadays, we have a script running on a weekly basis and updating the database. Currently, this script relies on the information provided by yum's metadata on the rawhide repo. This means that packages that are only present in EPEL or that are retired on rawhide but present in F21, will not have their information updated. This is likely something we will fix in the future though.

In the mean-time, you can now enjoy a pkgdb with summary and description information for almost all packages!

As an example, checkout the fedocal page, you can now see a link to the upstream website, a short summary and a little longer description of the project.

Also, to give you a little hint on the amount of updates we did:

The first time we ran the script:

 16638 packages checked
 15723 packages updated

Last week's run:

 16690 packages checked
 50 packages updated

Did you know?

You know copr right ? This tool to create easily your own yum repo building the RPMs in a new cloud instance everytime. It allows you to give access to nightly builds or a new version of a software backported from rawhide.

Well, if you have been playing with the development instance, know that in the sources there is a CLI tool!

Some example of what it can do if run directly from the sources:

$ python copr_cli/main.py -h
usage: copr-cli [-h] [--version] {create,list,build} ...

optional arguments:
  -h, --help           show this help message and exit
  --version            show program's version number and exit

actions:
  {create,list,build}
    list               List all the copr of the provided
    create             Create a new copr
    build              Build packages to a specified copr

And a small demo:

$ python copr_cli/main.py list toshio
name                |description                                                                                           |repos |instructions
-----------------------------------------------------------------------------------------------------------------------------------------------
fas2                |RPMS for the Fedora Account System run in Fedora Infrastructure.                                      |      |
packagedb           |Package Database that manages ownership of packages for Fedora.  Includes both the client and server. |      |
flowhub             |flowhub adapts the gitflow workflow to github repositories                                            |      |
python-fedora-devel |                                                                                                      |      |

Some documentation on how to setup copr-cli is present in the README in the source

Did you know?

Do you know about HyperKitty? It is this new interface for mailing-list archives offering a forum-like experience for those that prefer forum over mailing-list.

The latest version (which you can see online on the development server) allows you to

• create a new thread in the list as you would create a new thread in a forum
• reply to an email sent on the list as you would reply to a post in a forum
• tag posts on the list
• like/dislike post sent on the list
• get an overview of the list activity (see for the Fedora-devel mailing list)

Want more info?

Checkout:

• The project (which has links on the front page to the original brainstorms)
• The mailing-list
• The development instance