[Libguestfs] [PATCH 2/2] Use an internal representation of domain metadata

[Richard W.M. Jones]

On Tue, Mar 15, 2011 at 01:32:06PM +0000, Matthew Booth wrote:
> 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.

Dan ^^ ?

> >>+  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=4beb45b57df315e551ecb4be8b3748e2a565eeb0;hb=HEAD#l33
> 
> Nice. I hadn't actually considered this at all. Is there any way to
> make perl do 64-bit integers?

There's probably a CPAN module for it, but AFAIK 32 bit Perl cannot
natively do anything useful with 64 bit numbers without having it
convert them to floats which causes additional problems.

> >>+  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.

N x single core CPUs should be OK (it would be a problem if you were
defining it the other way around).  However I guess some people will
have specially set up topologies and won't want to lose them.  Unclear ...

> >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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/