I’m brand new to QubeOS so apologies if I’m missing something obvious
(Note: heavily edited - original post was mistaken about the cause issue)
When using the UI to move files between AppVMs, the UI silently fails if the directory contains unsafe symbolic links.
Only running qvm-copy displays the explicit issue.
As a new user, this caused quite a bit of a headache figuring out (from the UI) what was going on.
Could we consider adding an explicit UI message in case of a failure ?
Thanks !
Without more detail it’s difficult to comment, but my guess would be
that the copy is failing silently. This might be because the
directories contain links. This would be evident if you use the command
line tool.
(Ive copied very large directories between qubes with multiple files,
so there is no intrinsic reason why this wont work)
Thanks, you are correct about symlinks, in fact I figured out as much some minutes ago and edited the original post.
(Ive copied very large directories between qubes with multiple files,
so there is no intrinsic reason why this wont work)
Maybe slightly off-topic, but I’m currently trying to copy a single 300Gb folder containing hundred of thousands of items.
I used qvm-move --ignore-symlinks PopOS/, which worked fine for the first ~50Gb, and suddently the transfer halted to a snail’s pace, and the whole QubeOS started lagging like crazy. Am I doing something wrong ? I should have plenty of RAM, and I don’t see why disk I/O issues would suddenly pop at 50Gb…
xentop - 10:16:38 Xen 4.19.4
10 domains: 3 running, 5 blocked, 2 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 100394128k total, 31103488k used, 69290640k free CPUs: 24 @ 2419MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
debian-13- --b--- 28 0.5 4079672 4.1 4097024 4.1 2 0 0 0 4 0 13093 2392 930613 333320 0
disp4661 ----p- 3 0.0 346376 0.3 4097024 4.1 2 0 0 0 4 0 4360 93 238773 4304 0
disp5625 ----p- 4 0.0 365164 0.4 4097024 4.1 2 0 0 0 4 0 4283 122 229653 12024 0
Domain-0 -----r 12667 58.3 4177924 4.2 4195328 4.2 24 0 0 0 0 0 0 0 0 0 0
kopia-popo -----r 13473 76.5 8175672 8.1 8193024 8.2 6 0 0 0 4 0 871184 5076471 150001125 1102469400 0
sys-firewa --b--- 326 0.5 4079672 4.1 4097024 4.1 2 0 0 0 4 0 8842 6438 776325 978448 0
sys-net --b--- 374 0.7 290860 0.3 308224 0.3 2 0 0 0 4 0 1040013 125273 27429269 2567136 0
sys-net-dm --b--- 250 0.4 147456 0.1 148480 0.1 1 0 0 0 4 0 200 0 40154 0 0
untrusted --b--- 3302 1.8 4079672 4.1 4097024 4.1 2 0 0 0 4 0 63742 87617 7542462 9208656 0
vault-popo -----r 692 72.5 4079672 4.1 4097024 4.1 2 0 0 0 4 0 9124 652083 765517 159715696 0
(for context: I’m copying from kopia-pops-restore to vault-popos)
I’m afraid I dont see edits. Congrats on working it out yourself.
I havent seen this behavior. I’ll try some tests to see what may be
happening.
Thanks.
Some additional notes that might help for context:
After a long while (50+ min), the qvm-move progress got unstuck and moved forward again at a normal pace. This reminded me of the following that happened when creating the current backup using Kopia: in my backed-up files, I have some large (10Gb) media files, which are already fairly compressed. Since I applied a “strong” compression algorithm to my backup, the backup spent a significant amount of time trying to compress those huge media files. Could it be that qvm-move uses a similar compression under the hood, which is great for small files but results in large transfer times for huge compressed files ?
A note for the docs/… from a new user: it was unclear to me that qvm-move only moves the content of a folder after all of its contents have been moved. Practical use case: I have 400Gb of space left and am trying to move a 300Gb folder from one VM to another. I thought qvm-move would incrementally move the files within the folder, but this is not the case - I need to move the subfolder individually, unless I will run out of space. Would that benefit from being added to the docs ?