Posts made by nraynaud

@stevewest15 Thanks, I'm not really familiar with XFS. there might be a way to reclaim (trim) or zero the unused place on the disk.

Here are a few of the operations I have in mind:
https://unix.stackexchange.com/questions/44234/clear-unused-space-with-zeros-ext3-ext4

@stevewest15 Hello, can you tell us the list of partitions and what FS are inside the VHD please?

thanks,

Nicolas.

@klou, I see no obvious error, and I can't reproduce to really hunt it.

Since you're building from the sources, would you mind running a special test branch for me in a few days?

Right now, my working copy is tied up with something else that I would like to finish first.

Thanks,
Nicolas.

On it!

@klou
thanks.

I assume all kinds of VMs can be backed up in delta. I don't have any connection between the VM type and the remote type.

@klou is it happening in a full backup? (this question will help me look at the right place in the code)

@cdbessig Thanks.

I need to investigate the bug further.

About the folder: are you using AWS S3 or something else? Because S3 normally doesn't need to create a folder, you can just write straight wherever you want, and I was wondering if "S3-compatible" emulate this behavior.

it should be fixed in this PR: https://github.com/vatesfr/xen-orchestra/pull/5242

You can test it if you build from the sources and pull the PR.

nraynaud created this issue in vatesfr/xen-orchestra

closed fix(fs/S3): support 50GB+ files #5242

The fix should be here: https://github.com/vatesfr/xen-orchestra/pull/5255 if you have the ability to test Xo from the sources

nraynaud created this issue in vatesfr/xen-orchestra

closed fix(xo-vmdk-to-vhd/grabTables): read each entry independently #5255

@dgmcdona I see that the system did not recognize the disk, I will look into it deeper.

@dgmcdona Ok I'm downloading it I will take a look.

@klou sorry you'll have to put a directory for now. I have not taken the time to make it optional yet.

@martinhorton yes, if you were running from the sources, you'll need to rebuild from master.

If you're using Xen Orchestra Appliance, the fix is available in the 'latest' channel in version 5.48.1 https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md

you can follow the bug fix here: https://github.com/vatesfr/xen-orchestra/pull/5129

nraynaud created this issue in vatesfr/xen-orchestra

closed fix(import/OVA): fix big size parsing in OVA files #5129

@cbritton privately sent me a file that exhibit the error, many thanks. I am searching for the bug now.

@cbritton thank you, that would be great.

I really want everybody here know that I believe there is a bug in my code, it's just that I really need help reproducing on my machine to pinpoint it.

@martinhorton Haha, sorry, it's the VMDK parser.

OVA files are a tar files containing an XML file (.ovf) that describes the VM and .vmdk files that representing the disks. The VMDK file format uses a specific vocabulary, and each block of data is called a "grain" and there is a table that contains all the addresses of the "grains". The parser couldn't find it.

Can someone please send me a .ova file that triggers this error? I really need to trigger it on my machine to fix it.

thanks,

Nicolas.

@tofaz I don't see the parsing problem with the .ova file you sent me.

I have another test you could try: extract the .vmdk file from the ova, and try importing the disk itself, you should get the same error since it's the same .vmdk parser.

@tofaz thanks, I'll have a look at it.