[Fedora-xen] Re: virt-clone/Fedora 8/Xen3.1 ... ERROR: Disk size must be an int or a float.

[Cole Robinson]

Hi,

Petrus B. van Bork wrote:
> 
>                                                     Had some 'tap-dance' 
> at the virt-manager site (which I will deal with later) 

Just wondering what issues you had. If the documentation to build
from source isn't clear I'd like to improve it.


> CloneManager.py, on my machine, as per the first link Cole, so kindly, 
> provided. I deleted the one line shown in red with a minus, and added 
> the following line, in green, with a plus (...just for the record).  
> This resulted in virt-clone running - but very touchy.  After the change 
> virt-clone would still not run interactively - it would ask for a disk 
> and go back to the prompt and it would not run with a full string of 
> command line switches 

I'm a bit confused. I see below that just running 'virt-clone' fails
(this is a bug that needs to be fixed) but a full string of cmds 
fails as well? I can't seem to reproduce this.

> (...as illustrated in my last email and Cole's 
> reply).  It would, however, run:
> 
> #virt-clone -f foo.dsk
> 
> ...at that point it would ask for several things, including the original 
> clone's UUID or name (...this for those trying it for the first time, 
> seems to need the Virtual Machine Manager running and connected to the 
> Xen hypervisor but, of course, with the DomU to be cloned "Shutoff").
> 
> When the cloning began it started with:
> 
> libvir: Xen Daemon error : GET operation failed:
> libvir: Xen Daemon error : GET operation failed:
> 
> ...then I got - to my relief...
> 
> Cloning from /home/xenguest/hanoverguest.dsk to KohaHanoverConf_Gold.dsk
> 
> ...this worked...sort of...no more error messages BUT the result I ended 
> up with was:
> 
>     * an .sxp file that did not have a disk path to the .dsk,
>     * and it was missing a number of other things as well such as the
>       reference to localhost:5900
>     * tried running "xm create"  But...xm create would not run command
>       xm create -c /... path to UUID/config.sxp resulted in:
> 
> Error: Errors were found at line 5 while processing 
> /var/lib/xend/domains/...UUID.../config.sxp: (VCPUs_live 1) - alas, this 
> was the 100% identical line from the config.sxp that it was lifted from 
> (...the running DomU).
> 
>     * virsh didn't like the .sxp either and I was not sure how to create
>       an xml for it to read, just don't know enough and not enough
>       documentation available.
>

After a successful virt-clone, the domain will already be defined. This
means both virsh and xm know it exist. You shouldn't need to run xm
create at all: just try 'virsh start cloned_vm_name' or
'xm start cloned_vm_name' and the guest should run.

virsh doesn't sxp files, it uses xml. Try 'virsh dumpxml cloned_vm_name'.

> At the end of the day - another day spent fruitlessly trying, trying, 
> trying... I am a little further than yesterday but I am no further than 
> I was this morning.  Still completely unable to get the new cloned DomU 
> to run.  Using #xm start <domainName> changes the status to 'running' in 
> Virtual Machine Manager but with 0 CPU usage and RAM usage.  Does anyone 
> have any idea what is wrong?  I am still in the dark and would still be 
> most grateful for any more illumination on this!
> 
> Best,
> 
> P.
> 
> -------------------------------------------
> 
> Other Issues with virt-clone after fix, this morning:
> 
> #virt-clone
> 
> ...result: ERROR: A new disk image file for the cloned guest is 
> required, followed by a command prompt...  [...no interactive 
> functionality available, as yet...]
>

As mentioned above this is definitely a bug.
 
> #virt-clone -f testdisk.dsk
> 
> ..result "What is the name or uuid of the original virtual machine? 
> [...which is the correct response but you have not fed the script a path 
> and will result in a config.sxp with no path for the disk!]
> 

This is also a bug, we should put the full path in the cloned guest config.

> #virt-clone -f /var/lib/xen/images/testdisk.dsk
> 
> ...result: ERROR: Disk size must be an in or a float.
>              What would you like to use as the disk path?  
> [...problematic...can't seem to use '-f' switch, as per man syntax, 
> unless I have misread the man....)
> 

I can't reproduce this. -f and --file should give the exact same
result: they literally call the same functions.

> #virt-clone --file /var/lib/xen/images/testdisk.dsk
> 
> ...result: "What is the name or uuid of the original virtual machine?
> 
> 
> So...my question to Cole: "Does the version from the virtual manager 
> site, as per your second provided link, fix the above as well?  Or, not 
> yet?"  Obviously, if the material at the repository is better/later, I 
> will use it, once I figure out "hg" - which is 'unknown command' on my 
> system, presently.
> 
> 

The 'hg' command belongs to the mercurial package (intuitive, I know.) To
use the upstream checkout, try this:

yum install mercurial
hg clone http://hg.et.redhat.com/virt/applications/virtinst--devel
cd virtinst--devel
./virt-clone insert-args-here

Let us know how that goes and if you are still encountering above
issues I couldn't reproduce.

Thanks,
Cole