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

Dear Cole & Fellow List Members:

                                                    Had some
''tap-dance''
at the virt-manager site (which I will deal with later) so I patched 
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 (...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.

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

#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!]

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

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

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