Libvirt issues from upgrade

lhinds · 2017-03-06 16:11:46

Hi,

I raised the following issue [1], but the result was that it got closed and I got told in so many words, that I did not know how pacman works. Maybe that is true, so I am here to try and learn..

I had an issue starting libvirt domains, and so looked into `/var/log/pacman.log` as I recall a libvirt upgrade had occurred last time I ran pacman:

[2017-03-05 13:43] [ALPM] error: cannot remove /var/lib/libvirt/images/ (Not a directory)
[2017-03-05 13:43] [ALPM] warning: /etc/libvirt/qemu/networks/default.xml installed as /etc/libvirt/qemu/networks/default.xml.pacnew
[2017-03-05 13:43] [ALPM] upgraded libvirt (3.0.0-1 -> 3.1.0-1)
[2017-03-05 13:43] [ALPM-SCRIPTLET] >>> You may need to run 'rm -rf ~/.libvirt'

I actually had a symbolic link to a different path for pointing to /var/lib/libvirt/images/ , and the link had been deleted. I also found the default network had been destroyed, so had to recreate it that too. Once I set the symbolic link again, I was back in business and could start my domains.

Is this a case of an upstream issue caused this? I assumed (maybe incorrectly) that it would have been the upgrade, as the ALPM library reports the directory remove?

[1] https://bugs.archlinux.org/task/53179

Last edited by lhinds (2017-03-06 16:14:31)

Scimmia · 2017-03-06 17:32:32

You replaced a managed dir with a symlink. This is wrong and only worked by sheer luck; it would have failed if there were any managed files in the dir. You should have been using a bind mount.

You said that pacman would have deleted the dir, which is won't. Pacman will delete empty dirs after it removes the managed files from it, but it will not delete them if they're not empty. This only became an issue for you because of point 1 above.

lhinds · 2017-03-06 18:48:58

On what do you base it to be wrong apart from it breaks this rare edge case? bind mounts are really not an ideal choice as the data then resides in two locations (see the accepted answer on this stackexchange thread. Symlinks are useful as they result in the object working directly on the target files themselves, with no replication to end up creating scenarios where the same file is processed twice. Not sure what you need to manage as well in images/ its a user directory.

Either way, putting aside the above, is there any reason for disabling autostart in the default network?

Last edited by lhinds (2017-03-06 18:57:21)

Scimmia · 2017-03-07 01:35:47

You are misunderstanding how bind mounts work, there is no replication of data. Pacman also will not traverse symlinks.

The maintainer decided to disable the automatic starting of the network, making it opt-in instead of opt-out. Nothing wrong with that.

GSF1200S · 2017-03-10 05:49:47

Im guessing you use btrfs and use a symlink to link outside your rootfs tree (so that you can disable CoW for the virtual machine image directory), yes? This is what I do.

Until Scimmia's reply, I had no idea using a symlink here was considered bad form- I've been using a symlink in this case for years (its the only user-generated symlink I have). Ill have to look into this further as I try to follow standards to avoid problems. Thinking about it now, a bind mount does make more sense- the data doesnt really exist in two places as he says, and it would avoid this inconvenience.

Whenever I update libvirt, I too have had to recreate that symlink (so normal). However unlike you, I have not ever had my network settings mess up- I dont know exactly what happened on your end there.

Slithery · 2017-03-10 08:38:34

GSF1200S wrote:

Im guessing you use btrfs and use a symlink to link outside your rootfs tree (so that you can disable CoW for the virtual machine image directory), yes? This is what I do.

Why not just disable CoW for the VM directory...

chattr +c /var/lib/libvirt/images

GSF1200S · 2017-03-15 23:50:18

slithery wrote:

GSF1200S wrote:
Im guessing you use btrfs and use a symlink to link outside your rootfs tree (so that you can disable CoW for the virtual machine image directory), yes? This is what I do.
Why not just disable CoW for the VM directory...
chattr +c /var/lib/libvirt/images

Because if you take a snapshot of the rootfs subvolume (for example a preupgrade snapshot, a weekly, monthly, etc), CoW will be enabled for any directories contained within that subvolume, including /var/lib/libvirt/images. I could try to set that directory up as a subvolume (where /var/lib/libvirt/images is a subvolume within the rootfs subvolume), but then it becomes a PITA to easily delete rootfs, and my weekly snapshot script would grow markedly in complexity. Rather than all that hassle, I just symlinked out of the subvolume to KVM subvolume that is at subvolid=0 (in other words, where rootfs and all other subvolumes are stored), and disabled CoW on the images directory contained within. I mean, it has worked for years... only upgrades to libvirt have required manual intervention on my part (to refresh the symlink).

Again though, I never considered bind mounts. Im going to look into that this weekend

Arch Linux

#1 2017-03-06 16:11:46

Libvirt issues from upgrade

#2 2017-03-06 17:32:32

Re: Libvirt issues from upgrade

#3 2017-03-06 18:48:58

Re: Libvirt issues from upgrade

#4 2017-03-07 01:35:47

Re: Libvirt issues from upgrade

#5 2017-03-10 05:49:47

Re: Libvirt issues from upgrade

#6 2017-03-10 08:38:34

Re: Libvirt issues from upgrade

#7 2017-03-15 23:50:18

Re: Libvirt issues from upgrade

Board footer