8:32 a.m.
On 15/03/11 11:47, Richard W.M. Jones wrote:
On Fri, Mar 11, 2011 at 01:34:48PM +0000, Matthew Booth wrote:
[...]
You seem to be convinced this is better, and I'm not going to argue
with that, so ACK to the patch in general.
I have specific comments on the fields you are (not) preserving below.
> +%
> + name The name of the domain
I think you need to include the /domain/description free text field
here too.
Also /domain/uuid seems pretty important.
Ok.
Is there nothing /domain/os which is important? How about
/domain/os/sysinfo (SMBIOS information).
For more esoteric stuff like this, I would prefer to wait until it's
actually shown to be a problem in practise.
> + memory The memory assigned to the domain, in bytes
I'm assuming that virt-v2v no longer runs on 32 bit architectures (or
else sizes in bytes tend to get converted to floats and rounded
awkwardly). Is there a check for this, like the one in virt-resize?
http://git.annexia.org/?p=libguestfs.git;a=blob;f=tools/virt-resize;h=4be...
Nice. I hadn't actually considered this at all. Is there any way to make
perl do 64-bit integers?
> + cpus The number of cpus assigned to the domain
CPU topology? This appears to be important for performance -- we
recently discovered that the performance of 1 [virtual] socket with 4
[virtual] cores is quite a lot worse than the performance of 4
[virtual] sockets each with 1 core, because the guest OS schedules
things differently.
I'm currently completely ignoring topology for libvirt targets, and
defining N single-core CPUs for RHEV targets. How important do you think
this is? I don't see this as a major issue to include, but I'd prefer
the simplest possible solution.
I would also preserve libvirt's lifecycle actions,
/domain/on_poweroff, /domain/on_reboot and /domain/on_crash, unless
you know otherwise.
I can include these.
> + arch The architecture of the domain (eg i686,x86_64)
> + features[] An array containing 'features', as defined by libvirt
> + disks[] An array containing hashrefs of disk descriptions
> + device The name of the disk as seen by the guest (eg sda)
> + path The path to the device's storage, as known to the source
> + or target hypervisor. This will probably not be a valid
> + local path
> + (local_path) A local path to the device's storage, as usable by
> + libguestfs during conversion. This is populated by
> + copy_storage()
> + is_block 1 if the device uses block storage, 0 if it uses a file.
> + format The file format used by the underlying storage, as known to
> + qemu (eg raw,qcow)
I have no idea if we should be trying to preserve the
/domain/devices/controller elements and/or
/domain/devices/disk/address (to avoid Windoze reactivation).
I don't think so. Windows reactivation is basically unavoidable as so
much changes.
> + removables[] An array containing hashrefs of removable media
devices
> + name The name of the device, as seen by the guest (eg fd0)
> + type The device type, as defined by libvirt (eg floppy,cdrom)
> + nics[] An array containing hashrefs of NIC descriptions
> + mac The mac address
> + vnet The name of the virtual network the NIC will connect to
> + vnet_type The type of virtual network the NIC will connect to, as
> + defined by libvirt (eg network,bridge)
Sound cards?
Well they're specifically a source of problems ;) The current code
removes them explicitly. I'm happy to leave these out for the moment.
It's also worth mentioning that Dan Berrange suggested on IRC that
serial and parallel devices should be preserved.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490